receiving-code-review

# Receiving Code Review (the evaluator REWORK loop) The superpowers-evaluator returns REWORK with file:line evidence. Your job is to fix the right thing — not to please the evaluator. **Core principle:** Verify before implementing. Ask before assuming. Technical correctness over social comfort. The evaluator is a red-team reviewer, not an order-giver. ## The Response Pattern Run this for each rework item before changing code: 1. **READ** the full rework item (file:line + what failed + corrective action) without reacting. 2. **UNDERSTAND** restate the technical requirement in your own words (or ask the evaluator-equivalent: re-read the checklist item the rework cites). 3. **VERIFY** check the claim against codebase reality — does the cited file:line actually say what the evaluator says it says? 4. **EVALUATE** is the corrective action technically sound for THIS codebase? (see Push Back below) 5. **RESPOND** with a technical acknowledgment or a reasoned pushback — never performative agreement. 6. **IMPLEMENT** one item at a time, re-running verification after each, before re-spawning the evaluator. ## Forbidden Responses **NEVER output, even when the evaluator is right:** - "You're absolutely right!" / "Great point!" / "Excellent feedback!" / "Thanks for catching that" - "Let me implement that now" before verification - Any gratitude expression or performative agreement **INSTEAD:** - Restate the technical requirement - Ask a clarifying question if the item is unclear - Push back with technical reasoning if wrong - Just fix it and show the diff — actions speak, the code shows you heard it ## Handling Unclear Items If ANY rework item is unclear, do NOT implement the clear ones and defer the unclear ones. Items may be related — partial understanding produces wrong implementation. ``` Evaluator: 4 rework items. You understand items 1,2,4. Unclear on item 3. WRONG: implement 1,2,4 now, ask about 3 later RIGHT: re-read the cited checklist item for 3; if still unclear, note the ambiguity in your return and implement 1,2,4 only after 3 is resolved (or explicitly mark 3 as [AUTO-RESOLVED] per the sprint contract's Autonomous Resolution Protocol with the most concrete interpretation) ``` ## When To Push Back Push back (with technical reasoning, not defensiveness) when a rework item: - Breaks existing functionality the evaluator didn't see - Cites a checklist item that doesn't apply to this batch's scope - Violates YAGNI (the "fix" adds a feature nothing uses) - Is technically incorrect for this stack - Conflicts with a prior architectural decision recorded in the plan's `## Global Constraints` block - The evaluator misread the file (file:line doesn't say what the report claims) **How to push back in your return:** - Reference working tests / specific file:line that contradicts the finding - State what you verified and what you couldn't - If architectural, flag for the main agent's PIVOT consideration If the evaluator was right and you were wrong: state the correction factually and move on. No long apology, no defending why you pushed back. ## Implementation Order for Multi-Item REWORK 1. Clarify all unclear items FIRST (re-read checklist items) 2. Then implement in this order: - Blocking issues (breaks tests, security, correctness) - Simple fixes (typos, imports, missing guards) - Complex fixes (refactoring, logic changes) 3. Re-run the task's verification command after EACH fix (per `verification-before-completion`) 4. Re-spawn the superpowers-evaluator for the next round only after all items are addressed and verification passes THIS TURN. ## The Bottom Line Evaluator REWORK = findings to evaluate, not orders to follow. Verify each item against the codebase. Question the wrong ones. Implement the right ones one at a time with verification. No performative agreement, no blind batch implementation.