[DM-074] Document adapters for additional harnesses

[nicoechaniz]

Outcome

Publish a version-pinned, harness-neutral adoption guide for extending the frozen DM-018 boundary beyond the proven Codex/Hermes integrations. The guide must let an independent operator decide whether Claude Code, Grok Build, Kimi Code, Google Antigravity, or a generic MCP/CLI host can safely act as a Matrix body harness without granting it identity, ledger, memory, membership, species, source, relationship, routing, or deployment authority.

This is documentation and conformance work, not an implementation or support announcement. A vendor feature page proves only a candidate extension point; live support requires Matrix-owned tests and evidence.

Blocked by

DM-040, DM-041, DM-042, and DM-072.

Dependency order

Documentation preparation is blocked by:

• DM-040 and DM-041 stable CLI/MCP and Codex adapter contracts.
• DM-042 Hermes adapter and independent-/me boundary.
• DM-072 reversible private Codex/Hermes canary evidence.

DM-074 must merge before the exact release-candidate review in DM-073. DM-073 then reviews this guide, its fixtures, and the release candidate that contains them. This replaces the obsolete DM-074 blocked by DM-073 ordering, which would mutate the candidate after approval and invalidate exact-head review.

The implementation/canary prerequisites are complete. Keep status:review until PR #114 receives independent review and merges; technical evidence alone does not close the card.

Evidence discipline and support states

For every harness, record the official source URL, access date, tested product/version/commit, executable digest/install source, config precedence, state roots, auto-update/migration behavior, and limitations. Re-audit at claim time; vendor contracts are mutable.

Use only these states:

1. documented-candidate: official extension points mapped, no Matrix conformance result.
2. synthetic-conformant: pinned build passes the fake-daemon corpus in an isolated profile.
3. private-smoke: consented, reversible private canary passes with redacted evidence.
4. live-supported: all preceding evidence plus an explicit maintained support/version policy.

No state is inherited from another harness or model. Codex/Hermes evidence from DM-040/041/042/072 may be cited; Claude, Grok, Kimi, Antigravity and generic hosts begin as documented-candidate regardless of vendor claims.

Mandatory harness capability matrix

The guide must answer, with evidence, whether each candidate provides:

• a stable isolated home/profile/state root and a way to prevent fallback to a personal/default profile;
• deterministic lifecycle boundaries for process/session start, turn start/end, tool call, response/receipt, park, wake, crash and resume;
• stable system/project instruction injection with documented precedence and an effective-config inspection method;
• a local CLI, stdio/HTTP MCP, ACP, SDK, or equivalent authenticated call boundary suitable for DM-018 request/receipt IDs;
• tool/plugin/hook allowlists and explicit approval policy, with fail-closed handling for unknown or ambiguous actions;
• native session/history/memory disablement or a documented subordinate policy and purge/rebuild procedure;
• secret/token custody, environment/config precedence, log/transcript/export behavior and redaction controls;
• idempotent request/receipt correlation, timeout/crash classification and deterministic retry behavior;
• a way to observe or propose Matrix events without directly appending canonical state;
• proof that the host cannot create/rotate /me, sign as Matrix, choose canonical heads, mint membership/grants, admit memory/source/species, expand audiences, satisfy presence/fence gates, or make deployment effects.

Missing stable prompt, lifecycle, isolation, memory-subordination, receipt, or authority controls means unsupported for a Matrix body canary; MCP/tool calling alone is insufficient.

Candidate profiles from the 2026-08-01 official-doc audit

These links are discovery inputs, not frozen support evidence. Pin them again in the claimed guide.

Claude Code

• Audit official CLI/MCP reference, settings, hooks, permissions, instruction/memory hierarchy, headless structured I/O, session resume and credential storage.
• Use an isolated configuration/state root and explicit allowed/disallowed tools; prohibit --dangerously-skip-permissions in the reference profile.
• Matrix instructions and receipts remain external canonical evidence. CLAUDE.md, auto-memory, transcripts and resumed sessions cannot become identity or autobiography by existence.

Grok Build

• Audit official Grok Build overview, settings and GROK_HOME, MCP, hooks/plugins, permissions, headless/ACP output and session/memory commands.
• Use a fresh GROK_HOME; disable imported Claude configs/MCPs and cross-session memory unless the conformance profile explicitly makes them subordinate. Never use --always-approve/--yolo.
• grok inspect --json is configuration evidence, not authority. Grok web connectors and public-tunnel MCP are outside the local reference profile.

Kimi Code

• Treat MoonshotAI/kimi-code as the current candidate and separately identify the older MoonshotAI/kimi-cli; never silently mix their contracts.
• Pin the executable/repository commit and audit MCP, plugins, lifecycle hooks, ACP, approval, session, system-prompt and tool-gating behavior.
• Install/test only in a fresh isolated profile. Do not trigger automatic migration/import of an operator's prior Kimi configuration or sessions; imported state cannot become Matrix memory.

Google Antigravity

• Audit the official Antigravity IDE/CLI contract and the shared MCP configuration documented by Google, including ~/.gemini/config/mcp_config.json.
• Do not infer stable lifecycle, prompt, memory, isolation, receipt or headless semantics from MCP availability. If official/current controls cannot be pinned and independently exercised, keep the profile documented-candidate or mark it unsupported.
• Use a disposable OS/config home and synthetic credentials; GUI observation is not a canonical receipt.

Generic MCP/CLI host

• Define the lowest-common-denominator protocol: authenticated Matrix daemon endpoint, closed request/receipt schema, stable session/turn/tool IDs, explicit lifecycle events, bounded structured output, idempotency key, timeout classification and no secret/private-key transfer.
• A generic model API is not a harness. A host lacking prompt/lifecycle/profile/memory controls cannot be promoted merely because it supports function calling or MCP.
• No modification or fork of third-party core code is required by V0; unsupported hosts remain outside the body canary.

Synthetic fixture and checker

Add a checked-in, closed harness-adoption-fixture/v0 manifest plus a fake Matrix daemon and deterministic checker that require no network, vendor credentials or private state. It must exercise at least:

• exact version/capability negotiation and fail-closed unknown/downgrade behavior;
• isolated-profile preflight and effective-config digest;
• stable start/session/turn/tool/receipt/park/wake IDs across retry and process crash;
• duplicate request same bytes -> one effect/same terminal result; same ID different bytes -> conflict;
• proposal/observation only, with append/sign/key/membership/memory/source/species/deployment attempts refused;
• native-memory disabled/subordinate behavior, session resume, transcript/export/log secret scanning and profile cleanup;
• tool/hook/plugin/MCP allowlist enforcement and denial of ambient/default profile fallthrough;
• ambiguous timeout, malformed/oversized output, missing receipt, unknown lifecycle event and stale resume;
• adapter disablement/replacement while canonical Matrix state remains intact and rebuildable.

The fixture records vendor-neutral expected events and receipts. Per-harness launch/config snippets are data overlays, not new protocol. Conformance runs use synthetic keys/data and validated disposable roots only.

Deliverables

• docs/harness-adoption-v0.md (or equivalent) with the capability/status matrix, pinned official sources, per-harness profiles, limits, upgrade policy and troubleshooting.
• Machine-readable harness profile schema and example overlays for Claude Code, Grok Build, Kimi Code, Antigravity and generic MCP/CLI.
• Offline synthetic fixture, fake daemon/checker, deterministic expected report and CI invocation.
• Security checklist covering profile isolation, prompt precedence, permissions, native memory, secrets/logs, receipts/retries, authority refusal and cleanup.
• Compatibility policy stating supported version ranges, revalidation triggers and fail-closed treatment of unknown/new vendor behavior.

Acceptance criteria

• Every required capability has an evidence field and pass/fail/unknown result; unknown mandatory controls fail closed.
• Vendor documentation is pinned and clearly separated from Matrix-produced conformance/canary evidence.
• Each candidate has an isolated, least-authority reference profile or an explicit unsupported rationale.
• Synthetic tests prove lifecycle/receipt/idempotency and authority boundaries without live credentials or network calls.
• Native memory/history never becomes canonical autobiography; no shared harness state collapses distinct /me identities.
• No candidate is labeled supported above its achieved evidence state.
• DM-073 reviews the merged guide and fixtures as part of the exact frozen release candidate.

Non-goals and safety

• No live login, paid API call, installation into an operator profile, import/migration of existing sessions, third-party core patch, provider benchmark or production support promise.
• No harness/provider stores Matrix root keys, canonical ledger/CAS, personal-memory authority, membership, species/source admission or Cluster control credentials.
• Never expose a local Matrix MCP endpoint through a public tunnel for this work.
• Cleanup targets only validated disposable roots; preserve redacted config/test evidence and never publish credentials, transcripts or personal paths.

Canonical references

• PLAN.md
• ONTOLOGY.md
• ROADMAP.md
• ISSUES.md
• DM-018 adapter contract and DM-040/041/042/072 implementation/canary evidence at their exact approved heads.

Concurrent-work gate

Do not claim until the dependency order above is satisfied and the card contains the audit's reuse/coordination conclusions. A claim must pin its source versions and synthetic fixture digest; vendor changes after that point require a new conformance run, not silent compatibility.

[nicoechaniz]

Dependency reconciliation (2026-08-10): DM-040, DM-041, DM-042 and DM-072 are closed with their evidence merged. The card is now ready for the offline documentation/profile/fixture work; no vendor credentials, live harness calls or authority expansion are authorized.

[nicoechaniz]

/claim

[github-actions]

[nicoechaniz]

/release

[github-actions]