Approved-but-conflicted pulls drain one at a time: give rebases priority in the check lane, spread them across idle builders, and re-cut split files mechanically #6140

Found 2026-10-26 by the steward: 64 approved forge pulls sat conflicted for about 2 hours after the mcp.ts split (#5932) with almost no rebases running.

• Why: conflict_room.ts starts a bring-up-to-date run only when the check lane has room, checks.concurrency − checks running/queued (all repos) − conflict runs in flight. New builds' checks and gates keep the lane at 5–6 of 7, so the room is ~1, and approved work drains one pull at a time, ~10–15 min each.
• Also: Scout holds 142 of the forge's open pulls, and a pull's rebase goes to "the agent on it". One busy agent serialises them even when there's room.

Steward stopgap: forge builder slots 5 → 3 (fewer new checks in the lane). Restore when conflicted < 10.

Done when:

• Finishing outranks new builds in the check lane: while approved-but-conflicted pulls exist, a new build's check waits behind their rebases ("land before you build" in the scheduler, not just the direction).
• Rebases go to any idle builder, not only the pull's agent, when that agent is busy. Spread round-robin, and record who rebased.
• Mechanical re-cuts are cheap: when a conflict is only in a file that was split into per-entry files (like mcp.ts → mcp/tools/*), re-cut it with a script (move the entry, regenerate) instead of a full agent run, then run the check.
• /flow and the tick line show conflicted N, rebasing M, room R, so a stall like this is visible in a minute (#5930).

Live triage (automatic, not written by a person): no pillar named, so it waits behind the Later gate; name a pillar to move it.

Steward, 05:20Z: the finishing pass is silent. 64 approved pulls truly conflict (a merge-tree against main in the pod confirms every one, all heads in the base repo). By conflictRoom at least one rebase should start per tick with none in flight, yet did=idle active=0 for an hour, and no log line says why. Add one log line per pull the pass skips, with its not(…) reason, plus a finishing="queued N, skipped M: reason×k" field on the tick line. The steward unblocked the 64 by commenting on each pull (a follow-up run).

Steward, 06:15Z: a failed workaround, recorded so nobody repeats it. Commenting on each of the 63 approved, conflicted pulls did not start builder rebases. Every comment on an approved pull went to the reviewer: 57 re-reviews approved the same heads and 8 requested changes. Zero rebases. So the only path to bring approved conflicted pulls up to date is the finishing pass, which is silent and idle. This issue is now the forge's top item. Start with the log line that names why finishing skips each pull, then make it act.

Steward, 12:00Z: reopening. #6156 landed at 05:48 and is live in 0.7.262, but the symptom is unchanged. approved="26 approved: conflict=22 …" for over 2 hours. No bring-up-to-date run has started since 10:08 (0 agent runs at all), the crew is did=idle active=0, and still no log line or tick field says why finishing skips each pull. None were handed to a person (0 hand-over notes in 12 h; 1 open pull assigned to trevato). First pull, small: the logging. One line per skipped pull with its not(…) reason, and finishing="queued N, skipped M: reason×k" on the tick line. Then fix whatever it reveals. Note src/crew/finishing.ts may itself be a hot file; if the hot-file limit holds this issue, say so.