Fix: automations-gate's scheduler test fails locally on macOS — its 50 ms warm-up budget no longer covers the git spawn

[patzick]

What happens

packages/cezar/src/server/automations-gate.test.ts → "starts once the flag is on, so the gate is the only thing holding it back" fails deterministically on macOS, on main, with:

AssertionError: expected "start" to be called 1 times, but got 0 times
 ❯ boot src/server/automations-gate.test.ts:213:23
 ❯ src/server/automations-gate.test.ts:222:7

CI (Linux) is green, so nothing is broken in production code — but anyone running npm test locally on a Mac gets a red suite and has to decide whether it matters.

Why

The test's boot() helper waits a fixed macrotask turn for the listening warm-up chain:

// The warm-up chain is `listProjects().then(…)`; a macrotask turn is enough for it to run
// to the point where it either starts the scheduler or returns early.
await new Promise((resolve) => setTimeout(resolve, 50));

That comment was true when it was written, but the chain the assertion depends on is no longer just listProjects(). server.ts:5575-5583 now awaits one getRepoInfo(project.root) per project before automationScheduler.start(), and getRepoInfo spawns git. On Linux CI that round-trip fits inside 50 ms; on macOS process spawn is slower and it does not, so start simply has not been called yet when the assertion runs.

The failure is one-sided, which is why it went unnoticed: the sibling case "never starts polling while the flag is off" asserts start was called 0 times and therefore passes whether the chain finished or not.

Evidence

Reproduced on 185c68a7 (current main), macOS 24.6.0, three consecutive runs of the file alone — 1 failed | 20 passed (21) every time. Not a TMPDIR artifact: reproduced with TMPDIR on a real, non-symlinked, non-repo path. Raising that one 50 to 1500 in the same worktree turns the file green (21 passed) with no other change, which pins the cause to the timing budget rather than to behaviour.

Suggested fix

Wait for the event instead of guessing at its duration — e.g. resolve on a spy/promise the warm-up settles, or poll started under a vi.waitFor with a generous timeout, so the test is fast when the chain is fast and correct when it is not. Please don't just raise the constant; that trades a Mac-only failure for a slower suite everywhere and leaves the same assumption in place.

Provenance

Found by an om-auto-fix-pr run on #774 while validating that branch locally. It is not caused by #774 — verified failing identically on origin/main, and #774 does not touch this file. Filed so the branch is not blamed for it and so the next local run has the answer.