Apply only the rows the change touches. Use the repository's own commands. A gate is "not applicable" only with a concrete reason; a missing tool or service is an unrun check.
| Surface | Requirements | Evidence |
|---|---|---|
| Architecture | Preserve dependency direction; one owner per invariant and state transition; explicit, cohesive interfaces; no speculative abstraction. | Trace entry points and callers; check the final diff for duplicated policy or dead wiring. |
| APIs and inputs | Validate type, size, range, encoding, ownership; preserve error semantics and compatibility; keep public contracts (schemas, interfaces, event and persisted formats, command behavior) stable and version incompatible changes explicitly; bound pagination and uploads. | Malformed, oversized, empty, and boundary inputs; consumer compatibility; unauthorized and cross-tenant access. |
| State and persistence | Atomicity, constraints, uniqueness, and concurrency control; exact representations where required. | Duplicate requests, lost updates, partial failure, recovery, realistic migration data. |
| Concurrency | Clear ownership of shared state; atomic check-then-act; cancellation and deadlines propagate; ordering assumptions stated; operations idempotent where retried or redelivered; locks released before network, disk, inference, subprocess, or callback work; immutable values, message passing, and ownership transfer over shared mutable state. | Races, duplicate and out-of-order delivery, retry exhaustion, cancellation mid-operation, shutdown, deadlock. |
| Resources | Pair acquisition with release; bound memory, files, sockets, tasks, queues, and pools. | Cleanup on error and cancel, repeated runs, leak checks. |
| Security and privacy | Least privilege; secure defaults; authorize each sensitive operation in one central place regardless of entry interface; stronger validation on delete, overwrite, publish, and charge than on reads; safe parsing and encoding; no embedded secrets; minimal sensitive data in logs. | Negative access tests; injection, path traversal, SSRF where relevant; log redaction. |
| UI and accessibility | Semantic controls, keyboard and focus, labels, responsive layout; loading, empty, error, success states; no duplicate destructive submits. | Component or browser tests, keyboard checks, supported viewports, accessibility tooling. |
| Performance | Find the bottleneck before optimizing; algorithmic and architectural wins before micro-optimizations; optimize behind existing interfaces, with every fast path keeping a correct generic fallback; keep correctness checks alongside speed. | Before/after on a representative workload with warmup, repetitions, variance, and comparable hardware and versions. |
| Build and supply chain | Honor pinned versions, lockfiles, generated sources, licenses; minimal dependencies and permissions. | Clean build, lockfile consistency, dependency review. |
| Operations | Typed configuration loaded and validated once at startup, with business logic receiving values rather than reading the environment; actionable config errors; defined rollout and rollback; structured logs and metrics designed with the feature that report decisions without determining them; no secrets or unbounded cardinality in telemetry. | Health checks, structured errors, metrics or traces, rollback steps. |
Before a state or public-contract change, identify readers and writers, mixed-version operation, data volume, locks, and the point where reversal becomes unsafe. Test old data and interrupted or repeated runs. A code revert does not undo deleted data or external side effects; document backup/restore or a forward repair. Never run production migrations, credential changes, or deployments without explicit authorization.
Characterize existing behavior before changing it. Map each affected package to its own toolchain; a green root command may not cover every package.
For Substantial work and above, answer each against the final diff:
- What responsibility changed, where does it live, and does another part of the code already know the same rule?
- Does the change stay local, with dependencies pointing inward and no external representation leaking into core logic?
- Which additions are policy and which are mechanism, and are they kept apart?
- What new invariant exists, and what invalid states are now possible?
- What happens on failure, timeout, cancellation, and duplicate execution?
- Who owns cleanup, what can grow without a bound, and what happens under concurrency?
- Is each interface smaller and more stable than its implementation, and does each abstraction remove knowledge from callers?
- Does this make the next related change easier, and can obsolete code now be deleted?
- Do tests protect behavior rather than implementation details?
- Is the complexity justified by a real requirement, and would another engineer know where to modify this behavior six months from now?