deepwork-receiving-code-review

Verify the claim against current code, requirements, and test evidence before implementing anything. If the finding is wrong, push back with concrete evidence such as code references, test results, or platform documentation rather than agreeing performatively.

Classify each finding as a product defect, evidence gap, optional improvement, incorrect finding, or intent-changing proposal. Implement defects with the smallest justified correction, gather evidence for gaps, defer optional items, and escalate proposals that change approved scope.

Escalate when a suggestion changes scope or acceptance criteria, weakens security or data guarantees, modifies a public API, expands permissions, requires irreversible actions, or conflicts with approved user direction. Material ambiguity without available evidence also warrants escalation rather than guessing.

No. Rerun only the review lanes affected by substantive changes to code, requirements, acceptance criteria, or evidence. Formatting, narration, label changes, and unrelated edits do not require repeated review cycles.

Reviewer approval labels and acknowledgements are informational only and do not substitute for verification. The approach cannot resolve material ambiguity without evidence, and it never expands Git or permission boundaries beyond explicitly authorized operations.