spets 0.1.9 → 0.1.11
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -0,0 +1,460 @@
|
|
|
1
|
+
# Plan: {{title}}
|
|
2
|
+
|
|
3
|
+
## Summary
|
|
4
|
+
|
|
5
|
+
<!-- 2-3 sentences: What will be built, why it's needed, how it works -->
|
|
6
|
+
|
|
7
|
+
**Goal:** [One sentence describing the core objective]
|
|
8
|
+
|
|
9
|
+
**Architecture:** [2-3 sentences describing high-level approach]
|
|
10
|
+
|
|
11
|
+
**Tech Stack:** [Key technologies, libraries, or patterns involved]
|
|
12
|
+
|
|
13
|
+
## Codebase Analysis
|
|
14
|
+
|
|
15
|
+
### Current State
|
|
16
|
+
|
|
17
|
+
<!-- What exists NOW in the codebase -->
|
|
18
|
+
|
|
19
|
+
**Relevant Files Found:**
|
|
20
|
+
- `src/path/to/file.ts` - [What it does, why relevant]
|
|
21
|
+
- `src/path/to/other.ts` - [What it does, why relevant]
|
|
22
|
+
|
|
23
|
+
**Existing Patterns to Follow:**
|
|
24
|
+
- `src/services/auth.ts:45-78` - Authentication flow pattern
|
|
25
|
+
- WHY: Shows JWT creation and refresh handling structure
|
|
26
|
+
- `src/utils/validation.ts:sanitizeInput()` - Input sanitization pattern
|
|
27
|
+
- WHY: Must apply same sanitization approach for consistency
|
|
28
|
+
|
|
29
|
+
**Similar Features:**
|
|
30
|
+
- Feature X in `src/features/x/` - [How implemented, what to learn from it]
|
|
31
|
+
- Pattern Y in `src/patterns/y.ts` - [How structured, what to reuse]
|
|
32
|
+
|
|
33
|
+
**Testing Approach:**
|
|
34
|
+
- Testing library: [Jest/Vitest/etc]
|
|
35
|
+
- Test location: `src/**/*.test.ts` or `__tests__/`
|
|
36
|
+
- Example pattern: `src/__tests__/auth.test.ts:describe("login")` - [What pattern to follow]
|
|
37
|
+
|
|
38
|
+
### Key Findings
|
|
39
|
+
|
|
40
|
+
<!-- Important discoveries from exploration -->
|
|
41
|
+
|
|
42
|
+
**File Structure:**
|
|
43
|
+
- [Describe organization, where new files should go]
|
|
44
|
+
|
|
45
|
+
**Dependencies:**
|
|
46
|
+
- External: [npm packages used]
|
|
47
|
+
- Internal: [modules that will be imported]
|
|
48
|
+
|
|
49
|
+
**Code Conventions:**
|
|
50
|
+
- Naming: [camelCase, PascalCase patterns]
|
|
51
|
+
- File organization: [barrel exports, index files, etc]
|
|
52
|
+
- Error handling: [How errors are thrown/caught, example: `src/errors/AppError.ts`]
|
|
53
|
+
|
|
54
|
+
**Integration Points:**
|
|
55
|
+
- [Where this feature connects to existing code]
|
|
56
|
+
- [What interfaces/contracts must be maintained]
|
|
57
|
+
|
|
58
|
+
**Existing Utilities to Reuse:**
|
|
59
|
+
- `src/utils/logger.ts` - [How to use it]
|
|
60
|
+
- `src/utils/config.ts` - [How to use it]
|
|
61
|
+
|
|
62
|
+
## Architecture Decisions
|
|
63
|
+
|
|
64
|
+
### Chosen Approach: [Approach Name]
|
|
65
|
+
|
|
66
|
+
<!-- Detailed description of chosen approach -->
|
|
67
|
+
|
|
68
|
+
**How it works:**
|
|
69
|
+
1. [Step 1 of architecture]
|
|
70
|
+
2. [Step 2 of architecture]
|
|
71
|
+
3. [Step 3 of architecture]
|
|
72
|
+
|
|
73
|
+
**Why this approach:**
|
|
74
|
+
- Follows pattern from `src/path/file.ts:lines` - [Specific pattern]
|
|
75
|
+
- Consistent with existing [convention/pattern]
|
|
76
|
+
- Reuses existing [utility/helper]
|
|
77
|
+
- Simple and focused (avoids over-engineering)
|
|
78
|
+
|
|
79
|
+
**Pattern References:**
|
|
80
|
+
- `src/services/auth.ts:45-78` - Auth flow pattern (JWT creation, refresh)
|
|
81
|
+
- **Extract:** Token generation structure
|
|
82
|
+
- **Apply to:** Our new auth endpoint
|
|
83
|
+
- `src/types/user.ts:UserDTO` - Response type pattern
|
|
84
|
+
- **Extract:** Response shape consistency
|
|
85
|
+
- **Apply to:** Our new API response
|
|
86
|
+
|
|
87
|
+
### Alternatives Considered
|
|
88
|
+
|
|
89
|
+
**Alternative 1: [Name]**
|
|
90
|
+
- Description: [How it would work]
|
|
91
|
+
- Pros: [Advantages]
|
|
92
|
+
- Cons: [Disadvantages]
|
|
93
|
+
- Not chosen because: [Specific reason with evidence]
|
|
94
|
+
|
|
95
|
+
**Alternative 2: [Name]**
|
|
96
|
+
- Description: [How it would work]
|
|
97
|
+
- Pros: [Advantages]
|
|
98
|
+
- Cons: [Disadvantages]
|
|
99
|
+
- Not chosen because: [Specific reason with evidence]
|
|
100
|
+
|
|
101
|
+
### Test Strategy
|
|
102
|
+
|
|
103
|
+
**Chosen approach:** TDD (Red-Green-Refactor) / Tests After / Manual QA Only
|
|
104
|
+
|
|
105
|
+
**Rationale:** [Why this testing approach for this feature]
|
|
106
|
+
|
|
107
|
+
## Task Breakdown
|
|
108
|
+
|
|
109
|
+
<!-- CRITICAL: Each task should be 2-5 minutes MAXIMUM, with zero-context documentation -->
|
|
110
|
+
|
|
111
|
+
### Phase 1: [Phase Name - e.g., "Type Definitions & Infrastructure"]
|
|
112
|
+
|
|
113
|
+
#### Task 1: [Verb] [What] in [Specific File]
|
|
114
|
+
|
|
115
|
+
**File:** `src/exact/path/to/file.ts` (Create / Modify)
|
|
116
|
+
|
|
117
|
+
**Changes:**
|
|
118
|
+
- Add/Modify: [Specific function, interface, or logic]
|
|
119
|
+
- Code location: [Function name or around line X]
|
|
120
|
+
- Code sample (if helpful):
|
|
121
|
+
```typescript
|
|
122
|
+
// Follow pattern from src/example.ts:45
|
|
123
|
+
export interface ConfigType {
|
|
124
|
+
field1: string;
|
|
125
|
+
field2: number;
|
|
126
|
+
}
|
|
127
|
+
```
|
|
128
|
+
|
|
129
|
+
**Steps:**
|
|
130
|
+
1. [Granular step 1 with exact details]
|
|
131
|
+
2. [Granular step 2 with exact details]
|
|
132
|
+
3. [Granular step 3 with exact details]
|
|
133
|
+
4. [Commit changes with message: "..."]
|
|
134
|
+
|
|
135
|
+
**Verification:**
|
|
136
|
+
- [ ] Run: `npm run typecheck` (or specific command)
|
|
137
|
+
- [ ] Expected: No type errors
|
|
138
|
+
- [ ] Check: File exists at path and exports [specific items]
|
|
139
|
+
|
|
140
|
+
**Dependencies:** None / Requires Task X
|
|
141
|
+
|
|
142
|
+
**Parallelizable:** YES (with Task Y, Z) / NO
|
|
143
|
+
|
|
144
|
+
**Estimated Time:** 2-5 minutes
|
|
145
|
+
|
|
146
|
+
**Commit Message:** `feat: add ConfigType interface for [feature]`
|
|
147
|
+
|
|
148
|
+
---
|
|
149
|
+
|
|
150
|
+
#### Task 2: [Verb] [What] in [Specific File]
|
|
151
|
+
|
|
152
|
+
**File:** `src/exact/path/to/file.ts` (Create / Modify)
|
|
153
|
+
|
|
154
|
+
**Changes:**
|
|
155
|
+
- Add/Modify: [Specific function, interface, or logic]
|
|
156
|
+
- Code location: [Function name or around line X]
|
|
157
|
+
- Reference pattern: `src/reference/file.ts:123` - [What pattern to follow]
|
|
158
|
+
|
|
159
|
+
**Steps:**
|
|
160
|
+
1. [Granular step 1]
|
|
161
|
+
2. [Granular step 2]
|
|
162
|
+
3. [Granular step 3]
|
|
163
|
+
4. [Commit]
|
|
164
|
+
|
|
165
|
+
**Verification:**
|
|
166
|
+
- [ ] Run: `node -c src/exact/path/to/file.ts` (syntax check)
|
|
167
|
+
- [ ] Expected: No errors
|
|
168
|
+
- [ ] Check: Function exports correctly
|
|
169
|
+
|
|
170
|
+
**Dependencies:** Requires Task 1
|
|
171
|
+
|
|
172
|
+
**Parallelizable:** NO (sequential after Task 1)
|
|
173
|
+
|
|
174
|
+
**Estimated Time:** 3-5 minutes
|
|
175
|
+
|
|
176
|
+
**Commit Message:** `feat: implement [function] for [feature]`
|
|
177
|
+
|
|
178
|
+
---
|
|
179
|
+
|
|
180
|
+
### Phase 2: [Phase Name - e.g., "Core Implementation"]
|
|
181
|
+
|
|
182
|
+
<!-- Continue with tasks for this phase -->
|
|
183
|
+
|
|
184
|
+
---
|
|
185
|
+
|
|
186
|
+
### Phase 3: [Phase Name - e.g., "Testing"]
|
|
187
|
+
|
|
188
|
+
<!-- All test-related tasks -->
|
|
189
|
+
|
|
190
|
+
---
|
|
191
|
+
|
|
192
|
+
### Phase 4: [Phase Name - e.g., "Integration & Verification"]
|
|
193
|
+
|
|
194
|
+
<!-- Integration and final verification tasks -->
|
|
195
|
+
|
|
196
|
+
## Files to Modify
|
|
197
|
+
|
|
198
|
+
| File | Action | Description | Phase | Task # |
|
|
199
|
+
|------|--------|-------------|-------|---------|
|
|
200
|
+
| `src/types/config.ts` | Create | Type definitions for config | 1 | 1 |
|
|
201
|
+
| `src/utils/helper.ts` | Modify | Add new helper function | 2 | 3, 4 |
|
|
202
|
+
| `src/services/api.ts` | Modify | Integrate new endpoint | 2 | 5 |
|
|
203
|
+
| `src/__tests__/helper.test.ts` | Create | Unit tests for helper | 3 | 6 |
|
|
204
|
+
| `src/__tests__/api.test.ts` | Modify | Integration tests | 3 | 7 |
|
|
205
|
+
|
|
206
|
+
## Testing Strategy
|
|
207
|
+
|
|
208
|
+
### Test Approach
|
|
209
|
+
|
|
210
|
+
**Strategy:** TDD (Red-Green-Refactor) / Tests After / Manual QA Only
|
|
211
|
+
|
|
212
|
+
**Rationale:** [Why this approach for this feature]
|
|
213
|
+
|
|
214
|
+
### Unit Tests
|
|
215
|
+
|
|
216
|
+
**Test file:** `src/**/*.test.ts` or `src/**/*.spec.ts` (follow existing convention)
|
|
217
|
+
|
|
218
|
+
**Testing library:** [Jest/Vitest/etc - based on existing patterns]
|
|
219
|
+
|
|
220
|
+
**Reference pattern:** `src/__tests__/auth.test.ts:describe("login")` - Follow this structure
|
|
221
|
+
|
|
222
|
+
**Test cases to implement:**
|
|
223
|
+
|
|
224
|
+
**Happy Path:**
|
|
225
|
+
- [ ] Test Case 1: [Specific scenario] - Expected: [Specific result]
|
|
226
|
+
- [ ] Test Case 2: [Specific scenario] - Expected: [Specific result]
|
|
227
|
+
|
|
228
|
+
**Edge Cases:**
|
|
229
|
+
- [ ] Edge Case 1: [Empty input] - Expected: [How handled]
|
|
230
|
+
- [ ] Edge Case 2: [Boundary value] - Expected: [How handled]
|
|
231
|
+
- [ ] Edge Case 3: [Maximum value] - Expected: [How handled]
|
|
232
|
+
|
|
233
|
+
**Error Cases:**
|
|
234
|
+
- [ ] Error Case 1: [Invalid input] - Expected: [Error thrown/returned]
|
|
235
|
+
- [ ] Error Case 2: [Missing data] - Expected: [Error thrown/returned]
|
|
236
|
+
- [ ] Error Case 3: [Network failure] - Expected: [Error thrown/returned]
|
|
237
|
+
|
|
238
|
+
**Verification Commands:**
|
|
239
|
+
```bash
|
|
240
|
+
# Run specific test file
|
|
241
|
+
npm test src/__tests__/helper.test.ts
|
|
242
|
+
|
|
243
|
+
# Run all tests
|
|
244
|
+
npm test
|
|
245
|
+
|
|
246
|
+
# Run with coverage
|
|
247
|
+
npm test -- --coverage
|
|
248
|
+
```
|
|
249
|
+
|
|
250
|
+
### Integration Tests
|
|
251
|
+
|
|
252
|
+
**Integration scenarios:**
|
|
253
|
+
- [ ] Scenario 1: [Feature X integrates with Y]
|
|
254
|
+
- Command: `npm test -- integration`
|
|
255
|
+
- Expected: [Specific outcome]
|
|
256
|
+
- [ ] Scenario 2: [End-to-end flow]
|
|
257
|
+
- Command: [Specific command]
|
|
258
|
+
- Expected: [Specific outcome]
|
|
259
|
+
|
|
260
|
+
### Manual Verification
|
|
261
|
+
|
|
262
|
+
**Manual testing checklist:**
|
|
263
|
+
- [ ] Start application: `npm run dev`
|
|
264
|
+
- [ ] Navigate to [specific URL/page]
|
|
265
|
+
- [ ] Perform action: [Specific user action]
|
|
266
|
+
- [ ] Verify: [Specific expected outcome]
|
|
267
|
+
- [ ] Check console: No errors or warnings
|
|
268
|
+
- [ ] Check network tab: [Expected requests/responses]
|
|
269
|
+
|
|
270
|
+
**Environment:** Development / Staging / Production
|
|
271
|
+
|
|
272
|
+
**Browser compatibility (if applicable):**
|
|
273
|
+
- [ ] Chrome
|
|
274
|
+
- [ ] Firefox
|
|
275
|
+
- [ ] Safari
|
|
276
|
+
|
|
277
|
+
## Acceptance Criteria
|
|
278
|
+
|
|
279
|
+
<!-- Concrete, verifiable checklist -->
|
|
280
|
+
|
|
281
|
+
### Implementation Complete
|
|
282
|
+
- [ ] All tasks in all phases completed as specified
|
|
283
|
+
- [ ] All files created/modified as planned
|
|
284
|
+
- [ ] All verification commands pass
|
|
285
|
+
- [ ] Code committed with proper messages
|
|
286
|
+
|
|
287
|
+
### Tests Passing
|
|
288
|
+
- [ ] All unit tests passing: `npm test`
|
|
289
|
+
- [ ] All integration tests passing: `npm test -- integration`
|
|
290
|
+
- [ ] Test coverage ≥ [X%] for new code: `npm test -- --coverage`
|
|
291
|
+
- [ ] No flaky tests (all tests pass consistently)
|
|
292
|
+
|
|
293
|
+
### Code Quality
|
|
294
|
+
- [ ] No linting errors: `npm run lint`
|
|
295
|
+
- [ ] No type errors: `npm run typecheck`
|
|
296
|
+
- [ ] Build succeeds: `npm run build`
|
|
297
|
+
- [ ] Code follows existing patterns (matches reference files)
|
|
298
|
+
- [ ] No commented-out code
|
|
299
|
+
- [ ] No debug console.logs
|
|
300
|
+
|
|
301
|
+
### Functionality
|
|
302
|
+
- [ ] Manual verification checklist complete
|
|
303
|
+
- [ ] Happy path works as expected
|
|
304
|
+
- [ ] Edge cases handled appropriately
|
|
305
|
+
- [ ] Error cases show proper error messages
|
|
306
|
+
- [ ] No console errors or warnings
|
|
307
|
+
|
|
308
|
+
### Non-Regression
|
|
309
|
+
- [ ] Existing tests still pass
|
|
310
|
+
- [ ] No breaking changes to public APIs
|
|
311
|
+
- [ ] Existing features unaffected
|
|
312
|
+
|
|
313
|
+
**Status:** ✅ All criteria must be checked before considering feature complete
|
|
314
|
+
|
|
315
|
+
## Risks & Considerations
|
|
316
|
+
|
|
317
|
+
### Technical Risks
|
|
318
|
+
|
|
319
|
+
- **Risk 1**: [Specific technical risk]
|
|
320
|
+
- **Impact:** [What could go wrong]
|
|
321
|
+
- **Mitigation:** [Concrete steps to prevent/handle]
|
|
322
|
+
- **Contingency:** [Backup plan if mitigation fails]
|
|
323
|
+
|
|
324
|
+
- **Risk 2**: [Specific technical risk]
|
|
325
|
+
- **Impact:** [What could go wrong]
|
|
326
|
+
- **Mitigation:** [Concrete steps to prevent/handle]
|
|
327
|
+
- **Contingency:** [Backup plan if mitigation fails]
|
|
328
|
+
|
|
329
|
+
### Edge Cases
|
|
330
|
+
|
|
331
|
+
- **Empty/Null Input**
|
|
332
|
+
- Scenario: [When this happens]
|
|
333
|
+
- Handling: [How code handles it]
|
|
334
|
+
- Test coverage: Task #[X]
|
|
335
|
+
|
|
336
|
+
- **Boundary Values**
|
|
337
|
+
- Scenario: [Min/max values, array boundaries]
|
|
338
|
+
- Handling: [How code handles it]
|
|
339
|
+
- Test coverage: Task #[X]
|
|
340
|
+
|
|
341
|
+
- **Race Conditions (if applicable)**
|
|
342
|
+
- Scenario: [Concurrent access/updates]
|
|
343
|
+
- Handling: [Locking, atomicity approach]
|
|
344
|
+
- Test coverage: Task #[X]
|
|
345
|
+
|
|
346
|
+
### Dependencies
|
|
347
|
+
|
|
348
|
+
**External Dependencies:**
|
|
349
|
+
- Package: `[package-name]` (version [X.Y.Z])
|
|
350
|
+
- Purpose: [What it's used for]
|
|
351
|
+
- Impact: [What breaks if it fails]
|
|
352
|
+
|
|
353
|
+
**Internal Dependencies:**
|
|
354
|
+
- Module: `src/path/to/module.ts`
|
|
355
|
+
- Purpose: [What it provides]
|
|
356
|
+
- Impact: Changes require Task #[X] update
|
|
357
|
+
|
|
358
|
+
**Breaking Changes:**
|
|
359
|
+
- None / [Specific breaking changes]
|
|
360
|
+
- Migration path: [How to update existing code]
|
|
361
|
+
- Affected code: [Files/modules that need updates]
|
|
362
|
+
|
|
363
|
+
### Performance Considerations
|
|
364
|
+
|
|
365
|
+
- **Performance Impact:** Low / Medium / High
|
|
366
|
+
- **Specific concerns:**
|
|
367
|
+
- [Concern 1: e.g., "Large array iteration"]
|
|
368
|
+
- Mitigation: [e.g., "Use pagination"]
|
|
369
|
+
- [Concern 2: e.g., "Expensive computation"]
|
|
370
|
+
- Mitigation: [e.g., "Cache results"]
|
|
371
|
+
|
|
372
|
+
## Implementation Notes
|
|
373
|
+
|
|
374
|
+
<!-- Critical context for implementer -->
|
|
375
|
+
|
|
376
|
+
### Code Patterns to Follow
|
|
377
|
+
|
|
378
|
+
**Pattern 1: [Pattern name]**
|
|
379
|
+
```typescript
|
|
380
|
+
// Reference: src/example/file.ts:45-67
|
|
381
|
+
// Use this pattern for [specific case]
|
|
382
|
+
|
|
383
|
+
export function example(param: Type): ReturnType {
|
|
384
|
+
// Follow this structure
|
|
385
|
+
const result = processData(param);
|
|
386
|
+
return result;
|
|
387
|
+
}
|
|
388
|
+
```
|
|
389
|
+
|
|
390
|
+
**Pattern 2: [Pattern name]**
|
|
391
|
+
```typescript
|
|
392
|
+
// Reference: src/other/file.ts:123-145
|
|
393
|
+
// Use this pattern for [specific case]
|
|
394
|
+
```
|
|
395
|
+
|
|
396
|
+
### Gotchas & Pitfalls
|
|
397
|
+
|
|
398
|
+
- **Gotcha 1**: [Specific thing to watch out for]
|
|
399
|
+
- Why it matters: [Consequence if ignored]
|
|
400
|
+
- How to avoid: [Specific action]
|
|
401
|
+
|
|
402
|
+
- **Gotcha 2**: [Specific thing to watch out for]
|
|
403
|
+
- Why it matters: [Consequence if ignored]
|
|
404
|
+
- How to avoid: [Specific action]
|
|
405
|
+
|
|
406
|
+
### Common Mistakes to Avoid
|
|
407
|
+
|
|
408
|
+
- ❌ Don't [specific anti-pattern] - [Why it's wrong]
|
|
409
|
+
- ❌ Don't [specific anti-pattern] - [Why it's wrong]
|
|
410
|
+
- ✅ Do [correct pattern] - [Why it's right]
|
|
411
|
+
|
|
412
|
+
### Debugging Tips
|
|
413
|
+
|
|
414
|
+
- If [specific problem], check [specific location/log]
|
|
415
|
+
- If tests fail with [specific error], likely cause is [root cause]
|
|
416
|
+
|
|
417
|
+
---
|
|
418
|
+
|
|
419
|
+
## Task Flow Visualization
|
|
420
|
+
|
|
421
|
+
```
|
|
422
|
+
Phase 1 (Infrastructure)
|
|
423
|
+
Task 1 → Task 2
|
|
424
|
+
↓
|
|
425
|
+
Task 3 (parallel with 4)
|
|
426
|
+
Task 4 (parallel with 3)
|
|
427
|
+
|
|
428
|
+
Phase 2 (Implementation)
|
|
429
|
+
Task 5 (depends on 2, 3, 4)
|
|
430
|
+
↓
|
|
431
|
+
Task 6 → Task 7
|
|
432
|
+
|
|
433
|
+
Phase 3 (Testing)
|
|
434
|
+
Task 8 → Task 9 → Task 10
|
|
435
|
+
|
|
436
|
+
Phase 4 (Verification)
|
|
437
|
+
Task 11 (depends on all previous)
|
|
438
|
+
```
|
|
439
|
+
|
|
440
|
+
## Estimated Effort
|
|
441
|
+
|
|
442
|
+
- **Total phases:** [X]
|
|
443
|
+
- **Total tasks:** [Y]
|
|
444
|
+
- **Estimated time:** [Z minutes] (sum of all task estimates)
|
|
445
|
+
- **Complexity:** Low / Medium / High
|
|
446
|
+
- **Parallelization opportunities:** [X tasks can run in parallel]
|
|
447
|
+
|
|
448
|
+
---
|
|
449
|
+
|
|
450
|
+
## Plan Completion Checklist
|
|
451
|
+
|
|
452
|
+
Before submitting this plan, verify:
|
|
453
|
+
- [ ] ALL tasks are 2-5 minutes with exact file paths
|
|
454
|
+
- [ ] ≥80% of tasks reference specific existing code (file:line)
|
|
455
|
+
- [ ] EVERY task has concrete verification (command + expected output)
|
|
456
|
+
- [ ] Zero assumptions about business logic or patterns
|
|
457
|
+
- [ ] Test strategy decided and documented
|
|
458
|
+
- [ ] Dependencies and parallelization marked
|
|
459
|
+
- [ ] Phase organization logical and complete
|
|
460
|
+
- [ ] One complete plan (not split into multiple phases to plan later)
|