make-it-done 0.1.0
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.
- package/README.md +263 -0
- package/agents/.gitkeep +0 -0
- package/agents/mid-debugger.md +88 -0
- package/agents/mid-executor.md +69 -0
- package/agents/mid-planner.md +97 -0
- package/agents/mid-researcher.md +101 -0
- package/agents/mid-verifier.md +92 -0
- package/bin/install.js +122 -0
- package/commands/mid/.gitkeep +0 -0
- package/commands/mid/debug.md +19 -0
- package/commands/mid/do.md +24 -0
- package/commands/mid/help.md +77 -0
- package/commands/mid/init.md +18 -0
- package/commands/mid/next.md +18 -0
- package/commands/mid/plan.md +21 -0
- package/commands/mid/quick.md +24 -0
- package/commands/mid/report.md +16 -0
- package/commands/mid/status.md +16 -0
- package/commands/mid/verify.md +19 -0
- package/makeitdone/bin/mid-tools.cjs +2048 -0
- package/makeitdone/steps/agent-contracts.md +184 -0
- package/makeitdone/steps/anti-patterns.md +291 -0
- package/makeitdone/steps/context-budget.md +157 -0
- package/makeitdone/steps/init-gate.md +42 -0
- package/makeitdone/steps/model-route.md +70 -0
- package/makeitdone/steps/state-read.md +56 -0
- package/makeitdone/templates/plan.md +94 -0
- package/makeitdone/templates/project.md +62 -0
- package/makeitdone/templates/requirements.md +97 -0
- package/makeitdone/templates/roadmap.md +111 -0
- package/makeitdone/templates/state.md +28 -0
- package/makeitdone/templates/summary.md +58 -0
- package/makeitdone/workflows/debug.md +135 -0
- package/makeitdone/workflows/execute.md +218 -0
- package/makeitdone/workflows/init.md +113 -0
- package/makeitdone/workflows/next.md +114 -0
- package/makeitdone/workflows/plan.md +231 -0
- package/makeitdone/workflows/quick.md +151 -0
- package/makeitdone/workflows/report.md +138 -0
- package/makeitdone/workflows/status.md +135 -0
- package/makeitdone/workflows/verify.md +177 -0
- package/package.json +50 -0
|
@@ -0,0 +1,70 @@
|
|
|
1
|
+
# Model Routing Pattern
|
|
2
|
+
|
|
3
|
+
Route Claude models based on task complexity and context window.
|
|
4
|
+
|
|
5
|
+
## Profiles
|
|
6
|
+
|
|
7
|
+
From config.json `model_profile` field:
|
|
8
|
+
|
|
9
|
+
| Profile | Executor | Verifier | Use Case |
|
|
10
|
+
|---------|----------|----------|----------|
|
|
11
|
+
| **budget** | haiku | haiku | Token-constrained, simple tasks |
|
|
12
|
+
| **balanced** | sonnet | haiku | Default, good speed/quality trade-off |
|
|
13
|
+
| **quality** | opus | sonnet | Complex design, safety-critical code |
|
|
14
|
+
|
|
15
|
+
## Context Window Tiers
|
|
16
|
+
|
|
17
|
+
Based on `context_window` from config.json:
|
|
18
|
+
|
|
19
|
+
| Range | Tier | Behavior |
|
|
20
|
+
|-------|------|----------|
|
|
21
|
+
| < 300k | **POOR** | Read-only, no generation, agent spawn disabled |
|
|
22
|
+
| 300-500k | **DEGRADING** | Frontmatter-only reads, small tasks only |
|
|
23
|
+
| 500k-1M | **GOOD** | Full reads, normal task complexity |
|
|
24
|
+
| > 1M | **PEAK** | All features enabled, complex synthesis |
|
|
25
|
+
|
|
26
|
+
## Model Selection Logic
|
|
27
|
+
|
|
28
|
+
```
|
|
29
|
+
if tier == POOR:
|
|
30
|
+
disable agents, return "context too low"
|
|
31
|
+
|
|
32
|
+
if tier == DEGRADING:
|
|
33
|
+
use haiku for all work
|
|
34
|
+
forbid agents
|
|
35
|
+
use frontmatter-only reads
|
|
36
|
+
|
|
37
|
+
if tier == GOOD:
|
|
38
|
+
use config model_profile routing
|
|
39
|
+
enable research agent if --research
|
|
40
|
+
|
|
41
|
+
if tier == PEAK:
|
|
42
|
+
use config model_profile routing
|
|
43
|
+
enable all agents
|
|
44
|
+
parallelization enabled
|
|
45
|
+
```
|
|
46
|
+
|
|
47
|
+
## Practical Usage in Workflows
|
|
48
|
+
|
|
49
|
+
```
|
|
50
|
+
<context>
|
|
51
|
+
context_window: (mid-tools config get context_window)
|
|
52
|
+
model_profile: (mid-tools config get model_profile)
|
|
53
|
+
</context>
|
|
54
|
+
|
|
55
|
+
Determine Tier:
|
|
56
|
+
- If context_window < 300k: POOR tier → escalate to user
|
|
57
|
+
- If context_window < 500k: DEGRADING tier → frontmatter-only reads
|
|
58
|
+
- Else: Use normal read strategy
|
|
59
|
+
|
|
60
|
+
Route Executor:
|
|
61
|
+
- budget: use haiku
|
|
62
|
+
- balanced: use sonnet
|
|
63
|
+
- quality: use opus
|
|
64
|
+
```
|
|
65
|
+
|
|
66
|
+
## Anti-patterns
|
|
67
|
+
|
|
68
|
+
- Ignoring context_window (causes context exhaustion)
|
|
69
|
+
- Using opus for verification (wastes tokens)
|
|
70
|
+
- Not adjusting for POOR tier (causes failures)
|
|
@@ -0,0 +1,56 @@
|
|
|
1
|
+
# State Read Pattern
|
|
2
|
+
|
|
3
|
+
Token-optimized STATE.md reading with context window guard.
|
|
4
|
+
|
|
5
|
+
## Pattern
|
|
6
|
+
|
|
7
|
+
```bash
|
|
8
|
+
# Check context
|
|
9
|
+
if context_window < 500k:
|
|
10
|
+
FRONTMATTER=$(node ~/.claude/makeitdone/bin/mid-tools.cjs fm get .planning/STATE.md)
|
|
11
|
+
else:
|
|
12
|
+
STATE=$(node ~/.claude/makeitdone/bin/mid-tools.cjs state get)
|
|
13
|
+
```
|
|
14
|
+
|
|
15
|
+
## Frontmatter-Only Read (< 500k tokens)
|
|
16
|
+
|
|
17
|
+
When context is tight, read only frontmatter:
|
|
18
|
+
```bash
|
|
19
|
+
mid-tools fm get .planning/STATE.md
|
|
20
|
+
```
|
|
21
|
+
|
|
22
|
+
Returns TOON with only:
|
|
23
|
+
```
|
|
24
|
+
phase: 1
|
|
25
|
+
current_wave: 1
|
|
26
|
+
wave_1_complete: false
|
|
27
|
+
wave_2_complete: false
|
|
28
|
+
...
|
|
29
|
+
```
|
|
30
|
+
|
|
31
|
+
## Full State Read (>= 500k tokens)
|
|
32
|
+
|
|
33
|
+
When context is abundant:
|
|
34
|
+
```bash
|
|
35
|
+
mid-tools state get
|
|
36
|
+
```
|
|
37
|
+
|
|
38
|
+
Returns TOON with entire STATE.md frontmatter + body structure.
|
|
39
|
+
|
|
40
|
+
## Atomic State Updates
|
|
41
|
+
|
|
42
|
+
Always use mid-tools for writes (never write STATE.md directly):
|
|
43
|
+
|
|
44
|
+
```bash
|
|
45
|
+
# Set single field
|
|
46
|
+
mid-tools state set current_wave 2
|
|
47
|
+
|
|
48
|
+
# Advance to next phase
|
|
49
|
+
mid-tools state advance 2
|
|
50
|
+
```
|
|
51
|
+
|
|
52
|
+
## Anti-patterns
|
|
53
|
+
|
|
54
|
+
- Never write STATE.md directly
|
|
55
|
+
- Never load full STATE.md if context < 500k (use fm)
|
|
56
|
+
- Never update multiple fields without atomic operation
|
|
@@ -0,0 +1,94 @@
|
|
|
1
|
+
---
|
|
2
|
+
phase: 1
|
|
3
|
+
phase_name: Foundation
|
|
4
|
+
tasks: 8
|
|
5
|
+
estimated_hours: 16
|
|
6
|
+
waves: 2
|
|
7
|
+
acceptance_criteria: 8
|
|
8
|
+
dependencies: []
|
|
9
|
+
---
|
|
10
|
+
|
|
11
|
+
# Phase 1 Plan: Foundation
|
|
12
|
+
|
|
13
|
+
## Overview
|
|
14
|
+
|
|
15
|
+
Establish project infrastructure, authentication, and core data models.
|
|
16
|
+
|
|
17
|
+
**Target**: 16 hours / 2 weeks / 2 waves
|
|
18
|
+
|
|
19
|
+
---
|
|
20
|
+
|
|
21
|
+
## Wave 1: Infrastructure & Auth (6 tasks, ~8 hours)
|
|
22
|
+
|
|
23
|
+
### 01-01 Project Setup
|
|
24
|
+
- User stories: US-Setup-001
|
|
25
|
+
- Create git repo, CI/CD pipeline, Docker setup
|
|
26
|
+
- Tests: setup.test.ts
|
|
27
|
+
- Acceptance: CI passes, Docker builds, README complete
|
|
28
|
+
|
|
29
|
+
### 01-02 Database Schema
|
|
30
|
+
- User stories: US-Data-001, US-Data-002
|
|
31
|
+
- Design and implement core tables (users, data)
|
|
32
|
+
- Tests: schema.test.ts
|
|
33
|
+
- Acceptance: Migrations run, schema documented
|
|
34
|
+
|
|
35
|
+
### 01-03 Authentication System
|
|
36
|
+
- User stories: US-Auth-001, US-Auth-002
|
|
37
|
+
- JWT implementation, login/logout endpoints
|
|
38
|
+
- Tests: auth.test.ts (> 80% coverage)
|
|
39
|
+
- Acceptance: Login works, tokens refresh, security review passed
|
|
40
|
+
|
|
41
|
+
### 01-04 User Model
|
|
42
|
+
- User stories: US-User-001
|
|
43
|
+
- User model, validation, serialization
|
|
44
|
+
- Tests: user.test.ts
|
|
45
|
+
- Acceptance: Model works, validation complete
|
|
46
|
+
|
|
47
|
+
### 01-05 API Foundation
|
|
48
|
+
- User stories: US-API-001
|
|
49
|
+
- API server setup, routing, middleware
|
|
50
|
+
- Tests: api.test.ts
|
|
51
|
+
- Acceptance: Server runs, endpoints respond
|
|
52
|
+
|
|
53
|
+
### 01-06 Documentation
|
|
54
|
+
- User stories: US-Docs-001
|
|
55
|
+
- API docs (OpenAPI/Postman), README
|
|
56
|
+
- Tests: docs validation
|
|
57
|
+
- Acceptance: Docs complete, links valid
|
|
58
|
+
|
|
59
|
+
---
|
|
60
|
+
|
|
61
|
+
## Wave 2: Testing & Polish (2 tasks, ~8 hours)
|
|
62
|
+
|
|
63
|
+
### 01-07 Integration Tests
|
|
64
|
+
- User stories: US-Test-001
|
|
65
|
+
- End-to-end auth flow, data consistency
|
|
66
|
+
- Tests: integration.test.ts
|
|
67
|
+
- Acceptance: All flows pass, coverage > 80%
|
|
68
|
+
|
|
69
|
+
### 01-08 Security Audit & Fixes
|
|
70
|
+
- User stories: US-Security-001
|
|
71
|
+
- OWASP top 10 check, CVE scan
|
|
72
|
+
- Tests: security.test.ts
|
|
73
|
+
- Acceptance: No critical/high vulns, audit report
|
|
74
|
+
|
|
75
|
+
---
|
|
76
|
+
|
|
77
|
+
## Acceptance Criteria (for Phase Complete)
|
|
78
|
+
|
|
79
|
+
1. ✓ All 8 tasks completed with SUMMARY.md
|
|
80
|
+
2. ✓ Unit test coverage > 80%
|
|
81
|
+
3. ✓ Integration tests pass
|
|
82
|
+
4. ✓ Security audit passed
|
|
83
|
+
5. ✓ API documentation complete
|
|
84
|
+
6. ✓ README and setup guide done
|
|
85
|
+
7. ✓ Code reviewed (2+ approvals)
|
|
86
|
+
8. ✓ Deployed to staging environment
|
|
87
|
+
|
|
88
|
+
---
|
|
89
|
+
|
|
90
|
+
## Notes
|
|
91
|
+
|
|
92
|
+
- Wave 1 can be parallelized (01-02, 01-03, 01-04 independent)
|
|
93
|
+
- Wave 2 requires Wave 1 complete
|
|
94
|
+
- Estimated 16-20 hours total (accounting for meetings, reviews)
|
|
@@ -0,0 +1,62 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: Project Name
|
|
3
|
+
description: |
|
|
4
|
+
One-line project description / mission statement
|
|
5
|
+
created: 2026-04-05
|
|
6
|
+
owner: User Name
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
# Project Overview
|
|
10
|
+
|
|
11
|
+
## Vision
|
|
12
|
+
|
|
13
|
+
What is this project about? What does it accomplish?
|
|
14
|
+
|
|
15
|
+
## Goals
|
|
16
|
+
|
|
17
|
+
- Goal 1: Clear, measurable outcome
|
|
18
|
+
- Goal 2: Must have (vs nice-to-have)
|
|
19
|
+
- Goal 3: Success criteria
|
|
20
|
+
|
|
21
|
+
## Scope
|
|
22
|
+
|
|
23
|
+
What's IN scope:
|
|
24
|
+
- Feature A
|
|
25
|
+
- Feature B
|
|
26
|
+
|
|
27
|
+
What's OUT of scope:
|
|
28
|
+
- Non-goal 1
|
|
29
|
+
- Non-goal 2
|
|
30
|
+
|
|
31
|
+
## Key Constraints
|
|
32
|
+
|
|
33
|
+
- **Timeline**: Estimate in weeks (if applicable)
|
|
34
|
+
- **Tech Stack**: Framework/language choices and why
|
|
35
|
+
- **Team**: Who's involved? Roles?
|
|
36
|
+
|
|
37
|
+
## Success Metrics
|
|
38
|
+
|
|
39
|
+
How do we know this is done?
|
|
40
|
+
- Metric 1: Measurable, objective
|
|
41
|
+
- Metric 2: User feedback / adoption
|
|
42
|
+
- Metric 3: Performance / quality baseline
|
|
43
|
+
|
|
44
|
+
---
|
|
45
|
+
|
|
46
|
+
## Dependencies
|
|
47
|
+
|
|
48
|
+
- External APIs or services required?
|
|
49
|
+
- Third-party libraries or frameworks?
|
|
50
|
+
- Data or configurations needed from elsewhere?
|
|
51
|
+
|
|
52
|
+
## Risks & Mitigations
|
|
53
|
+
|
|
54
|
+
| Risk | Impact | Mitigation |
|
|
55
|
+
|------|--------|-----------|
|
|
56
|
+
| Technical debt from old codebase | High | Allocate refactor phase |
|
|
57
|
+
| Resource constraints | Medium | Prioritize MVP features |
|
|
58
|
+
|
|
59
|
+
## Next Steps
|
|
60
|
+
|
|
61
|
+
See REQUIREMENTS.md for detailed requirements.
|
|
62
|
+
See ROADMAP.md for phase breakdown.
|
|
@@ -0,0 +1,97 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: Requirements
|
|
3
|
+
description: Functional and non-functional requirements
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Requirements
|
|
7
|
+
|
|
8
|
+
## Functional Requirements
|
|
9
|
+
|
|
10
|
+
### User Stories
|
|
11
|
+
|
|
12
|
+
**US-001: User can authenticate**
|
|
13
|
+
- As a user, I can log in with email/password
|
|
14
|
+
- Acceptance: Login form appears, credentials validated, JWT token issued
|
|
15
|
+
- Status: Not started
|
|
16
|
+
|
|
17
|
+
**US-002: User can view dashboard**
|
|
18
|
+
- As an authenticated user, I can see my dashboard
|
|
19
|
+
- Acceptance: Dashboard loads, shows user data, respects permissions
|
|
20
|
+
- Status: Not started
|
|
21
|
+
|
|
22
|
+
### Features
|
|
23
|
+
|
|
24
|
+
| Feature | Priority | Story Points | Status |
|
|
25
|
+
|---------|----------|--------------|--------|
|
|
26
|
+
| Authentication | Must-have | 8 | Not started |
|
|
27
|
+
| Dashboard | Must-have | 13 | Not started |
|
|
28
|
+
| Data Export | Nice-to-have | 5 | Backlog |
|
|
29
|
+
|
|
30
|
+
---
|
|
31
|
+
|
|
32
|
+
## Non-Functional Requirements
|
|
33
|
+
|
|
34
|
+
### Performance
|
|
35
|
+
|
|
36
|
+
- Page load time: < 2s (P95)
|
|
37
|
+
- API response: < 200ms (P95)
|
|
38
|
+
- Database query: < 50ms (P95)
|
|
39
|
+
|
|
40
|
+
### Scalability
|
|
41
|
+
|
|
42
|
+
- Support 1000+ concurrent users
|
|
43
|
+
- Horizontal scaling via load balancer
|
|
44
|
+
- Auto-scaling based on CPU/memory
|
|
45
|
+
|
|
46
|
+
### Security
|
|
47
|
+
|
|
48
|
+
- Password hashing (bcrypt, min 12 rounds)
|
|
49
|
+
- HTTPS-only (no HTTP)
|
|
50
|
+
- CSRF protection on forms
|
|
51
|
+
- SQL injection protection via ORM/parameterized queries
|
|
52
|
+
- Rate limiting on login (5 attempts / 15 min)
|
|
53
|
+
|
|
54
|
+
### Reliability
|
|
55
|
+
|
|
56
|
+
- 99.9% uptime SLA
|
|
57
|
+
- Database backups (daily)
|
|
58
|
+
- Disaster recovery plan
|
|
59
|
+
- Monitoring & alerting
|
|
60
|
+
|
|
61
|
+
### Accessibility
|
|
62
|
+
|
|
63
|
+
- WCAG 2.1 Level AA compliance
|
|
64
|
+
- Keyboard navigation
|
|
65
|
+
- Screen reader support
|
|
66
|
+
|
|
67
|
+
---
|
|
68
|
+
|
|
69
|
+
## Acceptance Criteria (for phase completion)
|
|
70
|
+
|
|
71
|
+
Phase must meet ALL of these:
|
|
72
|
+
|
|
73
|
+
1. ✓ All unit tests pass (> 80% coverage)
|
|
74
|
+
2. ✓ Integration tests pass
|
|
75
|
+
3. ✓ Security scan passes (no critical/high vulnerabilities)
|
|
76
|
+
4. ✓ Performance benchmarks meet targets
|
|
77
|
+
5. ✓ Documentation updated (README, API docs)
|
|
78
|
+
6. ✓ Code review passed (2 approvals)
|
|
79
|
+
7. ✓ Manual QA sign-off
|
|
80
|
+
|
|
81
|
+
---
|
|
82
|
+
|
|
83
|
+
## Constraints
|
|
84
|
+
|
|
85
|
+
- **Technology**: Must use [framework/language]
|
|
86
|
+
- **Platform**: Target [browser/OS/device]
|
|
87
|
+
- **Data**: Comply with [regulation: GDPR/CCPA/etc]
|
|
88
|
+
- **Timeline**: Soft deadline [date]
|
|
89
|
+
|
|
90
|
+
---
|
|
91
|
+
|
|
92
|
+
## Open Questions
|
|
93
|
+
|
|
94
|
+
- [ ] Question 1: Details?
|
|
95
|
+
- [ ] Question 2: Details?
|
|
96
|
+
|
|
97
|
+
*Once planning phase completes, update this section with answers.*
|
|
@@ -0,0 +1,111 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: Roadmap
|
|
3
|
+
description: Phase breakdown and timeline
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Roadmap
|
|
7
|
+
|
|
8
|
+
## Phase Summary
|
|
9
|
+
|
|
10
|
+
Total phases: [N]
|
|
11
|
+
Timeline: [approx weeks]
|
|
12
|
+
Current phase: 1
|
|
13
|
+
|
|
14
|
+
---
|
|
15
|
+
|
|
16
|
+
## 01 - Foundation [not-started]
|
|
17
|
+
|
|
18
|
+
**Goal**: Set up infrastructure, authentication, data models
|
|
19
|
+
|
|
20
|
+
**Milestone**: Foundation ready for feature development
|
|
21
|
+
|
|
22
|
+
**Dependencies**: None (project start)
|
|
23
|
+
|
|
24
|
+
**Deliverables**:
|
|
25
|
+
- Project structure
|
|
26
|
+
- CI/CD pipeline
|
|
27
|
+
- Authentication system
|
|
28
|
+
- Core data models
|
|
29
|
+
- Database schema
|
|
30
|
+
|
|
31
|
+
**Duration**: 1-2 weeks
|
|
32
|
+
|
|
33
|
+
---
|
|
34
|
+
|
|
35
|
+
## 02 - Core Features [not-started]
|
|
36
|
+
|
|
37
|
+
**Goal**: Implement primary user-facing features
|
|
38
|
+
|
|
39
|
+
**Milestone**: MVP ready for internal testing
|
|
40
|
+
|
|
41
|
+
**Dependencies**: Phase 1 complete
|
|
42
|
+
|
|
43
|
+
**Deliverables**:
|
|
44
|
+
- Dashboard
|
|
45
|
+
- Data management UI
|
|
46
|
+
- API endpoints
|
|
47
|
+
- Admin panel
|
|
48
|
+
|
|
49
|
+
**Duration**: 2-3 weeks
|
|
50
|
+
|
|
51
|
+
---
|
|
52
|
+
|
|
53
|
+
## 03 - Refinement [not-started]
|
|
54
|
+
|
|
55
|
+
**Goal**: Polish, optimize, security hardening
|
|
56
|
+
|
|
57
|
+
**Milestone**: Ready for production release
|
|
58
|
+
|
|
59
|
+
**Dependencies**: Phase 2 complete
|
|
60
|
+
|
|
61
|
+
**Deliverables**:
|
|
62
|
+
- Performance optimization
|
|
63
|
+
- Security audit fixes
|
|
64
|
+
- Documentation
|
|
65
|
+
- User guide
|
|
66
|
+
|
|
67
|
+
**Duration**: 1-2 weeks
|
|
68
|
+
|
|
69
|
+
---
|
|
70
|
+
|
|
71
|
+
## 04 - Launch [not-started]
|
|
72
|
+
|
|
73
|
+
**Goal**: Deploy to production, monitor, support
|
|
74
|
+
|
|
75
|
+
**Milestone**: Live and stable
|
|
76
|
+
|
|
77
|
+
**Dependencies**: Phase 3 complete
|
|
78
|
+
|
|
79
|
+
**Deliverables**:
|
|
80
|
+
- Production deployment
|
|
81
|
+
- Monitoring setup
|
|
82
|
+
- Support runbook
|
|
83
|
+
- Launch announcement
|
|
84
|
+
|
|
85
|
+
**Duration**: 1 week
|
|
86
|
+
|
|
87
|
+
---
|
|
88
|
+
|
|
89
|
+
## 05 - Iteration [backlog]
|
|
90
|
+
|
|
91
|
+
**Goal**: Feedback loop, feature requests, tech debt
|
|
92
|
+
|
|
93
|
+
**Milestone**: Continuous improvement
|
|
94
|
+
|
|
95
|
+
**Dependencies**: Phase 4 complete
|
|
96
|
+
|
|
97
|
+
**Deliverables**:
|
|
98
|
+
- Bug fixes
|
|
99
|
+
- Performance tuning
|
|
100
|
+
- Feature enhancements
|
|
101
|
+
- Tech debt paydown
|
|
102
|
+
|
|
103
|
+
**Duration**: Ongoing
|
|
104
|
+
|
|
105
|
+
---
|
|
106
|
+
|
|
107
|
+
## Notes
|
|
108
|
+
|
|
109
|
+
- **Critical path**: Foundation → Core → Launch (minimum 4-5 weeks)
|
|
110
|
+
- **Risk**: Scope creep in Core Features phase
|
|
111
|
+
- **Slack**: Refinement phase acts as buffer
|
|
@@ -0,0 +1,28 @@
|
|
|
1
|
+
---
|
|
2
|
+
phase: 1
|
|
3
|
+
phase_name: Foundation
|
|
4
|
+
current_wave: 1
|
|
5
|
+
wave_1_complete: false
|
|
6
|
+
wave_2_complete: false
|
|
7
|
+
branch: phase-01-foundation
|
|
8
|
+
executor_model: sonnet
|
|
9
|
+
verifier_model: haiku
|
|
10
|
+
last_updated: 2026-04-05
|
|
11
|
+
status: in-progress
|
|
12
|
+
---
|
|
13
|
+
|
|
14
|
+
# Execution State
|
|
15
|
+
|
|
16
|
+
Current state of phase execution. Updated via `mid-tools state set/advance`.
|
|
17
|
+
|
|
18
|
+
**Last update**: [timestamp]
|
|
19
|
+
**By**: [agent/user]
|
|
20
|
+
|
|
21
|
+
## Current Wave
|
|
22
|
+
|
|
23
|
+
Wave 1: [Task 1, Task 2, Task 3] — in progress
|
|
24
|
+
|
|
25
|
+
## Notes
|
|
26
|
+
|
|
27
|
+
- Any blockers?
|
|
28
|
+
- Any context for next run?
|
|
@@ -0,0 +1,58 @@
|
|
|
1
|
+
---
|
|
2
|
+
phase: 1
|
|
3
|
+
phase_name: Foundation
|
|
4
|
+
completed_at: 2026-04-05
|
|
5
|
+
actual_hours: 18
|
|
6
|
+
status: complete
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
# Phase 1 Summary
|
|
10
|
+
|
|
11
|
+
## Results
|
|
12
|
+
|
|
13
|
+
**Status**: ✅ Complete
|
|
14
|
+
|
|
15
|
+
| Metric | Target | Actual |
|
|
16
|
+
|--------|--------|--------|
|
|
17
|
+
| Tasks | 8 | 8 |
|
|
18
|
+
| Waves | 2 | 2 |
|
|
19
|
+
| Hours | 16 | 18 |
|
|
20
|
+
| Test coverage | > 80% | 84% |
|
|
21
|
+
| Blockers | 0 | 1 (resolved) |
|
|
22
|
+
|
|
23
|
+
## What We Built
|
|
24
|
+
|
|
25
|
+
- CI/CD pipeline (GitHub Actions)
|
|
26
|
+
- PostgreSQL schema + migrations
|
|
27
|
+
- JWT authentication (Express.js)
|
|
28
|
+
- User model with validation
|
|
29
|
+
- REST API with 12 endpoints
|
|
30
|
+
- OpenAPI documentation
|
|
31
|
+
- Integration tests (15 scenarios)
|
|
32
|
+
- Security audit (OWASP, passed)
|
|
33
|
+
|
|
34
|
+
## Blockers Encountered
|
|
35
|
+
|
|
36
|
+
1. **Database migration tool** — initially chose Knex, switched to Prisma (1 hour)
|
|
37
|
+
- Resolution: Discussed with team, used Prisma template
|
|
38
|
+
|
|
39
|
+
## Quality Gates Passed
|
|
40
|
+
|
|
41
|
+
- ✅ Unit tests: 84% coverage
|
|
42
|
+
- ✅ Integration tests: all pass
|
|
43
|
+
- ✅ Security: no critical vulns
|
|
44
|
+
- ✅ Performance: API < 100ms
|
|
45
|
+
- ✅ Code review: 2 approvals
|
|
46
|
+
- ✅ Staging deployment: stable
|
|
47
|
+
|
|
48
|
+
## Lessons Learned
|
|
49
|
+
|
|
50
|
+
1. Database selection impacts velocity — Prisma migrations faster than manual SQL
|
|
51
|
+
2. Early authentication scaffolding saved Wave 2 time
|
|
52
|
+
3. Integration test setup should happen earlier (Wave 1)
|
|
53
|
+
|
|
54
|
+
## Next Phase
|
|
55
|
+
|
|
56
|
+
Foundation is ready. Proceed to **Phase 2: Core Features**
|
|
57
|
+
|
|
58
|
+
See ROADMAP.md Phase 2 section.
|
|
@@ -0,0 +1,135 @@
|
|
|
1
|
+
# Debug Workflow
|
|
2
|
+
|
|
3
|
+
Diagnose phase execution issues and unblock work.
|
|
4
|
+
|
|
5
|
+
**Token budget**: ~10K (mid-debugger spawn + context)
|
|
6
|
+
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
## Context Setup
|
|
10
|
+
|
|
11
|
+
@/Users/ismailalam/Development/my/makeitdone/makeitdone/steps/state-read.md
|
|
12
|
+
@/Users/ismailalam/Development/my/makeitdone/makeitdone/steps/model-route.md
|
|
13
|
+
|
|
14
|
+
---
|
|
15
|
+
|
|
16
|
+
## Execution
|
|
17
|
+
|
|
18
|
+
### 1. Capture Context
|
|
19
|
+
|
|
20
|
+
```bash
|
|
21
|
+
PHASE=${phase_arg}
|
|
22
|
+
PLAN_SPEC=${plan_arg:-"current"}
|
|
23
|
+
|
|
24
|
+
PHASE_DIR=".planning/phases/$(printf '%02d' $PHASE)-*"
|
|
25
|
+
|
|
26
|
+
# Get error/blocker from STATE.md
|
|
27
|
+
LAST_ERROR=$(mid-tools fm get .planning/STATE.md --field "last_error")
|
|
28
|
+
BLOCKED_AT=$(mid-tools fm get .planning/STATE.md --field "blocked_task_id")
|
|
29
|
+
```
|
|
30
|
+
|
|
31
|
+
### 2. Check Recent Output
|
|
32
|
+
|
|
33
|
+
```bash
|
|
34
|
+
# Look for executor/verifier output in session context
|
|
35
|
+
if [ -f "$PHASE_DIR/.last_execution_output" ]; then
|
|
36
|
+
ERROR_CONTEXT=$(cat "$PHASE_DIR/.last_execution_output")
|
|
37
|
+
else
|
|
38
|
+
ERROR_CONTEXT="No recent execution output"
|
|
39
|
+
fi
|
|
40
|
+
```
|
|
41
|
+
|
|
42
|
+
### 3. Spawn Debugger
|
|
43
|
+
|
|
44
|
+
```bash
|
|
45
|
+
DEBUGGER_OUTPUT=$(spawn agent \
|
|
46
|
+
name=mid-debugger \
|
|
47
|
+
model=sonnet \
|
|
48
|
+
context=$(cat << EOF
|
|
49
|
+
phase: $PHASE
|
|
50
|
+
plan_spec: $PLAN_SPEC
|
|
51
|
+
last_error: $LAST_ERROR
|
|
52
|
+
blocked_at: $BLOCKED_AT
|
|
53
|
+
error_context: $ERROR_CONTEXT
|
|
54
|
+
phase_dir: $PHASE_DIR
|
|
55
|
+
EOF
|
|
56
|
+
))
|
|
57
|
+
```
|
|
58
|
+
|
|
59
|
+
### 4. Parse Debugger Output
|
|
60
|
+
|
|
61
|
+
```bash
|
|
62
|
+
if [[ $DEBUGGER_OUTPUT == *"## ROOT CAUSE:"* ]]; then
|
|
63
|
+
# Extract root cause
|
|
64
|
+
ROOT_CAUSE=$(echo "$DEBUGGER_OUTPUT" | grep -A 2 "ROOT CAUSE:")
|
|
65
|
+
|
|
66
|
+
output "## ROOT CAUSE IDENTIFIED"
|
|
67
|
+
echo "$ROOT_CAUSE"
|
|
68
|
+
|
|
69
|
+
elif [[ $DEBUGGER_OUTPUT == *"## ESCALATION NEEDED"* ]]; then
|
|
70
|
+
# Extract escalation reason
|
|
71
|
+
REASON=$(echo "$DEBUGGER_OUTPUT" | grep -A 5 "ESCALATION NEEDED")
|
|
72
|
+
|
|
73
|
+
output "## ESCALATION NEEDED"
|
|
74
|
+
echo "$REASON"
|
|
75
|
+
|
|
76
|
+
ask_user "Next steps?"
|
|
77
|
+
else
|
|
78
|
+
output "## DEBUG INCOMPLETE"
|
|
79
|
+
fi
|
|
80
|
+
```
|
|
81
|
+
|
|
82
|
+
### 5. Suggest Actions
|
|
83
|
+
|
|
84
|
+
```bash
|
|
85
|
+
# Debugger outputs recommended action
|
|
86
|
+
RECOMMENDED=$(echo "$DEBUGGER_OUTPUT" | grep -A 3 "Recommended Action:")
|
|
87
|
+
|
|
88
|
+
echo "Suggested fix:"
|
|
89
|
+
echo "$RECOMMENDED"
|
|
90
|
+
|
|
91
|
+
ask_user "Apply fix and retry? Or escalate?"
|
|
92
|
+
```
|
|
93
|
+
|
|
94
|
+
### 6. Checkpoint State
|
|
95
|
+
|
|
96
|
+
```bash
|
|
97
|
+
# Save debug output for record
|
|
98
|
+
cp <(echo "$DEBUGGER_OUTPUT") "$PHASE_DIR/.debug_$(date +%s).txt"
|
|
99
|
+
|
|
100
|
+
# Update STATE
|
|
101
|
+
mid-tools state set last_error ""
|
|
102
|
+
mid-tools state set last_debug_time $(date -u +%s)
|
|
103
|
+
```
|
|
104
|
+
|
|
105
|
+
---
|
|
106
|
+
|
|
107
|
+
## Usage Examples
|
|
108
|
+
|
|
109
|
+
```bash
|
|
110
|
+
# Debug current blocked phase
|
|
111
|
+
/mid:debug
|
|
112
|
+
|
|
113
|
+
# Debug specific phase
|
|
114
|
+
/mid:debug --phase 2
|
|
115
|
+
|
|
116
|
+
# Debug specific task
|
|
117
|
+
/mid:debug --phase 1 --plan 01-03
|
|
118
|
+
```
|
|
119
|
+
|
|
120
|
+
---
|
|
121
|
+
|
|
122
|
+
## Error Handling
|
|
123
|
+
|
|
124
|
+
- **No error context**: Ask user to describe issue
|
|
125
|
+
- **Debugger timeout**: Partial diagnosis OK
|
|
126
|
+
- **Root cause unclear**: Escalate with findings
|
|
127
|
+
|
|
128
|
+
---
|
|
129
|
+
|
|
130
|
+
## Anti-patterns Avoided
|
|
131
|
+
|
|
132
|
+
✓ Single agent spawn (debugger only)
|
|
133
|
+
✓ Context-aware (reads recent state)
|
|
134
|
+
✓ Fast diagnosis (5 min budget)
|
|
135
|
+
✓ Escalation when needed
|