ho-impllisted

# Implement Build what the design says. You are not redesigning it, and you are not deciding anything it left open. ## Before you touch a file Read `change.yaml`, the whole of `01-design.md`, and any earlier `02-implementation.md` from a previous round. Then read every file the design puts in scope. `status` must be `ready_for_implementation` or `rework`; if `Open questions` still lists anything, the design is not ready — say so and stop. Set `status: implementing`. ## When the design does not match the project The design was written against the project at some earlier moment. Acceptance criteria name fixture rows, flags, files, and functions that may not be there. **A design that does not fit what is actually in the project is a question, not a puzzle to solve.** Stop, quote the criterion, quote what you found instead, and ask. This is the failure that shows up most in practice. Five independent agents given one design whose AC named a fixture row that did not exist produced three different repairs and none of them asked. | Rationalization | Why it fails | |---|---| | "There is a clean local fix, so it isn't really a conflict" | The cleanness of your repair says nothing about whether it is the repair the author wanted. | | "I documented it in a comment next to the code" | A comment in a file is not a report to the person who has to accept the change. | | "Editing that existing assertion is outside the design's tasks, so I worked around it" | Both the edit and the wo