F: run plan suggestions through lane D in planning's own worker (#117, part 2)

[mchwang]

Part 2 of #117, after #118. Plan suggestions now run Claude through lane D in production.

What changes

• One worker per feature. AgentWorker (formerly QuestionWorker, which stays as an alias) and runner/question-worker.ts each serve one feature. LeftoverLedger, worker roots, locks, the record file and the recovery wording now take a WorkerNaming. ASK_NAMING reproduces every Ask name and message exactly.
• Planning's own isolation. Planning gets its own worker thread, TMPDIR root (codeboost-plan-*), ledger (<db>.planning-leftovers.json), lock directory and a per-database owner token (planning_owner). Its recovery never touches Ask's or the runner's Docker objects, and Ask's never touches planning's.
• PlanningAgent (runner/planning.ts) runs each request on the review repository at the current snapshot head, with the vendor chosen in Settings. Codex is refused before any lock, worker or Docker work (D: decide how Codex reads code in review, execute and fix (shell is off in every phase) #93).
• Budget. E3's suggestion timer and the request share one 10-minute budget (PLANNING_BUDGET_MS). The worker's deadline leaves Ask's 5 s settle margin.
• Issue text. PlanningDeps.describe may be async. The server replays a recorded start first, then reads the issue from GitHub before the recorded action, using the existing bounded, collaborators-only issueText. A GitHub failure returns 502 and is not recorded. A shutdown during the read returns 503.
• Shutdown. After E3 aborts the requests, any still unsettled after 20 s (Ask's grace) are ended by closing planning's worker.
• Wiring. web/planning.ts and web/cli.ts turn planning on for any non-demo review with a github block. Demos never plan.

Behavior to note

• Lazy recovery, as for Ask. A crashed process's planning container is removed by the next process's first planning request, not at startup. Its output has no route back to the Store, so cancelling such a pending request stays safe. runner-lifecycle.md is updated to say so; it previously said startup recovery stopped it.
• Base ref. The prompt names the base by its commit, because main has no base-branch setting yet. This can switch to F: publish a finished task's pull request in production (#103) #110's github.baseBranch once that lands.

Validation

• npm run typecheck: passed.
• CI's npm test command: 62 files, 1417 tests passed.
• The real-Docker planning test (test/agent-planning.test.ts, added to the agent-isolation workflow) passes locally. A fake token reaches Anthropic from inside the container and gets a 401, and the test checks that nothing carrying planning's owner is left behind.
• Ask's suites (question-agent, question-leftovers, questions) pass unchanged.

Independent review

A fresh subagent compared Ask's names, messages and step order with main and found no difference Ask could observe. It also confirmed the isolation between Ask and planning and the security of the issue text. Fixed from its findings:

• a replayed start depended on GitHub (now replays first);
• a describe failure returned 409 (now 502, or 503 during shutdown);
• shutdown could wait about 10 minutes (now bounded by Ask's grace);
• a doc said a stray container ran at most 10 minutes (corrected);
• seven test gaps.

Not changed:

• CLI wiring has no test (it is one call);
• WorkerNaming's size;
• Ask and planning may each build the same image tag concurrently on a first run;
• an issue that fits an execute prompt but not a planning prompt is refused, with that refusal recorded.

🤖 Generated with Claude Code