Stop the git fixtures from making the local suite red

[VeryComplexAndLongName]

Implements git-fixture-test-cost (18/19) and proposes the one follow-up its verification uncovered.

Result

Full npm run test on this machine, before → after:

	Failing files	Failing tests
Before	3	8
After	1	1

change-timeline.test.ts and sprint-report.test.ts now pass inside the full run, not only alone — which is the distinction that matters, since they always passed alone.

What made them expensive

initRepo was three processes (init plus two addConfig), and every commit two more. The identity now travels in the env the commit helpers already set, so a repository costs one spawn instead of three. Tests that only read an unchanging repository build it once and share it, with the no-mutation rule stated at the fixture's construction rather than left to be inferred.

Cleanup moved from afterEach to afterAll, and that is what ends the EBUSY: resource busy or locked, rmdir failures — the git processes holding those directories have exited by then.

Both files carry their measured before and after at the top, and each sets its own per-test ceiling sized against the reduced cost. Not the global default: that would hide the same problem in every suite, including ones with no excuse for it.

No assertion moved in either file. Speed here had to come from spawning fewer git processes, never from mocking the git being measured — otherwise the change deletes the coverage it exists to protect.

Seven active task lists carried a note calling these two files "pre-existing Windows timeout flakes … do not attempt to fix them here". That condition is over, so the notes are gone. Archived changes are untouched — their notes were true when written.

Task 6.3 stays open, and why

What still fails under co-load is a different file for a different reason:

FAIL src/harness-chain-runner.test.ts > semi-autonomous
     > confirming a checkpoint resumes into the next stage's agent
AssertionError: expected { kind: 'started', …(4) } to match object { kind: 'completed' }

vi.waitFor defaults to 1000 ms, and that test drives four chain stages through real file writes before the completed event it waits for. No git fixture is involved. Fixing it here would have reached past the two files this change names — which its own task 2.4 explicitly forbids — so it is proposed separately.

load-sensitive-test-timeouts (proposal, included here)

Worth closing rather than living with, for a reason beyond the one test: the failure looks like a product bug and is not. The chain does emit ["plan", "review", "implement", "verify"]; the test simply stops watching too early. A red suite that is actually noise is how this repository lost an eslint error for days, and a suite green only on an idle machine cannot be the gate operations.apply.guidance requires before a commit.

Also closes harness-config-strictness task 7.2, left open pending CI, which went green on #175.

Test plan

• Both target files pass alone
• Both target files pass inside the full npm run test
• openspec change validate --strict — git-fixture-test-cost and load-sensitive-test-timeouts both valid
• npm run lint:english passed
• git diff on the two test files shows setup and timeouts only; no expect changed
• No changeset — test-only, matching archive/2026-09-01-ci-job-timeouts/
• CI green

🤖 Generated with Claude Code