The proposal tests in crew-proposal and upstream-forge wait for the proposal, not a fixed 1.5 s #9090

I replaced both fixed 1500 ms sleeps with waits for what the next line reads. Each wait has a deadline and fails by saying what never arrived. Only the two test files changed; nothing in src.

test/upstream-forge.test.ts — after p, the test now waits for both a toast and the forge.proposal event. Past 10 s it throws, saying which of the two is missing (no toast, or no event) and listing the toasts it did get.

test/crew-proposal.test.ts

• Writer's v: waits until the conflict screen shows "conflict block in". If that never appears it throws and prints the screen.
• Reader's v: the key does nothing for a reader, so the test now checks that the conflict blocks did not open, instead of sleeping.
• Crew tick: removing the sleep alone saved no time. The crew starts queued runs on a 5 s tick (src/crew/dispatch.ts:134), and the tests that wait on a run just waited longer for the next tick. Test "a failed proposal on a pull that still conflicts" went from 1.69 s to 0.17 s, and the last test grew from 2.9 s to 4.4 s by the same amount. So the test now passes tickMs: 50 to startCrew, which the option's own doc comment invites ("tests pass a small one") and five other crew suites already do. The waits are unchanged.

Timings (bun test, before → after):

Not done: the waits exposed no race in src, so I filed no issue. The plan wasn't kept on the issue because no keep_plan tool was available in this run.

Checks: bun scripts/gate.ts passes, bun x tsc --noEmit is clean, and bun test test/flake.test.ts passes 36/36 with no new fall-through wait. The two changed files passed 27/27 three runs in a row. To try it: bun test test/upstream-forge.test.ts test/crew-proposal.test.ts.

🤖 Generated with Claude Code

Closes #9083

I replaced both fixed 1500 ms sleeps with waits for what the next line reads. Each wait has a deadline and fails by saying what never arrived. Only the two test files changed; nothing in src.

test/upstream-forge.test.ts — after p, the test now waits for both a toast and the forge.proposal event. Past 10 s it throws, saying which of the two is missing (no toast, or no event) and listing the toasts it did get.

test/crew-proposal.test.ts

• Writer's v: waits until the conflict screen shows "conflict block in". If that never appears it throws and prints the screen.
• Reader's v: the key does nothing for a reader, so the test now checks that the conflict blocks did not open, instead of sleeping.
• Crew tick: removing the sleep alone saved no time. The crew starts queued runs on a 5 s tick (src/crew/dispatch.ts:134), and the tests that wait on a run just waited longer for the next tick. Test "a failed proposal on a pull that still conflicts" went from 1.69 s to 0.17 s, and the last test grew from 2.9 s to 4.4 s by the same amount. So the test now passes tickMs: 50 to startCrew, which the option's own doc comment invites ("tests pass a small one") and five other crew suites already do. The waits are unchanged.

Timings (bun test, before → after):

Not done: the waits exposed no race in src, so I filed no issue. The plan wasn't kept on the issue because no keep_plan tool was available in this run.

Checks: bun scripts/gate.ts passes, bun x tsc --noEmit is clean, and bun test test/flake.test.ts passes 36/36 with no new fall-through wait. The two changed files passed 27/27 three runs in a row. To try it: bun test test/upstream-forge.test.ts test/crew-proposal.test.ts.

🤖 Generated with Claude Code

Both fixed 1500 ms sleeps are gone. Each test now waits for what its next line reads, and fails by saying what never came. Only the two test files change; nothing in src.

• test/upstream-forge.test.ts: after p, the test waits until there is a toast and the forge.proposal event has arrived. After 10 s it throws, naming whichever is missing and listing the toasts it did get.
• test/crew-proposal.test.ts, writer: after a writer presses v, the test waits for "conflict block in" on the screen. If it never appears, it throws with the screen.
• test/crew-proposal.test.ts, reader: after a reader presses v, there is no check. A reader's v is ignored and draws nothing, so there is no sign to wait for. Per review, I dropped the one-shot "blocks are absent" check, because it proved nothing about a later draw. What a reader may not do is still checked on the c press that follows (no "have the crew propose", no run queued).
• Crew tick: removing the sleep alone saved nothing in crew-proposal. The crew starts queued runs on a 5 s tick (src/crew/dispatch.ts:134), and the test's runs just waited longer for the next tick. The test now passes tickMs: 50 to startCrew, which the option's own doc comment invites and other crew suites already do.
• Busy test: the 50 ms tick exposed a test bug. The busy test sets a fake run to running without a heartbeat. On the next tick requeueInterrupted cancelled it and queued a real run, which then broke the last test (2 of 6 runs failed). The fake run now gets a heartbeat, as a live run would. The race was there before; the 5 s tick only made it rare. It is a test fault, not a bug in src.

Timings (bun test, before → after):

• test/upstream-forge.test.ts: 4.92 s → 3.45 s
• test/crew-proposal.test.ts: 21.43 s → 3.98–4.59 s (10 runs, all passing)

bun test test/flake.test.ts passes with no new fall-through wait, and bun scripts/gate.ts and bun x tsc --noEmit are clean.

To try it: bun test test/upstream-forge.test.ts test/crew-proposal.test.ts.

🤖 Generated with Claude Code