diff --git a/docs/designs/codeboost-plan-indexed-review.md b/docs/designs/codeboost-plan-indexed-review.md index 1ce0aa2d..6b4a3ae2 100644 --- a/docs/designs/codeboost-plan-indexed-review.md +++ b/docs/designs/codeboost-plan-indexed-review.md @@ -1922,14 +1922,14 @@ Read each row left to right: finish and validate step 1 before step 2 within tha | C — guarded merge gate | **C1.** Required-check and branch-rule reads (T12). **C2.** Snapshot/evidence blockers, with unavailable T6 execution evidence blocking merge. **C3.** Head-pinned, base-protected merge and refusal handling (T7). **C4.** Review UI, race regressions and final #21 / PR #23 review. | Before C1, record B0 evidence for the foundation contracts C consumes; existing work must supply that evidence before C4 completion. Continue existing work rather than restarting implemented steps. Release shared runner/UI files after C4 merges. | | D — agent isolation | **D1.** Invocation contract and isolated task clone (T1). **D2.** Pinned, restricted container and startup self-test (T1). **D3.** Vendor-only egress and phase/tool enforcement (T2). **D4.** Claude/Codex adapters, cancellation settlement and bounded output. **D5.** Full real-Docker and hostile-input gate for this boundary (T9). | Can run alongside C and E. F requires D5 merged; G's production invocation requires D5. Add regressions with each step; D5 integrates them rather than postponing testing. | | E — planning logic | **E1.** Audit existing T18 schema/parser/prompt behavior and remaining #6 gaps. **E2.** Read-only authoring-provider contract and safe prompt/response handling. **E3.** Identity/revision-bound suggestion orchestration using the existing store interface. **E4.** Import, replay, malformed-response and hostile-input acceptance fixtures (T18). | Can run alongside C and D with injected providers. G consumes E4; live invocation waits for D5. Shared schema/store fixes must go through the assigned integration owner. | -| F — runner and pre-merge automation | **F1.** Before implementation, publish and review the lifecycle/state-holder contract: pending, running, completed, failed, cancelled, stale and closing; legal transitions; ownership and settlement for persisted records, in-memory jobs, subprocesses, admitted HTTP requests and rendered UI; guarded retry; reject-admission → drain requests → cancel/await jobs → close storage. Then implement it and the feedback-event contract under the AGENTS.md async rules. **F2.** Per-item execution, review/reject rounds, pre-PR already-fixed checks, PR opening and hostile-issue eval (build step 5; T9). **F3.** Trusted rebase and ledger mapping (remaining T3). **F4.** Foreign-commit conflict handling (T11). **F5.** Post-rebase attribution/approval refresh and head-bound command execution (T6). **F6.** Required-check refresh, already-fixed check, guarded merge handoff and #22 integration regressions. F owns common CI after C: integrate every T9 suite (Docker, adapter, hostile-input/issue, recorded-output, unit and browser) into required CI, coordinating D's dedicated workflow. T9 remains incomplete until the combined head demonstrably runs and passes every suite. *F6c status:* the workflows are in place (`docs/implementation/ci.md`); required-check settings, a passing run of both required jobs on one head and a green `Live probes` run remain. | Starts after C4 and D5 merge and B0 evidence is handed off for F's consumed contracts. Recheck that evidence against merged main before F1; existing T4/T5/T10 behavior is reused rather than rebuilt. F1 owns planning persistence/API additions needed by G. F2's working reject loop supplies the learning dependency. Ask already uses D's invocation contract (`runner/question-container.ts`), so F reuses that path rather than adding a second one. | +| F — runner and pre-merge automation | **F1.** Before implementation, publish and review the lifecycle/state-holder contract: pending, running, completed, failed, cancelled, stale and closing; legal transitions; ownership and settlement for persisted records, in-memory jobs, subprocesses, admitted HTTP requests and rendered UI; guarded retry; reject-admission → drain requests → cancel/await jobs → close storage. Then implement it and the feedback-event contract under the AGENTS.md async rules. **F2.** Per-item execution, review/reject rounds, pre-PR already-fixed checks, PR opening and hostile-issue eval (build step 5; T9). **F3.** Trusted rebase and ledger mapping (remaining T3). **F4.** Foreign-commit conflict handling (T11). **F5.** Post-rebase attribution/approval refresh and head-bound command execution (T6). **F6.** Required-check refresh, already-fixed check, guarded merge handoff and #22 integration regressions. F owns common CI after C: integrate every T9 suite (Docker, adapter, hostile-input/issue, recorded-output, unit and browser) into required CI, coordinating D's dedicated workflow. T9 remains incomplete until the combined head demonstrably runs and passes every suite. *F6c status:* complete on 2026-10-19. The workflows are in place (`docs/implementation/ci.md`), `test` and `real-docker` are required on `main` and passed on the combined head `ba8294d` (before the ruleset existed), and a `Live probes` run passed, so T9 is ticked. | Starts after C4 and D5 merge and B0 evidence is handed off for F's consumed contracts. Recheck that evidence against merged main before F1; existing T4/T5/T10 behavior is reused rather than rebuilt. F1 owns planning persistence/API additions needed by G. F2's working reject loop supplies the learning dependency. Ask already uses D's invocation contract (`runner/question-container.ts`), so F reuses that path rather than adding a second one. | | G — planning screen | **G1.** Import and plan display UI. **G2.** Authoring and suggestion cards. **G3.** Revision-bound Apply and draft/attachment preservation. **G4.** Real provider/store integration and complete T18 browser/adapter acceptance. | G1 starts after E4 and C4 merge; G1–G3 may use fixtures. G4 waits for D5 and F1's production planning API/persistence contract. Release shared web files after G4. | | H — issue prioritization | **H1.** Decide and record ranking policy. **H2.** Issue retrieval/normalization. **H3.** Deterministic ranking with reasons and failure/stale states. **H4.** Issue-list UI and end-to-end checks (build step 8). | H1–H3 can run alongside F/G after the issue-access contract is inspected. H4 waits for G4 to release shared web files. No existing T-ID covers this entire milestone. | | I — queue, schedule and recovery | **I1.** Queue admission and persisted transitions. **I2.** Run-window scheduling and cancellation. **I3.** Restart recovery, stale attempts and shutdown draining. **I4.** UI integration and controlled race acceptance (build step 7). | Starts after F6; owns shared runner/store files. UI work waits for G/H to release its exact files. No existing T-ID covers this entire milestone. | | J — lessons and learning | **J1.** Source-linked feedback distillation and quality fixtures (T15). **J2.** Approved-only lesson persistence and prompt injection (T15). **J3.** Lessons inbox controls and repository scope (T16). **J4.** Metrics, repeated-feedback flags and Learning screen (T17). | Starts after F6, using F2's reject loop. J1 can run alongside I with injected storage. J2 shared wiring waits for I's storage ownership handoff; J3/J4 wait for the web owner. End-to-end reject → lesson → approval → injection is required. | | K — merge-queue compatibility | **K1.** Queued/removed/failed/merged adapter contract and fixtures. **K2.** Persisted lifecycle and retry guards. **K3.** Complete #24 acceptance: preserve the exact reviewed head, disable the action while queued, await confirmed MERGED or removal/failure, surface the terminal reason, and test enqueue success, delayed merge, queue removal, head replacement and retry. Enqueue success never completes the merge; a replaced head requires fresh review before retry. | K1 can use a free slot after C4. K2/K3 wait for the runner/web owners to release their exact files; no concurrent edits to F/I or G/H/J integration files. Queue merging stayed disabled until K3 passed; K2 and K3 are complete (#46), and queue merging is enabled for an adapter that implements the K1 observation contract. | -**Complete T-ID mapping:** T1 → D1–D2; T2 → D3; T3 → B0 verification then F3; T4 → B0 (consumed by C/F); T5 → B0 (consumed by C/F); T6 → C2's blocking subset then F5–F6; T7 → C3; T8 → cancelled, no implementation lane (fresh optional validation only in #19); T9 → F6 (common-CI integration and all-suite completion gate), D5 (Docker and adapter probes), C1/C3 (recorded GitHub outputs), E4 (recorded authoring outputs), F2 (hostile-issue eval), and each lane's applicable unit/browser suites; T10 → B0 (consumed by C/F); T11 → F4; T12 → C1 then F6 revalidation; T13 → B0; T14 → B0; T15 → J1–J2; T16 → J3; T17 → J4; T18 → E1–E4 then G1–G4. Shared requirements are complete only after all assigned slices meet the original acceptance criteria. +**Complete T-ID mapping:** T1 → D1–D2; T2 → D3; T3 → B0 verification then F3; T4 → B0 (consumed by C/F); T5 → B0 (consumed by C/F); T6 → C2's blocking subset then F5–F6; T7 → C3; T8 → cancelled, no implementation lane (fresh optional validation only in #19); T9 → F6 (common-CI integration and all-suite completion gate; complete 2026-10-19), D5 (Docker and adapter probes), C1/C3 (recorded GitHub outputs), E4 (recorded authoring outputs), F2 (hostile-issue eval), and each lane's applicable unit/browser suites; T10 → B0 (consumed by C/F); T11 → F4; T12 → C1 then F6 revalidation; T13 → B0; T14 → B0; T15 → J1–J2; T16 → J3; T17 → J4; T18 → E1–E4 then G1–G4. Shared requirements are complete only after all assigned slices meet the original acceptance criteria. **Default dispatch order:** first C, D and E. As their prerequisites land, fill available slots with F, G and H; do not wait for unrelated lanes to finish. After F6, start I and J, retaining H if unfinished. K uses a free slot when its file dependencies permit. B0 is a short prerequisite inspection inside the relevant consuming task, not an extra concurrent implementation slot. Optional #19 and schema follow-ups #5/#7 are outside this default queue. @@ -1981,7 +1981,7 @@ F, G and H ran together within these ownership boundaries. G and H are done; for Built from this review's findings. Each task comes from a specific decision above. Run with Claude Code or Codex, and tick each one as you ship it. Effort ratios assumed: features about 30x, tests about 50x, architecture about 5x. -**Status (checked against `main` on 2026-09-26, lane B0).** T1, T2, T4, T5, T10, T13 and T14 meet their Verify lines and are ticked, with evidence under each (T1, T2 and T14 re-checked 2026-09-26 after lane D merged). T9 stays open. Lane F6 (common CI) has added the workflows in `docs/implementation/ci.md`: `test` and `real-docker` run on every pull request with no path filter, and `Live probes` runs the live Claude probes nightly and by hand. T9 can be ticked when a repository administrator requires `test` and `real-docker` on `main`, both pass on the same head, and a `Live probes` run passes with the `CLAUDE_CODE_OAUTH_TOKEN` secret. Ask calls the `agents/` boundary from `runner/question-container.ts`; it has no host adapter. The planned files `core/segments`, `core/choices` and `core/attribution` were never created. That logic lives in `core/linking.ts` (segments and ledger attribution) and `core/approvals.ts` (approvals and duplicate-segment choices). The Files lines below now name the real files. +**Status (checked against `main` on 2026-09-26, lane B0).** T1, T2, T4, T5, T10, T13 and T14 meet their Verify lines and are ticked, with evidence under each (T1, T2 and T14 re-checked 2026-09-26 after lane D merged). T9 was ticked on 2026-10-19 (checked against `main` that day), with evidence under it. Lane F6 (common CI) added the workflows in `docs/implementation/ci.md`: `test` and `real-docker` run on every pull request with no path filter, and `Live probes` runs the live Claude probes nightly and by hand. The ruleset "main checks" requires `test` and `real-docker` on `main`, both passed on the combined head `ba8294d`, and a `Live probes` run passed with the `CLAUDE_CODE_OAUTH_TOKEN` secret. Ask calls the `agents/` boundary from `runner/question-container.ts`; it has no host adapter. The planned files `core/segments`, `core/choices` and `core/attribution` were never created. That logic lives in `core/linking.ts` (segments and ledger attribution) and `core/approvals.ts` (approvals and duplicate-segment choices). The Files lines below now name the real files. These `T` IDs are requirement identifiers, not the build-order numbers. Current merge-gate work is **build step 4, increment 1 (#21)** and spans parts of T6, T7, and T12; it is unrelated to the numbering of T4. See “Build step 4: scope and progress” for the current increment and remaining milestone criteria. An increment must not mark a broader requirement complete while any of its acceptance criteria remain deferred. @@ -2021,10 +2021,11 @@ These `T` IDs are requirement identifiers, not the build-order numbers. Current - Surfaced by: R3 (D4: A), O5, O9 (D19: A) - Files: scripts/plant.ts, docs/experiments/review-protocol.md - Outcome: no experimental result or product claim; future work must start with a fresh protocol and fresh blinded packages -- [ ] **T9 (P1, human: ~2 weeks / CC: ~3 hours)** — tests — Set up Vitest, real git, recorded gh and CLI outputs, the real-Docker CI suite, Playwright, and the hostile-issue eval +- [x] **T9 (P1, human: ~2 weeks / CC: ~3 hours)** — tests — Set up Vitest, real git, recorded gh and CLI outputs, the real-Docker CI suite, Playwright, and the hostile-issue eval - Surfaced by: T1 (D10: A) - Files: test/, .github/workflows/ - Verify: CI runs every suite; the Docker suite fails if isolation breaks, a read-only phase can write `/work`, planning/questions can execute a process, or task/scratch byte and inode caps can be exceeded; hard-link and alias-write attempts from `.git/config` and objects into `/work` or scratch, and mountpoint replacement, must fail with metadata unchanged; both vendor startup probes must read the container schema and return bounded valid output through their documented file/stdout channel. *Changed 2026-10-01 (#93):* Codex is refused in every phase, because it cannot read files without its shell. Until #93 is revisited, only the Claude startup probes run, and tests confirm that every Codex phase is refused before anything is allocated + - Evidence (2026-10-19): on the combined head `ba8294d` on `main` (F6c, PR #177), CI `test` passed ([run 39115311602](https://github.com/codeabovelab/codeboost/actions/runs/39115311602)) and Agent isolation `real-docker` passed ([run 39115311588](https://github.com/codeabovelab/codeboost/actions/runs/39115311588)); the active repository ruleset "main checks" requires `test` and `real-docker` on `main` (not `live-probes`, by design); a `live-probes` run started by hand on `main` at `ba8294d` passed all 4 live Claude probes ([run 39206371497](https://github.com/codeabovelab/codeboost/actions/runs/39206371497)) with the `CLAUDE_CODE_OAUTH_TOKEN` secret, and nightly runs start at 06:23 UTC. Recorded Claude planning fixtures replay in `test`; recording them again is a manual step. The startup probes are Claude-only under the #93 change above. Details: `docs/implementation/ci.md` ("T9 status") - [x] **T10 (P2, human: ~2 hours / CC: ~10 min)** — core — Duplicate-segment key: file, content, copy number, and copy count - Surfaced by: R4 (D5: A), O1 (D11: A) - Files: core/approvals.ts `choiceKeys` (planned as core/choices) diff --git a/docs/implementation/agent-isolation.md b/docs/implementation/agent-isolation.md index 3760e1af..53bf794f 100644 --- a/docs/implementation/agent-isolation.md +++ b/docs/implementation/agent-isolation.md @@ -416,10 +416,10 @@ against real Docker, including two reviews with different Ask owners on one daem startup path. Start the workflow by hand, or run the probes locally, before a release that changes the image, the adapters or the prompts. Codex has no live probe while it is refused in every phase (#93). -- T9 as a whole is not complete yet. Lane F6 has added the workflows ([CI](ci.md)). What - remains: a repository administrator must require `test` and `real-docker` on `main`; - both jobs must pass on the same head after that; and a `Live probes` run must pass - once the secret exists. +- T9 as a whole is complete as of 2026-10-19. `test` and `real-docker` are + required on `main`, both passed on the same head (before the checks were required), + and a `Live probes` run passed. [CI](ci.md#t9-status) gives the evidence and says how + to keep it green. - Gitlink mounts and the pre-launch check apply to execute and fix only. In planning, questions and review, `/work` is a read-only volume, so nothing can be written beneath a gitlink there; that includes `check` attempts, which run as review. Running an item's `cmd` in a writable task filesystem is not built yet; when it is, each run must call diff --git a/docs/implementation/ci.md b/docs/implementation/ci.md index b10e663f..c94decad 100644 --- a/docs/implementation/ci.md +++ b/docs/implementation/ci.md @@ -167,7 +167,8 @@ Codex has no probe, because Codex is refused in every phase (#93). ## Settings for a repository administrator -The repository cannot make these settings itself. +The repository cannot make these settings itself. Both were made on +2026-10-19 (see [T9 status](#t9-status)). 1. **Required checks on `main`.** In the branch protection rule or ruleset for `main`, require the status checks `test` and `real-docker`. Do not require @@ -208,11 +209,38 @@ To run the live probes locally, set `CODEBOOST_RUN_AUTH_PROBES=1` and `CLAUDE_CODE_OAUTH_TOKEN`, then run the `vitest` command from `live-probes.yml`. -## What remains before T9 is complete - -T9 in the [plan](../designs/codeboost-plan-indexed-review.md) stays open until -all of these are true: - -1. A repository administrator requires `test` and `real-docker` on `main`. -2. Both required jobs pass on the same head after this setup is merged. -3. The `CLAUDE_CODE_OAUTH_TOKEN` secret exists and a `live-probes` run passes. +## T9 status + +T9 in the [plan](../designs/codeboost-plan-indexed-review.md) is complete as of +2026-10-19. The evidence: + +1. Since 2026-10-19, the active repository ruleset "main checks" requires + `test` and `real-docker` on `main`. It does not require `live-probes`, by + design. +2. Both required jobs passed on the same head, `ba8294d` on `main` (the F6c + merge, PR #177): [`test`](https://github.com/codeabovelab/codeboost/actions/runs/39115311602) + and [`real-docker`](https://github.com/codeabovelab/codeboost/actions/runs/39115311588). + These runs came before the ruleset existed. Every merge into `main` from + now on, starting with the pull request that records this status, must pass + both required checks. +3. The `CLAUDE_CODE_OAUTH_TOKEN` secret exists. A `live-probes` run started by + hand on 2026-10-19 on `main` at `ba8294d` + [passed](https://github.com/codeabovelab/codeboost/actions/runs/39206371497), + and its report check printed "All 4 live Claude probes passed." Nightly + runs start at 06:23 UTC. + +The probes are Claude-only, because Codex is refused in every phase (#93). + +To keep T9 green: + +- Keep `test` and `real-docker` required on `main`, and do not rename either + job (see [Workflows](#workflows)). +- Keep the `CLAUDE_CODE_OAUTH_TOKEN` secret valid. If it is removed, every + `live-probes` run fails at its first step. If it expires, the runs fail + later, at the step that runs the probes. +- If GitHub disables the scheduled `Live probes` workflow after 60 days without + repository activity, turn it on again (see [`live-probes`](#live-probes)). +- When `test/planning-recorded.test.ts` fails because a recording is stale, + record the fixtures again by hand (see + [Record the planning fixtures again](#record-the-planning-fixtures-again)). + No workflow records them. diff --git a/docs/implementation/planning-acceptance.md b/docs/implementation/planning-acceptance.md index e177b4f1..37eabaa6 100644 --- a/docs/implementation/planning-acceptance.md +++ b/docs/implementation/planning-acceptance.md @@ -88,9 +88,7 @@ composes the browser with production planning setup, lane D's provider boundary, F's HTTP lifecycle and Store persistence in `plans-production.spec.ts`. The exact-head real-Docker planning gate also passes, completing T18. -T9 is still incomplete. F6 runs the recordings in both required jobs, `test` and -`real-docker`, and the live Claude probes in the nightly `Live probes` workflow -([CI](ci.md)). No workflow records fixtures: when a recording goes stale, run -`scripts/record-planning.ts` again as above. T9 can be ticked when a repository -administrator requires `test` and `real-docker` on `main`, both pass on the same head, -and a `Live probes` run passes with the `CLAUDE_CODE_OAUTH_TOKEN` secret. +T9 is complete as of 2026-10-19 ([CI](ci.md#t9-status)). F6 runs the recordings in +both required jobs, `test` and `real-docker`, and the live Claude probes in the +nightly `Live probes` workflow. No workflow records fixtures: when a recording goes +stale, run `scripts/record-planning.ts` again as above.