operating-code-review · git:20260908.bf8e38b · 2026-09-08 · sha256 8a15fd80fc5ff6d6

operating-code-review git:20260908.bf8e38bA

Immutable. This exact content is served forever at /api/v1/blob/8a15fd80fc5ff6d6.

---
name: operating-code-review
description: Review without editing; report evidence-backed defects by severity and disclose material verification gaps.
---

# Code review

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.

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:

- 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).

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.

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.

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.