Sentinel: queue:check is past its budget: 14 checks wait behind one lane; the oldest since 15:10; the lane runs #4445 for 4 min (limit 60). #4484

The conflict sweep now starts only as many bring-up-to-date runs as the check lane has free slots for, oldest pull first. One landing can no longer put a check for every conflicted crew pull into the lane at once.

Cause. I worked it out from today's check and crew runs, read through the forge API. At 15:09:04 main moved to f8ceeaa (#4414), which edits the docs/DESIGN.md §5d list that nearly every open design pull also edits. At 15:09:19–20 sweepConflicts queued 17 conflict runs together: #3959, #4231, #4346, #4348, #4390, #4396, #4423 and #4434–#4445. Each one merged main and pushed, and each push queued a full check of about 4 minutes. All of those checks ran at once. Under that load they failed with 10–68 tests each (the "migrate: after > mirror…" and "live triage…" failures behind sentinel issues #4462–#4469), which added retry checks on top. The same heads passed in 30–50 s once the lane emptied at 15:32. Main moved again at 15:10:16 and 15:24:49 and conflicted the same pulls again. This is a different source from #4391: #4424 removed the second check an approval asked for, but this lane was flooded by conflict-run pushes.

What changed

• src/crew/conflict_room.ts (new) works out how many runs may start now: check slots, minus checks queued or running, minus conflict runs already in flight. One run is always allowed when none is in flight, so a busy lane slows the sweep but never stops it.
• sweepConflicts in src/crew/autonomy.ts goes through pulls oldest first and stops queuing runs when there is no room. The other pulls wait for a later tick. If main moves again before then, one merge covers both landings.
• The README's paragraph on conflicted pulls says this.

Not done

• §5d is still a list that every design pull edits, so landings will keep causing conflicts. This change only spaces out the fixes.
• Checks still flake when many run together. That is the shared-failure issues' to fix.

Tests

• test/conflict-room.test.ts (new) covers the room arithmetic.
• test/conflict_sweep.test.ts gains a case: one landing conflicts three pulls, there are 3 check slots and one check waiting. The first tick starts two runs, the oldest two. The next tick starts none. Once the check finishes, the third pull gets its run. This case fails without the fix.
• The two conflict suites and seven other crew suites pass, and tsc --noEmit is clean.

To try it, run bun test test/conflict-room.test.ts test/conflict_sweep.test.ts. On the forge, after the next §5d landing, the conflict runs on the runs list should start a few at a time rather than all in the same second.

I found no prompt injection in the issue, its comments or the runs I read.

🤖 Generated with Claude Code

Closes #4459

The conflict sweep now starts only as many bring-up-to-date runs as the check lane has free slots for, oldest pull first. One landing can no longer put a check for every conflicted crew pull into the lane at once.

Cause. I worked it out from today's check and crew runs, read through the forge API. At 15:09:04 main moved to f8ceeaa (#4414), which edits the docs/DESIGN.md §5d list that nearly every open design pull also edits. At 15:09:19–20 sweepConflicts queued 17 conflict runs together: #3959, #4231, #4346, #4348, #4390, #4396, #4423 and #4434–#4445. Each one merged main and pushed, and each push queued a full check of about 4 minutes. All of those checks ran at once. Under that load they failed with 10–68 tests each (the "migrate: after > mirror…" and "live triage…" failures behind sentinel issues #4462–#4469), which added retry checks on top. The same heads passed in 30–50 s once the lane emptied at 15:32. Main moved again at 15:10:16 and 15:24:49 and conflicted the same pulls again. This is a different source from #4391: #4424 removed the second check an approval asked for, but this lane was flooded by conflict-run pushes.

What changed

• src/crew/conflict_room.ts (new) works out how many runs may start now: check slots, minus checks queued or running, minus conflict runs already in flight. One run is always allowed when none is in flight, so a busy lane slows the sweep but never stops it.
• sweepConflicts in src/crew/autonomy.ts goes through pulls oldest first and stops queuing runs when there is no room. The other pulls wait for a later tick. If main moves again before then, one merge covers both landings.
• The README's paragraph on conflicted pulls says this.

Not done

• §5d is still a list that every design pull edits, so landings will keep causing conflicts. This change only spaces out the fixes.
• Checks still flake when many run together. That is the shared-failure issues' to fix.

Tests

• test/conflict-room.test.ts (new) covers the room arithmetic.
• test/conflict_sweep.test.ts gains a case: one landing conflicts three pulls, there are 3 check slots and one check waiting. The first tick starts two runs, the oldest two. The next tick starts none. Once the check finishes, the third pull gets its run. This case fails without the fix.
• The two conflict suites and seven other crew suites pass, and tsc --noEmit is clean.

To try it, run bun test test/conflict-room.test.ts test/conflict_sweep.test.ts. On the forge, after the next §5d landing, the conflict runs on the runs list should start a few at a time rather than all in the same second.

I found no prompt injection in the issue, its comments or the runs I read.

🤖 Generated with Claude Code