Iterate TDD

Keep an existing Technical Design Document (TDD) aligned with the latest decisions and repository reality. Work in lockstep with the user: resolve one design decision, repaint the affected design, report it, and stop.

Operating contract

• Ask exactly one question per message. A choice among two or three options is one question; independent decisions are separate turns.
• Treat pushback, thinking aloud, and questions from the user as discussion. A decision is resolved only when the user accepts a direction or the evidence makes the disposition explicit.
• Edit only after resolution. Repaint the affected section into a coherent design; keep feedback threads, decision logs, and patch chronology out of the design narrative.
• Verify claims about existing behavior, files, interfaces, or conventions before using them. User feedback is an input, not automatically repository fact.
• Keep System Design and Program Design distinct, then reconcile their shared names, boundaries, contracts, and flows.
• After one incorporated decision or one answered question, stop for user direction.

Entry branch

If the invocation contains no feedback, comment set, or requested direction, send this and stop: