prizmkit 1.1.122 → 1.1.124

package/bundled/skills/prizmkit-code-review/SKILL.md

@@ -1,166 +1,175 @@
 ---
 name: "prizmkit-code-review"
-description: "Iterative independent review-fix loop against spec, plan, workspace changes, and test evidence. Establishes a verified review snapshot using any platform-supported subagent strategy while keeping review judgment separate from Main-Agent filtering and fixes. Use after /prizmkit-implement as a Full path quality gate or when the user asks to review, check code, validate implementation, or decide whether changes are ready to commit. Loops until PASS or max 3 rounds. (project)"
+description: "Run a fail-closed, convergence-driven independent code review against the current spec, plan, complete workspace snapshot, applicable rules, contracts, and test evidence. Use after /prizmkit-implement, before commit when review is required, or whenever the user asks to review code, validate an implementation, find defects, assess regressions, or decide whether changes are ready. Each round launches exactly one fresh read-only non-delegating Reviewer, validates execution and workspace compliance, then has the Main Agent filter and directly fix accepted findings until PASS or the internal safety fuse stops review. (project)"
 ---
 
 # PrizmKit Code Review
 
-Run an iterative review-fix loop against the current change. Keep review judgment independent from fix application: an independent read-only Reviewer evaluates a verified snapshot, then the Main Agent filters findings and applies accepted fixes.
+Run an independent review-fix loop until the current implementation converges. One fresh Reviewer performs each complete review; the Main Agent alone controls rounds, filters findings, and applies accepted fixes.
 
-Review modes:
-- `independent-reviewer-verified-snapshot`: an independent Reviewer verified that its review snapshot is equivalent to the Main Agent's current change.
-- `not-run-no-changes`: no workspace changes were detected.
+The safety boundary is fail-closed. A Reviewer may run only when its execution environment makes workspace mutation, downstream execution creation, delegation-equivalent behavior, and orchestration re-entry unavailable. Prompt promises alone do not establish this boundary.
 
-The skill defines review invariants rather than platform tool parameters. Choose any platform-supported subagent launch and snapshot transport strategy that satisfies `${SKILL_DIR}/references/reviewer-workspace-protocol.md`.
+## When to Use
 
-If no independent Reviewer can receive and verify an equivalent snapshot, stop normal review and report the workspace verification failure. Do not replace the independent review with Main-Agent self-review because that would remove the separation between judgment and implementation.
-
-### When to Use
 - After `/prizmkit-implement` as the Full path quality gate
-- For Fast path when risk, scope, or the user warrants review
-- When the user says "review", "check code", "review my implementation", or "is it ready to commit"
-- Before `/prizmkit-committer` when the chosen lifecycle path requires review
+- For Fast path when scope, risk, or the user warrants review
+- When the user asks to review code, validate implementation, find defects, check regressions, or assess commit readiness
+- Before `/prizmkit-committer` when the selected lifecycle requires review
+
+## When Not to Use
 
-### When NOT to Use
-- Direct edit or low-risk Fast path where review is not required
-- No `spec.md` or `plan.md` exists and there is no clear task goal to review against
-- Trivial typo, formatting, or config-only changes that the user wants committed directly
+- Direct edit or low-risk Fast path where review is intentionally skipped
+- No task goal, specification, plan, or other review contract can be identified
+- Trivial changes the user explicitly wants committed without review
 
 ## Input
 
 | Parameter | Required | Description |
-|-----------|----------|-------------|
-| `artifact_dir` | No | Directory containing `spec.md` and `plan.md`. If omitted, scan `.prizmkit/` subdirectories for the most recently modified directory with a completed `plan.md`. When invoked as a handoff step, reuse the caller's `artifact_dir` rather than re-detecting. |
+|---|---|---|
+| `artifact_dir` | No | Directory containing `spec.md` and `plan.md`. Reuse a caller-provided directory. Otherwise locate the most recently modified completed change artifact under `.prizmkit/`. |
 
-## Phase 0: Context and Snapshot
+## Authoritative Protocols
 
-1. Read `spec.md` from the artifact directory and extract goals plus acceptance criteria.
-2. Read `plan.md` from the artifact directory and extract architecture decisions plus completed tasks.
-3. Read a scoped `/prizmkit-test` report when present:
-   - If `{artifact_dir}/test-report-path.txt` exists, read the pointed report.
-   - Extract Scope, Generated / Updated Tests, In-Scope Failures, Baseline Failures, Out of Scope Gaps, Boundary Matrix / Boundary Completion Gate, and Verdict when present.
-   - If no report exists, pass `No scoped /prizmkit-test report found` as informational context. Treat missing tests as a finding only when the lifecycle path required testing before review.
-4. Read dev rules when configured: load `.prizmkit/prizm-docs/root.prizm`, then referenced `.prizmkit/rules/<layer>-rules.md` files if any exist.
-5. Capture the current workspace manifest and review payload according to `${SKILL_DIR}/references/reviewer-workspace-protocol.md`. Include:
-   - baseline repository and revision identity
-   - `git status`, `git diff`, and `git diff --cached` evidence
-   - staged, unstaged, untracked, deleted, and renamed path inventory
-   - changed content and stable content identities sufficient to detect missing, stale, or mixed snapshots
-   - relevant root Prizm rules and plan decisions
-6. If no changes are detected, skip Phase 1 and write `review-report.md` with verdict PASS, rounds 0, review mode `not-run-no-changes`, and snapshot verification `NOT_APPLICABLE`.
+Read these references before starting Phase 1:
 
-## Phase 1: Review-Fix Loop
+- `${SKILL_DIR}/references/reviewer-execution-protocol.md`: mandatory execution topology, capability attestation, fail-closed behavior, and convergence rules
+- `${SKILL_DIR}/references/reviewer-workspace-protocol.md`: deterministic complete snapshots, content identities, transport reuse, and mismatch handling
+- `${SKILL_DIR}/references/reviewer-agent-prompt.md`: complete Reviewer prompt contract; fill placeholders without summarizing or omitting normative sections
+- `${SKILL_DIR}/assets/reviewer-role.json`: canonical semantic capability manifest used by platform adapters to construct enforceable Reviewer roles
 
-### Gate Mode Detection
+The protocol describes semantic capabilities rather than a platform-specific command or tool denylist. Current platform names in references are non-normative recognition examples only.
 
-Check Python availability:
+## Phase 0: Context and Initial Snapshot
 
-```bash
-python3 --version 2>/dev/null && echo "SCRIPT_MODE" || echo "TEXT_MODE"
-```
+1. Read `spec.md` and extract goals plus acceptance criteria.
+2. Read `plan.md` and extract architecture decisions plus completed tasks.
+3. Read scoped `/prizmkit-test` evidence when `{artifact_dir}/test-report-path.txt` exists. Preserve scope, generated or updated tests, in-scope failures, baseline failures, gaps, boundary evidence, and verdict.
+4. Read `.prizmkit/prizm-docs/root.prizm` and applicable project rules. Load only relevant progressive documentation.
+5. Capture a content-equivalent complete current logical workspace according to the workspace protocol, including staged, unstaged, untracked, deleted, and renamed states. Prefer `${SKILL_DIR}/scripts/workspace_snapshot.py` when Python is available.
+6. If no changes exist, skip Reviewer launch and write a no-change `PASS` report with execution metadata `NOT_APPLICABLE`.
 
-- Script mode: use `${SKILL_DIR}/scripts/check_loop.py` for round tracking, max-round enforcement, and divergence detection.
-- Text mode: follow §Text Fallback Constraints manually with identical behavior.
+## Phase 1: Convergence Loop
 
-### Step 0: Initialize Loop State
+### Loop State
 
-- `round = 1`
-- `max_rounds = 3`
-- `findings_history = []`
-- `review_mode = independent-reviewer-verified-snapshot` after snapshot verification succeeds
+Track:
 
-### Step 1: Establish Independent Review
+```yaml
+round: 1
+reviewers_started_total: 0
+completed_rounds: 0
+structured_result_state: <artifact_dir>/review-result-state.json
+```
 
-Use the skill-owned review contract:
+The internal safety fuse is fixed at ten rounds. It is not caller-configurable, is not a quality target, and never converts unresolved review into `PASS`.
 
-```yaml
-prompt_reference: ${SKILL_DIR}/references/reviewer-agent-prompt.md
-workspace_protocol: ${SKILL_DIR}/references/reviewer-workspace-protocol.md
-reviewer_contract: independent, read-only, workspace-equivalent
+### Step 1: Establish the Reviewer Boundary
+
+1. Select a fresh Reviewer execution mechanism that satisfies every invariant in the execution protocol.
+2. Establish launch-time capability attestation. Verify that mutation, delegation-equivalent behavior, downstream execution creation, and orchestration re-entry are unavailable.
+3. Ensure the Reviewer receives the complete authoritative prompt template and current snapshot, but no prior findings, verdicts, filtering decisions, Reviewer reasoning, or fix explanations.
+4. In script mode, authorize launch through the strict preflight gate:
+
+```bash
+python3 ${SKILL_DIR}/scripts/check_loop.py < preflight-payload.json
 ```
 
-1. Read both references and fill the Reviewer prompt with Phase 0 context plus the workspace manifest and payload.
-2. Choose a subagent launch and snapshot transport strategy supported by the current platform. Strategy choice belongs to the Main Agent because platforms expose different capabilities; do not treat a particular tool parameter, checkout layout, branch name, or transport as part of the skill contract.
-3. Require the Reviewer to verify snapshot equivalence before reviewing. Different physical paths or execution environments are acceptable when the verified review view is content-equivalent to the captured Main-Agent workspace.
-4. If the Reviewer returns `WORKSPACE_MISMATCH`, repair or replace the strategy only when equivalence can be established safely. Otherwise write a `NEEDS_FIXES` report with the verification failure unresolved and stop; do not perform Main-Agent self-review.
-5. After the Main Agent applies fixes, capture and verify a fresh snapshot for the next round because the previous snapshot is stale by definition.
+5. Launch exactly one foreground Reviewer only when the gate returns `launchAuthorized: true`.
 
-### Step 2: Run Review
+A platform-specific role may be used only when its actual launch configuration proves the semantic boundary. For example, an installed project role whose capability allowlist contains only observational file-inspection capabilities can establish the boundary; a generic subagent with prompt-only restrictions cannot.
 
-Round context:
-- Round 1: examine all current changes comprehensively.
-- Round 2+: verify prior fixes, look for regressions introduced by the fixes, and identify accepted findings that remain.
+If the boundary cannot be established or attested, do not launch a weaker Reviewer and do not substitute Main-Agent self-review. Stop with `NEEDS_FIXES` and blocker `REVIEW_INFRASTRUCTURE_BLOCKED`.
 
-Review result:
-- `PASS`: no findings.
-- `NEEDS_FIXES`: one or more findings with severity, dimension, location, problem, and suggested fix.
-- `WORKSPACE_MISMATCH`: snapshot equivalence was not established; this is a review transport failure, not a code verdict.
+### Step 2: Complete Independent Review
 
-### Step 3: Loop Exit Gate
+The fresh Reviewer performs the complete review itself. Every round evaluates the complete current change against all applicable requirements, contracts, rules, callers, dependents, regression risks, and test evidence.
 
-Call the gate only when:
+Later rounds are not historical fix verification. They remain complete independent reviews of current code and receive no previous-round finding context.
 
-1. Review returned `PASS`.
-2. The Main Agent has filtered `NEEDS_FIXES` findings.
+The Reviewer uses two-direction inspection inside the same execution:
 
-Do not call the gate for `NEEDS_FIXES` before filtering because `accepted_count` is not known. Handle `WORKSPACE_MISMATCH` through Step 1 rather than passing it to the code-verdict gate.
+- Code-forward: changed code → affected symbols → callers and dependents → concrete failure scenarios
+- Requirement-backward: requirements and contracts → required behavior → implementation path → side effects → test evidence
 
-Script mode invocation:
+Prefer direct read-only inspection, existing valid evidence, and the narrowest verification that can establish or refute a concrete issue. Broad verification is allowed when a concrete cross-cutting risk requires it and narrower evidence is insufficient.
 
-```bash
-echo '{"reviewer_result":"NEEDS_FIXES","accepted_count":2,"findings_count":3,"round":1,"findings_history":[],"max_rounds":3,"filtering_done":true}' | python3 ${SKILL_DIR}/scripts/check_loop.py
-```
+### Step 3: Validate Reviewer Output Before Consumption
+
+Before reading, filtering, or acting on any finding, run the result gate with `filtering_done: false`.
 
-The gate output determines whether to end the loop. If `divergenceWarning` is true, warn the user that the loop may not be converging.
+The result is usable only when all of these are proven:
 
-### Text Fallback Constraints
+- exactly one fresh Reviewer started in the round;
+- capability attestation remains verified;
+- descendant execution-unit count is zero;
+- delegation depth is zero;
+- orchestration status is compliant;
+- workspace identity is matched;
+- output is complete and structurally valid.
 
-When Python is unavailable, apply these rules manually:
+On orchestration violation or unverifiable topology:
 
-1. `PASS` exits with verdict PASS.
-2. `NEEDS_FIXES` continues to filtering before any all-rejected or max-round exit.
-3. If all findings are rejected after filtering, exit with verdict PASS.
-4. If `round >= 3` after filtering and accepted findings remain, exit with verdict NEEDS_FIXES.
-5. If findings count strictly increases for 3 consecutive recorded rounds, warn about possible divergence.
-6. Record `findings_history` once per round and increment `round` after a complete review/filter/fix cycle.
+1. Stop the Reviewer and identifiable descendants on a best-effort basis.
+2. Discard all Reviewer output without consuming findings.
+3. Do not count the round as completed, retry it, or launch another Reviewer.
+4. Stop Code Review with `NEEDS_FIXES` and `REVIEW_ORCHESTRATION_VIOLATION`.
+
+On post-launch workspace mismatch, discard the output and stop with `NEEDS_FIXES` and `WORKSPACE_MISMATCH`. Do not launch a replacement Reviewer in that round.
 
 ### Step 4: Main Agent Filters Findings
 
-For each finding, decide whether it is reasonable:
+Only after the pre-filter result gate authorizes consumption, classify every finding:
+
+- `accepted`: a concrete issue that cannot be refuted with current evidence;
+- `rejected`: not a defect, out of scope under the governing contract, or disproven with concrete evidence.
 
-- Is the finding relevant to the current changes?
-- Is it a real problem rather than a subjective style preference?
-- Would the fix improve the code without broad out-of-scope refactoring?
-- Does the finding conflict with the spec, plan, dev rules, or current test evidence?
+Do not reject a finding because it is inconvenient, uncertain, or low confidence. If a potentially valid defect cannot be concretely refuted, accept it for repair or leave it unresolved with `NEEDS_FIXES` when repair is unsafe.
 
-Output per finding:
-- Accepted: queue for direct Main Agent fix work.
-- Rejected: record a short reason such as out of scope, not a defect, or too risky for the current task.
+Call the result gate again with `filtering_done: true`, `accepted_count`, and `rejected_count`. Its internal action controls the loop:
 
-After filtering, call the Loop Exit Gate. If `endLoop=true`, proceed to Phase 2.
+- `PASS`: no accepted findings remain;
+- `CONTINUE`: accepted findings remain before the safety limit;
+- `STOP`: a blocker exists or round ten remains non-converged.
+
+`CONTINUE` and `STOP` are orchestration actions, not external verdicts.
 
 ### Step 5: Main Agent Applies Accepted Fixes
 
-The Main Agent applies accepted findings directly in its current workspace. Keeping fix ownership with the Main Agent prevents the read-only Reviewer from becoming a second, conflicting implementation authority.
+When the gate returns `CONTINUE`:
+
+1. The Main Agent directly applies the accepted batch in the current workspace. Do not launch a separate Fixer or Dev Agent.
+2. If a repair cannot be completed safely within scope, stop with `NEEDS_FIXES` and record the unresolved finding.
+3. Capture a fresh complete snapshot after fixes.
+4. Increment `round`, create a new execution identity, and return to Step 1.
+
+Do not send the next Reviewer any prior finding, filtering, or repair history.
+
+### Text Fallback
+
+When Python is unavailable, manually enforce the same protocol and state transitions. Text fallback removes only script automation; it does not weaken capability attestation, one-Reviewer topology, result validation, output-discard rules, workspace matching, convergence, or the ten-round safety fuse.
 
-If an accepted finding cannot be fixed safely within scope, record the reason and carry the finding into `review-report.md` as unresolved.
+If exact validation cannot be performed manually, fail closed with `REVIEW_INFRASTRUCTURE_BLOCKED` rather than guessing compliance.
+
+## Phase 2: Persist and Report
+
+Persist the minimum structured result needed to regenerate the report before rendering Markdown. Include final verdict, blocker code, completed rounds, Reviewers started, execution metadata, snapshot identities, and accepted, rejected, fixed, or unresolved findings.
+
+Write `{artifact_dir}/review-report.md` using `${SKILL_DIR}/references/review-report-template.md`. Prefer deterministic rendering:
+
+```bash
+python3 ${SKILL_DIR}/scripts/render_review_report.py \
+  {artifact_dir}/review-result-state.json \
+  {artifact_dir}/review-report.md
+```
 
-After fixes are complete, record results, increment the round, capture a fresh workspace snapshot, and return to Step 1.
+If report rendering or path verification fails after review completed, regenerate the report from `review-result-state.json`. Do not rerun Code Review.
 
-## Phase 2: Output
+External verdicts are limited to:
 
-Write `review-report.md` to the artifact directory, including no-change PASS and workspace-verification failure results. Read `${SKILL_DIR}/references/review-report-template.md` for the full output format.
+- `PASS`: a usable completed round leaves zero accepted findings, or no workspace changes existed;
+- `NEEDS_FIXES`: code findings remain unresolved or any review infrastructure, execution, workspace, result, or safety blocker prevents valid completion.
 
-Required report fields:
-- Verdict: `PASS` or `NEEDS_FIXES`
-- Review Mode: `independent-reviewer-verified-snapshot` or `not-run-no-changes`
-- Reviewer Strategy: concise strategy summary without relying on platform-specific parameter names
-- Snapshot Verification: `VERIFIED`, `FAILED`, or `NOT_APPLICABLE`
-- Snapshot Identity: manifest identity or failure reason
-- Rounds and total findings
-- Fixed, rejected, and unresolved findings
-- Final summary
+Completion handoff:
 
-Completion summary:
-- `PASS`: hand off to `/prizmkit-retrospective` when docs or durable knowledge changed, otherwise `/prizmkit-committer`.
-- `NEEDS_FIXES`: inform the caller of unresolved code findings or snapshot-verification blockers.
+- `PASS`: run `/prizmkit-retrospective` when structural docs or durable knowledge changed; otherwise proceed to `/prizmkit-committer`.
+- `NEEDS_FIXES`: report unresolved findings or the diagnostic blocker and stop.

package/bundled/skills/prizmkit-code-review/assets/reviewer-role.json

@@ -0,0 +1,21 @@
+{
+  "protocol_version": 1,
+  "role_name": "prizmkit-code-reviewer",
+  "description": "Use only as the single fresh independent Reviewer launched by /prizmkit-code-review after its strict preflight gate authorizes the round.",
+  "observational_capabilities": [
+    "read-files",
+    "search-content",
+    "search-paths"
+  ],
+  "unavailable_capabilities": [
+    "workspace-mutation",
+    "shell-execution",
+    "downstream-execution-creation",
+    "delegation-equivalent-behavior",
+    "orchestration-reentry",
+    "skill-invocation"
+  ],
+  "execution_mode": "foreground-single-authority",
+  "max_descendant_execution_units": 0,
+  "max_delegation_depth": 0
+}

package/bundled/skills/prizmkit-code-review/references/review-report-template.md

@@ -1,37 +1,53 @@
 # Review Report Output Template
 
-Used in Phase 2 of `/prizmkit-code-review`. Write `review-report.md` to the artifact directory using this format.
+Use this template to render `{artifact_dir}/review-report.md` from the persisted structured result. Report regeneration must not rerun Reviewer execution.
 
 ```markdown
 # Review Report
 
 ## Verdict: <PASS|NEEDS_FIXES>
+## Rounds Completed: <number>
+## Reviewers Started: <number>
 ## Review Mode: <independent-reviewer-verified-snapshot|not-run-no-changes>
-## Reviewer Strategy: <platform-selected strategy summary|not-applicable>
+## Reviewer Strategy: <semantic strategy summary|not-applicable>
+## Execution Protocol: <COMPLIANT|BLOCKED|VIOLATION|NOT_APPLICABLE>
+## Capability Attestation: <VERIFIED|FAILED|NOT_APPLICABLE>
+## Descendant Execution Units Observed: <number>
+## Delegation Depth Observed: <number>
 ## Snapshot Verification: <VERIFIED|FAILED|NOT_APPLICABLE>
-## Snapshot Identity: <manifest identity or failure reason>
-## Rounds: <number of completed review rounds; use 0 for no-change PASS or pre-review snapshot failure>
-## Total findings: <total> → Fixed: <fixed>, Rejected: <rejected>, Unresolved: <unresolved>
+## Snapshot Identity: <identity|failure reason|not-applicable>
+## Blocker Code: <REVIEW_INFRASTRUCTURE_BLOCKED|REVIEW_ORCHESTRATION_VIOLATION|WORKSPACE_MISMATCH|REVIEW_SAFETY_LIMIT_REACHED|INVALID_REVIEW_RESULT|NONE>
+## Total Findings: <total> → Fixed: <fixed>, Rejected: <rejected>, Unresolved: <unresolved>
 
 ## Round <N>
-Findings: <count> | Accepted: <count>, Rejected: <count>
+
+- Snapshot Identity: <identity>
+- Reviewer Execution Identity: <identity>
+- Result: <PASS|NEEDS_FIXES>
+- Findings: <count>
+- Accepted: <count>
+- Rejected: <count>
 
 ### Finding <N>: <short title>
+
 - Severity: <high|medium|low>
-- Dimension: <goal-alignment|defect|completeness|consistency|security|test-quality|rules-compliance>
-- Location: <filepath:line or project-level>
+- Dimension: <dimension>
+- Location: <filepath:line|project-level>
 - Problem: <what was wrong and why it mattered>
-- Status: <fixed (round N)|rejected — reason|unresolved — reason>
+- Failure Scenario: <concrete input or state>
+- Status: <fixed in round N|rejected — concrete evidence|unresolved — reason>
 
 ## Final Summary
-<One to three sentences summarizing the review outcome, snapshot verification, and any remaining blocker.>
-```
 
-For `PASS` with no findings, write `Total findings: 0 → Fixed: 0, Rejected: 0, Unresolved: 0` and either `## Round 0: PASS — no workspace changes to review` or `## Round N: PASS — no issues found`.
-
-For snapshot verification failure, use verdict `NEEDS_FIXES`, snapshot verification `FAILED`, and record the mismatch as an unresolved review blocker rather than an ordinary code finding.
+<One to three sentences covering the valid review outcome and any remaining blocker. Do not expose Reviewer reasoning traces.>
+```
 
-## Verdict Rules
+## Report Rules
 
-- `PASS`: Reviewer returned no findings from a verified snapshot, no workspace changes existed, or all findings from a verified snapshot were rejected as unreasonable.
-- `NEEDS_FIXES`: Max rounds completed with accepted findings unresolved, or no independent Reviewer could verify an equivalent current snapshot.
+- No-change review starts no Reviewer, uses zero completed rounds, and records execution plus snapshot metadata as `NOT_APPLICABLE`.
+- Findings from a violating or mismatched Reviewer are discarded and excluded from totals.
+- A violating or mismatched round is not completed.
+- `PASS` requires no workspace changes or a usable complete Reviewer result with zero accepted findings.
+- The ten-round safety fuse with accepted findings is `NEEDS_FIXES`, never `PASS`.
+- Only `PASS` and `NEEDS_FIXES` are external verdicts. Blocker codes are diagnostic metadata.
+- Persist structured state before Markdown rendering so a report-only failure can be recovered without repeating review.

package/bundled/skills/prizmkit-code-review/references/reviewer-agent-prompt.md

@@ -1,92 +1,138 @@
-# Reviewer Subagent Prompt Template
+# Reviewer Prompt Contract
 
-Used in Phase 1 Step 1 of `/prizmkit-code-review`. The orchestrator fills the placeholders before spawning an independent read-only Reviewer under `${SKILL_DIR}/references/reviewer-workspace-protocol.md`.
+Use this complete template for every Reviewer execution in Phase 1. Fill documented placeholders only. Do not summarize, shorten, or omit the execution boundary, complete-review scope, independence boundary, workspace guard, or output contract.
 
-```
-You are the independent read-only Reviewer for `/prizmkit-code-review`. Review the verified workspace snapshot against the spec goals, plan decisions, scoped test evidence, and dev rules. Do not modify files or apply fixes; the Main Agent will filter findings and apply accepted fixes.
+```text
+You are the sole independent read-only Reviewer for this round of `/prizmkit-code-review`.
+
+## Execution Boundary
+
+Perform the complete review yourself.
+
+Do not create, schedule, resume, continue, request, or coordinate any separate downstream execution unit. Do not re-enter orchestration, delegation, another review workflow, or an equivalent process directly or indirectly. Do not ask the Main Agent to create a helper on your behalf.
+
+Do not modify, create, delete, rename, stage, or commit workspace files. Do not run a command or tool that changes the review view.
+
+If you cannot complete the review within this execution context, stop and return `REVIEW_INFRASTRUCTURE_BLOCKED`. Do not delegate or provide a partial PASS.
+
+## Independent Input Boundary
+
+Review only the current state supplied below. No prior Reviewer findings, verdicts, filtering decisions, repair descriptions, or Reviewer reasoning are part of your input. Do not infer that an earlier Reviewer found every defect, and do not attempt historical reconciliation.
 
 ## Spec Goals
+
 {goals and acceptance criteria from spec.md}
 
 ## Plan Decisions
+
 {architecture decisions and task list from plan.md}
 
-## Scoped Test Report
-{summary from artifact_dir/test-report-path.txt and test-report.md, including Scope, Generated / Updated Tests, In-Scope Failures, Baseline Failures, Out of Scope Gaps, Boundary Matrix / Boundary Completion Gate if present, and Verdict. If no scoped report exists, write "No scoped /prizmkit-test report found (expected for pre-test review)." Treat that absence as informational unless the calling workflow requires a prior report.}
+## Applicable Rules and Contracts
+
+{relevant Prizm docs, project rules, public and internal contracts, or "No additional project rules identified."}
+
+## Scoped Test Evidence
+
+{current test report summary and identities. If absent, write "No scoped /prizmkit-test report found." Treat absence as informational unless the lifecycle contract required prior test evidence.}
 
 ## Workspace Manifest
-{repository and baseline identity, review-round identity, changed path inventory and statuses, staged/unstaged composition, untracked content entries, delete markers, rename pairs, and stable content identities captured by the Main Agent}
+
+{repository identity, baseline identity, snapshot identity, path inventory, change states, staged and unstaged composition, rename/delete state, content identities, and supporting-context identities}
 
 ## Review Payload
-{the reviewable representation of every manifest entry, plus clearly identified unchanged context needed to evaluate callers, dependents, or shared patterns}
+
+{complete logical representation of every manifest entry plus distinguishable unchanged caller and dependent context}
 
 ## Reviewer Strategy
-{concise description of how the current platform made the snapshot available. This is diagnostic context, not a required parameter contract.}
+
+{concise diagnostic description of how this platform established observational access and made mutation, downstream execution, delegation-equivalent behavior, and orchestration re-entry unavailable}
 
 ## Workspace Equivalence Guard
-Validate the supplied manifest and payload according to the Reviewer Workspace Protocol before normal review:
-- Every manifest path and state must be represented.
-- Staged, unstaged, untracked, deleted, and renamed changes must not be silently lost.
-- Changed content identities and review-round identity must match.
-- Unexplained changed paths, stale content, or unverifiable entries are mismatches.
-
-Do not reject a snapshot merely because its physical path, checkout layout, branch label, host, or transport differs from the Main Agent's environment. Content equivalence is the invariant.
-
-If equivalence cannot be proven:
-- Stop before normal review.
-- Do not produce ordinary findings.
-- Return `WORKSPACE_MISMATCH` with concrete mismatch evidence and required corrective action.
-
-## Dev Rules
-{rules from .prizmkit/rules/<layer>-rules.md, or "No custom dev rules configured — use general best practices."}
-
-## Review Round
-Round {N}. {round_context}
-
-## What to Review
-Use the verified workspace snapshot as the primary review scope:
-- Read the full content of new files.
-- For modified files, read enough surrounding context to understand behavior and impact.
-- Read unchanged callers, dependents, or shared patterns only when needed to verify a potential finding.
-- Do not edit files, stage changes, run tools that modify the review view, spawn other agents, or apply fixes.
-- Do not broadly re-index the repository when the supplied snapshot and targeted reads are sufficient.
-
-## Review Dimensions
-Evaluate the relevant dimensions:
-
-1. **Goal alignment**: Do the changes accomplish the spec goals and acceptance criteria?
-2. **Defects**: Are there logic bugs, boundary failures, or missing error handling?
-3. **Completeness**: Are required files, tests, types, imports, or exports missing?
-4. **Consistency**: Do the changes follow existing project patterns, naming, and style?
-5. **Security**: Do the changes introduce secrets, injection paths, or unsafe operations?
-6. **Test quality**: When a scoped report exists, verify its scope and artifact identity, meaningful assertions, failure classification, boundary evidence, and verdict compatibility.
-7. **Rules compliance**: When dev rules exist, verify the relevant layer conventions.
-
-## Output Format
+
+Validate the manifest and payload before ordinary review:
+
+1. Every manifest path and state is represented.
+2. Staged, unstaged, untracked, deleted, and renamed changes are preserved.
+3. Content and snapshot identities match.
+4. Supporting caller or dependent context is distinguishable from changed content.
+5. No unexplained changed path, stale content, mixed-round content, or unverifiable entry exists.
+
+Physical path, checkout layout, host, or transport may differ. Content-equivalent current state is the invariant.
+
+If equivalence cannot be proven, stop before ordinary review and return `WORKSPACE_MISMATCH` with concrete mismatch evidence. Do not return code findings from an unverified snapshot.
+
+## Complete Current-State Review
+
+Review the complete current change set independently. Do not limit inspection to files changed by the latest repair or to previously identified categories.
+
+Evaluate applicable dimensions:
+
+1. Requirement and acceptance-criteria alignment
+2. Implementation completeness
+3. Correctness and concrete failure scenarios
+4. Error handling
+5. Security and authorization
+6. Data integrity
+7. Transaction and concurrency behavior
+8. Public and internal contracts
+9. Backward compatibility and regression risks
+10. Test adequacy and evidence compatibility
+11. Project-rule compliance
+
+Use both inspection directions inside this one review:
+
+- Code-forward: changed code → affected symbols → callers and dependents → concrete failure scenarios
+- Requirement-backward: requirements and contracts → required behavior → implementation path → side effects → test evidence
+
+Read unchanged callers, dependents, or shared patterns when needed to evaluate impact.
+
+## Review Efficiency
+
+Complete the review directly instead of delegating it. Prefer direct read-only inspection and targeted verification.
+
+Use existing valid test evidence when it answers the question. Prefer the narrowest verification that can establish or refute a concrete issue. Do not rerun an equivalent check when relevant code and inputs have not changed.
+
+Avoid broad builds, tests, lint, or type checks as exploratory defaults. A broad command remains valid when a concrete cross-cutting risk genuinely requires it; state why narrower evidence is insufficient.
+
+Non-normative examples:
+
+- A repository-wide test or build without a concrete reason is often redundant with the formal Test Gate.
+- A focused module or test-case invocation is usually better when investigating one failure scenario.
+
+These examples do not prohibit command names. The governing rule is targeted, non-duplicative evidence gathering.
+
+## Finding Coverage
+
+Report every concrete issue you find, including uncertain or low-severity issues. Do not filter for importance or confidence; the Main Agent performs downstream filtering. Exclude pure style or naming preferences that cannot cause incorrect behavior, contract drift, regression, security weakness, or misleading evidence.
+
+## Output Contract
+
 Respond with exactly this structure:
 
-### Result: PASS | NEEDS_FIXES | WORKSPACE_MISMATCH
+### Result: PASS | NEEDS_FIXES | WORKSPACE_MISMATCH | REVIEW_INFRASTRUCTURE_BLOCKED
+
+### Execution Compliance
+- Status: COMPLIANT | BLOCKED
+- Descendant execution units created: 0
+- Delegation depth: 0
 
 ### Snapshot Verification
 - Status: VERIFIED | FAILED
-- Identity: <manifest identity or mismatch summary>
+- Identity: <snapshot identity or mismatch summary>
 
 ### Findings
-(If PASS, write "No issues found." If WORKSPACE_MISMATCH, include only mismatch evidence and required action.)
+(If PASS, write "No issues found." If WORKSPACE_MISMATCH or REVIEW_INFRASTRUCTURE_BLOCKED, include only blocker evidence and required action.)
 
 #### Finding N
-- **Severity**: high | medium | low
-- **Dimension**: goal-alignment | defect | completeness | consistency | security | test-quality | rules-compliance
-- **Location**: filepath:line (or "project-level")
-- **Problem**: What is wrong and why it matters
-- **Suggestion**: Recommended fix approach
-- **Verification**: How to confirm the fix is correct
+- Severity: high | medium | low
+- Confidence: high | medium | low
+- Dimension: requirement-alignment | defect | completeness | error-handling | security | data-integrity | concurrency | contract | compatibility | test-quality | rules-compliance
+- Location: filepath:line (or "project-level")
+- Problem: concrete wrong behavior and why it matters
+- Failure scenario: inputs or state that produce the wrong result
+- Suggestion: recommended repair approach
+- Verification: how to prove the repair
 
 ### Summary
-One to two sentences about the snapshot and overall state of the changes.
+One or two sentences describing the verified current state and overall result. Do not expose private reasoning traces.
 ```
-
-## Round Context
-
-- Round 1: "This is the first review. Examine all changes comprehensively."
-- Round 2+: "Previous findings were filtered and accepted fixes were applied. Verify those fixes, check for regressions, and identify remaining issues without re-reporting resolved findings."