@fro.bot/systematic 3.10.0 → 3.10.2

package/agents/review/architecture-strategist.md

@@ -1,6 +1,6 @@
 ---
 name: architecture-strategist
-description: "Analyzes code changes from an architectural perspective for pattern compliance and design integrity. Use when reviewing PRs, adding services, or evaluating structural refactors."
+description: "Analyzes code changes from an architectural perspective for pattern compliance and design integrity. Use when reviewing PRs, adding services, or evaluating structural refactors. Dispatched by deepen-plan and ce-plan's deepening workflow, not by ce:review."
 tools: Read, Grep, Glob, Bash
 mode: subagent
 temperature: 0.1

package/agents/review/code-simplicity-reviewer.md

@@ -1,6 +1,6 @@
 ---
 name: code-simplicity-reviewer
-description: "Final review pass to ensure code is as simple and minimal as possible. Use after implementation is complete to identify YAGNI violations and simplification opportunities."
+description: "Final review pass to ensure code is as simple and minimal as possible. Use after implementation is complete to identify YAGNI violations and simplification opportunities. Dispatched by ce-compound for code-heavy issues, not by ce:review."
 tools: Read, Grep, Glob, Bash
 mode: subagent
 temperature: 0.1

package/agents/review/pattern-recognition-specialist.md

@@ -1,6 +1,6 @@
 ---
 name: pattern-recognition-specialist
-description: "Analyzes code for design patterns, anti-patterns, naming conventions, and duplication. Use when checking codebase consistency or verifying new code follows established patterns."
+description: "Analyzes code for design patterns, anti-patterns, naming conventions, and duplication. Use when checking codebase consistency or verifying new code follows established patterns. Dispatched by deepen-plan, ce-plan's deepening workflow, and ce-compound, not by ce:review."
 tools: Read, Grep, Glob, Bash
 mode: subagent
 temperature: 0.6

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@fro.bot/systematic",
-  "version": "3.10.0",
+  "version": "3.10.2",
   "description": "Compound-engineering loops for OpenCode, Pi, and Claude Code",
   "type": "module",
   "homepage": "https://fro.bot/systematic",

package/skills/agent-native-audit/SKILL.md

@@ -34,7 +34,7 @@ Select option 7 (action parity) to load the full reference material.
 
 ### Step 2: Launch Parallel Sub-Agents
 
-Launch 8 parallel sub-agents using the task tool with `subagent_type: Explore`, one for each principle. Each agent should:
+Launch 8 parallel sub-agents using the bundled `systematic:research:repo-research-analyst` agent, one for each principle. Each agent should:
 
 1. Enumerate ALL instances in the codebase (user actions, tools, contexts, data stores, etc.)
 2. Check compliance against the principle

package/skills/ce-compound/SKILL.md

@@ -86,7 +86,7 @@ Launch research subagents. Each returns text data to the orchestrator.
 
 <parallel_tasks>
 
-#### 1. **Context Analyzer**
+#### 1. **Context Analyzer** — `systematic:research:repo-research-analyst`
    - Extracts conversation history
    - Reads `references/schema.yaml` for enum validation and **track classification**
    - Determines the track (bug or knowledge) from the problem_type
@@ -100,7 +100,7 @@ Launch research subagents. Each returns text data to the orchestrator.
    - Does not invent enum values, categories, or frontmatter fields from memory; reads the schema and mapping files above
    - Does not force bug-track fields onto knowledge-track learnings or vice versa
 
-#### 2. **Solution Extractor**
+#### 2. **Solution Extractor** — `systematic:research:repo-research-analyst`
    - Reads `references/schema.yaml` for track classification (bug vs knowledge)
    - Adapts output structure based on the problem_type track
    - Incorporates auto memory excerpts (if provided by the orchestrator) as supplementary evidence -- conversation history and the verified fix take priority; if memory notes contradict the conversation, note the contradiction as cautionary context
@@ -122,7 +122,7 @@ Launch research subagents. Each returns text data to the orchestrator.
    - **When to Apply**: Conditions or situations where this applies
    - **Examples**: Concrete before/after or usage examples showing the practice in action
 
-#### 3. **Related Docs Finder**
+#### 3. **Related Docs Finder** — `systematic:research:learnings-researcher`
    - Searches `docs/solutions/` for related documentation
    - Identifies cross-references and links
    - Finds related GitHub issues

package/skills/ce-ideate/SKILL.md

@@ -99,7 +99,7 @@ Before generating ideas, gather codebase context.
 
 Run agents in parallel in the **foreground** (do not use background dispatch — the results are needed before proceeding):
 
-1. **Quick context scan** — dispatch a general-purpose sub-agent using the platform's cheapest capable model (e.g., `model: "haiku"` in OpenCode) with this prompt:
+1. **Quick context scan** — dispatch `systematic:research:repo-research-analyst` with this prompt:
 
    > Read the project's AGENTS.md (or AGENTS.md only as compatibility fallback, then README.md if neither exists), then discover the top-level directory layout using the native file-search/glob tool (e.g., `Glob` with pattern `*` or `*/*` in OpenCode). Return a concise summary (under 30 lines) covering:
    > - project shape (language, framework, top-level directory layout)

package/skills/ce-plan/references/deepening-workflow.md

@@ -99,42 +99,42 @@ Use fully-qualified agent names inside Task calls.
 **Deterministic Section-to-Agent Mapping:**
 
 **Requirements / Open Questions classification**
-- `ce-spec-flow-analyzer` for missing user flows, edge cases, and handoff gaps
-- `ce-repo-research-analyst` (Scope: `architecture, patterns`) for repo-grounded patterns, conventions, and implementation reality checks
+- `systematic:workflow:spec-flow-analyzer` for missing user flows, edge cases, and handoff gaps
+- `systematic:research:repo-research-analyst` (Scope: `architecture, patterns`) for repo-grounded patterns, conventions, and implementation reality checks
 
 **Context & Research / Sources & References gaps**
-- `ce-learnings-researcher` for institutional knowledge and past solved problems
-- `ce-framework-docs-researcher` for official framework or library behavior
-- `ce-best-practices-researcher` for current external patterns and industry guidance
-- Add `ce-git-history-analyzer` only when historical rationale or prior art is materially missing
+- `systematic:research:learnings-researcher` for institutional knowledge and past solved problems
+- `systematic:research:framework-docs-researcher` for official framework or library behavior
+- `systematic:research:best-practices-researcher` for current external patterns and industry guidance
+- Add `systematic:research:git-history-analyzer` only when historical rationale or prior art is materially missing
 
 **Key Technical Decisions**
-- `ce-architecture-strategist` for design integrity, boundaries, and architectural tradeoffs
-- Add `ce-framework-docs-researcher` or `ce-best-practices-researcher` when the decision needs external grounding beyond repo evidence
+- `systematic:review:architecture-strategist` for design integrity, boundaries, and architectural tradeoffs
+- Add `systematic:research:framework-docs-researcher` or `systematic:research:best-practices-researcher` when the decision needs external grounding beyond repo evidence
 
 **High-Level Technical Design**
-- `ce-architecture-strategist` for validating that the technical design accurately represents the intended approach and identifying gaps
-- `ce-repo-research-analyst` (Scope: `architecture, patterns`) for grounding the technical design in existing repo patterns and conventions
-- Add `ce-best-practices-researcher` when the technical design involves a DSL, API surface, or pattern that benefits from external validation
+- `systematic:review:architecture-strategist` for validating that the technical design accurately represents the intended approach and identifying gaps
+- `systematic:research:repo-research-analyst` (Scope: `architecture, patterns`) for grounding the technical design in existing repo patterns and conventions
+- Add `systematic:research:best-practices-researcher` when the technical design involves a DSL, API surface, or pattern that benefits from external validation
 
 **Implementation Units / Verification**
-- `ce-repo-research-analyst` (Scope: `patterns`) for concrete file targets, patterns to follow, and repo-specific sequencing clues
-- `ce-pattern-recognition-specialist` for consistency, duplication risks, and alignment with existing patterns
-- Add `ce-spec-flow-analyzer` when sequencing depends on user flow or handoff completeness
+- `systematic:research:repo-research-analyst` (Scope: `patterns`) for concrete file targets, patterns to follow, and repo-specific sequencing clues
+- `systematic:review:pattern-recognition-specialist` for consistency, duplication risks, and alignment with existing patterns
+- Add `systematic:workflow:spec-flow-analyzer` when sequencing depends on user flow or handoff completeness
 
 **System-Wide Impact**
-- `ce-architecture-strategist` for cross-boundary effects, interface surfaces, and architectural knock-on impact
+- `systematic:review:architecture-strategist` for cross-boundary effects, interface surfaces, and architectural knock-on impact
 - Add the specific specialist that matches the risk:
-  - `ce-performance-reviewer` for scalability, latency, throughput, and resource-risk analysis
-  - `ce-security-reviewer` for auth, validation, exploit surfaces, and security boundary review
-  - `ce-data-migrations-reviewer` for migrations, persistent state safety, consistency, and data lifecycle risks
+  - `systematic:review:performance-reviewer` for scalability, latency, throughput, and resource-risk analysis
+  - `systematic:review:security-reviewer` for auth, validation, exploit surfaces, and security boundary review
+  - `systematic:review:data-migrations-reviewer` for migrations, persistent state safety, consistency, and data lifecycle risks
 
 **Risks & Dependencies / Operational Notes**
 - Use the specialist that matches the actual risk:
-  - `ce-security-reviewer` for security, auth, privacy, and exploit risk
-  - `ce-data-migrations-reviewer` for persistent data safety, constraints, transaction boundaries, and migration realism
-  - `ce-deployment-verification-agent` for rollout checklists, rollback planning, and launch verification
-  - `ce-performance-reviewer` for capacity, latency, and scaling concerns
+  - `systematic:review:security-reviewer` for security, auth, privacy, and exploit risk
+  - `systematic:review:data-migrations-reviewer` for persistent data safety, constraints, transaction boundaries, and migration realism
+  - `systematic:review:deployment-verification-agent` for rollout checklists, rollback planning, and launch verification
+  - `systematic:review:performance-reviewer` for capacity, latency, and scaling concerns
 
 **Agent Prompt Shape:**
 
@@ -200,7 +200,7 @@ Skip this step in auto mode — proceed directly to 5.3.7.
 
 In interactive mode, present each agent's findings to the user before integration. For each agent that returned findings:
 
-1. **Summarize the agent and its target section** — e.g., "The ce-architecture-strategist reviewed Key Technical Decisions and found:"
+1. **Summarize the agent and its target section** — e.g., "The systematic:review:architecture-strategist reviewed Key Technical Decisions and found:"
 2. **Present the findings concisely** — bullet the key points, not the raw agent output. Include enough context for the user to evaluate: what the agent found, what evidence supports it, and what plan change it implies.
 3. **Ask the user** using the platform's blocking question tool when available (see Interaction Method):
    - **Accept** — integrate these findings into the plan

package/skills/ce-review/SKILL.md

@@ -64,7 +64,7 @@ All tokens are optional. Each one present means one less thing to infer. When ab
 - **Skip all user questions.** Never use the platform question tool (`question` in OpenCode, `request_user_input` in Codex, `ask_user` in Gemini; in Pi, use the blocking-question extension if available, otherwise present numbered options in chat and wait) or other interactive prompts. Infer intent conservatively if the diff metadata is thin.
 - **Require a determinable diff scope.** If headless mode cannot determine a diff scope (no branch, PR, or `base:` ref determinable without user interaction), emit `Review failed (headless mode). Reason: no diff scope detected. Re-invoke with a branch name, PR number, or base:<ref>.` and stop without dispatching agents.
 - **Apply only `safe_auto -> review-fixer` findings in a single pass.** No bounded re-review rounds. Leave `gated_auto`, `manual`, `human`, and `release` work unresolved and return them in the structured output.
-- **Return all non-auto findings as structured text output.** Use the headless output envelope format (see Stage 6 below) preserving severity, autofix_class, owner, requires_verification, confidence, pre_existing, and suggested_fix per finding. Enrich with detail-tier fields (why_it_matters, evidence[]) from the per-agent artifact files on disk (see Detail enrichment in Stage 6).
+- **Return all non-auto findings as structured text output.** Use the headless output envelope format (see Stage 6 below) preserving severity, autofix_class, owner, requires_verification, confidence, pre_existing, and suggested_fix per finding. Enrich with detail-tier fields (why_it_matters, evidence[]) from the validated inline persona returns (see Detail enrichment in Stage 6).
 - **Write a run artifact** under `.context/systematic/ce-review/<run-id>/` summarizing findings, applied fixes, and advisory outputs. Include the artifact path in the structured output.
 - **Do not create todo files.** The caller receives structured findings and routes downstream work itself.
 - **Do not switch the shared checkout.** If the caller passes an explicit PR or branch target, `mode:headless` must run in an isolated checkout/worktree or stop instead of running `gh pr checkout` / `git checkout`. When stopping, emit `Review failed (headless mode). Reason: cannot switch shared checkout. Re-invoke with base:<ref> to review the current checkout, or run from an isolated worktree.`
@@ -371,28 +371,30 @@ Pass the resulting path list to the `project-standards` persona inside a `<stand
 
 ### Stage 4: Spawn sub-agents
 
-#### Model tiering
+#### Sub-agent dispatch and model policy
 
-Persona sub-agents do focused, scoped work and should use a fast mid-tier model to reduce cost and latency without sacrificing review quality. The orchestrator itself stays on the default (most capable) model.
+Persona sub-agents do focused, scoped work. Dispatch the named bundled agent for each role so the user's configured model assignment applies; the orchestrator itself stays on the default model.
 
-Use the platform's mid-tier model for all persona and CE sub-agents. In OpenCode, pass `model: "sonnet"` in the Agent tool call. On other platforms, use the equivalent mid-tier (e.g., `gpt-4o` in Codex). If the platform has no model override mechanism or the available model names are unknown, omit the model parameter and let agents inherit the default -- a working review on the parent model is better than a broken dispatch from an unrecognized model name.
+Dispatch named bundled agents for all persona and CE sub-agents. The named agent applies the user's configured model assignment; model policy is user-owned configuration, not a skill-level dispatch parameter.
 
-CE always-on agents (agent-native-reviewer, learnings-researcher) and CE conditional agents (deployment-verification-agent) also use the mid-tier model since they perform scoped, focused work.
+The same applies to CE always-on agents (`systematic:review:agent-native-reviewer`, `systematic:research:learnings-researcher`) and CE conditional agents (`systematic:review:deployment-verification-agent`): dispatch each by its bundled name so its configured assignment applies.
 
 The orchestrator (this skill) stays on the default model because it handles intent discovery, reviewer selection, finding merge/dedup, and synthesis -- tasks that benefit from stronger reasoning.
 
 #### Run ID
 
-Generate a unique run identifier before dispatching any agents. This ID scopes all agent artifact files and the post-review run artifact to the same directory.
+Generate a unique run identifier before dispatching any agents. This ID scopes the parent-owned per-agent records and the post-review run artifact to the same directory.
 
 ```bash
 RUN_ID=$(date +%Y%m%d-%H%M%S)-$(head -c4 /dev/urandom | od -An -tx1 | tr -d ' ')
 mkdir -p ".context/systematic/ce-review/$RUN_ID"
 ```
 
-Pass `{run_id}` to every persona sub-agent so they can write their full analysis to `.context/systematic/ce-review/{run_id}/{reviewer_name}.json`.
+Keep `{run_id}` in the parent orchestrator. Do not pass it, an artifact path, or any write instruction to persona sub-agents. The parent writes a per-agent record only after the returned payload passes validation.
 
-**Report-only mode:** Skip run-id generation and directory creation. Do not pass `{run_id}` to agents. Agents return compact JSON only with no file write, consistent with report-only's no-write contract.
+Capture the actual invoking harness once in the parent (`opencode`, `pi`, or `claude-code`). Do not infer it from persona metadata or declared tools. Add this parent-owned value to each persisted record and to the synthesis artifact so R6 remains explicit. `mode:report-only` still records nothing because it has no run artifact.
+
+**Report-only mode:** Skip run-id generation and directory creation. Agents return the same full JSON payload, with no file write, consistent with report-only's no-write contract.
 
 #### Spawning
 
@@ -405,14 +407,14 @@ Spawn each selected persona reviewer as a parallel sub-agent using the subagent
 3. The JSON output contract from the findings schema included below
 4. PR metadata: title, body, and URL when reviewing a PR (empty string otherwise). Passed in a `<pr-context>` block so reviewers can verify code against stated intent
 5. Review context: intent summary, file list, diff
-6. Run ID and reviewer name for the artifact file path
+6. Reviewer name for the returned `reviewer` field
 7. **For `project-standards` only:** the standards file path list from Stage 3b, wrapped in a `<standards-paths>` block appended to the review context
 
-Persona sub-agents are **read-only** with respect to the project: they review and return structured JSON. They do not edit project files or propose refactors. The one permitted write is saving their full analysis to the `.context/` artifact path specified in the output contract.
+Persona sub-agents are **read-only** with respect to the project: they review and return structured JSON. They do not edit project files, write artifacts, or propose refactors. The parent orchestrator owns all persistence.
 
 Read-only here means **non-mutating**, not "no shell access." Reviewer sub-agents may use non-mutating inspection commands when needed to gather evidence or verify scope, including read-oriented `git` / `gh` usage such as `git diff`, `git show`, `git blame`, `git log`, and `gh pr view`. They must not edit project files, change branches, commit, push, create PRs, or otherwise mutate the checkout or repository state.
 
-Each persona sub-agent writes full JSON (all schema fields) to `.context/systematic/ce-review/{run_id}/{reviewer_name}.json` and returns compact JSON with merge-tier fields only:
+Each persona sub-agent returns one full JSON payload (all schema fields) to the parent:
 
 ```json
 {
@@ -428,6 +430,10 @@ Each persona sub-agent writes full JSON (all schema fields) to `.context/systema
       "owner": "downstream-resolver",
       "requires_verification": true,
       "pre_existing": false,
+      "why_it_matters": "An unowned lookup can expose another account's orders.",
+      "evidence": [
+        "orders_controller.rb:42 uses params[:id] without an ownership guard."
+      ],
       "suggested_fix": "Add current_user.owns?(account) guard before lookup"
     }
   ],
@@ -436,7 +442,9 @@ Each persona sub-agent writes full JSON (all schema fields) to `.context/systema
 }
 ```
 
-Detail-tier fields (`why_it_matters`, `evidence`) are in the artifact file only. `suggested_fix` is optional in both tiers -- included in compact returns when present so the orchestrator has fix context for auto-apply decisions. If the file write fails, the compact return still provides everything the merge needs.
+`why_it_matters` and `evidence` are returned inline with the merge-tier fields. `suggested_fix` remains optional. The parent validates the complete payload before writing any per-agent record; a malformed or rejected return is never partially persisted.
+
+Returning the detail tier inline increases parent context per persona. The previous compact/detail split kept synthesis context lean, so this is an intentional cost of deleting the sub-agent write path. Verify it against a real multi-persona run. If it materially degrades synthesis, use a second targeted request per persona and keep the write parent-side; never restore sub-agent disk access.
 
 **CE always-on agents** (agent-native-reviewer, learnings-researcher) are dispatched as standard Agent calls in parallel with the persona agents. Give them the same review context bundle the personas receive: entry mode, any PR metadata gathered in Stage 1, intent summary, review base branch name when known, `BASE:` marker, file list, diff, and `UNTRACKED:` scope notes. Do not invoke them with a generic "review this" prompt. Their output is unstructured and synthesized separately in Stage 6.
 
@@ -444,22 +452,22 @@ Detail-tier fields (`why_it_matters`, `evidence`) are in the artifact file only.
 
 ### Stage 5: Merge findings
 
-Convert multiple reviewer compact JSON returns into one deduplicated, confidence-gated finding set. The compact returns contain merge-tier fields (title, severity, file, line, confidence, autofix_class, owner, requires_verification, pre_existing) plus the optional suggested_fix. Detail-tier fields (why_it_matters, evidence) are on disk in the per-agent artifact files and are not loaded at this stage.
-
-1. **Validate.** Check each compact return for required top-level and per-finding fields, plus value constraints. Drop malformed returns or findings. Record the drop count.
-   - **Top-level required:** reviewer (string), findings (array), residual_risks (array), testing_gaps (array). Drop the entire return if any are missing or wrong type.
-   - **Per-finding required:** title, severity, file, line, confidence, autofix_class, owner, requires_verification, pre_existing
-   - **Value constraints:**
-     - severity: P0 | P1 | P2 | P3
-     - autofix_class: safe_auto | gated_auto | manual | advisory
-     - owner: review-fixer | downstream-resolver | human | release
-     - confidence: numeric, 0.0-1.0
-     - line: positive integer
-     - pre_existing, requires_verification: boolean
-   - Do not validate against the full schema here -- the full schema (including why_it_matters and evidence) applies to the artifact files on disk, not the compact returns.
-2. **Confidence gate.** Suppress findings below 0.60 confidence. Exception: P0 findings at 0.50+ confidence survive the gate -- critical-but-uncertain issues must not be silently dropped. Record the suppressed count. This matches the persona instructions and the schema's confidence thresholds.
-3. **Deduplicate.** Compute fingerprint: `normalize(file) + line_bucket(line, +/-3) + normalize(title)`. When fingerprints match, merge: keep highest severity, keep highest confidence, note which reviewers flagged it.
-4. **Cross-reviewer agreement.** When 2+ independent reviewers flag the same issue (same fingerprint), boost the merged confidence by 0.10 (capped at 1.0). Cross-reviewer agreement is strong signal -- independent reviewers converging on the same issue is more reliable than any single reviewer's confidence. Note the agreement in the Reviewer column of the output (e.g., "security, correctness").
+Convert multiple reviewer JSON returns into one deduplicated, confidence-gated finding set. Each persona return already contains both tiers. The parent must retain the validated payload in memory for merge and synthesis, then persist only the same validated data.
+
+Before applying the confidence gate, assign every finding in a valid return a stable parent-owned `input_id` of `<reviewer>#<1-based finding index>`. Keep an input ledger through every later stage. The ledger is the authoritative reconciliation record in the synthesis artifact; it is not part of the persona's returned payload. If a return is rejected but its parsed `findings` array can be safely enumerated, assign IDs and record every enumerated input as `rejected`. If the return is malformed JSON or has no safely enumerable findings, record no synthetic input findings; the persona-level dispatch record and its exact safe rejection reason still record the rejection.
+
+1. **Validate before any write.** Treat every persona return as untrusted input. Parse the returned text as JSON without logging the raw text, then validate the complete parsed object against `references/findings-schema.json`, including `why_it_matters` and `evidence`.
+   - **Top-level required:** reviewer (string), findings (array), residual_risks (array), testing_gaps (array). Reject the entire persona return if any are missing or wrong type.
+   - **Per-finding required:** title, severity, file, line, why_it_matters, confidence, evidence, autofix_class, owner, requires_verification, pre_existing.
+   - **Schema constraints:** enforce every enum, type, confidence, line, path, evidence count, evidence length, and explicit overflow-marker bound from the schema. Empty evidence, absolute paths, and over-bound evidence are rejection cases, not truncation cases.
+   - **Environment-value detection:** JSON Schema cannot determine where a string came from, so recursively inspect every string leaf in the parsed payload before writing. Reject the payload when a string contains a shell/environment reference (`$NAME`, `${NAME}`, `process.env.NAME`, or `os.environ[...]`), an assignment using a known environment variable (`NAME=value`), or a current environment value as an exact or embedded match. Use a conservative match set of non-empty runtime environment values; never log the matched value. This detector is an additional parent-side check, not a schema claim.
+   - **Safe rejection message:** report only `Rejected persona <name> return: field <JSON path> failed <reason>.` Derive `<JSON path>` from the validator or recursive scan and use a fixed reason such as `schema validation`, `environment-value detection`, or `malformed JSON`; never include the offending value, raw return, or validator parameters.
+   - **No partial writes:** do not write a per-agent record or merge any finding until the entire persona payload passes schema and environment-value validation. A valid payload is then annotated by the parent with `harness` and `dispatch_outcome` and written by the parent only. Revalidate the enriched record before persistence.
+   - **Dispatch outcome:** a valid non-empty return is `findings`; a valid empty return is `empty`; invalid JSON or a rejected schema/environment payload is `malformed`; timeout or no return is `never_returned`. Keep these outcomes separate from finding `disposition`.
+   - **Rejection policy: degrade, do not fail the whole review.** Continue merging conforming returns, record the rejected persona's `dispatch_outcome` and safe rejection reason in the synthesis artifact, and give any rejected input the `rejected` disposition in the later reconciliation. If every persona fails or times out, use the existing degraded-review behavior. This preserves partial review coverage without ever persisting a non-conforming artifact; only an orchestration/storage failure that prevents the parent from producing its required run artifact is run-fatal.
+2. **Confidence gate.** Suppress findings below 0.60 confidence. Exception: P0 findings at 0.50+ confidence survive the gate -- critical-but-uncertain issues must not be silently dropped. Record the suppressed finding's original confidence and an explicit reason in the input ledger. A retained P0 at 0.50+ is recorded as `surviving` unless it later participates in a deduplication merge. This matches the persona instructions and the schema's confidence thresholds.
+3. **Deduplicate.** Compute fingerprint: `normalize(file) + line_bucket(line, +/-3) + normalize(title)`. When fingerprints match, merge: keep highest severity, keep highest confidence, preserve the exact fingerprint, and retain the input IDs that produced the merged entry. A singleton that passes the gate is `surviving`; each input in a multi-input merge is provisionally `merged`.
+4. **Cross-reviewer agreement.** When 2+ independent reviewers flag the same issue (same fingerprint), boost the merged confidence by 0.10 (capped at 1.0). Cross-reviewer agreement is strong signal -- independent reviewers converging on the same issue is more reliable than any single reviewer's confidence. Preserve the distinction in the merged finding's artifact provenance: `submitters` contains only personas with an input finding in that fingerprint group; `agreement_credit` contains only personas credited by the agreement boost without an input finding in that group. A persona with zero findings never appears in `submitters`. Do not infer submission from the report's Reviewer column.
 5. **Separate pre-existing.** Pull out findings with `pre_existing: true` into a separate list.
 6. **Resolve disagreements.** When reviewers flag the same code region but disagree on severity, autofix_class, or owner, annotate the Reviewer column with the disagreement (e.g., "security (P0), correctness (P1) -- kept P0"). This transparency helps the user understand why a finding was routed the way it was.
 7. **Normalize routing.** For each merged finding, set the final `autofix_class`, `owner`, and `requires_verification`. If reviewers disagree, keep the most conservative route. Synthesis may narrow a finding from `safe_auto` to `gated_auto` or `manual`, but must not widen it without new evidence.
@@ -470,10 +478,11 @@ Convert multiple reviewer compact JSON returns into one deduplicated, confidence
 9. **Sort.** Order by severity (P0 first) -> confidence (descending) -> file path -> line number.
 10. **Collect coverage data.** Union residual_risks and testing_gaps across reviewers.
 11. **Preserve CE agent artifacts.** Keep the learnings, agent-native, schema-drift, and deployment-verification outputs alongside the merged finding set. Do not drop unstructured agent output just because it does not match the persona JSON schema.
+12. **Keep the input ledger complete.** Every enumerated input finding has exactly one final disposition: `surviving`, `merged`, `suppressed`, `filtered`, or `rejected`, plus a reason. The ledger's disposition counts must sum to its input count. A rejected payload's reason is the exact safe rejection message produced by validation, not a bucket such as "invalid"; never include the offending value.
 
 ### Stage 5b: Validation pass
 
-Run an independent validation pass over the merged finding set before synthesis. This pass annotates each gated finding `validated: true` or `validated: false` with a one-sentence reason. It never deletes a finding — findings with `validated: false` are surfaced in the "Filtered (not validated)" group in Stage 6, not removed from the report.
+Run an independent validation pass over the merged finding set before synthesis. This pass annotates each gated finding `validated: true` or `validated: false` with a one-sentence reason. A `validated: false` finding is dropped from the surviving/actioned set and receives disposition `filtered`, but is retained in the synthesis artifact and surfaced in the "Filtered (not validated)" group in Stage 6. It is not erased from the record.
 
 **Gating band (default):** Validate only findings that are **P0 or P1 severity**, or that have `requires_verification: true`. Findings outside this band pass through to Stage 6 unvalidated and unfiltered — no validator is dispatched for them. This bounds cost: one validator subagent per gated finding.
 
@@ -482,9 +491,9 @@ Run an independent validation pass over the merged finding set before synthesis.
 1. Identify all gated findings from the Stage 5 merged set.
 2. For each gated finding, spawn one validator subagent in parallel using the validator template at `references/validator-template.md`. Pass the finding fields, the intent summary, the file list, and the full diff.
 3. Collect `{validated, reason}` from each validator. Attach both fields to the finding.
-4. **Never drop a finding.** A finding with `validated: false` is routed to the "Filtered (not validated)" group for Stage 6 presentation. It is not removed from the report, not suppressed, and not excluded from the Coverage count.
-5. Findings with `validated: true` flow through to Stage 6 unchanged — they appear in the normal severity tables.
-6. Findings outside the gating band carry no `validated` annotation and appear in Stage 6 severity tables unchanged.
+4. **Reconcile filtered inputs.** A finding with `validated: false` moves to the "Filtered (not validated)" presentation group in Stage 6, and every input ID contributing to that merged finding is updated to disposition `filtered` with the validator's exact one-sentence reason. It is not `suppressed`, `rejected`, or silently excluded from the input ledger.
+5. Findings with `validated: true` flow through to Stage 6 unchanged — they appear in the normal severity tables. Their input ledger dispositions remain `surviving` for singleton findings or `merged` for deduplicated groups.
+6. Findings outside the gating band carry no `validated` annotation and appear in Stage 6 severity tables unchanged; their input ledger dispositions remain `surviving` or `merged`.
 
 **Failure handling:** If a validator subagent fails or times out, treat the finding as `validated: true` (conservative fallback — keep it in the actioned set) and note the validator failure in the Coverage section.
 
@@ -494,7 +503,7 @@ Run an independent validation pass over the merged finding set before synthesis.
 
 Assemble the final report using **pipe-delimited markdown tables for findings** from the review output template included below. The table format is mandatory for finding rows in interactive mode — do not render findings as freeform text blocks or horizontal-rule-separated prose. Other report sections (Applied Fixes, Learnings, Coverage, etc.) use bullet lists and the `---` separator before the verdict, as shown in the template.
 
-1. **Header.** Scope, intent, mode, reviewer team with per-conditional justifications.
+1. **Header.** Scope, intent, mode, harness, reviewer team with per-conditional justifications.
 2. **Findings.** Rendered as pipe-delimited tables grouped by severity (`### P0 -- Critical`, `### P1 -- High`, `### P2 -- Moderate`, `### P3 -- Low`). Each finding row shows `#`, file, issue, reviewer(s), confidence, and synthesized route. Omit empty severity levels. Never render findings as freeform text blocks or numbered lists. Only findings with `validated: true` (or no `validated` annotation) appear in these tables.
 3. **Requirements Completeness.** Include only when a plan was found in Stage 2b. For each requirement (R1, R2, etc.) and implementation unit in the plan, report whether corresponding work appears in the diff. Use a simple checklist: met / not addressed / partially addressed. Routing depends on `plan_source`:
    - **`explicit`** (caller-provided or PR body): Flag unaddressed requirements as P1 findings with `autofix_class: manual`, `owner: downstream-resolver`. These enter the residual actionable queue and can become todos.
@@ -525,7 +534,7 @@ Scope: <scope-line>
 Intent: <intent-summary>
 Reviewers: <reviewer-list with conditional justifications>
 Verdict: <Ready to merge | Ready with fixes | Not ready>
-Artifact: .context/systematic/ce-review/<run-id>/
+Artifact: .context/systematic/ce-review/<run-id>/review-summary.json
 
 Applied N safe_auto fixes.
 
@@ -583,15 +592,15 @@ Coverage:
 Review complete
 ```
 
-**Detail enrichment (headless only):** The headless envelope includes `Why:`, `Evidence:`, and `Suggested fix:` lines. After merge (Stage 5), read the per-agent artifact files from `.context/systematic/ce-review/{run_id}/` for only the findings that survived dedup and confidence gating.
-   - **Field tiers:** `Why:` and `Evidence:` are detail-tier -- load from per-agent artifact files. `Suggested fix:` is merge-tier -- use it directly from the compact return without artifact lookup.
-   - **Artifact matching:** For each surviving finding, look up its detail-tier fields in the artifact files of the contributing reviewers. Match on `file + line_bucket(line, +/-3)` (the same tolerance used in Stage 5 dedup) within each contributing reviewer's artifact. When multiple artifact entries fall within the line bucket, apply `normalize(title)` to both the merged finding's title and each candidate entry's title as a tie-breaker.
-   - **Reviewer order:** Try contributing reviewers in the order they appear in the merged finding's reviewer list; use the first match.
-   - **No-match fallback:** If no artifact file contains a match (all writes failed, or the finding was synthesized during merge), omit the `Why:` and `Evidence:` lines for that finding and note the gap in Coverage. The `Suggested fix:` line can still be populated from the compact return since it is merge-tier.
+**Detail enrichment (headless only):** The headless envelope includes `Why:`, `Evidence:`, and `Suggested fix:` lines. After merge (Stage 5), use the validated full persona returns retained in parent memory for only the findings that survived dedup and confidence gating.
+   - **Field tiers:** `Why:` and `Evidence:` are detail-tier and are already present in the validated inline return. `Suggested fix:` is also available directly from that return and survives merge as optional fix context.
+   - **In-memory matching:** For each surviving finding, look up its detail-tier fields in the validated returns of the contributing reviewers. Match on `file + line_bucket(line, +/-3)` (the same tolerance used in Stage 5 dedup). When multiple entries fall within the line bucket, apply `normalize(title)` to the merged finding's title and each candidate entry's title as a tie-breaker.
+   - **Reviewer order:** Try contributing reviewers in the order they appear in the merged finding's reviewer list; use the first validated match.
+   - **No-match fallback:** If no validated in-memory return contains a match, omit the `Why:` and `Evidence:` lines for that finding and note the gap in Coverage. This should indicate a synthesis/matching gap, not a failed artifact-file write. Never re-read per-agent files to recover detail.
 
 **Formatting rules:**
 - The `[needs-verification]` marker appears only on findings where `requires_verification: true`.
-- The `Artifact:` line gives callers the path to the full run artifact for machine-readable access to the complete findings schema. The text envelope is the primary handoff; the artifact is for debugging and full-fidelity access.
+- The `Artifact:` line gives callers the path to the parent-written `review-summary.json` for machine-readable access to the complete findings schema, provenance, dispatch outcomes, and disposition ledger. The text envelope is the primary handoff; the artifact is for debugging and full-fidelity access.
 - Findings with `owner: release` appear in the Advisory section (they are operational/rollout items, not code fixes).
 - Findings with `pre_existing: true` appear in the Pre-existing section regardless of autofix_class.
 - Findings with `validated: false` from Stage 5b appear in the "Filtered (not validated)" section. They are surfaced for human review — not removed. Include the validator reason on the indented `Validator reason:` line.
@@ -691,18 +700,22 @@ After presenting findings and verdict (Stage 6), route the next steps by mode. R
 
 #### Step 4: Emit artifacts and downstream handoff
 
-- In interactive, autofix, and headless modes, write a per-run artifact under `.context/systematic/ce-review/<run-id>/` containing:
-  - synthesized findings (merged output from Stage 5)
-  - applied fixes
-  - residual actionable work
-  - advisory-only outputs
-  Per-agent full-detail JSON files (`{reviewer_name}.json`) are already present in this directory from Stage 4 dispatch.
+- In interactive, autofix, and headless modes, write **`review-summary.json` unconditionally** under `.context/systematic/ce-review/<run-id>/`, including when every persona returns `empty` and there are zero surviving findings. `mode:report-only` remains exempt: it skips run-id and directory creation and writes nothing.
+- `review-summary.json` is the parent-owned synthesis artifact and must contain, at minimum:
+  - `run_id`, `mode`, `harness` (`opencode`, `pi`, or `claude-code`), and run lifecycle fields;
+  - a `dispatches` entry for every selected persona with `persona`, `dispatch_outcome` (`findings`, `empty`, `malformed`, or `never_returned`), the number of safely enumerated input findings, and the exact safe `rejection_reason` when applicable;
+  - an `input_findings` ledger with one entry per safely enumerated input, its `input_id`, reviewer, original confidence, final `disposition` (`surviving`, `merged`, `suppressed`, `filtered`, or `rejected`), and a stated reason. Its count must reconcile exactly with the sum of disposition counts. A malformed JSON return with no safely enumerable finding has zero ledger entries, not a fabricated finding;
+  - surviving synthesized findings and filtered findings, each retaining their original fields plus `input_finding_ids` and provenance. Every synthesized finding's provenance must include the exact dedup `fingerprint`, `submitters`, and `agreement_credit` arrays. `submitters` means independent input submissions; `agreement_credit` means agreement boost credit without a corresponding input submission;
+  - applied fixes, residual actionable work, advisory-only outputs, coverage data, and the harness value.
+- During the pre-dispatch setup described in Stage 4, initialize the synthesis artifact with lifecycle state `in_progress` and all selected personas initialized as `never_returned`. Update each dispatch entry as returns arrive. Finalize it as `completed` or `degraded` after synthesis; if the parent catches an abort or storage/orchestration failure, finalize it as `abnormal` with the stated termination reason. If the process dies before finalization, the pre-written `in_progress` artifact is itself an explicit incomplete run and must be counted as abnormal rather than treated as a missing or clean run. Never infer a clean run from an absent artifact.
+- Per-agent full-detail JSON files (`{reviewer_name}.json`) are written by the parent only after the persona return passes full-schema and environment-value validation. Rejected or never-returned personas do not produce a per-agent file; their dispatch outcome remains in the synthesis artifact. If a later confidence or validation stage changes an input disposition, update the parent-owned record and synthesis ledger before finalizing `review-summary.json`.
 - Also write `metadata.json` alongside the findings so downstream skills can verify the artifact matches the current branch and HEAD. Minimum fields:
   ```json
   {
     "run_id": "<run-id>",
     "branch": "<git branch --show-current at dispatch time>",
     "head_sha": "<git rev-parse HEAD at dispatch time>",
+    "harness": "<opencode | pi | claude-code>",
     "verdict": "<Ready to merge | Ready with fixes | Not ready>",
     "completed_at": "<ISO 8601 UTC timestamp>"
   }

package/skills/ce-review/references/findings-schema.json

@@ -1,134 +1,338 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
   "title": "Code Review Findings",
-  "description": "Structured output schema for code review sub-agents",
-  "type": "object",
-  "required": ["reviewer", "findings", "residual_risks", "testing_gaps"],
-  "properties": {
-    "reviewer": {
+  "description": "Structured output schemas for code review sub-agent returns and parent-persisted records",
+  "$ref": "#/definitions/parentRecord",
+  "definitions": {
+    "dispatchOutcome": {
       "type": "string",
-      "description": "Persona name that produced this output (e.g., 'correctness', 'security')"
+      "enum": ["findings", "empty", "malformed", "never_returned"],
+      "description": "What a persona returned: findings, empty, malformed, or never returned"
     },
-    "findings": {
-      "type": "array",
-      "description": "List of code review findings. Empty array if no issues found.",
-      "items": {
-        "type": "object",
-        "required": [
-          "title",
-          "severity",
-          "file",
-          "line",
-          "why_it_matters",
-          "autofix_class",
-          "owner",
-          "requires_verification",
-          "confidence",
-          "evidence",
-          "pre_existing"
-        ],
-        "properties": {
-          "title": {
-            "type": "string",
-            "description": "Short, specific issue title. 10 words or fewer.",
-            "maxLength": 100
-          },
-          "severity": {
-            "type": "string",
-            "enum": ["P0", "P1", "P2", "P3"],
-            "description": "Issue severity level"
-          },
-          "file": {
-            "type": "string",
-            "description": "Relative file path from repository root"
-          },
-          "line": {
-            "type": "integer",
-            "description": "Primary line number of the issue",
-            "minimum": 1
-          },
-          "why_it_matters": {
-            "type": "string",
-            "description": "Impact and failure mode -- not 'what is wrong' but 'what breaks'"
-          },
-          "autofix_class": {
+    "disposition": {
+      "type": "string",
+      "enum": ["surviving", "merged", "suppressed", "filtered", "rejected"],
+      "description": "What happened to an input finding: surviving, merged, suppressed, filtered, or rejected"
+    },
+    "harness": {
+      "type": "string",
+      "enum": ["opencode", "pi", "claude-code"],
+      "description": "Harness that produced the artifact; populated by the parent orchestrator"
+    },
+    "repoRelativePath": {
+      "type": "string",
+      "minLength": 1,
+      "maxLength": 256,
+      "pattern": "^(?!/)(?![A-Za-z]:[\\\\/])(?!\\\\).+",
+      "description": "Relative file path from repository root; absolute POSIX, drive-letter, and UNC paths are rejected"
+    },
+    "boundedEvidenceString": {
+      "type": "string",
+      "minLength": 1,
+      "maxLength": 500,
+      "pattern": "^(?!/)(?![A-Za-z]:[\\\\/])(?!\\\\).+",
+      "description": "Bounded code-grounded evidence; absolute POSIX, drive-letter, and UNC paths are rejected"
+    },
+    "overflowExcerpt": {
+      "type": "string",
+      "minLength": 1,
+      "maxLength": 500,
+      "pattern": "^(?!/)(?![A-Za-z]:[\\\\/])(?!\\\\).+",
+      "description": "Bounded excerpt retained when evidence must be shortened"
+    },
+    "overflowEvidence": {
+      "type": "object",
+      "required": ["overflow", "excerpt"],
+      "properties": {
+        "overflow": {
+          "const": true,
+          "description": "Explicit marker that the complete evidence did not fit in one bounded entry"
+        },
+        "excerpt": {
+          "$ref": "#/definitions/overflowExcerpt"
+        }
+      },
+      "additionalProperties": false
+    },
+    "findingProperties": {
+      "type": "object",
+      "properties": {
+        "title": {
+          "type": "string",
+          "minLength": 1,
+          "maxLength": 256,
+          "pattern": "\\S",
+          "description": "Short, specific issue title. 10 words or fewer."
+        },
+        "severity": {
+          "type": "string",
+          "enum": ["P0", "P1", "P2", "P3"],
+          "description": "Issue severity level"
+        },
+        "file": {
+          "$ref": "#/definitions/repoRelativePath"
+        },
+        "line": {
+          "type": "integer",
+          "minimum": 1,
+          "description": "Primary line number of the issue"
+        },
+        "why_it_matters": {
+          "type": "string",
+          "minLength": 1,
+          "maxLength": 2048,
+          "pattern": "\\S",
+          "description": "Non-empty impact and failure mode -- not 'what is wrong' but 'what breaks'"
+        },
+        "autofix_class": {
+          "type": "string",
+          "enum": ["safe_auto", "gated_auto", "manual", "advisory"],
+          "description": "Reviewer's conservative recommendation for how this issue should be handled after synthesis"
+        },
+        "owner": {
+          "type": "string",
+          "enum": ["review-fixer", "downstream-resolver", "human", "release"],
+          "description": "Who should own the next action for this finding after synthesis"
+        },
+        "requires_verification": {
+          "type": "boolean",
+          "description": "Whether any fix for this finding must be re-verified with targeted tests or a follow-up review pass"
+        },
+        "suggested_fix": {
+          "type": ["string", "null"],
+          "maxLength": 2048,
+          "description": "Concrete minimal fix. Omit or null if no good fix is obvious -- a bad suggestion is worse than none."
+        },
+        "confidence": {
+          "type": "number",
+          "minimum": 0.0,
+          "maximum": 1.0,
+          "description": "Reviewer confidence in this finding, calibrated per persona"
+        },
+        "evidence": {
+          "type": "array",
+          "minItems": 1,
+          "maxItems": 5,
+          "description": "Code-grounded evidence. At least 1 and at most 5 bounded entries; split evidence across entries or use an explicit overflow marker rather than silently truncating it.",
+          "items": {
+            "oneOf": [
+              {
+                "$ref": "#/definitions/boundedEvidenceString"
+              },
+              {
+                "$ref": "#/definitions/overflowEvidence"
+              }
+            ]
+          }
+        },
+        "disposition": {
+          "$ref": "#/definitions/disposition"
+        },
+        "pre_existing": {
+          "type": "boolean",
+          "description": "True if this issue exists in unchanged code unrelated to the current diff"
+        }
+      }
+    },
+    "artifactProperties": {
+      "type": "object",
+      "properties": {
+        "reviewer": {
+          "type": "string",
+          "minLength": 1,
+          "maxLength": 64,
+          "pattern": "\\S",
+          "description": "Persona name that produced this output (e.g., 'correctness', 'security')"
+        },
+        "harness": {
+          "$ref": "#/definitions/harness"
+        },
+        "dispatch_outcome": {
+          "$ref": "#/definitions/dispatchOutcome"
+        },
+        "findings": {
+          "type": "array",
+          "maxItems": 32,
+          "description": "List of code review findings. Empty array if no issues found."
+        },
+        "residual_risks": {
+          "type": "array",
+          "maxItems": 64,
+          "description": "Risks the reviewer noticed but could not confirm as findings",
+          "items": {
             "type": "string",
-            "enum": ["safe_auto", "gated_auto", "manual", "advisory"],
-            "description": "Reviewer's conservative recommendation for how this issue should be handled after synthesis"
-          },
-          "owner": {
+            "maxLength": 1024
+          }
+        },
+        "testing_gaps": {
+          "type": "array",
+          "maxItems": 64,
+          "description": "Missing test coverage the reviewer identified",
+          "items": {
             "type": "string",
-            "enum": ["review-fixer", "downstream-resolver", "human", "release"],
-            "description": "Who should own the next action for this finding after synthesis"
-          },
-          "requires_verification": {
-            "type": "boolean",
-            "description": "Whether any fix for this finding must be re-verified with targeted tests or a follow-up review pass"
-          },
-          "suggested_fix": {
-            "type": ["string", "null"],
-            "description": "Concrete minimal fix. Omit or null if no good fix is obvious -- a bad suggestion is worse than none."
-          },
-          "confidence": {
-            "type": "number",
-            "description": "Reviewer confidence in this finding, calibrated per persona",
-            "minimum": 0.0,
-            "maximum": 1.0
-          },
-          "evidence": {
-            "type": "array",
-            "description": "Code-grounded evidence: snippets, line references, or pattern descriptions. At least 1 item.",
-            "items": { "type": "string" },
-            "minItems": 1
-          },
-          "pre_existing": {
-            "type": "boolean",
-            "description": "True if this issue exists in unchanged code unrelated to the current diff"
+            "maxLength": 1024
           }
         }
       }
     },
-    "residual_risks": {
-      "type": "array",
-      "description": "Risks the reviewer noticed but could not confirm as findings",
-      "items": { "type": "string" }
-    },
-    "testing_gaps": {
-      "type": "array",
-      "description": "Missing test coverage the reviewer identified",
-      "items": { "type": "string" }
-    }
-  },
-
-  "_meta": {
-    "confidence_thresholds": {
-      "suppress": "Below 0.60 -- do not report. Finding is speculative noise. Exception: P0 findings at 0.50+ may be reported.",
-      "flag": "0.60-0.69 -- include only when the issue is clearly actionable with concrete evidence.",
-      "confident": "0.70-0.84 -- real and important. Report with full evidence.",
-      "certain": "0.85-1.00 -- verifiable from the code alone. Report."
-    },
-    "severity_definitions": {
-      "P0": "Critical breakage, exploitable vulnerability, data loss/corruption. Must fix before merge.",
-      "P1": "High-impact defect likely hit in normal usage, breaking contract. Should fix.",
-      "P2": "Moderate issue with meaningful downside (edge case, perf regression, maintainability trap). Fix if straightforward.",
-      "P3": "Low-impact, narrow scope, minor improvement. User's discretion."
+    "subAgentFinding": {
+      "type": "object",
+      "required": [
+        "title",
+        "severity",
+        "file",
+        "line",
+        "why_it_matters",
+        "autofix_class",
+        "owner",
+        "requires_verification",
+        "confidence",
+        "evidence",
+        "pre_existing"
+      ],
+      "properties": {
+        "title": { "$ref": "#/definitions/findingProperties/properties/title" },
+        "severity": {
+          "$ref": "#/definitions/findingProperties/properties/severity"
+        },
+        "file": { "$ref": "#/definitions/findingProperties/properties/file" },
+        "line": { "$ref": "#/definitions/findingProperties/properties/line" },
+        "why_it_matters": {
+          "$ref": "#/definitions/findingProperties/properties/why_it_matters"
+        },
+        "autofix_class": {
+          "$ref": "#/definitions/findingProperties/properties/autofix_class"
+        },
+        "owner": { "$ref": "#/definitions/findingProperties/properties/owner" },
+        "requires_verification": {
+          "$ref": "#/definitions/findingProperties/properties/requires_verification"
+        },
+        "suggested_fix": {
+          "$ref": "#/definitions/findingProperties/properties/suggested_fix"
+        },
+        "confidence": {
+          "$ref": "#/definitions/findingProperties/properties/confidence"
+        },
+        "evidence": {
+          "$ref": "#/definitions/findingProperties/properties/evidence"
+        },
+        "pre_existing": {
+          "$ref": "#/definitions/findingProperties/properties/pre_existing"
+        }
+      },
+      "additionalProperties": false
     },
-    "autofix_classes": {
-      "safe_auto": "Local, deterministic code or test fix suitable for the in-skill fixer. Examples: extract duplicated helper, add missing nil check, fix off-by-one, add missing test, remove dead code. Do not default to advisory when a concrete safe fix exists.",
-      "gated_auto": "Concrete fix exists, but it changes behavior, permissions, contracts, or other sensitive areas that deserve explicit approval. Examples: add auth to unprotected endpoint, change API response shape.",
-      "manual": "Actionable issue that requires design decisions or cross-cutting changes. Examples: redesign data model, add pagination strategy, choose between architectural approaches.",
-      "advisory": "Informational or operational item that should be surfaced in the report only. Examples: design asymmetry the PR improves but does not fully resolve, residual risk notes, deployment considerations."
+    "parentFinding": {
+      "type": "object",
+      "required": [
+        "title",
+        "severity",
+        "file",
+        "line",
+        "why_it_matters",
+        "autofix_class",
+        "owner",
+        "requires_verification",
+        "confidence",
+        "evidence",
+        "disposition",
+        "pre_existing"
+      ],
+      "properties": {
+        "title": { "$ref": "#/definitions/findingProperties/properties/title" },
+        "severity": {
+          "$ref": "#/definitions/findingProperties/properties/severity"
+        },
+        "file": { "$ref": "#/definitions/findingProperties/properties/file" },
+        "line": { "$ref": "#/definitions/findingProperties/properties/line" },
+        "why_it_matters": {
+          "$ref": "#/definitions/findingProperties/properties/why_it_matters"
+        },
+        "autofix_class": {
+          "$ref": "#/definitions/findingProperties/properties/autofix_class"
+        },
+        "owner": { "$ref": "#/definitions/findingProperties/properties/owner" },
+        "requires_verification": {
+          "$ref": "#/definitions/findingProperties/properties/requires_verification"
+        },
+        "suggested_fix": {
+          "$ref": "#/definitions/findingProperties/properties/suggested_fix"
+        },
+        "confidence": {
+          "$ref": "#/definitions/findingProperties/properties/confidence"
+        },
+        "evidence": {
+          "$ref": "#/definitions/findingProperties/properties/evidence"
+        },
+        "disposition": {
+          "$ref": "#/definitions/findingProperties/properties/disposition"
+        },
+        "pre_existing": {
+          "$ref": "#/definitions/findingProperties/properties/pre_existing"
+        }
+      },
+      "additionalProperties": false
     },
-    "owners": {
-      "review-fixer": "The in-skill fixer can own this when policy allows.",
-      "downstream-resolver": "Turn this into residual work for later resolution.",
-      "human": "A person must make a judgment call before code changes should continue.",
-      "release": "Operational or rollout follow-up; do not convert into code-fix work automatically."
+    "subAgentReturn": {
+      "type": "object",
+      "required": ["reviewer", "findings", "residual_risks", "testing_gaps"],
+      "properties": {
+        "reviewer": {
+          "$ref": "#/definitions/artifactProperties/properties/reviewer"
+        },
+        "findings": {
+          "allOf": [
+            { "$ref": "#/definitions/artifactProperties/properties/findings" },
+            {
+              "items": { "$ref": "#/definitions/subAgentFinding" }
+            }
+          ]
+        },
+        "residual_risks": {
+          "$ref": "#/definitions/artifactProperties/properties/residual_risks"
+        },
+        "testing_gaps": {
+          "$ref": "#/definitions/artifactProperties/properties/testing_gaps"
+        }
+      },
+      "additionalProperties": false
     },
-    "return_tiers": {
-      "description": "Finding fields are split into two tiers. The full schema (with all required fields) applies to the artifact file on disk. The compact return to the orchestrator omits detail-tier fields. Both are valid uses of this schema in different contexts.",
-      "merge_tier": "Returned to orchestrator: title, severity, file, line, confidence, autofix_class, owner, requires_verification, pre_existing, suggested_fix (optional). Plus top-level reviewer, residual_risks, testing_gaps.",
-      "detail_tier": "Required in artifact file, omitted from compact return: why_it_matters, evidence. The artifact file must pass full schema validation including all required fields. Headless output depends on why_it_matters and evidence being present in the artifact."
+    "parentRecord": {
+      "type": "object",
+      "required": [
+        "reviewer",
+        "harness",
+        "dispatch_outcome",
+        "findings",
+        "residual_risks",
+        "testing_gaps"
+      ],
+      "properties": {
+        "reviewer": {
+          "$ref": "#/definitions/artifactProperties/properties/reviewer"
+        },
+        "harness": {
+          "$ref": "#/definitions/artifactProperties/properties/harness"
+        },
+        "dispatch_outcome": {
+          "$ref": "#/definitions/artifactProperties/properties/dispatch_outcome"
+        },
+        "findings": {
+          "allOf": [
+            { "$ref": "#/definitions/artifactProperties/properties/findings" },
+            {
+              "items": { "$ref": "#/definitions/parentFinding" }
+            }
+          ]
+        },
+        "residual_risks": {
+          "$ref": "#/definitions/artifactProperties/properties/residual_risks"
+        },
+        "testing_gaps": {
+          "$ref": "#/definitions/artifactProperties/properties/testing_gaps"
+        }
+      },
+      "additionalProperties": false
     }
   }
 }

package/skills/ce-review/references/persona-catalog.md

@@ -2,6 +2,14 @@
 
 13 reviewer personas organized into always-on, cross-cutting conditional, and stack-specific conditional layers, plus CE-specific agents. The orchestrator uses this catalog to select which reviewers to spawn for each review.
 
+## Shared persona pool
+
+The `agents/review/` directory is a shared persona pool, not `ce:review`'s roster. Directory placement does not imply that a persona is selectable by `ce:review`. These shared personas are dispatched by other workflows and intentionally do not appear in this catalog's `ce:review` selection tables:
+
+- `systematic:review:architecture-strategist` — dispatched by `deepen-plan` and `ce-plan`'s deepening workflow for architectural analysis.
+- `systematic:review:pattern-recognition-specialist` — dispatched by `deepen-plan`, `ce-plan`'s deepening workflow, and `ce-compound` for consistency, duplication, and pattern analysis.
+- `systematic:review:code-simplicity-reviewer` — dispatched by `ce-compound` for code-heavy issues.
+
 ## Always-on (4 personas + 2 CE agents)
 
 Spawned on every review regardless of diff content.

package/skills/ce-review/references/review-output-template.md

@@ -14,6 +14,7 @@ Use this **exact format** when presenting synthesized review findings. Findings
 **Mode:** autofix
 
 **Reviewers:** correctness, testing, maintainability, security, api-contract
+- **Harness:** opencode
 - security -- new public endpoint accepts user-provided format parameter
 - api-contract -- new /api/orders/export route with response schema
 
@@ -124,7 +125,7 @@ This fails because: no pipe-delimited tables, no severity-grouped `###` headers,
 - **Pipe-delimited markdown tables** for findings -- never ASCII box-drawing characters or per-finding horizontal-rule separators between entries (the report-level `---` before the verdict is still required)
 - **Severity-grouped sections** -- `### P0 -- Critical`, `### P1 -- High`, `### P2 -- Moderate`, `### P3 -- Low`. Omit empty severity levels.
 - **Always include file:line location** for code review issues
-- **Reviewer column** shows which persona(s) flagged the issue. Multiple reviewers = cross-reviewer agreement.
+- **Reviewer column** shows which persona(s) submitted the issue. Multiple reviewers indicate independent submissions, not merely agreement credit. The machine-readable synthesis artifact keeps `submitters` separate from `agreement_credit`; do not infer submission from an agreement boost or from the display column alone.
 - **Confidence column** shows the finding's confidence score
 - **Route column** shows the synthesized handling decision as ``<autofix_class> -> <owner>``.
 - **Header includes** scope, intent, and reviewer team with per-conditional justifications
@@ -136,7 +137,7 @@ This fails because: no pipe-delimited tables, no severity-grouped `###` headers,
 - **Learnings & Past Solutions section** -- results from learnings-researcher, with links to docs/solutions/ files
 - **Agent-Native Gaps section** -- results from agent-native-reviewer. Omit if no gaps found.
 - **Deployment Notes section** -- key checklist items from deployment-verification-agent. Omit if the agent did not run.
-- **Coverage section** -- suppressed count, residual risks, testing gaps, failed reviewers
+- **Coverage section** -- suppressed count with original confidences, residual risks, testing gaps, failed reviewers, and disposition reconciliation
 - **Summary uses blockquotes** for verdict, reasoning, and fix order
 - **Horizontal rule** (`---`) separates findings from verdict
 - **`###` headers** for each section -- never plain text headers
@@ -148,8 +149,69 @@ In `mode:headless`, replace the interactive pipe-delimited table report with a s
 - **No pipe-delimited tables.** Findings use `[severity][autofix_class -> owner] File: <file:line> -- <title>` line format with indented Why/Evidence/Suggested fix lines.
 - **Findings grouped by autofix_class** (gated-auto, manual, advisory) instead of severity. Within each group, findings are sorted by severity.
 - **Verdict in header** (top of output) instead of bottom, so programmatic callers get it first.
-- **`Artifact:` line** in metadata header gives callers the path to the full run artifact.
+- **`Artifact:` line** in metadata header gives callers the path to `review-summary.json`, the full run artifact with provenance, dispatch outcomes, and disposition reconciliation.
 - **`[needs-verification]` marker** on findings where `requires_verification: true`.
 - **Evidence lines** included per finding.
 - **"Filtered (not validated)" section** included when Stage 5b produced findings with `validated: false`. Uses `[severity][autofix_class -> owner] File: <file:line> -- <title>` format with an indented `Validator reason:` line. These findings are surfaced for human review, not removed.
 - **Completion signal:** "Review complete" as the final line.
+
+## Synthesis Artifact Contract
+
+For interactive, autofix, and headless runs, the parent writes `.context/systematic/ce-review/<run-id>/review-summary.json` even when every selected persona returns `empty` and no finding survives. `mode:report-only` is the deliberate no-write exception.
+
+The artifact must preserve the following distinctions:
+
+```json
+{
+  "run_id": "<run-id>",
+  "mode": "<interactive | autofix | headless>",
+  "harness": "<opencode | pi | claude-code>",
+  "run_status": "<in_progress | completed | degraded | abnormal>",
+  "dispatches": [
+    {
+      "persona": "correctness",
+      "dispatch_outcome": "findings",
+      "input_finding_count": 2
+    },
+    {
+      "persona": "kieran-typescript",
+      "dispatch_outcome": "malformed",
+      "input_finding_count": 1,
+      "rejection_reason": "Rejected persona kieran-typescript return: field findings[0].evidence failed schema validation."
+    }
+  ],
+  "input_findings": [
+    {
+      "input_id": "correctness#1",
+      "reviewer": "correctness",
+      "confidence": 0.55,
+      "disposition": "suppressed",
+      "reason": "confidence 0.55 is below the 0.60 gate"
+    }
+  ],
+  "findings": [
+    {
+      "title": "<merged finding>",
+      "input_finding_ids": ["correctness#2", "testing#1"],
+      "provenance": {
+        "fingerprint": "<normalize(file) + line_bucket(line, +/-3) + normalize(title)>",
+        "submitters": ["correctness", "testing"],
+        "agreement_credit": []
+      }
+    }
+  ],
+  "disposition_counts": {
+    "surviving": 0,
+    "merged": 2,
+    "suppressed": 1,
+    "filtered": 0,
+    "rejected": 0
+  }
+}
+```
+
+- `dispatch_outcome` records what a persona returned: `findings`, `empty`, `malformed`, or `never_returned`. A rejection reason is preserved as the exact safe validation reason, naming persona and field without echoing the offending value.
+- `disposition` records what happened to each input finding: `surviving`, `merged`, `suppressed`, `filtered`, or `rejected`. Every safely enumerable input has exactly one disposition and stated reason; the disposition counts must equal the input-finding count.
+- `submitters` contains only personas with an input finding in the merged fingerprint group. `agreement_credit` contains only personas credited by the cross-reviewer agreement boost without an input finding in that group. A persona returning zero findings never appears in `submitters`.
+- `filtered` findings remain available for human review with the validator's stated reason, but are not part of the surviving/actioned set. A suppressed finding retains its original confidence, including the P0 exception for confidence `0.50` or higher.
+- The parent initializes the artifact as `in_progress` before dispatch. A completed run becomes `completed` or `degraded`; an interrupted or failed run is `abnormal` with its stated termination reason. An unfinished `in_progress` artifact is evidence of an abnormal run, not evidence of a clean run.

package/skills/ce-review/references/subagent-template.md

@@ -22,23 +22,11 @@ The supplied diff is the primary source of truth. Use the supplied paths and lin
 </bounded-investigation>
 
 <output-contract>
-You produce up to two outputs depending on whether a run ID was provided:
+Return exactly one JSON payload to the parent. The payload contains the complete schema for every finding, including both the merge tier and the detail tier (`why_it_matters`, `evidence`, and `suggested_fix` when present).
 
-1. **Artifact file (when run ID is present).** If a Run ID appears in <review-context> below, WRITE your full analysis (all schema fields, including why_it_matters, evidence, and suggested_fix) as JSON to:
-   .context/systematic/ce-review/{run_id}/{reviewer_name}.json
-   This is the ONE write operation you are permitted to make. Use the platform's file-write tool.
-   If the write fails, continue -- the compact return still provides everything the merge needs.
-   If no Run ID is provided (the field is empty or absent), skip this step entirely -- do not attempt any file write.
+Do not write any file. Do not use a Run ID or an artifact path. Persistence is owned by the parent orchestrator: it validates this returned payload, adds parent-owned provenance, and writes only conforming data. This rule is the same in every supported harness.
 
-2. **Compact return (always).** RETURN compact JSON to the parent with ONLY merge-tier fields per finding:
-   title, severity, file, line, confidence, autofix_class, owner, requires_verification, pre_existing, suggested_fix.
-   Do NOT include why_it_matters or evidence in the returned JSON.
-   Include reviewer, residual_risks, and testing_gaps at the top level.
-
-The full file preserves detail for downstream consumers (headless output, debugging).
-The compact return keeps the orchestrator's context lean for merge and synthesis.
-
-The schema below describes the **full artifact file format** (all fields required). For the compact return, follow the field list above -- omit why_it_matters and evidence even though the schema marks them as required.
+The schema below defines the payload's fields and bounds. Its transport is inline for this contract; any schema metadata describing a compact return or a separate detail artifact is superseded by this output contract.
 
 {schema}
 
@@ -62,9 +50,12 @@ False-positive categories to actively suppress:
 
 Rules:
 - You are a leaf reviewer inside an already-running systematic review workflow. Do not invoke systematic skills or agents unless this template explicitly instructs you to. Perform your analysis directly and return findings in the required output format only.
-- Every finding in the full artifact file MUST include at least one evidence item grounded in the actual code. The compact return omits evidence -- the evidence requirement applies to the disk artifact only.
+- Every returned finding MUST include at least one evidence item grounded in the actual code. Detail fields are part of the returned payload, not a second output.
+- Evidence is bounded to at most 5 entries of at most 500 characters each. Split a longer trail across entries when it fits; otherwise retain a bounded `excerpt` with `{ "overflow": true, "excerpt": "..." }`. Never silently truncate evidence.
+- Finding paths MUST be repository-relative. The schema rejects absolute paths, while the parent-side validator in Unit 3 detects environment values because JSON Schema cannot infer where a string came from.
+- The parent adds `harness`, `dispatch_outcome`, and `disposition` after validating the return. Do not invent those parent-owned fields. The parent uses only the canonical values defined by the schema (`findings`, `empty`, `malformed`, `never_returned` and `surviving`, `merged`, `suppressed`, `filtered`, `rejected`).
 - Set pre_existing to true ONLY for issues in unchanged code that are unrelated to this diff. If the diff makes the issue newly relevant, it is NOT pre-existing.
-- You are operationally read-only. The one permitted exception is writing your full analysis to the `.context/` artifact path when a run ID is provided. You may also use non-mutating inspection commands, including read-oriented `git` / `gh` commands, to gather evidence. Do not edit project files, change branches, commit, push, create PRs, or otherwise mutate the checkout or repository state.
+- You are operationally read-only. You may use non-mutating inspection commands, including read-oriented `git` / `gh` commands, to gather evidence. Do not write files, edit project files, change branches, commit, push, create PRs, or otherwise mutate the checkout or repository state.
 - Set `autofix_class` accurately -- not every finding is `advisory`. Use this decision guide:
   - `safe_auto`: The fix is local and deterministic — the fixer can apply it mechanically without design judgment. Examples: extracting a duplicated helper, adding a missing nil/null check, fixing an off-by-one, adding a missing test for an untested code path, removing dead code.
   - `gated_auto`: A concrete fix exists but it changes contracts, permissions, or crosses a module boundary in a way that deserves explicit approval. Examples: adding authentication to an unprotected endpoint, changing a public API response shape, switching from soft-delete to hard-delete.
@@ -83,7 +74,6 @@ Rules:
 </pr-context>
 
 <review-context>
-Run ID: {run_id}
 Reviewer name: {reviewer_name}
 
 Intent: {intent_summary}
@@ -106,5 +96,4 @@ Diff:
 | `{pr_metadata}` | Stage 1 output | PR title, body, and URL when reviewing a PR. Empty string when reviewing a branch or standalone checkout |
 | `{file_list}` | Stage 1 output | List of changed files from the scope step |
 | `{diff}` | Stage 1 output | The actual diff content to review |
-| `{run_id}` | Stage 4 output | Unique review run identifier for the artifact directory |
-| `{reviewer_name}` | Stage 3 output | Persona or agent name used as the artifact filename stem |
+| `{reviewer_name}` | Stage 3 output | Persona name used in the returned `reviewer` field |