From 69d0b1d52d429969894734a21d8c318d7f41e826 Mon Sep 17 00:00:00 2001 From: mchwang Date: Fri, 9 Oct 2026 23:39:53 -0700 Subject: [PATCH 01/43] Close out Lane G status records (#145) Lane G (G1-G4) merged in PRs #148, #150, #151 and #152. The README and the design overview still described the Planning screen as unbuilt, and build step 6 said "no screen yet". Record the screen as built, mark build step 6 done, and record Lane G's release of the shared web files plus the remaining lane F follow-up (#146) in the planning-screen document. Co-Authored-By: Claude Opus 5.5 --- README.md | 2 +- docs/designs/codeboost-plan-indexed-review.md | 4 ++-- docs/implementation/planning-screen.md | 6 ++++++ 3 files changed, 9 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index d1bc2f96..95eeec9e 100644 --- a/README.md +++ b/README.md @@ -2,7 +2,7 @@ Review agent-made Git changes one plan item at a time. The approved plan lists each item's files and acceptance checks; the review engine shows which item produced each change and flags foreign or overlapping work. -**Status:** the plan/linking library, SQLite store, local review screen, opt-in code-writing runner, durable local rebase, and exact-head plan command checks are implemented. Run `npm run demo` and open its private local URL. Ask and the runner use Claude Code inside locked-down containers; Codex is refused because it reads code only by running commands ([why](docs/implementation/agent-isolation.md#codex-is-refused-in-every-phase)). They need Docker, plus `CLAUDE_CODE_OAUTH_TOKEN` (from `claude setup-token`). Startup builds the agent image, which can take a few minutes. A configured GitHub review can merge only after the guarded exact-head gate passes. The agent container, vendor-only network, credential-free command-check profile, and Claude/Codex adapters are described in [agent isolation](docs/implementation/agent-isolation.md). Pushing a rebased head, waiting for its required checks, and handing that exact pair to guarded merge remain follow-up work. The paired human review experiment was cancelled before results were recorded and no longer blocks roadmap work; optional future validation is tracked in [#19](https://github.com/codeabovelab/codeboost/issues/19). +**Status:** the plan/linking library, SQLite store, local review screen, Plans screen (plan import, agent drafts and suggestions, revision-bound Apply), opt-in code-writing runner, durable local rebase, and exact-head plan command checks are implemented. Run `npm run demo` and open its private local URL. Ask and the runner use Claude Code inside locked-down containers; Codex is refused because it reads code only by running commands ([why](docs/implementation/agent-isolation.md#codex-is-refused-in-every-phase)). They need Docker, plus `CLAUDE_CODE_OAUTH_TOKEN` (from `claude setup-token`). Startup builds the agent image, which can take a few minutes. A configured GitHub review can merge only after the guarded exact-head gate passes. The agent container, vendor-only network, credential-free command-check profile, and Claude/Codex adapters are described in [agent isolation](docs/implementation/agent-isolation.md). Pushing a rebased head, waiting for its required checks, and handing that exact pair to guarded merge remain follow-up work. The paired human review experiment was cancelled before results were recorded and no longer blocks roadmap work; optional future validation is tracked in [#19](https://github.com/codeabovelab/codeboost/issues/19). ## Development diff --git a/docs/designs/codeboost-plan-indexed-review.md b/docs/designs/codeboost-plan-indexed-review.md index 5cb53ca8..b8249eab 100644 --- a/docs/designs/codeboost-plan-indexed-review.md +++ b/docs/designs/codeboost-plan-indexed-review.md @@ -27,7 +27,7 @@ Last checked against the code: 2026-09-26 (see "Lane status" under "Parallel bui - **How it stays trustworthy.** codeboost records commits in a trusted ledger with either an owning plan item or an explicit foreign/unowned classification. Rewriting a foreign commit never turns it into owned work. It also checks each change against the files the plan item said it would touch. One blind spot remains: an unrelated edit inside a file the plan item declared is caught only by the review agent and by you. - **How it stays safe.** Agents run inside a container that holds only the task's code and the credential for that phase, so your other files and credentials are not there. Ask, code-writing runs, and conflict resolution use provider-specific containers; exact-head `cmd:` checks use a credential-free read-only profile. codeboost needs your approval before its own dependency installation or invocation of changed scripts; containment must also cover commands the agent already ran. - **It learns from you.** After each task, codeboost turns your feedback into short lessons. You approve each lesson before agents use it, and a Learning screen shows whether you are repeating yourself less. -- **Where the build is.** Built: the plan and linking library, SQLite store, review screen with Ask and change requests, guarded merge gate with merge-queue support, agent isolation boundary, opt-in code-writing runner and publishing, durable local rebase/conflict resolution, and pre-merge base/head refresh with exact-head `cmd:` checks. Still deferred: pushing the rewritten head, waiting for its required checks, handing that exact pair to guarded merge, and the Planning, Queue, Lessons and Learning screens (the ranked Issues screen is built). Optional real-PR validation is tracked separately in #19 and is not a prerequisite. +- **Where the build is.** Built: the plan and linking library, SQLite store, review screen with Ask and change requests, guarded merge gate with merge-queue support, agent isolation boundary, Planning screen (lane G, #145), opt-in code-writing runner and publishing, durable local rebase/conflict resolution, and pre-merge base/head refresh with exact-head `cmd:` checks. Still deferred: pushing the rewritten head, waiting for its required checks, handing that exact pair to guarded merge, and the Queue, Lessons and Learning screens (the ranked Issues screen is built). Optional real-PR validation is tracked separately in #19 and is not a prerequisite. ## Terms used @@ -567,7 +567,7 @@ The numbers below identify delivery milestones, not a requirement to implement t 3. **Optional validation.** A future real-PR comparison may test the assumptions in "How we will know it works," but it is non-blocking under the superseding decision above. 4. **Merge gate and merging** (product workflow step 9): the merge rules, the pre-merge sequence, and merging through `gh`. Increment 1 merged (PR #23), and merge-queue support merged (#38, #46, closing #24); the rest waits for the runner in build step 5. See the scope and completion criteria below. 5. **Running agents.** Per-task clones, containers, agent adapters, permissions, one invocation per plan item, review rounds, the "already fixed" check, and opening PRs (step 6). Isolation boundary merged (lane D, PRs #31, #40, #44, #47, #50); the runner (lane F) is next. -6. **Planning screen.** Writing plans with an agent, and approving plan changes (steps 2 and 3). Backend in progress (lane E); no screen yet. +6. **Planning screen.** Writing plans with an agent, and approving plan changes (steps 2 and 3). *Done:* planning backend (lane E, E1–E4) and the Plans screen (lane G, G1–G4, #145; PRs #148, #150, #151, #152). 7. **Queue, schedule, and recovery** (steps 4 and 5). 8. **Issue list, sorted by how critical each issue is** (step 1). *Done:* ranking backend (H1–H3), the Issues screen (H4a, #55), and the author-bound "trust this issue" action and runner guard (H4b, #108, PR #139) have merged. 9. **Learning from your feedback** (step 10): lessons, the Lessons inbox, and the Learning screen. It needs the reject loop from steps 4 to 7. diff --git a/docs/implementation/planning-screen.md b/docs/implementation/planning-screen.md index 47a3d2b2..bf7dd8f7 100644 --- a/docs/implementation/planning-screen.md +++ b/docs/implementation/planning-screen.md @@ -35,3 +35,9 @@ 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. `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. + +## Handoff + +Lane G is complete (#145). G1–G4 merged as PRs #148, #150, #151 and #152. Lane G no longer owns `web/public/index.html`, `web/public/app.js`, `web/public/style.css` or the Plans browser specs. The next change to those files takes ownership under the usual rules: check open PRs and worktrees first. + +One related issue remains open. #146: `POST /api/plan/import` refuses request bodies over 16 KiB, but some schema-valid plans are larger. Lane F owns it, because the fix is in the server's request limit, not in the screen. From 53a38e51880f7bcde8f83e94c20893d4507182dc Mon Sep 17 00:00:00 2001 From: mchwang Date: Fri, 9 Oct 2026 23:40:54 -0700 Subject: [PATCH 02/43] Point lane status readers to the live table; name released files (#145) Co-Authored-By: Claude Opus 5.5 --- docs/designs/codeboost-plan-indexed-review.md | 4 ++-- docs/implementation/planning-screen.md | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/designs/codeboost-plan-indexed-review.md b/docs/designs/codeboost-plan-indexed-review.md index b8249eab..ae054ef0 100644 --- a/docs/designs/codeboost-plan-indexed-review.md +++ b/docs/designs/codeboost-plan-indexed-review.md @@ -6,7 +6,7 @@ Repo: codeabovelab/codeboost Status: APPROVED Mode: Builder (open source / research) Writing standard: plain language, ISO 24495-1:2023 -Last checked against the code: 2026-09-26 (see "Lane status" under "Parallel build lanes") +Last checked against the code: 2026-09-26 (see "Lane status" under "Parallel build lanes"). For the current state of each lane, see the lane table in `docs/architecture.md`. ## About this document @@ -1894,7 +1894,7 @@ Critical gaps (no test, no handling, and silent): 0. #### Lane status (checked 2026-09-26, after #55) -This table records merged and open PRs only. A lane is complete only when every step meets its acceptance criteria on `main`. +This table is a snapshot from 2026-09-26 and is not kept current. For the current state of each lane, see the lane table in `docs/architecture.md`. This table records merged and open PRs only. A lane is complete only when every step meets its acceptance criteria on `main`. | Lane | Merged | Open PRs | Next | |---|---|---|---| diff --git a/docs/implementation/planning-screen.md b/docs/implementation/planning-screen.md index bf7dd8f7..59d7e526 100644 --- a/docs/implementation/planning-screen.md +++ b/docs/implementation/planning-screen.md @@ -38,6 +38,6 @@ Suggestion replies render as plain text followed by one line-separated row per t ## Handoff -Lane G is complete (#145). G1–G4 merged as PRs #148, #150, #151 and #152. Lane G no longer owns `web/public/index.html`, `web/public/app.js`, `web/public/style.css` or the Plans browser specs. The next change to those files takes ownership under the usual rules: check open PRs and worktrees first. +G1–G4 have merged as PRs #148, #150, #151 and #152, which completes lane G (#145). Lane G no longer owns `web/public/index.html`, `web/public/app.js`, `web/public/style.css`, `test/browser/plans.spec.ts`, `test/browser/plans-authoring.spec.ts`, `test/browser/plans-production.spec.ts` or this document. The next change to those files takes ownership under the usual rules: check open PRs and worktrees first. One related issue remains open. #146: `POST /api/plan/import` refuses request bodies over 16 KiB, but some schema-valid plans are larger. Lane F owns it, because the fix is in the server's request limit, not in the screen. From fe50fe35b70ef1576c96828fd3278243c7e677f3 Mon Sep 17 00:00:00 2001 From: mchwang Date: Fri, 9 Oct 2026 23:41:50 -0700 Subject: [PATCH 03/43] Clarify Lane G handoff and screen name (#145) Co-Authored-By: Claude Opus 5.5 --- docs/designs/codeboost-plan-indexed-review.md | 4 ++-- docs/implementation/planning-screen.md | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/designs/codeboost-plan-indexed-review.md b/docs/designs/codeboost-plan-indexed-review.md index ae054ef0..bf2b924a 100644 --- a/docs/designs/codeboost-plan-indexed-review.md +++ b/docs/designs/codeboost-plan-indexed-review.md @@ -6,7 +6,7 @@ Repo: codeabovelab/codeboost Status: APPROVED Mode: Builder (open source / research) Writing standard: plain language, ISO 24495-1:2023 -Last checked against the code: 2026-09-26 (see "Lane status" under "Parallel build lanes"). For the current state of each lane, see the lane table in `docs/architecture.md`. +Last checked against the code: 2026-09-26 (see "Lane status" under "Parallel build lanes"). The summary and build-step status were updated later as lanes merged. For the current state of each lane, see the lane table in `docs/architecture.md`. ## About this document @@ -27,7 +27,7 @@ Last checked against the code: 2026-09-26 (see "Lane status" under "Parallel bui - **How it stays trustworthy.** codeboost records commits in a trusted ledger with either an owning plan item or an explicit foreign/unowned classification. Rewriting a foreign commit never turns it into owned work. It also checks each change against the files the plan item said it would touch. One blind spot remains: an unrelated edit inside a file the plan item declared is caught only by the review agent and by you. - **How it stays safe.** Agents run inside a container that holds only the task's code and the credential for that phase, so your other files and credentials are not there. Ask, code-writing runs, and conflict resolution use provider-specific containers; exact-head `cmd:` checks use a credential-free read-only profile. codeboost needs your approval before its own dependency installation or invocation of changed scripts; containment must also cover commands the agent already ran. - **It learns from you.** After each task, codeboost turns your feedback into short lessons. You approve each lesson before agents use it, and a Learning screen shows whether you are repeating yourself less. -- **Where the build is.** Built: the plan and linking library, SQLite store, review screen with Ask and change requests, guarded merge gate with merge-queue support, agent isolation boundary, Planning screen (lane G, #145), opt-in code-writing runner and publishing, durable local rebase/conflict resolution, and pre-merge base/head refresh with exact-head `cmd:` checks. Still deferred: pushing the rewritten head, waiting for its required checks, handing that exact pair to guarded merge, and the Queue, Lessons and Learning screens (the ranked Issues screen is built). Optional real-PR validation is tracked separately in #19 and is not a prerequisite. +- **Where the build is.** Built: the plan and linking library, SQLite store, review screen with Ask and change requests, guarded merge gate with merge-queue support, agent isolation boundary, Plans screen (lane G, #145), opt-in code-writing runner and publishing, durable local rebase/conflict resolution, and pre-merge base/head refresh with exact-head `cmd:` checks. Still deferred: pushing the rewritten head, waiting for its required checks, handing that exact pair to guarded merge, and the Queue, Lessons and Learning screens (the ranked Issues screen is built). Optional real-PR validation is tracked separately in #19 and is not a prerequisite. ## Terms used diff --git a/docs/implementation/planning-screen.md b/docs/implementation/planning-screen.md index 59d7e526..5dbc6b48 100644 --- a/docs/implementation/planning-screen.md +++ b/docs/implementation/planning-screen.md @@ -38,6 +38,6 @@ Suggestion replies render as plain text followed by one line-separated row per t ## Handoff -G1–G4 have merged as PRs #148, #150, #151 and #152, which completes lane G (#145). Lane G no longer owns `web/public/index.html`, `web/public/app.js`, `web/public/style.css`, `test/browser/plans.spec.ts`, `test/browser/plans-authoring.spec.ts`, `test/browser/plans-production.spec.ts` or this document. The next change to those files takes ownership under the usual rules: check open PRs and worktrees first. +G1–G4 have merged as PRs #148, #150, #151 and #152, which completes lane G (#145). Lane G no longer owns `web/public/index.html`, `web/public/app.js`, `web/public/style.css`, `test/browser/plans.spec.ts`, `test/browser/plans-authoring.spec.ts`, `test/browser/plans-production.spec.ts` or this document. G3 also edited `web/server.ts` and `test/planning-drafts-api.test.ts`; those stay with lane F, which owns the server contract. Before the next change to any of these files, follow "Task resumption and ownership" in `AGENTS.md`: check open PRs, branches and worktrees first. One related issue remains open. #146: `POST /api/plan/import` refuses request bodies over 16 KiB, but some schema-valid plans are larger. Lane F owns it, because the fix is in the server's request limit, not in the screen. From 928c863ffa1917fcb9ac67d4a3b8c698cd7462c0 Mon Sep 17 00:00:00 2001 From: mchwang Date: Fri, 9 Oct 2026 23:42:32 -0700 Subject: [PATCH 04/43] Tighten Lane G handoff wording (#145) Co-Authored-By: Claude Opus 5.5 --- docs/implementation/planning-screen.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/implementation/planning-screen.md b/docs/implementation/planning-screen.md index 5dbc6b48..04205d69 100644 --- a/docs/implementation/planning-screen.md +++ b/docs/implementation/planning-screen.md @@ -38,6 +38,6 @@ Suggestion replies render as plain text followed by one line-separated row per t ## Handoff -G1–G4 have merged as PRs #148, #150, #151 and #152, which completes lane G (#145). Lane G no longer owns `web/public/index.html`, `web/public/app.js`, `web/public/style.css`, `test/browser/plans.spec.ts`, `test/browser/plans-authoring.spec.ts`, `test/browser/plans-production.spec.ts` or this document. G3 also edited `web/server.ts` and `test/planning-drafts-api.test.ts`; those stay with lane F, which owns the server contract. Before the next change to any of these files, follow "Task resumption and ownership" in `AGENTS.md`: check open PRs, branches and worktrees first. +G1–G4 have merged as PRs #148, #150, #151 and #152, which completes lane G (#145). Lane G no longer owns `web/public/index.html`, `web/public/app.js`, `web/public/style.css`, `test/browser/plans.spec.ts`, `test/browser/plans-authoring.spec.ts`, `test/browser/plans-production.spec.ts` or this document. G3 also edited `web/server.ts` and `test/planning-drafts-api.test.ts`; those stay with lane F, which owns the server contract. Before the next change to any file named above, follow "Task resumption and ownership" in `AGENTS.md`: check open PRs, branches and worktrees first. -One related issue remains open. #146: `POST /api/plan/import` refuses request bodies over 16 KiB, but some schema-valid plans are larger. Lane F owns it, because the fix is in the server's request limit, not in the screen. +One related issue remains open. #146: `POST /api/plan/import` refuses request bodies over 16 KiB, but some schema-valid plans are larger. Lane F owns it, because the fix is in the server contract (the request limit or the import bound), not in the screen. From b69a14639472abfcd31493730324f709b896da03 Mon Sep 17 00:00:00 2001 From: mchwang Date: Fri, 9 Oct 2026 23:43:23 -0700 Subject: [PATCH 05/43] Mark lane G done in the Wave 2 table; state #146 ownership source (#145) Co-Authored-By: Claude Opus 5.5 --- docs/designs/codeboost-plan-indexed-review.md | 2 +- docs/implementation/planning-screen.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/designs/codeboost-plan-indexed-review.md b/docs/designs/codeboost-plan-indexed-review.md index bf2b924a..363756eb 100644 --- a/docs/designs/codeboost-plan-indexed-review.md +++ b/docs/designs/codeboost-plan-indexed-review.md @@ -1951,7 +1951,7 @@ Read each row left to right: finish and validate step 1 before step 2 within tha | Lane | Prerequisites | Scope / ownership | Completion check | |---|---|---|---| | F — runner and pre-merge automation | C and D merged; invocation contract available | Build step 5 runner plus #22 / remaining build step 4; T3, T6, T11. Own `runner/`, rebase helpers and shared acceptance persistence during this wave. | Preserve ledger attribution through rebase; recompute approval staleness; execute and persist head-bound checks; cover timeout, cancellation, shutdown and collaborator-push races; complete #22 acceptance. | -| G — planning screen | E merged; C releases shared UI files | Build step 6 UI and T18 integration. Own `web/` and dedicated browser tests during this wave. Route persistence changes through F. UI work can use controlled provider fixtures until D is available. | Import, generation and Apply preserve user drafts and attachments and reject stale/replayed suggestions. Final completion requires real D-backed invocation and integration with F/store, not fixtures alone. | +| G — planning screen | Done: G1–G4 (#145; PRs #148, #150, #151, #152) | Build step 6 UI and T18 integration. Owned `web/` and dedicated browser tests during this wave; released them after G4 (see `docs/implementation/planning-screen.md`). Route persistence changes through F. UI work can use controlled provider fixtures until D is available. | Import, generation and Apply preserve user drafts and attachments and reject stale/replayed suggestions. Final completion requires real D-backed invocation and integration with F/store, not fixtures alone. Done. | | H — issue prioritization | Done: access contract and ranking policy (H1); retrieval/ranking (#39, #42); Issues screen (#55); author-bound trust, runner/publish guards, prompt comment evidence, and trust controls (#108, PR #139) | Build step 8: issue retrieval, normalization, ranking, and trust enforcement with dedicated unit, integration, and browser tests. | Done. Stable ranking has visible reasons and explicit unavailable/stale states; H4b persists trust, fails closed at runner and publishing boundaries, controls comment inclusion, records delivered comment evidence, and works in demo mode. | F, G and H can proceed together within these ownership boundaries. If F and G need an incompatible shared storage/API change, land that small prerequisite first; neither edits the other's files in parallel. Merge independent backend modules first, then their shared integration, and rerun checks on the combined head. diff --git a/docs/implementation/planning-screen.md b/docs/implementation/planning-screen.md index 04205d69..51cc7a8a 100644 --- a/docs/implementation/planning-screen.md +++ b/docs/implementation/planning-screen.md @@ -40,4 +40,4 @@ Suggestion replies render as plain text followed by one line-separated row per t G1–G4 have merged as PRs #148, #150, #151 and #152, which completes lane G (#145). Lane G no longer owns `web/public/index.html`, `web/public/app.js`, `web/public/style.css`, `test/browser/plans.spec.ts`, `test/browser/plans-authoring.spec.ts`, `test/browser/plans-production.spec.ts` or this document. G3 also edited `web/server.ts` and `test/planning-drafts-api.test.ts`; those stay with lane F, which owns the server contract. Before the next change to any file named above, follow "Task resumption and ownership" in `AGENTS.md`: check open PRs, branches and worktrees first. -One related issue remains open. #146: `POST /api/plan/import` refuses request bodies over 16 KiB, but some schema-valid plans are larger. Lane F owns it, because the fix is in the server contract (the request limit or the import bound), not in the screen. +One related issue remains open. #146: `POST /api/plan/import` refuses request bodies over 16 KiB, but some schema-valid plans are larger. The fix is to raise the server's request limit, or to tighten the schema or import bound so the two agree. The screen needs no change. #146 and the #145 progress notes record it as lane F's work. From 6bc0a45b0d0baa5ecdaa9b6e2225aa792eeef585 Mon Sep 17 00:00:00 2001 From: mchwang Date: Fri, 9 Oct 2026 23:44:09 -0700 Subject: [PATCH 06/43] Name the web files lane G released in the Wave 2 table (#145) Co-Authored-By: Claude Opus 5.5 --- docs/designs/codeboost-plan-indexed-review.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/designs/codeboost-plan-indexed-review.md b/docs/designs/codeboost-plan-indexed-review.md index 363756eb..417858fe 100644 --- a/docs/designs/codeboost-plan-indexed-review.md +++ b/docs/designs/codeboost-plan-indexed-review.md @@ -1951,7 +1951,7 @@ Read each row left to right: finish and validate step 1 before step 2 within tha | Lane | Prerequisites | Scope / ownership | Completion check | |---|---|---|---| | F — runner and pre-merge automation | C and D merged; invocation contract available | Build step 5 runner plus #22 / remaining build step 4; T3, T6, T11. Own `runner/`, rebase helpers and shared acceptance persistence during this wave. | Preserve ledger attribution through rebase; recompute approval staleness; execute and persist head-bound checks; cover timeout, cancellation, shutdown and collaborator-push races; complete #22 acceptance. | -| G — planning screen | Done: G1–G4 (#145; PRs #148, #150, #151, #152) | Build step 6 UI and T18 integration. Owned `web/` and dedicated browser tests during this wave; released them after G4 (see `docs/implementation/planning-screen.md`). Route persistence changes through F. UI work can use controlled provider fixtures until D is available. | Import, generation and Apply preserve user drafts and attachments and reject stale/replayed suggestions. Final completion requires real D-backed invocation and integration with F/store, not fixtures alone. Done. | +| G — planning screen | Done: G1–G4 (#145; PRs #148, #150, #151, #152) | Build step 6 UI and T18 integration. Owned the Plans screen files in `web/public/` and dedicated browser tests during this wave, and released them after G4; `web/server.ts` stays with F (see `docs/implementation/planning-screen.md`). Route persistence changes through F. UI work can use controlled provider fixtures until D is available. | Import, generation and Apply preserve user drafts and attachments and reject stale/replayed suggestions. Final completion requires real D-backed invocation and integration with F/store, not fixtures alone. Done. | | H — issue prioritization | Done: access contract and ranking policy (H1); retrieval/ranking (#39, #42); Issues screen (#55); author-bound trust, runner/publish guards, prompt comment evidence, and trust controls (#108, PR #139) | Build step 8: issue retrieval, normalization, ranking, and trust enforcement with dedicated unit, integration, and browser tests. | Done. Stable ranking has visible reasons and explicit unavailable/stale states; H4b persists trust, fails closed at runner and publishing boundaries, controls comment inclusion, records delivered comment evidence, and works in demo mode. | F, G and H can proceed together within these ownership boundaries. If F and G need an incompatible shared storage/API change, land that small prerequisite first; neither edits the other's files in parallel. Merge independent backend modules first, then their shared integration, and rerun checks on the combined head. From 7adcb1b3c0ccce06414e0cd097948aabf719b605 Mon Sep 17 00:00:00 2001 From: mchwang Date: Fri, 9 Oct 2026 23:45:03 -0700 Subject: [PATCH 07/43] Put the finished lane G row in the past tense (#145) Co-Authored-By: Claude Opus 5.5 --- docs/designs/codeboost-plan-indexed-review.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/designs/codeboost-plan-indexed-review.md b/docs/designs/codeboost-plan-indexed-review.md index 417858fe..8891ef37 100644 --- a/docs/designs/codeboost-plan-indexed-review.md +++ b/docs/designs/codeboost-plan-indexed-review.md @@ -1951,7 +1951,7 @@ Read each row left to right: finish and validate step 1 before step 2 within tha | Lane | Prerequisites | Scope / ownership | Completion check | |---|---|---|---| | F — runner and pre-merge automation | C and D merged; invocation contract available | Build step 5 runner plus #22 / remaining build step 4; T3, T6, T11. Own `runner/`, rebase helpers and shared acceptance persistence during this wave. | Preserve ledger attribution through rebase; recompute approval staleness; execute and persist head-bound checks; cover timeout, cancellation, shutdown and collaborator-push races; complete #22 acceptance. | -| G — planning screen | Done: G1–G4 (#145; PRs #148, #150, #151, #152) | Build step 6 UI and T18 integration. Owned the Plans screen files in `web/public/` and dedicated browser tests during this wave, and released them after G4; `web/server.ts` stays with F (see `docs/implementation/planning-screen.md`). Route persistence changes through F. UI work can use controlled provider fixtures until D is available. | Import, generation and Apply preserve user drafts and attachments and reject stale/replayed suggestions. Final completion requires real D-backed invocation and integration with F/store, not fixtures alone. Done. | +| G — planning screen | Done: G1–G4 (#145; PRs #148, #150, #151, #152) | Build step 6 UI and T18 integration. During this wave G owned the shared screen files `web/public/index.html`, `app.js` and `style.css` and the Plans browser tests, and released them after G4; `web/server.ts` stayed with F (see `docs/implementation/planning-screen.md`). Persistence changes went through F, and G1–G3 used controlled provider fixtures. | Import, generation and Apply preserve user drafts and attachments and reject stale/replayed suggestions. Final completion requires real D-backed invocation and integration with F/store, not fixtures alone. Done. | | H — issue prioritization | Done: access contract and ranking policy (H1); retrieval/ranking (#39, #42); Issues screen (#55); author-bound trust, runner/publish guards, prompt comment evidence, and trust controls (#108, PR #139) | Build step 8: issue retrieval, normalization, ranking, and trust enforcement with dedicated unit, integration, and browser tests. | Done. Stable ranking has visible reasons and explicit unavailable/stale states; H4b persists trust, fails closed at runner and publishing boundaries, controls comment inclusion, records delivered comment evidence, and works in demo mode. | F, G and H can proceed together within these ownership boundaries. If F and G need an incompatible shared storage/API change, land that small prerequisite first; neither edits the other's files in parallel. Merge independent backend modules first, then their shared integration, and rerun checks on the combined head. From 7eb87ec6ee8cac33f345d736f00f81f0ec5072fd Mon Sep 17 00:00:00 2001 From: mchwang Date: Fri, 9 Oct 2026 23:46:07 -0700 Subject: [PATCH 08/43] Drop unneeded history from the lane G row (#145) Co-Authored-By: Claude Opus 5.5 --- docs/designs/codeboost-plan-indexed-review.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/designs/codeboost-plan-indexed-review.md b/docs/designs/codeboost-plan-indexed-review.md index 8891ef37..39f22bfc 100644 --- a/docs/designs/codeboost-plan-indexed-review.md +++ b/docs/designs/codeboost-plan-indexed-review.md @@ -1951,7 +1951,7 @@ Read each row left to right: finish and validate step 1 before step 2 within tha | Lane | Prerequisites | Scope / ownership | Completion check | |---|---|---|---| | F — runner and pre-merge automation | C and D merged; invocation contract available | Build step 5 runner plus #22 / remaining build step 4; T3, T6, T11. Own `runner/`, rebase helpers and shared acceptance persistence during this wave. | Preserve ledger attribution through rebase; recompute approval staleness; execute and persist head-bound checks; cover timeout, cancellation, shutdown and collaborator-push races; complete #22 acceptance. | -| G — planning screen | Done: G1–G4 (#145; PRs #148, #150, #151, #152) | Build step 6 UI and T18 integration. During this wave G owned the shared screen files `web/public/index.html`, `app.js` and `style.css` and the Plans browser tests, and released them after G4; `web/server.ts` stayed with F (see `docs/implementation/planning-screen.md`). Persistence changes went through F, and G1–G3 used controlled provider fixtures. | Import, generation and Apply preserve user drafts and attachments and reject stale/replayed suggestions. Final completion requires real D-backed invocation and integration with F/store, not fixtures alone. Done. | +| G — planning screen | Done: G1–G4 (#145; PRs #148, #150, #151, #152) | Build step 6 UI and T18 integration. During this wave G owned the shared screen files `web/public/index.html`, `app.js` and `style.css` and the Plans browser tests, and released them after G4; `web/server.ts` stayed with F (see `docs/implementation/planning-screen.md`). | Import, generation and Apply preserve user drafts and attachments and reject stale/replayed suggestions. Final completion requires real D-backed invocation and integration with F/store, not fixtures alone. Done. | | H — issue prioritization | Done: access contract and ranking policy (H1); retrieval/ranking (#39, #42); Issues screen (#55); author-bound trust, runner/publish guards, prompt comment evidence, and trust controls (#108, PR #139) | Build step 8: issue retrieval, normalization, ranking, and trust enforcement with dedicated unit, integration, and browser tests. | Done. Stable ranking has visible reasons and explicit unavailable/stale states; H4b persists trust, fails closed at runner and publishing boundaries, controls comment inclusion, records delivered comment evidence, and works in demo mode. | F, G and H can proceed together within these ownership boundaries. If F and G need an incompatible shared storage/API change, land that small prerequisite first; neither edits the other's files in parallel. Merge independent backend modules first, then their shared integration, and rerun checks on the combined head. From 6b1fe462646d0a3d302b51415d2beb75f55c444f Mon Sep 17 00:00:00 2001 From: mchwang Date: Fri, 9 Oct 2026 23:47:03 -0700 Subject: [PATCH 09/43] Match the H row layout; cite where #146 is assigned to lane F (#145) Co-Authored-By: Claude Opus 5.5 --- docs/designs/codeboost-plan-indexed-review.md | 2 +- docs/implementation/planning-screen.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/designs/codeboost-plan-indexed-review.md b/docs/designs/codeboost-plan-indexed-review.md index 39f22bfc..a7dc7819 100644 --- a/docs/designs/codeboost-plan-indexed-review.md +++ b/docs/designs/codeboost-plan-indexed-review.md @@ -1951,7 +1951,7 @@ Read each row left to right: finish and validate step 1 before step 2 within tha | Lane | Prerequisites | Scope / ownership | Completion check | |---|---|---|---| | F — runner and pre-merge automation | C and D merged; invocation contract available | Build step 5 runner plus #22 / remaining build step 4; T3, T6, T11. Own `runner/`, rebase helpers and shared acceptance persistence during this wave. | Preserve ledger attribution through rebase; recompute approval staleness; execute and persist head-bound checks; cover timeout, cancellation, shutdown and collaborator-push races; complete #22 acceptance. | -| G — planning screen | Done: G1–G4 (#145; PRs #148, #150, #151, #152) | Build step 6 UI and T18 integration. During this wave G owned the shared screen files `web/public/index.html`, `app.js` and `style.css` and the Plans browser tests, and released them after G4; `web/server.ts` stayed with F (see `docs/implementation/planning-screen.md`). | Import, generation and Apply preserve user drafts and attachments and reject stale/replayed suggestions. Final completion requires real D-backed invocation and integration with F/store, not fixtures alone. Done. | +| G — planning screen | Done: G1–G4 (#145; PRs #148, #150, #151, #152) | Build step 6 UI and T18 integration. During this wave G owned the shared screen files `web/public/index.html`, `app.js` and `style.css` and the Plans browser tests, and released them after G4; `web/server.ts` stayed with F (see `docs/implementation/planning-screen.md`). | Done. Import, generation and Apply preserve user drafts and attachments and reject stale/replayed suggestions. Final completion requires real D-backed invocation and integration with F/store, not fixtures alone. | | H — issue prioritization | Done: access contract and ranking policy (H1); retrieval/ranking (#39, #42); Issues screen (#55); author-bound trust, runner/publish guards, prompt comment evidence, and trust controls (#108, PR #139) | Build step 8: issue retrieval, normalization, ranking, and trust enforcement with dedicated unit, integration, and browser tests. | Done. Stable ranking has visible reasons and explicit unavailable/stale states; H4b persists trust, fails closed at runner and publishing boundaries, controls comment inclusion, records delivered comment evidence, and works in demo mode. | F, G and H can proceed together within these ownership boundaries. If F and G need an incompatible shared storage/API change, land that small prerequisite first; neither edits the other's files in parallel. Merge independent backend modules first, then their shared integration, and rerun checks on the combined head. diff --git a/docs/implementation/planning-screen.md b/docs/implementation/planning-screen.md index 51cc7a8a..f226f75d 100644 --- a/docs/implementation/planning-screen.md +++ b/docs/implementation/planning-screen.md @@ -40,4 +40,4 @@ Suggestion replies render as plain text followed by one line-separated row per t G1–G4 have merged as PRs #148, #150, #151 and #152, which completes lane G (#145). Lane G no longer owns `web/public/index.html`, `web/public/app.js`, `web/public/style.css`, `test/browser/plans.spec.ts`, `test/browser/plans-authoring.spec.ts`, `test/browser/plans-production.spec.ts` or this document. G3 also edited `web/server.ts` and `test/planning-drafts-api.test.ts`; those stay with lane F, which owns the server contract. Before the next change to any file named above, follow "Task resumption and ownership" in `AGENTS.md`: check open PRs, branches and worktrees first. -One related issue remains open. #146: `POST /api/plan/import` refuses request bodies over 16 KiB, but some schema-valid plans are larger. The fix is to raise the server's request limit, or to tighten the schema or import bound so the two agree. The screen needs no change. #146 and the #145 progress notes record it as lane F's work. +One related issue remains open. #146: `POST /api/plan/import` refuses request bodies over 16 KiB, but some schema-valid plans are larger. The fix is to raise the server's request limit, or to tighten the schema or import bound so the two agree. The screen needs no change. The #145 progress notes record #146 as lane F's work, because `web/server.ts` is an F-owned server contract. From 19cf519898bccd16aee382259fa925afdd151d00 Mon Sep 17 00:00:00 2001 From: mchwang Date: Fri, 9 Oct 2026 23:47:59 -0700 Subject: [PATCH 10/43] README: planning agent needs a github review, not the demo (#145) Co-Authored-By: Claude Opus 5.5 --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 95eeec9e..43d43416 100644 --- a/README.md +++ b/README.md @@ -2,7 +2,7 @@ Review agent-made Git changes one plan item at a time. The approved plan lists each item's files and acceptance checks; the review engine shows which item produced each change and flags foreign or overlapping work. -**Status:** the plan/linking library, SQLite store, local review screen, Plans screen (plan import, agent drafts and suggestions, revision-bound Apply), opt-in code-writing runner, durable local rebase, and exact-head plan command checks are implemented. Run `npm run demo` and open its private local URL. Ask and the runner use Claude Code inside locked-down containers; Codex is refused because it reads code only by running commands ([why](docs/implementation/agent-isolation.md#codex-is-refused-in-every-phase)). They need Docker, plus `CLAUDE_CODE_OAUTH_TOKEN` (from `claude setup-token`). Startup builds the agent image, which can take a few minutes. A configured GitHub review can merge only after the guarded exact-head gate passes. The agent container, vendor-only network, credential-free command-check profile, and Claude/Codex adapters are described in [agent isolation](docs/implementation/agent-isolation.md). Pushing a rebased head, waiting for its required checks, and handing that exact pair to guarded merge remain follow-up work. The paired human review experiment was cancelled before results were recorded and no longer blocks roadmap work; optional future validation is tracked in [#19](https://github.com/codeabovelab/codeboost/issues/19). +**Status:** the plan/linking library, SQLite store, local review screen, Plans screen (plan import and revision-bound Apply; agent drafts and suggestions need a configured `github` review, not the demo), opt-in code-writing runner, durable local rebase, and exact-head plan command checks are implemented. Run `npm run demo` and open its private local URL. Ask, planning and the runner use Claude Code inside locked-down containers; Codex is refused because it reads code only by running commands ([why](docs/implementation/agent-isolation.md#codex-is-refused-in-every-phase)). They need Docker, plus `CLAUDE_CODE_OAUTH_TOKEN` (from `claude setup-token`). Startup builds the agent image, which can take a few minutes. A configured GitHub review can merge only after the guarded exact-head gate passes. The agent container, vendor-only network, credential-free command-check profile, and Claude/Codex adapters are described in [agent isolation](docs/implementation/agent-isolation.md). Pushing a rebased head, waiting for its required checks, and handing that exact pair to guarded merge remain follow-up work. The paired human review experiment was cancelled before results were recorded and no longer blocks roadmap work; optional future validation is tracked in [#19](https://github.com/codeabovelab/codeboost/issues/19). ## Development From 520432615ce2bad82fc8c69cf5e30e225afc2403 Mon Sep 17 00:00:00 2001 From: mchwang Date: Fri, 9 Oct 2026 23:48:48 -0700 Subject: [PATCH 11/43] Clarify met G4 condition and demo limits (#145) Co-Authored-By: Claude Opus 5.5 --- README.md | 2 +- docs/designs/codeboost-plan-indexed-review.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 43d43416..55af6a7c 100644 --- a/README.md +++ b/README.md @@ -2,7 +2,7 @@ Review agent-made Git changes one plan item at a time. The approved plan lists each item's files and acceptance checks; the review engine shows which item produced each change and flags foreign or overlapping work. -**Status:** the plan/linking library, SQLite store, local review screen, Plans screen (plan import and revision-bound Apply; agent drafts and suggestions need a configured `github` review, not the demo), opt-in code-writing runner, durable local rebase, and exact-head plan command checks are implemented. Run `npm run demo` and open its private local URL. Ask, planning and the runner use Claude Code inside locked-down containers; Codex is refused because it reads code only by running commands ([why](docs/implementation/agent-isolation.md#codex-is-refused-in-every-phase)). They need Docker, plus `CLAUDE_CODE_OAUTH_TOKEN` (from `claude setup-token`). Startup builds the agent image, which can take a few minutes. A configured GitHub review can merge only after the guarded exact-head gate passes. The agent container, vendor-only network, credential-free command-check profile, and Claude/Codex adapters are described in [agent isolation](docs/implementation/agent-isolation.md). Pushing a rebased head, waiting for its required checks, and handing that exact pair to guarded merge remain follow-up work. The paired human review experiment was cancelled before results were recorded and no longer blocks roadmap work; optional future validation is tracked in [#19](https://github.com/codeabovelab/codeboost/issues/19). +**Status:** the plan/linking library, SQLite store, local review screen, Plans screen (plan import, plus agent drafts and suggestions with revision-bound Apply; drafts and suggestions need a configured `github` review, not the demo), opt-in code-writing runner, durable local rebase, and exact-head plan command checks are implemented. Run `npm run demo` and open its private local URL. Ask, planning and the runner use Claude Code inside locked-down containers; Codex is refused because it reads code only by running commands ([why](docs/implementation/agent-isolation.md#codex-is-refused-in-every-phase)). They need Docker, plus `CLAUDE_CODE_OAUTH_TOKEN` (from `claude setup-token`). Startup builds the agent image, which can take a few minutes. A configured GitHub review can merge only after the guarded exact-head gate passes. The agent container, vendor-only network, credential-free command-check profile, and Claude/Codex adapters are described in [agent isolation](docs/implementation/agent-isolation.md). Pushing a rebased head, waiting for its required checks, and handing that exact pair to guarded merge remain follow-up work. The paired human review experiment was cancelled before results were recorded and no longer blocks roadmap work; optional future validation is tracked in [#19](https://github.com/codeabovelab/codeboost/issues/19). ## Development diff --git a/docs/designs/codeboost-plan-indexed-review.md b/docs/designs/codeboost-plan-indexed-review.md index a7dc7819..87ae2297 100644 --- a/docs/designs/codeboost-plan-indexed-review.md +++ b/docs/designs/codeboost-plan-indexed-review.md @@ -1951,7 +1951,7 @@ Read each row left to right: finish and validate step 1 before step 2 within tha | Lane | Prerequisites | Scope / ownership | Completion check | |---|---|---|---| | F — runner and pre-merge automation | C and D merged; invocation contract available | Build step 5 runner plus #22 / remaining build step 4; T3, T6, T11. Own `runner/`, rebase helpers and shared acceptance persistence during this wave. | Preserve ledger attribution through rebase; recompute approval staleness; execute and persist head-bound checks; cover timeout, cancellation, shutdown and collaborator-push races; complete #22 acceptance. | -| G — planning screen | Done: G1–G4 (#145; PRs #148, #150, #151, #152) | Build step 6 UI and T18 integration. During this wave G owned the shared screen files `web/public/index.html`, `app.js` and `style.css` and the Plans browser tests, and released them after G4; `web/server.ts` stayed with F (see `docs/implementation/planning-screen.md`). | Done. Import, generation and Apply preserve user drafts and attachments and reject stale/replayed suggestions. Final completion requires real D-backed invocation and integration with F/store, not fixtures alone. | +| G — planning screen | Done: G1–G4 (#145; PRs #148, #150, #151, #152) | Build step 6 UI and T18 integration. During this wave G owned the shared screen files `web/public/index.html`, `app.js` and `style.css` and the Plans browser tests, and released them after G4; `web/server.ts` stayed with F (see `docs/implementation/planning-screen.md`). | Done. Import, generation and Apply preserve user drafts and attachments and reject stale/replayed suggestions. G4 (PR #152) met the final condition: real D-backed invocation and integration with F/store, not fixtures alone. | | H — issue prioritization | Done: access contract and ranking policy (H1); retrieval/ranking (#39, #42); Issues screen (#55); author-bound trust, runner/publish guards, prompt comment evidence, and trust controls (#108, PR #139) | Build step 8: issue retrieval, normalization, ranking, and trust enforcement with dedicated unit, integration, and browser tests. | Done. Stable ranking has visible reasons and explicit unavailable/stale states; H4b persists trust, fails closed at runner and publishing boundaries, controls comment inclusion, records delivered comment evidence, and works in demo mode. | F, G and H can proceed together within these ownership boundaries. If F and G need an incompatible shared storage/API change, land that small prerequisite first; neither edits the other's files in parallel. Merge independent backend modules first, then their shared integration, and rerun checks on the combined head. From 79e56c7ff44bd64668cb6c084ce990e9949a6599 Mon Sep 17 00:00:00 2001 From: mchwang Date: Fri, 9 Oct 2026 23:56:23 -0700 Subject: [PATCH 12/43] Put wave 2 ownership rules in the past tense (#145) Copilot round 1 found that the Wave 2 note and integration rule 2 still gave G active ownership of web files the handoff says were released. Co-Authored-By: Claude Opus 5.5 --- docs/designs/codeboost-plan-indexed-review.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/designs/codeboost-plan-indexed-review.md b/docs/designs/codeboost-plan-indexed-review.md index 87ae2297..c9c52400 100644 --- a/docs/designs/codeboost-plan-indexed-review.md +++ b/docs/designs/codeboost-plan-indexed-review.md @@ -1954,7 +1954,7 @@ Read each row left to right: finish and validate step 1 before step 2 within tha | G — planning screen | Done: G1–G4 (#145; PRs #148, #150, #151, #152) | Build step 6 UI and T18 integration. During this wave G owned the shared screen files `web/public/index.html`, `app.js` and `style.css` and the Plans browser tests, and released them after G4; `web/server.ts` stayed with F (see `docs/implementation/planning-screen.md`). | Done. Import, generation and Apply preserve user drafts and attachments and reject stale/replayed suggestions. G4 (PR #152) met the final condition: real D-backed invocation and integration with F/store, not fixtures alone. | | H — issue prioritization | Done: access contract and ranking policy (H1); retrieval/ranking (#39, #42); Issues screen (#55); author-bound trust, runner/publish guards, prompt comment evidence, and trust controls (#108, PR #139) | Build step 8: issue retrieval, normalization, ranking, and trust enforcement with dedicated unit, integration, and browser tests. | Done. Stable ranking has visible reasons and explicit unavailable/stale states; H4b persists trust, fails closed at runner and publishing boundaries, controls comment inclusion, records delivered comment evidence, and works in demo mode. | -F, G and H can proceed together within these ownership boundaries. If F and G need an incompatible shared storage/API change, land that small prerequisite first; neither edits the other's files in parallel. Merge independent backend modules first, then their shared integration, and rerun checks on the combined head. +F, G and H ran together within these ownership boundaries. G and H are done; for the current state of each lane, see `docs/architecture.md`. If two lanes need an incompatible shared storage/API change, land that small prerequisite first; neither edits the other's files in parallel. Merge independent backend modules first, then their shared integration, and rerun checks on the combined head. #### Wave 3: lifecycle features and learning @@ -1967,7 +1967,7 @@ F, G and H can proceed together within these ownership boundaries. If F and G ne #### Ownership and integration rules 1. Each task uses its own branch/worktree from current remote main or a documented prerequisite branch. Record its issue, milestone, T-IDs, dependencies, owner and exact files in the PR. Delegated reviewers report findings; the implementation task's main agent owns its writes. -2. One integration owner controls `runner/store.ts`, shared runner/review wiring, `web/server.ts`, `web/cli.ts`, `web/public/app.js`, `web/public/index.html`, `web/public/style.css`, shared browser fixtures, package manifests/lockfiles, schema registry and common CI configuration. C holds this ownership first; in wave 2 F owns runner/storage and G owns web. C owns common configuration in wave 1 and hands it to F before F1; D exclusively owns the new `.github/workflows/agent-isolation.yml`. D must route changes to existing `.github/workflows/ci.yml`, package scripts or lockfiles through the common-configuration owner. Separate worktrees do not remove this constraint. +2. One integration owner controls `runner/store.ts`, shared runner/review wiring, `web/server.ts`, `web/cli.ts`, `web/public/app.js`, `web/public/index.html`, `web/public/style.css`, shared browser fixtures, package manifests/lockfiles, schema registry and common CI configuration. C held this ownership first. In wave 2, F owned runner/storage and the server contract, and G owned the shared screen files until it released them after G4 (#145). Before editing any of these files now, find the current owner as described in "Task resumption and ownership" in `AGENTS.md`. C owns common configuration in wave 1 and hands it to F before F1; D exclusively owns the new `.github/workflows/agent-isolation.yml`. D must route changes to existing `.github/workflows/ci.yml`, package scripts or lockfiles through the common-configuration owner. Separate worktrees do not remove this constraint. 3. Keep this plan under one documentation owner. Lane owners record detailed progress and review rounds in their own issues/PRs; the documentation owner updates milestone status after integration. Never check off a milestone because only one parallel increment landed. 4. A blocked integration does not block disjoint modules or fixture work, but those tasks must report the missing production integration. No stub provider, skipped Docker test or mocked merge outcome counts as completed production behavior. 5. Every lane runs its targeted acceptance checks and required regressions. After its final integration change, rerun typecheck, unit/integration tests and applicable browser/Docker checks against the exact pushed head. Complete automated review and the review-lesson audit before an authorized merge. Revalidate downstream work after prerequisite changes. From b3601d837a2f4b985ce8a69266e6916c317930df Mon Sep 17 00:00:00 2001 From: mchwang Date: Fri, 9 Oct 2026 23:57:32 -0700 Subject: [PATCH 13/43] Record where H4a's web files went after G1 (#145) Co-Authored-By: Claude Opus 5.5 --- docs/implementation/issue-prioritization.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/implementation/issue-prioritization.md b/docs/implementation/issue-prioritization.md index 596b2f09..665bdb4f 100644 --- a/docs/implementation/issue-prioritization.md +++ b/docs/implementation/issue-prioritization.md @@ -85,7 +85,9 @@ them now, split in two: - **H4a (this change): the Issues screen.** It owns `web/server.ts`, `web/public/*`, a new `web/issues.ts`, the demo fixture `scripts/demo-issues.ts` and their tests. It does not edit `runner/store.ts`. - It hands the web files to G when G1 starts. + When G1 started, it handed `web/public/*` to G; #145 kept server-contract + changes in `web/server.ts` with F. G released its files after G4 (see + `docs/implementation/planning-screen.md`). - **H4b: the "trust this issue" action.** It records trust decisions through the storage owner (F) after F1's Store changes land, so the two lanes do not both bump the schema version. From 746d3f2389632d896d635e59a00ecc77fe4e6010 Mon Sep 17 00:00:00 2001 From: mchwang Date: Fri, 9 Oct 2026 23:58:46 -0700 Subject: [PATCH 14/43] Name G3's one web/server.ts change in the handoff records (#145) Co-Authored-By: Claude Opus 5.5 --- docs/designs/codeboost-plan-indexed-review.md | 2 +- docs/implementation/issue-prioritization.md | 5 +++-- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/docs/designs/codeboost-plan-indexed-review.md b/docs/designs/codeboost-plan-indexed-review.md index c9c52400..5fd7946c 100644 --- a/docs/designs/codeboost-plan-indexed-review.md +++ b/docs/designs/codeboost-plan-indexed-review.md @@ -1951,7 +1951,7 @@ Read each row left to right: finish and validate step 1 before step 2 within tha | Lane | Prerequisites | Scope / ownership | Completion check | |---|---|---|---| | F — runner and pre-merge automation | C and D merged; invocation contract available | Build step 5 runner plus #22 / remaining build step 4; T3, T6, T11. Own `runner/`, rebase helpers and shared acceptance persistence during this wave. | Preserve ledger attribution through rebase; recompute approval staleness; execute and persist head-bound checks; cover timeout, cancellation, shutdown and collaborator-push races; complete #22 acceptance. | -| G — planning screen | Done: G1–G4 (#145; PRs #148, #150, #151, #152) | Build step 6 UI and T18 integration. During this wave G owned the shared screen files `web/public/index.html`, `app.js` and `style.css` and the Plans browser tests, and released them after G4; `web/server.ts` stayed with F (see `docs/implementation/planning-screen.md`). | Done. Import, generation and Apply preserve user drafts and attachments and reject stale/replayed suggestions. G4 (PR #152) met the final condition: real D-backed invocation and integration with F/store, not fixtures alone. | +| G — planning screen | Done: G1–G4 (#145; PRs #148, #150, #151, #152) | Build step 6 UI and T18 integration. During this wave G owned the shared screen files `web/public/index.html`, `app.js` and `style.css` and the Plans browser tests, and released them after G4. `web/server.ts` is F's server contract; G3 changed it once, to return 503 with `outcomeUnknown` for unrecorded SQLite errors (PR #151) (see `docs/implementation/planning-screen.md`). | Done. Import, generation and Apply preserve user drafts and attachments and reject stale/replayed suggestions. G4 (PR #152) met the final condition: real D-backed invocation and integration with F/store, not fixtures alone. | | H — issue prioritization | Done: access contract and ranking policy (H1); retrieval/ranking (#39, #42); Issues screen (#55); author-bound trust, runner/publish guards, prompt comment evidence, and trust controls (#108, PR #139) | Build step 8: issue retrieval, normalization, ranking, and trust enforcement with dedicated unit, integration, and browser tests. | Done. Stable ranking has visible reasons and explicit unavailable/stale states; H4b persists trust, fails closed at runner and publishing boundaries, controls comment inclusion, records delivered comment evidence, and works in demo mode. | F, G and H ran together within these ownership boundaries. G and H are done; for the current state of each lane, see `docs/architecture.md`. If two lanes need an incompatible shared storage/API change, land that small prerequisite first; neither edits the other's files in parallel. Merge independent backend modules first, then their shared integration, and rerun checks on the combined head. diff --git a/docs/implementation/issue-prioritization.md b/docs/implementation/issue-prioritization.md index 665bdb4f..dd9b333f 100644 --- a/docs/implementation/issue-prioritization.md +++ b/docs/implementation/issue-prioritization.md @@ -85,8 +85,9 @@ them now, split in two: - **H4a (this change): the Issues screen.** It owns `web/server.ts`, `web/public/*`, a new `web/issues.ts`, the demo fixture `scripts/demo-issues.ts` and their tests. It does not edit `runner/store.ts`. - When G1 started, it handed `web/public/*` to G; #145 kept server-contract - changes in `web/server.ts` with F. G released its files after G4 (see + When G1 started, it handed `web/public/*` to G. #145 treated `web/server.ts` + as F's server contract; G3 still changed it once (PR #151). G released its + files after G4 (see `docs/implementation/planning-screen.md`). - **H4b: the "trust this issue" action.** It records trust decisions through the storage owner (F) after F1's Store changes land, so the two lanes do not From 98f297b8c5cafe07bd04736b7a2e59a98bfe4690 Mon Sep 17 00:00:00 2001 From: mchwang Date: Sat, 10 Oct 2026 00:00:13 -0700 Subject: [PATCH 15/43] Put the H4a ownership bullet in the past tense (#145) Co-Authored-By: Claude Opus 5.5 --- docs/implementation/issue-prioritization.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/docs/implementation/issue-prioritization.md b/docs/implementation/issue-prioritization.md index dd9b333f..2e754dee 100644 --- a/docs/implementation/issue-prioritization.md +++ b/docs/implementation/issue-prioritization.md @@ -82,13 +82,12 @@ to wait for G4 to release the shared web files. G cannot start until E4 merges, and E4 waits for D5, so the web files had no active owner. H4 therefore takes them now, split in two: -- **H4a (this change): the Issues screen.** It owns `web/server.ts`, +- **H4a (#55): the Issues screen.** It owned `web/server.ts`, `web/public/*`, a new `web/issues.ts`, the demo fixture - `scripts/demo-issues.ts` and their tests. It does not edit `runner/store.ts`. - When G1 started, it handed `web/public/*` to G. #145 treated `web/server.ts` - as F's server contract; G3 still changed it once (PR #151). G released its - files after G4 (see - `docs/implementation/planning-screen.md`). + `scripts/demo-issues.ts` and their tests. It did not edit `runner/store.ts`. + When G1 started, H4a handed `web/public/*` to G, and `web/server.ts` passed + to F as the server contract (#145); G3 changed it once (PR #151). G released + its files after G4 (see `docs/implementation/planning-screen.md`). - **H4b: the "trust this issue" action.** It records trust decisions through the storage owner (F) after F1's Store changes land, so the two lanes do not both bump the schema version. From 4ae4a8aa58d864bfb2355acac179ce656bdf2468 Mon Sep 17 00:00:00 2001 From: mchwang Date: Sat, 10 Oct 2026 00:01:26 -0700 Subject: [PATCH 16/43] Name F's wave 2 server files in integration rule 2 (#145) Co-Authored-By: Claude Opus 5.5 --- docs/designs/codeboost-plan-indexed-review.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/designs/codeboost-plan-indexed-review.md b/docs/designs/codeboost-plan-indexed-review.md index 5fd7946c..f8eb7514 100644 --- a/docs/designs/codeboost-plan-indexed-review.md +++ b/docs/designs/codeboost-plan-indexed-review.md @@ -1967,7 +1967,7 @@ F, G and H ran together within these ownership boundaries. G and H are done; for #### Ownership and integration rules 1. Each task uses its own branch/worktree from current remote main or a documented prerequisite branch. Record its issue, milestone, T-IDs, dependencies, owner and exact files in the PR. Delegated reviewers report findings; the implementation task's main agent owns its writes. -2. One integration owner controls `runner/store.ts`, shared runner/review wiring, `web/server.ts`, `web/cli.ts`, `web/public/app.js`, `web/public/index.html`, `web/public/style.css`, shared browser fixtures, package manifests/lockfiles, schema registry and common CI configuration. C held this ownership first. In wave 2, F owned runner/storage and the server contract, and G owned the shared screen files until it released them after G4 (#145). Before editing any of these files now, find the current owner as described in "Task resumption and ownership" in `AGENTS.md`. C owns common configuration in wave 1 and hands it to F before F1; D exclusively owns the new `.github/workflows/agent-isolation.yml`. D must route changes to existing `.github/workflows/ci.yml`, package scripts or lockfiles through the common-configuration owner. Separate worktrees do not remove this constraint. +2. One integration owner controls `runner/store.ts`, shared runner/review wiring, `web/server.ts`, `web/cli.ts`, `web/public/app.js`, `web/public/index.html`, `web/public/style.css`, shared browser fixtures, package manifests/lockfiles, schema registry and common CI configuration. C held this ownership first. In wave 2, F owned runner/storage and the server wiring (`web/server.ts`, `web/cli.ts`), and G owned the shared screen files until it released them after G4 (#145). Before editing any of these files now, find the current owner as described in "Task resumption and ownership" in `AGENTS.md`. C owns common configuration in wave 1 and hands it to F before F1; D exclusively owns the new `.github/workflows/agent-isolation.yml`. D must route changes to existing `.github/workflows/ci.yml`, package scripts or lockfiles through the common-configuration owner. Separate worktrees do not remove this constraint. 3. Keep this plan under one documentation owner. Lane owners record detailed progress and review rounds in their own issues/PRs; the documentation owner updates milestone status after integration. Never check off a milestone because only one parallel increment landed. 4. A blocked integration does not block disjoint modules or fixture work, but those tasks must report the missing production integration. No stub provider, skipped Docker test or mocked merge outcome counts as completed production behavior. 5. Every lane runs its targeted acceptance checks and required regressions. After its final integration change, rerun typecheck, unit/integration tests and applicable browser/Docker checks against the exact pushed head. Complete automated review and the review-lesson audit before an authorized merge. Revalidate downstream work after prerequisite changes. From 3acf0ec6fc08b977d2f81a212db67a14e5b67662 Mon Sep 17 00:00:00 2001 From: mchwang Date: Sat, 10 Oct 2026 00:02:35 -0700 Subject: [PATCH 17/43] Remove unneeded ownership history; quote the AGENTS.md rule (#145) Co-Authored-By: Claude Opus 5.5 --- docs/designs/codeboost-plan-indexed-review.md | 4 ++-- docs/implementation/issue-prioritization.md | 5 ++--- 2 files changed, 4 insertions(+), 5 deletions(-) diff --git a/docs/designs/codeboost-plan-indexed-review.md b/docs/designs/codeboost-plan-indexed-review.md index f8eb7514..00afacb7 100644 --- a/docs/designs/codeboost-plan-indexed-review.md +++ b/docs/designs/codeboost-plan-indexed-review.md @@ -1951,7 +1951,7 @@ Read each row left to right: finish and validate step 1 before step 2 within tha | Lane | Prerequisites | Scope / ownership | Completion check | |---|---|---|---| | F — runner and pre-merge automation | C and D merged; invocation contract available | Build step 5 runner plus #22 / remaining build step 4; T3, T6, T11. Own `runner/`, rebase helpers and shared acceptance persistence during this wave. | Preserve ledger attribution through rebase; recompute approval staleness; execute and persist head-bound checks; cover timeout, cancellation, shutdown and collaborator-push races; complete #22 acceptance. | -| G — planning screen | Done: G1–G4 (#145; PRs #148, #150, #151, #152) | Build step 6 UI and T18 integration. During this wave G owned the shared screen files `web/public/index.html`, `app.js` and `style.css` and the Plans browser tests, and released them after G4. `web/server.ts` is F's server contract; G3 changed it once, to return 503 with `outcomeUnknown` for unrecorded SQLite errors (PR #151) (see `docs/implementation/planning-screen.md`). | Done. Import, generation and Apply preserve user drafts and attachments and reject stale/replayed suggestions. G4 (PR #152) met the final condition: real D-backed invocation and integration with F/store, not fixtures alone. | +| G — planning screen | Done: G1–G4 (#145; PRs #148, #150, #151, #152) | Build step 6 UI and T18 integration. During this wave G owned the shared screen files `web/public/index.html`, `app.js` and `style.css` and the Plans browser tests, and released them after G4. `web/server.ts` is F's server contract; G3 changed it once (PR #151) (see `docs/implementation/planning-screen.md`). | Done. Import, generation and Apply preserve user drafts and attachments and reject stale/replayed suggestions. G4 (PR #152) met the final condition: real D-backed invocation and integration with F/store, not fixtures alone. | | H — issue prioritization | Done: access contract and ranking policy (H1); retrieval/ranking (#39, #42); Issues screen (#55); author-bound trust, runner/publish guards, prompt comment evidence, and trust controls (#108, PR #139) | Build step 8: issue retrieval, normalization, ranking, and trust enforcement with dedicated unit, integration, and browser tests. | Done. Stable ranking has visible reasons and explicit unavailable/stale states; H4b persists trust, fails closed at runner and publishing boundaries, controls comment inclusion, records delivered comment evidence, and works in demo mode. | F, G and H ran together within these ownership boundaries. G and H are done; for the current state of each lane, see `docs/architecture.md`. If two lanes need an incompatible shared storage/API change, land that small prerequisite first; neither edits the other's files in parallel. Merge independent backend modules first, then their shared integration, and rerun checks on the combined head. @@ -1967,7 +1967,7 @@ F, G and H ran together within these ownership boundaries. G and H are done; for #### Ownership and integration rules 1. Each task uses its own branch/worktree from current remote main or a documented prerequisite branch. Record its issue, milestone, T-IDs, dependencies, owner and exact files in the PR. Delegated reviewers report findings; the implementation task's main agent owns its writes. -2. One integration owner controls `runner/store.ts`, shared runner/review wiring, `web/server.ts`, `web/cli.ts`, `web/public/app.js`, `web/public/index.html`, `web/public/style.css`, shared browser fixtures, package manifests/lockfiles, schema registry and common CI configuration. C held this ownership first. In wave 2, F owned runner/storage and the server wiring (`web/server.ts`, `web/cli.ts`), and G owned the shared screen files until it released them after G4 (#145). Before editing any of these files now, find the current owner as described in "Task resumption and ownership" in `AGENTS.md`. C owns common configuration in wave 1 and hands it to F before F1; D exclusively owns the new `.github/workflows/agent-isolation.yml`. D must route changes to existing `.github/workflows/ci.yml`, package scripts or lockfiles through the common-configuration owner. Separate worktrees do not remove this constraint. +2. One integration owner controls `runner/store.ts`, shared runner/review wiring, `web/server.ts`, `web/cli.ts`, `web/public/app.js`, `web/public/index.html`, `web/public/style.css`, shared browser fixtures, package manifests/lockfiles, schema registry and common CI configuration. C held this ownership first. In wave 2, F owned runner/storage and the server wiring (`web/server.ts`, `web/cli.ts`), and G owned the shared screen files until it released them after G4 (#145). Before editing any of these files now, check open PRs, branches and worktrees, and name one integration owner for any overlap, as "Task resumption and ownership" in `AGENTS.md` requires. C owns common configuration in wave 1 and hands it to F before F1; D exclusively owns the new `.github/workflows/agent-isolation.yml`. D must route changes to existing `.github/workflows/ci.yml`, package scripts or lockfiles through the common-configuration owner. Separate worktrees do not remove this constraint. 3. Keep this plan under one documentation owner. Lane owners record detailed progress and review rounds in their own issues/PRs; the documentation owner updates milestone status after integration. Never check off a milestone because only one parallel increment landed. 4. A blocked integration does not block disjoint modules or fixture work, but those tasks must report the missing production integration. No stub provider, skipped Docker test or mocked merge outcome counts as completed production behavior. 5. Every lane runs its targeted acceptance checks and required regressions. After its final integration change, rerun typecheck, unit/integration tests and applicable browser/Docker checks against the exact pushed head. Complete automated review and the review-lesson audit before an authorized merge. Revalidate downstream work after prerequisite changes. diff --git a/docs/implementation/issue-prioritization.md b/docs/implementation/issue-prioritization.md index 2e754dee..d646ec7f 100644 --- a/docs/implementation/issue-prioritization.md +++ b/docs/implementation/issue-prioritization.md @@ -85,9 +85,8 @@ them now, split in two: - **H4a (#55): the Issues screen.** It owned `web/server.ts`, `web/public/*`, a new `web/issues.ts`, the demo fixture `scripts/demo-issues.ts` and their tests. It did not edit `runner/store.ts`. - When G1 started, H4a handed `web/public/*` to G, and `web/server.ts` passed - to F as the server contract (#145); G3 changed it once (PR #151). G released - its files after G4 (see `docs/implementation/planning-screen.md`). + When G1 started, H4a handed `web/public/*` to G. G released those files + after G4 (see `docs/implementation/planning-screen.md`). - **H4b: the "trust this issue" action.** It records trust decisions through the storage owner (F) after F1's Store changes land, so the two lanes do not both bump the schema version. From 7e7abd39019953d11b60dabbcf153a58f0777303 Mon Sep 17 00:00:00 2001 From: mchwang Date: Sat, 10 Oct 2026 00:03:56 -0700 Subject: [PATCH 18/43] Keep only supported ownership history (#145) Co-Authored-By: Claude Opus 5.5 --- docs/designs/codeboost-plan-indexed-review.md | 2 +- docs/implementation/issue-prioritization.md | 5 +++-- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/docs/designs/codeboost-plan-indexed-review.md b/docs/designs/codeboost-plan-indexed-review.md index 00afacb7..d91499b9 100644 --- a/docs/designs/codeboost-plan-indexed-review.md +++ b/docs/designs/codeboost-plan-indexed-review.md @@ -1967,7 +1967,7 @@ F, G and H ran together within these ownership boundaries. G and H are done; for #### Ownership and integration rules 1. Each task uses its own branch/worktree from current remote main or a documented prerequisite branch. Record its issue, milestone, T-IDs, dependencies, owner and exact files in the PR. Delegated reviewers report findings; the implementation task's main agent owns its writes. -2. One integration owner controls `runner/store.ts`, shared runner/review wiring, `web/server.ts`, `web/cli.ts`, `web/public/app.js`, `web/public/index.html`, `web/public/style.css`, shared browser fixtures, package manifests/lockfiles, schema registry and common CI configuration. C held this ownership first. In wave 2, F owned runner/storage and the server wiring (`web/server.ts`, `web/cli.ts`), and G owned the shared screen files until it released them after G4 (#145). Before editing any of these files now, check open PRs, branches and worktrees, and name one integration owner for any overlap, as "Task resumption and ownership" in `AGENTS.md` requires. C owns common configuration in wave 1 and hands it to F before F1; D exclusively owns the new `.github/workflows/agent-isolation.yml`. D must route changes to existing `.github/workflows/ci.yml`, package scripts or lockfiles through the common-configuration owner. Separate worktrees do not remove this constraint. +2. One integration owner controls `runner/store.ts`, shared runner/review wiring, `web/server.ts`, `web/cli.ts`, `web/public/app.js`, `web/public/index.html`, `web/public/style.css`, shared browser fixtures, package manifests/lockfiles, schema registry and common CI configuration. C held this ownership first. In wave 2, lanes F, G and H each held parts of it; G released its shared screen files after G4 (#145). Before editing any of these files now, check open PRs, branches and worktrees, and name one integration owner for any overlap, as "Task resumption and ownership" in `AGENTS.md` requires. C owns common configuration in wave 1 and hands it to F before F1; D exclusively owns the new `.github/workflows/agent-isolation.yml`. D must route changes to existing `.github/workflows/ci.yml`, package scripts or lockfiles through the common-configuration owner. Separate worktrees do not remove this constraint. 3. Keep this plan under one documentation owner. Lane owners record detailed progress and review rounds in their own issues/PRs; the documentation owner updates milestone status after integration. Never check off a milestone because only one parallel increment landed. 4. A blocked integration does not block disjoint modules or fixture work, but those tasks must report the missing production integration. No stub provider, skipped Docker test or mocked merge outcome counts as completed production behavior. 5. Every lane runs its targeted acceptance checks and required regressions. After its final integration change, rerun typecheck, unit/integration tests and applicable browser/Docker checks against the exact pushed head. Complete automated review and the review-lesson audit before an authorized merge. Revalidate downstream work after prerequisite changes. diff --git a/docs/implementation/issue-prioritization.md b/docs/implementation/issue-prioritization.md index d646ec7f..768e93e6 100644 --- a/docs/implementation/issue-prioritization.md +++ b/docs/implementation/issue-prioritization.md @@ -85,8 +85,9 @@ them now, split in two: - **H4a (#55): the Issues screen.** It owned `web/server.ts`, `web/public/*`, a new `web/issues.ts`, the demo fixture `scripts/demo-issues.ts` and their tests. It did not edit `runner/store.ts`. - When G1 started, H4a handed `web/public/*` to G. G released those files - after G4 (see `docs/implementation/planning-screen.md`). + Its plan was to hand the web files to G when G1 started. Lane G has since + finished and released its shared screen files (see + `docs/implementation/planning-screen.md`). - **H4b: the "trust this issue" action.** It records trust decisions through the storage owner (F) after F1's Store changes land, so the two lanes do not both bump the schema version. From 28dc718c37703aaa992baf9112d6c0530b39f849 Mon Sep 17 00:00:00 2001 From: mchwang Date: Sat, 10 Oct 2026 00:08:29 -0700 Subject: [PATCH 19/43] Describe wave 1 config ownership as the plan's (#145) Copilot round 2 found that rule 2 still stated C's and D's finished wave 1 assignments as active rules. Co-Authored-By: Claude Opus 5.5 --- docs/designs/codeboost-plan-indexed-review.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/designs/codeboost-plan-indexed-review.md b/docs/designs/codeboost-plan-indexed-review.md index d91499b9..28ca8750 100644 --- a/docs/designs/codeboost-plan-indexed-review.md +++ b/docs/designs/codeboost-plan-indexed-review.md @@ -1967,7 +1967,7 @@ F, G and H ran together within these ownership boundaries. G and H are done; for #### Ownership and integration rules 1. Each task uses its own branch/worktree from current remote main or a documented prerequisite branch. Record its issue, milestone, T-IDs, dependencies, owner and exact files in the PR. Delegated reviewers report findings; the implementation task's main agent owns its writes. -2. One integration owner controls `runner/store.ts`, shared runner/review wiring, `web/server.ts`, `web/cli.ts`, `web/public/app.js`, `web/public/index.html`, `web/public/style.css`, shared browser fixtures, package manifests/lockfiles, schema registry and common CI configuration. C held this ownership first. In wave 2, lanes F, G and H each held parts of it; G released its shared screen files after G4 (#145). Before editing any of these files now, check open PRs, branches and worktrees, and name one integration owner for any overlap, as "Task resumption and ownership" in `AGENTS.md` requires. C owns common configuration in wave 1 and hands it to F before F1; D exclusively owns the new `.github/workflows/agent-isolation.yml`. D must route changes to existing `.github/workflows/ci.yml`, package scripts or lockfiles through the common-configuration owner. Separate worktrees do not remove this constraint. +2. One integration owner controls `runner/store.ts`, shared runner/review wiring, `web/server.ts`, `web/cli.ts`, `web/public/app.js`, `web/public/index.html`, `web/public/style.css`, shared browser fixtures, package manifests/lockfiles, schema registry and common CI configuration. C held this ownership first. In wave 2, lanes F, G and H each held parts of it; G released its shared screen files after G4 (#145). Before editing any of these files now, check open PRs, branches and worktrees, and name one integration owner for any overlap, as "Task resumption and ownership" in `AGENTS.md` requires. The wave 1 plan gave C common configuration, to hand to F before F1, and gave D exclusive ownership of the new `.github/workflows/agent-isolation.yml`, with D's changes to existing `.github/workflows/ci.yml`, package scripts or lockfiles routed through the common-configuration owner. C and D are done. Separate worktrees do not remove this constraint. 3. Keep this plan under one documentation owner. Lane owners record detailed progress and review rounds in their own issues/PRs; the documentation owner updates milestone status after integration. Never check off a milestone because only one parallel increment landed. 4. A blocked integration does not block disjoint modules or fixture work, but those tasks must report the missing production integration. No stub provider, skipped Docker test or mocked merge outcome counts as completed production behavior. 5. Every lane runs its targeted acceptance checks and required regressions. After its final integration change, rerun typecheck, unit/integration tests and applicable browser/Docker checks against the exact pushed head. Complete automated review and the review-lesson audit before an authorized merge. Revalidate downstream work after prerequisite changes. From c715e0205d92bd01b16798c97bf66491e13f8f45 Mon Sep 17 00:00:00 2001 From: mchwang Date: Sat, 10 Oct 2026 00:10:01 -0700 Subject: [PATCH 20/43] Mark the lane plans as the original schedule (#145) Co-Authored-By: Claude Opus 5.5 --- docs/designs/codeboost-plan-indexed-review.md | 2 ++ docs/implementation/issue-prioritization.md | 3 ++- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/docs/designs/codeboost-plan-indexed-review.md b/docs/designs/codeboost-plan-indexed-review.md index 28ca8750..aa431c96 100644 --- a/docs/designs/codeboost-plan-indexed-review.md +++ b/docs/designs/codeboost-plan-indexed-review.md @@ -1892,6 +1892,8 @@ Critical gaps (no test, no handling, and silent): 0. **Scheduling decision (2026-09-24).** Run up to three implementation tasks concurrently in separate feature branches and worktrees. The foundation and review screen are the baseline, not new assignments. Recheck current main, open PRs, and existing implementations before taking a lane; unchecked historical T-items are not proof that their code is missing. These lanes authorize a development schedule, not simultaneous task execution in the shipped runner. +**Current state.** The lane plans below record the original schedule. Lanes C, D, E, G, H and K are done, so their rows and handoff steps describe past work, not current owners or blockers. For the current state of each lane, see the lane table in `docs/architecture.md`. Before editing a shared file, follow "Task resumption and ownership" in `AGENTS.md`. + #### Lane status (checked 2026-09-26, after #55) This table is a snapshot from 2026-09-26 and is not kept current. For the current state of each lane, see the lane table in `docs/architecture.md`. This table records merged and open PRs only. A lane is complete only when every step meets its acceptance criteria on `main`. diff --git a/docs/implementation/issue-prioritization.md b/docs/implementation/issue-prioritization.md index 768e93e6..a4217fe9 100644 --- a/docs/implementation/issue-prioritization.md +++ b/docs/implementation/issue-prioritization.md @@ -87,7 +87,8 @@ them now, split in two: `scripts/demo-issues.ts` and their tests. It did not edit `runner/store.ts`. Its plan was to hand the web files to G when G1 started. Lane G has since finished and released its shared screen files (see - `docs/implementation/planning-screen.md`). + `docs/implementation/planning-screen.md`); `web/server.ts` is lane F's + server contract. - **H4b: the "trust this issue" action.** It records trust decisions through the storage owner (F) after F1's Store changes land, so the two lanes do not both bump the schema version. From 2934a84a1f9971a8e2e1bf6b604f47420a8cda5c Mon Sep 17 00:00:00 2001 From: mchwang Date: Sat, 10 Oct 2026 00:12:04 -0700 Subject: [PATCH 21/43] Link the Lane G close-out follow-ups (#155, #156) (#145) Co-Authored-By: Claude Opus 5.5 --- docs/designs/codeboost-plan-indexed-review.md | 2 +- docs/implementation/runner-lifecycle.md | 2 +- docs/plan-format.md | 4 ++-- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/designs/codeboost-plan-indexed-review.md b/docs/designs/codeboost-plan-indexed-review.md index aa431c96..e9ef93e8 100644 --- a/docs/designs/codeboost-plan-indexed-review.md +++ b/docs/designs/codeboost-plan-indexed-review.md @@ -1892,7 +1892,7 @@ Critical gaps (no test, no handling, and silent): 0. **Scheduling decision (2026-09-24).** Run up to three implementation tasks concurrently in separate feature branches and worktrees. The foundation and review screen are the baseline, not new assignments. Recheck current main, open PRs, and existing implementations before taking a lane; unchecked historical T-items are not proof that their code is missing. These lanes authorize a development schedule, not simultaneous task execution in the shipped runner. -**Current state.** The lane plans below record the original schedule. Lanes C, D, E, G, H and K are done, so their rows and handoff steps describe past work, not current owners or blockers. For the current state of each lane, see the lane table in `docs/architecture.md`. Before editing a shared file, follow "Task resumption and ownership" in `AGENTS.md`. +**Current state.** The lane plans below record the original schedule. B0 and lanes C, D, E, G, H and K are done, so their rows and handoff steps describe past work, not current owners or blockers. For the current state of each lane, see the lane table in `docs/architecture.md`. Before editing a shared file, follow "Task resumption and ownership" in `AGENTS.md`. #### Lane status (checked 2026-09-26, after #55) diff --git a/docs/implementation/runner-lifecycle.md b/docs/implementation/runner-lifecycle.md index 9b418201..0564ba4a 100644 --- a/docs/implementation/runner-lifecycle.md +++ b/docs/implementation/runner-lifecycle.md @@ -592,7 +592,7 @@ The user approved the proposal for each of these four questions. 4. `lstat` the database path and compare it with step 1's descriptor: same device and inode, a regular file, and a link count of 1. Exit on a mismatch. Keep the lock connection, and so the OS lock, open until shutdown step 8. Renames (including moves between directories on the same filesystem), symlink aliases and relative paths therefore meet the same lock, because they reach the same device and inode. Hard-link aliases are refused. A copy is a different file with a different inode, so it is a different database with its own lock and its own runner owner token. Take the lock at startup and release it at the end of shutdown, by closing the lock connection. Lock files must be on a local filesystem, because POSIX locks are unreliable on network filesystems, so startup refuses a network mount. Do not use a lease row in the main database, because lease expiry could release a live runner. | -| 2 | Does E3 keep writing `cancelled` before the provider settles? | Yes. This exception applies only to read-only phases. | Leave E3 unchanged. New F records use "terminal only after settlement" for every phase. Revisit this when G4 wires the planning endpoints. | +| 2 | Does E3 keep writing `cancelled` before the provider settles? | Yes. This exception applies only to read-only phases. | Leave E3 unchanged. New F records use "terminal only after settlement" for every phase. Revisit this when G4 wires the planning endpoints. G4 merged (PR #152) without recording this revisit; #156 tracks it. | | 3 | Is process shutdown a hard stop? | Yes. | Stopping the process cancels the running task with the reason "Stopped by shutdown". It does not wait for the task to finish. Restart recovery requeues the task. | | 4 | Does F set its own time limit on settlement at shutdown? | No. F waits for D's forced-kill escalation. | Do not abandon a job after a timer. The D5 real-Docker suite must prove that settlement always ends, including for a child process that ignores SIGTERM. D4 does not yet prove it: its cleanup retries have no limit (see the prerequisite under "Shutdown"). If D5 cannot prove it, reopen this decision before F1 merges. | diff --git a/docs/plan-format.md b/docs/plan-format.md index 36d6ed32..743d123c 100644 --- a/docs/plan-format.md +++ b/docs/plan-format.md @@ -149,8 +149,8 @@ Issue text and agent-produced plan fields remain untrusted. The prompt builder s | Source | What happens | |---|---| | **Claude drafts it** | codeboost runs the agent with the prompt in [`prompts/plan-author.md`](../prompts/plan-author.md) and passes the schema. The answer is a JSON plan. codeboost runs the checks after import and shows the plan on the Plans screen as a draft. | -| **You import a file** | On the Plans screen, choose "Import plan" and pick a `.yaml`, `.yml`, or `.json` file, or paste one. codeboost reads it, runs the schema and the checks after import, and saves it as the next draft revision. The file's `revision` is replaced by the next free number. | -| **You edit on the Plans screen** | Each change is checked as you type. Approving saves the revision. | +| **You import a file** | On the Plans screen, choose "Import plan" and pick a `.yaml`, `.yml`, or `.json` file. (Pasting a plan is not built yet: #155.) codeboost reads it, runs the schema and the checks after import, and saves it as the next draft revision. The file's `revision` is replaced by the next free number. | +| **You edit on the Plans screen** | *Not built yet (#155).* Each change is checked as you type. Approving saves the revision. | codeboost keeps the master copy in its own database. The copy in the PR description is written from that master and is never read back. From 5d349774d4b74384d9194325d54f8e8bf9b38c91 Mon Sep 17 00:00:00 2001 From: mchwang Date: Sat, 10 Oct 2026 00:12:12 -0700 Subject: [PATCH 22/43] List all open Lane G follow-ups in the handoff (#145) Co-Authored-By: Claude Opus 5.5 --- docs/implementation/planning-screen.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/implementation/planning-screen.md b/docs/implementation/planning-screen.md index f226f75d..53e10d90 100644 --- a/docs/implementation/planning-screen.md +++ b/docs/implementation/planning-screen.md @@ -40,4 +40,6 @@ Suggestion replies render as plain text followed by one line-separated row per t G1–G4 have merged as PRs #148, #150, #151 and #152, which completes lane G (#145). Lane G no longer owns `web/public/index.html`, `web/public/app.js`, `web/public/style.css`, `test/browser/plans.spec.ts`, `test/browser/plans-authoring.spec.ts`, `test/browser/plans-production.spec.ts` or this document. G3 also edited `web/server.ts` and `test/planning-drafts-api.test.ts`; those stay with lane F, which owns the server contract. Before the next change to any file named above, follow "Task resumption and ownership" in `AGENTS.md`: check open PRs, branches and worktrees first. -One related issue remains open. #146: `POST /api/plan/import` refuses request bodies over 16 KiB, but some schema-valid plans are larger. The fix is to raise the server's request limit, or to tighten the schema or import bound so the two agree. The screen needs no change. The #145 progress notes record #146 as lane F's work, because `web/server.ts` is an F-owned server contract. +Three related issues remain open. #146: `POST /api/plan/import` refuses request bodies over 16 KiB, but some schema-valid plans are larger. The fix is to raise the server's request limit, or to tighten the schema or import bound so the two agree. The screen needs no change. The #145 progress notes record #146 as lane F's work, because `web/server.ts` is an F-owned server contract. + +#155: `docs/plan-format.md` describes paste import and in-screen plan editing, which were not built. #156: the runner-lifecycle decision to revisit E3's early `cancelled` write at G4 was not recorded. From f6e5d5d518eb4fc218d2605e5a511c7c96ddeafa Mon Sep 17 00:00:00 2001 From: mchwang Date: Sat, 10 Oct 2026 00:13:40 -0700 Subject: [PATCH 23/43] Note what the Plans screen does for amendments today (#145) Co-Authored-By: Claude Opus 5.5 --- docs/designs/codeboost-plan-indexed-review.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/designs/codeboost-plan-indexed-review.md b/docs/designs/codeboost-plan-indexed-review.md index e9ef93e8..799cbed4 100644 --- a/docs/designs/codeboost-plan-indexed-review.md +++ b/docs/designs/codeboost-plan-indexed-review.md @@ -190,6 +190,8 @@ This keeps the plan out of the code, and there is only one master copy. 4. waits for you to approve or edit the proposal on the planning screen. Your approval creates the next plan revision; 5. puts the task back in the queue at its old position, and re-runs that plan item from the start. +The Plans screen does not yet show this proposal or support in-screen editing (#155). Today the next revision comes from an import, or from an applied agent draft or suggestion. + If an invocation finishes normally and passes the safety audit but edited an undeclared regular file within the task repository, codeboost still commits the change. Unsafe path, metadata, symlink, or submodule violations instead stop the invocation before any test or commit and move it to needs human. The change shows on that plan item's row, marked out of scope. Execution deliberately pauses in **needs amendment** before any later item or check invocation. A person must approve a revised plan and continuation; the runner reconciles the already-executed prefix with the audited current head, then validates remaining operations from that actual checkpoint. Do not silently add the file to scope or erase its original out-of-scope evidence. **Checking whether the issue is already fixed.** Before it opens the PR, and again before merging, codeboost checks: From 273c59ba0dc2f0c3601cdfcc976bda9f85f4d67e Mon Sep 17 00:00:00 2001 From: mchwang Date: Sat, 10 Oct 2026 00:14:03 -0700 Subject: [PATCH 24/43] Match the handoff to #155's scope (#145) Co-Authored-By: Claude Opus 5.5 --- docs/implementation/planning-screen.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/implementation/planning-screen.md b/docs/implementation/planning-screen.md index 53e10d90..a7c3df22 100644 --- a/docs/implementation/planning-screen.md +++ b/docs/implementation/planning-screen.md @@ -42,4 +42,4 @@ G1–G4 have merged as PRs #148, #150, #151 and #152, which completes lane G (#1 Three related issues remain open. #146: `POST /api/plan/import` refuses request bodies over 16 KiB, but some schema-valid plans are larger. The fix is to raise the server's request limit, or to tighten the schema or import bound so the two agree. The screen needs no change. The #145 progress notes record #146 as lane F's work, because `web/server.ts` is an F-owned server contract. -#155: `docs/plan-format.md` describes paste import and in-screen plan editing, which were not built. #156: the runner-lifecycle decision to revisit E3's early `cancelled` write at G4 was not recorded. +#155: `docs/plan-format.md` and the design doc describe paste import, in-screen plan editing and a view of the runner's amendment proposal, which were not built. #156: the runner-lifecycle decision to revisit E3's early `cancelled` write at G4 was not recorded. From 220d449bfa22f78a2be45a3467e5941bfe25ac87 Mon Sep 17 00:00:00 2001 From: mchwang Date: Sat, 10 Oct 2026 00:15:58 -0700 Subject: [PATCH 25/43] Update next steps and menu-link status for the Plans screen (#145) Co-Authored-By: Claude Opus 5.5 --- docs/designs/codeboost-plan-indexed-review.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/designs/codeboost-plan-indexed-review.md b/docs/designs/codeboost-plan-indexed-review.md index 799cbed4..18ab633f 100644 --- a/docs/designs/codeboost-plan-indexed-review.md +++ b/docs/designs/codeboost-plan-indexed-review.md @@ -653,8 +653,8 @@ Report the declared-file catch rate for both methods, with no pass bar. It shows ## What to do next -1. Done: create the repository, README, plan/linking foundation, persistent store, and read-only review screen. Also done: the guarded merge gate (PR #23), planning audit and authoring contract (E1, E2), suggestion orchestration (E3), issue ranking backend (H1–H3), merge-queue support (K1–K3), the agent isolation boundary (D1–D5), the runner lifecycle contract (F1) and the Issues screen (H4a). -2. Finish the open lane PRs listed in "Lane status", then continue the roadmap from the current open issues; the cancelled experiment is not a prerequisite. +1. Done: create the repository, README, plan/linking foundation, persistent store, and read-only review screen. Also done: the guarded merge gate (PR #23), planning audit and authoring contract (E1, E2), suggestion orchestration (E3), issue ranking backend (H1–H3), merge-queue support (K1–K3), the agent isolation boundary (D1–D5), the runner lifecycle contract (F1), the Issues screen (H4a), planning acceptance (E4) and the Plans screen (G1–G4, #145). +2. Finish the open lane work listed in the lane table in `docs/architecture.md`, then continue the roadmap from the current open issues; the cancelled experiment is not a prerequisite. 3. Optionally run the non-blocking human validation tracked in #19. 4. The engineering review (2026-09-22) settled how agents run, their container, network, and permissions. Re-run `/plan-eng-review` before implementing code-writing agents if anything in those areas changes. 5. **Test this document with a reader** (ISO 24495-1 asks for this). Ask one engineer who was not in this session to read the Summary and Terms, then explain codeboost back to you. Fix any part they misread. @@ -2167,7 +2167,7 @@ Built from this review's decisions. Tick each one as you ship it. **Status (checked against `main` on 2026-09-26).** Only DT1 is complete. Most DTs are partly built. Do not tick one until its Verify line passes. - Built: two-tab composer and "n pending changes" tags (part of DT4); the notice below 1280px (part of DT13); the `?` shortcut help (part of DT12); a blocker list from the guarded merge gate (part of DT7). -- Missing: "Send N change requests" and the reject flow (DT4, needs build step 5's reject loop); the merge step list (D16, DT7); menu links for Plans, Queue, Lessons and Learning, which are plain text until their screens exist (DT8, build steps 6 to 9; Issues became a link in #55); Lessons inbox and Learning screen (DT14, DT15, build step 9). +- Missing: "Send N change requests" and the reject flow (DT4, needs build step 5's reject loop); the merge step list (D16, DT7); menu links for Queue, Lessons and Learning, which are plain text until their screens exist (DT8, build steps 7 to 9; Issues became a link in #55 and Plans in G1, #148); Lessons inbox and Learning screen (DT14, DT15, build step 9). - Not yet audited against their Verify lines: DT2, DT3, DT5, DT6, DT9, DT10, DT11. - File paths in the DTs (`web/review`, `web/shell` and others) are proposed names. Today all UI code is in `web/public/`. From c967526913d06463aae248d8b408c7ac325a43ec Mon Sep 17 00:00:00 2001 From: mchwang Date: Sat, 10 Oct 2026 00:17:51 -0700 Subject: [PATCH 26/43] Describe the built Dismiss control in plan-format (#145) Co-Authored-By: Claude Opus 5.5 --- docs/plan-format.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/plan-format.md b/docs/plan-format.md index 743d123c..59436b13 100644 --- a/docs/plan-format.md +++ b/docs/plan-format.md @@ -160,7 +160,7 @@ When you ask the plan assistant on the Plans screen for changes, it answers in t - `reply`: its answer to you, in plain words; - `base_revision`: the revision it read. codeboost refuses edits made against an older revision; -- `edits`: 0 to 10 suggested edits. Each one becomes a card with **Apply** and **Dismiss**. Nothing changes until you click Apply. Applying one card creates the next revision and makes all remaining cards from that response stale, including independent edits. +- `edits`: 0 to 10 suggested edits. Each one becomes a card with **Apply**. **Dismiss suggestions** discards the whole response. Nothing changes until you click Apply. Applying one card creates the next revision and makes all remaining cards from that response stale, including independent edits. | `op` | Fields it uses | What it does | |---|---|---| From 1c4f62bdf4ab70f560df5a07fcbef5e5e2ddb6af Mon Sep 17 00:00:00 2001 From: mchwang Date: Sat, 10 Oct 2026 00:19:37 -0700 Subject: [PATCH 27/43] Match plan-format's Plans screen controls to the built screen (#145) Co-Authored-By: Claude Opus 5.5 --- docs/implementation/planning-screen.md | 2 +- docs/plan-format.md | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/implementation/planning-screen.md b/docs/implementation/planning-screen.md index a7c3df22..e6474b91 100644 --- a/docs/implementation/planning-screen.md +++ b/docs/implementation/planning-screen.md @@ -6,7 +6,7 @@ G1 adds a Plans screen over the planning contracts already owned by lanes E and 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. +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 lose their Apply control 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. diff --git a/docs/plan-format.md b/docs/plan-format.md index 59436b13..ff8326ef 100644 --- a/docs/plan-format.md +++ b/docs/plan-format.md @@ -149,7 +149,7 @@ Issue text and agent-produced plan fields remain untrusted. The prompt builder s | Source | What happens | |---|---| | **Claude drafts it** | codeboost runs the agent with the prompt in [`prompts/plan-author.md`](../prompts/plan-author.md) and passes the schema. The answer is a JSON plan. codeboost runs the checks after import and shows the plan on the Plans screen as a draft. | -| **You import a file** | On the Plans screen, choose "Import plan" and pick a `.yaml`, `.yml`, or `.json` file. (Pasting a plan is not built yet: #155.) codeboost reads it, runs the schema and the checks after import, and saves it as the next draft revision. The file's `revision` is replaced by the next free number. | +| **You import a file** | In the Plans screen's Import plan section, pick a `.yaml`, `.yml`, or `.json` file and choose **Import next revision**. (Pasting a plan is not built yet: #155.) codeboost reads it, runs the schema and the checks after import, and saves it as the next revision. The file's `revision` is replaced by the next free number. | | **You edit on the Plans screen** | *Not built yet (#155).* Each change is checked as you type. Approving saves the revision. | codeboost keeps the master copy in its own database. The copy in the PR description is written from that master and is never read back. @@ -174,7 +174,7 @@ When you ask the plan assistant on the Plans screen for changes, it answers in t | `remove_check` | `item`, `check_index` | Removes an acceptance entry by position, starting at 0. | | `set_depends` | `item`, `depends_on` | Replaces the item's `depends_on` list. | -**One card per revision.** Version 1 applies one selected card in one transaction, validates the complete resulting plan, increments the revision, and consumes that suggestion ID. In the same transaction, invalidate every other outstanding suggestion against the old revision. Remaining cards show "Plan changed — refresh suggestions" with Apply disabled and a **Refresh suggestions** action. Refresh sends the unapplied requested changes and the new current plan to the assistant under a new server-bound request, returning new IDs/revision; the person reviews the new cards before applying another. Never silently bump base_revision or replay old operations (especially positional check indexes). Dismiss does not mutate the plan or revision. Concurrent Apply requests use compare-and-swap: exactly one wins, the other returns stale with no mutation; retrying a consumed ID cannot create another revision. The two edits in the example are alternatives available at revision 3, not two sequentially applicable cards from that same response. Test first Apply, disabled sibling Apply, refresh, second Apply, and concurrent/replayed requests. +**One card per revision.** Version 1 applies one selected card in one transaction, validates the complete resulting plan, increments the revision, and consumes that suggestion ID. In the same transaction, invalidate every other outstanding suggestion against the old revision. Remaining cards stay visible without Apply, under one "Plan changed — refresh suggestions" line and a **Refresh suggestions** action. Refresh sends the unapplied requested changes and the new current plan to the assistant under a new server-bound request, returning new IDs/revision; the person reviews the new cards before applying another. Never silently bump base_revision or replay old operations (especially positional check indexes). Dismiss does not mutate the plan or revision. Concurrent Apply requests use compare-and-swap: exactly one wins, the other returns stale with no mutation; retrying a consumed ID cannot create another revision. The two edits in the example are alternatives available at revision 3, not two sequentially applicable cards from that same response. Test first Apply, sibling cards without Apply, refresh, second Apply, and concurrent/replayed requests. **Request identity binding.** `base_revision` is local to one plan, not a globally unique identity. Before an assistant request starts, the server persists an opaque request ID bound to the stable repository/task/plan IDs, schema version, and base revision. Store its response/suggestion IDs under that captured context only; never attach a late result to the currently selected UI plan. Apply accepts a server-issued suggestion ID, loads its bound context, and atomically verifies the target plan identity and revision before mutation. Reject unknown, canceled, cross-plan, or stale requests. A matching revision and item IDs on another plan are insufficient. The assistant response need not echo trusted IDs, and any identity claims in free text are ignored. Test two plans at revision 3 with P1 while a delayed response for A arrives with B selected: B must remain unchanged. From d606e61b4b5e1b05c1d425632126b75c7a6452df Mon Sep 17 00:00:00 2001 From: mchwang Date: Sat, 10 Oct 2026 00:21:59 -0700 Subject: [PATCH 28/43] Mark unbuilt Plans screen design features (#155) (#145) Co-Authored-By: Claude Opus 5.5 --- docs/designs/codeboost-plan-indexed-review.md | 4 ++-- docs/plan-format.md | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/designs/codeboost-plan-indexed-review.md b/docs/designs/codeboost-plan-indexed-review.md index 18ab633f..9d7394c6 100644 --- a/docs/designs/codeboost-plan-indexed-review.md +++ b/docs/designs/codeboost-plan-indexed-review.md @@ -2138,7 +2138,7 @@ Overall (the lowest pass): **1 → 8**. D22 is complete: DESIGN.md defines the r ### Not in scope - **Phone and tablet layouts.** codeboost is a desktop tool (D25). -- **Queue, Plans, Issues, and Settings screens.** Not reviewed here. Review them before build steps 6 to 8. +- **Queue, Plans, Issues, and Settings screens.** Not reviewed here. The Plans screen (build step 6) and the Issues screen (build step 8) were built without this review; review the Queue and Settings screens before they are built. - **Motion design.** None is needed for this tool. ### What already exists @@ -2167,7 +2167,7 @@ Built from this review's decisions. Tick each one as you ship it. **Status (checked against `main` on 2026-09-26).** Only DT1 is complete. Most DTs are partly built. Do not tick one until its Verify line passes. - Built: two-tab composer and "n pending changes" tags (part of DT4); the notice below 1280px (part of DT13); the `?` shortcut help (part of DT12); a blocker list from the guarded merge gate (part of DT7). -- Missing: "Send N change requests" and the reject flow (DT4, needs build step 5's reject loop); the merge step list (D16, DT7); menu links for Queue, Lessons and Learning, which are plain text until their screens exist (DT8, build steps 7 to 9; Issues became a link in #55 and Plans in G1, #148); Lessons inbox and Learning screen (DT14, DT15, build step 9). +- Missing: "Send N change requests" and the reject flow (DT4, needs build step 5's reject loop); the merge step list (D16, DT7); menu links for Queue, Lessons and Learning, which are plain text until their screens exist (DT8, build steps 7 to 9; Issues became a link in #55 and Plans in G1, #148); the approved Plans mockup's expandable row editing (not built, #155) and bottom-drawer plan assistant (the built screen puts the assistant in a side panel); Lessons inbox and Learning screen (DT14, DT15, build step 9). - Not yet audited against their Verify lines: DT2, DT3, DT5, DT6, DT9, DT10, DT11. - File paths in the DTs (`web/review`, `web/shell` and others) are proposed names. Today all UI code is in `web/public/`. diff --git a/docs/plan-format.md b/docs/plan-format.md index ff8326ef..3172763d 100644 --- a/docs/plan-format.md +++ b/docs/plan-format.md @@ -109,7 +109,7 @@ Every consumer of a current plan (execution, review, fixes, and conflict resolut ## Checks after import -The schema checks the shape. codeboost then checks the meaning. A **failure** blocks approval. A **warning** shows on the item, and you can approve anyway. +The schema checks the shape. codeboost then checks the meaning. A **failure** blocks approval. A **warning** shows on the item, and you can approve anyway. (The Plans screen does not show warnings yet: #155.) | Check | Result if it fails | |---|---| @@ -126,7 +126,7 @@ The schema checks the shape. codeboost then checks the meaning. A **failure** bl | The item has at least one `cmd`. | Warning: "No test command" | | Each `cmd` is parsed as one executable and literal arguments, with the entire argv matched element-for-element against a repo-approved argv entry. Prefix matches, appended flags, extra arguments, and argument substitution are not allowed. An unlisted argv needs the person's explicit approval as a new exact allowlist entry; plan approval alone does not grant execution permission. Shell operators, pipelines, redirects, substitutions, and expansions are rejected. Execute the resulting argv without a shell. | Invalid syntax blocks approval; a valid but unlisted command warns and cannot run until allowed | | A completed agent invocation changes a dependency or a script codeboost will run. | Before its own installation or script invocation, codeboost stops in "needs approval". This post-invocation gate cannot prevent an agent from executing a changed script during its invocation; container and network restrictions must already contain that execution. | -| `questions` is not empty. | The plan shows the questions at the top; answer them or approve anyway | +| `questions` is not empty. | The plan shows the questions at the top; answer them or approve anyway. (The Plans screen lists them read-only; answering is not built yet: #155.) | **Submodules in version 1.** Gitlinks are review-only metadata leaves: the linking engine can display and attribute externally produced pointer changes, but v1 plans cannot author, add, delete, or rename a gitlink. Reject declarations targeting an existing gitlink and reject agent-produced gitlinks. Authoring them requires a future typed target-commit field and runner-controlled operation. Do not initialize or update nested submodule worktrees. Before each invocation that can write the task filesystem (an execute or fix agent, and a check that runs an item's `cmd` there), reject an initialized/populated gitlink directory and bind an empty read-only mount at every existing gitlink path; refuse the invocation if that protection cannot be enforced. A read-only invocation (planning, questions, review, and a check that runs as review) needs neither: its task filesystem is a fresh non-recursive clone, so every gitlink directory is empty, and it is mounted read-only, so nothing can fill one. Every directory above a gitlink is pinned for the invocation too (mounted again at its own path, so it cannot be renamed), so the gitlink's mount cannot be moved aside and its path refilled. Before tests and before committing, inspect gitlink locations without following links and reject nested content, including content under newly introduced gitlinks. A top-level Git diff is not enough. Reviewing submodule pointers reads the Git entry only; the agent never receives an editable nested checkout. Tests must attempt writes beneath a gitlink and provide a pre-populated nested checkout, and both must be refused. From 33e8b39ab7758fe365ad93d7774c859387493f4c Mon Sep 17 00:00:00 2001 From: mchwang Date: Sat, 10 Oct 2026 00:22:13 -0700 Subject: [PATCH 29/43] Match the handoff to #155's widened scope (#145) Co-Authored-By: Claude Opus 5.5 --- docs/implementation/planning-screen.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/implementation/planning-screen.md b/docs/implementation/planning-screen.md index e6474b91..6adef810 100644 --- a/docs/implementation/planning-screen.md +++ b/docs/implementation/planning-screen.md @@ -42,4 +42,4 @@ G1–G4 have merged as PRs #148, #150, #151 and #152, which completes lane G (#1 Three related issues remain open. #146: `POST /api/plan/import` refuses request bodies over 16 KiB, but some schema-valid plans are larger. The fix is to raise the server's request limit, or to tighten the schema or import bound so the two agree. The screen needs no change. The #145 progress notes record #146 as lane F's work, because `web/server.ts` is an F-owned server contract. -#155: `docs/plan-format.md` and the design doc describe paste import, in-screen plan editing and a view of the runner's amendment proposal, which were not built. #156: the runner-lifecycle decision to revisit E3's early `cancelled` write at G4 was not recorded. +#155: `docs/plan-format.md` and the design doc describe Plans screen features that were not built: paste import, in-screen plan editing, a view of the runner's amendment proposal, check warnings and answering open questions. #156: the runner-lifecycle decision to revisit E3's early `cancelled` write at G4 was not recorded. From c27a441298314edb8dc92b2e29a84b341f785ed6 Mon Sep 17 00:00:00 2001 From: mchwang Date: Sat, 10 Oct 2026 00:24:55 -0700 Subject: [PATCH 30/43] Name the suggestion Apply control; date the Plans DT update (#145) Co-Authored-By: Claude Opus 5.5 --- docs/designs/codeboost-plan-indexed-review.md | 2 +- docs/plan-format.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/designs/codeboost-plan-indexed-review.md b/docs/designs/codeboost-plan-indexed-review.md index 9d7394c6..ce860c2d 100644 --- a/docs/designs/codeboost-plan-indexed-review.md +++ b/docs/designs/codeboost-plan-indexed-review.md @@ -2165,7 +2165,7 @@ None proposed. Every fix is in the plan and in the tasks below. Built from this review's decisions. Tick each one as you ship it. -**Status (checked against `main` on 2026-09-26).** Only DT1 is complete. Most DTs are partly built. Do not tick one until its Verify line passes. +**Status (checked against `main` on 2026-09-26; Plans entries updated after G4, PR #152).** Only DT1 is complete. Most DTs are partly built. Do not tick one until its Verify line passes. - Built: two-tab composer and "n pending changes" tags (part of DT4); the notice below 1280px (part of DT13); the `?` shortcut help (part of DT12); a blocker list from the guarded merge gate (part of DT7). - Missing: "Send N change requests" and the reject flow (DT4, needs build step 5's reject loop); the merge step list (D16, DT7); menu links for Queue, Lessons and Learning, which are plain text until their screens exist (DT8, build steps 7 to 9; Issues became a link in #55 and Plans in G1, #148); the approved Plans mockup's expandable row editing (not built, #155) and bottom-drawer plan assistant (the built screen puts the assistant in a side panel); Lessons inbox and Learning screen (DT14, DT15, build step 9). - Not yet audited against their Verify lines: DT2, DT3, DT5, DT6, DT9, DT10, DT11. diff --git a/docs/plan-format.md b/docs/plan-format.md index 3172763d..e1d94a00 100644 --- a/docs/plan-format.md +++ b/docs/plan-format.md @@ -160,7 +160,7 @@ When you ask the plan assistant on the Plans screen for changes, it answers in t - `reply`: its answer to you, in plain words; - `base_revision`: the revision it read. codeboost refuses edits made against an older revision; -- `edits`: 0 to 10 suggested edits. Each one becomes a card with **Apply**. **Dismiss suggestions** discards the whole response. Nothing changes until you click Apply. Applying one card creates the next revision and makes all remaining cards from that response stale, including independent edits. +- `edits`: 0 to 10 suggested edits. Each one becomes a card with **Apply this edit**. **Dismiss suggestions** discards the whole response. Nothing changes until you click Apply. Applying one card creates the next revision and makes all remaining cards from that response stale, including independent edits. | `op` | Fields it uses | What it does | |---|---|---| From 063828f2bd2a1189689fd28f2ddf2b359a6e011c Mon Sep 17 00:00:00 2001 From: mchwang Date: Sat, 10 Oct 2026 00:28:04 -0700 Subject: [PATCH 31/43] Correct the amendment and Settings notes (#145) Co-Authored-By: Claude Opus 5.5 --- docs/designs/codeboost-plan-indexed-review.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/designs/codeboost-plan-indexed-review.md b/docs/designs/codeboost-plan-indexed-review.md index ce860c2d..32b87888 100644 --- a/docs/designs/codeboost-plan-indexed-review.md +++ b/docs/designs/codeboost-plan-indexed-review.md @@ -190,7 +190,7 @@ This keeps the plan out of the code, and there is only one master copy. 4. waits for you to approve or edit the proposal on the planning screen. Your approval creates the next plan revision; 5. puts the task back in the queue at its old position, and re-runs that plan item from the start. -The Plans screen does not yet show this proposal or support in-screen editing (#155). Today the next revision comes from an import, or from an applied agent draft or suggestion. +The runner does not yet save this proposal, and the Plans screen cannot show or edit one (#155). Today a needs-amendment pause comes from an out-of-scope edit (next paragraph), and the next revision comes from an import or an applied agent draft or suggestion. If an invocation finishes normally and passes the safety audit but edited an undeclared regular file within the task repository, codeboost still commits the change. Unsafe path, metadata, symlink, or submodule violations instead stop the invocation before any test or commit and move it to needs human. The change shows on that plan item's row, marked out of scope. Execution deliberately pauses in **needs amendment** before any later item or check invocation. A person must approve a revised plan and continuation; the runner reconciles the already-executed prefix with the audited current head, then validates remaining operations from that actual checkpoint. Do not silently add the file to scope or erase its original out-of-scope evidence. @@ -2138,7 +2138,7 @@ Overall (the lowest pass): **1 → 8**. D22 is complete: DESIGN.md defines the r ### Not in scope - **Phone and tablet layouts.** codeboost is a desktop tool (D25). -- **Queue, Plans, Issues, and Settings screens.** Not reviewed here. The Plans screen (build step 6) and the Issues screen (build step 8) were built without this review; review the Queue and Settings screens before they are built. +- **Queue, Plans, Issues, and Settings screens.** Not reviewed here. The Plans screen (build step 6) and the Issues screen (build step 8) were built without this review; review the Queue screen and the full Settings screen (today a question-agent dialog) before they are built. - **Motion design.** None is needed for this tool. ### What already exists From fb2f2763d8fc561be96bb1f65d44e28f51014da9 Mon Sep 17 00:00:00 2001 From: mchwang Date: Sat, 10 Oct 2026 00:30:17 -0700 Subject: [PATCH 32/43] Qualify build step 6 status with #155's unbuilt parts (#145) Co-Authored-By: Claude Opus 5.5 --- docs/designs/codeboost-plan-indexed-review.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/designs/codeboost-plan-indexed-review.md b/docs/designs/codeboost-plan-indexed-review.md index 32b87888..cbb53c5b 100644 --- a/docs/designs/codeboost-plan-indexed-review.md +++ b/docs/designs/codeboost-plan-indexed-review.md @@ -27,7 +27,7 @@ Last checked against the code: 2026-09-26 (see "Lane status" under "Parallel bui - **How it stays trustworthy.** codeboost records commits in a trusted ledger with either an owning plan item or an explicit foreign/unowned classification. Rewriting a foreign commit never turns it into owned work. It also checks each change against the files the plan item said it would touch. One blind spot remains: an unrelated edit inside a file the plan item declared is caught only by the review agent and by you. - **How it stays safe.** Agents run inside a container that holds only the task's code and the credential for that phase, so your other files and credentials are not there. Ask, code-writing runs, and conflict resolution use provider-specific containers; exact-head `cmd:` checks use a credential-free read-only profile. codeboost needs your approval before its own dependency installation or invocation of changed scripts; containment must also cover commands the agent already ran. - **It learns from you.** After each task, codeboost turns your feedback into short lessons. You approve each lesson before agents use it, and a Learning screen shows whether you are repeating yourself less. -- **Where the build is.** Built: the plan and linking library, SQLite store, review screen with Ask and change requests, guarded merge gate with merge-queue support, agent isolation boundary, Plans screen (lane G, #145), opt-in code-writing runner and publishing, durable local rebase/conflict resolution, and pre-merge base/head refresh with exact-head `cmd:` checks. Still deferred: pushing the rewritten head, waiting for its required checks, handing that exact pair to guarded merge, and the Queue, Lessons and Learning screens (the ranked Issues screen is built). Optional real-PR validation is tracked separately in #19 and is not a prerequisite. +- **Where the build is.** Built: the plan and linking library, SQLite store, review screen with Ask and change requests, guarded merge gate with merge-queue support, agent isolation boundary, Plans screen (lane G, #145; #155 lists unbuilt parts), opt-in code-writing runner and publishing, durable local rebase/conflict resolution, and pre-merge base/head refresh with exact-head `cmd:` checks. Still deferred: pushing the rewritten head, waiting for its required checks, handing that exact pair to guarded merge, and the Queue, Lessons and Learning screens (the ranked Issues screen is built). Optional real-PR validation is tracked separately in #19 and is not a prerequisite. ## Terms used @@ -569,7 +569,7 @@ The numbers below identify delivery milestones, not a requirement to implement t 3. **Optional validation.** A future real-PR comparison may test the assumptions in "How we will know it works," but it is non-blocking under the superseding decision above. 4. **Merge gate and merging** (product workflow step 9): the merge rules, the pre-merge sequence, and merging through `gh`. Increment 1 merged (PR #23), and merge-queue support merged (#38, #46, closing #24); the rest waits for the runner in build step 5. See the scope and completion criteria below. 5. **Running agents.** Per-task clones, containers, agent adapters, permissions, one invocation per plan item, review rounds, the "already fixed" check, and opening PRs (step 6). Isolation boundary merged (lane D, PRs #31, #40, #44, #47, #50); the runner (lane F) is next. -6. **Planning screen.** Writing plans with an agent, and approving plan changes (steps 2 and 3). *Done:* planning backend (lane E, E1–E4) and the Plans screen (lane G, G1–G4, #145; PRs #148, #150, #151, #152). +6. **Planning screen.** Writing plans with an agent, and approving plan changes (steps 2 and 3). *Done for T18:* planning backend (lane E, E1–E4) and the Plans screen (lane G, G1–G4, #145; PRs #148, #150, #151, #152). Not built: paste import, in-screen editing, the amendment-proposal view, check warnings and answering questions (#155). 7. **Queue, schedule, and recovery** (steps 4 and 5). 8. **Issue list, sorted by how critical each issue is** (step 1). *Done:* ranking backend (H1–H3), the Issues screen (H4a, #55), and the author-bound "trust this issue" action and runner guard (H4b, #108, PR #139) have merged. 9. **Learning from your feedback** (step 10): lessons, the Lessons inbox, and the Learning screen. It needs the reject loop from steps 4 to 7. From cf8f7380a98887aaa07e4580a328bf7410581960 Mon Sep 17 00:00:00 2001 From: mchwang Date: Sat, 10 Oct 2026 00:32:38 -0700 Subject: [PATCH 33/43] Place the refresh line below the cards in plan-format (#145) Co-Authored-By: Claude Opus 5.5 --- docs/plan-format.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/plan-format.md b/docs/plan-format.md index e1d94a00..95869649 100644 --- a/docs/plan-format.md +++ b/docs/plan-format.md @@ -174,7 +174,7 @@ When you ask the plan assistant on the Plans screen for changes, it answers in t | `remove_check` | `item`, `check_index` | Removes an acceptance entry by position, starting at 0. | | `set_depends` | `item`, `depends_on` | Replaces the item's `depends_on` list. | -**One card per revision.** Version 1 applies one selected card in one transaction, validates the complete resulting plan, increments the revision, and consumes that suggestion ID. In the same transaction, invalidate every other outstanding suggestion against the old revision. Remaining cards stay visible without Apply, under one "Plan changed — refresh suggestions" line and a **Refresh suggestions** action. Refresh sends the unapplied requested changes and the new current plan to the assistant under a new server-bound request, returning new IDs/revision; the person reviews the new cards before applying another. Never silently bump base_revision or replay old operations (especially positional check indexes). Dismiss does not mutate the plan or revision. Concurrent Apply requests use compare-and-swap: exactly one wins, the other returns stale with no mutation; retrying a consumed ID cannot create another revision. The two edits in the example are alternatives available at revision 3, not two sequentially applicable cards from that same response. Test first Apply, sibling cards without Apply, refresh, second Apply, and concurrent/replayed requests. +**One card per revision.** Version 1 applies one selected card in one transaction, validates the complete resulting plan, increments the revision, and consumes that suggestion ID. In the same transaction, invalidate every other outstanding suggestion against the old revision. Remaining cards stay visible without Apply. Below them, one "Plan changed — refresh suggestions" line has a **Refresh suggestions** action. Refresh sends the unapplied requested changes and the new current plan to the assistant under a new server-bound request, returning new IDs/revision; the person reviews the new cards before applying another. Never silently bump base_revision or replay old operations (especially positional check indexes). Dismiss does not mutate the plan or revision. Concurrent Apply requests use compare-and-swap: exactly one wins, the other returns stale with no mutation; retrying a consumed ID cannot create another revision. The two edits in the example are alternatives available at revision 3, not two sequentially applicable cards from that same response. Test first Apply, sibling cards without Apply, refresh, second Apply, and concurrent/replayed requests. **Request identity binding.** `base_revision` is local to one plan, not a globally unique identity. Before an assistant request starts, the server persists an opaque request ID bound to the stable repository/task/plan IDs, schema version, and base revision. Store its response/suggestion IDs under that captured context only; never attach a late result to the currently selected UI plan. Apply accepts a server-issued suggestion ID, loads its bound context, and atomically verifies the target plan identity and revision before mutation. Reject unknown, canceled, cross-plan, or stale requests. A matching revision and item IDs on another plan are insufficient. The assistant response need not echo trusted IDs, and any identity claims in free text are ignored. Test two plans at revision 3 with P1 while a delayed response for A arrives with B selected: B must remain unchanged. From a9d9f02707f077349d03581ea9f7d80ef15c15b5 Mon Sep 17 00:00:00 2001 From: mchwang Date: Sat, 10 Oct 2026 00:34:41 -0700 Subject: [PATCH 34/43] Qualify the Plans screen in What to do next (#145) Co-Authored-By: Claude Opus 5.5 --- docs/designs/codeboost-plan-indexed-review.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/designs/codeboost-plan-indexed-review.md b/docs/designs/codeboost-plan-indexed-review.md index cbb53c5b..3e844b51 100644 --- a/docs/designs/codeboost-plan-indexed-review.md +++ b/docs/designs/codeboost-plan-indexed-review.md @@ -653,7 +653,7 @@ Report the declared-file catch rate for both methods, with no pass bar. It shows ## What to do next -1. Done: create the repository, README, plan/linking foundation, persistent store, and read-only review screen. Also done: the guarded merge gate (PR #23), planning audit and authoring contract (E1, E2), suggestion orchestration (E3), issue ranking backend (H1–H3), merge-queue support (K1–K3), the agent isolation boundary (D1–D5), the runner lifecycle contract (F1), the Issues screen (H4a), planning acceptance (E4) and the Plans screen (G1–G4, #145). +1. Done: create the repository, README, plan/linking foundation, persistent store, and read-only review screen. Also done: the guarded merge gate (PR #23), planning audit and authoring contract (E1, E2), suggestion orchestration (E3), issue ranking backend (H1–H3), merge-queue support (K1–K3), the agent isolation boundary (D1–D5), the runner lifecycle contract (F1), the Issues screen (H4a), planning acceptance (E4) and the Plans screen (G1–G4, #145; #155 lists unbuilt parts). 2. Finish the open lane work listed in the lane table in `docs/architecture.md`, then continue the roadmap from the current open issues; the cancelled experiment is not a prerequisite. 3. Optionally run the non-blocking human validation tracked in #19. 4. The engineering review (2026-09-22) settled how agents run, their container, network, and permissions. Re-run `/plan-eng-review` before implementing code-writing agents if anything in those areas changes. From ef055c708a26addd2ce9fa2b89ad722b0a9df66b Mon Sep 17 00:00:00 2001 From: mchwang Date: Sat, 10 Oct 2026 00:36:45 -0700 Subject: [PATCH 35/43] Say the Plans screen has no approval step yet (#145) Co-Authored-By: Claude Opus 5.5 --- docs/plan-format.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/plan-format.md b/docs/plan-format.md index 95869649..b11fa704 100644 --- a/docs/plan-format.md +++ b/docs/plan-format.md @@ -109,7 +109,7 @@ Every consumer of a current plan (execution, review, fixes, and conflict resolut ## Checks after import -The schema checks the shape. codeboost then checks the meaning. A **failure** blocks approval. A **warning** shows on the item, and you can approve anyway. (The Plans screen does not show warnings yet: #155.) +The schema checks the shape. codeboost then checks the meaning. A **failure** blocks approval. A **warning** shows on the item, and you can approve anyway. (The Plans screen does not show warnings or have an approval step yet: an import or an applied draft or suggestion creates the next revision directly. #155 tracks both.) | Check | Result if it fails | |---|---| @@ -126,7 +126,7 @@ The schema checks the shape. codeboost then checks the meaning. A **failure** bl | The item has at least one `cmd`. | Warning: "No test command" | | Each `cmd` is parsed as one executable and literal arguments, with the entire argv matched element-for-element against a repo-approved argv entry. Prefix matches, appended flags, extra arguments, and argument substitution are not allowed. An unlisted argv needs the person's explicit approval as a new exact allowlist entry; plan approval alone does not grant execution permission. Shell operators, pipelines, redirects, substitutions, and expansions are rejected. Execute the resulting argv without a shell. | Invalid syntax blocks approval; a valid but unlisted command warns and cannot run until allowed | | A completed agent invocation changes a dependency or a script codeboost will run. | Before its own installation or script invocation, codeboost stops in "needs approval". This post-invocation gate cannot prevent an agent from executing a changed script during its invocation; container and network restrictions must already contain that execution. | -| `questions` is not empty. | The plan shows the questions at the top; answer them or approve anyway. (The Plans screen lists them read-only; answering is not built yet: #155.) | +| `questions` is not empty. | The plan shows the questions at the top; answer them or approve anyway. (The Plans screen lists them read-only. It has no answer or approve control yet: #155.) | **Submodules in version 1.** Gitlinks are review-only metadata leaves: the linking engine can display and attribute externally produced pointer changes, but v1 plans cannot author, add, delete, or rename a gitlink. Reject declarations targeting an existing gitlink and reject agent-produced gitlinks. Authoring them requires a future typed target-commit field and runner-controlled operation. Do not initialize or update nested submodule worktrees. Before each invocation that can write the task filesystem (an execute or fix agent, and a check that runs an item's `cmd` there), reject an initialized/populated gitlink directory and bind an empty read-only mount at every existing gitlink path; refuse the invocation if that protection cannot be enforced. A read-only invocation (planning, questions, review, and a check that runs as review) needs neither: its task filesystem is a fresh non-recursive clone, so every gitlink directory is empty, and it is mounted read-only, so nothing can fill one. Every directory above a gitlink is pinned for the invocation too (mounted again at its own path, so it cannot be renamed), so the gitlink's mount cannot be moved aside and its path refilled. Before tests and before committing, inspect gitlink locations without following links and reject nested content, including content under newly introduced gitlinks. A top-level Git diff is not enough. Reviewing submodule pointers reads the Git entry only; the agent never receives an editable nested checkout. Tests must attempt writes beneath a gitlink and provide a pre-populated nested checkout, and both must be refused. From 43d5f75a091b6d5ce70b959f0b5ec162e54dcea5 Mon Sep 17 00:00:00 2001 From: mchwang Date: Sat, 10 Oct 2026 00:36:48 -0700 Subject: [PATCH 36/43] List the approval step among #155's unbuilt parts (#145) Co-Authored-By: Claude Opus 5.5 --- docs/designs/codeboost-plan-indexed-review.md | 2 +- docs/implementation/planning-screen.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/designs/codeboost-plan-indexed-review.md b/docs/designs/codeboost-plan-indexed-review.md index 3e844b51..82a216eb 100644 --- a/docs/designs/codeboost-plan-indexed-review.md +++ b/docs/designs/codeboost-plan-indexed-review.md @@ -569,7 +569,7 @@ The numbers below identify delivery milestones, not a requirement to implement t 3. **Optional validation.** A future real-PR comparison may test the assumptions in "How we will know it works," but it is non-blocking under the superseding decision above. 4. **Merge gate and merging** (product workflow step 9): the merge rules, the pre-merge sequence, and merging through `gh`. Increment 1 merged (PR #23), and merge-queue support merged (#38, #46, closing #24); the rest waits for the runner in build step 5. See the scope and completion criteria below. 5. **Running agents.** Per-task clones, containers, agent adapters, permissions, one invocation per plan item, review rounds, the "already fixed" check, and opening PRs (step 6). Isolation boundary merged (lane D, PRs #31, #40, #44, #47, #50); the runner (lane F) is next. -6. **Planning screen.** Writing plans with an agent, and approving plan changes (steps 2 and 3). *Done for T18:* planning backend (lane E, E1–E4) and the Plans screen (lane G, G1–G4, #145; PRs #148, #150, #151, #152). Not built: paste import, in-screen editing, the amendment-proposal view, check warnings and answering questions (#155). +6. **Planning screen.** Writing plans with an agent, and approving plan changes (steps 2 and 3). *Done for T18:* planning backend (lane E, E1–E4) and the Plans screen (lane G, G1–G4, #145; PRs #148, #150, #151, #152). Not built: paste import, in-screen editing, the amendment-proposal view, check warnings, answering questions and a whole-plan approval step (#155). 7. **Queue, schedule, and recovery** (steps 4 and 5). 8. **Issue list, sorted by how critical each issue is** (step 1). *Done:* ranking backend (H1–H3), the Issues screen (H4a, #55), and the author-bound "trust this issue" action and runner guard (H4b, #108, PR #139) have merged. 9. **Learning from your feedback** (step 10): lessons, the Lessons inbox, and the Learning screen. It needs the reject loop from steps 4 to 7. diff --git a/docs/implementation/planning-screen.md b/docs/implementation/planning-screen.md index 6adef810..14e935ae 100644 --- a/docs/implementation/planning-screen.md +++ b/docs/implementation/planning-screen.md @@ -42,4 +42,4 @@ G1–G4 have merged as PRs #148, #150, #151 and #152, which completes lane G (#1 Three related issues remain open. #146: `POST /api/plan/import` refuses request bodies over 16 KiB, but some schema-valid plans are larger. The fix is to raise the server's request limit, or to tighten the schema or import bound so the two agree. The screen needs no change. The #145 progress notes record #146 as lane F's work, because `web/server.ts` is an F-owned server contract. -#155: `docs/plan-format.md` and the design doc describe Plans screen features that were not built: paste import, in-screen plan editing, a view of the runner's amendment proposal, check warnings and answering open questions. #156: the runner-lifecycle decision to revisit E3's early `cancelled` write at G4 was not recorded. +#155: `docs/plan-format.md` and the design doc describe Plans screen features that were not built: paste import, in-screen plan editing, a view of the runner's amendment proposal, check warnings, answering open questions and a whole-plan approval step. #156: the runner-lifecycle decision to revisit E3's early `cancelled` write at G4 was not recorded. From 8e9d6588373373bc6d1561ad7c92959a5cebe706 Mon Sep 17 00:00:00 2001 From: mchwang Date: Sat, 10 Oct 2026 00:39:24 -0700 Subject: [PATCH 37/43] Put lane H's ownership section in the past tense (#145) Co-Authored-By: Claude Opus 5.5 --- docs/implementation/issue-prioritization.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/implementation/issue-prioritization.md b/docs/implementation/issue-prioritization.md index a4217fe9..57d23779 100644 --- a/docs/implementation/issue-prioritization.md +++ b/docs/implementation/issue-prioritization.md @@ -73,14 +73,14 @@ dedicated read-only gateway with these boundaries: ## Ownership and staged delivery -H1-H3 own dedicated issue retrieval, normalization and ranking modules plus -their tests and this document. They do not edit the Store, runner, shared web -shell, package files or CI. +Lane H is done. H1-H3 owned dedicated issue retrieval, normalization and +ranking modules plus their tests and this document. They did not edit the +Store, runner, shared web shell, package files or CI. **Schedule change (2026-09-25, approved by the product owner).** H4 was planned -to wait for G4 to release the shared web files. G cannot start until E4 merges, -and E4 waits for D5, so the web files had no active owner. H4 therefore takes -them now, split in two: +to wait for G4 to release the shared web files. G could not start until E4 +merged, and E4 waited for D5, so the web files had no active owner. H4 +therefore took them, split in two: - **H4a (#55): the Issues screen.** It owned `web/server.ts`, `web/public/*`, a new `web/issues.ts`, the demo fixture From 8f835aa4565944712c40f242d5465f6bbb536859 Mon Sep 17 00:00:00 2001 From: mchwang Date: Sat, 10 Oct 2026 00:39:30 -0700 Subject: [PATCH 38/43] Put the H4b bullet in the past tense (#145) Co-Authored-By: Claude Opus 5.5 --- docs/implementation/issue-prioritization.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/implementation/issue-prioritization.md b/docs/implementation/issue-prioritization.md index 57d23779..637b57d1 100644 --- a/docs/implementation/issue-prioritization.md +++ b/docs/implementation/issue-prioritization.md @@ -89,9 +89,9 @@ therefore took them, split in two: finished and released its shared screen files (see `docs/implementation/planning-screen.md`); `web/server.ts` is lane F's server contract. -- **H4b: the "trust this issue" action.** It records trust decisions through - the storage owner (F) after F1's Store changes land, so the two lanes do not - both bump the schema version. +- **H4b (#108, PR #139): the "trust this issue" action.** It recorded trust + decisions through the storage owner (F) after F1's Store changes landed, so + the two lanes did not both bump the schema version. H1 is complete when this policy and access inspection are committed. H2/H3 are complete when dedicated tests prove normalized retrieval, deterministic reasons, From 8e26937686247234731c6550515a3123bb3d1c90 Mon Sep 17 00:00:00 2001 From: mchwang Date: Sat, 10 Oct 2026 00:41:39 -0700 Subject: [PATCH 39/43] Keep H4b's storage note as the original plan (#145) Co-Authored-By: Claude Opus 5.5 --- docs/implementation/issue-prioritization.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/implementation/issue-prioritization.md b/docs/implementation/issue-prioritization.md index 637b57d1..e94840b5 100644 --- a/docs/implementation/issue-prioritization.md +++ b/docs/implementation/issue-prioritization.md @@ -89,9 +89,9 @@ therefore took them, split in two: finished and released its shared screen files (see `docs/implementation/planning-screen.md`); `web/server.ts` is lane F's server contract. -- **H4b (#108, PR #139): the "trust this issue" action.** It recorded trust - decisions through the storage owner (F) after F1's Store changes landed, so - the two lanes did not both bump the schema version. +- **H4b (#108, PR #139): the "trust this issue" action.** It was planned to + record trust decisions through the storage owner (F) after F1's Store changes + landed, so the two lanes would not both bump the schema version. H1 is complete when this policy and access inspection are committed. H2/H3 are complete when dedicated tests prove normalized retrieval, deterministic reasons, From eded1eb08205acf3de6ca08e67cd8ad069ac3bfa Mon Sep 17 00:00:00 2001 From: mchwang Date: Sat, 10 Oct 2026 00:49:03 -0700 Subject: [PATCH 40/43] Keep plan-format's v1 contract text; list shipped differences separately (#145) Copilot round 3: the guide's suggestion-card wording had been changed to match the shipped screen, which conflicts with the immutable v1 contract (schema/versions/1/semantics.md). Restore the contract-mirroring text, describe what the shipped screen does in its own section, and track the non-conformance in #159. Co-Authored-By: Claude Opus 5.5 --- docs/designs/codeboost-plan-indexed-review.md | 2 +- docs/implementation/planning-screen.md | 6 +++--- docs/plan-format.md | 20 +++++++++++++------ 3 files changed, 18 insertions(+), 10 deletions(-) diff --git a/docs/designs/codeboost-plan-indexed-review.md b/docs/designs/codeboost-plan-indexed-review.md index 82a216eb..8c86ebe7 100644 --- a/docs/designs/codeboost-plan-indexed-review.md +++ b/docs/designs/codeboost-plan-indexed-review.md @@ -569,7 +569,7 @@ The numbers below identify delivery milestones, not a requirement to implement t 3. **Optional validation.** A future real-PR comparison may test the assumptions in "How we will know it works," but it is non-blocking under the superseding decision above. 4. **Merge gate and merging** (product workflow step 9): the merge rules, the pre-merge sequence, and merging through `gh`. Increment 1 merged (PR #23), and merge-queue support merged (#38, #46, closing #24); the rest waits for the runner in build step 5. See the scope and completion criteria below. 5. **Running agents.** Per-task clones, containers, agent adapters, permissions, one invocation per plan item, review rounds, the "already fixed" check, and opening PRs (step 6). Isolation boundary merged (lane D, PRs #31, #40, #44, #47, #50); the runner (lane F) is next. -6. **Planning screen.** Writing plans with an agent, and approving plan changes (steps 2 and 3). *Done for T18:* planning backend (lane E, E1–E4) and the Plans screen (lane G, G1–G4, #145; PRs #148, #150, #151, #152). Not built: paste import, in-screen editing, the amendment-proposal view, check warnings, answering questions and a whole-plan approval step (#155). +6. **Planning screen.** Writing plans with an agent, and approving plan changes (steps 2 and 3). *Done for T18:* planning backend (lane E, E1–E4) and the Plans screen (lane G, G1–G4, #145; PRs #148, #150, #151, #152). Not built: paste import, in-screen editing, the amendment-proposal view, check warnings, answering questions and a whole-plan approval step (#155). The suggestion cards do not yet conform to the v1 contract (#159). 7. **Queue, schedule, and recovery** (steps 4 and 5). 8. **Issue list, sorted by how critical each issue is** (step 1). *Done:* ranking backend (H1–H3), the Issues screen (H4a, #55), and the author-bound "trust this issue" action and runner guard (H4b, #108, PR #139) have merged. 9. **Learning from your feedback** (step 10): lessons, the Lessons inbox, and the Learning screen. It needs the reject loop from steps 4 to 7. diff --git a/docs/implementation/planning-screen.md b/docs/implementation/planning-screen.md index 14e935ae..e31a55f5 100644 --- a/docs/implementation/planning-screen.md +++ b/docs/implementation/planning-screen.md @@ -6,7 +6,7 @@ G1 adds a Plans screen over the planning contracts already owned by lanes E and 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 lose their Apply control and **Refresh suggestions** sends their bounded operation, item and summary descriptions in a new revision-bound request without replacing newer guidance in the textarea. +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 lose their Apply control (the v1 contract requires a disabled one: #159) 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. @@ -40,6 +40,6 @@ Suggestion replies render as plain text followed by one line-separated row per t G1–G4 have merged as PRs #148, #150, #151 and #152, which completes lane G (#145). Lane G no longer owns `web/public/index.html`, `web/public/app.js`, `web/public/style.css`, `test/browser/plans.spec.ts`, `test/browser/plans-authoring.spec.ts`, `test/browser/plans-production.spec.ts` or this document. G3 also edited `web/server.ts` and `test/planning-drafts-api.test.ts`; those stay with lane F, which owns the server contract. Before the next change to any file named above, follow "Task resumption and ownership" in `AGENTS.md`: check open PRs, branches and worktrees first. -Three related issues remain open. #146: `POST /api/plan/import` refuses request bodies over 16 KiB, but some schema-valid plans are larger. The fix is to raise the server's request limit, or to tighten the schema or import bound so the two agree. The screen needs no change. The #145 progress notes record #146 as lane F's work, because `web/server.ts` is an F-owned server contract. +Four related issues remain open. #146: `POST /api/plan/import` refuses request bodies over 16 KiB, but some schema-valid plans are larger. The fix is to raise the server's request limit, or to tighten the schema or import bound so the two agree. The screen needs no change. The #145 progress notes record #146 as lane F's work, because `web/server.ts` is an F-owned server contract. -#155: `docs/plan-format.md` and the design doc describe Plans screen features that were not built: paste import, in-screen plan editing, a view of the runner's amendment proposal, check warnings, answering open questions and a whole-plan approval step. #156: the runner-lifecycle decision to revisit E3's early `cancelled` write at G4 was not recorded. +#155: `docs/plan-format.md` and the design doc describe Plans screen features that were not built: paste import, in-screen plan editing, a view of the runner's amendment proposal, check warnings, answering open questions and a whole-plan approval step. #156: the runner-lifecycle decision to revisit E3's early `cancelled` write at G4 was not recorded. #159: the suggestion cards do not conform to the v1 contract, which requires a disabled sibling Apply and a Dismiss on each card. diff --git a/docs/plan-format.md b/docs/plan-format.md index b11fa704..bf81e00b 100644 --- a/docs/plan-format.md +++ b/docs/plan-format.md @@ -109,7 +109,7 @@ Every consumer of a current plan (execution, review, fixes, and conflict resolut ## Checks after import -The schema checks the shape. codeboost then checks the meaning. A **failure** blocks approval. A **warning** shows on the item, and you can approve anyway. (The Plans screen does not show warnings or have an approval step yet: an import or an applied draft or suggestion creates the next revision directly. #155 tracks both.) +The schema checks the shape. codeboost then checks the meaning. A **failure** blocks approval. A **warning** shows on the item, and you can approve anyway. | Check | Result if it fails | |---|---| @@ -126,7 +126,7 @@ The schema checks the shape. codeboost then checks the meaning. A **failure** bl | The item has at least one `cmd`. | Warning: "No test command" | | Each `cmd` is parsed as one executable and literal arguments, with the entire argv matched element-for-element against a repo-approved argv entry. Prefix matches, appended flags, extra arguments, and argument substitution are not allowed. An unlisted argv needs the person's explicit approval as a new exact allowlist entry; plan approval alone does not grant execution permission. Shell operators, pipelines, redirects, substitutions, and expansions are rejected. Execute the resulting argv without a shell. | Invalid syntax blocks approval; a valid but unlisted command warns and cannot run until allowed | | A completed agent invocation changes a dependency or a script codeboost will run. | Before its own installation or script invocation, codeboost stops in "needs approval". This post-invocation gate cannot prevent an agent from executing a changed script during its invocation; container and network restrictions must already contain that execution. | -| `questions` is not empty. | The plan shows the questions at the top; answer them or approve anyway. (The Plans screen lists them read-only. It has no answer or approve control yet: #155.) | +| `questions` is not empty. | The plan shows the questions at the top; answer them or approve anyway | **Submodules in version 1.** Gitlinks are review-only metadata leaves: the linking engine can display and attribute externally produced pointer changes, but v1 plans cannot author, add, delete, or rename a gitlink. Reject declarations targeting an existing gitlink and reject agent-produced gitlinks. Authoring them requires a future typed target-commit field and runner-controlled operation. Do not initialize or update nested submodule worktrees. Before each invocation that can write the task filesystem (an execute or fix agent, and a check that runs an item's `cmd` there), reject an initialized/populated gitlink directory and bind an empty read-only mount at every existing gitlink path; refuse the invocation if that protection cannot be enforced. A read-only invocation (planning, questions, review, and a check that runs as review) needs neither: its task filesystem is a fresh non-recursive clone, so every gitlink directory is empty, and it is mounted read-only, so nothing can fill one. Every directory above a gitlink is pinned for the invocation too (mounted again at its own path, so it cannot be renamed), so the gitlink's mount cannot be moved aside and its path refilled. Before tests and before committing, inspect gitlink locations without following links and reject nested content, including content under newly introduced gitlinks. A top-level Git diff is not enough. Reviewing submodule pointers reads the Git entry only; the agent never receives an editable nested checkout. Tests must attempt writes beneath a gitlink and provide a pre-populated nested checkout, and both must be refused. @@ -149,18 +149,26 @@ Issue text and agent-produced plan fields remain untrusted. The prompt builder s | Source | What happens | |---|---| | **Claude drafts it** | codeboost runs the agent with the prompt in [`prompts/plan-author.md`](../prompts/plan-author.md) and passes the schema. The answer is a JSON plan. codeboost runs the checks after import and shows the plan on the Plans screen as a draft. | -| **You import a file** | In the Plans screen's Import plan section, pick a `.yaml`, `.yml`, or `.json` file and choose **Import next revision**. (Pasting a plan is not built yet: #155.) codeboost reads it, runs the schema and the checks after import, and saves it as the next revision. The file's `revision` is replaced by the next free number. | -| **You edit on the Plans screen** | *Not built yet (#155).* Each change is checked as you type. Approving saves the revision. | +| **You import a file** | On the Plans screen, choose "Import plan" and pick a `.yaml`, `.yml`, or `.json` file, or paste one. codeboost reads it, runs the schema and the checks after import, and saves it as the next draft revision. The file's `revision` is replaced by the next free number. | +| **You edit on the Plans screen** | Each change is checked as you type. Approving saves the revision. | codeboost keeps the master copy in its own database. The copy in the PR description is written from that master and is never read back. +### What the shipped Plans screen does today + +This guide and the v1 contract describe the full design. The Plans screen built in lane G (#145) differs from it in these ways: + +- **Not built yet (#155):** pasting a plan, editing on the Plans screen, showing check warnings, answering open questions, and a whole-plan approval step. Today an import, or an applied agent draft or suggestion, creates the next revision directly. +- **Does not yet conform to the v1 suggestion-card contract (#159):** after one card is applied, the other cards lose their Apply control instead of showing it disabled. One **Dismiss suggestions** control discards the whole response; cards have no Dismiss of their own. +- **Control names:** the import button is **Import next revision**. A suggestion card's button is **Apply this edit**, and a draft's is **Apply draft**. + ## Suggested edits (plan assistant) When you ask the plan assistant on the Plans screen for changes, it answers in the shape of [`schema/plan-edit.schema.json`](../schema/plan-edit.schema.json): - `reply`: its answer to you, in plain words; - `base_revision`: the revision it read. codeboost refuses edits made against an older revision; -- `edits`: 0 to 10 suggested edits. Each one becomes a card with **Apply this edit**. **Dismiss suggestions** discards the whole response. Nothing changes until you click Apply. Applying one card creates the next revision and makes all remaining cards from that response stale, including independent edits. +- `edits`: 0 to 10 suggested edits. Each one becomes a card with **Apply** and **Dismiss**. Nothing changes until you click Apply. Applying one card creates the next revision and makes all remaining cards from that response stale, including independent edits. | `op` | Fields it uses | What it does | |---|---|---| @@ -174,7 +182,7 @@ When you ask the plan assistant on the Plans screen for changes, it answers in t | `remove_check` | `item`, `check_index` | Removes an acceptance entry by position, starting at 0. | | `set_depends` | `item`, `depends_on` | Replaces the item's `depends_on` list. | -**One card per revision.** Version 1 applies one selected card in one transaction, validates the complete resulting plan, increments the revision, and consumes that suggestion ID. In the same transaction, invalidate every other outstanding suggestion against the old revision. Remaining cards stay visible without Apply. Below them, one "Plan changed — refresh suggestions" line has a **Refresh suggestions** action. Refresh sends the unapplied requested changes and the new current plan to the assistant under a new server-bound request, returning new IDs/revision; the person reviews the new cards before applying another. Never silently bump base_revision or replay old operations (especially positional check indexes). Dismiss does not mutate the plan or revision. Concurrent Apply requests use compare-and-swap: exactly one wins, the other returns stale with no mutation; retrying a consumed ID cannot create another revision. The two edits in the example are alternatives available at revision 3, not two sequentially applicable cards from that same response. Test first Apply, sibling cards without Apply, refresh, second Apply, and concurrent/replayed requests. +**One card per revision.** Version 1 applies one selected card in one transaction, validates the complete resulting plan, increments the revision, and consumes that suggestion ID. In the same transaction, invalidate every other outstanding suggestion against the old revision. Remaining cards show "Plan changed — refresh suggestions" with Apply disabled and a **Refresh suggestions** action. Refresh sends the unapplied requested changes and the new current plan to the assistant under a new server-bound request, returning new IDs/revision; the person reviews the new cards before applying another. Never silently bump base_revision or replay old operations (especially positional check indexes). Dismiss does not mutate the plan or revision. Concurrent Apply requests use compare-and-swap: exactly one wins, the other returns stale with no mutation; retrying a consumed ID cannot create another revision. The two edits in the example are alternatives available at revision 3, not two sequentially applicable cards from that same response. Test first Apply, disabled sibling Apply, refresh, second Apply, and concurrent/replayed requests. **Request identity binding.** `base_revision` is local to one plan, not a globally unique identity. Before an assistant request starts, the server persists an opaque request ID bound to the stable repository/task/plan IDs, schema version, and base revision. Store its response/suggestion IDs under that captured context only; never attach a late result to the currently selected UI plan. Apply accepts a server-issued suggestion ID, loads its bound context, and atomically verifies the target plan identity and revision before mutation. Reject unknown, canceled, cross-plan, or stale requests. A matching revision and item IDs on another plan are insufficient. The assistant response need not echo trusted IDs, and any identity claims in free text are ignored. Test two plans at revision 3 with P1 while a delayed response for A arrives with B selected: B must remain unchanged. From 82b7e5cf3c119cbfdea102df9ab32a398b4bf296 Mon Sep 17 00:00:00 2001 From: mchwang Date: Sat, 10 Oct 2026 00:51:06 -0700 Subject: [PATCH 41/43] Cite #159 in status lines; note the #146 import limit (#145) Co-Authored-By: Claude Opus 5.5 --- docs/designs/codeboost-plan-indexed-review.md | 4 ++-- docs/plan-format.md | 1 + 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/docs/designs/codeboost-plan-indexed-review.md b/docs/designs/codeboost-plan-indexed-review.md index 8c86ebe7..f7d283bc 100644 --- a/docs/designs/codeboost-plan-indexed-review.md +++ b/docs/designs/codeboost-plan-indexed-review.md @@ -27,7 +27,7 @@ Last checked against the code: 2026-09-26 (see "Lane status" under "Parallel bui - **How it stays trustworthy.** codeboost records commits in a trusted ledger with either an owning plan item or an explicit foreign/unowned classification. Rewriting a foreign commit never turns it into owned work. It also checks each change against the files the plan item said it would touch. One blind spot remains: an unrelated edit inside a file the plan item declared is caught only by the review agent and by you. - **How it stays safe.** Agents run inside a container that holds only the task's code and the credential for that phase, so your other files and credentials are not there. Ask, code-writing runs, and conflict resolution use provider-specific containers; exact-head `cmd:` checks use a credential-free read-only profile. codeboost needs your approval before its own dependency installation or invocation of changed scripts; containment must also cover commands the agent already ran. - **It learns from you.** After each task, codeboost turns your feedback into short lessons. You approve each lesson before agents use it, and a Learning screen shows whether you are repeating yourself less. -- **Where the build is.** Built: the plan and linking library, SQLite store, review screen with Ask and change requests, guarded merge gate with merge-queue support, agent isolation boundary, Plans screen (lane G, #145; #155 lists unbuilt parts), opt-in code-writing runner and publishing, durable local rebase/conflict resolution, and pre-merge base/head refresh with exact-head `cmd:` checks. Still deferred: pushing the rewritten head, waiting for its required checks, handing that exact pair to guarded merge, and the Queue, Lessons and Learning screens (the ranked Issues screen is built). Optional real-PR validation is tracked separately in #19 and is not a prerequisite. +- **Where the build is.** Built: the plan and linking library, SQLite store, review screen with Ask and change requests, guarded merge gate with merge-queue support, agent isolation boundary, Plans screen (lane G, #145; #155 lists unbuilt parts and #159 tracks suggestion-card non-conformance), opt-in code-writing runner and publishing, durable local rebase/conflict resolution, and pre-merge base/head refresh with exact-head `cmd:` checks. Still deferred: pushing the rewritten head, waiting for its required checks, handing that exact pair to guarded merge, and the Queue, Lessons and Learning screens (the ranked Issues screen is built). Optional real-PR validation is tracked separately in #19 and is not a prerequisite. ## Terms used @@ -653,7 +653,7 @@ Report the declared-file catch rate for both methods, with no pass bar. It shows ## What to do next -1. Done: create the repository, README, plan/linking foundation, persistent store, and read-only review screen. Also done: the guarded merge gate (PR #23), planning audit and authoring contract (E1, E2), suggestion orchestration (E3), issue ranking backend (H1–H3), merge-queue support (K1–K3), the agent isolation boundary (D1–D5), the runner lifecycle contract (F1), the Issues screen (H4a), planning acceptance (E4) and the Plans screen (G1–G4, #145; #155 lists unbuilt parts). +1. Done: create the repository, README, plan/linking foundation, persistent store, and read-only review screen. Also done: the guarded merge gate (PR #23), planning audit and authoring contract (E1, E2), suggestion orchestration (E3), issue ranking backend (H1–H3), merge-queue support (K1–K3), the agent isolation boundary (D1–D5), the runner lifecycle contract (F1), the Issues screen (H4a), planning acceptance (E4) and the Plans screen (G1–G4, #145; #155 lists unbuilt parts and #159 tracks suggestion-card non-conformance). 2. Finish the open lane work listed in the lane table in `docs/architecture.md`, then continue the roadmap from the current open issues; the cancelled experiment is not a prerequisite. 3. Optionally run the non-blocking human validation tracked in #19. 4. The engineering review (2026-09-22) settled how agents run, their container, network, and permissions. Re-run `/plan-eng-review` before implementing code-writing agents if anything in those areas changes. diff --git a/docs/plan-format.md b/docs/plan-format.md index bf81e00b..079ad7e9 100644 --- a/docs/plan-format.md +++ b/docs/plan-format.md @@ -160,6 +160,7 @@ This guide and the v1 contract describe the full design. The Plans screen built - **Not built yet (#155):** pasting a plan, editing on the Plans screen, showing check warnings, answering open questions, and a whole-plan approval step. Today an import, or an applied agent draft or suggestion, creates the next revision directly. - **Does not yet conform to the v1 suggestion-card contract (#159):** after one card is applied, the other cards lose their Apply control instead of showing it disabled. One **Dismiss suggestions** control discards the whole response; cards have no Dismiss of their own. +- **Import size (#146):** the server refuses import requests over 16 KiB, so some schema-valid plans cannot be imported yet. - **Control names:** the import button is **Import next revision**. A suggestion card's button is **Apply this edit**, and a draft's is **Apply draft**. ## Suggested edits (plan assistant) From d30cd4790b39e44cd37142514d5d7cf01753edec Mon Sep 17 00:00:00 2001 From: mchwang Date: Sat, 10 Oct 2026 00:56:54 -0700 Subject: [PATCH 42/43] List the amendment-proposal gap in plan-format's shipped section (#145) Co-Authored-By: Claude Opus 5.5 --- docs/plan-format.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/plan-format.md b/docs/plan-format.md index 079ad7e9..a5f09b12 100644 --- a/docs/plan-format.md +++ b/docs/plan-format.md @@ -158,7 +158,7 @@ codeboost keeps the master copy in its own database. The copy in the PR descript This guide and the v1 contract describe the full design. The Plans screen built in lane G (#145) differs from it in these ways: -- **Not built yet (#155):** pasting a plan, editing on the Plans screen, showing check warnings, answering open questions, and a whole-plan approval step. Today an import, or an applied agent draft or suggestion, creates the next revision directly. +- **Not built yet (#155):** pasting a plan, editing on the Plans screen, showing check warnings, answering open questions, a whole-plan approval step, and the amendment-proposal flow (the runner does not save a plan-change proposal, and the Plans screen cannot show or edit one; see "When the plan is wrong" in the design doc). Today an import, or an applied agent draft or suggestion, creates the next revision directly. - **Does not yet conform to the v1 suggestion-card contract (#159):** after one card is applied, the other cards lose their Apply control instead of showing it disabled. One **Dismiss suggestions** control discards the whole response; cards have no Dismiss of their own. - **Import size (#146):** the server refuses import requests over 16 KiB, so some schema-valid plans cannot be imported yet. - **Control names:** the import button is **Import next revision**. A suggestion card's button is **Apply this edit**, and a draft's is **Apply draft**. From befe2048e7f51b1b386c63c394d18608b72549fe Mon Sep 17 00:00:00 2001 From: mchwang Date: Sat, 10 Oct 2026 00:59:27 -0700 Subject: [PATCH 43/43] Record that #146 was fixed by PR #158 (#145) Co-Authored-By: Claude Opus 5.5 --- docs/implementation/planning-screen.md | 2 +- docs/plan-format.md | 1 - 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/docs/implementation/planning-screen.md b/docs/implementation/planning-screen.md index e31a55f5..b256af71 100644 --- a/docs/implementation/planning-screen.md +++ b/docs/implementation/planning-screen.md @@ -40,6 +40,6 @@ Suggestion replies render as plain text followed by one line-separated row per t G1–G4 have merged as PRs #148, #150, #151 and #152, which completes lane G (#145). Lane G no longer owns `web/public/index.html`, `web/public/app.js`, `web/public/style.css`, `test/browser/plans.spec.ts`, `test/browser/plans-authoring.spec.ts`, `test/browser/plans-production.spec.ts` or this document. G3 also edited `web/server.ts` and `test/planning-drafts-api.test.ts`; those stay with lane F, which owns the server contract. Before the next change to any file named above, follow "Task resumption and ownership" in `AGENTS.md`: check open PRs, branches and worktrees first. -Four related issues remain open. #146: `POST /api/plan/import` refuses request bodies over 16 KiB, but some schema-valid plans are larger. The fix is to raise the server's request limit, or to tighten the schema or import bound so the two agree. The screen needs no change. The #145 progress notes record #146 as lane F's work, because `web/server.ts` is an F-owned server contract. +The import size gap that G1 found (#146) was fixed by lane F in PR #158: `POST /api/plan/import` now admits every source within the parser's 1 MiB limit (see `docs/plan-format.md`). Three related issues remain open. #155: `docs/plan-format.md` and the design doc describe Plans screen features that were not built: paste import, in-screen plan editing, a view of the runner's amendment proposal, check warnings, answering open questions and a whole-plan approval step. #156: the runner-lifecycle decision to revisit E3's early `cancelled` write at G4 was not recorded. #159: the suggestion cards do not conform to the v1 contract, which requires a disabled sibling Apply and a Dismiss on each card. diff --git a/docs/plan-format.md b/docs/plan-format.md index a5a9eb6e..24bf73d3 100644 --- a/docs/plan-format.md +++ b/docs/plan-format.md @@ -162,7 +162,6 @@ This guide and the v1 contract describe the full design. The Plans screen built - **Not built yet (#155):** pasting a plan, editing on the Plans screen, showing check warnings, answering open questions, a whole-plan approval step, and the amendment-proposal flow (the runner does not save a plan-change proposal, and the Plans screen cannot show or edit one; see "When the plan is wrong" in the design doc). Today an import, or an applied agent draft or suggestion, creates the next revision directly. - **Does not yet conform to the v1 suggestion-card contract (#159):** after one card is applied, the other cards lose their Apply control instead of showing it disabled. One **Dismiss suggestions** control discards the whole response; cards have no Dismiss of their own. -- **Import size (#146):** the server refuses import requests over 16 KiB, so some schema-valid plans cannot be imported yet. - **Control names:** the import button is **Import next revision**. A suggestion card's button is **Apply this edit**, and a draft's is **Apply draft**. ## Suggested edits (plan assistant)