refactor(harness): declare tool layout in one adapter table

[replygirl]

The harness layer's tool shape was spread across five places that had to agree by hand: harness.yaml's harnesses: block, name branches in render.ts, DETECT_PATHS/RESTART_LINES in init.ts, and separate copies of the roots in update.ts/doctor.ts. None of them could express the per-tool shapes the pinned OpenSpec dist declares (a split commands root, per-extension filename templates, TOML serialization, IDE-restart flags, setup notes). This change puts all of it in one typed HARNESS_TABLE in apps/cli/src/harness/adapters.ts. render.ts, init, update and doctor all read the table, and none of them keeps its own copy. HarnessName/HARNESS_NAMES/isHarnessName are still exported, now derived from the table, and keep the same name, shape and order.

What each consumer reads from the table

• render.ts: skills and command paths, frontmatter builder, injectArguments, rulesPath, and the markdown/toml serializer. The table is injectable through RenderOptions.adapters.
• init.ts: builds the --harness value list and error text from HARNESS_NAMES and detects from each row's detectionPaths. The opsx leftover sweep and doctor's harness scan both read a row's shape through isHarnessDocument/findOpsxFiles. The receipt prints each selected row's setupNote, then upstream's single requiresIdeRestart line.
• update.ts: gets the skills root, legacy roots and the rulesPath marker from the row, and MANAGED_REMOVAL_ROOTS is removalRoots(). Manifest routing is keyed on frontmatter === null, which is how TOML commands get tracked. A scope: 'home' file is refused before any write.
• doctor.ts: attributes a file to the row with the longest-prefix surface (skills root, legacy skills root, commands dir or rules dir), falling back to primary root, and resolves references through the owning row's dialect-aware pattern. Both walks use scanRoots().

None of the four shipped rows sets requiresIdeRestart, so no receipt gains a line.

Byte-identical output

• Render goldens: git diff 70b32f9e HEAD -- apps/cli/test/unit/__golden__/harness-render/ is empty.
• Wiring characterization (init receipts for every harness selection, the invalid --harness error, both detection systems, removal containment, doctor human and --json): re-taken on the rebased, unmodified tree at 2f5a9de7. git diff 2f5a9de7 HEAD -- apps/cli/test/integration/__golden__/harness-wiring/ is empty.
• A sandboxed built-binary cospec init --harness all --yes in a fresh repo, run once from this branch and once from main: both write 127 files to the identical file-tree digest (sha256:599c19a0…0902) and identical normalized stdout (sha256:aa758dca…eb62) — full byte identity, including the version stamp, since the branch rebased onto main's v0.8.3 release before the comparison.
• generate:check shows no drift, test:pack is green, and apps/cli/test/contract/ and parity-pending.yaml have no changes against main.

Review rounds (table-fitness gaps, no behavior change today)

Three post-implementation review rounds found table-fitness gaps — "no behavior change today, breaks when a row is added" — each fixed on this branch before merge:

1. Round 1: update.ts's orphan sweep matched commands by a literal .md filter instead of each row's extension; doctor.ts attributed a file by primary root first instead of the longest matching surface, and matched references only on / instead of the owning row's invocation prefix.
2. Round 2: doctor.ts's harness-file scan and init's opsx leftover scan both read a literal .md filter instead of each row's shape (isHarnessDocument); the init receipt's shared-skills-root line was keyed on the literal ids codex/agents instead of equal resolved skills roots.
3. Round 3: doctor.ts attributed a file by primary root on a tie instead of the longest row surface, missing legacy skills roots as surfaces.

Each fix added a synthetic fixture row to the relevant test file proving the gap, rather than relying on the four shipped rows (which can't exercise it).

Routed by ruling, not fixed here

Two further findings are genuine, user-visible defects on main today — not table-fitness gaps this change introduces — and fixing them here would break the byte-identical scope above. Per ruling, they are routed to a new follow-on PR, harness-receipt-and-doctor-scope, sequenced directly after this one merges:

1. The init receipt's closing Try: /cospec:propose … hint always prints in Claude's spelling, regardless of which row was selected.
2. Doctor's (and init's leftover sweep's) scan reads every .md file under a row's skills or legacy skills root, rather than narrowing to SKILL.md and the table's command paths.

design.md's Non-Goals no longer frame either one as a deliberate choice this change preserves — both are now named as known defects, out of scope here by ruling.

Gates

Rebased onto main twice: first onto d25c5c0 once unknown-option-contract, upstream-spellings and passthrough-json-and-doctor had merged (all three now recorded archived under ## Blocked by), then a second time onto 67f20c5d (the v0.8.3 release plus reset-yes-pipe-flake) — 0 conflicts both times. cospec validate harness-adapter-table --strict passes and cospec apply exits 0. mise run check is green on the final tree: lint, format, typecheck, unit 1891, contract 2403, integration 184, bench 339, release-test 14, all 0 fail; generate:check no drift; agents:check in sync; cospec-validate-all 0 errors.

Archive

cospec archive harness-adapter-table, no flags — validated, moved the change to openspec/changes/archive/2026-10-05-harness-adapter-table/, blocking-changes fully synced. The archive commit touches only openspec/ paths:

 .../2026-10-05-harness-adapter-table}/.openspec.yaml       | 0
 .../2026-10-05-harness-adapter-table}/blocking-changes.md  | 0
 .../2026-10-05-harness-adapter-table}/design.md            | 0
 .../2026-10-05-harness-adapter-table}/proposal.md          | 0
 .../2026-10-05-harness-adapter-table}/tasks.md             | 0
 .../2026-10-05-harness-adapter-table}/verification.md      | 0
 6 files changed, 0 insertions(+), 0 deletions(-)

🤖 Generated with Claude Code

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.