Complete Lane G planning acceptance

docs/architecture.md

@@ -413,7 +413,7 @@ These are the decisions that shape the structure. The full list, with the reason
 | F | Runner | Merged: F1 (lifecycle store, coordinator, shutdown wiring, startup recovery and the lock, planning API, feedback events, and stops that wait for their commit: #53, #74, #57, #59, #60, #96); F2a–F2b (execute prompts, audit, per-item execution, real workspace, durable safety findings: #67, #68, #92, #94, #128); F2d (already-fixed check, PR opening, branch pusher, production publishing, closing PRs on cancel: #84, #101, #110, #115, #116, #119, #123); production wiring and `start`/`resume` (#91, PRs #102, #105); planning through lane D (#117, #124, PRs #118, #120, #125); merging the task's own PR (#121, PR #126); start/resume approval, review-version, recovery and completed-prefix guards (#107, PR #130); continuation after a scope pause (#88, PR #134); the F3 durable trusted local-rebase foundation (#22, PR #136); the F4 foreign-conflict engine plus production sandbox adapter (#22, PRs #138 and #140); and sandboxed owned-commit conflict resolution (#22, PR #144). Next in #22: F5 owns current base/head refresh, rebase admission, post-rebase attribution and approval refresh, and head-bound `cmd:` execution. F6 owns rewritten-head push, fresh required-check refresh, the already-fixed rerun, and exact-pair guarded-merge handoff. The integrated flow pushes a rewritten head before it recomputes review state and reruns every plan item's head-bound `cmd:` checks; fresh required GitHub checks follow. |
 | Hardening | Allowlisted subprocess environments | Done: every Git command (#82, #83) and every `gh` runner (#84, #86). |
 | Tests | Test suite reliability | Done. The full suite runs ordinary tests first and Docker-backed files serially; CI and the real-Docker gate passed on PR #132 (#129). |
-| G | Planning screen | G1 through G3 built (#145, PRs #148 and #150): display/import the current plan, request a next-revision draft or suggestion cards, render or dismiss the result, and revision-bound Apply with exact ambiguous replay. G4 real-provider integration acceptance remains. |
+| G | Planning screen | Done (#145). The screen displays/imports the current plan, requests and renders a next-revision draft or suggestion cards, and applies results with revision-bound exact ambiguous replay. G4 composes the browser with the production planning setup, D-backed provider boundary, F endpoints and SQLite persistence; focused adapter, recorded-output and exact-head real-Docker planning suites cover the lower boundary. |
 | H | Issue ranking and Issues screen | Done. H4b (#108, PR #139) records author-bound trust, guards runner and publishing boundaries, controls which comments reach prompts, records prompt comment evidence, and provides trust/untrust controls on the Issues screen. |
 | I, J | Queue and run windows; learning from feedback | Not started (after F) |
 

docs/designs/codeboost-plan-indexed-review.md

@@ -2057,10 +2057,11 @@ These `T` IDs are requirement identifiers, not the build-order numbers. Current
   - Surfaced by: L4 (D24: A)
   - Files: web/learning, runner/metrics
   - Verify: repeated feedback matching an approved lesson raises its count and flags it
-- [ ] **T18 (P2, human: ~2 days / CC: ~45 min)** — core, agents, web — Plan schema: draft plans with either agent, import YAML or JSON, apply typed suggestions
+- [x] **T18 (P2, human: ~2 days / CC: ~45 min)** — core, agents, web — Plan schema: draft plans with the supported planning agent, import YAML or JSON, apply typed suggestions
   - Surfaced by: P1 (approved 2026-09-22)
   - Files: schema/, docs/plan-format.md, prompts/plan-author.md, core/plan (schema and meaning checks), agents/claude, agents/codex, web/plans (Import plan, suggestion cards)
-  - Verify: both examples pass and 8 broken plans fail; JSON-compatible YAML parsing is deterministic and rejects duplicate decoded keys, anchors/aliases, merge keys, tags, non-JSON scalars, excessive depth/size, and extra documents before validation; recorded Claude and Codex answers pass; an imported plan for #412 is rejected when the selected task is #413 without silently changing either issue; a declared final symlink can be deleted or safely retargeted while symlink parents and escaping targets are rejected; writes through declared links to undeclared files, directory children, or dangling targets fail the target snapshot audit before out-of-scope classification, tests, or commit; a plan with a `..` path or a dependency loop cannot be approved; the edit schema's copied definitions match; dependent add → edit and rename → edit plans pass projected-state validation, while missing sources and occupied destinations fail; a new field requires a new schema version and old plans validate against the immutable registry-selected snapshot before conversion; registry paths exist, snapshot IDs are version-qualified and unique, and unversioned CLI schemas exactly match the current snapshots; directory/root declarations and children beneath a file or submodule are rejected; malformed edit payloads and invalid resulting plans cannot be applied; a delayed suggestion captured for plan A at revision 3 with P1 cannot apply to plan B with the same revision/item IDs, and B remains unchanged; applying one card increments the revision and disables all old sibling cards until the person refreshes and reviews regenerated suggestions; concurrent/replayed Apply cannot create duplicate mutations; command chains and delimiter-escape payloads are rejected or remain data; appended flags such as `go test -exec` do not match a shorter allowlist entry and cannot execute; hostile filenames, branch names, script-derived argv values, approved lessons, and revision feedback remain escaped JSON data in the authoring prompt and cannot break its delimiters; `codex exec` runs with stdin closed
+  - Verify: both examples pass and 8 broken plans fail; JSON-compatible YAML parsing is deterministic and rejects duplicate decoded keys, anchors/aliases, merge keys, tags, non-JSON scalars, excessive depth/size, and extra documents before validation; recorded Claude answers pass, while every Codex planning request is refused before Docker or Git work under the later #75/#93 decision; an imported plan for #412 is rejected when the selected task is #413 without silently changing either issue; a declared final symlink can be deleted or safely retargeted while symlink parents and escaping targets are rejected; writes through declared links to undeclared files, directory children, or dangling targets fail the target snapshot audit before out-of-scope classification, tests, or commit; a plan with a `..` path or a dependency loop cannot be approved; the edit schema's copied definitions match; dependent add → edit and rename → edit plans pass projected-state validation, while missing sources and occupied destinations fail; a new field requires a new schema version and old plans validate against the immutable registry-selected snapshot before conversion; registry paths exist, snapshot IDs are version-qualified and unique, and unversioned CLI schemas exactly match the current snapshots; directory/root declarations and children beneath a file or submodule are rejected; malformed edit payloads and invalid resulting plans cannot be applied; a delayed suggestion captured for plan A at revision 3 with P1 cannot apply to plan B with the same revision/item IDs, and B remains unchanged; applying one card increments the revision and disables all old sibling cards until the person refreshes and reviews regenerated suggestions; concurrent/replayed Apply cannot create duplicate mutations; command chains and delimiter-escape payloads are rejected or remain data; appended flags such as `go test -exec` do not match a shorter allowlist entry and cannot execute; hostile filenames, branch names, script-derived argv values, approved lessons, and revision feedback remain escaped JSON data in the authoring prompt and cannot break its delimiters
+  - Evidence (2026-10-08): E1–E4 cover schema, parsing, prompt/response validation, recorded Claude output and Store orchestration; G1–G3 cover browser import, rendering, lifecycle and revision-bound Apply; G4's `plans-production.spec.ts` composes production issue description, lane D's provider boundary, F's HTTP endpoints and Store persistence through browser Apply, server restart and independent SQLite reopen. `planning-provider.test.ts`, `planning-production.test.ts` and `planning-recorded.test.ts` pass on the G4 head, and exact-head `agent-planning.test.ts` passes the real-Docker vendor-egress and cleanup gate.
 
 ### Unresolved decisions
 

docs/implementation/planning-acceptance.md

@@ -82,8 +82,9 @@ suggestion timer and the request share one ten-minute budget. The recording
 script still runs the provider in its own process and prints its runner label if
 it leaves anything.
 
-F/G still own live API and UI integration. The Store now guarantees revision/snapshot
-binding and pending-only settlement across processes, and E3 requires the caller's
-snapshot identity before admission. G must not treat these fixture-only results as a
-completed production planning milestone. T18/T9 remain incomplete until all assigned
-lane slices pass their original acceptance.
+The Store guarantees revision/snapshot binding and pending-only settlement across
+processes, and E3 requires the caller's snapshot identity before admission. G4 now
+composes the browser with production planning setup, lane D's provider boundary,
+F's HTTP lifecycle and Store persistence in `plans-production.spec.ts`. The exact-head
+real-Docker planning gate also passes, completing T18. T9 remains incomplete until
+its remaining F6 common-CI and all-suite gate passes.

docs/implementation/planning-screen.md

@@ -1,13 +1,15 @@
 # Planning screen
 
-**Lane and steps:** lane G, G1 through G3. Tracking issue: #145.
+**Lane and steps:** lane G, G1 through G4. Tracking issue: #145.
 
 G1 adds a Plans screen over the planning contracts already owned by lanes E and F. It does not add another plan writer: the browser imports through `POST /api/plan/import`, then reloads `GET /api/review` so the current Store revision remains the only displayed authority.
 
 G2 adds browser controls for the existing draft and suggestion request lifecycles. The screen can ask for a complete next-revision draft or independent edit cards, poll the durable request, render the result and dismiss it.
 
 G3 applies a ready draft or one suggestion card through the Store-owned revision-bound endpoint. The browser never constructs a new plan. It retains one action ID across an ambiguous Apply retry, accepts only the expected next revision, then reloads the authoritative review. Once Apply commits, a reload failure is reported separately and cannot re-enable the action or start authoring against the old revision; a manual refresh must observe the applied revision first. Applying one card consumes the response; sibling cards stay disabled and **Refresh suggestions** sends their bounded operation, item and summary descriptions in a new revision-bound request without replacing newer guidance in the textarea.
 
+G4 connects those browser flows to the production planning setup rather than a browser-only provider stub. Its acceptance runs suggestions and whole-plan drafts through `productionPlanning`, the real `createPlanningProvider` boundary with deterministic lane D stand-ins, F's production HTTP endpoints and the SQLite Store. It applies each result in the browser, restarts the server between them and reopens SQLite after each Apply. The separate real-Docker suite remains the authority for the concrete clone, bounded storage and Claude adapter implementations.
+
 ## Display contract
 
 The screen renders the complete current plan: issue, summary, revision, open questions, ordered items, dependencies, files (including both sides of a rename) and acceptance checks. Navigation uses `?view=plans`, announces the active destination with `aria-current`, and preserves the existing Review composer DOM while the Plans screen is open. An authoritative Review refresh reconciles a settled Plans revision or load-failure status with the response it applies, but only while no newer plan operation owns that status. A failed Review refresh still clears unavailable plan data, but likewise replaces the Plans status only while it retains ownership.
@@ -32,4 +34,4 @@ Suggestion replies render as plain text followed by one line-separated row per t
 
 `test/browser/plans-authoring.spec.ts` covers duplicate activation, focus and disabled styling, request-time guidance preservation, exact ambiguous-start replay, a start refused after an intervening import, malformed-status ownership, failed states with impossible output, consumed-result stale labeling, rejection of mismatched bindings, wrong-operation payloads, incomplete edit cards and incomplete nested draft data, hostile markup and attribute text in both result types, retained completed history and invalidated-history labeling, suggestion rows, whole-draft preview without mutation, dismissal and ambiguous-cancellation reconciliation without a revision change, an older poll returning after dismissal, the interleaving where an import advances the plan before an older ready poll returns, single-flight draft Apply with Review text and snippet preservation, committed-Apply reporting when the authoritative reload fails, and exact ambiguous Apply replay followed by sibling refresh and a second revision-bound Apply.
 
-G4 completes real-provider/store integration and the remaining T18 browser/adapter gate.
+`test/browser/plans-production.spec.ts` is G4's composed browser/adapter acceptance. It proves the production issue description, provider schema mount and read-only planning invocation feed F's durable request lifecycle; the browser can render and Apply both result types; and revisions 2 and 3 survive independent Store reopens and a server restart. `test/planning-provider.test.ts`, `test/planning-production.test.ts` and `test/planning-recorded.test.ts` retain the focused adapter, production-wiring and real recorded-output checks. `test/agent-planning.test.ts` retains the real-Docker vendor-egress and cleanup gate.