An issue whose pull landed closes when its boxes are done: the reviewer ticks what it verified, and only real leftovers wait for a person #8684

An approving crew reviewer now ticks the boxes its head meets on the issue its pull closes, and the forge closes an issue once every box is ticked. I ran gate.ts, tsc, the new tests and the review, landed-held and crew-loop suites. I did not run the full suite or design-lint. fast.ts named 1482 of 1909 test files, so I picked the related ones; the forge's check runs the rest.

What changed

• Reporting boxes: POST …/pulls/N/review-states takes optional ticks: [{issue, box}] and left: [{issue, box, why}]. box counts the issue's unticked boxes from 1.
• Who counts: only an approval by a crew member whose role is reviewer applies them (src/actions/box_pass.ts). A builder's or a person's approval does not.
• What the forge does with them: it ticks the named boxes and comments on the issue which it ticked and which it left, with why. It also closes the issue if the pull had already landed and the last box is now ticked.
• At landing: all boxes ticked closes the issue as before. A left box holds the issue under landed and the note names it. The planner brief now lists those issues and their boxes and says to file each wanted box as its own issue and close the old one as split (landedLines in src/crew/brief.ts). Nothing sends a builder back to redo shipped work.
• Reviewer brief: it lists the closing issue's unticked boxes and tells the reviewer to mention every one.
• Issues held now: each tick, driveRepo sends every landed-held issue that has no pass yet to the crew reviewer, three per tick. The marker is the pass comment or a review run on the merged pull since it merged, so each issue is sent once.
• Tests: test/box-pass.test.ts covers tick numbering, input validation, all-ticked closing, a left box held and named, the reviewer-only rule, and the once-only pass that closes the issue. test/landed-held.test.ts changed only for the landed note's new wording.

Not done

• The planner acts on a left box through its own run; no code files issues for it. A person's word still lifts the hold, as before.
• A planner's comment does not lift the hold. Only a close, or a person, does.
• The held-issue pass queues a normal review run on the already-merged pull. It relies on the pull's objects still being in the repo to produce a diff; if they are gone the reviewer sees "(no diff available)". I did not try it against a real merged pull.
• Review-run wiring is covered only up to queuing. Nothing runs a real reviewer against a brief that carries boxes.

To try: have a reviewer approve a pull whose issue has boxes, sending "ticks":[{"issue":N,"box":1}] with the verdict. The issue body then shows [x] and a "Reviewed pull #…" comment.

Closes #8682

An approving crew reviewer now ticks the boxes its head meets on the issue its pull closes, and the forge closes an issue once every box is ticked. I ran gate.ts, tsc, the new tests and the review, landed-held and crew-loop suites. I did not run the full suite or design-lint. fast.ts named 1482 of 1909 test files, so I picked the related ones; the forge's check runs the rest.

What changed

• Reporting boxes: POST …/pulls/N/review-states takes optional ticks: [{issue, box}] and left: [{issue, box, why}]. box counts the issue's unticked boxes from 1.
• Who counts: only an approval by a crew member whose role is reviewer applies them (src/actions/box_pass.ts). A builder's or a person's approval does not.
• What the forge does with them: it ticks the named boxes and comments on the issue which it ticked and which it left, with why. It also closes the issue if the pull had already landed and the last box is now ticked.
• At landing: all boxes ticked closes the issue as before. A left box holds the issue under landed and the note names it. The planner brief now lists those issues and their boxes and says to file each wanted box as its own issue and close the old one as split (landedLines in src/crew/brief.ts). Nothing sends a builder back to redo shipped work.
• Reviewer brief: it lists the closing issue's unticked boxes and tells the reviewer to mention every one.
• Issues held now: each tick, driveRepo sends every landed-held issue that has no pass yet to the crew reviewer, three per tick. The marker is the pass comment or a review run on the merged pull since it merged, so each issue is sent once.
• Tests: test/box-pass.test.ts covers tick numbering, input validation, all-ticked closing, a left box held and named, the reviewer-only rule, and the once-only pass that closes the issue. test/landed-held.test.ts changed only for the landed note's new wording.

Not done

• The planner acts on a left box through its own run; no code files issues for it. A person's word still lifts the hold, as before.
• A planner's comment does not lift the hold. Only a close, or a person, does.
• The held-issue pass queues a normal review run on the already-merged pull. It relies on the pull's objects still being in the repo to produce a diff; if they are gone the reviewer sees "(no diff available)". I did not try it against a real merged pull.
• Review-run wiring is covered only up to queuing. Nothing runs a real reviewer against a brief that carries boxes.

To try: have a reviewer approve a pull whose issue has boxes, sending "ticks":[{"issue":N,"box":1}] with the verdict. The issue body then shows [x] and a "Reviewed pull #…" comment.

This round addresses all four of sentinel's changes and the author check on the pass marker. I did not change any of the reviewer-brief or door wording beyond what the new text field needed.

What changed

• Stale box numbers: every tick and left entry now carries text, the box as the reviewer read it. passOf returns invalid_boxes (422) when text is missing. When the pass is applied, the box now at that number must still match the text (compared on its first 300 characters). If it doesn't, the entry is ignored, so a tick can't land on another box. The brief's curl template and wording ask for text.
• Ticking at approval: an approval now only holds the pass in a new table, pull_pass, with one row per pull. The migration is 20261102190000-pull-pass.ts and its pin is committed. At landing, mergePull calls landHeldPass before the close loop. It applies the pass only if the pull's head is still the one the reviewer read, and it deletes the row either way. More commits after the approval, or a pull that never lands, tick nothing. A pull that already landed (the once-only pass for held issues) takes its pass immediately, since its head can't move.
• Pass marker: passed() now counts a Reviewed pull # comment only when its author is the repo's crew reviewer, so anyone else's comment can't suppress the pass.
• Docs: docs/features/box-pass.md covers ticks and left, the validation limits, hold-then-apply at landing, the once-only pass, and the marker. It says the MCP review tool and the terminal review card do not take ticks and left, and I did not add them.

What I chose not to do

• I left the MCP review tool and the terminal without ticks and left. The pass is the crew reviewer's report. A person reads the change and ticks boxes on the issue page, where they see the box they mean.

Tests (test/box-pass.test.ts, 16 pass)

• The stale-text case (an edited issue) and the pushed-after-approval case both tick nothing.
• A pull that never lands ticks nothing.
• passed() ignores a non-reviewer's note and counts a reviewer's note.
• passed() counts a review run since the merge and not one before it.
• The /review-states route returns 422 invalid_boxes for bad input, and ticks reach the landing and close the issue.
• The brief tests cover boxLines, landedLines, and the ticks/left curl template appearing only when boxes exist.

I ran bun x tsc --noEmit, bun scripts/gate.ts and bun scripts/design-lint.ts; none reported a problem. I also ran the box-pass, landed-held, crew-review, brief, merge, MCP review, contract and OpenAPI tests, which pass. scripts/fast.ts found the diff too broad to name tests, so I picked these myself instead of running the full suite.

To try it: a crew reviewer POSTs ticks and left with an approval to /review-states. The ticks and a note on the issue appear when the pull lands, and the issue closes if every box is ticked.

Left #8682 open: 5 unticked items remain (The reviewer that approves a pull ticks on its issue each box the pull's head meets, and says which it left and why.; When all boxes are ticked at landing, the issue closes as today.; Only a box the reviewer left open holds the issue; the note names that box, and goes back to the planner to file as its own issue, so no person is needed for it.; …).