Review Implementation

Review only the supplied objective, non-goals, acceptance criteria, exact changed files or diff, declared verification, and a small justified supporting-file set, under the finding rules, causal scope, and verdict in review-change.

Implementation-Specific Checks

• Evidence applies to the actual candidate and protected behavior, not merely to a successful process, report, or source export. On follow-up, inspect the supplied new content, prior dispositions, unresolved findings, and affected regression boundaries; a repair claim needs evidence, and a changed round alone does not repeat the full audit.
• A blocking candidate is caused or newly activated by the current diff, violates a named requirement or oracle, has a concrete consequence, carries sufficient evidence, and admits a smallest fix inside the approved scope. When the brief supplies a whole artifact instead of a diff, defects anywhere in it are in scope.
• A new issue enters scope when evidence shows it blocks the current outcome or its necessary correctness or safety within the chosen design and authority; a directly blocking caller or schema mismatch and a change-induced regression qualify, while thematic relevance, a red test, an accepted label, or a small diff alone do not. A demonstrated critical risk outside authority is returned as needs-decision.
• When the selected mechanism produces a growing repair stream, the finding compares simplifying or removing it with further hardening.
• Newly introduced or changed identifiers are checked for leaked plan task IDs, stage codes, or review rounds under the naming rule in development-standards, with evidence that the name depends on the plan rather than domain responsibility; genuine domain terminology and compatibility-bound names stand.
• An authorized best-effort secondary adaptation with evidence is not a defect; relabeling a required result as secondary, deleting its oracle, or replacing a specified library without substitution authority is.