An issue whose pull landed with boxes unticked goes to a person, not back to a builder #8497

When a pull that closes an issue lands with boxes still unticked, the issue now goes to a person instead of back to a builder. Closes #8482.

What changed

• The note is on the issue too. mergePull in src/actions/pulls.ts still leaves the pull's Left #N open: … note. It now also writes Left open after pull #P landed: K unticked items remain (…) on the issue itself, with an issue.commented event. The note names the pull and the unticked items and says what to do: close it, tick what is done, or say what is left. The text comes from landedNote in src/core/done_on_main.ts.
• The picker skips it. A new hold, landed, sits in src/crew/held.ts after done_on_main. That file is the filter driveRepo in autonomy.ts picks from, so the change lives there rather than in autonomy.ts itself. Because it is a named hold, the tick line (landed=1), /boards, /flow and the terminal's Flow screen all say why the issue is held.
• The rule is in src/crew/landed.ts. landedUnanswered holds an open issue when it still has unticked boxes and mergedPullClosing finds a merged pull that closes it. The hold lifts once a person who may direct the crew comments on the issue, edits it (ticking a box is an edit) or reopens it after the merge. Comments from agents don't count, and neither does the landing's own note, even when a person did the merge.
• No new index. The event read uses the existing event_repo_kind_number_at index. It only runs for issues with an unticked box.
• Unchanged: a merge still does not close umbrellas or the Later gate.
• Docs: docs/features/done-on-main.md and docs/CREW.md describe the new hold.

Left out on purpose: issues already stuck this way before this pull carry no note on the issue. They are still held, because the hold reads the merged pull, not the note. A reader's comment does not lift the hold, the same as the existing stall rule (#619).

Tests: test/landed-held.test.ts covers the cases below. I checked that three of its five tests fail with the hold removed.

• A landing leaves the partial issue open and puts the exact note on it.
• The issue is held as landed, is not startable, and driveRepo does not assign it.
• An agent's comment keeps it held; a person's comment or tick makes it startable again.
• A fully ticked issue still closes on landing and gets no note.

Checks run: bun scripts/gate.ts and bun x tsc --noEmit are clean. scripts/fast.ts named 1,428 test files for this diff, too many to run, so I ran the 87 files that use mergePull, the holds, done_on_main or driveRepo: 844 pass, 0 fail.

To try it: open an issue with - [x] a and - [ ] b, then land a pull that says Closes #N. The issue stays open with the note, and the held list on /boards shows it as landed. Comment on it as the owner and it becomes pickable again.

🤖 Generated with Claude Code

Closes #8482

When a pull that closes an issue lands with boxes still unticked, the issue now goes to a person instead of back to a builder. Closes #8482.

What changed

• The note is on the issue too. mergePull in src/actions/pulls.ts still leaves the pull's Left #N open: … note. It now also writes Left open after pull #P landed: K unticked items remain (…) on the issue itself, with an issue.commented event. The note names the pull and the unticked items and says what to do: close it, tick what is done, or say what is left. The text comes from landedNote in src/core/done_on_main.ts.
• The picker skips it. A new hold, landed, sits in src/crew/held.ts after done_on_main. That file is the filter driveRepo in autonomy.ts picks from, so the change lives there rather than in autonomy.ts itself. Because it is a named hold, the tick line (landed=1), /boards, /flow and the terminal's Flow screen all say why the issue is held.
• The rule is in src/crew/landed.ts. landedUnanswered holds an open issue when it still has unticked boxes and mergedPullClosing finds a merged pull that closes it. The hold lifts once a person who may direct the crew comments on the issue, edits it (ticking a box is an edit) or reopens it after the merge. Comments from agents don't count, and neither does the landing's own note, even when a person did the merge.
• No new index. The event read uses the existing event_repo_kind_number_at index. It only runs for issues with an unticked box.
• Unchanged: a merge still does not close umbrellas or the Later gate.
• Docs: docs/features/done-on-main.md and docs/CREW.md describe the new hold.

Left out on purpose: issues already stuck this way before this pull carry no note on the issue. They are still held, because the hold reads the merged pull, not the note. A reader's comment does not lift the hold, the same as the existing stall rule (#619).

Tests: test/landed-held.test.ts covers the cases below. I checked that three of its five tests fail with the hold removed.

• A landing leaves the partial issue open and puts the exact note on it.
• The issue is held as landed, is not startable, and driveRepo does not assign it.
• An agent's comment keeps it held; a person's comment or tick makes it startable again.
• A fully ticked issue still closes on landing and gets no note.

Checks run: bun scripts/gate.ts and bun x tsc --noEmit are clean. scripts/fast.ts named 1,428 test files for this diff, too many to run, so I ran the 87 files that use mergePull, the holds, done_on_main or driveRepo: 844 pass, 0 fail.

To try it: open an issue with - [x] a and - [ ] b, then land a pull that says Closes #N. The issue stays open with the note, and the held list on /boards shows it as landed. Comment on it as the owner and it becomes pickable again.

🤖 Generated with Claude Code