todo-planner

TODO Planner

Overview

Create structured TODO.md files for tracking multi-phase implementation projects. The format emphasizes testability, verification, and phase dependencies to maintain context and ensure thorough execution.

Document Structure

A TODO.md file consists of these sections in order:

# Project Implementation Plan
[1-2 sentence description]

## Testing Philosophy
[Testing approach preamble - re-injected for context retention]

## Verification Checklist
[Pre-commit checklist - re-injected for context retention]

## Dependencies Between Phases
[ASCII diagram showing phase relationships]

---

## Phase N: Title
[Phase description]

### N.1 Sub-phase title
- [x] Completed task
- [ ] Pending task
- [ ] **Test**: Explicit test task

---

## Future Phases (Deferred)
[Items explicitly out of scope for now]

Nesting subphases

Subphases may be nested, if the complexity of a phase is high. Number them hierarchically: x.y or x.y.z or x.y.z.a, a necessary. The scope of a subphase should be work that can be completed in a single agent session and would logically make sense as an atomic commit -- a single, logical unit of change.

Testing Philosophy Preamble

Include a Testing Philosophy section near the top. This section is critical for context retention - when working on later phases, this preamble reminds the agent of testing expectations.

Template:

## Testing Philosophy

- **Automated tests for business logic**: [specific areas like store operations, API handlers]
- **Playwright tests for UI interactions**: [specific areas like drag-drop, visual behavior]
- **Manual tests for subjective UI experience**: [specific areas that require human input]
- **Factor code for testability**: Interfaces for backends, dependency injection
- **[Language] tests**: [framework specifics, e.g., "Use `testing` with `httptest` for handlers"]
- **[Frontend] tests**: [framework specifics, e.g., "Vitest for component logic"]

Test what new code changes. Don't revalidate behaviors already tested in earlier commits. E.g. browser tests
are for layout, controls, navigation, storage, not API contracts backend tests already cover.