dsh-compound-engineering 0.0.0-stage → 0.1.0

package/skills/ce-code-review/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: ce-code-review
+description: "Review a named diff or PR for bugs, regressions, tests, and standards. Use when asked to review code or when a shipping skill needs a review receipt. Use when asked to apply this review's findings locally. Use ce-resolve-pr-feedback for feedback already left on a PR."
+argument-hint: "[mode:agent] [apply:local] [blank to review current branch, or provide PR link]"
+---
+
+# Code Review
+
+Help the caller deliver a correct change within the agreed scope. Find defects and improvements whose consequences justify action; judge the code against its intended behavior and project requirements, not a preferred rewrite. Serious defects remain important even when the diff is small. An adequate change needs no findings.
+
+**Done when:** required review and validation are complete, retained findings are supported by the source, and the caller has a clear result with any remaining coverage limits. Apply only when the invocation authorizes it, under the rules below.
+
+## Artifact Root
+
+<!-- ce-docs-root:start -->
+**Resolve the CE artifact root `<root>` before composing any artifact path.**
+
+- **Read** `docs_root` from `<repo-root>/.compound-engineering/config.yaml` only (`<repo-root>` = `git rev-parse --show-toplevel`). Do not read it from `config.local.yaml`. Unset -> `<root>` is `docs`, exactly as before.
+- **Validate** a set value: a repo-relative directory whose real, symlink-resolved path stays inside the repo and is neither the repo root nor under `.git/`. Otherwise stop with an error naming `docs_root` and the value -- never fall back to `docs`.
+- **Use** `<root>` as the sole artifact location: create it if absent, compose each path as `<root>/<subdir>` with this skill's own subdirectory, and never also read `docs`.
+<!-- ce-docs-root:end -->
+
+## Execution spine
+
+Follow these steps in order; the references supply the detail but never change the order. Read each reference when you enter the step whose own work it governs; a read made before that step does not satisfy it, and a reference you only hand to a leaf is not one you read.
+
+1. Read `references/modes-and-output.md` first. It settles arguments, conflicts, the quick-review short-circuit, the Review depth gate, and what this invocation returns.
+2. **Stage 1.** Read `references/scope.md` and resolve the reviewed diff, the scope mode, and the deterministic scope signals. Then apply that Review depth gate before Stage 2. Lite ends the run without the later spine references; lite and focused each run from this context by `references/depth-paths.md`.
+3. **Stage 2.** Read `references/intent-and-plan.md`, write the intent summary every reviewer receives, and discover the plan Stage 6 verifies requirements against.
+4. **Stage 3.** Read `references/persona-catalog.md` and `references/select-and-route.md`, then select the reviewers the change's risks call for, find the applicable standards files, and decide how the adversarial review will run.
+5. **Stage 3d.** When adversarial is selected for a local reviewed tree, start and persist the sanctioned cross-model job that `references/cross-model-review.md` defines, **before any local persona dispatch**. Invoking this skill is itself the authorization for its configured or allowlisted peer route, once you have made the required disclosure of the recipient and of the code that leaves the machine. Do not ask the user to confirm a second time, and do not skip the peer because the user did not repeat that authorization. An explicit user prohibition on external review overrides it, as does a checkout that sets `cross_model_review_mode: off` with no live opt-in; both are resolved before you bind a route. A started peer replaces the local adversarial persona at this stage, and only a real failure to scope, allowlist, reach, authenticate, or start it leaves the local fallback in the roster; a later stage may still restore the local reviewer under the conditions that reference states.
+6. **Stage 4.** Read `references/dispatch-reviewers.md`. Dispatch the selected local reviewers as one concurrent batch collected in this turn, sized to the host's active-agent cap. Every successful launch is collected only when its terminal outcome is in hand: a valid compact return is consumed, a tool error or malformed output is recorded as a failed reviewer, and a launch acknowledgement alone is not a result. Use the host's blocking collection capability for asynchronous receipts within the bound that reference states, after which an uncollected reviewer is a failed reviewer; a terminal outcome may arrive as the call's return, a blocking wait's return, or a host-delivered terminal message that names the launch and carries its payload; a progress update is not one. If launched work cannot be collected reliably, stop it, and for any persisted peer (the cross-model job) run the cleanup its reference describes before returning the failure result, and never end the turn on progress to await it. Detaching local review into a polled background job is forbidden. The cross-model peer is the only detached work, and it may overlap this batch.
+7. **Stages 5 and 6.** Once every reviewer result is in, write the finish input `references/finish-input.md` defines and stay in that reference: it owns the validator launch and the run-artifact list. Dispatch in sequence the two leaf subagents it names, each seeded with `references/finish-review.md`, which the leaves read from disk and you do not open: a merge leaf that folds in the peer's findings once and merges from the run dir, then, after you launch and collect the validator it selected, a report leaf that renders the report. Neither leaf launches a subagent; you launch every one. Emit the report leaf's return verbatim as this skill's response. Never synthesize directly from raw reviewer artifacts, and never merge or render in the dispatch context. In the multi-agent path, emit only this skill's report: do not also invoke a harness-native findings or reporting tool, which belongs to the quick-review short-circuit alone.
+
+## Operating principles
+
+- **Report-only by default; never push.** A bare `ce-code-review` invocation produces findings and does not apply them. Entering the apply stage requires `apply:local`, or an explicit user request in the invoking prompt to apply or fix this review's findings; a deprecated `mode:autofix` token is neither. `mode:agent` never mutates the tree, even when nested inside a workflow that later applies findings. Never push, open PRs, or file tickets in any mode.
+- **No blocking prompts.** Never use `AskUserQuestion`, `request_user_input`, `ask_user`, or other blocking question tools. Infer intent, plan, and scope from explicit tokens, git state, PR metadata, and conversation. Note uncertainty in Coverage or the verdict — do not stop to ask.
+- **Explicit mutations only.** Never run `gh pr checkout`, `git checkout`, `git switch`, or similar branch-switch commands. Passing a PR number, URL, or branch name selects **review scope**, not permission to mutate the working tree. Uncommitted work can only be reviewed from the checkout that holds it, so to review it on a feature branch, stay on that branch (or check it out yourself) and pass `base:` or no target.
+- **Report outcomes, not machinery.** What you show the user is about the review: what is being examined, which coverage is included and the one-line reason for each conditional lens, the independent cross-model pass, and the findings. Name what the user would recognize, such as a PR number, a reviewer's concern, or a peer model. This skill's internal labels, dispatch bookkeeping, and setup narration stay out of user-facing text. Never claim more about the peer than its receipt attests. This governs *what* you surface and suppress, not the wording; use your own voice.

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

@@ -0,0 +1,67 @@
+# `autofix_class` rubric (personas)
+
+`autofix_class` describes the **shape** of the follow-up work a finding needs — it is information, **not a check that permits or blocks applying a fix**. In report-only runs the user or caller interprets findings and decides what to apply; when local apply was explicitly authorized, Stage 5c (Act on findings) still uses judgment. 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`.
+
+## Severity Scale
+
+The merge bar is the one from Google's Code Review Developer Guide: the change must improve overall code health, not be perfect. Severity ranks by that bar — functionality and design defects outrank style and taste, and a finding whose only claim is "could be better" never blocks.
+
+All reviewers use P0-P3:
+
+| Level | Meaning | Action |
+|-------|---------|--------|
+| **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 |
+
+## Action Routing
+
+Severity answers **urgency**. `autofix_class` and `owner` are **information** describing the shape of follow-up work for callers; this metadata does not grant apply permission. Permission to apply fixes is a separate, explicit authorization that Stage 5c checks before touching any file. The persona guidance for choosing a class is at the top of this reference.
+
+| `autofix_class` | Default owner | Meaning |
+|-----------------|---------------|---------|
+| `gated_auto` | `downstream-resolver` or `human` | Concrete `suggested_fix` proposed; caller applies after judgment |
+| `manual` | `downstream-resolver` or `human` | Actionable work needing design input or handoff |
+| `advisory` | `human` or `release` | Report-only — learnings, rollout notes, residual risk |
+
+Routing rules:
+
+- **Synthesis (Stage 5, Merge findings) makes the final decision on `autofix_class` and `owner`.** The values a persona supplies are input, not the last word.
+- **When reviewers disagree, keep the more cautious class.** A merged finding may move from `gated_auto` to `manual`; moving the other way needs stronger evidence.
+- **Reject `safe_auto` and `review-fixer` if present** — drop the finding or remap to `gated_auto` / `downstream-resolver` during synthesis.
+- **`requires_verification: true` means any caller-applied fix needs targeted tests or follow-up validation.**
+
+## Protected Artifacts
+
+Compound-engineering pipeline artifacts must never be flagged for deletion, removal, or gitignore by any reviewer. A protected artifact is any file **under** a `plans/`, `solutions/`, or legacy `brainstorms/` directory **whose immediate parent is the artifact root** — a directory named `docs` (the default, and where unmigrated legacy artifacts stay even after a project sets `docs_root`) or the configured `docs_root` when this run resolved it:
+
+- `plans/` under the artifact root -- unified plan artifacts created by ce-brainstorm or ce-plan (decision artifacts; execution progress is derived from git, not stored in plan bodies)
+- `solutions/` under the artifact root -- solution documents created during the pipeline (categories nest, e.g. `solutions/<category>/foo.md`)
+- the legacy `brainstorms/` -- requirements documents created by older ce-brainstorm versions
+
+Matching by the immediate parent covers nested category files while leaving a same-named directory elsewhere (a skill's own `references/personas/` prompt assets, parented by `references`) as ordinary code whose deletion finding stands. A run that never resolved a configured root still protects the `docs`-parented tree; a configured-root artifact seen by such a run is the one honest gap. A finding that recommends deleting, removing, or gitignoring such a file is never emitted, on any depth path; synthesis discards one that arrives anyway.
+

package/skills/ce-code-review/references/cross-model-recovery.md

@@ -0,0 +1,38 @@
+# Cross-Model Adversarial Pass: recovery branches
+
+Read this only from the branch that sends you here: Stage 3d's no-job-id start failure (`references/select-and-route.md`), or the fold-in read in `references/cross-model-review.md` Step 5 when the runner's exit code or the job's terminal state says the peer produced no usable artifact. A run whose peer started and folded never opens this file. Every branch below decides one thing: whether the adversarial lens is still covered, and by what.
+
+## Outcomes that need a decision
+
+- **Dispatch-infrastructure failure** — the runner or worker itself crashed: a non-zero exit before any job starts, a preflight/detach failure, or an unresolved `$SKILL_DIR`/script path. This is different from the conditions-not-met skips above, where no dispatch was attempted, so do not fold it into the clean not-run bucket on the first error. The two failure shapes recover at different points. A **no-job-id** preflight failure (exit before any job id, unresolved `$SKILL_DIR`) is recovered entirely at **Stage 3d's no-job branch**, before the local roster is final. That is the only point where re-running the start can still recover cross-model corroboration and, failing that, cleanly fall back to the in-process reviewer, which then covers the lens; only corroboration is lost. Do **not** re-attempt that case here at fold-in: Stage 4 may already have dispatched the in-process `adversarial-reviewer`, so a fold-in peer re-run would put both on the same brief, and only one of them may run it. This step handles only the **job-id-returned-then-failed** crash; its failed job is reaped here and the in-process reviewer is already gone. For it, re-run the **same resolved fixed route** by hand, holding the target and model, the `git diff <base-ref>` read scope, and the adversarial persona brief fixed. Keep retrying while each failure is a new, plausibly recoverable one and the shared peer deadline holds. This is a same-route retry, deliberately distinct from the quota rule below, which requires a newly disclosed route. Stop once a failure repeats or the deadline is spent. The hand recovery is then the adversarial lens's only cover, so the Coverage line must report the adversarial lens as **degraded**, not merely cross-model corroboration lost. A hand recovery may not substitute a different target or provider, widen the read scope, or relax the read-only trust boundary; those make the recovered peer untrustworthy, not merely unavailable.
+- **Transport unavailable before egress** — `out.log` carries `transport unavailable (pre-egress, <scope>): <reason>`. The peer did not run and no reviewed content reached the provider, so this is never "peer ran, no usable output"; Coverage reports the cross-model peer as not run with that reason. Scope `shared` (Node, `npx`, or the npm fetch of acpx) fails every route the same way, so no replacement peer can cover the lens: take step 2 of the did-not-run fallback. Scope `route` (that route's CLI is missing, an acpx config file replaces its launch command, or the adapter rejected the model, with the available models listed) affects only that route. A rejected model follows the refused-model rule below; any other route reason runs the did-not-run fallback, which allows its one replacement.
+- **Ran but produced no usable output** — the job reached `done` (or any terminal state) yet no `adversarial-<provider>.json` exists. The peer ran and received the content but returned nothing in the schema shape: unparseable output, or empty findings the script dropped. This is different from not-run: note "cross-model pass: peer ran, no usable output" in human-facing markdown Coverage. Never fail the review. When the diagnostic classification below proves this was a no-review outcome, run the did-not-run fallback before treating the lens as covered.
+- **Started but not `done`** — the final status read reports `failed`, `timeout`, or `died-without-result` (a job reaped at the shared deadline records `timeout`, with the reap noted in its reason) → still non-blocking, but never silent: name the peer and its terminal state in Coverage (e.g. "cross-model adversarial peer: timeout"). A pass that never started gets no terminal-state line; it is reported as not run. When the diagnostic classification below proves this was a no-review outcome, run the did-not-run fallback rather than leaving the lens uncovered.
+- **Classify the skip reason before deleting.** Read `out.log` before cleanup, including bounded lines prefixed `peer skip evidence:`. Judge the full diagnostic; do not grep for a closed phrase list. Attribute an account authentication failure only after provider-capable dispatch is positively established by the launch context or provider response; then report the observed failure and login or credential-refresh remediation. Without that proof, login-shaped peer text describes only the peer's execution context: a sandboxed host produces the same signal as a genuine logout, so never report it as the user's account being logged out or prompt a login command.
+  - Any authentication-shaped failure: the peer did not review, whether the explanation is credential-attributable or execution-context-only. Attribution changes the explanation, not coverage; run the did-not-run fallback.
+  - Transient provider-capacity or rate-limit failure: the worker exclusively owns the one same-route retry under Step 1's overload condition (the worker alone retries, once, after its adapter reports a provider overload, HTTP 529). Once a provider no-review outcome reaches the host, dispatch in-process `adversarial-reviewer`; the host never restarts that peer. Do not run the did-not-run fallback or switch recipients.
+  - Max-turn exhaustion: dispatch in-process `adversarial-reviewer`. Do not retry the peer or switch recipients.
+  - The requested model itself was refused: the adapter did not offer it, or the provider rejected it for this account (`peer skip evidence (reply):` carries a rejection the provider sent as reply text). Only the model failed; the route is still usable. If the worker ran its own default model because none was configured or named by the user, use the lens's one replacement for a new job on the same route. Give it the closest same-family model, picked from `peer skip evidence (advertised models):` when that line is present, and bind it as the same-family replacement paragraph in `references/cross-model-review.md` describes. If that job also ends in a no-review outcome, take step 2 of the did-not-run fallback. Coverage says which model was rejected and that the user can set `cross_model_model` to one that works. A configured or user-named model is never swapped; run the did-not-run fallback.
+  - Any other diagnostic that shows the peer never reviewed the diff: it hit a session or usage quota, or its CLI failed before reviewing, for example by rejecting an option that its installed version does not support. Do not retry that route; run the did-not-run fallback.
+  - Anything else, including a diagnostic that cannot show whether the peer reviewed: name the observed failure; do not run the did-not-run fallback.
+- **Did-not-run fallback** (first no-review outcome, including the first one): the started job did not cover the adversarial lens. Do not retry that same route. Then:
+  1. If this is the first replacement attempt, the failed recipient was **not** an explicit user-stated preference (Step 1 item 1), and another attested-different installed+allowlisted target remains: announce that new recipient and start a new job with a new `CROSS_MODEL_FIXED_ROUTE`. Wait for it with the remaining shared deadline and fold its artifact the same way as the first job. That job now covers the lens. Never switch recipients inside the worker. If this replacement also ends in a no-review outcome, do not start a third peer; take step 2.
+  2. Otherwise (explicit recipient, or no other eligible peer): dispatch in-process `adversarial-reviewer` now. Coverage records the peer as not run, with the observed reason, and names the cover in exactly this form: `adversarial lens: in-process fallback (cross-model peer not run: <reason>)`, matching `peer.outcome: in-process-fallback`. Never write `harness-native fallback` here: that phrase is `ce-work`'s ship-gate signal for a review that ran without `ce-code-review` at all, and reusing it makes a complete review read as a skipped one.
+  A config or default selection is not an explicit user-stated preference. One replacement only; never silently continue to another recipient.
+
+## Trust boundary (maintainers)
+
+The peer reviews the **current work tree** against `git diff <base-ref>`. Reviewed code/diff content is sent to an external model provider (OpenAI, Anthropic, xAI, Google, or Cursor, depending on the resolved peer). `CROSS_MODEL_PEERS` restricts which providers may receive content.
+
+**Isolation differs from ce-doc-review by design.** Doc-review embeds a self-contained document and denies every permission from an empty workspace. Code-review needs surrounding code context, so peers run **in-tree**: every route runs through acpx (an Agent Client Protocol client, which needs Node 22.13 or newer with `npx`) from the repository root, and acpx passes it no MCP servers. acpx approves the peer's read and search requests and denies every other permission request, and each adapter runs in its read-only mode where it has one. That removes a tool only where the agent asks permission before using it, so the routes differ in what the peer can still do:
+
+| Route | Reads outside the repository, including the staged large diff | Tools still usable without permission |
+|---|---|---|
+| `claude` | Allowed (a read permission, which acpx approves) | Reads and searches; read-only shell commands such as `git diff`. Web tools are denied |
+| `codex` | Allowed | Reads anywhere and shell commands, including writes: its adapter does not enforce read-only mode |
+| `grok-cursor`, `cursor`, `composer` | Allowed | Reads and searches anywhere |
+| `grok-cli` | Small diff: refused (it reads through acpx, which rejects paths outside the repository). Large diff: allowed, through its own read tool | Reads inside the repository; web fetch and web search, which its ACP server cannot disable. On a large diff its own tools also write without asking |
+| `opencode` | Allowed (its config allows external-directory reads) | Reads anywhere; edits, web, and subagents are denied in its config |
+| `antigravity` | Allowed (a read permission, which acpx approves) | Reads and searches. Shell commands and edits ask permission and are denied. It loads skills only from its private per-run home and the repository's `.agents/skills` and `.gemini/skills` |
+
+On a diff too large to inline, every route gets the staged diff's private path instead of the diff. `grok-cli` then runs with its own file tools, because acpx's file access refuses that path. Claude starts in safe mode and OpenCode with `OPENCODE_DISABLE_PROJECT_CONFIG=1`, so the reviewed repository's Claude settings and hooks and its `.opencode/{plugin,agent}` do not load. The worst case is disclosure of the reviewed content, except on the codex route, and on `grok-cli` with a large diff, where a peer could also change files. The script's stderr audit log records each send so every transfer is auditable even in `mode:agent`.

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

@@ -0,0 +1,191 @@
+# Cross-Model Adversarial Pass
+
+Runs the **adversarial** review a second time through a different model (the "peer"), reached over one fixed route, in a read-only process. The peer gets the **same** `references/personas/adversarial-reviewer.md` brief the in-process reviewer uses, returns the same `findings-schema.json` shape, and joins Stage 5 (synthesis) as reviewer `adversarial-<provider>`. Its findings count as independent corroboration, and can promote a finding both reviewers agree on, only when its identity record (the "receipt") says `independence_verified: true`. Otherwise its findings stay in the review as attributed evidence with no promotion bonus.
+
+This pass is **adversarial-only**. No other persona gets a cross-model twin, and there is no whole-diff generalist peer. The pass costs nothing unless Stage 3 (reviewer selection) already selected the adversarial reviewer.
+
+Before any reviewed content leaves the machine, the host picks one concrete route and approves it (this document calls that approval a "sanction"). `scripts/cross-model-adversarial-review.sh` holds to that fixed route, applies read-only controls, captures JSON in the findings-schema shape, and records identity receipts. Before dispatch it makes a conservative estimate of the diff's token count and file count. An oversized diff is not pasted whole into the prompt: the worker gives the peer the orchestrator's compact semantic review map and keeps the exact diff as a private file outside the repository. Every route gets that file's path and reads it selectively (`references/cross-model-recovery.md` records what each route can read). Every route runs through acpx, which needs Node 22.13 or newer with `npx`. A failed route writes no artifact and never switches recipients on its own.
+
+## Run conditions — run only when all hold
+
+1. `adversarial-reviewer` was selected in Stage 3 (reviewer selection), or the Review depth gate chose the focused path, whose one independent read is this lens. Reuse that selection; do not run a costly external CLI on a trivial diff.
+2. The working tree is the reviewed head (standalone, `base:`, or `local-aligned` scope). Skip in `pr-remote` / `branch-remote`: the peer reviews the local tree, which is not the PR or branch head.
+
+## Step 1 — Attest host identity, then sanction one fixed route
+
+Keep requested **target**, CLI **harness/intermediary**, serving **family/provider**, and served model separate. `cursor` means `cursor-agent` with its configured default/Auto model and no `--model` flag. `composer` means an explicit Composer-family model through Cursor. `grok` prefers its native CLI; Grok through Cursor is a distinct route and recipient. `antigravity` means a Gemini model through Google's Antigravity ACP runtime; a request for a Gemini peer binds target `antigravity`.
+
+Attest both the host harness and its serving family:
+
+```bash
+XHOST_SEEN=;
+if [ "${CLAUDECODE:-}" = "1" ]; then XHOST_SEEN="$XHOST_SEEN claude"; fi;
+if [ -n "${CODEX_SANDBOX:-}${CODEX_SANDBOX_NETWORK_DISABLED:-}${CODEX_SESSION_ID:-}${CODEX_THREAD_ID:-}${CODEX_CI:-}" ]; then XHOST_SEEN="$XHOST_SEEN codex"; fi;
+if [ "${GROK_AGENT:-}" = "1" ] || [ -n "${GROK_SESSION_ID:-}" ]; then XHOST_SEEN="$XHOST_SEEN grok"; fi;
+if [ -n "${OMPCODE:-}" ]; then XHOST_HARNESS=omp; XHOST_FAMILY=unknown;
+elif [ "$XHOST_SEEN" = " claude" ] || [ "$XHOST_SEEN" = " codex" ] || [ "$XHOST_SEEN" = " grok" ]; then XHOST_HARNESS="${XHOST_SEEN# }"; XHOST_FAMILY="$XHOST_HARNESS";
+elif [ -n "$XHOST_SEEN" ]; then XHOST_HARNESS=unknown; XHOST_FAMILY=unknown;
+elif [ -n "${CURSOR_AGENT:-}${CURSOR_CONVERSATION_ID:-}" ]; then XHOST_HARNESS=cursor; XHOST_FAMILY=unknown;
+elif [ -n "${OPENCODE_TERMINAL:-}" ]; then XHOST_HARNESS=opencode; XHOST_FAMILY=unknown;
+else XHOST_HARNESS=unknown; XHOST_FAMILY=unknown; fi
+```
+
+Pass `XHOST_HARNESS` as `CROSS_MODEL_HOST_HARNESS`; pass `XHOST_FAMILY` as the first worker argument. The snippet is evidence, not the verdict: it resolves the harnesses whose environment markers it already names, and where it yields `unknown` on a harness you can identify from your own runtime, attest what you know instead. A harness the snippet does not name needs no new branch here. Both tokens must be peer keys the worker accepts, never a provider's company name. Family is `codex`, `claude`, `grok`, `composer`, `gemini`, or `unknown`. Harness is `codex`, `claude`, `grok`, `cursor`, `opencode`, `antigravity`, `omp`, or `unknown`. A company name such as `anthropic`, `openai`, or `xai` in either slot makes the worker refuse the job and write no artifact.
+
+Claude Code, Codex, and Grok each serve their own model family, so the snippet takes the family from that harness's marker when it is the only such marker present. Another harness can copy one of those markers (oh-my-pi sets `CLAUDECODE=1` whatever model serves it), and a session started from inside another harness inherits that harness's marker. So the snippet leaves family `unknown` under `OMPCODE` or when more than one of those markers is present. Pass a family the snippet names. Where it leaves family `unknown`, set it only from a model id the runtime publishes as the model serving this session, and only when that id maps to `codex`, `claude`, `grok`, `composer`, or `gemini`. A requested model, the model's own claim, and the product name are not that id. Never infer serving family from the Cursor brand. An unknown host family cannot pass the automatic same-family check, so skip the automatic cross-model pass.
+
+<!-- ce-config-layers:start -->
+**Resolve ordinary CE yaml keys from the two repo files.**
+
+- **Read** `<repo-root>/.compound-engineering/config.local.yaml`, then `config.yaml` (`<repo-root>` = `git rev-parse --show-toplevel`). Missing files are skipped. Gitignore does not change resolution.
+- **Win** with the first active (non-commented) value. For scalars, empty is unset; an invalid value continues to the next layer, then the skill default. For lists and maps, a present key — including an empty list or map — replaces the whole key.
+- **Do not** use this rule for `docs_root` — that key is `config.yaml` only.
+<!-- ce-config-layers:end -->
+
+**Checkout policy on sending content out — evaluate first.** Read `cross_model_review_mode:` from the same two repo CE config files under the ordinary-key rule. Valid values are `auto` (default) and `off`; anything else is invalid and continues to the next layer, then `auto`. When it resolves to `off`, skip the automatic cross-model pass here, before peer resolution, disclosure, or any job start. The one exception is when the user explicitly asked for a cross-model peer for this run in conversation; a `cross_model_peer` value or a project-instruction preference is not that opt-in. Record the skip reason as **disabled by checkout config**, which is a different reason from an un-attestable host or an unavailable or non-independent route. The in-process `adversarial-reviewer` keeps the lens exactly as it does for any peer that never started. A live user prohibition still overrides `auto`. This pass's skip and target-selection keys are `cross_model_review_mode` and `cross_model_peer`. Missing files or unset keys take the default auto route; they are not a skip. Another skill's engine preference is not this gate. Model and effort overrides stay with the bound target as the reference states.
+
+Resolve the preference in this order:
+
+1. A preference the user **states in conversation** (e.g. "use grok for the cross-model pass").
+2. `cross_model_peer:` from the two repo CE config files (`config.local.yaml` then `config.yaml`). Apply the ordinary-key rule: first active supported target wins; an invalid value continues to the next layer, then step 3.
+3. A preference already in your **project instructions** (the active instructions in your context) — consumed from context, **never** read from a named file.
+4. **Default:** first available attested-different target in `codex → claude → grok → antigravity`. Cursor default and Composer run only when one of steps 1-3 names them.
+
+Before any content is sent, resolve the target to one concrete installed route, announce it, and pass it as `CROSS_MODEL_FIXED_ROUTE`. `CROSS_MODEL_PEERS` is an optional egress restriction, not a required approval. When it is set, every recipient (target and intermediary) must be allowed by it under the alias rule below, and a recipient it does not allow is a named skip. Otherwise, when it is unset or empty, no recipient is filtered and the pass proceeds; invoking this skill plus the disclosure made before sending is the approval. Do not inspect the worker source to rediscover this; it implements exactly this contract. `CROSS_MODEL_FIXED_ROUTE` accepts exactly these tokens. The worker refuses anything else and writes no artifact, including route-shaped guesses like `codex-cli`:
+
+| Target | Route token(s) |
+|--------|----------------|
+| `codex` | `codex` |
+| `claude` | `claude` |
+| `grok` | `grok-cli` (native CLI) or `grok-cursor` (via Cursor intermediary) |
+| `cursor` | `cursor` |
+| `composer` | `composer` |
+| `opencode` | `opencode` |
+| `antigravity` | `antigravity` |
+
+The host harness does not choose the Grok route. Target `grok` binds `grok-cli` when that CLI is installed. Bind `grok-cursor` only when the user asked for Grok through Cursor, or when the grok CLI is absent and Cursor is a sanctioned recipient.
+
+A failed route returns no artifact and never changes provider or intermediary on its own. Retrying the same resolved route retains its existing sanction and disclosure; changing the route or any recipient requires a new resolution, sanction, and disclosure before dispatch. The worker may repeat that same route once only after the route's adapter reports a provider overload (HTTP 529) as the prompt's error kind `overloaded`; it keeps the recipient, model, scope, and shared peer deadline fixed. Today only the Claude adapter reports that form; the other adapters retry overloads internally, so an overload that reaches the worker from them ends as an ordinary failure. For backward compatibility, either `cursor` or `composer` in `CROSS_MODEL_PEERS` sanctions Cursor as an intermediary, but selecting Cursor-default requires target `cursor`; `grok` alone never sanctions Grok-via-Cursor. The Antigravity route is sanctioned only by the literal `antigravity`; `gemini` in `CROSS_MODEL_PEERS` admits nothing.
+
+**Checkout-configured model and effort.** After the target is resolved, read `cross_model_model:` and `cross_model_effort:` from the same two repo CE config files under the ordinary-key rule. When `cross_model_model` is set, pass `CROSS_MODEL_MODEL_OVERRIDE_TARGET=<resolved-target>` and `CROSS_MODEL_MODEL_OVERRIDE=<value>`; when `cross_model_effort` is set, pass `CROSS_MODEL_EFFORT_OVERRIDE=<value>`. Both ride the `env` prefix of the start invocation below. The worker checks each value against the route it actually runs. A model must belong to the resolved target's own family: an alias such as `fable` or a full id such as `claude-opus-5-5` for `claude`; `gpt-*` for `codex`, optionally namespace-qualified such as `openai.gpt-6.1-sol` when that CLI routes through a non-default `model_provider`; `gemini-*` for `antigravity`. An effort must be a level the route's adapter offers; for `antigravity` that is its thinking level, `low`, `medium`, or `high`, and for `opencode` (2.x) it is `none` through `max` as the model lists them. cursor-agent routes accept no effort override. An incompatible value stops the pass with a named skip reason; the worker never substitutes. Unset keys leave the script's editorial mapping unchanged. Announce the configured model and effort in the Step 3 (Announce) line exactly as requested. A model or effort the user states in conversation outranks the config keys.
+
+Preferred mappings run first. Only after an observed unavailable, obsolete, or incompatible model may the host choose the closest compatible same-target/same-family replacement. Bind it with `CROSS_MODEL_MODEL_OVERRIDE_TARGET=<target>` and `CROSS_MODEL_MODEL_OVERRIDE=<model-id>`. Never substitute across families, leak an override to another route, silently change an explicit model, or add a recipient.
+
+Target `antigravity` never takes a host-chosen replacement. Its worker requests Gemini 4 Argon and, when the account does not offer Argon, falls back once to Gemini Flash before any prompt is sent; the run log names the model used. A configured `antigravity` model runs exactly or the pass skips.
+
+## Step 2 — Provider model + reasoning tier (defined in the script)
+
+The peer runs on **one editorially selected model and reasoning tier per provider**. The concrete model IDs and route effort flags live in one mapping in `scripts/cross-model-adversarial-review.sh`; this reference does not repeat them. Claude Opus and Antigravity currently use high; Codex and native Grok use extra-high. The cursor-agent Grok route uses Cursor's high/fast preset, because Cursor offers one preset per model; composer's fast tier is its ceiling. Users choose the peer target, and may pin that target's model and effort through `cross_model_model` / `cross_model_effort` (Step 1); the script validates and never substitutes. Never inherit a harness-configured default model. A lower tier is adopted only after an eval shows it finds the same issues, never from cost alone.
+
+The script always uses the adversarial persona brief; fold-in forces `reviewer` to `adversarial-<provider>`.
+
+## Step 3 — Announce
+
+Invoking ce-code-review is the authorization for the selected, configured, and allowlisted route once this disclosure is made. The announcement is a notice, not a second confirmation prompt. Skip only for an explicit user prohibition, a checkout `cross_model_review_mode: off` without a live opt-in, or an observed scope, allowlist, or route failure. Never skip solely because the user did not separately authorize the external pass in the same prompt.
+
+Pre-dispatch eligibility is based on installed route presence and sanction, not credential state. Do not run authentication probes before the provider-capable launch; authentication is authoritative only after provider-capable dispatch.
+
+- **Interactive host, default mode:** print a **prominent standalone line** that frames it as an **independent cross-model adversarial review** (say "cross-model" / "independent model", not the internal "peer" jargon). The line names the requested **model and reasoning level** from the in-script mapping, and states that reviewed code/diff content is sent to that provider. For cursor-agent routes it names **the route as well as the model**, because two different models can arrive over the *same* `cursor-agent` CLI. **One disclosure condition governs the announce and every later mention of the peer:** name it by target and requested model and effort, as a request ("requested <model> at <effort>"), never as a claim that this model served. Add a serving caveat only when a receipt disagrees with the request, or when the route requested no model (Cursor default/Auto says "serving model unverified"). A receipt-less route with a requested model gets no caveat: `model_actual: unverified` means no receipt, not an unknown model. Place the line with the Stage 3 team announce, not buried after it.
+  - Call the pass **independent** only when host and target serving families are attestably different. For Cursor default/Auto or an unknown host family, call it a cross-harness review and state that independence is unverified; do not promise agreement promotion before the receipt exists.
+  - Announce the one fixed route and every recipient before dispatch. After a failure, apply Step 1's retry/disclosure condition. Reconcile target, harness, route, requested model, and actual model from the artifact.
+- **Interactive host, no peer resolved** (host serving family un-attestable, no different-provider route installed, or disabled by checkout config): one quiet line that the cross-model pass was skipped and why. Name the checkout policy when that is the reason. Never an error.
+- **`mode:agent`:** emit no user-facing prose. The script still writes a one-line stderr audit log per send saying that review content was sent cross-model to the named provider, so the transfer to a third party is auditable. The JSON result still records the peer outcome as `references/modes-and-output.md` defines.
+
+## Step 4 — Start the detached peer job before local dispatch
+
+The script is a CLI shell-out, not a subagent, so it does not consume the subagent concurrency budget. **Never hold a tool call open for the peer's runtime.** Some harnesses kill long tool calls, and a killed call makes the pass vanish silently. At Stage 3d (routing), start it as a **detached, supervised job** through the bundled runner in one short Bash call; the call prints the job id in under about 2s. Only after that call returns may the host finalize the local reviewer roster and enter Stage 4 (dispatch). The detached worker still runs alongside the local reviewers; starting it first prevents the host from also dispatching the in-process adversarial reviewer by mistake.
+
+Before `start`, the orchestrator writes two compact files under `<run-dir>` and never combines their trust domains:
+
+- `adversarial-review-constraints.md` (at most 32 KiB) contains only applicable criteria distilled from the project's active instructions and conventions already in your context. It is additive context for a corroborative peer, not the complete scoped-standards contract; do not load standards solely to expand it. Write `none` when no additional criteria apply. Never copy raw instruction content or user-controlled text into this trusted file.
+- `adversarial-review-brief.md` (at most 32 KiB) is untrusted review data: the Stage 2 intent summary; 2-8 material risk divisions chosen from the current file inventory and diff, each with a one-line reason and representative paths or path prefixes; any explicit generated repetition to cover through generator inputs, manifests, tests, and representative outputs; and any cross-division interaction the adversarial lens must test.
+
+The map is your judgment, not a mechanical directory listing. Do not copy the full file list, diff hunks, or a split by file extension into it. On a simple change, one division is enough. The worker places the constraints and the map in separate prompt regions, each delimited by a nonce; constraint-like text inside the map remains untrusted data. Missing or oversized constraints stop before provider egress so the in-process adversarial fallback retains the lens. The transport preflight only measures the exact diff and stages it outside the prompt; it never cuts semantic shards, and it never chooses or rewrites the orchestrator's divisions.
+
+Invoke via the skill-dir anchor — set `SKILL_DIR` to the absolute directory of **this** skill's `SKILL.md` (the Bash tool's CWD is the user's project, not the skill dir, on every host):
+
+**Interpreter.** The commands below run a bundled Python script. Resolve the
+interpreter in the *same* shell call as the command -- each tool call is a fresh
+shell, so a `$PY` set in an earlier call does not persist. Do not hardcode
+`python3`: on native Windows it resolves to a Microsoft Store stub that exits
+without running Python, and that stub still satisfies `command -v`, so probe
+execution rather than presence.
+
+```bash
+PY="$(for c in python3 python py; do command -v "$c" >/dev/null 2>&1 && "$c" -c '' >/dev/null 2>&1 && { echo "$c"; break; }; done)"; [ -n "$PY" ] || { echo "no working Python 3 interpreter on PATH" >&2; exit 1; };
+```
+
+**Host command-sandbox boundary.** The detached worker inherits the permission context of the `start` call that launches it. Before executing that exact call, treat `CODEX_SANDBOX_NETWORK_DISABLED` as a positive signal that the current Codex command sandbox cannot reach the provider; unsetting it does not change the sandbox policy. A DNS or authentication failure alone is not proof of that condition. Use the narrowest host permission that restores the fixed route's provider connection. When Codex exposes only full command escalation, attach this request to the exact `peer-job-runner.py start ...` tool call after the existing disclosure that reviewed content leaves the machine:
+
+```json
+{
+  "sandbox_permissions": "require_escalated",
+  "justification": "Allow the disclosed read-only cross-model review to send the reviewed diff to the fixed external provider."
+}
+```
+
+Disclose that this is not launcher-only isolation: the detached worker inherits that launch context for its lifetime, so the adapter's declared read-only/tool restrictions, not the Codex command sandbox, are what bound the peer while the reviewed material is sent out. If the grant is denied or unavailable, do not execute `start`; keep the in-process adversarial reviewer as the fallback and create no peer job. After `start` returns a job id, any network, authentication, or provider failure is a started-job outcome and follows the ordinary terminal/recovery rules; keep `status`, `wait`, `result`, and `reap` sandboxed because they need no provider connection.
+
+```bash
+SKILL_DIR="<absolute path of the directory containing the ce-code-review SKILL.md you read>";
+PY="$(for c in python3 python py; do command -v "$c" >/dev/null 2>&1 && "$c" -c '' >/dev/null 2>&1 && { echo "$c"; break; }; done)"; [ -n "$PY" ] || { echo "no working Python 3 interpreter on PATH" >&2; exit 1; };
+echo "peer-deadline-secs=$(( ${CROSS_MODEL_HARD_SECS:-1200} + 10 ))";
+CE_PEER_HARD_SECS= CROSS_MODEL_HOST_HARNESS="<host-harness>" CROSS_MODEL_FIXED_ROUTE="<fixed-route>" "$PY" "$SKILL_DIR/scripts/peer-job-runner.py" start --skill ce-code-review --run-id "<run-id>" --label adversarial -- env CROSS_MODEL_HOST_HARNESS="<host-harness>" CROSS_MODEL_FIXED_ROUTE="<fixed-route>" bash "$SKILL_DIR/scripts/cross-model-adversarial-review.sh" "<host-serving-family>" "<target>" "<base-ref>" "<run-dir>"
+```
+
+When Step 1 resolved a configured model or effort, add `CROSS_MODEL_MODEL_OVERRIDE_TARGET="<target>" CROSS_MODEL_MODEL_OVERRIDE="<model>"` and/or `CROSS_MODEL_EFFORT_OVERRIDE="<effort>"` to the `env` prefix after `CROSS_MODEL_FIXED_ROUTE`; omit them when unset.
+
+The three nested time windows are one budget controlled by one setting (the "knob"), `CROSS_MODEL_HARD_SECS`. The runner derives its supervisor hard window from that ambient knob automatically (`max(1230, knob + 30)`). Clear `CE_PEER_HARD_SECS` on the start prefix (`CE_PEER_HARD_SECS=`) so a stale value left in the environment by an earlier session or a harness export cannot undercut that derivation. An explicit numeric `CE_PEER_HARD_SECS` still wins when a skill deliberately sets one (ce-work / elevation); this path must not set one. Print the orchestrator deadline as `knob + 10` in the same shell as `start` (as above) and use that printed `peer-deadline-secs=<n>` below. Never hardcode it: a literal survives a knob change and then reaps a healthy peer.
+
+**Do not forward `CROSS_MODEL_HARD_SECS` to the worker.** The runner already passes the ambient environment through, so a knob the user actually set reaches the worker on its own. Re-exporting the orchestrator's *resolved* value would turn a fallback into an explicit override and strip the worker of its own default.
+
+- `<run-id>` = the Stage 1b run id (the same one that forms `<run-dir>`); job state lives under `<run-dir>/jobs/<job-id>/`.
+- `<host-serving-family>` is `codex`, `claude`, `grok`, `composer`, `gemini`, or `unknown`; `<host-harness>` is `codex`, `claude`, `grok`, `cursor`, `opencode`, `antigravity`, `omp`, or `unknown`.
+- `<target>` is one of `codex`, `claude`, `grok`, `cursor`, `composer`, `opencode`, or `antigravity`; `<fixed-route>` is its already-sanctioned concrete route token from the Step 1 table (`codex`, `claude`, `grok-cli`, `grok-cursor`, `cursor`, `composer`, `opencode`, or `antigravity`).
+- `<base-ref>` = the Stage 1 `BASE` (the diff base the peer reviews via `git diff <base-ref>`).
+- `<run-dir>` = the absolute Stage 4 run dir. The script writes `adversarial-<provider>.json` there **only after** forcing `reviewer` to `adversarial-<provider>` and downgrading peer `safe_auto` → `gated_auto`.
+
+Every persisted job id remains a lifecycle obligation until its worker is terminal and its job directory is deleted before the skill returns. The normal review path meets that obligation through the single-reap finish and fold-in below. If the local workflow cannot continue to fold-in, reap the peer promptly, perform the final `wait --max-secs 10` because reap is asynchronous, and delete its job directory without reading or folding the result or attempting route recovery.
+
+**Single-reap finish.** The runner detaches the worker into its own supervised session. Capture the epoch time right after `start` (`date +%s`) and do not poll while local reviewers are active. After local returns are collected, check status once. If the job is still running, issue bounded `wait` slices until the job is terminal **or** the shared deadline (`peer-deadline-secs` from the `start` call; 1210s by default) has elapsed since `start`. Compare `date +%s` against the captured start time before each slice, and never begin a slice that would cross the deadline. Size each slice at up to 480s (Luna xhigh runs can legitimately take up to ~419s, so a shorter slice can end before a healthy peer returns), and let the slices repeat: one slice is far shorter than the derived deadline, so capping the *total* wait would reap a healthy peer for exactly the reason this budget was widened. A slice is not a polling turn. Do not interleave status reads, shell no-ops, or "still waiting" turns between slices. Fold in the artifact when the job is terminal. At the deadline, `reap <job-id>` and perform one final `wait --max-secs 10` because reap is asynchronous. The script limits its own runtime (idle timeout 480s; hard backstop `CROSS_MODEL_HARD_SECS`, default 1200s) *inside* that deadline, so reaping at the deadline is the exception. Done is detected by the file's presence: the worker publishes `<run-dir>/adversarial-<provider>.json` only after normalization. The script reads the persona brief and schema from the skill dir and reviews the current work tree against `<base-ref>`. Its large-diff preflight is transport only: it measures the exact diff and stages it outside the prompt; the orchestrator chooses the semantic divisions, and the reviewer chooses representatives and evidence within them.
+
+The job ID that `start` returns is the proof that the start succeeded. Do not immediately call `status`, inspect `--help`, or otherwise verify it; persist it and continue to local dispatch. Status collection begins only after the local wave completes.
+
+The commands in this reference are the executable contract. Do not inspect or grep the worker script for its model mapping or allowlist, run `CROSS_MODEL_DRY_RUN`, call `--emit-adapter`, or probe runner `--help` before dispatch. Those exploratory calls only replay host context and cannot strengthen the route the runner enforces.
+
+After local reviewers complete, the one status read is exactly:
+
+```bash
+SKILL_DIR="<absolute path of the directory containing the SKILL.md you just read>";
+PY="$(for c in python3 python py; do command -v "$c" >/dev/null 2>&1 && "$c" -c '' >/dev/null 2>&1 && { echo "$c"; break; }; done)"; [ -n "$PY" ] || { echo "no working Python 3 interpreter on PATH" >&2; exit 1; };
+"$PY" "$SKILL_DIR/scripts/peer-job-runner.py" status "<job-id>" --json
+```
+
+If it is still running and time remains, each `wait` slice is exactly:
+
+```bash
+SKILL_DIR="<absolute path of the directory containing the SKILL.md you just read>";
+PY="$(for c in python3 python py; do command -v "$c" >/dev/null 2>&1 && "$c" -c '' >/dev/null 2>&1 && { echo "$c"; break; }; done)"; [ -n "$PY" ] || { echo "no working Python 3 interpreter on PATH" >&2; exit 1; };
+"$PY" "$SKILL_DIR/scripts/peer-job-runner.py" wait --max-secs <remaining-slice-secs> --json "<job-id>"
+```
+
+Repeat that call until the job is terminal or the derived deadline is spent; do not invent alternate status flags or inspect help.
+
+## Step 5 — Fold into Stage 5
+
+- Read the artifact through the runner's verified read (resolve `$PY` in the same tool call — shells do not persist):
+
+  ```bash
+  SKILL_DIR="<absolute path of the directory containing the SKILL.md you just read>";
+  PY="$(for c in python3 python py; do command -v "$c" >/dev/null 2>&1 && "$c" -c '' >/dev/null 2>&1 && { echo "$c"; break; }; done)"; [ -n "$PY" ] || { echo "no working Python 3 interpreter on PATH" >&2; exit 1; };
+  "$PY" "$SKILL_DIR/scripts/peer-job-runner.py" result "<job-id>" --path <run-dir>/adversarial-<target>.json
+  ```
+
+  The runner checks that it owns the file descriptor and bounds the read. Exit 0 emits the artifact. Exit 2 means the job is still running, so the deadline loop above was left early; return to it rather than classifying. Exit 3 is the only outcome that means the peer produced nothing; it names the job's state, and at that point read `references/cross-model-recovery.md` and follow the branch that matches that state, since it alone owns what happens when the peer yielded no usable artifact. Any other exit means the runner could not complete the read: a trust failure on the artifact or on the job's own state, or a job id that did not resolve. None of those has a recovery branch. Name the failure in Coverage as a degraded cross-model pass, and never fold it into the clean skip.
+
+  Its findings enter ordinary dedup, but agreement promotion is allowed **only when `independence_verified` is `true`**. A false or absent value may contribute findings but never raises confidence. `independence_verified` attests a different serving family; it does not claim the exact served model was verified. `receipt_supported`, `model_actual`, and `effort_actual` carry that separate identity evidence. Peer findings never grant silent-apply authority.
+- In final Coverage, name `cross_model_route`, `model_requested`, `effort_requested`, `receipt_supported`, `model_actual`, `effort_actual`, and `independence_verified` from the artifact. Keep the literal `unverified`; never compress a request into a serving claim such as "via Codex high" when actual model or effort is unverified. The disclosure condition above decides how the peer is named in the report.
+- **Never started / not run** — the job was never started (run conditions not met, disabled by checkout config, host un-attestable, no different-provider route installed, or CLI missing): the pass simply didn't run. Note "cross-model pass: not run" in Coverage for human-facing markdown — or "cross-model pass: disabled by checkout config" when Step 1's checkout policy was the reason. In `mode:agent`, do not announce the skip; the JSON result records it as `references/modes-and-output.md` defines. Ignore any `*.raw.json` leftovers — they are not fold-in artifacts.
+- Empty `findings` → note "cross-model pass: no additional issues" in Coverage.
+- After fold-in (or after deadline reaping), delete the consumed job directory (`<run-dir>/jobs/<job-id>/`). Its log and result are review content and must not outlive their use.
+- A finding sharing a fingerprint with in-process `adversarial` promotes only when the artifact records `independence_verified: true`. Cursor-default artifacts default false; an unattested host skips automatic dispatch.

package/skills/ce-code-review/references/depth-paths.md

@@ -0,0 +1,32 @@
+# Lite and focused paths
+
+Read this only when the Review depth gate in `references/modes-and-output.md` selected lite or focused; a full run never opens it. Both paths finish in the dispatch context and write the same receipt shape that reference defines.
+
+### Lite path
+
+Lite is the same review with the same receipt, done in this context. Do not dispatch reviewers or finish leaves. Read no reference beyond the two named below. The skill's done condition applies unchanged: every retained finding is supported by the source, and the receipt states its coverage limits.
+
+Produce, in this context:
+
+- Correctness findings on the diff. The diff shows each file in `deleted_files` as a header only; for each one, check that nothing in the surviving tree still uses it. Static imports are not the only readers: also look for references by string (asset paths, config and plugin names), routes resolved from file names, and registrations the file made when it was imported. A deleted test is a separate question: whether the code it tested still ships. A finding that a deleted file is still used quotes the surviving line that uses it as its evidence. Read a body with `git show <base>:<path>` from the Stage 1 base (`PR_BASE_REF` in `pr-remote`) only when the check needs it. Every lite finding carries the merged finding fields the output format lists, with severity, `autofix_class`, and `owner` set by `references/action-class-rubric.md` (read it before writing a finding). A lite finding quotes its motivating line as `first_evidence` and carries confidence `100` when the defect is mechanical or `75` when it names a concrete consequence; a concern you cannot quote goes to `residual_risks`, not `findings`.
+- Criteria findings from the Stage 1c mapping: read each governing criteria file, judge every changed file only against the criteria paired with it, and report a changed line that contradicts a written rule as a finding that quotes the rule and names its file.
+- Requirements verification: read the Plan Requirements Completeness and Stage 2b sections of `references/intent-and-plan.md`, discover a plan by that contract (the `plan:` argument, the PR body, or the branch), and when one is found fill `requirements_completeness`. An unaddressed requirement or unit is a finding routed by `plan_source` under that section's rule, so an explicit-plan omission reaches `actionable_findings`; it also makes the verdict Not ready unless the omission is intentional.
+- Test sufficiency: when the change alters runtime behavior without corresponding test work, record the gap in `testing_gaps`. Risks you can see but cannot settle go in `residual_risks`.
+
+Coverage states that the lite path ran and no reviewer agents were dispatched; names the criteria files checked, or that none govern the change, and the instruction-file fallback when it supplied criteria; states that declared Compound Packs were not applied; and names what lite did not assess (learnings, agent-native gaps, deployment notes).
+
+Write the receipt and `metadata.json` (## Run artifacts in `references/modes-and-output.md`) into the run directory Stage 1b created, then record `--end review --start receipt --candidates <count of findings you retained from your own read>` and, once `metadata.json` is on disk, `--end receipt` followed by `summarize` as that section states, and emit the receipt as the response. In `mode:agent`, the receipt is the JSON object the JSON output format in `references/modes-and-output.md` defines, written to `review.json`. In default mode, it is every retained finding (stable `#`, severity, `file:line`, route), then Actionable Findings, Coverage, and Verdict, written to `report.md`; a retained finding that is not actionable still appears in the findings list.
+
+That receipt is the last thing this skill writes. The focused path writes it the same way. It ends this skill, not the turn. When a caller invoked this skill, the caller runs in this same session, and its next step follows the receipt; otherwise end the turn.
+
+### Focused path
+
+Focused is the lite review plus one independent adversarial read of the same diff, merged in this context. It exists for a change that can fail silently but does not need the full roster: the defects it targets are the ones a second, differently-seated reader finds and a single reader rationalizes away. No finish leaves run; the round is small enough to finish where it was dispatched.
+
+Do the lite path's four pieces of work above, in this context, and additionally read the Stage 2 section of `references/intent-and-plan.md` and write the intent summary, because the independent read needs it. In default mode, tell the user the review is focused and that one independent adversarial read will run; in `mode:agent` the receipt is the only output.
+
+**The independent read.** The Review depth gate's silent-consequence decision is the adversarial selection this run makes; no roster stage runs. Where the reviewed tree is local (standalone, `base:`, or `local-aligned` scope), read `references/cross-model-review.md` in full and run its Steps 1 through 4 to start the peer, then its Step 5 to fold the artifact in, with the run directory Stage 1c created. Start the peer before doing your own review so the two overlap, recording `--start peer` in the same shell call as the start; wait for it afterwards exactly as that reference's single-reap finish states, and record `--end peer --candidates <count of findings in its artifact, or 0 when it produced none>` when its artifact is folded or its outcome classified. The focused path needs one usable independent read: the peer is the only independent read on this path, unlike the full path where other reviewers still cover the change when the peer yields nothing. When the peer route does not produce a usable review artifact, for any reason that reference or its recovery branches in `references/cross-model-recovery.md` name, or when scope is `pr-remote` or `branch-remote`, read `references/dispatch-reviewers.md` and dispatch exactly one local `adversarial-reviewer` by its Spawning rules, collected in this turn; when that fallback also fails, the receipt's verdict is Not ready and Coverage says the adversarial lens did not run. One read covers the lens; never run both on the same brief.
+
+**Merging the two reads.** Your own findings keep the lite confidence rule. A finding the independent read returns is retained when you can quote its motivating line from the source as `first_evidence`; one you cannot quote goes to `residual_risks` with its reviewer named. A finding both reads made is one finding with both reviewers listed; it promotes one confidence level only when the peer artifact records `independence_verified: true`. A local `adversarial-reviewer` is a separately dispatched context, so agreement with it is corroboration, but from the same serving family: it never counts as cross-model, and Coverage says which it was. No validator batch runs on this path; a P0 or P1 that only one read found carries `requires_verification: true` and says so in its detail line.
+
+Coverage states that the focused path ran, which independent read covered the adversarial lens (the peer with its receipt fields named as that reference's Step 5 lists them, or the local fallback and why), that no other reviewer agents were dispatched and no validator ran, and everything the lite path's Coverage states. `reviewers` is `["correctness", "adversarial-<provider>"]` for a peer or `["correctness", "adversarial"]` for the local fallback; `coverage.depth` is `"focused"`. Write the receipt and `metadata.json` as lite does, and delete the consumed peer job directory before returning.

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

@@ -0,0 +1,59 @@
+# 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 any file that belongs to the reviewed tree — the changed-file list, and any other file the review points you at, such as a criteria file. They may not match the branch or PR under review, and an unchanged file is not exempt: the checkout can hold a version the reviewed head never had.
+
+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.
+
+## Whole-file deletions
+
+A file the change deletes appears in the diff as a header only: `deleted file mode` and its path. Its old body is left out. The `<deleted-files>` block in your review context lists each one with what it exported and whether it ran anything at import time. Read a body only when a finding needs it, with `git show <base>:<path>` against the base that block names.
+
+Whether the surviving tree still uses a deleted file is the correctness and adversarial reviewers' question; their personas say what to check. That check needs the reviewed tree, and a body needs the base the block names. When you cannot read one of them (for example, remote scope with no head ref, or a block with no base), record in `residual_risks` which deleted files went unchecked and why; never report their liveness as checked. Every other reviewer reviews the files that survive, including what the deletion left behind there: imports, props, styles, flags, and assets that no longer have a reader. The body of a deleted file is not code to review.
+
+## Evidence Tools (tool-adaptive)
+
+Recall depends on how you find related code. A diff-local read plus a text `grep` misses callers reached through re-exports, aliases, and barrel files, and mis-hits identifiers inside strings, comments, or longer names. When a claim depends on a symbol's callers, implementations, or whether a construct appears elsewhere, use the strongest search your harness actually exposes, preferring in this order and falling through when a tier is unavailable:
+
+1. **Symbol-aware search** — a references/definitions/implementations capability (LSP or an equivalent MCP tool) that follows renames, re-exports, and barrels text search cannot. Most reviewer harnesses do not expose one; when it is absent, drop to the next tier without ceremony.
+2. **Structural (AST) search** — a syntax-tree matcher such as `ast-grep` (optional; may not be installed). For "does construct X occur elsewhere" it beats regex: it matches the parsed tree, ignoring formatting and skipping the string/comment hits `grep` reports as false positives.
+3. **Text search (`grep`)** — always available; correct for genuinely lexical checks (config keys, string literals, log messages), and the fallback when the tiers above are not reachable.
+
+No tool is complete: dynamic dispatch, reflection, dependency injection, string-keyed routes/config, generated code, and external consumers hide usages from all of them. This only bites a claim that rests on *exhaustive* coverage — "this symbol is unused," "nothing else calls this," "safe to change." For such a claim, when coverage is text-search-only or a hiding construct could apply, record the unresolved boundary in `residual_risks` (e.g. `callsite completeness: grep-only`) or step the finding down, rather than asserting absence or safety. A finding that does not turn on exhaustive coverage needs no such note.
+
+In `pr-remote` / `branch-remote` scope these tiers inspect the working tree, which is not the reviewed head — apply the Remote scope rules above (`git show` / `git grep <remote-head-ref>`) instead of local search.
+
+## 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. When history is what makes the pre-existing call, attach one concise provenance evidence line from targeted blame/log (see the line provenance rule in `subagent-template.md`).
+
+**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.