Validate a stage entry against what actually runs it

[VeryComplexAndLongName]

Implements harness-config-strictness (25/27; 7.5 human-only, 7.2 gated on CI — see below).

What it fixes

Three defects in assertValidStepAgents, all of the same family: a configuration that presents itself as effective and is not.

1. An agent that never runs had to be named. "apply": { "agent": "claude-cli", "dispatch": "vscode-chat" } — agent is required and must be a known id, while chat dispatch spawns no process. Chat dispatch is now a step-runner id of its own (vscode-chat) and dispatch is retired. Old files are read and migrated, reported once, not refused — this repository's own config used the old shape.

2. model, effort and budget were silently ignored under chat dispatch. The validator compared each to the agent; claude-cli accepts all three, so the entry passed — while no argv was ever built for the flag to reach. "effort": "high" bought a run with no elevated effort and no message. Now refused, with a message saying the parameter cannot reach anything in that mode rather than that it is merely unaccepted — different problems for whoever reads it.

That was already forbidden here: ADR 0019 and harness-step-effort-and-budget task 2.2 both require refusing, never ignoring. The rule existed; the check compared the setting to the agent instead of to how the stage is delivered.

3. Unknown keys loaded silently. { "agent": "claude-cli", "modle": "claude-opus-5" } ran the default model. Now an error naming the key and the accepted set, at the top level and inside budget. Warning instead was rejected on this repository's own evidence — npm run lint was expected-red for days and a real error passed unread.

Every existing per-agent check is untouched: modelFlag, the accepted effort set, budgetField, Copilot's credit floor. Those were already thorough; this adds a dimension.

Review findings, fixed in this PR

Task 6.4's test could not fail. The task asked for an assertion against the real openspec/agent-harness.json rather than a fixture, because a schema change that breaks the workspace it ships in is what it guards. The test did this:

const workspaceRoot = path.resolve(here, "..", "..", "..", "..");

here is packages/core/src; four .. land one level above the repository root. No config exists there, so readGlobalHarnessConfig returned DEFAULT_HARNESS_CONFIG, whose autonomyLevel: "assisted" and reviewGate.mode: "human-required" are exactly the two values the test asserted. It passed without ever reading the file it names.

Now three .., with the file's existence asserted first (so a moved config fails loudly instead of falling back to defaults again) and stepAgents asserted non-empty — the part the defaults cannot produce.

openspec/agent-harness.json had also lost its trailing newline.

Test plan

• openspec change validate --strict harness-config-strictness
• npm run typecheck — exit 0
• npm run lint and lint:english — exit 0
• harness-config.test.ts — 62 tests, covering each refusal message, both unknown-key paths, both migration paths, and the real repository config
• packages/core/src/agents/ untouched apart from registry.ts's comment (task 7.3)
• Task 7.2 left unchecked. core's change-timeline.test.ts and sprint-report.test.ts fail on this machine with EBUSY: resource busy or locked, rmdir and 5-second timeouts while cleaning up git fixtures. Reproduced in isolation, unrelated to this change (it touches neither file nor anything either imports), and the subject of git-fixture-test-cost. harness-chain-runner.test.ts also failed under full load and passes alone (27/27). CI's Linux runner is the gate.
• Task 7.5 is human-only: set a stage to vscode-chat, confirm the chat opens and the stage shows handed off; then add "effort": "high" and confirm the load is refused with a message naming why.

🤖 Generated with Claude Code