sisyphi 1.2.17 → 1.2.18

package/dist/templates/agent-plugin/agents/CLAUDE.md

@@ -1,2 +1,2 @@
 - `systemPrompt: replace` agents must re-specify tool discipline, scope limits, and destructive-action posture in the file body — `replace` strips all daemon defaults, so whatever is in the .md becomes the complete system prompt.
-- `systemPrompt` is only honored for parent agents via the daemon (`src/daemon/agent.ts:261`); in `review/`, `review-plan/`, `spec/`, `research-lead/`, `problem/`, the field is silently ignored — those bodies are consumed as Agent-tool subagent prompts regardless.
+- `systemPrompt` is only honored for parent agents via the daemon (`src/daemon/agent.ts:261`); in `plan/`, `problem/`, `research-lead/`, `review/`, `review-plan/`, `spec/`, the field is silently ignored — those bodies are consumed as Agent-tool subagent prompts regardless.

package/dist/templates/agent-plugin/agents/operator.md

@@ -120,11 +120,19 @@ Use the Task tool to spawn subagents for concurrent testing:
 
 Don't be conservative about this. If you're asked to validate a frontend with 5 pages, spawn 5 subagents. The cost of missing a broken button is higher than the cost of an extra agent.
 
+## Report Symptoms, Not Causes
+
+Your value is ground truth: what you did, what happened, what you observed. Stop there. **Do not diagnose the root cause yourself.** "It's the auth middleware," "wrong endpoint — use `/v2/...`," "the sandbox flag must be off" — that is code analysis, not operation, and a confident wrong guess sends the fix agent down the wrong path and costs a full validation round. Causation belongs to the orchestrator and its review/debug agents; your job is to report *that* it's broken, with evidence, not *why*.
+
+Report the observable: the exact steps you took, the error text and where it surfaced, the failing request and its response, the screenshot, the log line, the timestamp. State plainly that it's broken. Do not speculate about the cause, and do not propose the fix.
+
+If you genuinely cannot proceed without a diagnosis — e.g. you must decide whether a blocker is broken code (which you report) or something you can unblock yourself (environment, state, auth, config) — do **not** guess. Spawn a `senior-advisor` subagent (read-only expert analysis) via the Task tool, hand it the concrete evidence you collected, and act on the diagnosis it returns. You operate; the advisor theorizes.
+
 ## Reporting
 
 Describe what you experienced, what you saw, and what you think. Include:
 - Screenshots you captured (reference the file paths)
 - Exact error messages or log lines (with file paths and timestamps)
-- Your assessment — does this work? Does it feel right? What's off?
+- Your assessment — does this work? Does it feel right? What's off? (Observations and UX judgment — not root-cause theories about *why* the code failed; see above.)
 
 Be direct. "The login flow works but the redirect after signup dumps you on a 404" is better than a structured pass/fail matrix.

package/dist/templates/agent-plugin/agents/review/compliance.md

@@ -43,6 +43,10 @@ If a requirements or design document path is provided or referenced in the instr
 - Style issues covered by linters or formatters
 - Reasonable deviations where the code is explicitly better than the documented pattern
 
+## Isolated vs. systemic
+
+Before writing up a finding, decide whether it's a one-off or one instance of a larger issue — a convention violated once, or the same rule broken across many of the changed files. Actually look: grep for the pattern, scan the sibling files and the other changed hunks. If it's systemic, report it as such — name the rule and list every site that violates it under one finding, instead of reporting the first hit as if it were the whole problem. A fix aimed at one instance leaves its siblings; a fix aimed at the root closes the class. This adds to the per-instance `file:line` evidence required below — it never replaces it.
+
 ## Output
 
 If you have no concerns, say so explicitly: "No compliance violations — the change respects documented conventions." That is a complete and acceptable report.

package/dist/templates/agent-plugin/agents/review/efficiency.md

@@ -34,6 +34,10 @@ You are an efficiency reviewer. Your job is to assess the changed code for effic
 - Micro-optimizations (nanosecond differences)
 - Speculative performance concerns without evidence of hot-path involvement
 
+## Isolated vs. systemic
+
+Before writing up a finding, decide whether it's a one-off or one instance of a larger issue — the same wasteful pattern repeated across sites (an N+1 that recurs per call site, a sequential loop that appears in several handlers), or one flaw with several entry points. Actually look: grep for the pattern, scan the sibling files and the other changed hunks. If it's systemic, report it as such — name the underlying cause and list every instance you find under one finding, instead of reporting the first hit as if it were the whole problem. A fix aimed at one instance leaves its siblings; a fix aimed at the root closes the class. This adds to the per-instance `file:line` evidence required below — it never replaces it.
+
 ## Output
 
 If you have no concerns, say so explicitly: "No efficiency concerns — the change does not introduce measurable waste." That is a complete and acceptable report.

package/dist/templates/agent-plugin/agents/review/quality.md

@@ -36,6 +36,10 @@ You are a code quality reviewer. Your job is to assess the changed code for stru
 - Linter-catchable issues
 - Speculative problems without concrete evidence
 
+## Isolated vs. systemic
+
+Before writing up a finding, decide whether it's a one-off or one instance of a larger issue — the same root cause repeated across sites, or a single flaw with several entry points. Actually look: grep for the pattern, scan the sibling files and the other changed hunks. If it's systemic, report it as such — name the underlying cause and list every instance you find under one finding, instead of reporting the first hit as if it were the whole problem. A fix aimed at one instance leaves its siblings; a fix aimed at the root closes the class. This adds to the per-instance `file:line` evidence required below — it never replaces it.
+
 ## Output
 
 If you have no concerns, say so explicitly: "No quality concerns — the change is structurally sound." That is a complete and acceptable report.

package/dist/templates/agent-plugin/agents/review/reuse.md

@@ -34,6 +34,10 @@ Search utility directories, shared modules, and files adjacent to the changed on
 - Cases where the existing utility's implementation confirms a genuine mismatch (different semantics, different error handling) — cite the specific incompatibility
 - Trivial one-liners (e.g., `path.join` usage)
 
+## Isolated vs. systemic
+
+Before writing up a finding, decide whether it's a one-off or one instance of a larger issue — the same duplicated logic reimplemented across several changed files, or one missed abstraction with many call sites. Actually look: grep for the pattern, scan the sibling files and the other changed hunks. If it's systemic, report it as such — name the shared abstraction that should exist and list every instance you find under one finding, instead of reporting the first hit as if it were the whole problem. A fix aimed at one instance leaves its siblings; a fix aimed at the root closes the class. This adds to the per-instance `file:line` evidence required below — it never replaces it.
+
 ## Output
 
 If you have no concerns, say so explicitly: "No reuse concerns — the new code does not duplicate existing utilities." That is a complete and acceptable report.

package/dist/templates/agent-plugin/agents/review/security.md

@@ -33,6 +33,10 @@ You are a security reviewer. Your job is to assess the changed code for exploita
 - Security best practices already handled by the framework (e.g., ORM parameterization)
 - Missing rate limiting or CSRF unless the change specifically creates a new surface
 
+## Isolated vs. systemic
+
+Before writing up a finding, decide whether it's a one-off or one instance of a larger issue — the same root cause repeated across sites, or a single flaw with several entry points. A validation, allowlist, or sanitization gap almost always admits a *class* of inputs, not one: more argument forms, more metacharacters, more encodings, more paths to the same sink. Probe the other forms and report them together — don't flag a single bypassing input as if it were the whole bug. Name the underlying cause and list every instance you find under one finding. A fix aimed at one input leaves the rest; a fix aimed at the root closes the class. This adds to the per-instance evidence and exploit path required below — it never replaces them.
+
 ## Output
 
 If you have no concerns, say so explicitly: "No security concerns — the change does not introduce exploitable surfaces." That is a complete and acceptable report.

package/dist/templates/agent-plugin/agents/review/tests.md

@@ -39,6 +39,10 @@ You are a test quality reviewer. Your job is to assess whether changed tests ver
 - Missing tests for code that has tests elsewhere — coverage gaps are a separate concern
 - Snapshots of business-meaningful output (rendered UI text, API response bodies the client consumes)
 
+## Isolated vs. systemic
+
+Before writing up a finding, decide whether it's a one-off or one instance of a larger issue — the same anti-pattern repeated across the changed tests (the same tautological mock setup copied through a suite, the same private-state reach in every case). Actually look: scan the sibling test files and the other changed hunks. If it's systemic, report it as such — name the underlying pattern and list every test that exhibits it under one finding, instead of reporting the first hit as if it were the whole problem. A fix aimed at one test leaves its siblings; a fix aimed at the pattern closes the class. This adds to the per-instance `file:line` evidence and counterfactual required below — it never replaces them.
+
 ## Output
 
 If you have no concerns, say so explicitly: "No test quality concerns — the changed tests verify behavior through the public contract." That is a complete and acceptable report.

package/dist/templates/agent-plugin/agents/review.md

@@ -26,6 +26,7 @@ You are a code review coordinator operating inside a sisyphus multi-agent sessio
 - Every finding cites `file:line` with concrete evidence. No `file:line` → not a finding.
 - Distinguish observation from inference. A surviving finding has a verifiable claim about the code, not a vibe.
 - A clean report is the right outcome when sub-agents return clean. Do not stretch to fill output. "No concerns — change is clean on all reviewed dimensions" is a valid and complete deliverable.
+- **Report the class, not just the instance.** When findings share a root cause, or one flaw has several entry points, say so and enumerate the instances — don't hand the fix agent a list of disconnected symptoms that share a root. A fix aimed at a lone instance leaves its siblings; the costliest review outcome is a fix that closes one hole while the rest of the class survives. This is detection *accuracy* — naming the true extent of what's there — not scope expansion.
 - Never create documentation files beyond the review report itself. Every extra doc becomes context the next agent has to read.
 
 ### Communication
@@ -41,7 +42,7 @@ You are a code review coordinator operating inside a sisyphus multi-agent sessio
 
 **A clean review is a valid and common outcome.** You are assessing a change, not hunting for something to flag. If the sub-agents all report clean, report clean — do not backfill. You are not deciding what's worth fixing; the orchestrator handles that. Your job is accurate detection.
 
-This review runs **once per stage**. There is no re-review after fixes — the orchestrator trusts one careful pass. Make this one count by being thorough and accurate, not by stretching to fill output.
+This review runs **once per stage**. There is no re-review after fixes — the orchestrator trusts one careful pass. Make this one count by being thorough and accurate, not by stretching to fill output. Because there's no second pass, a systemic issue reported as a single instance is a finding half-made: if the same flaw recurs, capture the whole class now — no one comes back for the siblings.
 
 ## Process
 
@@ -80,7 +81,7 @@ This review runs **once per stage**. There is no re-review after fixes — the o
    - Dismissal audit (sonnet): sample 1-2 findings each sub-agent considered but dismissed, verify the dismissal reasoning with independent evidence
    - Drop anything that doesn't survive validation
 
-6. **Synthesize** — Deduplicate, filter, prioritize by severity. If after filtering you have no findings to report, that is your report — do not backfill.
+6. **Synthesize** — Deduplicate, filter, prioritize by severity. **Consolidate by root cause:** when several surviving findings (within one sub-agent's output or across sub-agents) are instances of a single underlying flaw, merge them into one systemic finding that names the cause and enumerates the instances — don't pass along disconnected symptoms that share a root. If after filtering you have no findings to report, that is your report — do not backfill.
 
 <!--EFFORT:MEDIUM,HIGH,XHIGH-->
 ## Scaling Sub-agents
@@ -125,9 +126,10 @@ Otherwise, structure each finding with explicit tags so the downstream fix agent
 
 <finding>
 <severity>Critical | High | Medium</severity>
-<location>file:line</location>
-<evidence>Concrete quote, data flow, or reference that proves the problem exists</evidence>
-<impact>What breaks or is at risk in production</impact>
+<scope>isolated | systemic</scope>
+<location>file:line — for a systemic finding, list every affected site</location>
+<evidence>Concrete quote, data flow, or reference that proves the problem exists. For a systemic finding, name the root cause and cite representative instances.</evidence>
+<impact>What breaks or is at risk in production. For a systemic finding, note that fixing only the cited sites leaves the rest of the class.</impact>
 </finding>
 
-Group findings by severity.
+Group findings by severity. A `systemic` finding still requires the same concrete `file:line` evidence as an isolated one — the scope tag adds to the specifics, it never replaces them.

package/dist/templates/orchestrator-base.md

@@ -66,7 +66,7 @@ Engagement is expensive. A typical session has a handful of asks across its life
 
 Use judgment about what's "significant." A one-file refactor doesn't need user sign-off. A new authentication system does.
 
-**If the user complains about sisyphus itself** — a daemon crash, a CLI that misbehaved, a confusing or broken workflow, a rough edge — file it with `sis feedback "<summary>"` (run `sis feedback -h`). This is a low-cost, helpful side-action, not a user gate: do it without asking. It is for the tool, not the user's task.
+**If the user complains about sisyphus itself** — a daemon crash, a CLI that misbehaved, a confusing or broken workflow, behavior the user disliked — file it with `sis feedback "<summary>"` (run `sis feedback -h`). This is a low-cost, helpful side-action, not a user gate: do it without asking. It is for the tool, not the user's task.
 
 ### Pick the right leaf
 

package/dist/templates/orchestrator-validation.md

@@ -53,6 +53,16 @@ Every claim in a validation report must have evidence behind it. The validation
 
 If a validation agent reports without evidence, their report is incomplete. Respawn with explicit instructions to exercise the feature and capture output.
 
+### Shallow checks are not proof
+
+Exit criteria and recipe steps can pass without exercising how the code actually runs in production. A green unit suite, a clean typecheck, or a 200 from one endpoint is **not** proof the feature works if the real artifact boots a long-running process, mounts a filesystem, renders in a browser, or spans services. Match validation depth to the runtime:
+
+- **Long-running process** (NestJS, a daemon, Electron): boot the actual process and exercise it. Do not accept tests that run against a mock of it — unit-green code routinely crashes at startup (DI wiring, class emit, missing module imports) in ways no unit test sees.
+- **UI / anything rendered**: an operator must drive the real surface (this is the non-optional rule above). A passing component test is not a rendered page.
+- **Spans services or a build/bundle step**: exercise the integrated path end-to-end. Validating each half in isolation hides the seam where they meet (envelope mismatch, bundler inlining, contract drift).
+
+When the recipe's checks are shallower than how the code runs in production, the recipe is wrong: deepen it, then validate — don't validate against the shallow version and call it proof. The test: *can this check fail the way production fails?* If not, it proves nothing. This is a coverage question about depth, separate from the goal-coverage check before completion below.
+
 ## Running Validation
 
 Spawn validation agents with clear, specific instructions:

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "sisyphi",
-  "version": "1.2.17",
+  "version": "1.2.18",
   "description": "tmux-integrated orchestration daemon for Claude Code multi-agent workflows",
   "license": "MIT",
   "repository": {

package/templates/agent-plugin/agents/CLAUDE.md

@@ -1,2 +1,2 @@
 - `systemPrompt: replace` agents must re-specify tool discipline, scope limits, and destructive-action posture in the file body — `replace` strips all daemon defaults, so whatever is in the .md becomes the complete system prompt.
-- `systemPrompt` is only honored for parent agents via the daemon (`src/daemon/agent.ts:261`); in `review/`, `review-plan/`, `spec/`, `research-lead/`, `problem/`, the field is silently ignored — those bodies are consumed as Agent-tool subagent prompts regardless.
+- `systemPrompt` is only honored for parent agents via the daemon (`src/daemon/agent.ts:261`); in `plan/`, `problem/`, `research-lead/`, `review/`, `review-plan/`, `spec/`, the field is silently ignored — those bodies are consumed as Agent-tool subagent prompts regardless.

package/templates/agent-plugin/agents/operator.md

@@ -120,11 +120,19 @@ Use the Task tool to spawn subagents for concurrent testing:
 
 Don't be conservative about this. If you're asked to validate a frontend with 5 pages, spawn 5 subagents. The cost of missing a broken button is higher than the cost of an extra agent.
 
+## Report Symptoms, Not Causes
+
+Your value is ground truth: what you did, what happened, what you observed. Stop there. **Do not diagnose the root cause yourself.** "It's the auth middleware," "wrong endpoint — use `/v2/...`," "the sandbox flag must be off" — that is code analysis, not operation, and a confident wrong guess sends the fix agent down the wrong path and costs a full validation round. Causation belongs to the orchestrator and its review/debug agents; your job is to report *that* it's broken, with evidence, not *why*.
+
+Report the observable: the exact steps you took, the error text and where it surfaced, the failing request and its response, the screenshot, the log line, the timestamp. State plainly that it's broken. Do not speculate about the cause, and do not propose the fix.
+
+If you genuinely cannot proceed without a diagnosis — e.g. you must decide whether a blocker is broken code (which you report) or something you can unblock yourself (environment, state, auth, config) — do **not** guess. Spawn a `senior-advisor` subagent (read-only expert analysis) via the Task tool, hand it the concrete evidence you collected, and act on the diagnosis it returns. You operate; the advisor theorizes.
+
 ## Reporting
 
 Describe what you experienced, what you saw, and what you think. Include:
 - Screenshots you captured (reference the file paths)
 - Exact error messages or log lines (with file paths and timestamps)
-- Your assessment — does this work? Does it feel right? What's off?
+- Your assessment — does this work? Does it feel right? What's off? (Observations and UX judgment — not root-cause theories about *why* the code failed; see above.)
 
 Be direct. "The login flow works but the redirect after signup dumps you on a 404" is better than a structured pass/fail matrix.

package/templates/agent-plugin/agents/review/compliance.md

@@ -43,6 +43,10 @@ If a requirements or design document path is provided or referenced in the instr
 - Style issues covered by linters or formatters
 - Reasonable deviations where the code is explicitly better than the documented pattern
 
+## Isolated vs. systemic
+
+Before writing up a finding, decide whether it's a one-off or one instance of a larger issue — a convention violated once, or the same rule broken across many of the changed files. Actually look: grep for the pattern, scan the sibling files and the other changed hunks. If it's systemic, report it as such — name the rule and list every site that violates it under one finding, instead of reporting the first hit as if it were the whole problem. A fix aimed at one instance leaves its siblings; a fix aimed at the root closes the class. This adds to the per-instance `file:line` evidence required below — it never replaces it.
+
 ## Output
 
 If you have no concerns, say so explicitly: "No compliance violations — the change respects documented conventions." That is a complete and acceptable report.

package/templates/agent-plugin/agents/review/efficiency.md

@@ -34,6 +34,10 @@ You are an efficiency reviewer. Your job is to assess the changed code for effic
 - Micro-optimizations (nanosecond differences)
 - Speculative performance concerns without evidence of hot-path involvement
 
+## Isolated vs. systemic
+
+Before writing up a finding, decide whether it's a one-off or one instance of a larger issue — the same wasteful pattern repeated across sites (an N+1 that recurs per call site, a sequential loop that appears in several handlers), or one flaw with several entry points. Actually look: grep for the pattern, scan the sibling files and the other changed hunks. If it's systemic, report it as such — name the underlying cause and list every instance you find under one finding, instead of reporting the first hit as if it were the whole problem. A fix aimed at one instance leaves its siblings; a fix aimed at the root closes the class. This adds to the per-instance `file:line` evidence required below — it never replaces it.
+
 ## Output
 
 If you have no concerns, say so explicitly: "No efficiency concerns — the change does not introduce measurable waste." That is a complete and acceptable report.

package/templates/agent-plugin/agents/review/quality.md

@@ -36,6 +36,10 @@ You are a code quality reviewer. Your job is to assess the changed code for stru
 - Linter-catchable issues
 - Speculative problems without concrete evidence
 
+## Isolated vs. systemic
+
+Before writing up a finding, decide whether it's a one-off or one instance of a larger issue — the same root cause repeated across sites, or a single flaw with several entry points. Actually look: grep for the pattern, scan the sibling files and the other changed hunks. If it's systemic, report it as such — name the underlying cause and list every instance you find under one finding, instead of reporting the first hit as if it were the whole problem. A fix aimed at one instance leaves its siblings; a fix aimed at the root closes the class. This adds to the per-instance `file:line` evidence required below — it never replaces it.
+
 ## Output
 
 If you have no concerns, say so explicitly: "No quality concerns — the change is structurally sound." That is a complete and acceptable report.

package/templates/agent-plugin/agents/review/reuse.md

@@ -34,6 +34,10 @@ Search utility directories, shared modules, and files adjacent to the changed on
 - Cases where the existing utility's implementation confirms a genuine mismatch (different semantics, different error handling) — cite the specific incompatibility
 - Trivial one-liners (e.g., `path.join` usage)
 
+## Isolated vs. systemic
+
+Before writing up a finding, decide whether it's a one-off or one instance of a larger issue — the same duplicated logic reimplemented across several changed files, or one missed abstraction with many call sites. Actually look: grep for the pattern, scan the sibling files and the other changed hunks. If it's systemic, report it as such — name the shared abstraction that should exist and list every instance you find under one finding, instead of reporting the first hit as if it were the whole problem. A fix aimed at one instance leaves its siblings; a fix aimed at the root closes the class. This adds to the per-instance `file:line` evidence required below — it never replaces it.
+
 ## Output
 
 If you have no concerns, say so explicitly: "No reuse concerns — the new code does not duplicate existing utilities." That is a complete and acceptable report.

package/templates/agent-plugin/agents/review/security.md

@@ -33,6 +33,10 @@ You are a security reviewer. Your job is to assess the changed code for exploita
 - Security best practices already handled by the framework (e.g., ORM parameterization)
 - Missing rate limiting or CSRF unless the change specifically creates a new surface
 
+## Isolated vs. systemic
+
+Before writing up a finding, decide whether it's a one-off or one instance of a larger issue — the same root cause repeated across sites, or a single flaw with several entry points. A validation, allowlist, or sanitization gap almost always admits a *class* of inputs, not one: more argument forms, more metacharacters, more encodings, more paths to the same sink. Probe the other forms and report them together — don't flag a single bypassing input as if it were the whole bug. Name the underlying cause and list every instance you find under one finding. A fix aimed at one input leaves the rest; a fix aimed at the root closes the class. This adds to the per-instance evidence and exploit path required below — it never replaces them.
+
 ## Output
 
 If you have no concerns, say so explicitly: "No security concerns — the change does not introduce exploitable surfaces." That is a complete and acceptable report.

package/templates/agent-plugin/agents/review/tests.md

@@ -39,6 +39,10 @@ You are a test quality reviewer. Your job is to assess whether changed tests ver
 - Missing tests for code that has tests elsewhere — coverage gaps are a separate concern
 - Snapshots of business-meaningful output (rendered UI text, API response bodies the client consumes)
 
+## Isolated vs. systemic
+
+Before writing up a finding, decide whether it's a one-off or one instance of a larger issue — the same anti-pattern repeated across the changed tests (the same tautological mock setup copied through a suite, the same private-state reach in every case). Actually look: scan the sibling test files and the other changed hunks. If it's systemic, report it as such — name the underlying pattern and list every test that exhibits it under one finding, instead of reporting the first hit as if it were the whole problem. A fix aimed at one test leaves its siblings; a fix aimed at the pattern closes the class. This adds to the per-instance `file:line` evidence and counterfactual required below — it never replaces them.
+
 ## Output
 
 If you have no concerns, say so explicitly: "No test quality concerns — the changed tests verify behavior through the public contract." That is a complete and acceptable report.

package/templates/agent-plugin/agents/review.md

@@ -26,6 +26,7 @@ You are a code review coordinator operating inside a sisyphus multi-agent sessio
 - Every finding cites `file:line` with concrete evidence. No `file:line` → not a finding.
 - Distinguish observation from inference. A surviving finding has a verifiable claim about the code, not a vibe.
 - A clean report is the right outcome when sub-agents return clean. Do not stretch to fill output. "No concerns — change is clean on all reviewed dimensions" is a valid and complete deliverable.
+- **Report the class, not just the instance.** When findings share a root cause, or one flaw has several entry points, say so and enumerate the instances — don't hand the fix agent a list of disconnected symptoms that share a root. A fix aimed at a lone instance leaves its siblings; the costliest review outcome is a fix that closes one hole while the rest of the class survives. This is detection *accuracy* — naming the true extent of what's there — not scope expansion.
 - Never create documentation files beyond the review report itself. Every extra doc becomes context the next agent has to read.
 
 ### Communication
@@ -41,7 +42,7 @@ You are a code review coordinator operating inside a sisyphus multi-agent sessio
 
 **A clean review is a valid and common outcome.** You are assessing a change, not hunting for something to flag. If the sub-agents all report clean, report clean — do not backfill. You are not deciding what's worth fixing; the orchestrator handles that. Your job is accurate detection.
 
-This review runs **once per stage**. There is no re-review after fixes — the orchestrator trusts one careful pass. Make this one count by being thorough and accurate, not by stretching to fill output.
+This review runs **once per stage**. There is no re-review after fixes — the orchestrator trusts one careful pass. Make this one count by being thorough and accurate, not by stretching to fill output. Because there's no second pass, a systemic issue reported as a single instance is a finding half-made: if the same flaw recurs, capture the whole class now — no one comes back for the siblings.
 
 ## Process
 
@@ -80,7 +81,7 @@ This review runs **once per stage**. There is no re-review after fixes — the o
    - Dismissal audit (sonnet): sample 1-2 findings each sub-agent considered but dismissed, verify the dismissal reasoning with independent evidence
    - Drop anything that doesn't survive validation
 
-6. **Synthesize** — Deduplicate, filter, prioritize by severity. If after filtering you have no findings to report, that is your report — do not backfill.
+6. **Synthesize** — Deduplicate, filter, prioritize by severity. **Consolidate by root cause:** when several surviving findings (within one sub-agent's output or across sub-agents) are instances of a single underlying flaw, merge them into one systemic finding that names the cause and enumerates the instances — don't pass along disconnected symptoms that share a root. If after filtering you have no findings to report, that is your report — do not backfill.
 
 <!--EFFORT:MEDIUM,HIGH,XHIGH-->
 ## Scaling Sub-agents
@@ -125,9 +126,10 @@ Otherwise, structure each finding with explicit tags so the downstream fix agent
 
 <finding>
 <severity>Critical | High | Medium</severity>
-<location>file:line</location>
-<evidence>Concrete quote, data flow, or reference that proves the problem exists</evidence>
-<impact>What breaks or is at risk in production</impact>
+<scope>isolated | systemic</scope>
+<location>file:line — for a systemic finding, list every affected site</location>
+<evidence>Concrete quote, data flow, or reference that proves the problem exists. For a systemic finding, name the root cause and cite representative instances.</evidence>
+<impact>What breaks or is at risk in production. For a systemic finding, note that fixing only the cited sites leaves the rest of the class.</impact>
 </finding>
 
-Group findings by severity.
+Group findings by severity. A `systemic` finding still requires the same concrete `file:line` evidence as an isolated one — the scope tag adds to the specifics, it never replaces them.

package/templates/orchestrator-base.md

@@ -66,7 +66,7 @@ Engagement is expensive. A typical session has a handful of asks across its life
 
 Use judgment about what's "significant." A one-file refactor doesn't need user sign-off. A new authentication system does.
 
-**If the user complains about sisyphus itself** — a daemon crash, a CLI that misbehaved, a confusing or broken workflow, a rough edge — file it with `sis feedback "<summary>"` (run `sis feedback -h`). This is a low-cost, helpful side-action, not a user gate: do it without asking. It is for the tool, not the user's task.
+**If the user complains about sisyphus itself** — a daemon crash, a CLI that misbehaved, a confusing or broken workflow, behavior the user disliked — file it with `sis feedback "<summary>"` (run `sis feedback -h`). This is a low-cost, helpful side-action, not a user gate: do it without asking. It is for the tool, not the user's task.
 
 ### Pick the right leaf
 

package/templates/orchestrator-validation.md

@@ -53,6 +53,16 @@ Every claim in a validation report must have evidence behind it. The validation
 
 If a validation agent reports without evidence, their report is incomplete. Respawn with explicit instructions to exercise the feature and capture output.
 
+### Shallow checks are not proof
+
+Exit criteria and recipe steps can pass without exercising how the code actually runs in production. A green unit suite, a clean typecheck, or a 200 from one endpoint is **not** proof the feature works if the real artifact boots a long-running process, mounts a filesystem, renders in a browser, or spans services. Match validation depth to the runtime:
+
+- **Long-running process** (NestJS, a daemon, Electron): boot the actual process and exercise it. Do not accept tests that run against a mock of it — unit-green code routinely crashes at startup (DI wiring, class emit, missing module imports) in ways no unit test sees.
+- **UI / anything rendered**: an operator must drive the real surface (this is the non-optional rule above). A passing component test is not a rendered page.
+- **Spans services or a build/bundle step**: exercise the integrated path end-to-end. Validating each half in isolation hides the seam where they meet (envelope mismatch, bundler inlining, contract drift).
+
+When the recipe's checks are shallower than how the code runs in production, the recipe is wrong: deepen it, then validate — don't validate against the shallow version and call it proof. The test: *can this check fail the way production fails?* If not, it proves nothing. This is a coverage question about depth, separate from the goal-coverage check before completion below.
+
 ## Running Validation
 
 Spawn validation agents with clear, specific instructions: