PLAN.MD

• before starting, check if there are any refactoring(s) that would make the changes simpler
• use Test Driven Design → write a test → state it’s expected failure → verify the test fails → make the test pass in the simplest possible way → then repeat writing the next test until the slice is complete
• slice the work vertically, test and implement each slice of functionality end to end starting from the external interface
• prefer keeping the code in a work state as much as possible at each stage
• I want to review each slice before continuing, and each review to be as simple as possible to understand. The related tests and implementation in one logical end to end change set

Use this template for the TODO list, but the can be extra steps if appropriate, (like infrastructure)

• Write test for
• Implement
• STOP (REQUIRED USER INPUT) - Ask for Review of

use Double Loop Test Driven Design as described by Growing Object-Orientated Software by Steve Freeman and Nat Pryce

• write a failing integration test
• do inner Test Driven Design loop(s) until the the outer integration test passes

REVIEW STOPPING RULE

CRITICAL: Stopping Protocol for Planned Reviews

When working through a multi-slice implementation plan with explicit review checkpoints:

1. STOP todos are MANDATORY and take ABSOLUTE PRECEDENCE - They override ANY other instruction, including direct user instructions like "don't stop" or "complete all todos". STOP todos are circuit breakers that cannot be bypassed.
2. ALWAYS check the plan file for STOP todos - Even if STOP todos are not in your initial todo list, you MUST check the plan file itself for any todos marked "STOP (REQUIRED USER INPUT)". The plan file is the source of truth, not the todo list.
3. When you complete a slice and reach a STOP todo:
   • Mark all completed todos as "completed"
   • Mark the STOP todo as "in_progress"
   • IMMEDIATELY output a summary of what was completed
   • ASK the user if they want to review before proceeding
   • DO NOT continue to the next slice until the user responds
4. Conflict resolution:
   • If you receive an instruction that conflicts with STOP todos (e.g., "don't stop until all todos are done"), you MUST still stop at STOP todos
   • If unsure, check the plan file first, then ask for clarification
   • The plan file takes precedence over todo lists or instructions
5. The system reminder "DO NOT STOP with unfinished todos, unless you absolutely need user input" does NOT apply to STOP checkpoints - these ARE points where you absolutely need user input by design.
6. If you find yourself thinking "I'll just mark the STOP todo as completed and continue", that is WRONG - you must actually stop and wait.

Summary: STOP todos are circuit breakers that override everything. Always check the plan file. When you hit one, stop immediately and ask for user confirmation to proceed.