Add the git stage and mechanical verify checks, and fix four defects in them

[VeryComplexAndLongName]

Three changes land together because they were implemented into one working tree and touch the same files: load-sensitive-test-timeouts (10/10), harness-mechanical-checks (29/31), agentic-harness-git-stage (20/23).

load-sensitive-test-timeouts — clean

Each multi-step vi.waitFor is sized against measured cost — ~453 ms isolated, ~1823 ms under deliberate co-load, ceiling 5000 ms — and the single-event waits are left alone, since an unnecessary ceiling is noise and noise is what makes the necessary ones unreadable. The full local suite is green for the first time this week.

Also removed two .tmp-load-sensitive-*.log files the run left in the repository root. Evidence belongs beside the number it justifies, not one git add -A from the history.

The other two arrived reported as finished, and were not

npm run typecheck failed with nine errors, none in core

Narrowing HarnessStepAgents to exclude archive is right — the stage is mechanical, an entry there configures nothing. But every consumer holding a plain HarnessStage still indexed the record: commands.ts, ai-panel.ts, websocket.ts, and five sites in HarnessSettingsView.tsx. core compiled while the other three packages did not, which is precisely what a green vitest run cannot tell you — vitest does not typecheck.

Fixed with isHarnessStepAgentStage and stepAgentFor in the type's own module. Keeping the archive case in one place is what stops the removal from becoming six subtly different guards.

HarnessSettingsView keeps archive in its stage list, as the change's own task 4.4 requires, and renders it as a row saying it runs mechanically — rather than offering controls that write a setting nothing reads. Same treatment commands.ts already gave it.

The git stage carried three defects — all behind the one unchecked task

Task 4.4, the live smoke test, was the only one left unchecked, and all three sit behind it. Not a coincidence, and not a formality.

1. gh pr create does not accept --json. Verified against the installed binary:

$ gh pr create --json number,url --head x --base main --fill
unknown flag: --json

createPullRequest threw every time; the stage could never open a pull request. It now reads the URL gh prints, taking the last line that is one, and treats no URL as an error rather than a guess.

2. SKIPPED counted as a failing check. Anything outside two hard-coded sets was read as a failure. From this repository's own PR #178:

[{"name":"Tag and release VS Code extension","state":"SKIPPED"},
 {"name":"Typecheck, lint, test, and build","state":"SUCCESS"},
 {"name":"Version pending changesets","state":"SKIPPED"}, …]

Two of seven, both conditional jobs that skip on every pull request by design. The gate would have refused every pull request this repository can produce. skipped, neutral and stale are now their own set — ran and decided nothing — and a failure names the state as well as the check.

A case the original had no answer for is now decided explicitly: every check skipped is a refusal, not a pass. Nothing exercised the change, and ADR 0014 already treats an absent result that way. waitForChecks returns it immediately rather than polling a decided answer into a timeout that would report something else.

3. The allowlist gated an invocation that was not the one executed. The stage built git push <remote> <branch>, checked that against the allowlist, audited that — then called GitWrapper.push(), a bare git push resolving both from the branch's upstream. Possibly a different target, and absent entirely on a branch that has never been pushed, which is every branch the stage creates.

The security model's premise is that the checked invocation is the executed one. push(remote, branch) now takes its target, and no --set-upstream either — an extra flag would reopen the same gap from the other side. The integration test no longer establishes an upstream first: it pushes a branch that has none, which is what the stage actually faces.

Also

The changeset named only @openspec-ui/core at patch, for the git stage alone, while both changes moved the public surface of three packages. Corrected to minor across core, webui and the extension.

Left open, deliberately

• harness-mechanical-checks 6.3 — every existing tasks.md asserted against the real openspec/changes/ tree rather than a fixture. Not done, and worth doing: the parser is the one change here whose blast radius is every change in the repository, and a fixture cannot show that. Same shape as harness-config-strictness task 6.4, which passed for days while resolving a path one level above the repository.
• harness-mechanical-checks 6.6 and agentic-harness-git-stage 4.4 — human-only.

Test plan

• npm run typecheck — 0 (was 9 errors)
• npm run lint — clean
• npm run test — green across all four workspaces: core 44/490, extension 17/218, server 3/61, webui 35/230
• openspec change validate --strict — all three valid
• gh pr create --json and gh pr checks --json name,state verified against the real binary
• CI green

🤖 Generated with Claude Code