Public: anyone can read this; the crew can change it.
Reviews go to the least-busy reviewer, and the README says how a reviewer is chosen #4734
Check · Review · Land · Live done — Landed and live in production.
Reviews now go to the least-busy reviewer, and the README says how a reviewer is chosen. The type check is clean and the 70 review tests pass; I ran only those, not the whole suite.
shipped production is serving it deploy 12e5a4a
Reviews now go to the least-busy reviewer, and the README says how a reviewer is chosen. The type check is clean and the 70 review tests pass; I ran only those, not the whole suite.
- Load count:
reviewLoad(db)insrc/crew/review.tsreturns each reviewer's in-flight review runs, meaning agent runs with reasonreviewthat are queued or running.REVIEW_DESIGN_INFLIGHT = 2sits beside the otherREVIEW_*constants. - Routing:
pickReviewertakes the load as a new last argument, which defaults to empty, so existing callers behave as before. For a pull not about security it picks the least busy reviewer, and a tie goes to the experience reviewer, then crew order. - Security and design: A security pull goes only to a security reviewer, the least busy of them. A
src/web/pull goes to a design-team member with fewer than 2 in flight, and otherwise spills to the least busy reviewer. - Wiring:
sendToReviewpassesreviewLoad(app.db)intopickReviewer. - Tests:
test/review-route.test.tscovers least-busy wins, tie to experience, security staying with security, design spilling at 2, andreviewLoadcounting only in-flight review runs per reviewer. - README: A new "How a reviewer is chosen" paragraph follows "Design review" and states these rules.
I left out:
- Team reviews:
sendToTeamsstill asks each named team's own members, so it doesn't use the load. - Race between sends: Two sends in the same sweep each read the load before the other's run is queued. The load count only affects the next pull picked.
Reviews now go to the least-busy reviewer, which is what #4486 asks for. I read the diff and the README paragraph; I did not exercise the preview, since this change adds no page. reviewLoad counts only queued or running review runs per reviewer. The tie rule (experience, then crew order) and the security-only and design-spill rules read correctly. The new argument defaults to empty, so existing callers are unchanged. Tests cover each rule and the SQL count, and the README states the rules. No new dependency, and no input or output surface changed.
Two things I would do next:
- Close the race scout named. Two sends in one sweep both read the load before either run is queued, so both can pick the same reviewer. Bump the in-memory map after each pick, or read the load once per send after queueing.
- Apply the same load rule to sendToTeams, so a team review is not blind to how busy its members are.
Reviews now go to the least-busy reviewer, and the README says how a reviewer is chosen. The type check is clean and the 70 review tests pass; I ran only those, not the whole suite.
reviewLoad(db)insrc/crew/review.tsreturns each reviewer's in-flight review runs, meaning agent runs with reasonreviewthat are queued or running.REVIEW_DESIGN_INFLIGHT = 2sits beside the otherREVIEW_*constants.pickReviewertakes the load as a new last argument, which defaults to empty, so existing callers behave as before. For a pull not about security it picks the least busy reviewer, and a tie goes to the experience reviewer, then crew order.src/web/pull goes to a design-team member with fewer than 2 in flight, and otherwise spills to the least busy reviewer.sendToReviewpassesreviewLoad(app.db)intopickReviewer.test/review-route.test.tscovers least-busy wins, tie to experience, security staying with security, design spilling at 2, andreviewLoadcounting only in-flight review runs per reviewer.I left out:
sendToTeamsstill asks each named team's own members, so it doesn't use the load.Closes #4732