1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
# Task Plan: [Brief Description]
<!--
WHAT: This is your roadmap for the entire task. Think of it as your "working memory on disk."
WHY: After 50+ tool calls, your original goals can get forgotten. This file keeps them fresh.
WHEN: Create this FIRST, before starting any work. Update after each phase completes.
SOLID PRINCIPLES REMINDER:
- Single Responsibility: Each class/module should have one reason to change
- Open/Closed: Open for extension, closed for modification
- Liskov Substitution: Subclasses must be substitutable for their parents
- Interface Segregation: Clients shouldn't depend on unused interfaces
- Dependency Inversion: Depend on abstractions, not concretions
-->
## Goal
<!--
WHAT: One clear sentence describing what you're trying to achieve.
WHY: This is your north star. Re-reading this keeps you focused on the end state.
EXAMPLE: "Create a Python CLI todo app with add, list, and delete functionality."
-->
[One sentence describing the end state]
## Current Phase
<!--
WHAT: Which phase you're currently working on (e.g., "Phase 1", "Phase 3").
WHY: Quick reference for where you are in the task. Update this as you progress.
-->
Phase 1
## Phases
<!--
WHAT: Break your task into 3-7 logical phases. Each phase should be completable.
WHY: Breaking work into phases prevents overwhelm and makes progress visible.
WHEN: Update status after completing each phase: pending → in_progress → complete
-->
### Phase 1: Requirements & Discovery
<!--
WHAT: Understand what needs to be done and gather initial information.
WHY: Starting without understanding leads to wasted effort. This phase prevents that.
-->
- [ ] Understand user intent and business requirements
- [ ] Identify constraints, dependencies, and integration points
- [ ] Review existing codebase and architectural patterns
- [ ] Read component-specific AGENT.md files if applicable
- [ ] Document findings and architectural context
- **Status:** in_progress
<!--
STATUS VALUES:
- pending: Not started yet
- in_progress: Currently working on this
- complete: Finished this phase
-->
### Phase 2: Planning & Architecture
<!--
WHAT: Decide how you'll approach the problem and what structure you'll use.
WHY: Good planning prevents rework. Document decisions so you remember why you chose them.
-->
- [ ] Define technical approach following SOLID principles
- [ ] Design interfaces and abstractions first (DIP)
- [ ] Plan for extensibility without modification (OCP)
- [ ] Ensure single responsibility for each component (SRP)
- [ ] Create focused, client-specific interfaces (ISP)
- [ ] Design inheritance hierarchies carefully (LSP)
- [ ] Document architectural decisions with rationale
- **Status:** pending
### Phase 3: Implementation
<!--
WHAT: Actually build/create/write the solution.
WHY: This is where the work happens. Break into smaller sub-tasks if needed.
-->
- [ ] Implement interfaces and abstractions first
- [ ] Create concrete implementations following SRP
- [ ] Use dependency injection for loose coupling (DIP)
- [ ] Write small, focused methods and classes
- [ ] Follow established coding standards and patterns
- [ ] Write code to files before executing
- [ ] Test incrementally with unit tests
- **Status:** pending
### Phase 4: Testing & Verification
<!--
WHAT: Verify everything works and meets requirements.
WHY: Catching issues early saves time. Document test results for future reference.
-->
- [ ] Verify all functional requirements met
- [ ] Test SOLID principles compliance:
- [ ] Single Responsibility: Each class has one clear purpose
- [ ] Open/Closed: Can extend without modifying existing code
- [ ] Liskov Substitution: Subclasses work as drop-in replacements
- [ ] Interface Segregation: No unused interface methods
- [ ] Dependency Inversion: High-level modules independent of low-level details
- [ ] Run unit tests and integration tests
- [ ] Test error handling and edge cases
- [ ] Document test results and coverage
- [ ] Fix any issues found following 3-strike protocol
- **Status:** pending
### Phase 5: Delivery
<!--
WHAT: Final review and handoff to user.
WHY: Ensures nothing is forgotten and deliverables are complete.
-->
- [ ] Review all output files
- [ ] Ensure deliverables are complete
- [ ] Deliver to user
- **Status:** pending
## Key Questions
<!--
WHAT: Important questions you need to answer during the task.
WHY: These guide your research and decision-making. Answer them as you go.
EXAMPLE:
1. Should tasks persist between sessions? (Yes - need file storage)
2. What format for storing tasks? (JSON file)
3. How can we ensure this design is extensible? (Use interfaces and dependency injection)
-->
1. [Question to answer]
2. [Question to answer]
3. [SOLID-related question if applicable]
## Decisions Made
<!--
WHAT: Technical and design decisions you've made, with the reasoning behind them.
WHY: You'll forget why you made choices. This table helps you remember and justify decisions.
WHEN: Update whenever you make a significant choice (technology, approach, structure).
EXAMPLE:
| Use Repository pattern for data access | Follows SRP and DIP, makes testing easier |
| Create separate interfaces for read/write | Follows ISP, clients only depend on what they use |
-->
| Decision | Rationale | SOLID Principle(s) |
|----------|-----------|-------------------|
| | | |
## Errors Encountered
<!--
WHAT: Every error you encounter, what attempt number it was, and how you resolved it.
WHY: Logging errors prevents repeating the same mistakes. This is critical for learning.
WHEN: Add immediately when an error occurs, even if you fix it quickly.
EXAMPLE:
| FileNotFoundError | 1 | Check if file exists, create empty list if not | Added proper error handling |
| Tight coupling issue | 2 | Introduced interface to decouple components | Applied DIP principle |
-->
| Error | Attempt | Resolution | Lessons Learned |
|-------|---------|------------|----------------|
| | 1 | | |
## Architecture & Design Notes
<!--
WHAT: Important architectural insights and design patterns discovered during implementation
WHY: Capture design knowledge for future reference and team learning
-->
- Design patterns used: [e.g., Repository, Factory, Strategy]
- SOLID principle applications: [specific examples from your implementation]
- Integration points: [how this connects with existing systems]
- Future extensibility: [planned extension points]
## Development Notes
<!--
REMINDERS:
- Update phase status as you progress: pending → in_progress → complete
- Re-read this plan before major decisions (attention manipulation)
- Log ALL errors - they help avoid repetition
- Never repeat a failed action - mutate your approach instead
- Always consider SOLID principles when making design decisions
- Read component AGENT.md files before modifying existing code
-->
- Update phase status as you progress: pending → in_progress → complete
- Re-read this plan before major decisions (attention manipulation)
- Log ALL errors - they help avoid repetition