@runfusion/fusion 0.73.0-beta.2 → 0.73.0-beta.4

package/dist/plugins/.fusion-ce-skills/ce-code-review/references/action-class-rubric.md

@@ -0,0 +1,26 @@
+# `autofix_class` rubric (personas)
+
+`autofix_class` describes the **intrinsic shape** of follow-up work — it is signal, **not an apply gate or permission**. In `mode:agent` the caller interprets findings and owns apply; in default (interactive) mode the review applies safe fixes itself by judgment (SKILL.md Stage 5c). Either way the class informs *what to do first* and *what to flag* — it does not mechanically decide what gets applied.
+
+| `autofix_class` | Meaning |
+|-----------------|---------|
+| `gated_auto` | A concrete change is proposed in `suggested_fix`. Callers may apply after their own judgment. |
+| `manual` | Actionable work that needs design input or a decision before code changes. Include `suggested_fix` when you can propose a defensible default. |
+| `advisory` | Report-only — learnings, residual risk, rollout notes. |
+
+## Persona guidance
+
+- Prefer `gated_auto` when you can write a defensible `suggested_fix` for a localized change.
+- Use `manual` when the right fix depends on product intent, architecture, or cross-cutting refactors.
+- Use `advisory` when nothing breaks if left unfixed but the observation has value.
+- Do **not** emit `safe_auto` — callers decide what to apply; reviewers classify and propose.
+
+## Owner field
+
+| `owner` | Meaning |
+|---------|---------|
+| `downstream-resolver` | Caller or human should act after review. |
+| `human` | Judgment required before implementation. |
+| `release` | Operational / rollout follow-up. |
+
+Do not use `review-fixer`.

package/dist/plugins/.fusion-ce-skills/ce-code-review/references/bulk-preview.md

@@ -0,0 +1,112 @@
+# Bulk Action Preview
+
+This reference defines the compact plan preview that Interactive mode shows before the file-tickets routing option (option C) executes. The preview gives the user a single-screen view of what the agent is about to do, with exactly two options to Proceed or Cancel.
+
+Interactive mode only. Option C only.
+
+The best-judgment path (routing option B and the walk-through's `Auto-resolve with best judgment on the rest`) does **not** use the bulk preview. The best-judgment path dispatches the fixer immediately and surfaces failures in a post-run question, per the `(B)` handler in `SKILL.md` Step 2 Interactive mode. Filing tickets is the one bulk action that benefits from a preview because filing produces durable external state that is expensive to undo — applying local fixes on uncommitted edits is not.
+
+---
+
+## When the preview fires
+
+One call site:
+
+- **Routing option C (top-level File tickets)** — after the user picks `File a [TRACKER] ticket per finding without applying fixes` but before any ticket is filed. Scope: every pending `gated_auto` / `manual` finding. Every finding appears under `Filing [TRACKER] tickets (N):` regardless of the agent's natural recommendation, because option C is batch-defer.
+
+The user confirms with `Proceed` or backs out with `Cancel`. No per-item decisions inside the preview — per-item decisioning is the walk-through's role (option A).
+
+---
+
+## Preview structure
+
+The preview is grouped by the action the agent intends to take. Bucket headers appear only when their bucket is non-empty.
+
+```
+<Path label> — <scope summary>[ (tracker: <name>)]:
+
+Applying (N):
+  [P0] <file>:<line> — <one-line plain-English summary>
+  [P1] <file>:<line> — <one-line plain-English summary>
+
+Filing [TRACKER] tickets (N):
+  [P2] <file>:<line> — <one-line plain-English summary>
+
+Skipping (N):
+  [P2] <file>:<line> — <one-line plain-English summary>
+
+Acknowledging (N):
+  [P3] <file>:<line> — <one-line plain-English summary>
+```
+
+Worked example, for routing option C (file tickets):
+
+```
+File plan — 8 findings as Linear tickets:
+
+Filing Linear tickets (8):
+  [P0] orders_controller.rb:42 — Missing ownership guard on order lookup
+  [P1] webhook_handler.rb:120 — Unhandled error swallowed in webhook
+  [P2] user_serializer.rb:14 — internal_id leaks in serialized response
+  [P2] billing_service.rb:230 — N+1 on refund batch
+  [P2] session_helper.rb:12 — Session reset behavior unclear
+  [P2] report_worker.rb:55 — Worker timeout under heavy load
+  [P3] string_utils.rb:8 — Ambiguous helper name
+  [P3] readme.md:14 — Documentation gap
+```
+
+---
+
+## Scope summary wording
+
+- **Routing option C (top-level File tickets):** header reads `File plan — N findings as [TRACKER] tickets:`. Every finding lands in the `Filing [TRACKER] tickets (N):` bucket. Option C is batch-defer — no Apply / Skip / Acknowledge buckets render in the preview, since every finding is being filed.
+
+When the detected tracker is low-confidence or generic (see `tracker-defer.md`), the `(tracker: <name>)` annotation is omitted from the header and the `Filing [TRACKER] tickets` bucket header uses the generic form (`Filing tickets (N):`).
+
+---
+
+## Per-finding line format
+
+Each line uses the compressed form of the framing-quality bar from the plan (R22-R25 — observable-behavior-first, no function / variable names unless needed to locate). The one-line summary is drawn from the persona-produced `why_it_matters` by taking the first sentence (and, when the first sentence is too long for the preview width, paraphrasing it tightly to fit).
+
+- **Shape:** `[<severity>] <file>:<line> — <one-line summary>`
+- **Width target:** keep lines near 80 columns so the preview renders cleanly in narrow terminals. Truncate with ellipsis when necessary.
+- **No function / variable names inline** unless the reader needs them to locate the issue.
+- **Advisory bucket phrasing:** the `Acknowledging (N):` bucket describes the advisory content in one line. No "fix" phrase — advisory findings have no concrete fix.
+
+When no `why_it_matters` is available for a finding (e.g., Unit 2's template upgrade hasn't fully propagated through the persona run, or the artifact file was unreadable), fall back to the finding's title directly. Note the gap in the completion report's Coverage section if it affects more than a few findings in the same run.
+
+---
+
+## Question and options
+
+After the preview body is rendered, ask the user using the platform's blocking question tool (`AskUserQuestion` in Claude Code, `request_user_input` in Codex, `ask_user` in Gemini, `ask_user` in Pi (requires the `pi-ask-user` extension)). In Claude Code, the tool should already be loaded from the Interactive-mode pre-load step — if it isn't, call `ToolSearch` with query `select:AskUserQuestion` now. The text fallback below applies only when the harness genuinely lacks a blocking tool — `ToolSearch` returns no match, the tool call explicitly fails, or the runtime mode does not expose it (e.g., Codex edit modes without `request_user_input`). A pending schema load is not a fallback trigger. Never silently skip the question.
+
+Stem: `The agent is about to file the tickets above. Proceed?`
+
+Options (exactly two):
+- `Proceed` — file every ticket in the preview
+- `Cancel` — do nothing, return to the routing question
+
+Only when `ToolSearch` explicitly returns no match or the tool call errors — or on a platform with no blocking question tool — fall back to presenting numbered options and waiting for the user's next reply.
+
+---
+
+## Cancel semantics
+
+`Cancel` returns the user to the routing question (the four-option menu in `SKILL.md` Step 2 Interactive mode). No tickets are filed; no state is recorded. The session's cached tracker-detection tuple is preserved.
+
+---
+
+## Proceed semantics
+
+When the user picks `Proceed`, every finding in the preview routes through `references/tracker-defer.md` for ticket creation. No fixes are applied. After all tickets have been filed (or failed), emit the unified completion report (see `references/walkthrough.md`).
+
+Failure during `Proceed` (e.g., ticket creation fails for one finding during a batch Defer) follows the failure path defined in `tracker-defer.md` — surface the failure inline with Retry / Fallback / Skip, continue with the rest of the plan, and capture the failure in the completion report's failure section.
+
+---
+
+## Edge cases
+
+- **N=1 preview (only one finding in scope):** the preview still renders with a single-line bucket. `Proceed` / `Cancel` still apply.
+- **No tracker available:** option C is not offered upstream (see `tracker-defer.md` no sink handling). The bulk preview is therefore never invoked when `any_sink_available` is false.

package/dist/plugins/.fusion-ce-skills/ce-code-review/references/cross-model-review.md

@@ -0,0 +1,63 @@
+# Cross-Model Adversarial Pass
+
+Runs the adversarial review through a **different model family than the host**, in a separate read-only process, so its findings are independent of the in-process reviewers. The peer gets the **same** `references/personas/adversarial-reviewer.md` brief the in-process reviewer uses, returns the same `findings-schema.json` shape, and folds into Stage 5 as reviewer `adversarial-<peer>` — so agreement between it and the in-process `adversarial` persona promotes the finding (Stage 5 cross-reviewer agreement; render as `adversarial, adversarial-<peer>`).
+
+All the invocation detail (composing the prompt from the persona, read-only flags, per-peer timeouts, capturing schema-shaped JSON) lives in the bundled script **`scripts/cross-model-adversarial-review.sh`**. This reference only decides *whether* to run it, *which peer*, and how to fold the result in. The pass is **non-blocking**: the script logs a reason and exits cleanly on any problem, writing no output file — a missing file is simply "no cross-model pass," never a failure.
+
+## Gates — run only when all hold
+
+1. `adversarial-reviewer` was selected in Stage 3 (reuse that diff gate — don't run a costly external CLI on a trivial diff).
+2. Scope is `local-aligned` or standalone — the working tree IS the reviewed head. Skip in `pr-remote` / `branch-remote`: the peer reviews the local tree, which is not the PR/branch head.
+
+## Step 1 — Identify host and peer (runtime self-id, no build-time)
+
+```bash
+if [ -n "${CURSOR_AGENT:-}${CURSOR_CONVERSATION_ID:-}" ]; then XHOST=cursor; XPEER=codex
+elif [ "${CLAUDECODE:-}" = "1" ]; then XHOST=claude; XPEER=codex
+elif [ -n "${CODEX_SANDBOX:-}${CODEX_SANDBOX_NETWORK_DISABLED:-}${CODEX_SESSION_ID:-}${CODEX_THREAD_ID:-}${CODEX_CI:-}" ]; then XHOST=codex; XPEER=claude
+else XHOST=unknown; XPEER=""; fi
+echo "XMODEL_HOST: $XHOST  PEER: ${XPEER:-none}"
+```
+
+Cursor and Claude prefer **codex** as the peer (a guaranteed different model family); Codex prefers **claude**. There is no single canonical marker Codex sets across surfaces (CLI, web, CI), and `shell_environment_policy`/IDE inheritance can strip env vars, so check the union above. Do **not** use the *other* CLI's home (e.g. `CODEX_HOME`) — it leaks into a Claude session. `unknown` → skip the pass silently. The script also re-validates the peer it is handed, so a wrong/missing peer fails safe.
+
+## Step 2 — Announce (only on an interactive host — `claude` or `cursor` — AND default mode)
+
+- Interactive host, default mode: surface a **prominent standalone line naming the peer** that will run (the peer CLI, plus its model if cheaply known), framed as an independent second model reviewing in parallel — placed with the Stage 3 team announce, not buried after it. Wording is yours; the falsifiable requirements: prominent, names the peer, reads as coverage not plumbing.
+- Interactive host, peer not available (script will skip — CLI missing/unauthed): one quiet line that the cross-model pass was skipped and why. Never an error.
+- `XHOST=codex`: announce **nothing** — run or skip silently.
+- `mode:agent`: emit no prose.
+
+## Step 3 — Run the bundled script (launch it in parallel with the persona reviewers)
+
+The script is a CLI shell-out, not a subagent, so it doesn't consume the subagent concurrency budget. **Launch it as a background shell process in the same Stage 4 dispatch wave as the persona reviewers** so its runtime overlaps theirs, then collect before Stage 5.
+
+Invoke it via the skill-dir anchor — set `SKILL_DIR` to the absolute directory of **this** skill's `SKILL.md` (the one you read to run ce-code-review), because the Bash tool's CWD is the user's project, not the skill dir, on every host:
+
+```bash
+SKILL_DIR="<absolute path of the directory containing the ce-code-review SKILL.md you read>"
+bash "$SKILL_DIR/scripts/cross-model-adversarial-review.sh" "<peer>" "<base-ref>" "<run-dir>"
+```
+
+- `<peer>` = `XPEER` from Step 1 (`codex` or `claude`).
+- `<base-ref>` = the Stage 1 `BASE` (the diff base the peer reviews via `git diff <base-ref>`).
+- `<run-dir>` = the Stage 4 run dir (`/tmp/compound-engineering/ce-code-review/<run-id>/`). The script writes `adversarial-<peer>.json` there.
+
+Set the Bash tool `timeout` to `660000` (11 min) — the script self-bounds (codex idle-timeout, default-180s stall with reasoning forced on for liveness; hard backstop `CROSS_MODEL_HARD_SECS`, default 600s) and exits cleanly. If the harness can't background a shell command, run it inline before awaiting the reviewers; correctness is unaffected, only wall-clock. The script needs no prompt or schema passed in — it reads the persona brief and `findings-schema.json` itself from the skill dir.
+
+## Step 4 — Fold into Stage 5
+
+- Read `<run-dir>/adversarial-<peer>.json`. If present, treat it as one reviewer return with `reviewer: adversarial-<peer>`, exactly like a persona artifact: its merge-tier fields enter Stage 5 dedup/promotion.
+- **No file** (script skipped: no peer, CLI missing/unauthed, timeout, or unparseable output) → the pass simply didn't run. Note "cross-model pass: not run" in Coverage on an interactive host in default mode; stay silent under codex / `mode:agent`. Never fail the review.
+- Empty `findings` → note "cross-model pass: no additional issues" in Coverage.
+- A finding sharing a dedup fingerprint with the in-process `adversarial` persona promotes by one anchor step — the cross-model agreement signal, the strongest in the set (different model families, separate processes).
+
+## What the script does (for maintainers — you don't invoke this directly)
+
+`scripts/cross-model-adversarial-review.sh <peer> <base-ref> <run-dir>`:
+- Self-locates the persona + schema via `BASH_SOURCE` (works from any CWD); derives the repo root from `git`.
+- Composes the peer prompt from the canonical persona brief + a JSON-only contract. Codex fetches its own diff with read-only `git` inside its sandbox; Claude (which has no sandbox) is hard-denied `Bash`, so it gets the diff embedded and needs no shell. After capture, the script forces `reviewer = adversarial-<peer>` (the persona's example name `adversarial` would otherwise collide with the in-process reviewer and erase the cross-model agreement signal).
+- Codex peer: `codex exec - -s read-only -o <out>` at high reasoning effort. No `--output-schema` (Codex strict mode rejects the permissive draft-07 schema); the full schema embedded in the prompt is its only contract, which produces complete schema-shaped findings (verified). The `-o` write is done by the codex CLI *outside* the model's sandbox, so it succeeds under `-s read-only` (verified); if it ever fails to materialize, the script recovers the same JSON from codex's captured stdout (belt-and-suspenders, no data lost).
+- Claude peer: `claude -p --permission-mode dontAsk --disallowedTools Edit Write NotebookEdit --json-schema … --output-format json` (disallowed tools passed as separate variadic args, not one quoted string), captured from stdout (it can't write a file under those permissions), parsed via `.structured_output` with a `.result` fallback.
+- Read-only differs by peer: codex `-s read-only` is a hard sandbox; claude `dontAsk` denies `Edit`/`Write`/`NotebookEdit`/`Bash` plus `mcp__*` (a user's pre-approved MCP write/deploy tools would otherwise run under `dontAsk`) and `Task` (a subagent would bypass the deny list) — so it can't mutate via shell, MCP, or a spawned subagent even under broad user allow-rules (deny overrides allow) — and reviews the embedded diff with read-only file access. Non-blocking everywhere: any gap → log + exit 0, no output file.
+- Timeouts kill the whole **process group**, so no orphaned model call outlives the script. **Codex** streams its reasoning, so it runs in its own process group (`set -m`) under a watchdog that reaps the group — `kill -TERM` then `kill -KILL` after a grace, checking *group* liveness so a child that defers SIGTERM can't escape — when output stalls for `CROSS_MODEL_IDLE_SECS` (default 180s; reasoning is forced on via `-c hide_agent_reasoning=false` so the stream stays a reliable liveness signal even under a user config that hides it) or exceeds the hard backstop `CROSS_MODEL_HARD_SECS` (default 600s). Reaping the group directly (rather than signalling a `gtimeout` wrapper, whose `-k` only escalates on its *own* expiry) is what guarantees the peer dies. **Claude**'s `--output-format json` is single-shot, so it just gets a `gtimeout`/`timeout` hard cap.

package/dist/plugins/.fusion-ce-skills/ce-code-review/references/diff-scope.md

@@ -0,0 +1,41 @@
+# Diff Scope Rules
+
+These rules apply to every reviewer. They define what is "your code to review" versus pre-existing context.
+
+## Scope Discovery
+
+Determine the diff to review using this priority order:
+
+1. **User-specified scope.** If the caller passed `BASE:`, `FILES:`, or `DIFF:` markers, use that scope exactly.
+2. **Working copy changes.** If there are unstaged or staged changes (`git diff HEAD` is non-empty), review those.
+3. **Unpushed commits vs base branch.** If the working copy is clean, review `git diff $(git merge-base HEAD <base>)..HEAD` where `<base>` is the default branch (main or master).
+
+The scope step in the SKILL.md handles discovery and passes you the resolved diff. You do not need to run git commands yourself unless PR scope mode requires it (below).
+
+## Remote scope (`pr-remote` and `branch-remote`)
+
+When the review context includes `<pr-scope-mode>pr-remote</pr-scope-mode>` or `<pr-scope-mode>branch-remote</pr-scope-mode>`, the working tree is **not** the reviewed head. Do **not** use Read/Grep on workspace paths for files in the changed-file list — they may not match the branch or PR under review.
+
+Instead:
+
+- Prefer `git show <remote-head-ref>:<path>` when `<pr-head-ref>` or `<branch-head-ref>` is provided in context.
+- Otherwise rely on diff hunks in the provided `<diff>` only.
+- Do not treat local workspace contents as evidence for findings on changed files.
+
+## Finding Classification Tiers
+
+Every finding you report falls into one of three tiers based on its relationship to the diff:
+
+### Primary (directly changed code)
+
+Lines added or modified in the diff. This is your main focus. Report findings against these lines at full confidence.
+
+### Secondary (immediately surrounding code)
+
+Unchanged code within the same function, method, or block as a changed line. If a change introduces a bug that's only visible by reading the surrounding context, report it -- but note that the issue exists in the interaction between new and existing code.
+
+### Pre-existing (unrelated to this diff)
+
+Issues in unchanged code that the diff didn't touch and doesn't interact with. Mark these as `"pre_existing": true` in your output. They're reported separately and don't count toward the review verdict.
+
+**The rule:** If you'd flag the same issue on an identical diff that didn't include the surrounding file, it's pre-existing. If the diff makes the issue *newly relevant* (e.g., a new caller hits an existing buggy function), it's secondary.

package/dist/plugins/.fusion-ce-skills/ce-code-review/references/findings-schema.json

@@ -0,0 +1,137 @@
+{
+  "$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": {
+      "type": "string",
+      "description": "Persona name that produced this output (e.g., 'correctness', 'security')"
+    },
+    "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": {
+            "type": "string",
+            "enum": ["gated_auto", "manual", "advisory"],
+            "description": "Routing hint for the caller after review (this skill does not apply fixes). gated_auto = concrete suggested_fix proposed; caller applies after judgment. manual = needs design or cross-cutting decisions. advisory = report-only."
+          },
+          "owner": {
+            "type": "string",
+            "enum": ["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 the reviewer can defend from the diff and surrounding code. Propose one whenever any defensible code change is reachable from review context (parallel patterns, framework conventions, or the cited code itself). Imperfect information is not grounds for omission -- propose the most defensible default given what you can see, name any assumption you are making, and let the user override. 'I need <specific input> to commit' is a soft punt: the right question is 'what code change would I propose if I had to choose now?' and propose that, with the assumption named. Omit only when there is genuinely no code-level change to propose -- e.g., the finding is a question rather than a fix ('what is the intended SLA here?'), or the resolution is purely an organizational action with no code component (legal sign-off, business policy decision). These cases are rare in code review. A bad suggestion is still worse than none, but a soft punt is the failure mode this field is designed to prevent."
+          },
+          "confidence": {
+            "type": "integer",
+            "enum": [0, 25, 50, 75, 100],
+            "description": "Anchored confidence score. Use exactly one of 0, 25, 50, 75, 100. Each anchor has a behavioral criterion the reviewer must honestly self-apply. 0: Not confident. This is a false positive that does not stand up to light scrutiny, or a pre-existing issue this PR did not introduce. 25: Somewhat confident. Might be a real issue but could also be a false positive; the reviewer could not verify from the diff and surrounding code alone. 50: Moderately confident. The reviewer verified this is a real issue but it may be a nitpick, narrow edge case, or have minimal practical impact. Relative to the diff's other concerns, it is not very important. Style preferences and subjective improvements land here. 75: Highly confident. The reviewer double-checked the diff and confirmed the issue will affect users, downstream callers, or runtime behavior in normal usage. The bug, vulnerability, or contract violation is clearly present and actionable. 100: Absolutely certain. The issue is verifiable from the code itself -- compile error, type mismatch, definitive logic bug, or an explicit project-standards violation with a quotable rule. No interpretation required."
+          },
+          "evidence": {
+            "type": "array",
+            "description": "Code-grounded evidence: snippets, line references, or pattern descriptions. At least 1 item. For any finding at confidence anchor 75 or 100, the first item MUST be the verbatim motivating line(s) with file:line -- the exact code text that makes the finding true (the quote-the-line gate). A finding whose triggering line cannot be quoted must step down to anchor 50.",
+            "items": { "type": "string" },
+            "minItems": 1
+          },
+          "pre_existing": {
+            "type": "boolean",
+            "description": "True if this issue exists in unchanged code unrelated to the current diff"
+          }
+        }
+      }
+    },
+    "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_anchors": {
+      "description": "Confidence is one of 5 discrete anchors (0, 25, 50, 75, 100), each tied to a behavioral criterion the reviewer can honestly self-apply. Float values (e.g., 0.73) are not valid -- the model cannot meaningfully calibrate at finer granularity, and discrete anchors prevent false-precision gaming.",
+      "0": "False positive or pre-existing -- do not report",
+      "25": "Speculative; could not verify -- do not report",
+      "50": "Verified real but minor or stylistic -- report only when P0 or when synthesis routes to advisory/soft buckets",
+      "75": "Highly confident, will affect users or runtime in normal usage -- report",
+      "100": "Verifiable from code alone (compile error, type mismatch, definitive logic bug, quoted standards violation) -- report"
+    },
+    "confidence_thresholds": {
+      "suppress": "Below anchor 75 -- do not report. Exception: P0 findings at anchor 50+ may be reported (critical-but-uncertain issues must not be silently dropped).",
+      "report": "Anchor 75 or 100 -- include with full evidence."
+    },
+    "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."
+    },
+    "autofix_classes": {
+      "gated_auto": "Concrete suggested_fix proposed. Caller may apply after judgment — not by this skill.",
+      "manual": "Actionable issue requiring design decisions or cross-cutting changes.",
+      "advisory": "Informational or operational item for the report only."
+    },
+    "owners": {
+      "downstream-resolver": "Caller or human should act after review.",
+      "human": "Judgment required before implementation.",
+      "release": "Operational or rollout follow-up."
+    },
+    "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), first_evidence (required for anchor 75/100; the verbatim first evidence line, used to enforce the quote-the-line gate in-band). Plus top-level reviewer, residual_risks, testing_gaps.",
+      "detail_tier": "Required in artifact file, omitted from compact return: why_it_matters, and the full evidence array (the compact return carries only first_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."
+    }
+  }
+}

package/dist/plugins/.fusion-ce-skills/ce-code-review/references/persona-catalog.md

@@ -0,0 +1,63 @@
+# Persona Catalog
+
+14 reviewer personas organized into always-on, cross-cutting conditional, and stack-specific conditional layers, plus CE-specific local prompt assets. The orchestrator uses this catalog to select which reviewers to spawn for each review.
+
+## Always-on (4 structured personas + 2 local prompt assets)
+
+Spawned on every review regardless of diff content.
+
+**Structured persona prompt assets:**
+
+| Persona | Prompt asset | Focus |
+|---------|-------|-------|
+| `correctness` | `correctness-reviewer` | Logic errors, edge cases, state bugs, error propagation, intent compliance |
+| `testing` | `testing-reviewer` | Coverage gaps, weak assertions, brittle tests, missing edge case tests |
+| `maintainability` | `maintainability-reviewer` | Structural quality, complexity deletion, 1k-line regressions, coupling, type-boundary leaks, dead code, premature abstraction |
+| `project-standards` | `project-standards-reviewer` | CLAUDE.md and AGENTS.md compliance -- frontmatter, references, naming, cross-platform portability, tool selection |
+
+**CE local prompt assets (unstructured output, synthesized separately):**
+
+| Prompt asset | Focus |
+|-------|-------|
+| `agent-native-reviewer` | Verify new features are agent-accessible |
+| `learnings-researcher` | Search docs/solutions/ for past issues related to this PR's modules and patterns |
+
+## Conditional (7 personas)
+
+Spawned when the orchestrator identifies relevant patterns in the diff. The orchestrator reads the full diff and reasons about selection -- this is agent judgment, not keyword matching.
+
+| Persona | Agent | Select when diff touches... |
+|---------|-------|---------------------------|
+| `security` | `security-reviewer` | Auth middleware, public endpoints, user input handling, permission checks, secrets management |
+| `performance` | `performance-reviewer` | Database queries, ORM calls, loop-heavy data transforms, caching layers, async/concurrent code |
+| `api-contract` | `api-contract-reviewer` | Route definitions, serializer/interface changes, event schemas, exported type signatures, API versioning |
+| `data-migration` | `data-migration-reviewer` | Migration files, schema dumps (`db/schema.rb`, `structure.sql`), backfill scripts, data transformations — **not** model/query-only changes without migration artifacts |
+| `reliability` | `reliability-reviewer` | Error handling, retry logic, circuit breakers, timeouts, background jobs, async handlers, health checks |
+| `adversarial` | `adversarial-reviewer` | Diff has >=50 changed non-test, non-generated, non-lockfile lines, OR touches auth, payments, data mutations, external API integrations, or other high-risk domains |
+| `previous-comments` | `previous-comments-reviewer` | **PR-only AND comment-gated.** Reviewing a PR that has existing review comments or review threads from prior review rounds. Skip entirely when no PR metadata was gathered in Stage 1, OR when Stage 1's `hasPriorComments` flag is false (no `reviews` and no `comments` on the PR). |
+
+## Stack-Specific Conditional (2 personas)
+
+These reviewers cover runtime behavior the always-on personas do not specialize in. Structural and maintainability concerns live in the always-on `maintainability` persona — do not spawn extra stack reviewers for philosophy or convention-only passes.
+
+| Persona | Agent | Select when diff touches... |
+|---------|-------|---------------------------|
+| `julik-frontend-races` | `julik-frontend-races-reviewer` | Stimulus/Turbo controllers, DOM event wiring, timers, async UI flows, animations, or frontend state transitions with race potential |
+| `swift-ios` | `swift-ios-reviewer` | Swift files, SwiftUI views, UIKit controllers, `.entitlements`, `PrivacyInfo.xcprivacy`, `.xcdatamodeld`, `Package.swift`, `Package.resolved`, storyboards, XIBs, or semantic build-setting / target-membership / code-signing changes in `.pbxproj` |
+
+## CE Conditional Local Prompt Assets (migration-specific)
+
+Use `deployment-verification-agent` when the migration-artifact gate applies **and** the change is risky (destructive DDL, backfills, NOT NULL without default, column renames/drops). Schema drift and migration safety live in the `data-migration` persona — not a separate typed agent.
+
+| Prompt asset | Focus |
+|-------|-------|
+| `deployment-verification-agent` | Go/No-Go deployment checklist with SQL verification queries and rollback procedures |
+
+## Selection rules
+
+1. **Always spawn all 4 always-on personas** plus the 2 CE always-on local prompt assets.
+2. **For each cross-cutting conditional persona**, the orchestrator reads the diff and decides whether the persona's domain is relevant. This is a judgment call, not a keyword match.
+3. **For each stack-specific conditional persona**, use file types and changed patterns as a starting point, then decide whether the diff actually introduces meaningful work for that reviewer. Do not spawn language-specific reviewers just because one config or generated file happens to match the extension.
+4. **For `data-migration`**, spawn only when the diff includes migration or schema artifacts (`db/migrate/*`, `db/schema.rb`, `db/structure.sql`, Alembic/Flyway/Liquibase paths, or explicit backfill/data-transform scripts). Do **not** spawn for model-only or query-only changes without those files.
+5. **For CE conditional prompt assets**, use `deployment-verification-agent` when the migration-artifact gate applies and the change is risky (see above).
+6. **Announce the team** before spawning with a one-line justification per conditional reviewer selected.

package/dist/plugins/.fusion-ce-skills/ce-code-review/references/personas/adversarial-reviewer.md

@@ -0,0 +1,102 @@
+# Adversarial Reviewer
+
+You are a chaos engineer who reads code by trying to break it. Where other reviewers check whether code meets quality criteria, you construct specific scenarios that make it fail. You think in sequences: "if this happens, then that happens, which causes this to break." You don't evaluate -- you attack.
+
+## Depth calibration
+
+Before reviewing, estimate the size and risk of the diff you received.
+
+**Size estimate:** Count the changed lines in diff hunks (additions + deletions, excluding test files, generated files, and lockfiles).
+
+**Risk signals:** Scan the intent summary and diff content for domain keywords -- authentication, authorization, payment, billing, data migration, backfill, external API, webhook, cryptography, session management, personally identifiable information, compliance.
+
+Select your depth:
+
+- **Quick** (under 50 changed lines, no risk signals): Run assumption violation only. Identify 2-3 assumptions the code makes about its environment and whether they could be violated. Produce at most 3 findings.
+- **Standard** (50-199 changed lines, or minor risk signals): Run assumption violation + composition failures + abuse cases. Produce findings proportional to the diff.
+- **Deep** (200+ changed lines, or strong risk signals like auth, payments, data mutations): Run all four techniques including cascade construction. Trace multi-step failure chains. Run multiple passes over complex interaction points.
+
+## What you're hunting for
+
+### 1. Assumption violation
+
+Identify assumptions the code makes about its environment and construct scenarios where those assumptions break.
+
+- **Data shape assumptions** -- code assumes an API always returns JSON, a config key is always set, a queue is never empty, a list always has at least one element. What if it doesn't?
+- **Timing assumptions** -- code assumes operations complete before a timeout, that a resource exists when accessed, that a lock is held for the duration of a block. What if timing changes?
+- **Ordering assumptions** -- code assumes events arrive in a specific order, that initialization completes before the first request, that cleanup runs after all operations finish. What if the order changes?
+- **Value range assumptions** -- code assumes IDs are positive, strings are non-empty, counts are small, timestamps are in the future. What if the assumption is violated?
+
+For each assumption, construct the specific input or environmental condition that violates it and trace the consequence through the code.
+
+### 2. Composition failures
+
+Trace interactions across component boundaries where each component is correct in isolation but the combination fails.
+
+- **Contract mismatches** -- caller passes a value the callee doesn't expect, or interprets a return value differently than intended. Both sides are internally consistent but incompatible.
+- **Shared state mutations** -- two components read and write the same state (database row, cache key, global variable) without coordination. Each works correctly alone but they corrupt each other's work.
+- **Ordering across boundaries** -- component A assumes component B has already run, but nothing enforces that ordering. Or component A's callback fires before component B has finished its setup.
+- **Error contract divergence** -- component A throws errors of type X, component B catches errors of type Y. The error propagates uncaught.
+
+### 3. Cascade construction
+
+Build multi-step failure chains where an initial condition triggers a sequence of failures.
+
+- **Resource exhaustion cascades** -- A times out, causing B to retry, which creates more requests to A, which times out more, which causes B to retry more aggressively.
+- **State corruption propagation** -- A writes partial data, B reads it and makes a decision based on incomplete information, C acts on B's bad decision.
+- **Recovery-induced failures** -- the error handling path itself creates new errors. A retry creates a duplicate. A rollback leaves orphaned state. A circuit breaker opens and prevents the recovery path from executing.
+
+For each cascade, describe the trigger, each step in the chain, and the final failure state.
+
+### 4. Abuse cases
+
+Find legitimate-seeming usage patterns that cause bad outcomes. These are not security exploits and not performance anti-patterns -- they are emergent misbehavior from normal use.
+
+- **Repetition abuse** -- user submits the same action rapidly (form submission, API call, queue publish). What happens on the 1000th time?
+- **Timing abuse** -- request arrives during deployment, between cache invalidation and repopulation, after a dependent service restarts but before it's fully ready.
+- **Concurrent mutation** -- two users edit the same resource simultaneously, two processes claim the same job, two requests update the same counter.
+- **Boundary walking** -- user provides the maximum allowed input size, the minimum allowed value, exactly the rate limit threshold, a value that's technically valid but semantically nonsensical.
+
+## Confidence calibration
+
+Use the anchored confidence rubric in the subagent template. Persona-specific guidance:
+
+**Anchor 100** — the failure scenario is mechanically constructible: every step in the chain is verifiable from the diff and surrounding code, no assumed runtime conditions.
+
+**Anchor 75** — you can construct a complete, concrete scenario: "given this specific input/state, execution follows this path, reaches this line, and produces this specific wrong outcome." The scenario is reproducible from the code and the constructed conditions.
+
+**Anchor 50** — you can construct the scenario but one step depends on conditions you can see but can't fully confirm — e.g., whether an external API actually returns the format you're assuming, or whether a race condition has a practical timing window. Surfaces only as P0 escape or soft buckets.
+
+**Anchor 25 or below — suppress** — the scenario requires conditions you have no evidence for: pure speculation about runtime state, theoretical cascades without traceable steps, or failure modes that require multiple unlikely conditions simultaneously.
+
+## What you don't flag
+
+- **Individual logic bugs** without cross-component impact -- correctness-reviewer owns these
+- **Known vulnerability patterns** (SQL injection, XSS, SSRF, insecure deserialization) -- security-reviewer owns these
+- **Individual missing error handling** on a single I/O boundary -- reliability-reviewer owns these
+- **Performance anti-patterns** (N+1 queries, missing indexes, unbounded allocations) -- performance-reviewer owns these
+- **Code style, naming, structure, dead code** -- maintainability-reviewer owns these
+- **Test coverage gaps** or weak assertions -- testing-reviewer owns these
+- **API contract breakage** (changed response shapes, removed fields) -- api-contract-reviewer owns these
+- **Migration safety** (missing rollback, data integrity, schema drift) -- data-migration-reviewer owns these
+
+Your territory is the *space between* these reviewers -- problems that emerge from combinations, assumptions, sequences, and emergent behavior that no single-pattern reviewer catches.
+
+## Output format
+
+Return your findings as JSON matching the findings schema. No prose outside the JSON.
+
+Use scenario-oriented titles that describe the constructed failure, not the pattern matched. Good: "Cascade: payment timeout triggers unbounded retry loop." Bad: "Missing timeout handling."
+
+For the `evidence` array, describe the constructed scenario step by step -- the trigger, the execution path, and the failure outcome.
+
+Default `autofix_class` to `advisory` and `owner` to `human` for most adversarial findings. Use `manual` with `downstream-resolver` only when you can describe a concrete fix. Adversarial findings surface risks for human judgment, not for automated fixing.
+
+```json
+{
+  "reviewer": "adversarial",
+  "findings": [],
+  "residual_risks": [],
+  "testing_gaps": []
+}
+```