"a reader's issue on an autonomous public repository > the planner's link and a writer's label adopt nothing; a writer's link or assignment does, and it flows" passes every time on a loaded check machine #5255

I couldn't reproduce the flake, so this fix is a best guess. I never saw the test fail, either unloaded or with CPU-hogging processes running beside it.

Likely cause: the test file ran on bun's default 5 s per-test timeout. Every test builds a repository and drives the clock over it, and both shell out to git. Unloaded, that setup took about 140–310 ms. On a machine running many suites at once, spawning git can be slow enough to overrun 5 s. I found no real race in the source on this path. The crew's autonomy loop is not started by createApp, so nothing ticks in the background.

What changed (test/crew-direction-autonomy.test.ts only):

• setDefaultTimeout(30_000) for the file, matching its existing beforeAll. The timeout is a test-harness limit, not a product budget, so no product budget moved.
• The two places that built times from Date.now() (the hour-old run row and the later passed to driveRepo) now share one clock, hoursFromNow(). They no longer read the wall clock separately from the code under test.

No assertions changed, so the test promises the same thing about the product and still fails if adoption or the picking rules break.

How it was checked:

• bun test --rerun-each 30 test/crew-direction-autonomy.test.ts passed 330 of 330 (run before the edit).
• A targeted run of this test under CPU-hog load passed 8 of 8 (also before the edit).
• After the edit, bun test --rerun-each 5 on this file plus test/apps.test.ts passed 160 of 160.
• bun x tsc --noEmit is clean.

If it still flakes on the check machine, look at the failure message: a timeout means git is slow there, and anything else points at a real race I didn't find.

🤖 Generated with Claude Code

Closes #5199

I couldn't reproduce the flake, so this fix is a best guess. I never saw the test fail, either unloaded or with CPU-hogging processes running beside it.

Likely cause: the test file ran on bun's default 5 s per-test timeout. Every test builds a repository and drives the clock over it, and both shell out to git. Unloaded, that setup took about 140–310 ms. On a machine running many suites at once, spawning git can be slow enough to overrun 5 s. I found no real race in the source on this path. The crew's autonomy loop is not started by createApp, so nothing ticks in the background.

What changed (test/crew-direction-autonomy.test.ts only):

• setDefaultTimeout(30_000) for the file, matching its existing beforeAll. The timeout is a test-harness limit, not a product budget, so no product budget moved.
• The two places that built times from Date.now() (the hour-old run row and the later passed to driveRepo) now share one clock, hoursFromNow(). They no longer read the wall clock separately from the code under test.

No assertions changed, so the test promises the same thing about the product and still fails if adoption or the picking rules break.

How it was checked:

• bun test --rerun-each 30 test/crew-direction-autonomy.test.ts passed 330 of 330 (run before the edit).
• A targeted run of this test under CPU-hog load passed 8 of 8 (also before the edit).
• After the edit, bun test --rerun-each 5 on this file plus test/apps.test.ts passed 160 of 160.
• bun x tsc --noEmit is clean.

If it still flakes on the check machine, look at the failure message: a timeout means git is slow there, and anything else points at a real race I didn't find.

🤖 Generated with Claude Code