Build a delivered plan's later changes on demand without LIVE_BUILD

[MaggieAppleton]

Note: This branch now also carries the 13 commits of #454 (prototype spikes). #454 was merged into this branch while it was #454's base, so landing this PR lands #454's content on main too.

Slice 2 of the approved build-plan jig. Stacks on #508.

What changes

• Manual mode records the built source. Without LIVE_BUILD, a browser build that delivers (verification passed) now records the source it built (plan.live). The flag-off lifecycle is unchanged: verification still ends the run, and nothing auto-triggers. The live record now restores for a verified manual run as well as a live one.
• N changes to build + Build. The capsule counts the top-level blocks changed since that source and offers a small outline Build. POST /api/channels/:id/implementation/rebuild checks the origin and write access, then reuses queueRebuild to queue one rebuild of the edits onto the existing pull requests on the presser’s own connected agent. It persists the rebuild before answering and before announcing. A collaborator’s tooltip says “Edits since @Maggie built it. Building them runs on your agent.”
• Retry on a failed rebuild uses the same route, in either mode. Under LIVE_BUILD the capsule still shows a clock and no Build.
• Docs: implementation-lifecycle.md.

Tests

• Route test: a manual build delivers, records its source (0 changes), counts an edit (1 change), refuses a cross-origin Build, queues one rebuild for the presser, and refuses a second while it runs.
• Unit: Build appears only in manual mode for someone who can act, Retry on a failed rebuild, and the collaborator tooltip.
• E2E: Build plan → Built → typing an edit → “1 change to build” → the capsule’s Build queues a rebuild (the tab stays inert).
• apps/server unit tests and implementation-launcher pass locally.

Screenshots

Desktop and phone: 3 changes to build with Build, Build failed with Retry, and a collaborator with 2 changes.

Review fixes

1. A pressed Build (and Retry on a failed rebuild) is refused by queueRebuild and the route while decisions or accepted comments are open. The capsule’s action stays visible but inert, with the same reason as Build plan in its tooltip and accessible description.
2. The press is the approval. This is now stated at reportRebuild, in docs/implementation-lifecycle.md and in AGENTS.md “Implementation graphs”, replacing the LIVE_BUILD-only wording.
3. restoreLive accepts a live run, or a manual run whose outcome is implemented or delivered. A run returned for changes is rejected; the new test covers this.
4. A refused Build is visible.
   • Desktop: the reason shows inline beside the capsule, as an alert.
   • Phone: Build opens with the reason in its headline.
   • The reason clears once the changes are building or built.
5. On a phone the action reads Build changes, both as its label and as its accessible name.
6. “Building them runs on your agent.” is shown only to people who can build.
7. New server tests.
   • A manual build goes queued → read_rebuild → report_rebuild, then reads as up to date (changes: 0).
   • A pressed Build is refused while a decision is open.
   • A delivered manual build’s live record restores after reopen.

Review fixes (restack, 2026-10-12)

• Busy agent. A pressed Build skips connections that are running a prototype or another document's build, as POST /implementation does (options.busy and the connector's busy check). When none is free it answers agent-busy, shown as "Your local agent is busy with another document".
• Refusal copy. Rebuild refusals go through the shared copy mapper.
• DELETE /implementation/request. It refuses archived documents.
• e2e. The completing fixture agent now reads and reports the rebuild, so the test waits for Built and a recorded commit; |Build failed is no longer accepted. It finds the capsule's Build by role, not by class.
• Route tests. Pull-only callers get 403, archived documents 403, and children 404. A collaborator's press runs on their own agent, a busy agent is refused, and a manual rebuild reopens intact.
• Capsule action. The Retry and Build action uses aria-disabled and aria-busy instead of disabled.

🤖 Generated with Claude Code

[MaggieAppleton]

Review: Changes needed

Diffed against design-build-capsule (#508). I ran the branch on the fake server (8825) and stubbed the snapshot to check the manual states at 1440×900 and 390×844, as the builder and as a collaborator. The capsule shows “3 changes to build” with Build, “Build failed” with Retry, and “Edits since @Maggie built it. Building them runs on your agent.” for a collaborator, as in the jig.

What holds up

• Route authorization. It follows the pattern of the existing POST. The origin check comes first. Then browser() runs: the session (admission), the channel (no child documents), and a fresh repositoryAccess on the caller’s token with a repository-id match. After that it requires push or admin and an unarchived document. So admission alone is not enough.
• Persistence before publication. queueRebuild persists (persistExclusive) before connections.assign, announceImplementation and the HTTP answer, and it rolls back on failure.
• Double-click. The client guard (rebuilding, disabled) and the server’s buildActive check under exclusive refuse a second rebuild with a 409. The route test covers this.
• Clicker’s agent. by = session.user.id picks the owner, so only the presser’s own connections are eligible, and the build is recorded under the presser.
• Flag-off lifecycle. It is unchanged apart from the new plan.live record: verification still ends the run, and LiveSyncCoordinator stays gated on config.liveBuild, so nothing auto-triggers.

Findings

1. Build can run with open decisions or accepted comments (routes.ts, rebuild route; builds.ts:queueRebuild). Nothing calls implementationReadiness. I reproduced this in the UI: a built document with 2 unanswered decisions still shows “3 changes to build” with an active Build. Build plan refuses this same state, and it is the stated rule (“Answer N open decisions first”). Today, pressing Build sends half-decided prose to the agent. Fix: in the rebuild route, refuse with implementationReadiness(plan, plan.revision), at least when by is set. In buildLook, return build: false with the same reason as the tooltip when phase.blocked or unanswered > 0, so the button is inert with its reason, like Build plan.
2. Flag-off deployments now get the rebuild path that skips graph approval (builds.ts:reportRebuild). The rebuild appends an approved, completed graph version from the coding agent’s report alone. The code comment calls this “LIVE_BUILD prototype … deliberately bypasses the human-only graph approval.” This PR makes it reachable without LIVE_BUILD. A human press is arguably the approval, but AGENTS.md says approval has no production route. Update that comment, and update docs/implementation-lifecycle.md and AGENTS.md (“Implementation graphs”) to say a user-pressed Build is the approval in flag-off mode. Or gate the manual path behind its own flag.
3. Restore is looser than it needs to be (builds.ts:restoreLive). Dropping && item.live means any archived run with that id passes, including one that ended in revision_requested or was blocked. Only a delivered or implemented run should, so check that rather than accepting any history entry. For example, keep item.live, or require the run’s outcome to be implemented/delivered via historyFor. The sidecar is server-written, so this is defence in depth rather than an exploit, but the old check was doing exactly that job.
4. A refused Build gives no visible feedback (build-plan-button.tsx). rebuildError appears only as the capsule’s tooltip and aria-description. On desktop you see it only if you hover again. On the phone the capsule is glyph-only and tooltips don’t show, so “Start your local agent, then build” is never seen. Show it, for example as a toast, or in Build’s headline, where the phone already carries the words. It also stays set after a later successful rebuild until the next press. Clear it on the next snapshot change.
5. The phone shows two adjacent “Build” controls. The top bar has the outline Build action next to a bare orange dot, and directly below it is the Build destination tab with the same dot. One acts and the other navigates, but they read as the same control. Their accessible names also collide (getByRole("button", { name: "Build" }) matches both outside the nav group). Use “Build changes” on compact, or always.
6. The collaborator copy says “Building them runs on your agent.” even to people who can’t act. tip doesn’t depend on act. Keep the clause only when look.build is true.
7. The manual rebuild is only tested to “queued”. The route test and the e2e stop once the rebuild is queued. Add one route test that runs read_rebuild → report_rebuild in flag-off mode and asserts the base advances (changes: 0). Nothing currently proves that the rest of the rebuild path works without LIVE_BUILD.

Checks

After the hash renewal commit (2a8ea49c, which changes only dynamic-web.json), validation and container pass on the rebased head 544f2096. That rebase changes only the hash file relative to the head I reviewed. e2e was still running when I posted this. Locally on 0bbd0823, the full bun test gives 4676 pass and 0 fail, and types, check-design-record and design:check pass. The merge-conflict notes for #457/#460/#495 are on #508 and apply here too: #460 also edits implementation-lifecycle.md.