executing

TDD-driven execution writes failing tests first, then implements minimal code to pass them, committing each step atomically. Read plan.md, design.md, and requirements.md to understand the approved changes, write tests before implementation, and commit after each completed step to maintain an auditable history.

Execute changes by reading your approved plan.md, then proceeding step-by-step with tests written before implementation. Update plan.md as you complete each step, creating small, verifiable commits that satisfy functional requirements and enable resumption after interruptions.

Yes, this approach supports resumption after interruptions by maintaining plan.md with completion markers and atomic commits. Reading the current plan state and existing tests lets you pick up exactly where you left off without losing context or duplicating work.

Create atomic commits after each test-passing implementation step, with commit messages reflecting what plan.md describes. Each commit should be small and verifiable, ensuring the change history is auditable and each step independently validates functional requirements.

Start with plan.md (the approved implementation steps), design.md (architectural decisions), and requirements.md (functional specifications). These files provide the context needed to write appropriate tests and implement changes in the correct order.

Use this approach for simple, well-defined tasks where an approved plan exists and changes follow clear specifications. TDD-driven execution works best when functional requirements are documented and you need an auditable, resumable history of incremental changes.