@mrciphersmith/keryx 0.3.117 → 0.3.119

package/src/gdskills/bundled/skills/orchestration/flow-orchestrator/SKILL.md

@@ -628,7 +628,7 @@ keryx flow complete <id>
 
 Completion is allowed only after the PR merge has been confirmed. The merge
 target must be the base branch captured when the flow was created; do not
-silently retarget or close against another branch. The flow folder is committed in the same PR as the code; the commit at closing is a rule to follow, not one the gate checks. `flow complete` fails the `folder-committed` gate while the flow's `flow.json` is not in `HEAD` (flows created from 0.3.53 on; commit it with `git add .metaproject/flows/<dir> && git commit`, then run `flow complete` again). `flow init` and `flow renumber` avoid numbers used on known remote branches, and `keryx flow check` reports a clash with a remote branch (repair with `keryx flow renumber <dir> --to <free id> --reason "<why>"`) and warns about a folder that is not committed. Flows created since the owner gate fail completion while no owner is set (`keryx flow owner set <id> --owner "<name>" --reason "<why>"`); `ac confirm` and `flow complete` append a signature — `--signed-by "<name>"` names the signer, otherwise `KERYX_ACTOR` or the local git identity is recorded, as a claim. A flow created with `--require-confirmation` needs one more gate — `--confirm-token <token>` from `keryx flow confirm <id>`, a short-lived single-use token minted by a typed challenge in a terminal; it proves an interactive step ran outside the agent's tool roster, not that a human ran it. A flow left stuck in `completing` by a crash or interrupted attempt (never a normal gate failure) recovers with `keryx flow recover <id> --reason "<why>"`.
+silently retarget or close against another branch. The flow folder is committed in the same PR as the code; the commit at closing is a rule to follow, not one the gate checks. `flow complete` fails the `folder-committed` gate while the flow's `flow.json` is not in `HEAD` (flows created from 0.3.53 on; commit it with `git add .metaproject/flows/<dir> && git commit`, then run `flow complete` again). `flow init` and `flow renumber` avoid numbers used on known remote branches, and `keryx flow check` reports a clash with a remote branch (repair with `keryx flow renumber <dir> --to <free id> --reason "<why>"`) and warns about a folder that is not committed. Flows created since the owner gate fail completion while no owner is set (`keryx flow owner set <id> --owner "<name>" --reason "<why>"`); `ac confirm` and `flow complete` append a signature — `--signed-by "<name>"` names the signer, otherwise `KERYX_ACTOR` or the local git identity is recorded, as a claim. A flow created with `--require-confirmation` needs one more gate — `--confirm-token <token>` from `keryx flow confirm <id>`, a short-lived single-use token. In keryx shell call the `flow_confirm` tool (the operator answers it as a card; never send the operator to a terminal); outside it, a typed challenge in a terminal mints it. It proves an interactive step ran, not that a human ran it. A flow left stuck in `completing` by a crash or interrupted attempt (never a normal gate failure) recovers with `keryx flow recover <id> --reason "<why>"`.
 
 If gates fail, the CLI returns the flow to `in-progress`. Add a journal note,
 create fix tasks, and repeat Phase 2.

package/src/gdskills/bundled/skills/platform/scheduled-tasks/SKILL.md

@@ -55,7 +55,7 @@ operator reads in the shell's Schedules section.
 Call `schedule_create`. The operator then sees a confirmation card: cadence and
 next runs, prompt, runner, budget, network, every granted tool with its binary
 and account, and exactly what gets installed. You do not confirm it. Only the
-operator can, and every permission mode asks, `auto` included.
+operator can, and every permission mode asks, `auto` included. Changing an existing schedule works the same way (`schedule_pause`, `schedule_resume`, `schedule_run`, `schedule_remove`): the operator answers a card; never send them to a terminal.
 
 ### Step 4: Report back
 After the operator's answer, say what was scheduled and when it next runs, or
@@ -72,7 +72,7 @@ that nothing was written. Point to `/schedules` for the list and the reports.
 - NEVER read or copy the schedule signing key (`schedule-hmac.key`), and never try to
   reach the scheduler another way (quoting, `env -u`, a script). The text floor can be
   worked around, and that is exactly why it is not the gate. `keryx schedule add|resume|run`
-  need the operator's own terminal, and a schedule without this machine's signature never runs.
+  need the operator's own terminal (inside keryx shell the operator answers the card instead), and a schedule without this machine's signature never runs.
 - NEVER run `loginctl enable-linger`. If linger is off, tell the operator the
   timer runs only while they are logged in and that the command is theirs to run.
 - State the limits when they matter: the machine must be on; systemd and launchd

package/src/gdskills/bundled/skills/review/review-architecture/SKILL.md

@@ -26,7 +26,7 @@ license: "MIT"
 
 Specialized reviewer for **architectural patterns and structural decisions**.
 Reviews only changes introduced in the current branch (merge-base to HEAD).
-Focuses exclusively on verifiable structural violations — not style opinions or hypothetical concerns.
+Focuses exclusively on verifiable structural violations — not style opinions or hypothetical concerns. Its inputs are the reviewer payload only; session memory and earlier conversation are not inputs.
 
 ---
 

package/src/gdskills/bundled/skills/review/review-backend/SKILL.md

@@ -26,7 +26,7 @@ license: "MIT"
 
 Focused backend reviewer covering NestJS patterns, REST API design, database access patterns,
 and TypeScript correctness for service-layer code. This skill does NOT duplicate security or
-performance checks — those belong to `review-security-code` and `review-performance`.
+performance checks — those belong to `review-security-code` and `review-performance`. Its inputs are the reviewer payload only; session memory and earlier conversation are not inputs.
 
 ---
 

package/src/gdskills/bundled/skills/review/review-clean-code/SKILL.md

@@ -27,7 +27,7 @@ license: "MIT"
 # Review: Clean Code + SOLID
 
 Specialized reviewer for **Clean Code principles** (Robert C. Martin) and **SOLID** at the
-function and class level. Focuses on code in the current branch diff only.
+function and class level. Focuses on code in the current branch diff only. Its inputs are the reviewer payload only; session memory and earlier conversation are not inputs.
 
 The goal is not stylistic nitpicking — every finding here points to a concrete
 maintainability, readability, or extensibility problem that will cause friction

package/src/gdskills/bundled/skills/review/review-core-boundaries/SKILL.md

@@ -24,7 +24,7 @@ license: "MIT"
 # Review — Core Boundaries
 
 Reviewer for shared infrastructure modules. A core module should provide stable foundations
-used by feature modules; it should not accumulate feature-specific behaviour.
+used by feature modules; it should not accumulate feature-specific behaviour. Its inputs are the reviewer payload only; session memory and earlier conversation are not inputs.
 
 ---
 

package/src/gdskills/bundled/skills/review/review-flow-graph/SKILL.md

@@ -24,7 +24,7 @@ license: "MIT"
 # Review — Flow Graph Abstractions
 
 Reviewer for reusable ReactFlow/graph integration layers. Use it when a repository has a shared
-graph surface consumed by domain modules.
+graph surface consumed by domain modules. Its inputs are the reviewer payload only; session memory and earlier conversation are not inputs.
 
 ---
 

package/src/gdskills/bundled/skills/review/review-frontend/SKILL.md

@@ -21,7 +21,7 @@ license: "MIT"
 
 ## Purpose
 
-Validates frontend-specific patterns in the changed code of the current branch. Covers React component correctness (observer wrapping, MVVM boundary, useEffect misuse, accessibility basics, key props), full MobX store patterns (structure, member ordering, accessibility modifiers, observable collections, reactions, async actions, bidirectional sync, lifecycle, API placement), and TypeScript safety.
+Validates frontend-specific patterns in the changed code of the current branch. Covers React component correctness (observer wrapping, MVVM boundary, useEffect misuse, accessibility basics, key props), full MobX store patterns (structure, member ordering, accessibility modifiers, observable collections, reactions, async actions, bidirectional sync, lifecycle, API placement), and TypeScript safety. Its inputs are the reviewer payload only; session memory and earlier conversation are not inputs.
 
 This skill consolidates what was previously split between `code-style-review` (frontend parts) and `code-mobx-store-review`. It supersedes both for frontend changes.
 

package/src/gdskills/bundled/skills/review/review-frontend-conventions/SKILL.md

@@ -28,7 +28,7 @@ license: "MIT"
 
 Reviewer for frontend repository conventions that are more specific than generic React/MobX
 correctness. Use it alongside `review-frontend`, `review-style`, `review-performance`, and
-`review-logic`.
+`review-logic`. Its inputs are the reviewer payload only; session memory and earlier conversation are not inputs.
 
 Before reviewing, read the nearest project guide files if they exist: root `CLAUDE.md`,
 `AGENTS.md`, `.junie/guidelines.md`, `ARCHITECTURE.md`, and module-level `CLAUDE.md` files.

package/src/gdskills/bundled/skills/review/review-highload/SKILL.md

@@ -28,7 +28,7 @@ license: "MIT"
 
 Specialized reviewer for **code that will run under significant concurrent load**.
 Focuses on correctness under concurrency, resource contention, back-pressure, failure
-modes at scale, and distributed systems invariants — not general performance profiling.
+modes at scale, and distributed systems invariants — not general performance profiling. Its inputs are the reviewer payload only; session memory and earlier conversation are not inputs.
 
 Reviews only changes introduced in the current branch (merge-base to HEAD).
 

package/src/gdskills/bundled/skills/review/review-jev-comments/SKILL.md

@@ -34,7 +34,7 @@ LLM sub-agent: `review-orchestrator` never dispatches a platform-native agent
 for it, it runs `keryx review jev-comments` and reads the `--json` output.
 Every finding is composed by keryx; Jev ("System One" on OpenRouter) supplies
 only a `choice` label per comment — it never writes prose, and nothing it
-returns is quoted verbatim into a finding.
+returns is quoted verbatim into a finding. Its inputs are the reviewer payload only; session memory and earlier conversation are not inputs.
 
 ---
 

package/src/gdskills/bundled/skills/review/review-jev-contract/SKILL.md

@@ -35,7 +35,7 @@ An ADDITIONAL orchestrator reviewer, flow 335. It is a **keryx program**, not
 an LLM sub-agent: `review-orchestrator` never dispatches a platform-native
 agent for it, it runs `keryx review jev-contract` and reads the `--json`
 output. Every finding is composed by keryx; Jev ("System One" on OpenRouter)
-supplies only one `noul` probability per claim — never prose.
+supplies only one `noul` probability per claim — never prose. Its inputs are the reviewer payload only; session memory and earlier conversation are not inputs.
 
 ---
 

package/src/gdskills/bundled/skills/review/review-jev-docs/SKILL.md

@@ -35,7 +35,7 @@ LLM sub-agent: `review-orchestrator` never dispatches a platform-native agent
 for it, it runs `keryx review jev-docs` and reads the `--json` output. Every
 finding is composed by keryx; Jev ("System One" on OpenRouter) supplies only a
 `noul` staleness probability per doc section — it never writes prose, and
-nothing it returns is quoted verbatim into a finding.
+nothing it returns is quoted verbatim into a finding. Its inputs are the reviewer payload only; session memory and earlier conversation are not inputs.
 
 ---
 

package/src/gdskills/bundled/skills/review/review-jev-risk/SKILL.md

@@ -33,7 +33,7 @@ an LLM sub-agent: `review-orchestrator` never dispatches a platform-native
 agent for it, it runs `keryx review jev-risk` and reads the `--json` output.
 Every finding is composed by keryx; Jev ("System One" on OpenRouter) supplies
 only five `noul` probabilities per hunk — one per risk dimension — never
-prose.
+prose. Its inputs are the reviewer payload only; session memory and earlier conversation are not inputs.
 
 ---
 

package/src/gdskills/bundled/skills/review/review-jev-rules/SKILL.md

@@ -37,7 +37,7 @@ for it, it runs `keryx review jev-rules` and reads the `--json` output. Every
 finding is composed by keryx; Jev ("System One" on OpenRouter) supplies only a
 `noul` probability per `(hunk, rule clause)` pair — it never writes prose, and
 nothing it returns is quoted verbatim into a finding except the clause text
-keryx already had.
+keryx already had. Its inputs are the reviewer payload only; session memory and earlier conversation are not inputs.
 
 ---
 

package/src/gdskills/bundled/skills/review/review-jev-scenarios/SKILL.md

@@ -34,7 +34,7 @@ An ADDITIONAL orchestrator reviewer, flow 332. It is a **keryx program**, not
 an LLM sub-agent: `review-orchestrator` never dispatches a platform-native
 agent for it, it runs `keryx review jev-scenarios` and reads the `--json`
 output. Every finding is composed by keryx; Jev ("System One" on OpenRouter)
-supplies only one `noul` probability per scenario — never prose.
+supplies only one `noul` probability per scenario — never prose. Its inputs are the reviewer payload only; session memory and earlier conversation are not inputs.
 
 ---
 

package/src/gdskills/bundled/skills/review/review-layout/SKILL.md

@@ -25,7 +25,7 @@ license: "MIT"
 
 # Review — Layout
 
-Reviewer for what the CSS actually renders.
+Reviewer for what the CSS actually renders. Its inputs are the reviewer payload only; session memory and earlier conversation are not inputs.
 
 This lane exists because nobody else owns it. `review-frontend` owns React and
 MobX structure; `review-style` explicitly excludes everything but naming and

package/src/gdskills/bundled/skills/review/review-logic/SKILL.md

@@ -27,7 +27,7 @@ license: "MIT"
 
 Specialized reviewer for **logic correctness and algorithmic soundness**.
 Inherits from the original `code-ai-review` + `code-learned-review` correctness phases
-and unifies them into a single focused pass.
+and unifies them into a single focused pass. Its inputs are the reviewer payload only; session memory and earlier conversation are not inputs.
 
 This reviewer does not care about formatting, naming, or architecture opinions.
 Every finding must describe an observable, reproducible defect or a spec gap.

package/src/gdskills/bundled/skills/review/review-orchestrator/SKILL.detail.md

@@ -173,8 +173,8 @@ When one is absent:
 
 - **A legacy reviewer a flag asked for** is not dispatched and not replaced.
   Record it in `Skipped reviewers` with reason `not-installed` and the command
-  below. `--legacy-profiles` and `--all` dispatch the legacy reviewers that are
-  installed and record the others the same way. Leave an absent reviewer out of
+  below. `--legacy-profiles` dispatches the legacy reviewers that are
+  installed and records the others the same way; `--all` never selects them. Leave an absent reviewer out of
   the `Optional legacy/profile reviewers` preview: offering a flag that cannot
   run is worse than not offering it.
 - **`review-pr-feedback`** changes nothing about a round. No caller can declare
@@ -326,7 +326,7 @@ model: `docs/docs/jev-in-review.md`.
 reviewer above: it never produces a `findings` array of its own, and it is
 never merged into the consolidated array. It runs AFTER the Sub-Agent Report
 Quality Gate has already validated/merged/deduplicated the round's findings
-(Step 9) and BEFORE Wave C verification (Step 10) — Step 9b in the Workflow
+(Step 9) and BEFORE the later Wave C passes (Step 10; the early verifier pass starts first, on the findings held then) — Step 9b in the Workflow
 block — annotating the findings that already exist. It is advisory and
 annotate-only by construction: nothing it returns drops or demotes a finding,
 and no downstream step is permitted to treat its output as anything but a
@@ -353,7 +353,7 @@ differently in the report:
 |---|---|---|
 | `severity_check` | `{id, p, flagged}` per blocker/major finding — `flagged` means `p < 0.4` | Show `flagged` findings as a soft note next to their existing severity ("Jev's own trigger+outcome check scored this low"). Never change the finding's `severity` field from this alone. |
 | `merge_candidates` | `{id, a, b, reason, p}` per candidate pair | A high `p` is a suggestion to a human that `a` and `b` may be the same defect — surface it in the report as a note on both findings. Never merge, drop, or renumber either finding from this alone. |
-| `verify_order` | `{id, p}`, sorted lowest-`p`-first | Feed this order into Wave C's own dispatch — verify the lowest-plausibility findings first — never as a reason to skip verifying any of them. |
+| `verify_order` | `{id, p}`, sorted lowest-`p`-first | Feed this order into the later Wave C passes — verify the lowest-plausibility findings first — never as a reason to skip verifying any of them. |
 
 `status` is `DONE_WITH_CONCERNS` — never `DONE` — when any `severity_check` is
 `flagged` OR any `merge_candidates` pair scores `p >= 0.5`
@@ -369,6 +369,26 @@ itself draws between a reviewer's claim (`severity`, `problem`, …) and what
 became of it (`disposition`), which a reviewer never states and this pass
 does not either.
 
+## Clean context — why, the log, the three accepted paths
+
+A review must be reproducible from its package: the same inputs give the same context, whoever runs it and whatever that agent remembers from earlier work. So the round starts empty and every input has a named source.
+
+**Inputs.** Only the orchestrator's context stages (scope, Review Context Pack, the memory stage, layers) and, for a reviewer, its payload. The agent's session memory, the auto-memory index (`MEMORY.md`), remembered feedback and the earlier conversation are not inputs, and neither is a second memory search made "to double-check".
+
+**The three accepted paths** are known and kept on the operator's decision (poll 179), not leaks:
+
+1. `prior_findings` — findings of an earlier round of the same package enter by design from round 2 on.
+2. Review-notes and skill learning — auto-accepted output of earlier reviews reaches a later one only through the memory stage, as accepted memory.
+3. A reviewer's `memory_search` — the reviewer agents keep it as a lookup in the project's recorded lessons.
+
+**One memory read, and the log.** The stage query is `keryx memory search "<changed modules and the concepts they touch>" --status accepted`, once. Pass the same text to `keryx review start … --memory-query "<query>"` so the manifest's `cleanContext` block holds it next to the start time. keryx writes the orchestrator log, `<package>/tool-calls/orchestrator.jsonl`, on its own: `keryx review start` and `keryx review attach` mark the package active, and every `keryx memory` command and every MCP memory tool (`memory_search`, `memory_handoff`, `memory_propose`) appends one line naming its caller. You do not write that file and must not edit it; a hand-written line is a forgery the readiness item cannot tell apart from a record. A call by a `spawn_subagent` child is recorded under the child's reviewer id and is not judged by item 10. A call from a host that names no caller is recorded as `unattributed`: it warns in the item's detail line and never blocks. Reviewer logs stay in their own files.
+
+Item 10, `memory-outside-stage`, reads that log. Outside the stage is: a memory search with a different query, a search without `--status accepted`, any other memory command or MCP memory tool, and a stage call stamped before the round started. The same query repeated is the stage. Repair is to rerun from a session whose only memory read is the stage; only the operator's waiver lifts it: in keryx shell call `review_waive_readiness` (the operator answers a card, never a terminal), then run `keryx review complete <package>`; outside keryx shell `keryx review complete <package> --waive memory-outside-stage "<operator quote>"` in a terminal; unattended, record Not run. With no orchestrator log the item passes and its evidence says it could not see your reads; with a log that holds no memory call it passes and says so. Outside keryx shell, `keryx review start` prints a caller token (`export KERYX_REVIEW_CALLER_TOKEN=…`): export it on this session's keryx calls so they are attributed to you; without it the item reads "not observable on this host" rather than a clean pass. Only calls that go through keryx are visible: a read through a tool keryx does not wrap is not in the log.
+
+**Open questions.** One general rule, replacing per-fork wording: the answer is in this skill or `SKILL.detail.md`, or it is the user's. Interactive: one `AskUserQuestion`. Unattended: the whole output is one line, `STATUS: BLOCKED question — <the question>`, and you stop. A guess and a recollection are both wrong answers.
+
+**Named limit.** An agent runtime that loads its memory before this skill starts cannot be prevented by keryx. The guarantee is instruction plus detection, not isolation, and reads of the agent's personal memory outside `keryx memory` are not visible to the log.
+
 ## Start questions (Step 5) — once per round, after the context pack
 
 The round asks its operator three questions, once, in one interaction, after
@@ -379,8 +399,9 @@ three questions; on any other host, the lettered prompt below. An unattended
 round (job pipeline, trigger, schedule) asks nothing, applies the defaults and
 records them under `### How this review was run`.
 
-1. **Reviewers** — default `--all`: every reviewer the engine detects plus every
-   project and convention reviewer its gates admit. Narrowing is an explicit
+1. **Reviewers** — default the set `keryx review required --depth auto` prints
+   (light, or the full set the engine detects plus every project and convention
+   reviewer its gates admit); `--all` only when the operator asks. Narrowing is an explicit
    choice (tests only, one domain, a custom list). Flags the caller passed
    answer this question and skip it. Convention reviewers are part of this
    question; the job setting `convention_reviewers` still answers it in a
@@ -409,7 +430,7 @@ records them under `### How this review was run`.
 ```text
 Context: <PR or branch>, <N> files / <N> lines, <domains>; risk: <class>
 
-1) Reviewers     A) --all (default)  B) tests only  C) <domain> only  D) choose
+1) Reviewers     A) the `required --depth auto` set (default)  B) --all  C) tests only  D) <domain> only  E) choose
 2) Counterpart   found: <endpoints, rules, paired PR — or "no link found">
                  A) verify <backend|frontend> (default)  B) skip — give a reason
 3) Models        complexity: <low|medium|high>; <role>: <tier> → <model>, …
@@ -441,16 +462,28 @@ flow (`flow-orchestrator` Phase 3), a pre-merge or pre-ship review, a
 re-request after fixes. A gating round runs the composition the start questions
 selected.
 
-- **No dispatch tool, no review.** A host that cannot dispatch subagents — no
-  spawn tool, or the depth budget spent — returns
-  `STATUS: BLOCKED` with reason `nested_dispatch_unavailable` and no verdict.
-  It does not review the diff alone and call that a round. Measured (flow 405):
+- **No dispatch tool, no review.** A host with no spawn tool hands the round to
+  the autonomous runner (`keryx review run --autonomous --target pr --ref <pull
+  request URL>`, or `--target branch --ref <base> [--head <commit>]`), which
+  spawns the reviewers itself; a nested session whose depth budget is spent
+  returns `STATUS: BLOCKED` with reason `nested_dispatch_unavailable` and no
+  verdict. Neither reviews the diff alone and calls that a round. Measured (flow 405):
   a single-agent round on a 150-line frontend PR wrote "did not dispatch any
   sub-reviewers", approved it with two cosmetic minors, and the next human round
   filed six real findings, every one reachable from the diff and the backend at
   a pinned SHA.
 - **Size never lowers depth below the risk class.** The budget table sizes the
-  context, not the depth.
+  context, not the depth. Outside the risk class a small change does not need the
+  whole roster: `keryx review required --depth auto` picks the **light** round —
+  `review-logic`, `review-testing-practices` and the stack-conventions reviewer
+  only — when the diff is at most 5 files and 300 changed lines, matches no risk
+  path gate, and is neither `--all` nor gating. Auto needs a file list AND a line
+  count: `--scope <scope.json>` gives both (`review start|ingest --scope` stores
+  the count in `scope-files.json`, so `--package <review-dir>` has both too);
+  with either missing the round is full. Light is only ever granted by those auto
+  checks; `--all`, gating and `--depth full` force full. A light round records `Not run: mutation
+  (light round)` instead of the mutation gate and says so in the report. Inside the
+  risk class the round is full.
 - **High-risk includes a client-side mirror of a server rule** — validation,
   limits, permissions, uniqueness, reserved names — beside the triggers the main
   file lists.
@@ -616,6 +649,23 @@ nothing moved. The final round recomputes whatever the file set did — otherwis
 fix introduced in round 3 gets no regression check at all, and the round that
 certifies the flow is the one that checked the least.
 
+## Readiness — the checklist behind `completed` and behind publishing
+
+`keryx review readiness <review-id-or-path> [--json]` reads the package and prints ten items, READY or NOT READY, each with the evidence and the command that repairs it. It writes nothing, and exits non-zero when the verdict is NOT READY. Only item 9 reaches GitHub (the PR's own file list); the TUI and `review status` read the package alone.
+
+1. `files-covered` — every changed file is in a wave or carries a recorded waiver.
+2. `blast-radius` — no file the blast radius cut is left unreviewed. A cut radius writes `chunks.json`; run `keryx review chunks plan`, `estimate`, `next`/`record`, `merge`. In an unattended run every wave runs without a question, up to the 25-pass ceiling; in an interactive run the operator is asked once: in keryx shell call `review_chunks_answer` (a card, never a terminal); elsewhere the operator runs `keryx review chunks estimate --package <dir> --answer yes --quote "<their words>"` in their terminal; unattended, record Not run.
+3. `reviewers` — every planned reviewer was dispatched and its result ingested.
+4. `verifier` — the verifier checked every finding it should, or the report says how many it did not.
+5. `ledger` — the ledger is READY.
+6. `coverage-md` — coverage.md does not list a reviewer as `run` that the dispatch record says did not finish. Re-run `keryx review ingest` for the package.
+7. `head` — the report's head is the PR head.
+8. `report-names` — pending mutation candidates and parity warnings are named in the report.
+9. `pr-files` — the changed-file count equals the PR's own file list. A recount more than 3x the recorded scope is refused: it came from the wrong base. Recount with `keryx review blast-radius --package <ref> --changed <the PR's files>`.
+10. `memory-outside-stage` — the orchestrator read memory only in its memory stage ("Clean context" above). Outside keryx shell it reads "not observable on this host" unless this session's keryx calls carry the caller token `keryx review start` printed.
+
+`keryx review complete` refuses status `completed` while any item fails. A failing item is waived only by the operator. In keryx shell call `review_waive_readiness` for the item: the operator answers it as a card, the waiver is recorded with the card text and the time, and then you run `keryx review complete`. Never send the operator to a terminal. Outside keryx shell the operator runs `keryx review complete --waive <item> "<their own words>"` in a terminal, repeatable. Unattended, record the item as Not run. `keryx review publish` is held by the same checklist. Publishing is the operator's decision too: in keryx shell call `review_publish` (a card shows the target and the body; never send the operator to a terminal). A not-ready package goes to GitHub only as a partial review (`review_publish` with `partial: true`, or `keryx review publish --partial`), which puts a "Partial review" header on the post and never approves. The shell guard stops a publish command that runs through the keryx shell; a publisher outside it (CI, another agent, a script file) is not stopped, and that limit is named, not hidden.
+
 ## Fix rounds — dispositions, regressions, withdrawal
 
 ### Every prior finding leaves the round with a disposition
@@ -709,9 +759,18 @@ and `.json`. A mutant is `killed` (the suite went red), `survived` (nothing pins
 behaviour), `timeout`, or `invalid` (anchor missing or not unique, file outside the copy).
 A survivor is evidence for the finding that names it.
 
-`keryx review complete` refuses while proposed mutants are unrun, unless
-`dispatch.mutationWaiver = { operatorQuote, reason }` carries the operator's own words.
-`keryx review run --autonomous` is unchanged: it records `Not run: mutation pass` as before.
+`keryx review complete` refuses while proposed mutants are unrun on an attended round, unless the
+operator waived the pass themselves: the `review_waive_mutation` card in keryx shell, or `keryx review
+waive-mutation --package <review-dir> --reason "<why>"` in their terminal (it writes
+`operator-decisions.json`; a `dispatch.mutationWaiver` quote you write is not enough on a package
+`keryx review start` created). Attended is what the start recorded in `run-profile.json`: every round
+except `review start --unattended` and `keryx review run --autonomous`, which record `Not run: mutation
+pass` without asking.
+
+These operator gates (cards, terminal-only commands, plan confirmation, decision records) keep a
+cooperating agent from cutting corners and make every decision visible and attributable; they do not
+stop a hostile same-user agent, which can fake a pty or write the JSON records itself (the TM-03/TM-04
+boundary). The autonomous runner's mutation-gate exemption predates flow 457 and is kept on purpose.
 
 `keryx review mutate --cap <n>` runs the first `n` candidates and records `cap` and `not_reached`
 in `mutation-<n>.json`. The table then prints `Not run: N candidates` (and the report must carry
@@ -723,17 +782,22 @@ never closes it.
 
 A reviewer that argues a finding from a mutant writes `mutant:<id>` in the finding's `evidence`.
 After the mutation pass run `keryx review severity-audit --package <review-dir>`: a cited mutant
-that survived on a file the review changed raises a minor finding to major and records
-`severity_audit {from, to, evidence: "mutation-<n>.json#<id>"}`. A finding that cites a mutant no
+that survived on a file the review changed moves a minor finding up to major only when no mutant
+in that file was `killed` (or `timeout`) in any recorded pass, because then nothing in the suite
+exercises the changed behaviour. It records `severity_audit {from, to, evidence: "mutation-<n>.json#<id>"}`.
+When the file has a killed mutant, the suite covers the code, the survivor is a gap in covered
+code, and the severity is held (see below). A survivor shows a missing assertion, not wrong
+behaviour. A finding that cites a mutant no
 run executed stays minor (a major is capped at minor) and gets the label `unproven`. The audit
 never deletes a finding and never touches a blocker; it is a separate pass from the verifier,
 which can only delete. `--dry-run` prints the changes without writing `findings.json`.
 
 Each mutant in `mutants.json` carries a `kind`: `behavior` (the default, and what a record written
 before the field reads as) or `presentation` (it changes only what a reader sees: a label, a
-column, copy, spacing). A behavior survivor raises as above. When the only survivors a finding
-cites are `presentation`, the severity stays, and the finding gets
-`severity_audit {held: {severity, mutant, kind: "presentation", evidence, reason}}` instead of
+column, copy, spacing). A behavior survivor in a file with no killed mutant raises as above. When
+the only survivors a finding cites are `presentation`, or every behavior survivor sits in a file
+with a killed mutant, the severity stays, and the finding gets
+`severity_audit {held: {severity, mutant, kind: "presentation" | "covered", evidence, reason}}` instead of
 `{from, to}`. A held note is not a raise and not a deletion; it is the record that a survivor was
 seen and did not move the severity, so the report must say so.
 
@@ -767,3 +831,75 @@ available) and the backend pins the pull request names (refs on lines that talk
 Set `pr_context` in every reviewer payload to the `.md` path; reviewers read it before the diff.
 `keryx review dispatch-check --payload <file> --pr-context` refuses a payload without it
 (`REVIEWER_INPUT_NO_PR_CONTEXT`).
+
+## Preflight 4 — PR state, depth and estimate before dispatch
+
+Two 2026-10-15 rounds took 2 h and 3.5 h. One verdict was ready at minute 55, was held to
+minute 119, and the PR merged first; the other re-dispatched a finished wave and ended at 27 of
+41 slices. The operator can only act on a risk they were told about.
+
+1. On a PR target read merged / approved / CI (`gh pr view <n> --json state,reviewDecision,statusCheckRollup`). Say in one line what the state means for the round: an approved PR with green CI can merge any minute, and a merged PR makes the rest of the round a post-merge audit.
+2. **Later, once the package and slices exist** (after `review scope`, `review start` and `review slice --package`, before the first reviewer starts): `keryx review required --mode all --scope .metaproject/data/review/scope.json --depth auto --package <review-dir>` prints the reviewer set and the depth it chose (see "Depth floor"); auto needs the file list and a line count, else the round is full. `keryx review estimate --package <review-dir> [--manifest <slices/manifest.json>]` prints assignments, waves and a duration range; the manifest defaults to `<package>/slices/manifest.json`, then `.metaproject/data/review/slices/manifest.json`.
+3. Show the operator depth + estimate and the merge risk before the first dispatch. Attended: let them choose `full` over a light default. Unattended: record both in the report and continue.
+4. **An over-threshold plan waits for the operator.** `estimate` flags a plan over `reviewPlan.maxDispatches` (default 40) or `reviewPlan.maxMinutes` (default 90) in `routing.config.json`; `dispatch-check --package` and `ledger build` refuse it (`REVIEWER_INPUT_PLAN_UNCONFIRMED`) until `<review-dir>/plan-confirmation.json` exists. Only the operator writes it: the `review_confirm_plan` card in keryx shell, or `keryx review confirm-plan --package <review-dir>` (or `keryx review estimate --package <review-dir> --confirm --quote "<their words>"`) in their terminal; both refuse without a TTY. Unattended, the plan is not dispatched: report the estimate and stop.
+
+## Early verdict — the verdict is interim until `complete`
+
+As soon as every reviewer result and the verifier's are on disk, save each verifier pass to `research-evidence/verifications.json` first (without it a refuted finding still counts), then run `keryx review verdict <id|path> [--json]`: it reads `<package>/raw`, where every host keeps the round's results (`--raw <dir>` only for results kept elsewhere; the shared `.metaproject/data/review/raw` mixes in other rounds' replies). It prints the interim verdict and writes `verdict-interim.md` into the package. Give the operator that verdict in the same message; do not hold it for the mutation pass, the ledger or `complete`.
+
+The tail keeps running after it: the mutation pass (`keryx review mutate`), `ledger build`, `ingest`, `readiness` and `keryx review complete`. Every managed round finishes them. The round is **not done** until `complete`: the verdict you gave is interim, and the report says so and names what the tail may still change (a surviving mutant, a verifier refutation, a late reviewer result). A light round has no mutation pass: its tail is `ledger build`, `ingest`, `readiness`, `complete`.
+
+## Early verifier — start on the first blocker or major
+
+Do not wait for the last reviewer. When the first `blocker` or `major` finding arrives, dispatch `review-verifier` over the findings you hold, while the other reviewers keep running. Each later blocker or major starts another verifier pass over just the new findings (each pass is its own run; Wave C overlaps A and B here, and Step 9b's `verify_order` orders the later passes), so verification finishes within minutes of the last reviewer. The verifier stays delete-only and never verifies a finding its own reviewer raised; the merge still comes from `keryx review ingest --verifications <file>`, once per pass.
+
+## Recovery — collect, validate, ingest, dispatch only what is missing
+
+After a timeout, a crash or a resumed session, in this order:
+
+1. **Collect.** `keryx review retry-plan --manifest <package>/slices/manifest.json --package <package> --reviewer <id> --next-wave` reads `<package>/raw/` first and collects late reviewer results; it prints `collected late: N` and never re-hands a slice that is finished.
+2. **Validate** each collected reply (a `STATUS:` line and a `REVIEW_RESULT` block matching `reviewer-finding.schema.json`), **ingest** it, and rebuild `research.json` with `ledger build`; run `ingest --research` once it prints READY.
+3. **Dispatch only what is missing:** the wave `retry-plan` prints. A wave whose results are on disk is never dispatched again.
+4. **A second timeout of the same reviewer changes the task, not only the diff size:** fewer slices per dispatch, a narrower focus (one concern or one directory), or a lighter model tier for a mechanical slice. Two results in a row with nothing new are `Not run`, as `retry-plan` prints.
+
+## dispatch-check on every payload
+
+Before any mass dispatch run `keryx review dispatch-check --payload <file> --manifest <dir>/manifest.json` on every payload, on every host. It fails `REVIEWER_INPUT_PATH_MISSING` when a `skill_path` or `context_doc` names a file that is not there, and still fails a payload that names no slice, exceeds the wave ceiling or breaks `reviewer-input.schema.json`. Fix the payload; a dead path costs a whole wave of refusals. Related: `review mutate` runs in a scratch copy under the repo and prints the baseline's tail when the baseline is red; `review start --graph-timeout <s>` bounds the graph build.
+
+## Review Plan Preview — legacy groups
+
+```text
+Optional legacy/profile reviewers:
+  - code-ai-review: available via --code-ai or --legacy-profiles
+  - code-learned-review: available via --learned or --legacy-profiles
+  - code-style-review: available via --code-style or --legacy-profiles
+  - code-mobx-store-review: auto-suggest when *.store.ts or MobX patterns are present; available via --mobx-store or --legacy-profiles
+
+Skipped reviewers:
+  - code-ai-review: profile reviewer, not selected unless --code-ai/--legacy-profiles
+  - code-learned-review: profile reviewer, not selected unless --learned/--legacy-profiles
+  - code-style-review: legacy style profile, not selected unless --code-style/--legacy-profiles
+  - code-mobx-store-review: not selected unless --mobx-store/--legacy-profiles or MobX store files are detected
+```
+
+## Token and context budget
+
+The orchestrator owns the token budget. Sub-reviewers receive only the context their domain needs.
+
+Budget rules:
+- Compute a scope digest before dispatch: file list, diff stats, module map, and top risks.
+- Send full diffs only for files relevant to each reviewer.
+- For large files, send changed hunks plus nearby symbols first; include the full file only when path mode or the reviewer requires whole-file context.
+- Never send generated files, lockfiles, snapshots, build output, or vendored code unless the reviewer is specifically about that file type.
+- Cap each reviewer prompt with the `per_reviewer` budget when provided; otherwise use the smallest prompt that preserves evidence.
+- Record omitted files and truncation in `review_context.token_policy.omissions`.
+- If a reviewer returns `NEEDS_CONTEXT`, provide only the missing targeted context, not the entire repository.
+
+Default budget guidance:
+
+| Review size | Detection | Context mode | Dispatch style |
+|---|---|---|---|
+| small | <= 5 files and <= 300 changed lines | `light` | full relevant diff to selected reviewers |
+| medium | <= 20 files or <= 2,000 changed lines | `light` | per-domain filtered diff |
+| large | > 20 files or > 2,000 changed lines | ask `full` | staged waves by domain |
+| high-risk | auth/API/core/security/data migrations | ask `full` | staged waves, verifier included |