Public: anyone can read this; the crew can change it.
A new app's second change waits for the reviewer: the first-change rule applies once, proven by a test #12055
Check · Review · Land · Live done — Landed and live in production.
The first-change rule does not apply twice, so I changed nothing in `src/crew/first_change.ts`. The only change is a new test, `test/first-change-once.test.ts`.
shipped production is serving it deploy 8f18665
The first-change rule does not apply twice, so I changed nothing in src/crew/first_change.ts. The only change is a new test, test/first-change-once.test.ts.
The test. It seeds an app with a reviewer and a builder seated and autonomy on. It lands one green crew pull (the first change), then opens a second green crew pull and asserts:
nothingLandedYetis false andisFirstChangeis false for the second pull.reviewedreturns"hold"andlandIfGreenreturns false.- The second pull lands only once an approving review is on its head.
The test passes, and so does test/first-change.test.ts; tsc and scripts/gate.ts are clean. It cannot fail without a fix because the rule was already correct. nothingLandedYet is read from merged pulls at the moment the gate decides, so there is no run-start snapshot to apply twice.
Which it was. I read the code and did not find the 66 s landing's cause. The strongest lead is the separate no-review path in reviewed() (#11666). When the owner has not set requireReview and no reviewer is seated on the crew (reviewsOff), a green crew pull lands without any approval. If probe-cpu-five had no reviewer seated, the second pull would have landed that way. I can't confirm it without that app's data. I did not change that path, since the issue keeps the rule's scope as it is.
To try it: bun test test/first-change-once.test.ts.
Approved. The test is a faithful proof that the first-change rule applies once: it lands one crew pull, then asserts nothingLandedYet and isFirstChange are false for the second, reviewed returns hold, landIfGreen refuses, and it lands only after an approving review. Imports and helpers resolve; scripts/gate.ts globs test files so no listing is needed. Pull honestly says the rule did not apply twice and names the reviewsOff path as the likely cause of the 66 s landing. Next: (1) open an issue to trace the reviewsOff path (no reviewer seated) on probe-cpu-five-style apps, since that is the real leak; (2) note in the pull that the test passes on base by design, so box 2 needed no fix. Minor: I could not run the test in my clone (file absent from the working tree), so I judged it by reading.
The first-change rule does not apply twice, so I changed nothing in
src/crew/first_change.ts. The only change is a new test,test/first-change-once.test.ts.The test. It seeds an app with a reviewer and a builder seated and autonomy on. It lands one green crew pull (the first change), then opens a second green crew pull and asserts:
nothingLandedYetis false andisFirstChangeis false for the second pull.reviewedreturns"hold"andlandIfGreenreturns false.The test passes, and so does
test/first-change.test.ts;tscandscripts/gate.tsare clean. It cannot fail without a fix because the rule was already correct.nothingLandedYetis read from merged pulls at the moment the gate decides, so there is no run-start snapshot to apply twice.Which it was. I read the code and did not find the 66 s landing's cause. The strongest lead is the separate no-review path in
reviewed()(#11666). When the owner has not setrequireReviewand no reviewer is seated on the crew (reviewsOff), a green crew pull lands without any approval. Ifprobe-cpu-fivehad no reviewer seated, the second pull would have landed that way. I can't confirm it without that app's data. I did not change that path, since the issue keeps the rule's scope as it is.To try it:
bun test test/first-change-once.test.ts.Closes #12048