When checks are scarce, they go to the work that matters most: the check queu… #12231

Queued checks now start in the owner's ranked order, and the home lanes list them in that order. tsc and bun scripts/gate.ts were clean, and the tests that cover the change pass. I ran no other tests locally: scripts/fast.ts said the diff touches 2240 of 3057 files, so I ran the relevant suites by hand. I didn't run bun scripts/design-lint.ts, which this change doesn't call for.

What changed

• Check order: pickNext (src/checks/service.ts) takes a new rank argument, read from issue_rank by src/checks/ranked_first.ts.

- The order is: a merge-queue gate, then an approved pull's check, then by the rank of the pull's issue, top first. Unranked checks go last, newest first. - A check past STARVATION_MS still beats all of these, so nothing waits forever. - Among approved checks, rank breaks ties before recency does. The issue didn't say which should win there, so that is my call.

• Builder slots: the new-build pick already followed pickOrder. Rework did not, so moveRequested and sweepStaleReds now walk pulls in rank order through a new inRankOrder in src/core/rank.ts. When slots are scarce, the higher-ranked pull's rework or re-check gets one first.
• Home lanes: src/flow/lanes_read.ts now sorts waiting checks and builds in the order they will be taken, and numbers them in that order. The first tile reads "next in line". Moving an issue to the top moves its check to that spot.
• Tests: test/checks-ranked.test.ts queues five checks ranked 3,1,5,2,unranked and sees them start 1,2,3,5,unranked. It also covers approved-first, starvation, the lane order and the rework order.

Left out

• The lane doesn't mark approved checks, so a waiting approved check isn't pulled to the front of the tiles the way the real queue does. Showing that would need a review lookup per lane read.
• Ranks are per repository, so two repos' top-ranked checks tie on place and fall back to newest first.

Try it: rank two pulls with next_up, queue checks for both, and the lane shows the higher-ranked one first.

🤖 Generated with Claude Code

Fixed the gate failure and pushed it as 15895ac73.

The gate rejected test/checks-ranked.test.ts because a comment line was 124 columns long. I shortened that comment. I also wrapped the long createRun line above it, which was code rather than a comment.

bun scripts/gate.ts passes now. bun x tsc --noEmit printed nothing, so it found no type errors. The four tests in test/checks-ranked.test.ts pass. The gate only passed after I committed. Run on the uncommitted file, it still reported the old line 42.

I didn't run the full suite here. The forge runs it on this push.

The home checks lane now orders waiting checks the way pickNext does, so "next in line" names the check that starts next. This answers all four review points, pushed as 77e27f369.

• Lane order: takenOrder in src/flow/lanes_read.ts now sorts a starved check first, then an approved pull's check, then everything else. Within each group it uses rank, then newest first. A starved check is the oldest queued check that has waited at least half of BUDGETS.laneWait, the same bound as STARVATION_MS. I don't import STARVATION_MS itself, because service.ts is heavy for the lane worker thread. Approval is read with reviewSummariesFor, one batch per lane read, not one query per row.
• Rank before the limit: the SQL now orders by the starved check, then rank (k.pos IS NULL, k.pos), then age, before LIMIT. A ranked check can no longer be cut off by newer unranked ones. I also made the checks lane order newest first before the limit, since that is what pickNext takes among the unranked.
• Ties across repos: I kept the tie-break as newest first and said so in a test and in the doc, rather than adding a repo ordering. I judged that interleaving repos by some other rule would be arbitrary too.
• Doc: docs/features/ranked-checks.md explains how ranking now drives check and rework order. I left the README alone.

I added three tests to test/checks-ranked.test.ts:

• Lane tiers: an approved check goes ahead of the ranked ones, and a starved one goes ahead of that.
• Scan bound: with 60 extra queued checks, the ranked ones still lead the lane.
• Ties across repos: equal ranks in two repos pick the newest check.

The gate passes, tsc is clean, test/checks-ranked.test.ts passes (7 tests), and the other lane tests I ran pass. scripts/fast.ts said the diff was too broad to name tests for, so I ran only the files that import lanes_read or readFast, plus the two home-query tests. I didn't run the whole suite, since the forge's check does that on the push. I haven't looked at the preview.

An approved check can still fall outside the 40-row window if it is unranked and there are more than 40 newer ones. The review only asked for the rank ordering in SQL, and approval is read after the fetch.

When checks are scarce, the work the owner ranked highest gets them first (#12230). Queued checks, rework and re-checks now follow the owner's ranked list: highest first, unranked last, and newest first only as a tie-break. A check that has waited too long ("starved") still goes first, and an approved pull's check still goes before the rest. The home checks lane lists waiting checks in the order they will start, and the first one says "next in line".

This round, from review:

• Approved checks are no longer cut off the lane (src/flow/lanes_read.ts). The lane shows at most 40 checks. Before, an approved check could fall outside those 40 even though it starts first. Now approval is worked out for every queued check (that set is small), using the same review rule approvedForCheck uses. The order is decided before the 40-check cutoff: starved, then approved, then rank, then age.
• One starvation limit. STARVATION_MS now lives in src/kernel/budgets.ts. checks/service.ts re-exports it and the lane imports it, so the two can't drift apart.
• The lane's starved check is approximate, and a comment now says so. pickNext skips a check whose repository is at its concurrency limit; the lane doesn't read that live state, so it doesn't apply the skip.
• Tests (test/checks-ranked.test.ts):

- Fixed the setup comment and removed the stale comment and the pulls.length assertion. - Faking an old or approved check now goes through two shared helpers, age and approve, in every test. - Two new cases: a ranked check that is the oldest of 60 newer unranked ones, and an approved unranked check behind 45 newer ones. Each still appears first in the lane, and each fails when its part of the ORDER BY is removed. - A new test pins the starvation limit: just under it, rank decides in both the lane and pickNext; just over it, the starved check leads the lane.

Not done: there are no README or terminal screen changes, because this PR only changes ordering.

Checks run:

• bun scripts/gate.ts and bun x tsc --noEmit pass.
• scripts/fast.ts couldn't name the tests (exit 2) because kernel/budgets.ts changed. So the 71 test files that touch the checks service, the lanes, or the budgets were run: 653 pass, 0 fail, 33 skipped. The skipped ones are the unix-socket and cell suites this sandbox can't run; the forge's check runs them on every push.

To try it: on the preview, queue checks on pulls in one repository, reorder its ranked list, and watch the home checks lane reorder to match.

🤖 Generated with Claude Code