@mrciphersmith/keryx 0.3.85 → 0.3.86

package/README.md

@@ -600,7 +600,9 @@ Grouped by what you are trying to do, not by internal module layout.
   trends.
 - **review** — managed review packages, standalone under `.metaproject/reviews/`
   or inside the flow package when attached to a flow, so review findings become
-  durable project artifacts. A finding points at the code it **quotes**: the
+  durable project artifacts. `review-orchestrator` is the default way a review is
+  done: the main session runs it inline, and a session that cannot spawn the
+  reviewers stops with one `STATUS: BLOCKED` line instead of reviewing alone. A finding points at the code it **quotes**: the
   line is derived by locating that quote at the commit the round records, not
   taken on the reviewer's word, and a quote that cannot be found is marked
   unlocatable rather than carrying a number nobody checked. Each round also

package/dist/cli.js

@@ -8637,6 +8637,9 @@ var init_git_local_ignore = __esm(() => {
   init_git_worktrees();
 });
 
+// src/lib/orchestrators-inline.ts
+var ORCHESTRATORS_INLINE_NOTE = "The orchestrators (`review-orchestrator`, `flow-orchestrator`, `job-orchestrator`) run in the main session: the main agent reads the SKILL.md and runs it inline, and never hands a whole orchestrator to a subagent, because a subagent cannot spawn the reviewers and workers the orchestrator dispatches.";
+
 // src/lib/config-dir.ts
 import {
   appendFileSync,
@@ -10336,6 +10339,7 @@ function renderProjectMetaprojectReferenceBlock({
     "For commands, search, diff, test logs, lint/build output, and large file reads that can produce long output, use the Metaproject gdctx skill by default before loading raw command output into context.",
     "For a non-trivial navigation, debugging, review, or investigation task, end with a short routing audit: `graph_used`, `wiki_used`, `ctx_used`, and `raw_rg_used: yes/no`. An omitted layer must be justified (`not-relevant`/`unavailable`), not silently skipped.",
     "For implementation, review, refactoring, planning, documentation, or quality tasks, use project-local Metaproject skills first: .metaproject/skills/catalog.md, .metaproject/project-skills/, then .metaproject/skills/gdskills/. External/global skills are fallback only when explicitly needed.",
+    ORCHESTRATORS_INLINE_NOTE,
     "For creating, changing, debugging, reviewing, or running tests, use the Metaproject testing skill and read .metaproject/data/testing/context.md before broad test search or raw logs.",
     "For lessons learned, decisions, constraints, repeated mistakes, and historical project context, use the Metaproject memory skill before broad documentation search.",
     ...enableTasks ? [flowPolicy] : [],
@@ -11091,6 +11095,7 @@ function renderIndexMarkdown({
       "For implementation, review, refactoring, planning, documentation, or quality tasks, check `skills/catalog.md` and project-local gdskills before any external/global skill set.",
       "For Metaproject requirements packages under `docs/requirements` (README, PRD, specification, policies, schemas), use `skills/gdskills/planning/docpack-orchestrator/SKILL.md`; for current-codebase reverse-engineering documentation, use `autodoc-orchestrator` from `skills/catalog.md`.",
       "For known modules/components/stores/services/domain entities, check generated project skills under `project-skills/<module>/<entity>/` before generic guidance.",
+      ORCHESTRATORS_INLINE_NOTE,
       "When orchestrating multi-agent work, dispatch gdskills workers through the schema contracts in `core/gdskills/contracts/` (subagent-dispatch -> subagent-result) and read `rules/core/subagent-status-protocol.md`; validate a concrete message with `keryx skills contracts validate <file> --schema <name>`."
     ] : [],
     ...enableHealth ? [
@@ -16351,6 +16356,7 @@ Resolution order:
 - User asks which project skill applies to a file/task: run \`keryx skills route <query-or-target>\` before reading broad files.
 - User asks whether a project skill is still valid: run \`keryx skills verify <skill-or-target>\`.
 - User asks to create/update a Metaproject requirements package, PRD/spec package, or \`docs/requirements/<name>\` documentation: load \`gdskills/planning/docpack-orchestrator/SKILL.md\`; use \`autodoc-orchestrator\` instead only for reverse-engineering documentation from the current codebase.
+- Orchestrators: ${ORCHESTRATORS_INLINE_NOTE}
 
 | Skill | Category | Purpose | Entry |
 |---|---|---|---|
@@ -17226,12 +17232,12 @@ var init_skill_length_ceilings = __esm(() => {
     "orchestration/flow-orchestrator": 694,
     "orchestration/issue-analyzer": 373,
     "orchestration/job-documenter": 414,
-    "orchestration/job-orchestrator": 2243,
+    "orchestration/job-orchestrator": 2235,
     "orchestration/task-implementer": 668,
     "planning/autodoc-analyst": 180,
     "planning/autodoc-architect": 179,
     "planning/autodoc-assembler": 145,
-    "planning/autodoc-orchestrator": 343,
+    "planning/autodoc-orchestrator": 342,
     "planning/autodoc-scanner": 183,
     "planning/autodoc-writer": 270,
     "planning/brainstorm": 115,
@@ -17288,7 +17294,7 @@ var init_skill_length_ceilings = __esm(() => {
     "review/review-jev-scenarios": 187,
     "review/review-layout": 238,
     "review/review-logic": 377,
-    "review/review-orchestrator": 1712,
+    "review/review-orchestrator": 1615,
     "review/review-performance": 374,
     "review/review-pr-feedback": 895,
     "review/review-regression": 216,
@@ -19281,7 +19287,8 @@ var init_tools = __esm(() => {
     "apply_patch",
     "shell_exec",
     "web_fetch",
-    "web_search"
+    "web_search",
+    "spawn_subagent"
   ];
   TOOL_TARGET_MAPS = {
     claude: new Map([
@@ -21098,7 +21105,7 @@ var package_default;
 var init_package = __esm(() => {
   package_default = {
     name: "@mrciphersmith/keryx",
-    version: "0.3.85",
+    version: "0.3.86",
     description: "Version-controlled project context for AI coding agents: code graph, architecture wiki, project memory, relevant tests, quality signals, and task flows.",
     private: false,
     publishConfig: {
@@ -87272,22 +87279,35 @@ function spendFromTokens(input) {
   }
   return (inputTokens * inputRatePerMillion + outputTokens * outputRatePerMillion) / 1e6;
 }
+function reviewerDomain(reviewer) {
+  if (CORE_REVIEWERS.has(reviewer)) {
+    return "core";
+  }
+  if (SUPPORT_REVIEWERS.has(reviewer)) {
+    return "support";
+  }
+  return "domain";
+}
 function planReviewerWaves(reviewers, options = {}) {
-  const cap = options.cap ?? DEFAULT_MAX_PARALLEL_REVIEWERS;
+  const cap = options.cap ?? MAX_REVIEWERS_PER_WAVE_FULL;
   if (!Number.isInteger(cap) || cap < 1) {
-    throw new Error(`Invalid concurrency cap: ${cap}. Expected a positive integer; the default is ${DEFAULT_MAX_PARALLEL_REVIEWERS}.`);
+    throw new Error(`Invalid concurrency cap: ${cap}. Expected a positive integer; the default is ${MAX_REVIEWERS_PER_WAVE_FULL}.`);
   }
   const outstanding = options.outstanding;
   if (outstanding !== undefined && (!Number.isInteger(outstanding) || outstanding < 0)) {
     throw new Error(`Invalid outstanding subagent count: ${outstanding}. Expected a non-negative integer.`);
   }
-  const effective = Math.max(1, cap - (outstanding ?? 0));
+  const ceiling = options.full === true ? Math.min(cap, MAX_REVIEWERS_PER_WAVE_FULL) : cap;
+  const effective = Math.max(1, ceiling - (outstanding ?? 0));
   const waves = [];
-  for (let index = 0;index < reviewers.length; index += effective) {
-    waves.push([...reviewers.slice(index, index + effective)]);
+  for (const domain of DOMAIN_ORDER) {
+    const group = reviewers.filter((name) => reviewerDomain(name) === domain);
+    for (let index = 0;index < group.length; index += effective) {
+      waves.push(group.slice(index, index + effective));
+    }
   }
   return {
-    cap,
+    cap: ceiling,
     outstanding,
     effective,
     waves,
@@ -87388,7 +87408,7 @@ function renderCapsMarkdown(record) {
 function escapePipes2(value) {
   return value.replace(/\|/g, "\\|");
 }
-var DEFAULT_MAX_FINDINGS_PER_REVIEWER = 10, SEVERITY_RANK3, DEFAULT_SPEND_CEILING_USD = 3, DEFAULT_MAX_PARALLEL_REVIEWERS = 4;
+var DEFAULT_MAX_FINDINGS_PER_REVIEWER = 10, SEVERITY_RANK3, DEFAULT_SPEND_CEILING_USD = 3, MAX_REVIEWERS_PER_WAVE_FULL = 10, CORE_REVIEWERS, SUPPORT_REVIEWERS, DOMAIN_ORDER;
 var init_caps = __esm(() => {
   SEVERITY_RANK3 = {
     blocker: 0,
@@ -87396,6 +87416,26 @@ var init_caps = __esm(() => {
     minor: 2,
     info: 3
   };
+  CORE_REVIEWERS = new Set([
+    "review-logic",
+    "review-security-code",
+    "review-architecture",
+    "review-highload",
+    "review-regression",
+    "review-core-boundaries",
+    "code-boss-reviewer",
+    "code-ai-review"
+  ]);
+  SUPPORT_REVIEWERS = new Set([
+    "review-style",
+    "review-clean-code",
+    "review-testing-practices",
+    "review-vantage-testing",
+    "review-vantage-styling",
+    "review-layout",
+    "code-style-review"
+  ]);
+  DOMAIN_ORDER = ["core", "domain", "support"];
 });
 
 // src/lib/git-hooks.ts
@@ -180594,20 +180634,38 @@ async function importProjectSkills(options) {
   const plans = await Promise.all(sources.map((source) => planOne(options, source)));
   const refusedPackages = new Set(plans.flatMap((plan) => ("row" in plan) && isRefusedStatus(plan.row.status) ? [plan.row.name] : []));
   const candidates = sources.filter((source) => !skippedAsDeprecated(source)).filter((source) => options.force === true || !BUNDLED_NAMES.has(source.name));
-  const ruleDecisions = await decideReferencedRules(options, candidates, refusedPackages);
   const templatePlans = [];
+  const refusedByTemplates = new Set;
   for (const source of candidates) {
     if (source.sourcePath === undefined || refusedPackages.has(source.name))
       continue;
-    templatePlans.push(...await planTemplates(options, { module: source.module, name: source.name, sourcePath: source.sourcePath }, options.force === true));
+    const own = await planTemplates(options, { module: source.module, name: source.name, sourcePath: source.sourcePath }, options.force === true);
+    if (packageRefusedByTemplates(own)) {
+      refusedByTemplates.add(source.name);
+      if (plans.some((plan) => ("write" in plan) && plan.write.name === source.name))
+        refusedPackages.add(source.name);
+      templatePlans.push(...withheldTemplates(own));
+    } else {
+      templatePlans.push(...own);
+    }
   }
+  const ruleDecisions = await decideReferencedRules(options, candidates, refusedPackages);
   await refuseUncontainedWrites(label, options.projectRoot, [
-    ...plans.flatMap((plan) => ("write" in plan) ? projectSkillWritePaths(plan.write.module, plan.write.name, "single") : []),
+    ...plans.flatMap((plan) => ("write" in plan) && !refusedByTemplates.has(plan.write.name) ? projectSkillWritePaths(plan.write.module, plan.write.name, "single") : []),
     ...ruleDecisions.flatMap((decision) => ("placement" in decision) ? [decision.placement.target] : []),
-    ...templatePlans.flatMap((plan) => ("write" in plan) ? [plan.write.target] : [])
+    ...templateTargets(templatePlans)
   ]);
   const imported = [];
   for (const plan of plans) {
+    if ("write" in plan && refusedByTemplates.has(plan.write.name)) {
+      imported.push(refusedByTemplateRow({
+        name: plan.write.name,
+        module: plan.write.module,
+        path: projectSkillPackagePath(plan.write.module, plan.write.name),
+        origin: plan.write.origin
+      }, options.dryRun === true));
+      continue;
+    }
     imported.push("row" in plan ? plan.row : await writeOne(options, plan));
   }
   addFlagWarnings(imported, sources, existingFlags);
@@ -180652,18 +180710,29 @@ async function updateProjectSkills(options) {
     plans.push(await planUpdate(options, entry));
   }
   const templatePlans = [];
+  const refusedByTemplates = new Set;
   for (const plan of plans) {
     if (!("content" in plan) || plan.sourcePath === undefined)
       continue;
-    templatePlans.push(...await planTemplates(options, { module: projectSkillSlug(plan.entry.module), name: projectSkillSlug(plan.entry.name), sourcePath: plan.sourcePath }, true));
+    const own = await planTemplates(options, { module: projectSkillSlug(plan.entry.module), name: projectSkillSlug(plan.entry.name), sourcePath: plan.sourcePath }, true);
+    if (packageRefusedByTemplates(own)) {
+      refusedByTemplates.add(plan);
+      templatePlans.push(...withheldTemplates(own));
+    } else {
+      templatePlans.push(...own);
+    }
   }
   await refuseUncontainedWrites("keryx skills update", options.projectRoot, [
-    ...plans.flatMap((plan) => ("content" in plan) ? projectSkillWritePaths(projectSkillSlug(plan.entry.module), projectSkillSlug(plan.entry.name), "single") : []),
-    ...templatePlans.flatMap((plan) => ("write" in plan) ? [plan.write.target] : [])
+    ...plans.flatMap((plan) => ("content" in plan) && !refusedByTemplates.has(plan) ? projectSkillWritePaths(projectSkillSlug(plan.entry.module), projectSkillSlug(plan.entry.name), "single") : []),
+    ...templateTargets(templatePlans)
   ]);
   const existingFlags = await projectReviewerFlags(options.projectRoot);
   const imported = [];
   for (const plan of plans) {
+    if (refusedByTemplates.has(plan) && "entry" in plan) {
+      imported.push(refusedByTemplateRow({ name: plan.entry.name, module: plan.entry.module, path: plan.entry.path, origin: plan.origin }, options.dryRun === true));
+      continue;
+    }
     imported.push("row" in plan ? plan.row : await writeUpdate(options, plan));
   }
   addFlagWarnings(imported, plans.map((plan) => ("content" in plan) ? plan : undefined), existingFlags);
@@ -181211,7 +181280,7 @@ async function planOne(options, source) {
         status: "skipped",
         path: dest,
         origin: source.origin,
-        reason: "already exists; pass --force to overwrite",
+        reason: "already exists; pass --force to overwrite, or run `keryx skills update` to refresh it from its origin",
         wired: wiringNote(source.module)
       }
     };
@@ -181565,6 +181634,40 @@ async function listTemplateFiles(sourcePath) {
   await walk(root, "");
   return files;
 }
+async function fileInTheWay(projectRoot, target) {
+  let current = projectRoot;
+  let relative = "";
+  for (const part of target.split("/").slice(0, -1)) {
+    current = path343.join(current, part);
+    relative = relative === "" ? part : `${relative}/${part}`;
+    try {
+      if (!(await stat37(current)).isDirectory())
+        return relative;
+    } catch {
+      return;
+    }
+  }
+  return;
+}
+function packageRefusedByTemplates(plans) {
+  return plans.some((plan) => ("row" in plan) && isRefusedStatus(plan.row.status));
+}
+function withheldTemplates(plans) {
+  return plans.map((plan) => ("row" in plan) ? plan : {
+    row: {
+      ...plan.write.row,
+      status: "skipped",
+      reason: "not written: another template of this package was refused"
+    }
+  });
+}
+function refusedByTemplateRow(pkg, dryRun) {
+  return {
+    ...pkg,
+    status: dryRun ? "would-refuse" : "refused",
+    reason: "a template of this package was refused by the security gate; nothing of the package was written"
+  };
+}
 async function planTemplates(options, pkg, replace) {
   const plans = [];
   const packageKey = `${pkg.module}/${pkg.name}`;
@@ -181579,6 +181682,11 @@ async function planTemplates(options, pkg, replace) {
       continue;
     }
     const targetAbs = path343.join(options.projectRoot, target);
+    const blocker = await fileInTheWay(options.projectRoot, target);
+    if (blocker !== undefined) {
+      plans.push({ row: { ...base, status: "skipped", reason: `${blocker} is a file, not a directory; nothing was written there` } });
+      continue;
+    }
     const exists = await pathExists(targetAbs);
     if (exists && !await isRegularFile(targetAbs)) {
       plans.push({ row: { ...base, status: "skipped", reason: `${target} is not a regular file; nothing was written there` } });
@@ -181594,8 +181702,14 @@ async function planTemplates(options, pkg, replace) {
       plans.push({ row: { ...base, status: "unchanged" } });
       continue;
     }
-    if (existing !== undefined && !replace) {
-      plans.push({ row: { ...base, status: "differs", reason: "left as it is; pass --force to replace it with the package's" } });
+    if (existing !== undefined && !replace && verdict.kind === "write") {
+      plans.push({
+        row: {
+          ...base,
+          status: "differs",
+          reason: "the project's copy is another file than the package's; pass --force to replace it, or run `keryx skills update`, which replaces it too"
+        }
+      });
       continue;
     }
     if (verdict.kind !== "write") {
@@ -181881,7 +181995,7 @@ Examples:
 var BUNDLED_NAMES, PATHS_NONE_WARNING = 'paths: none \u2014 dispatched on every round. Declare `metadata.paths: "<glob>, <glob>"` in its frontmatter to gate it on the diff.', DEFAULT_FETCHER = async (url) => {
   const response = await fetch(url);
   return { ok: response.ok, status: response.status, text: await response.text() };
-}, DEPRECATED_REASON = "deprecated", KNOWN_CATEGORIES, isString4 = (value) => value !== undefined, REFUSED_NOTE = "A refused file was not written.", ALLOW_FLAGGED_HINT = "A prompt-injection refusal can be overridden after you read the file: run the command again with --allow-flagged.", IMPORT_HEADER_LABELS, IMPORT_HEADER_LINE, BYTE_ORDER_MARK = 65279, TEMPLATES_DIR = "templates", ALLOW_FLAGGED_FLAG = "--allow-flagged", SECURITY_GATE_HELP = `Security gate: a SKILL.md or rule is written as the gate returns it, so a secret is
+}, DEPRECATED_REASON = "deprecated", KNOWN_CATEGORIES, isString4 = (value) => value !== undefined, REFUSED_NOTE = "A refused file was not written.", ALLOW_FLAGGED_HINT = "A prompt-injection refusal can be overridden after you read the file: run the command again with --allow-flagged.", IMPORT_HEADER_LABELS, IMPORT_HEADER_LINE, BYTE_ORDER_MARK = 65279, TEMPLATES_DIR = "templates", templateTargets = (plans) => plans.flatMap((plan) => ("write" in plan) ? [plan.write.target] : plan.row.status === "skipped" ? [] : [plan.row.path]), ALLOW_FLAGGED_FLAG = "--allow-flagged", SECURITY_GATE_HELP = `Security gate: a SKILL.md or rule is written as the gate returns it, so a secret is
 masked and the row says it was redacted, and any other finding is reported on the
 row. Text with a prompt-injection finding is refused in every security mode: the
 row is \`refused\` (\`would-refuse\` on a dry run) with the gate's own summary,
@@ -188097,9 +188211,12 @@ async function runBudget(args) {
     ceiling: parseMoney(optionValue(args, "--ceiling"), "--ceiling")
   });
   const reviewers = optionValue(args, "--reviewers")?.split(",").map((item) => item.trim()).filter(Boolean) ?? [];
+  if (args.some((arg) => arg.startsWith("--full=")))
+    throw new Error("`--full` takes no value.");
   const plan = planReviewerWaves(reviewers, {
     cap: parseNonNegativeInteger(optionValue(args, "--parallel"), "--parallel"),
-    outstanding: parseNonNegativeInteger(optionValue(args, "--outstanding"), "--outstanding")
+    outstanding: parseNonNegativeInteger(optionValue(args, "--outstanding"), "--outstanding"),
+    full: args.includes("--full")
   });
   console.log("# review budget");
   console.log("");
@@ -189739,7 +189856,7 @@ Usage:
                             [--no-related-tests] [--final] [--previous <blast-radius.json>]
                             [--json | --brief] [--out <file>]
   keryx review budget [--spent <usd>] [--ceiling <usd>]
-                      [--reviewers a,b] [--parallel <n>] [--outstanding <n>]
+                      [--reviewers a,b] [--parallel <n>] [--outstanding <n>] [--full]
   keryx review tier [--scope <scope>] [--fix-attempt <n>] [--forced-strategy-change]
                     [--findings <n>] [--diff-lines <n>]
                     [--verifier ${VERIFICATION_METHODS.join("|")}] [--security]
@@ -190041,7 +190158,7 @@ budget:
   The gate to run BEFORE dispatching, where stopping is still possible. Exits
   non-zero when spend has reached the ceiling (default ${DEFAULT_SPEND_CEILING_USD} USD) so the
   orchestrator asks the operator instead of proceeding. Also prints the reviewer
-  dispatch waves for the concurrency cap (default ${DEFAULT_MAX_PARALLEL_REVIEWERS} in flight).
+  dispatch waves for the concurrency cap (default ${MAX_REVIEWERS_PER_WAVE_FULL} in flight; split by diff domain, never above ${MAX_REVIEWERS_PER_WAVE_FULL} for a full review).
   --outstanding <n> is what an enclosing orchestrator already has in flight.
   WITHOUT it the cap bounds this plan only: keryx cannot observe subagents in
   another process, so it does NOT bind the total across job-orchestrator ->
@@ -190199,7 +190316,7 @@ var init_review = __esm(() => {
     "--parallel",
     "--outstanding"
   ];
-  BUDGET_FLAGS = ["--spent", "--ceiling", "--parallel", "--outstanding", "--reviewers"];
+  BUDGET_FLAGS = ["--spent", "--ceiling", "--parallel", "--outstanding", "--reviewers", "--full"];
   COMMENTS_COLLECT_FLAGS = [
     "--repo",
     "--pr",

package/dist/core.js

@@ -9995,7 +9995,6 @@ var init_route_tokens = __esm(() => {
     "them"
   ]);
 });
-
 // src/gdskills/skill-frontmatter.ts
 function frontmatterLines(content) {
   const text = content.startsWith("\uFEFF") ? content.slice(1) : content;
@@ -10791,12 +10790,12 @@ var init_skill_length_ceilings = __esm(() => {
     "orchestration/flow-orchestrator": 694,
     "orchestration/issue-analyzer": 373,
     "orchestration/job-documenter": 414,
-    "orchestration/job-orchestrator": 2243,
+    "orchestration/job-orchestrator": 2235,
     "orchestration/task-implementer": 668,
     "planning/autodoc-analyst": 180,
     "planning/autodoc-architect": 179,
     "planning/autodoc-assembler": 145,
-    "planning/autodoc-orchestrator": 343,
+    "planning/autodoc-orchestrator": 342,
     "planning/autodoc-scanner": 183,
     "planning/autodoc-writer": 270,
     "planning/brainstorm": 115,
@@ -10853,7 +10852,7 @@ var init_skill_length_ceilings = __esm(() => {
     "review/review-jev-scenarios": 187,
     "review/review-layout": 238,
     "review/review-logic": 377,
-    "review/review-orchestrator": 1712,
+    "review/review-orchestrator": 1615,
     "review/review-performance": 374,
     "review/review-pr-feedback": 895,
     "review/review-regression": 216,
@@ -11732,7 +11731,8 @@ var init_tools = __esm(() => {
     "apply_patch",
     "shell_exec",
     "web_fetch",
-    "web_search"
+    "web_search",
+    "spawn_subagent"
   ];
   TOOL_TARGET_MAPS = {
     claude: new Map([

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mrciphersmith/keryx",
-  "version": "0.3.85",
+  "version": "0.3.86",
   "description": "Version-controlled project context for AI coding agents: code graph, architecture wiki, project memory, relevant tests, quality signals, and task flows.",
   "private": false,
   "publishConfig": {

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

@@ -21,6 +21,10 @@ license: "MIT"
 
 # Flow Orchestrator
 
+## Preflight
+
+Run in the main session: this skill dispatches workers. Without the `Agent` tool, or with the depth budget spent (Claude Code nests at most 3 deep), the whole output is this line, with no tool calls and no work of your own: `STATUS: BLOCKED nested_dispatch_unavailable — run this skill in the main session`
+
 ## Purpose
 
 Flow Orchestrator is the Task Manager-aware implementation orchestrator. Plan bridge: publish the tasks with `plan_set` under the ids `T1`…`Tn`, mirror each `keryx flow task done` with `plan_update`, and publish Phase 4's completion choice as `proposed` — see the `session-plan-bridge` rule.
@@ -28,8 +32,6 @@ It wraps the existing gdskills pipeline with `keryx flow` state.
 
 Use this skill instead of `job-orchestrator` when the user wants a managed story/issue lifecycle with frozen acceptance criteria, task state, an explicit completion choice, Code Health, and a durable flow package in `.metaproject/flows/`.
 
-Do not modify `job-orchestrator` or `task-implementer` behavior. They remain usable without Task Manager. This skill coordinates them through flow state.
-
 ## Hard Preconditions
 
 1. Read `.metaproject/index.md` and `.metaproject/metaproject.json`.
@@ -122,9 +124,8 @@ it already tried. The flow package does.
       keryx flow next <id> --json
       ```
 
-      This is the first task whose `status` is not `done` and whose declared
-      `dependsOn` are all `done` — the ordering computed from the package
-      instead of re-derived by you from prose.
+      This is the first task not `done` whose declared `dependsOn` are all
+      `done` — computed from the package, not re-derived from prose.
 
    4. **Read the `resume` field before dispatching anything.** It has three
       answers and they are not interchangeable:
@@ -141,10 +142,9 @@ it already tried. The flow package does.
         or close the task (`keryx flow task done <id> <Tn>`). Re-dispatching
         over an unresolved attempt is how the same work gets done twice.
 
-      `keryx flow next` also lists every OTHER not-done task carrying an
-      unresolved attempt, under `unresolved`. Those are parallel dispatches that
-      never reported back; resolve them the same way before assuming the flow is
-      idle.
+      `keryx flow next` also lists every OTHER not-done task with an unresolved
+      attempt, under `unresolved`: parallel dispatches that never reported back.
+      Resolve them the same way before assuming the flow is idle.
 
    5. Before dispatching a worker for that task, record the attempt:
 
@@ -436,19 +436,17 @@ Before accepting implementation:
 4. Check the bounds, then run `review-orchestrator` with relevant domains — in this session,
    never handed whole to one subagent: one without a dispatch tool returns `STATUS: BLOCKED`.
    ```bash
-   keryx review budget --spent <usd-so-far> --outstanding <subagents you already have in flight>
+   keryx review budget --spent <usd-so-far> --full --outstanding <subagents still running, 0 if none>
    ```
    A non-zero exit means the spend ceiling (3 USD by default) has been reached:
    **stop and ask the user** rather than dispatching another fan-out — never shrink the fan-out to fit.
    Dispatch prompts point at sources (files, SHAs, the PR) and never paraphrase a contract.
 
-   `--outstanding` is the part that matters here. `review-orchestrator`
-   dispatches reviewers in parallel and runs *nested* under this skill, and
-   keryx cannot observe subagents in another process. Passing the count you
-   already have in flight is the only thing that makes the concurrency cap mean
-   anything across the nesting; omit it and the cap bounds the reviewer fan-out
-   alone, which the review record then states plainly rather than implying
-   otherwise.
+   `--outstanding` is the part that matters here. `review-orchestrator` runs inline
+   in this session and dispatches reviewers in parallel; keryx cannot observe other
+   subagents. Passing the count still running is the only thing that makes the
+   concurrency cap mean anything; omit it and the cap bounds the reviewer fan-out
+   alone, which the review record then states plainly. Add `--full` for `--all`.
 
 5. If findings require code changes, dispatch fix work through `task-implementer`
    and record the fix task in the flow.
@@ -586,7 +584,9 @@ the bound plus an escalation — never an unbounded loop.
    findings, affected graph, relevant wiki, and health/testing artifacts;
    identify the likely cycle cause; choose a materially different fix strategy
    or split the work into narrower tasks; record the decision in `journal.md`;
-   then continue with the enriched context.
+   then continue with the enriched context. The review round count is not reset:
+   past `REVIEW_ROUND_CAP` rounds on one merge-base..HEAD, report to the operator
+   instead of running another round.
 6. Never merge while findings or required checks remain unresolved. If the
    re-planned approach still cannot produce a mergeable PR, leave the flow
    `in-progress` and report the blocker instead of forcing completion.

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

@@ -22,14 +22,12 @@ metadata:
 license: "MIT"
 ---
 
-<SUBAGENT-STOP>
-If you were dispatched as a subagent to execute a specific task, skip this skill entirely.
-This skill is for orchestrators and interactive session-level routing only.
-Proceed directly with your assigned task.
-</SUBAGENT-STOP>
-
 # Job Orchestrator
 
+## Preflight
+
+Run in the main session: this skill dispatches sub-agents. Without the `Agent` tool, or with the depth budget spent (Claude Code nests at most 3 deep), the whole output is this line, with no tool calls and no work of your own: `STATUS: BLOCKED nested_dispatch_unavailable — run this skill in the main session`
+
 ## Purpose
 
 Dynamic orchestrator that builds execution plans based on user intent. Unlike a fixed pipeline, the orchestrator adapts its workflow to what the user actually needs — from "just analyze this issue" to "implement, review, and create a PR". It dispatches sub-agents (`issue-analyzer`, `context-collector`, `tests-creator`, `task-implementer`, `code-verifier`, `review-orchestrator`) and persists every step, document and retry through `keryx job`, which writes `.metaproject/jobs/<job-name>/`. Plan bridge: publish these steps with `plan_set` under the ids `keryx job status` reports, mirror each `keryx job step` with `plan_update`, and mark them `proposed` while the approval above is open — see the `session-plan-bridge` rule.
@@ -1059,16 +1057,14 @@ carried in the dispatch prompt and reported in 2.9.
 **Step 1 — check the budget before dispatching, while stopping is still possible.**
 
 ```bash
-keryx review budget --spent <usd-so-far> --outstanding <subagents this orchestrator has in flight>
+keryx review budget --spent <usd-so-far> --full --outstanding <subagents still running, 0 if none>
 ```
 
-`--outstanding` is not optional here. `src/review/caps.ts` names `job-orchestrator`
-as the outermost of the three nesting levels — `job-orchestrator` →
-`flow-orchestrator` → `review-orchestrator` — that its cap of 4 in-flight reviewers
-was chosen to survive. keryx is a CLI invoked once per command; it cannot observe
-subagents running inside another orchestrator's process. **The cap binds the nested
-total only when the parent declares its own in-flight count.** Omit `--outstanding`
-and the cap bounds the reviewer fan-out alone, which the record then states plainly.
+`--outstanding` is the number of subagents this session still has running while the
+round starts (0 when none). All three orchestrators run inline in the main session, so the
+reviewers are the only fan-out; keryx cannot observe other subagents, so **the wave size
+(at most 10 for `--all` or a full review; add `--full`) binds the total only when you
+declare that count.** Omit it and the record states that the cap bounds the reviewers alone.
 
 A non-zero exit means the spend ceiling (3 USD by default) is reached: stop and ask
 the user rather than dispatching another fan-out.
@@ -1122,30 +1118,26 @@ replaced. The command names no model — it ranks what the provider reports at r
 and, when it cannot rank anything, prints `inherit: true`, which means the dispatch
 runs on the session model. That is a correct answer, not a failure.
 
-**Step 6 — dispatch `review-orchestrator`.**
+**Step 6 — run `review-orchestrator` inline, in this main session.** Load
+`skills/gdskills/review/review-orchestrator/SKILL.md` yourself; do **not** wrap it in a
+`Task` — a subagent cannot spawn the reviewers and the skill answers
+`STATUS: BLOCKED nested_dispatch_unavailable`. Give it these inputs:
 
 ```
-Task({
-  description: "Review round <n>: <job-name>",
-  subagent_type: "general-purpose",
-  prompt: |
-    Load skill: skills/gdskills/review/review-orchestrator/SKILL.md
-
-    flags:            <selected flags, e.g. --backend --security --testing-practices>
-    commit_range:     <BASE_SHA>..HEAD
-    issue_url:        <issue URL, when the job has one — enables the Stage 1 spec gate>
-    context_doc:      <JOBS_ROOT>/<job-name>/ai/context.md
-    verification_mode: annotate
-    managed_review:   { mode: "review-flow", target: "branch", target_ref: "<feature-branch>" }
-    is_fix_round:     <true on any round after the first>
-    pr_comments:      { enabled: <true when a PR exists> }
-
-    Emit the unified report AND the fenced ```json keryx:findings``` block.
-    Dispatch review-verifier (Wave C) over the consolidated findings and return
-    its verification claims as a file path.
-})
+flags:             <selected flags, e.g. --backend --security --testing-practices>
+commit_range:      <BASE_SHA>..HEAD
+issue_url:         <issue URL, when the job has one — enables the Stage 1 spec gate>
+context_doc:       <JOBS_ROOT>/<job-name>/ai/context.md
+verification_mode: annotate
+managed_review:    { mode: "review-flow", target: "branch", target_ref: "<feature-branch>" }
+is_fix_round:      <true on any round after the first>
+pr_comments:       { enabled: <true when a PR exists> }
 ```
 
+It emits the unified report AND the fenced ```json keryx:findings``` block, and runs
+`review-verifier` (Wave C) over the consolidated findings, returning its verification
+claims as a file path.
+
 **Step 7 — verification is part of the round, not an extra.** `review-orchestrator`
 dispatches `review-verifier` in Wave C over the consolidated findings. The verifier
 **runs something** and can only delete — it never raises a severity, adds a finding,
@@ -1310,7 +1302,7 @@ FOR iteration in [1, 2, 3]:
        keryx review comments collect --repo <r> --pr <n> --sha <new-head> --round <N+1> --out <file>
        keryx review scope        --ref "$BASE_SHA" --json > scope.json
        keryx review blast-radius --ref "$BASE_SHA" --previous blast-radius.json --json > blast-radius.json
-       <dispatch review-orchestrator with is_fix_round: true>
+       <run review-orchestrator inline, in this session, with is_fix_round: true>
        keryx review ingest  --report <new-report> --ref <feature-branch> --head <new-head> \
                             --scope scope.json --blast-radius blast-radius.json \
                             --verifications <file> --refuted <file> --outstanding <n>
@@ -1985,7 +1977,7 @@ What actually bounds this orchestrator:
 | review → fix rounds | 3 | 2.7, and `max_review_iterations` (`maximum: 3`) in the input contract |
 | repetition, whatever the count says | first repeat | the STUCK CHECK in 2.7, and `keryx review loop` against the durable record |
 | retries per step | recorded, not guessed | `metrics.steps[].retries`, incremented by `keryx job step --status in-progress` and read back with `keryx job status --json` |
-| reviewer fan-out | 4 in flight | `keryx review budget --outstanding <n>` before every dispatch (2.6.1) |
+| reviewer fan-out | ≤10 per wave | `keryx review budget --outstanding <n>` before every dispatch (2.6.1) |
 | spend | 3 USD by default | `keryx review budget --spent <usd>` — a non-zero exit means stop and ask |
 
 Each of these is a number some command reads or writes. A guard no command can

package/src/gdskills/bundled/skills/planning/autodoc-orchestrator/SKILL.md

@@ -20,8 +20,7 @@ metadata:
   version: 1.0.0
 ---
 
-<!-- SUBAGENT-STOP: If you are a subagent dispatched by another orchestrator, HALT.
-     Return STATUS: BLOCKED — autodoc-orchestrator must run as top-level agent only. -->
+**Preflight:** run in the main session. Without the `Agent` tool or depth budget, output only `STATUS: BLOCKED nested_dispatch_unavailable — run this skill in the main session`, with no tool calls.
 
 # autodoc-orchestrator
 

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

@@ -426,7 +426,7 @@ 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 — this
-  engine running inside a subagent is the usual case — returns
+  engine running inside a subagent, say — 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):
   a single-agent round on a 150-line frontend PR wrote "did not dispatch any
@@ -503,3 +503,157 @@ New managed packages carry `research.json`, initially pending. Before closing a
 Supply the ledger using `keryx review ingest --research <ledger.json>` alongside the report and findings. Format: `version: 1`, `scopeReviewed: true`, `rawReconciled: true`, `obligations: [...]`. Each obligation requires `id`, `source`, `question`, `status`, `evidence`, `reason`. Status `finding` additionally requires `finding` pointing to exactly one canonical finding ID or global ID. Other terminal statuses are `refuted` and `out-of-scope`, both requiring evidence and reason. Preserve distinct scenarios when deduplicating. Assert census/reconciliation flags only after performing those checks; an empty obligations array is valid only if the actual census found no open observations.
 
 Open, deferred and unverifiable obligations block completion. If context, runtime or budget prevents resolution, retain the obligation and report incomplete; do not relabel it refuted or out-of-scope. Completion and the flow gate re-read the ledger even when the manifest says closed. Legacy packages without this artifact remain compatible, not proven complete. This gate validates the declared ledger, not the truth or exhaustiveness of its census; independent source/raw audits remain necessary.
+
+## Why Wave C verifies instead of re-scoring
+
+Wave C used to run `review-strict`: a meta-pass that re-read the consolidated
+findings and **adjusted their severity with no new evidence**, under an elevation
+table biased 3:1 toward escalation. It was **removed, not improved**, and the
+reason is measured rather than stylistic:
+
+- **GPT-4 on GSM8K across self-correction rounds: 95.5 → 91.5 → 89.0.**
+  **GPT-3.5 on CommonSenseQA: 75.8 → 38.1.** Among the answers that changed,
+  correct → incorrect exceeded incorrect → correct (Huang et al., *Large Language
+  Models Cannot Self-Correct Reasoning Yet*, ICLR 2024, arXiv:2310.01798).
+- **Self-Refine (arXiv:2303.17651): +49.2 on dialogue response generation, +0.2
+  on maths.** Self-refinement gains are on subjective tasks and vanish on
+  verifiable reasoning. Judging whether a null-guard is missing is verifiable
+  reasoning.
+
+Re-scoring a finding by re-reading it is therefore not a rigour pass; it is a
+coin flip weighted toward more findings. **Do not restore it because it looks
+obviously useful — it looked obviously useful the first time.**
+
+`review-verifier` occupies the slot and differs in exactly one way that matters:
+**it runs something.** Verification that executes rejects 85–96% of false reports
+against 4–15% unaided while finding 30–44% more true bugs (AnyPoC,
+arXiv:2604.11950); Meta's TestGen-LLM funnel discards 75% of its own output
+(75% build → 57% build and pass → 25% improve coverage) and the surviving quarter
+reaches 73% human acceptance (arXiv:2402.09171).
+
+## Scope B — bounds, rejections and recompute
+
+It walks `gdgraph affected` outward from every changed file, ranks by edge
+distance, keeps distance ≤ 2, cuts at 40 files closest-first, and adds a changed
+file's naming-related tests when the graph did not already reach them. Requires a
+built graph — run `keryx gdgraph build` if it refuses.
+
+**Do not pick the files yourself, and do not widen it.** "Review the
+functionality so nothing breaks" naively means "review the whole repository every
+round", which is unaffordable *and* actively harmful: review quality decays as
+context grows — measured F1 0.65 at round 2 falling to 0.29 at round 10. An
+unbounded scope B makes later rounds worse than earlier ones.
+
+The bounds are measured on this repository, not guessed: at depth 2 the set is a
+median of 19 files (p90 65); depth 3 buys eight more in the median and doubles
+the p90. The 40-file cap fires on 25% of commits and removes only hop-2 entries
+on all but 2 of 80, so it almost never costs a direct dependent — and when it
+does, it says so.
+
+**Record the whole thing.** `--out "<review-package>/blast-radius.md"` writes the
+set, the depth, and **every file the cap removed**. A truncation nobody can see
+reads afterwards as "we checked everything", which is the claim this pipeline
+exists to stop making. An empty radius is reported as `unresolved`, not as clean:
+the graph indexes code, so a change to a skill, a rule or a schema has no blast
+radius at all and that is a different fact from "nothing depends on it".
+
+### The scope-B question, and what is rejected
+
+> Does this change break an existing behaviour **at these sites**?
+
+Nothing else. The blast-radius set is **under regression check, not under
+review**. A finding about style, naming or architecture in code the change did
+not touch is refused **by the orchestrator in code** — not discouraged here —
+under three rules, every one of them a fact about the claim rather than about who
+made it:
+
+| Rule | Refused because |
+|---|---|
+| `outside-set` | the file is neither in the computed set nor in the changed set; the reviewer went browsing |
+| `non-regression-severity` | below `major`. Under the canonical rubric `minor` states the code behaves correctly and `info` names neither trigger nor outcome; neither can be a claim that something broke |
+| `no-link-to-change` | nothing in the finding names a changed file, module or symbol. A regression claim says THE CHANGE broke this site |
+
+Rejections are **recorded, not deleted** — raise the observation under scope A or
+as a separate review. Pass `--brief` output verbatim into the scope-B dispatch:
+the code rejection is the enforcement, but a reviewer told afterwards has already
+spent the round producing findings that will all be refused.
+
+`class_scope` on a scope-B finding names the **caller that breaks**, not the
+changed line, because that is the site a human has to look at.
+
+### When it is recomputed
+
+| Round | Scope A | Scope B |
+|---|---|---|
+| 1 (first after the draft PR) | yes | yes |
+| 2..N | yes | recomputed only if the changed-file set moved |
+| final | yes | **yes, always** |
+
+Do not decide this by memory:
+
+```bash
+keryx review blast-radius --ref "${BASE_SHA}" --previous blast-radius.json [--final]
+```
+
+It prints the decision and the reason, and reuses the previous record when
+nothing moved. The final round recomputes whatever the file set did — otherwise a
+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.
+
+## Fix rounds — dispositions, regressions, withdrawal
+
+### Every prior finding leaves the round with a disposition
+
+A fix round that reports only new findings is unreadable: the author cannot tell
+which of their fixes landed. Close the loop explicitly — one line per prior
+finding, in the report, before the new findings:
+
+| Disposition | Meaning |
+|---|---|
+| `closed` | Checked against the code, not against the commit message, and the defect is gone |
+| `open` | The fix does not reach the defect; say what is still true |
+| `partial` | One site of the class was fixed and the enumeration named others |
+| `regressed` | The fix removed this defect and introduced another — file the new one separately |
+| `withdrawn` | The finding was wrong. See below |
+
+**Check the code, not the commit message.** A commit titled *"report an abandoned
+sync as abandoned"* is a claim; the disposition is whether the branch it renamed
+is reachable and pinned. On a recorded round, two such commits asserted behaviour
+on lines no test could reach.
+
+### A fix is a change, and changes get reviewed
+
+The most expensive class in a multi-round review is **the defect the fix
+introduced**. It is systematically under-found, for a structural reason: the fix
+arrives framed as the answer to a finding, so it is read as an answer rather than
+as new code. It is new code.
+
+So scope A of a fix round includes the fix, reviewed on its own merits, and the
+report carries its own section:
+
+```markdown
+## Regressions the fixes introduced
+<[F-NNN] — the finding it was answering, and the new defect it created>
+```
+
+Recorded shapes, all from fixes that correctly closed the finding they answered:
+an early return added to stop a fall-through, which then skipped the work the
+caller needed; a persistence call added to save expanded state, which then
+persisted the broken state on the error path too. Both were closed correctly and
+both shipped a new bug in the same commit.
+
+### Withdrawing your own earlier finding
+
+A finding from a previous round that this round disproves is **withdrawn**,
+explicitly, at the top of the report, with the evidence — before any new finding.
+
+This is not a courtesy. An uncorrected wrong finding costs the author a fix they
+did not need, and it stays in `prior_findings` steering later rounds. Withdrawal
+is also the one self-correction this pipeline permits, and it is permitted because
+it is asymmetric: it *deletes* a claim, so it cannot inflate the finding count,
+which is the failure mode that removed the re-scoring pass from Wave C.
+
+State what made the original claim wrong, in one sentence, and if the same
+reasoning error has now happened twice in one review, say that too. A reviewer
+that names its own recurring error is calibrating; one that quietly drops a
+finding is hiding a result.

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

@@ -19,10 +19,16 @@ metadata:
 license: "MIT"
 ---
 # Review Orchestrator
-Entry point for the entire review domain. This skill is a thin router: it detects scope,
-dispatches specialized reviewers in parallel, then consolidates their findings into one
-unified report sorted by severity. It does not perform any review logic itself.
----
+
+**You are the orchestrator. Run the round yourself, inline, in the main session that loaded this skill; never hand the whole round to one subagent.** This skill routes: it detects scope, dispatches specialized reviewers, and consolidates their findings into one report sorted by severity. The reviewers do the reviewing.
+
+## Preflight — before Step 0, in this order
+
+1. **Can it spawn?** The round needs the `Agent` tool (or the host's equivalent) and depth budget left: Claude Code nests subagents at most 3 deep, and at the limit `Agent` is withheld. If it cannot spawn, the whole output is this line, with no tool calls and no review of your own:
+   `STATUS: BLOCKED nested_dispatch_unavailable — run this skill in the main session`
+2. **Is a round needed?** A diff of only docs, markdown, comments, formatting, lockfiles or generated files, with no CI, auth, migration or rule-bearing config, ends here with one line, `round not needed: <reason>`, and no reviewer. `--all`, an explicit reviewer list or a gating round forces a round.
+3. **Round ceiling.** 5 rounds (`REVIEW_ROUND_CAP`) over the same `merge-base..HEAD`. Past it: interactive, ask the operator; unattended, `STATUS: BLOCKED round_cap`.
+
 ## Workflow
 
 ```
@@ -36,16 +42,16 @@ Review Orchestrator Progress:
 - [ ] Step 4: Parse flags / auto-detect domain from scope
 - [ ] Step 5: Start questions, once, after Steps 1 and 3 — reviewers (default `--all`), counterpart verification (default on), model plan; unattended takes the defaults (SKILL.detail.md § "Start questions"; legacy/profile reviewers stay flag-only)
 - [ ] Step 5c: When `review.jev.select` is on, run `keryx review jev-select` over the finalized candidate set and drop its `skip` decisions from Wave A/B — see "Reviewer selection with Jev"
-- [ ] Step 6: Plan sub-agent dispatch and token budgets, and compute each dispatch's model with `keryx review tier` — never by hand
+- [ ] Step 6: Plan sub-agent dispatch and token budgets; compute each dispatch's model with `keryx review tier` (6a: publish this plan)
 - [ ] Step 7: Stage 1 gate - spec compliance check (if issue/task provided)
-- [ ] Step 8: Dispatch selected reviewers in PARALLEL with reviewer-input schema
+- [ ] Step 8: Dispatch selected reviewers in parallel with the reviewer-input schema — see "How to spawn"
 - [ ] Step 9: Collect reviewer-finding schema results and handle NEEDS_CONTEXT
 - [ ] Step 9b: `jev-triage` — advisory, annotate-only severity/duplicate/verify-order annotations over the consolidated findings (opt-in `review.jev.triage`)
-- [ ] Step 10: Wave C — dispatch `review-verifier` over the consolidated findings
+- [ ] Step 10: Wave C — when blockers/majors exist, `--verify` is set, or the PR is high-risk, dispatch `review-verifier` over the consolidated findings
 - [ ] Step 11: Sort by severity, deduplicate, emit unified report
 - [ ] Step 12: Emit the machine-readable `keryx:findings` block alongside the report
 - [ ] Step 13: Report the stage counts: dropped by pre-filter, refuted by the verifier, retained
-- [ ] Step 14: MANAGED rounds only (NEVER in `lightweight`, which is report-only), AFTER THE FINAL ROUND, on an OPEN pull request at the head you reviewed — answer every external comment once, `keryx review comments reply --final` (render with `--dry-run` and get the user's explicit approval first) — never against a pull request the dispatch named as the caller's
+- [ ] Step 14: Managed rounds only (not `lightweight`, which is report-only), after the final round, on an open pull request at the head you reviewed — answer every external comment once with `keryx review comments reply --final` (render with `--dry-run` and get the user's explicit approval first; unattended: do not publish, hand the rendered body back) — never against a pull request the dispatch named as the caller's
 ```
 
 Step 0 runs on **every** round. Step 14 runs **once**, after the last one. They are
@@ -55,22 +61,28 @@ one comment.
 
 ### Step 6 — the model is computed, not chosen
 
-Before dispatching each reviewer, run `keryx review tier` with the signals you
-already hold (`--scope`, `--findings`, `--diff-lines`, `--fix-attempt`,
-`--verifier`, `--security`, `--forced-strategy-change`) and paste the `model`
-block it prints into that dispatch.
+Before dispatching each reviewer, run `keryx review tier` with the signals you hold (`--scope`, `--findings`, `--diff-lines`, `--fix-attempt`, `--verifier`, `--security`, `--forced-strategy-change`) and paste the `model` block it prints into that dispatch. The tier comes from the command, not from reading `rules/core/model-selection.mdc`.
+
+It names a model only if you gave it your session (`--session-provider`/`--session-model` or `KERYX_SESSION_*`) and discovery found another. Otherwise it prints `inherit: true` with the tier — **adaptive**: pick your own runtime's model for that tier (`standard` = your session model; `light`/`deep` = your runtime's lighter/most capable class if its dispatch tool offers one, else the session model). A model id never goes into a dispatch by hand.
+
+### Step 6a — the plan bridge
+
+Publish this checklist with `plan_set` under the ids `step-0`…`step-14` once, here, when scope and dispatch are fixed. Publish each of steps 0–5 that ran as `completed` and each that did not run as `skipped`; publish steps 6–14 as `pending` (`in_progress` for the one starting now). From then on move each item with `plan_update` as its step completes — see the `session-plan-bridge` rule. `completed` means the step's artifact exists: steps 8–10 become `completed` (in the plan and in the report) only after `keryx review ingest` has recorded their results, and a step whose reviewers were `BLOCKED` is `blocked`.
+
+## How to spawn (Steps 8 and 10)
+
+- One `Agent` call per reviewer, all calls of a wave in a single message, so the wave runs in parallel.
+- Use the reviewer's exact `subagent_type`. If the runtime has no such type, use `general-purpose` and name the reviewer's `SKILL.md` path in the prompt. Neither available: that reviewer is `BLOCKED`.
+- Prompts carry pointers, not pasted files — the diff, the SHAs, the PR, the schema paths — and never paraphrase a contract.
+- A reply is a result only if it starts with a `STATUS:` line and carries a `REVIEW_RESULT` block matching `reviewer-finding.schema.json`; anything else is `BLOCKED`.
+- The model comes from `keryx review tier` (Step 6).
 
-Do NOT assign the tier by reading the table in `rules/core/model-selection.mdc`. Plan bridge: publish this checklist with `plan_set` under the ids `step-0`…`step-14` ONCE, here at Step 6 when scope and dispatch are fixed — never earlier. Publish each of steps 0–5 that ran as `completed`, publish any of steps 0–5 that did NOT run as `skipped`, and publish steps 6–14 as `pending` (or `in_progress` for whichever of them is starting right now) — and from then on move each item with `plan_update` as its step completes — see the `session-plan-bridge` rule. `completed` means the step's artifact exists: steps 8–10 become `completed` (in the plan and in the report) only after `keryx review ingest` has recorded their results, and a step whose reviewers were `BLOCKED` is `blocked`, never `completed`.
-Working it out in your head is exactly the mechanical step that rule moves into
-code — and it is the step that was documented as running for a whole release
-while nothing called it.
+## Control
 
-It names a model only if you gave it your session (`--session-provider`/
-`--session-model` or `KERYX_SESSION_*`) and discovery found another. Otherwise it prints
-`inherit: true` with the tier — **adaptive**: pick your own runtime's model for
-that tier (`standard` = your session model; `light`/`deep` = your runtime's
-lighter/most capable class if its dispatch tool offers one, else the session
-model). Never "fix" it by writing a model id into a dispatch.
+- **Profiles.** The default is read-only: one round, no edits. `--fix` hands the findings to `flow-orchestrator` or `task-implementer`; the orchestrator never edits code. Control returns to this main session after each hand-off, which loads this skill again (never the implementer, which would nest); each re-review counts toward the ceiling (it adds 1 to the count).
+- **Waves.** Split by diff domain (`core` = logic, security, architecture; `domain` = frontend, backend, conventions; `support` = style, tests), in that order; A/B/C below keep their dependency order. A full or `--all` round runs at most 10 reviewers per wave (`MAX_REVIEWERS_PER_WAVE_FULL`).
+- **Rate limits.** On a reviewer dispatch that fails with a rate-limit or overloaded error (reported as `STATUS: RATE_LIMITED`, a harness signal, not a schema status), halve the wave, requeue the rest and honour `retry-after`. After at most two halvings (`MAX_RATE_HALVINGS`) stop with `STATUS: BLOCKED rate_limited`, naming the queue left.
+- **Done when** every dispatched reviewer's result is recorded with `keryx review ingest`, the stage counts and **Not run** are in the report, and `keryx review complete` has run.
 
 ---
 
@@ -520,7 +532,8 @@ The rule that follows for reviewers, and that belongs in the dispatch prompt:
 
 If you cannot locate the producer, ask the operator where it is (Start question 2); record `state: unavailable` only when it cannot be read, and leave the dependent findings at `info`.
 An unavailable producer is a result. Assuming one is not. An input rule records the producer's full check set and is verified every round,
-paired PR or not — SKILL.detail.md § "Counterpart verification".
+paired PR or not — SKILL.detail.md § "Counterpart verification". Unattended, nobody is asked: record
+`state: unavailable` with the reason and continue.
 
 A finding whose evidence lives in the producer sets `repo` on the finding itself.
 `file` and `line` alone name a path in the repository under review, so without
@@ -611,6 +624,8 @@ This PR touches high-risk areas. Build full review context before dispatching re
 > pick a letter (default: A)
 ```
 
+Unattended: take A and record it in the review scope.
+
 ---
 
 ## Token and Context Budget Management
@@ -639,31 +654,22 @@ Default budget guidance:
 
 ## Model Strategy
 
-The model for each dispatch is computed, not chosen — see Step 6. Before every
-reviewer dispatch, run `keryx review tier` with the signals you hold and paste
-the `model` block it prints into that dispatch. Do not assign a model class by
-reading a table or by hand; that mechanical step is exactly what the command
-replaced (see Step 6 above and `job-orchestrator` Step 5, which pins the same
-rule: `model_strategy: "current"` is gone).
-
-`model_strategy` now governs only how the *computed* model is surfaced, not
-whether it is computed:
+The model per dispatch is computed by `keryx review tier` (Step 6) and never written by hand.
+`model_strategy` governs only how the computed model is surfaced:
 
 | `model_strategy` | Behavior |
 |---|---|
 | `ask` (default, interactive) | Present the `keryx review tier` model plan once before dispatch — Start question 3; the operator may accept it, take all `deep`, or set it. |
 | `adaptive` (default, unattended) | Dispatch on the computed model directly; record the chosen model per reviewer in the final report metadata. |
 
-Rules:
-- Never write a model id into a dispatch by hand — paste the `model` block `keryx review tier` printed.
-- `inherit: true` is the adaptive answer: dispatch on your runtime's model for the block's `tier` (Step 6). Record `model_assignment: adaptive` and the model you actually chose — not a failure.
-- With `model_strategy: ask`, present the model plan once before dispatch, then proceed with the computed model.
+`inherit: true` is the adaptive answer: dispatch on your runtime's model for the block's `tier`, and
+record `model_assignment: adaptive` with the model you chose.
 
 ---
 
 ## Scope Detection
 
-### Step 0: Is this a fix round?
+### Fix round check (Step 1a)
 
 A **fix round** is any review of work produced to answer earlier findings. Set
 `is_fix_round: true` on every reviewer input, and populate `prior_findings` with
@@ -702,63 +708,14 @@ Recording the enumeration matters as much as doing it: a round that searched and
 found nothing is a different fact from a round that never searched, and only the
 recorded list distinguishes them.
 
-#### Every prior finding leaves the round with a disposition
-
-A fix round that reports only new findings is unreadable: the author cannot tell
-which of their fixes landed. Close the loop explicitly — one line per prior
-finding, in the report, before the new findings:
-
-| Disposition | Meaning |
-|---|---|
-| `closed` | Checked against the code, not against the commit message, and the defect is gone |
-| `open` | The fix does not reach the defect; say what is still true |
-| `partial` | One site of the class was fixed and the enumeration named others |
-| `regressed` | The fix removed this defect and introduced another — file the new one separately |
-| `withdrawn` | The finding was wrong. See below |
-
-**Check the code, not the commit message.** A commit titled *"report an abandoned
-sync as abandoned"* is a claim; the disposition is whether the branch it renamed
-is reachable and pinned. On a recorded round, two such commits asserted behaviour
-on lines no test could reach.
-
-#### A fix is a change, and changes get reviewed
-
-The most expensive class in a multi-round review is **the defect the fix
-introduced**. It is systematically under-found, for a structural reason: the fix
-arrives framed as the answer to a finding, so it is read as an answer rather than
-as new code. It is new code.
+Every prior finding leaves the round with a disposition — `closed`, `open`, `partial`,
+`regressed` or `withdrawn` — one line each in the report before the new findings, checked against
+the code and not the commit message. A fix is new code: scope A includes it, and the report carries
+a `## Regressions the fixes introduced` section. A finding this round disproves is withdrawn at the
+top of the report with its evidence. The table, recorded shapes and rationale:
+`SKILL.detail.md` § "Fix rounds — dispositions, regressions, withdrawal".
 
-So scope A of a fix round includes the fix, reviewed on its own merits, and the
-report carries its own section:
-
-```markdown
-## Regressions the fixes introduced
-<[F-NNN] — the finding it was answering, and the new defect it created>
-```
-
-Recorded shapes, all from fixes that correctly closed the finding they answered:
-an early return added to stop a fall-through, which then skipped the work the
-caller needed; a persistence call added to save expanded state, which then
-persisted the broken state on the error path too. Both were closed correctly and
-both shipped a new bug in the same commit.
-
-#### Withdrawing your own earlier finding
-
-A finding from a previous round that this round disproves is **withdrawn**,
-explicitly, at the top of the report, with the evidence — before any new finding.
-
-This is not a courtesy. An uncorrected wrong finding costs the author a fix they
-did not need, and it stays in `prior_findings` steering later rounds. Withdrawal
-is also the one self-correction this pipeline permits, and it is permitted because
-it is asymmetric: it *deletes* a claim, so it cannot inflate the finding count,
-which is the failure mode that removed the re-scoring pass from Wave C.
-
-State what made the original claim wrong, in one sentence, and if the same
-reasoning error has now happened twice in one review, say that too. A reviewer
-that names its own recurring error is calibrating; one that quietly drops a
-finding is hiding a result.
-
-### Step 1: Determine Review Mode
+### Step 2: Determine Review Mode
 
 Before anything else, determine whether the request is **diff mode** or **path mode**:
 
@@ -832,72 +789,23 @@ keryx review blast-radius --ref "${BASE_SHA}" --brief                      # wha
 scope-B finding arrives without it — pass it back as
 `review ingest ... --blast-radius blast-radius.json`.
 
-It walks `gdgraph affected` outward from every changed file, ranks by edge
-distance, keeps distance ≤ 2, cuts at 40 files closest-first, and adds a changed
-file's naming-related tests when the graph did not already reach them. Requires a
-built graph — run `keryx gdgraph build` if it refuses.
-
-**Do not pick the files yourself, and do not widen it.** "Review the
-functionality so nothing breaks" naively means "review the whole repository every
-round", which is unaffordable *and* actively harmful: review quality decays as
-context grows — measured F1 0.65 at round 2 falling to 0.29 at round 10. An
-unbounded scope B makes later rounds worse than earlier ones.
-
-The bounds are measured on this repository, not guessed: at depth 2 the set is a
-median of 19 files (p90 65); depth 3 buys eight more in the median and doubles
-the p90. The 40-file cap fires on 25% of commits and removes only hop-2 entries
-on all but 2 of 80, so it almost never costs a direct dependent — and when it
-does, it says so.
-
-**Record the whole thing.** `--out "<review-package>/blast-radius.md"` writes the
-set, the depth, and **every file the cap removed**. A truncation nobody can see
-reads afterwards as "we checked everything", which is the claim this pipeline
-exists to stop making. An empty radius is reported as `unresolved`, not as clean:
-the graph indexes code, so a change to a skill, a rule or a schema has no blast
-radius at all and that is a different fact from "nothing depends on it".
-
-#### The scope-B question, and what is rejected
-
-> Does this change break an existing behaviour **at these sites**?
-
-Nothing else. The blast-radius set is **under regression check, not under
-review**. A finding about style, naming or architecture in code the change did
-not touch is refused **by the orchestrator in code** — not discouraged here —
-under three rules, every one of them a fact about the claim rather than about who
-made it:
-
-| Rule | Refused because |
-|---|---|
-| `outside-set` | the file is neither in the computed set nor in the changed set; the reviewer went browsing |
-| `non-regression-severity` | below `major`. Under the canonical rubric `minor` states the code behaves correctly and `info` names neither trigger nor outcome; neither can be a claim that something broke |
-| `no-link-to-change` | nothing in the finding names a changed file, module or symbol. A regression claim says THE CHANGE broke this site |
+Scope B is bounded and computed: distance ≤ 2 from every changed file, at most 40 files, closest
+first. Do not pick the files or widen the set. Record it with `--out "<review-package>/blast-radius.md"`,
+including every file the cap removed; an empty radius is `unresolved`, not clean.
 
-Rejections are **recorded, not deleted** — raise the observation under scope A or
-as a separate review. Pass `--brief` output verbatim into the scope-B dispatch:
-the code rejection is the enforcement, but a reviewer told afterwards has already
-spent the round producing findings that will all be refused.
+A scope-B reviewer answers one question: does this change break an existing behaviour **at these
+sites**? The orchestrator refuses, in code, a finding that is `outside-set`, below `major`
+(`non-regression-severity`), or names nothing the change touched (`no-link-to-change`) — pass
+`--brief` verbatim so no reviewer spends the round on findings that will be refused. `class_scope`
+names the caller that breaks.
 
-`class_scope` on a scope-B finding names the **caller that breaks**, not the
-changed line, because that is the site a human has to look at.
-
-#### When it is recomputed
-
-| Round | Scope A | Scope B |
-|---|---|---|
-| 1 (first after the draft PR) | yes | yes |
-| 2..N | yes | recomputed only if the changed-file set moved |
-| final | yes | **yes, always** |
-
-Do not decide this by memory:
+Recompute scope B on rounds 2..N only when the changed-file set moved, and always on the final round:
 
 ```bash
 keryx review blast-radius --ref "${BASE_SHA}" --previous blast-radius.json [--final]
 ```
 
-It prints the decision and the reason, and reuses the previous record when
-nothing moved. The final round recomputes whatever the file set did — otherwise a
-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.
+The measurements, the rule table and the recompute table: `SKILL.detail.md` § "Scope B — bounds, rejections and recompute".
 
 ### Path Mode
 
@@ -905,10 +813,10 @@ When a path or target is named, collect the candidate files:
 
 ```bash
 # If a directory path is given:
-find <path> -type f \( -name "*.ts" -o -name "*.tsx" -o -name "*.js" -o -name "*.jsx" \) | sort
+keryx ctx rg --files -g '*.{ts,tsx,js,jsx}' <path> | sort
 
 # If a module name is given (e.g. "UserStore", "pipelines module"):
-find . -type f -name "*<name>*" \( -name "*.ts" -o -name "*.tsx" \)
+keryx ctx rg --files -g '*<name>*.{ts,tsx}'
 # Also check common locations: src/stores/, src/modules/, src/components/
 ```
 
@@ -1069,7 +977,7 @@ Unattended rounds ask nothing: `--all`, counterpart verified, computed models
 and record that choice in the review scope).
 
 A gating round runs what these answers selected; a host that cannot dispatch subagents
-returns `STATUS: BLOCKED` (`nested_dispatch_unavailable`) instead of reviewing alone. Every
+returns `STATUS: BLOCKED` (`nested_dispatch_unavailable`) instead of reviewing alone (Preflight 1). Every
 round also carries the always-on obligations — SKILL.detail.md § "Depth floor",
 § "Counterpart verification", § "Round obligations".
 
@@ -1092,8 +1000,8 @@ Legacy/profile reviewers are specialized review profiles that predate the review
 | `--mobx-store` | `code-mobx-store-review` |
 | `*.store.ts`, `makeObservable`, `observable`, `computed`, `action.bound` | suggest `code-mobx-store-review` as optional profile reviewer |
 
-Legacy/profile reviewers are never auto-included and never prompted for — do not ask the user
-about them. They are exempt from the finding contract (for example `code-ai-review` emits
+Legacy/profile reviewers are never auto-included and never prompted for, interactive or unattended — do not
+ask about them. They are exempt from the finding contract (for example `code-ai-review` emits
 free-prose Russian with no per-finding severity field, so its output cannot be normalised into
 the unified report), which is why inclusion must be a deliberate, explicit act rather than a
 default the user has to opt out of on every review. Dispatch them ONLY when the user passes one
@@ -1185,7 +1093,7 @@ whoever reads the merge commit a year later reads the body. When `review.jev.con
 
 New managed packages declare `reviewerDispatch: "research.json"`. Alongside the research ledger, provide `dispatch: { version: 1, selected: [...], unresolvedRules: [], runs: [...] }`. Preserve the actual computed reviewer inventory. Each run has `reviewer`, unique `executionId`, `status: "complete"`, `scopeComplete: true`, `rawEvidence`, nonempty `ruleEvidence`, and boolean `executionRequired`. Required execution needs nonempty `executionEvidence` (command/output references); a source-only scope requires `executionReason`. Do not fabricate IDs or mark truncated responses complete. Runtime validates these declarations at closure and the flow gate, not their truth: independently audit evidence and inventory before freezing. Legacy artifact absence is compatibility, not proof of a correct launch. Research closure is mandatory: see [Runtime research-completion ledger](SKILL.detail.md#runtime-research-completion-ledger).
 
-Dispatch selected reviewers in parallel when independent — this engine dispatches them itself; a host without a dispatch tool returns `STATUS: BLOCKED` (`nested_dispatch_unavailable`) and never reviews alone. Use waves when token budget is tight or when one reviewer needs another result:
+Dispatch selected reviewers in parallel when independent — this engine dispatches them itself (see "How to spawn"); a host without a dispatch tool returns `STATUS: BLOCKED` (`nested_dispatch_unavailable`) and never reviews alone — Preflight 1. Waves follow the diff domains in "Control" and keep their dependency order:
 
 1. Wave A - core correctness/risk reviewers: logic, architecture, security/highload when selected.
 2. Wave B - domain reviewers: frontend/backend/testing/convention reviewers filtered to relevant files. `review-jev-rules` (flow 330), `review-jev-risk`/`review-jev-scenarios` (flow 332), `review-jev-docs`/`review-jev-comments` (flow 333), `review-jev-contract` (flow 335) also run here, CLI-engine not sub-agent, `"engine": "jev"` in `keryx review reviewers --json`, gated on their own opt-in and a resolvable Jev/OpenRouter credential — measured verdicts per reviewer (keep off by default, experimental, etc.) in `SKILL.detail.md` § "CLI-engine reviewers".
@@ -1204,34 +1112,17 @@ not something Wave C can hand you.** If Wave B skips its mutation pass, that
 finding class is unreachable for the entire round, and no amount of verification
 downstream recovers it. When a testing reviewer returns without a mutation table,
 treat it the way you would treat a reviewer that returned without findings *and*
-without evidence: ask once, then record that the pass did not run.
+without evidence: ask once, then record that the pass did not run. Unattended: record
+`Not run: mutation pass` without asking.
 
 ### Wave C — verification, and what it replaced
 
-Wave C used to run `review-strict`: a meta-pass that re-read the consolidated
-findings and **adjusted their severity with no new evidence**, under an elevation
-table biased 3:1 toward escalation. It was **removed, not improved**, and the
-reason is measured rather than stylistic:
-
-- **GPT-4 on GSM8K across self-correction rounds: 95.5 → 91.5 → 89.0.**
-  **GPT-3.5 on CommonSenseQA: 75.8 → 38.1.** Among the answers that changed,
-  correct → incorrect exceeded incorrect → correct (Huang et al., *Large Language
-  Models Cannot Self-Correct Reasoning Yet*, ICLR 2024, arXiv:2310.01798).
-- **Self-Refine (arXiv:2303.17651): +49.2 on dialogue response generation, +0.2
-  on maths.** Self-refinement gains are on subjective tasks and vanish on
-  verifiable reasoning. Judging whether a null-guard is missing is verifiable
-  reasoning.
-
-Re-scoring a finding by re-reading it is therefore not a rigour pass; it is a
-coin flip weighted toward more findings. **Do not restore it because it looks
-obviously useful — it looked obviously useful the first time.**
-
-`review-verifier` occupies the slot and differs in exactly one way that matters:
-**it runs something.** Verification that executes rejects 85–96% of false reports
-against 4–15% unaided while finding 30–44% more true bugs (AnyPoC,
-arXiv:2604.11950); Meta's TestGen-LLM funnel discards 75% of its own output
-(75% build → 57% build and pass → 25% improve coverage) and the surviving quarter
-reaches 73% human acceptance (arXiv:2402.09171).
+Wave C replaced `review-strict`, a meta-pass that re-read the findings and adjusted severity with no new evidence. It was **removed, not improved**, on measured evidence:
+self-correction fell 95.5 → 91.5 → 89.0 (GPT-4, GSM8K) and 75.8 → 38.1 (GPT-3.5, CommonSenseQA), arXiv:2310.01798; Self-Refine's +49.2 on dialogue response generation is +0.2 on maths
+(arXiv:2303.17651), so re-reading helps subjective tasks and not verifiable ones. A verifier that **runs something** rejects most false reports.
+Do not restore the re-score because it looks useful. Full figures: `SKILL.detail.md` § "Why Wave C verifies instead of re-scoring".
+
+`review-verifier` occupies the slot and differs in one way that matters: it runs something.
 
 It also **never votes.** 80+ agents unanimously endorsed a padding-oracle
 vulnerability that did not exist, and a single empirical test killed it: consensus
@@ -1346,12 +1237,21 @@ Each reviewer must return a `REVIEW_RESULT` object matching `.metaproject/skills
 ## Sub-Agent Report Quality Gate
 
 Before consolidation, validate every reviewer result:
-- Required status: `DONE`, `DONE_WITH_CONCERNS`, `NEEDS_CONTEXT`, or `BLOCKED`.
+- Every reply starts with a `STATUS:` line, and each status has one action:
+
+| Status | Action |
+|---|---|
+| `DONE` | Consolidate. |
+| `DONE_WITH_CONCERNS` | Consolidate and carry the concerns into the report. |
+| `NEEDS_CONTEXT` | One targeted context refill; if still unresolved, keep it as an explicit open question, not a blocker. |
+| `BLOCKED` | Re-dispatch once; if it fails again, list the pass under **Not run**. |
+| `RATE_LIMITED` | Halve the wave and requeue (Control). |
+| anything else, or no result | Treat as `BLOCKED`. |
+
 - Required finding fields: id, severity, file, `quote`, problem, impact, suggested_fix, evidence, confidence, reviewer. **`quote`, not `line`:** copy the code the finding is about verbatim out of `file` and do not count lines — `keryx review ingest` locates the quote at the round's head and derives `line` from where it matched, so a number reported here is overwritten. A model is poor at counting lines and good at repeating text it has just read; this asks only for the second. Quote enough to be unambiguous: a snippet appearing twice in the file is recorded `unlocatable` rather than anchored to the first hit. A finding about the round rather than a site carries neither.
 - Every blocker must include evidence and a concrete suggested fix.
 - Findings without evidence are downgraded to `info` or returned to the reviewer for clarification.
 - Duplicate findings are merged by `dedupe_key` or by `(file, quote, problem)`.
-- `NEEDS_CONTEXT` triggers one targeted context refill. If still unresolved, keep it as an explicit open question, not as a blocker.
 - **A reply that is not a result is `BLOCKED`.** That covers an empty reply (`(subagent produced no text)`), a reply without a valid `REVIEW_RESULT` block, and a `spawn_subagent` output whose first line is `status: BudgetExhausted (…)` or `status: NoProgress …` — the reviewer was cut short, so whatever fragment it left is not its review. Re-dispatch it exactly once with a larger budget, telling it to return its report before the budget ends (and the same `cwd` when the round reviews a worktree). If that also fails, the pass is **not run**: list it under **Not run** with the reason, and never write its findings yourself — a review nobody ran reported as run is worse than a gap the operator can see.
 - **The verifier is held to the same rule.** A finding without an applied verifier verdict is `unverified`; the orchestrator never verifies one itself, and a verifier that returned nothing leaves every finding `unverified`, stated in the stage counts.
 - If a reviewer exceeds `max_findings`, keep blockers/majors first and summarize lower severity findings.
@@ -1652,6 +1552,8 @@ Automation values, names unchanged:
 - `comment-and-ai-artifact` -> the PR review plus the follow-up file.
 - `none` or legacy `false` -> do not publish.
 
+Unattended: do not publish; hand the rendered body back to the caller.
+
 Default is do not publish. No resolvable PR number means skip and say so.
 
 The review body is the report rendered from `templates/review-report.md`, English, with the domain file chosen above (`templates/pr-comment-frontend.md` / `templates/pr-comment-backend.md`) — never a summary written freehand. It does not use a tool heading, a finding table, or a meta table. It does not carry a co-author line, a `Generated with` trailer, or any sentence that names a vendor or a product as the author. Name the workflow and reviewers that actually ran, with models, tools, skills and subagents. Never identify the operator from `gh auth status`, git config or a credential; do not sign the review as a person, reviewer or model. A project overlay adds content only through the template's overlay slots.
@@ -1707,6 +1609,7 @@ If absent, proceed normally — context is optional and non-blocking.
 | "The spec-gate finding is mine, so `reviewer: review-orchestrator`" | That name makes the finding unroutable in Wave C. File it under the reviewer that ran the comparison |
 | "Steps 8–10 are done, I'll tick them now and ingest later" | `completed` means the ingest record exists. A plan that runs ahead of the artifacts is how an unrun review looked finished |
 | "The user said publish, so I can post the comment" | That chose whether, not what. Show the rendered body and get approval of it before any GitHub write |
+| "I cannot spawn reviewers, so I will review it myself" | A review nobody dispatched is not the review the report names. Output the Preflight 1 `BLOCKED` line and stop |
 | "No flags means no reviewers" | No flags → run auto-detection; never produce an empty review |
 | "User named a module so I'll use diff mode" | Named module/component/store → path mode; diff mode is only for branch changes |
 | "Path mode should only show lines I'd flag in diff mode" | Path mode reviews the entire file — all findings apply, not just added lines |