operating-code-review ยท diff
git:20260808.e803581 to git:20260908.bf8e38b
23 added, 60 removed. Audit A to A.
---
name: operating-code-review
- description: Review code, diffs, pull requests, migrations, or architecture without modifying files. Lead with severity-ranked evidence-backed findings, challenge root-cause claims, and disclose cleared and unreviewed scope.
+ description: Review without editing; report evidence-backed defects by severity and disclose material verification gaps.
---
# Code review
- Review only. Do not modify code unless the user explicitly changes the task.
-
- ## Scope
-
- Read the requested diff plus the smallest sufficient callers, consumers, contracts,
- tests, configuration, schemas, generated behavior, and one analogous sibling. Treat the
- author's explanation and previous findings as leads, not proof.
-
- Load specialized References only when Diff Facts require them:
-
- - auth, trust boundaries, secrets, injection, or unsafe parsing:
- [security-review.md](references/security-review.md);
- - migrations, DDL, ORM models, persistent serialization, or stored formats:
- [data-and-migration-review.md](references/data-and-migration-review.md);
- - manifests, lockfiles, packaging, CI, deployment, or release changes:
- [dependency-and-release-review.md](references/dependency-and-release-review.md);
- - formal UI, interaction, accessibility, responsive, or visual changes:
- [ui-review.md](references/ui-review.md).
-
- ## Finding standard
-
- A finding must include:
-
- - severity: Critical, High, Medium, or Low;
- - exact file and line/symbol;
- - failure mode and triggering conditions;
- - evidence from a code path, contract mismatch, reproduction, or missing durable test;
- - the smallest concrete correction;
- - confidence: verified, strongly inferred, or uncertain.
-
- Do not report style preferences as defects. Separate questions and optional
- improvements from findings.
-
- ## Review method
-
- Start from the failure surface and trace ownership, callers, and consumers. Read the
- full relevant diff. Compare it with source-of-truth schemas, manifests, docs, CI, and
- tests. Attempt to disprove the strongest completion claim and test negative paths,
- cleanup, retries, cancellation, timeouts, partial failure, and mixed versions as
- applicable.
-
- A guard, flag, journal, abstraction, or workflow step earns its place only when the
- review can name the observable failure, owning boundary, executable enforcement,
- regression proof, and decision it changes.
-
- For a defect repair, require:
+ Review only. Do not modify files or execute external changes unless the user explicitly
+ changes the task. Preserve unrelated work and respect the active access and approval rules.
- ```text
- ROOT_CAUSE_ALIGNMENT: PASS | FAIL | NOT_APPLICABLE
- ```
+ Read the relevant diff and enough callers, consumers, contracts, or tests to assess its
+ behavior. Treat the author's explanation and previous findings as leads, not proof. Load
+ specialized References only for the affected surface:
- `PASS` requires evidence for the trigger, violated invariant, root cause, and repair at
- the owning boundary. Caller-only special cases, swallowed exceptions, arbitrary
- retries/delays, widened timeouts, silent defaults, duplicated state, or weakened tests
- are possible false fixes until repository evidence proves otherwise.
+ - security or trust boundaries: [security-review.md](references/security-review.md);
+ - persistent data or migrations: [data-and-migration-review.md](references/data-and-migration-review.md);
+ - dependencies, packaging, or release: [dependency-and-release-review.md](references/dependency-and-release-review.md);
+ - rendered UI or interaction: [ui-review.md](references/ui-review.md).
- ## Output
+ For a defect repair, verify that the changed owner explains and fixes the original trigger.
+ Challenge a completion claim with a concrete counterexample where useful; inspect an
+ analogous implementation only when it could reveal the same failure. Consider cancellation,
+ retries, partial failure, and compatibility when the changed behavior makes them relevant.
+ Do not require every review to traverse every failure category or run a fixed test suite.
- Start with `## Findings`, ordered by severity. Then state
- `ROOT_CAUSE_ALIGNMENT`. Add questions or optional improvements only when useful.
+ Report material findings by severity (Critical, High, Medium, Low), with an exact location,
+ trigger and impact, supporting evidence, confidence, and the smallest concrete correction.
+ Keep questions and optional improvements separate; style preferences are not defects.
- Finish with verification gaps. If there are no material findings, say so explicitly
- and list the concrete cleared surfaces, strongest counterexample attempted, analogous
- implementation checked, and unavailable or unreviewed evidence.
+ If there are no material findings, say so and describe the reviewed scope and material
+ gaps. Distinguish executed checks from suggested checks and do not claim unobserved success.
+ Explain root-cause alignment for defect reviews; emit a machine-style status field only
+ when an applicable reporting contract requires it. No empty sections or inapplicable
+ checklist fields are needed.