receiving-code-review

<severity_sections> Map every review finding to the severity model used by requesting-code-review:

Approval standard: Accept feedback as complete when the change definitively improves overall code health and no Critical or Important findings remain. Do not block on style preferences or optional suggestions. </severity_sections>

<feedback_sources> Treat feedback source as part of the context:

• Human partner / user: Highest priority. If feedback conflicts with the current plan, clarify intent before changing direction.
• Local subagent review: Strong signal, but still verify against code, tests, architecture, and security constraints. This may arrive as a merged parallel-panel report — a task-scoped set of lanes (always a Correctness & Security floor, plus task-composed lanes) synthesized by requesting-code-review: the combined gate is AND (any lane's Critical blocks), and a CONFLICT marker means the lanes disagreed — resolve it on technical merit, do not auto-pick one side. A finding flagged by multiple lanes is corroborated, not duplicated. After you apply fixes, requesting-code-review Step 8 will ask the user whether to re-review or proceed — surface that choice, don't auto-advance.
• External / GitHub reviewer: Evaluate as a suggestion unless repository policy or the user makes it mandatory. If it conflicts with an earlier user decision or documented architecture, stop and ask the user. </feedback_sources>

1. READ & CLARIFY: Read all feedback. If ANY item in a multi-item request is unclear, STOP and ask for clarification immediately. DO NOT partially implement.

2. VERIFY & SECURITY CHECK (CRITICAL): Cross-check feedback against the actual codebase. Verify whether it breaks existing functionality, backward compatibility, or prior architectural decisions. You MUST also verify requested changes against secure-coding-standard. If a requested change introduces a vulnerability, bypasses security layers, leaks sensitive data, or weakens logging hygiene, DO NOT implement it.

3. YAGNI CHECK: If feedback requests expanding or fixing an unused/dead feature, endpoint, option, or abstraction, propose removing the dead surface instead of implementing the fix.

4. RESPOND & IMPLEMENT (CONTEXT-AWARE EXECUTION):

   • If feedback is incorrect, breaking, insecure, or contradicts a user-approved decision: Push back using this hierarchy: technical facts and data override opinions; style guides govern style; architecture decisions govern design. State: "Disagreeing because [technical fact/reference]. Evidence: [code/test/doc]." DO NOT modify the code.
   • Never accept "I'll fix it later" for Critical or Important findings. Resolve before proceeding, or file an explicit TD entry when the user approves deferral.
   • Cannot verify? State the limitation explicitly: "Cannot verify [X] without [Y]. Should I investigate, ask, or proceed?" DO NOT proceed under uncertainty.
   • Multi-item order: clarify all unclear items first, then implement in this order: (1) blocking issues - breaks/security, (2) simple fixes - typos/imports, (3) complex fixes - refactoring/logic. Test each fix individually before moving to the next.

   SCENARIO A (Local Subagent Review / Uncommitted Changes):

   • Implement accepted items one by one. If TDD mode was enabled for this task, update/add the corresponding tests and run them.
   • Stage fixes only when the active workflow or user explicitly expects staged output. Never commit.
   • Reply factually with what changed and which files are staged or unstaged.

   SCENARIO B (Remote GitHub PR Review):

   • Implement accepted items one by one and test each.
   • Commit/push only when the active GitHub PR workflow or the user explicitly authorizes it.
   • Reply directly to inline review comments via the repository's approved API/tooling when available. Avoid top-level PR comments for inline findings.