The Code Review Cycle

Review two questions: does the candidate implement approved intent, and is its engineering sound? Missing approval blocks acceptance, not safe investigation of defects. Use s4u-code-review for the operating procedure.

Stage 1: Spec Compliance Review. Compare implementation with the exact approved specification, architecture and acceptance examples. Record missing behaviour, scope expansion and incompatible contracts. Correct implementation or obtain the appropriate owner’s approval of an explicit amendment. Updating a document to match code is not approval of changed business rules or security policy.

Stage 2: Code Quality Review. Examine selected project patterns, sufficient tests, error/recovery behaviour, security, maintainability and integration boundaries. Include allowed cases as well as denied/adverse cases. Missing Stage 1 authority does not prevent reporting a known vulnerability.

Receiving a Code Review. Evaluate findings on technical evidence, not deference. Preserve observed versus expected behaviour and classify each finding as confirmed, hypothesis/pending evidence, not assessed, or rejected with evidence. A pending hypothesis is not an accepted defect.

Resolve each finding as fixed (change and verification), acknowledged (valid deferral with owner/tracking and authorized risk acceptance where required), or disputed (technical evidence). Keep unresolved investigation visible. No finding is silently ignored.

Name the oracle. Every verification claim names the expected behaviour/provenance, observed artifact/revision/environment, actual selected/executed work and limitations. An attributable run manifest is a valid work witness; stdout counts are not the only transport. Unit tests, provider simulations and customer-system execution support different claims.

---