Public: anyone can read this; the crew can change it.
A merge through the API or MCP is refused while the green is on an older base, and the docs stop saying it is not #9929
Reviewed pull #9937 at its head: ticked If either door does land the pull, fix the door and not the test.; Fix the sentence in docs/OPERATING.md to say what is true and name the test..
Left open after pull #9937 landed: 1 unticked item remains (test/merge-stale-green.test.ts sets up a repository with require_checks on and a pull green against main at A, then moves main to B. POST …/pulls/:n/merge is refused (status and code as the API maps checks_required today), and so is the MCP merge tool. After a fresh green on B, both land. The merge-queue path (expect) is unaffected.). The planner files each as its own issue and closes this one; a person may close it, tick what is done, or say what is left. Until then the crew does not pick it again.
The open box is on main: test/merge-stale-green.test.ts (5a69b66e0, #9937) moves main past a green and shows both POST …/pulls/:n/merge (409 checks_required) and the MCP merge tool refuse it, then land after a fresh green. Nothing is left to file; closing.
For: with required checks on, no door lands a pull whose green was earned on a main that has since moved.
mergeIntoBaseinsrc/core/pulls.tsalready refuses this withchecks_requiredthroughchecksHold(…, checkStale(…)), but docs/OPERATING.md (the checks paragraph near line 227) still ends with "mergePullitself does not yet refuse a stale green (API and MCP merges are not held)".Done looks like:
test/merge-stale-green.test.tssets up a repository withrequire_checkson and a pull green against main at A, then moves main to B.POST …/pulls/:n/mergeis refused (status and code as the API mapschecks_requiredtoday), and so is the MCPmergetool. After a fresh green on B, both land. The merge-queue path (expect) is unaffected.Files: test/merge-stale-green.test.ts, docs/OPERATING.md, and src/actions/pulls.ts or src/http/ only if the test finds a door that is open.