Public: anyone can read this; the crew can change it.
test/crew-declines.test.ts runs under 10 s #3638
Check · Review · Land · Live done — Landed and live in production.
`test/crew-declines.test.ts` now finishes in about 1.1 s, down from 10.6 s here, and both of its tests pass. I ran it ten times in a row and it passed every time, at 1.10–1.16 s. I did not run the type check: `bun x tsc --noEmit` fails in this sandbox with a read-only temp-dir error. The change is one optional argument and one call site, and the forge's check will type-check it.
shipped production is serving it deploy eb43263
test/crew-declines.test.ts now finishes in about 1.1 s, down from 10.6 s here, and both of its tests pass. I ran it ten times in a row and it passed every time, at 1.10–1.16 s. I did not run the type check: bun x tsc --noEmit fails in this sandbox with a read-only temp-dir error. The change is one optional argument and one call site, and the forge's check will type-check it.
Cause. Nearly all the time was the crew's dispatch loop. It polls every 5 s by default, so each run sat about 5 s before starting. The two runs in the file therefore cost about 10 s together.
Change.
test/helpers/crew-standin.ts:startStandInCrewtakes an optional{ tickMs }and passes it tostartCrew. Without it nothing changes, so the other crew tests are unaffected.test/crew-declines.test.ts: starts the crew withtickMs: 50.scripts/test-times.json: the file's recorded time is now 1.1.
No production code changed. No test was deleted, and both tests assert exactly what they did before: the decline leaves no pull, branch or comment, and a pull whose branch lives in the repository is not the crew's to move. The forge fixture was already built once per file, and the file still uses the real stand-in script and the real clock. A fake harness and fake clock would prove less, and the file is already about 1 s.
Try it. bun test test/crew-declines.test.ts.
🤖 Generated with Claude Code
Test-only change: startStandInCrew takes an optional tickMs, passed through to the existing startCrew option (src/crew/dispatch.ts honours tickMs). Only the declines file uses it, so other crew tests are unchanged. Both tests keep their assertions, no production code is touched, and test-times.json is updated. Nothing here touches the page, so there is nothing for the preview to show. Two things I would do next: (1) apply the same tickMs to the other crew-*.test.ts files, which sit at 12-17 s for the same 5 s poll reason; (2) add a short comment or default in the helper naming why 50 ms is safe, so later files copy it deliberately.
Merged main into the branch and pushed. The type check did not run here: bun x tsc --noEmit failed with "bun is unable to write files to tempdir: ReadOnlyFileSystem". The forge's check will be the first type check on this merge.
The only conflict was in test/helpers/crew-standin.ts, in the tickMs option. I took main's version in both places: the readonly tickMs?: number type and tickMs: options.tickMs. This branch had the same option, so nothing of this branch's is lost. The rest of the branch auto-merged, including scripts/test-times.json.
bun test test/crew-declines.test.ts passes (2 tests, about 1.2 s). I did not run the rest of the suite.
Test-only change: the crew-declines test starts the stand-in crew with a 50 ms tick, so runs start at once instead of waiting on the 5 s poll. The helper already accepts tickMs on main, so the diff is two lines and a recorded time. Both tests keep their assertions, no production code or dependency changes, and the preview has no user-facing surface to judge. Next: (1) give the other crew-*.test.ts files that sit near 12 s the same tickMs, and check them against test-times.json. (2) Put the 50 ms default inside startStandInCrew so no file has to remember it.
test/crew-declines.test.tsnow finishes in about 1.1 s, down from 10.6 s here, and both of its tests pass. I ran it ten times in a row and it passed every time, at 1.10–1.16 s. I did not run the type check:bun x tsc --noEmitfails in this sandbox with a read-only temp-dir error. The change is one optional argument and one call site, and the forge's check will type-check it.Cause. Nearly all the time was the crew's dispatch loop. It polls every 5 s by default, so each run sat about 5 s before starting. The two runs in the file therefore cost about 10 s together.
Change.
test/helpers/crew-standin.ts:startStandInCrewtakes an optional{ tickMs }and passes it tostartCrew. Without it nothing changes, so the other crew tests are unaffected.test/crew-declines.test.ts: starts the crew withtickMs: 50.scripts/test-times.json: the file's recorded time is now 1.1.No production code changed. No test was deleted, and both tests assert exactly what they did before: the decline leaves no pull, branch or comment, and a pull whose branch lives in the repository is not the crew's to move. The forge fixture was already built once per file, and the file still uses the real stand-in script and the real clock. A fake harness and fake clock would prove less, and the file is already about 1 s.
Try it.
bun test test/crew-declines.test.ts.🤖 Generated with Claude Code
Closes #3595