Harness Onboard

Writes adapters/{target}/MANIFEST.md — the facts — and adapters/{target}/overlay/, derived from them. Both are tracked: the overlay is a cache of the manifest, so nobody pays the probe cost twice and a diff shows when a release moved a path. {target} = a lowercase slug, one per install, not per binary — a wrapper pointing the binary at its own config directory is its own target. A harness used only as a dispatch target needs no adapter; dispatch-configurator probes it per machine.

Evidence over documentation. Every row comes from something that answered on this machine; nothing answered → unknown, the harness lacks it → gap. Both stay visible; neither gets guessed — a wrong seed multiplies into every install.

1. Frame

• Existing manifest → re-verify: probe every row verified on an older version than the installed one, plus whatever the user names; keep the rest.
• New target → fill templates/MANIFEST.md. Read one existing manifest for the kind of answer a row wants, never for its value.
• Resolve the binary and its version first — not on PATH is itself a fact for the Binary line.

2. Levers first

Before any row, find what makes rows checkable without a model call: --help of every subcommand, recursively — debug, doctor, config print or validate, prompt rendering, session export, the transcript store, a published config schema. Each goes into Verification levers with what it shows. They turn an unfalsifiable install into a checkable one; a harness with none gets its checks from scratch runs, and the manifest says so.

3. Probe each row

Strongest evidence first; stop at the first that answers:

1. A lever's output.
2. A throwaway probe, removed afterwards — a stub skill, agent or import in a scratch repo or a junctioned folder, then the lever or one run to see it picked up. A file existing proves nothing; only the harness reporting it does.
3. A binary string dump (grep -a, strings) — paths, config keys and defaults the docs omit.
4. Official docs or schema, fetched — never recalled.
5. Upstream issues — a lead, never a verdict.

• Check the check: a comparison that filters lines (say, those containing {) can skip exactly the wrong one.
• A row that needs a model run: point the harness at a local endpoint through its custom-provider config instead of a subscription, and fill Custom provider on the way. Scope tools per run rather than bypassing permissions. A small model proves wiring, not workflow quality.
• Dispatch is proven by the child's own record — transcript, export or rollout naming the agent and carrying its instructions — never by the parent's report.

4. Derive the overlay

Files sit at the exact paths they land on in {home}; overlay/adapter/ holds the folders and files workspace-sync step 3 defines. From the manifest:

• Instruction shim overlay/{global instruction file} — only where that file isn't AGENTS.md: it imports AGENTS.md and, given an import lever, ~/.agents/memory/MEMORY.md.
• adapter/merge/ — the home config's instructions list where that is the memory lever, and capability entries (MCP, plugins) in the harness's own shape.
• adapter/project-merge/ — the project config's MCP block and pre-approval, plus the domain-memory entry where the lever is a list.
• adapter/project/ — the project shim, where Project → Instruction shim says needed.
• adapter/threads.md — where Threads names a session-start tool: how to start one, what reports back, the limits.
• adapter/chat-title.md — where Chat title names a tool: how to call it, how to load it when deferred.
• gap → no file; nothing invented to paper over it.
• The workspace invariants are inputs, not probe results: shared content lives once in ~/.agents/, harnesses are pointed at it, a non-native skills root is linked per folder, agents install flat in the manifest's format with frontmatter per the repo's AGENTS.md.

5. Join the enumerations

Grep the repo for an existing target's home path: every hit outside adapters/ — workspace_TEMPLATE/AGENTS.md — is a list the new target joins. User-facing docs name no harness; they point at adapters/.

6. Prove it

The install is the user's: they run workspace-sync for this target, whose step 7 uses the new levers. Then one end-to-end run in a throwaway repo — a minimal-workflow change with docs and commit, one agent dispatch, a memory read — its outcome into Proven. Commit feat: {target} adapter, or docs: {target} manifest re-verified.