Lifting an issue from Later makes it startable, and the tick says why any ready issue isn't #8926

Lifting an issue from Later now leaves it under a pillar and startable, and Next up and the tick line give a reason for every ready issue a builder won't start. I ran bun x tsc --noEmit, bun scripts/gate.ts, and the 15 test files that touch Next up, lift, release or the picker; all pass. I did not run the full suite, because scripts/fast.ts found the diff too broad to name (1430 of 1984 files). The forge's check runs it on this push.

Why lifted issues sat unpicked. The edge to the gate counted as a director's link, which is what adopts an issue a reader opened. Removing it left a reader's issue unadopted, so it never became ready. Issues serving no pillar were also left nameless.

What changed

• src/core/pillar_pick.ts (new): servePillar links an issue under the first pillar when it serves none. The lifter is recorded as the actor, so the issue is adopted again.
• Lift: liftHold in src/actions/gate.ts calls servePillar after the unlink, so Lift and wait_for stop leave the issue ready in that one action.
• Pacer's release: releaseFromGate takes an optional actor and does the same. releaseForPace passes the crew's by user.
• Picker reasons: the polish-share and no-backed-bet filters are pulled out of inSlotOrder into pickFilter, which returns each pass-over with a reason. The tick line gains passed=no_bet=N polish_share=N (or none).
• Next up: src/crew/not_startable.ts (new) combines the existing held.ts reasons with the picker's. nextUp takes it as an optional callback, and the web page, terminal screen and MCP next_up tool pass it. A ready row now shows one reason, including the direction issue (the planner's, never a builder's).
• Tests: test/lift-startable.test.ts lifts an issue with no pillar and sees driveRepo pick it. It also covers a reader's issue staying ready after the lift, the pacer release, a Next up reason for a ready issue, and the tick words.

What I chose not to do

• Pillar choice: it is always the first pillar, not the least loaded.
• Pillar labels: the pillar link is written at the database level, so the pillar label catches up at the next boot sync rather than at once.
• Bets: under backed bets, a lifted issue that isn't raised, put first or small is still passed over. It now says no_bet instead of being silent. I did not make a lift count as raising it.
• Builder routing: passes for a missing or shunned builder are not in passed. They are decided inside driveRepo.

To try it, open /<owner>/<app>/next: a ready row held by a run or a pull now shows its reason.

🤖 Generated with Claude Code

Closes #8924

Lifting an issue from Later now leaves it under a pillar and startable, and Next up and the tick line give a reason for every ready issue a builder won't start. I ran bun x tsc --noEmit, bun scripts/gate.ts, and the 15 test files that touch Next up, lift, release or the picker; all pass. I did not run the full suite, because scripts/fast.ts found the diff too broad to name (1430 of 1984 files). The forge's check runs it on this push.

Why lifted issues sat unpicked. The edge to the gate counted as a director's link, which is what adopts an issue a reader opened. Removing it left a reader's issue unadopted, so it never became ready. Issues serving no pillar were also left nameless.

What changed

• src/core/pillar_pick.ts (new): servePillar links an issue under the first pillar when it serves none. The lifter is recorded as the actor, so the issue is adopted again.
• Lift: liftHold in src/actions/gate.ts calls servePillar after the unlink, so Lift and wait_for stop leave the issue ready in that one action.
• Pacer's release: releaseFromGate takes an optional actor and does the same. releaseForPace passes the crew's by user.
• Picker reasons: the polish-share and no-backed-bet filters are pulled out of inSlotOrder into pickFilter, which returns each pass-over with a reason. The tick line gains passed=no_bet=N polish_share=N (or none).
• Next up: src/crew/not_startable.ts (new) combines the existing held.ts reasons with the picker's. nextUp takes it as an optional callback, and the web page, terminal screen and MCP next_up tool pass it. A ready row now shows one reason, including the direction issue (the planner's, never a builder's).
• Tests: test/lift-startable.test.ts lifts an issue with no pillar and sees driveRepo pick it. It also covers a reader's issue staying ready after the lift, the pacer release, a Next up reason for a ready issue, and the tick words.

What I chose not to do

• Pillar choice: it is always the first pillar, not the least loaded.
• Pillar labels: the pillar link is written at the database level, so the pillar label catches up at the next boot sync rather than at once.
• Bets: under backed bets, a lifted issue that isn't raised, put first or small is still passed over. It now says no_bet instead of being silent. I did not make a lift count as raising it.
• Builder routing: passes for a missing or shunned builder are not in passed. They are decided inside driveRepo.

To try it, open /<owner>/<app>/next: a ready row held by a run or a pull now shows its reason.

🤖 Generated with Claude Code

The failed rule wanted a "Try:" line in a commit message, and I've now added one. I pushed an empty commit carrying it, and bun scripts/gate.ts passes locally. The code and tests are unchanged since the last push, so I did not re-run them.

The line reads: open /<owner>/<app>/next on the preview; a ready row a builder won't start shows its reason, and Lift on a held issue makes it ready under a pillar.

The pull description from my previous message still applies.

🤖 Generated with Claude Code

This round addresses all of @sentinel's requested changes, and the one thing I did differently is below. I've pushed it and haven't seen the forge's check result yet.

What changed

• Lift behaviour: Lift, wait_for stop on the Later gate and the pacer's release now all leave the issue under a pillar. The wait_for stop path did not before: only Lift and the pacer's release were wired up, which matches the gap the review pointed at. Lift and wait_for stop now share one function, stopWaiting in src/actions/gate.ts.
• Picker reasons: the pick filter (pickFilter, the reason words, passedWords) moved out of autonomy.ts into src/crew/pick_filter.ts. The web page, TUI and MCP tool now import that and not_startable.ts, not autonomy.ts. autonomy.ts uses the same module.
• Silent case closed: a ready issue no builder may take is now passed over as no_builder. The tick and Next up use one function for this, so they can't disagree. Normally a stalled issue is already explained by the hold ("a builder ran on it and left without a pull"). no_builder covers the remainder, such as a crew with no builder.
• Scope: the web page, TUI and MCP tool now compute sealedScope once per request.
• Docs: docs/features/next-up-why.md says Next up explains unstartable ready issues and that a lift places the issue under a pillar.

Tests

• test/not-startable.test.ts is new. It covers:

- polish_share, no_bet and no_builder - the stall hold on a shunned issue - the reason appearing on the web page, in the TUI and in the MCP next_up why - wait_for stop through MCP leaving the issue under a pillar and ready - a warm /next request completing in under 50 ms

• These ran green:

- the new test and test/lift-startable.test.ts - test/later-gate.test.ts and test/mcp-wait-for.test.ts - about 1,100 tests across 110 files that touch gate, later, autonomy, bets, polish and next-up - tsc, scripts/gate.ts and design-lint

What I chose not to do

• Where the pillar link lives: I first put it inside unlinkIssue, which broke later-gate.test.ts. That path serves taking the Later label off by hand, and the label puts the gate back. So it stays in stopWaiting, and that case is noted in the doc.
• Already-done issues: issues retired as already done on the base are not listed with a reason. Finding them needs git, so they aren't read on the page render. The tick still closes them with a note, and the doc says so.

The check failed because one test in test/not-startable.test.ts used a wall-clock bound: a warm /next request had to finish in under 50 ms. The check forbids clock budgets in tests. I replaced it with a bound on SQL statements, using requestStatements and expectWork from test/helpers/work.ts.

The Next up page, with its reasons, runs 92 statements on a warm request. The test allows at most 120. A regression that adds queries, such as an N+1, now fails the pull in every run.

tsc is clean and test/not-startable.test.ts passes locally. I pushed this and haven't seen the forge's check result yet.

Nothing else changed since the last pull description: the earlier summary and the choices listed in it still stand.