@@ -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)
 
@@ -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
 
@@ -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.