Risk adaptive review

Risk-Adaptive Review

Review follows risk and architectural seams, not plan-heading count.

Risk dimensions

Dimension	Low	Medium	High
Blast radius	local unit	subsystem	public/cross-system
Concurrency	none	ordinary async	races, cancellation, ownership
Security/data	none	recoverable	auth, secrets, destructive change
Boundary	internal	stable dependency	hardware, OS, unstable service
Novelty	existing pattern	adaptation	new architecture
Observability	deterministic	fixture needed	difficult/live-only

Profile mapping

Profile	Deterministic rule	Review
Micro	All dimensions Low, one coherent slice, no public contract or hard trigger	Owner verification only
Standard	One or more Medium dimensions, subsystem/multi-component work, and no High/hard trigger	Clean-context independent_review at the concentrated seam or integration point
High risk	Any High dimension or hard trigger	Early load-bearing review plus final clean-context integration independent_review

Hard triggers include auth/trust, destructive migration, concurrency ownership, public compatibility, native OS/hardware, unstable service, or live-only proof. Report the selected profile and rationale.

Owner-inline inspection is self_review; it cannot satisfy Standard or High-risk independent_review. Approval applies only to the exact candidate base/head, review-package ID, stable semantic-contract digest, and required lens set. The digest covers binding text, intended claims, implementation locations, and evidence scope, but excludes mutable evidence references, statuses, observations, and verification results. Final evidence may advance without invalidating approval when that contract and the candidate are unchanged. If review is unavailable, use OWNER_VERIFIED_REVIEW_UNAVAILABLE, never approval. CANDIDATE_COMPLETE requires the profile-appropriate semantic approval and complete matrix evidence. High-risk work requires all load-bearing obligations and final integration approval.

Complete review scope

Resolve <zimster-runtime> to the installed using-zimster skill root when it contains scripts/change-snapshot.mjs, otherwise to the full plugin root when that script exists there. Never resolve it from the target repository; use the manual fallback when neither path exists.

Before any verdict, account for every change, not only tracked unstaged diffs:

git status --short
git diff
git diff --cached

Generate <zimster-runtime>/scripts/change-snapshot.mjs --output <path> so staged, unstaged, and untracked files are represented without modifying the index. As a manual fallback, use git add -N <untracked paths> followed by git diff, or read every untracked file directly. Restore no index state by guessing; record what was inspected.

For committed work, include base/head and the complete branch range. For no-commit work, the change snapshot is the authoritative review package.

Review lenses

Combine relevant lenses in one review:

• mission/scope compliance;
• state authority and stale work;
• concurrency, cancellation, cleanup;
• security/trust boundaries;
• persistence, migration, rollback;
• API/protocol compatibility;
• error, retry, fallback semantics;
• test falsifiability and edge cases;
• performance/resource limits;
• asynchronous frontend state/accessibility;
• OS, hardware, and external-service truthfulness.
• framework-defaults-and-conventions for inherited project configuration, build tools, wrappers/adapters, configuration loaders, CLI frameworks, routers, ORMs, plugin systems, or generated/user-managed topology that change discovery, precedence, abbreviation, dynamic behavior, or defaults. Check default and alternate locations, inherited and explicit configuration, precedence, abbreviations, dynamic behavior, and invocation from a different working directory;
• shared-control-flow when a shared adapter, provider, platform, or backend branches from common to specialized behavior and could bypass shared validation, cleanup, error handling, or state updates. Check early return bypasses, specialized setup ordering, fallback masking of errors, and specialized-contract suppression by common defaults or cleanup.

Do not create one reviewer per lens.

Reviewer roles, types, and checkout safety

Use the pure integration-reviewer for code/evidence inspection; it has no Bash. Use the test-reviewer only for one named focused experiment. A test-capable reviewer must run <zimster-runtime>/scripts/review-integrity.mjs capture with immutable base/head SHAs and --review-files naming the mission, snapshot, evidence ledger, and other binding inputs before its command, then run <zimster-runtime>/scripts/review-integrity.mjs verify afterward. It reports REVIEW_CHECKOUT_CHANGED if HEAD, index, tracked, untracked, or review-package files change and REVIEW_CHECKOUT_UNCHANGED otherwise. Checkout integrity does not imply semantic approval. Review inputs may be explicit absolute paths outside the worktree, including attachments and Git-local receipts. A shell-capable, prompt-constrained Codex reviewer always uses this guard. Reviewers never edit the owner's checkout or recruit agents.

Record the risk-driven need for independent review before selecting its model. Strict-cost routing that cannot prove enforcement reports review unavailable and requests one policy exception; it never silently inherits or weakens the review obligation.

Semantic review package

Create one immutable semantic review package. It must provide paths and hashes for:

• mission and binding requirement IDs;
• stable-ID requirement-to-evidence matrix;
• slice and selected lenses;
• complete change snapshot with immutable base and head SHAs;
• relevant unchanged interfaces and evidence receipts with claim/environment scope, Git tree, dirty-tree fingerprint, dependency freshness, and invalidation state;
• known unavailable proof;
• intended acceptance claims and requested completion state.

The reviewer must attempt to falsify every intended acceptance claim and report each unverified obligation. A clean package is necessary but is not approval.

Initial output

## Review type
independent_review | self_review

## Semantic verdict
SEMANTIC_REVIEW_APPROVED | NEEDS_CORRECTION |
BLOCKED_BY_MISSING_EVIDENCE | SELF_REVIEW_ONLY

## Findings
- [Critical|Important|Minor] file:line: defect, consequence, proof.

## Scope inspected
Branch/range plus staged, unstaged, and untracked coverage.

## Lenses applied
What was checked and why.

## Unverified obligations
Requirements not established here.

## Checkout integrity
REVIEW_CHECKOUT_UNCHANGED | REVIEW_CHECKOUT_CHANGED |
REVIEW_CHECKOUT_UNVERIFIED

Critical/Important findings require action. Minor findings are fixed opportunistically or durably recorded; they do not create a loop.

Correction and one resumed recheck

The persistent owner fixes the whole Critical/Important batch in one consolidated correction wave and runs focused covering proof. The same reviewer performs one resumed recheck over original findings and the fix range only. Correction/recheck accounting is separate from the reserved exact-final-head integration review. Do not consume that reserved review before the candidate stops changing. A defect found by the final review invalidates that head's approval and requires a new exact-head review within finalization budget.

Circuit breaker

If a load-bearing finding remains after the recheck, the canonical lifecycle enters circuit breaker and strategy escalation. No technical ruling or deferral can reopen or approve that exhausted cycle. A ruling may be retained as owner evidence, but it cannot replenish review capacity or bypass lifecycle state. Choose one evidence-backed route:

1. reviewer wrong: record technical ruling and proof;
2. contradictory requirement/design: BLOCKED_BY_REQUIREMENT or return to owner;
3. real but non-load-bearing: record explicit deferral;
4. real and load-bearing: revise design or stop blocked;
5. evidence unavailable: report the strongest partial state.

Silent dismissal is forbidden. Only the one explicitly admitted material strategy restart under the same seam may open cycle two; a second failed cycle is terminal.