gsdd-cli 0.1.0 → 0.3.1
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 +38 -20
- package/agents/DISTILLATION.md +116 -3
- package/agents/README.md +9 -0
- package/agents/approach-explorer.md +361 -0
- package/agents/planner.md +20 -5
- package/bin/adapters/claude.mjs +41 -11
- package/bin/adapters/codex.mjs +20 -1
- package/bin/adapters/opencode.mjs +37 -11
- package/bin/gsdd.mjs +44 -34
- package/bin/lib/init-flow.mjs +220 -0
- package/bin/lib/init-prompts.mjs +308 -0
- package/bin/lib/init-runtime.mjs +224 -0
- package/bin/lib/init.mjs +20 -379
- package/bin/lib/models.mjs +27 -10
- package/distilled/DESIGN.md +366 -7
- package/distilled/README.md +173 -169
- package/distilled/templates/agents.block.md +5 -3
- package/distilled/templates/approach.md +232 -0
- package/distilled/templates/delegates/approach-explorer.md +25 -0
- package/distilled/templates/delegates/plan-checker.md +11 -1
- package/distilled/workflows/audit-milestone.md +2 -0
- package/distilled/workflows/map-codebase.md +10 -5
- package/distilled/workflows/new-project.md +26 -21
- package/distilled/workflows/pause.md +2 -0
- package/distilled/workflows/plan.md +83 -12
- package/distilled/workflows/quick.md +163 -4
- package/package.json +11 -3
package/distilled/README.md
CHANGED
|
@@ -1,169 +1,173 @@
|
|
|
1
|
-
# GSDD (Get Shit Done Distilled)
|
|
2
|
-
|
|
3
|
-
Lightweight Spec-Driven Development (SDD) for AI-assisted engineering.
|
|
4
|
-
|
|
5
|
-
Distilled from GSD (Get Shit Done): keep rigor and leverage, drop ceremony.
|
|
6
|
-
|
|
7
|
-
## What This Is
|
|
8
|
-
|
|
9
|
-
GSDD is a small set of workflow sources plus a CLI (`gsdd`) that:
|
|
10
|
-
- scaffolds a project planning workspace (`.planning/`)
|
|
11
|
-
- generates portable workflow entrypoints as skills (`.agents/skills/gsdd-*/SKILL.md`)
|
|
12
|
-
- optionally generates tool-specific adapters for runtimes that need extra native surfaces (root `AGENTS.md`, Claude skills + plan-command alias + native agents, OpenCode commands + native agents)
|
|
13
|
-
|
|
14
|
-
## Quick Start
|
|
15
|
-
|
|
16
|
-
Run in your project root:
|
|
17
|
-
```bash
|
|
18
|
-
npx gsdd-cli init
|
|
19
|
-
```
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
npx gsdd-cli init --tools
|
|
26
|
-
npx gsdd-cli init --tools
|
|
27
|
-
npx gsdd-cli init --tools
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
|
|
34
|
-
-
|
|
35
|
-
-
|
|
36
|
-
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
|
|
45
|
-
|
|
46
|
-
/gsdd:
|
|
47
|
-
/gsdd:
|
|
48
|
-
/gsdd:
|
|
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
|
-
gsdd-
|
|
103
|
-
gsdd-
|
|
104
|
-
gsdd-
|
|
105
|
-
gsdd-
|
|
106
|
-
gsdd-
|
|
107
|
-
gsdd-
|
|
108
|
-
.
|
|
109
|
-
gsdd-
|
|
110
|
-
.
|
|
111
|
-
gsdd-
|
|
112
|
-
.claude/
|
|
113
|
-
gsdd-plan
|
|
114
|
-
.
|
|
115
|
-
gsdd-plan
|
|
116
|
-
.
|
|
117
|
-
gsdd-plan.md
|
|
118
|
-
.
|
|
119
|
-
gsdd-plan-checker.
|
|
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
|
-
researcher-
|
|
158
|
-
|
|
159
|
-
|
|
160
|
-
|
|
161
|
-
|
|
162
|
-
|
|
163
|
-
|
|
164
|
-
|
|
165
|
-
|
|
166
|
-
|
|
167
|
-
|
|
168
|
-
|
|
169
|
-
|
|
1
|
+
# GSDD (Get Shit Done Distilled)
|
|
2
|
+
|
|
3
|
+
Lightweight Spec-Driven Development (SDD) for AI-assisted engineering.
|
|
4
|
+
|
|
5
|
+
Distilled from GSD (Get Shit Done): keep rigor and leverage, drop ceremony.
|
|
6
|
+
|
|
7
|
+
## What This Is
|
|
8
|
+
|
|
9
|
+
GSDD is a small set of workflow sources plus a CLI (`gsdd`) that:
|
|
10
|
+
- scaffolds a project planning workspace (`.planning/`)
|
|
11
|
+
- generates portable workflow entrypoints as skills (`.agents/skills/gsdd-*/SKILL.md`)
|
|
12
|
+
- optionally generates tool-specific adapters for runtimes that need extra native surfaces (root `AGENTS.md`, Claude skills + plan-command alias + native agents, OpenCode commands + native agents)
|
|
13
|
+
|
|
14
|
+
## Quick Start
|
|
15
|
+
|
|
16
|
+
Run in your project root:
|
|
17
|
+
```bash
|
|
18
|
+
npx gsdd-cli init
|
|
19
|
+
```
|
|
20
|
+
|
|
21
|
+
In a TTY, `gsdd init` now opens a guided install wizard: choose runtimes first, then decide separately whether repo-wide `AGENTS.md` governance is worth installing.
|
|
22
|
+
|
|
23
|
+
Optional adapters:
|
|
24
|
+
```bash
|
|
25
|
+
npx gsdd-cli init --tools claude
|
|
26
|
+
npx gsdd-cli init --tools opencode
|
|
27
|
+
npx gsdd-cli init --tools codex
|
|
28
|
+
npx gsdd-cli init --tools agents
|
|
29
|
+
npx gsdd-cli init --tools cursor
|
|
30
|
+
npx gsdd-cli init --tools all
|
|
31
|
+
```
|
|
32
|
+
|
|
33
|
+
Notes:
|
|
34
|
+
- `gsdd init` always generates open-standard skills at `.agents/skills/gsdd-*`. This is also the primary Codex CLI surface.
|
|
35
|
+
- `--tools ...` remains the manual/headless path; legacy runtime aliases such as `cursor`, `copilot`, and `gemini` are still supported for backward compatibility.
|
|
36
|
+
- `--tools claude` also generates native agents at `.claude/agents/gsdd-*.md` and a compatibility plan command alias at `.claude/commands/gsdd-plan.md`.
|
|
37
|
+
- `--tools opencode` also generates native agents at `.opencode/agents/gsdd-*.md`.
|
|
38
|
+
- `--tools codex` generates `.codex/agents/gsdd-plan-checker.toml`; the portable `.agents/skills/gsdd-plan/` surface remains the Codex entry path.
|
|
39
|
+
- Root `AGENTS.md` is only written when explicitly requested (`--tools agents`, `--tools all`, legacy runtime aliases, or the wizard governance opt-in).
|
|
40
|
+
|
|
41
|
+
## The Workflow
|
|
42
|
+
|
|
43
|
+
```
|
|
44
|
+
gsdd init -> bootstrap (create .planning/, copy templates, generate skills/adapters)
|
|
45
|
+
/gsdd:new-project -> .planning/SPEC.md + .planning/ROADMAP.md (questioning + codebase audit + research)
|
|
46
|
+
/gsdd:plan N -> phases/N/PLAN.md (task breakdown + research)
|
|
47
|
+
/gsdd:execute N -> code changes (plan execution with quality gates)
|
|
48
|
+
/gsdd:verify N -> VERIFICATION.md (goal-backward validation)
|
|
49
|
+
... repeat plan/execute/verify per phase ...
|
|
50
|
+
/gsdd:quick -> .planning/quick/NNN/ (sub-hour task outside phases)
|
|
51
|
+
/gsdd:pause -> .planning/.continue-here.md (session checkpoint)
|
|
52
|
+
/gsdd:resume -> restore context, route to next action
|
|
53
|
+
/gsdd:progress -> show status, route to next action
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
## Current Status (updated 2026-03-20)
|
|
57
|
+
|
|
58
|
+
| Workflow | Status | Notes |
|
|
59
|
+
|----------|--------|-------|
|
|
60
|
+
| `new-project.md` | [OK] Defined, source-audited | Covers greenfield + brownfield + milestone context |
|
|
61
|
+
| `plan.md` | [OK] Defined, source-audited | Portable workflow defines the planner contract and supports independent plan checking through generated native adapters |
|
|
62
|
+
| `execute.md` | [OK] Source-audited | Mandatory read enforcement, auth-gate routing, deviation-rule examples, and substantive summary quality gate |
|
|
63
|
+
| `verify.md` | [OK] Source-audited | 5 gap closures against hardened verifier role contract: grouped-gap guidance, orphan detection, frontmatter enforcement, verification basis emphasis, requirements coverage chain |
|
|
64
|
+
| `audit-milestone.md` | [OK] Defined, source-audited | Aggregates phase verification, cross-phase integration audit, auth protection checks, requirement reconciliation, and orphan detection into `MILESTONE-AUDIT.md` |
|
|
65
|
+
| `quick.md` | [OK] | Quick-work lane for sub-hour tasks outside the phase cycle (D11) |
|
|
66
|
+
| `pause.md` | [OK] Source-audited | Session checkpoint writer with conversational handoff (D12) |
|
|
67
|
+
| `resume.md` | [OK] Source-audited | Session context restorer with priority-ordered routing (D12) |
|
|
68
|
+
| `progress.md` | [OK] Source-audited | Read-only status reporter with 6 named route branches, recent work, between-milestones detection (D12) |
|
|
69
|
+
| `map-codebase.md` | [OK] Defined, source-audited | Standalone codebase mapping/refresh |
|
|
70
|
+
|
|
71
|
+
Architecture notes:
|
|
72
|
+
- `bin/gsdd.mjs` remains the thin generator entrypoint, while vendor-specific rendering lives in adapter modules.
|
|
73
|
+
- Codex CLI uses the always-generated `.agents/skills/gsdd-*` surface as its entry path and can add a native `.codex/agents/gsdd-plan-checker.toml` checker agent.
|
|
74
|
+
- Portable lifecycle contracts now align to the roadmap template status grammar: `[ ]`, `[-]`, `[x]`.
|
|
75
|
+
- Phase verification and milestone integration audit are treated as separate concerns.
|
|
76
|
+
- Canonical role contracts use bounded sections, typed output examples, and checklist-driven completion where those structures materially improve downstream reliability.
|
|
77
|
+
|
|
78
|
+
## Init Workflow Agent Count (by config)
|
|
79
|
+
|
|
80
|
+
| Mode | Mappers | Researchers | Synthesizer | Total |
|
|
81
|
+
|------|---------|-------------|-------------|-------|
|
|
82
|
+
| Brownfield, first run, research balanced/deep | 4 | 4 | 1 | 9 |
|
|
83
|
+
| Brownfield, first run, research fast | 4 | 4 | 0 (inline) | 8 |
|
|
84
|
+
| Brownfield, subsequent run, research balanced/deep | 0 (maps exist) | 4 | 1 | 5 |
|
|
85
|
+
| Greenfield, research balanced/deep | 0 | 4 | 1 | 5 |
|
|
86
|
+
| Greenfield, research fast | 0 | 4 | 0 (inline) | 4 |
|
|
87
|
+
| Any, no research | 0-4 | 0 | 0 | 0-4 |
|
|
88
|
+
|
|
89
|
+
Note: `parallelization: false` keeps the same mapper/researcher set but runs them sequentially.
|
|
90
|
+
|
|
91
|
+
## What Gets Created (Project Output)
|
|
92
|
+
|
|
93
|
+
```
|
|
94
|
+
.planning/
|
|
95
|
+
SPEC.md
|
|
96
|
+
ROADMAP.md
|
|
97
|
+
config.json
|
|
98
|
+
templates/ # copied from distilled/templates/
|
|
99
|
+
phases/ # phase plans and summaries
|
|
100
|
+
research/ # optional research outputs
|
|
101
|
+
.agents/skills/
|
|
102
|
+
gsdd-new-project/SKILL.md
|
|
103
|
+
gsdd-plan/SKILL.md
|
|
104
|
+
gsdd-execute/SKILL.md
|
|
105
|
+
gsdd-verify/SKILL.md
|
|
106
|
+
gsdd-audit-milestone/SKILL.md
|
|
107
|
+
gsdd-quick/SKILL.md
|
|
108
|
+
gsdd-pause/SKILL.md
|
|
109
|
+
gsdd-resume/SKILL.md
|
|
110
|
+
gsdd-progress/SKILL.md
|
|
111
|
+
gsdd-map-codebase/SKILL.md
|
|
112
|
+
.claude/agents/
|
|
113
|
+
gsdd-plan-checker.md # native-capable checker agent generated from the active plan-checker contract
|
|
114
|
+
.claude/commands/
|
|
115
|
+
gsdd-plan.md # compatibility alias to the Claude skill-primary plan entry
|
|
116
|
+
.claude/skills/
|
|
117
|
+
gsdd-plan/SKILL.md # Claude-native skill-primary planner -> checker surface
|
|
118
|
+
.opencode/agents/
|
|
119
|
+
gsdd-plan-checker.md # native-capable checker agent generated from the active plan-checker contract
|
|
120
|
+
.opencode/commands/
|
|
121
|
+
gsdd-plan.md # OpenCode-native specialized planner -> checker command surface
|
|
122
|
+
.codex/agents/
|
|
123
|
+
gsdd-plan-checker.toml # Codex-native checker agent (read-only, high reasoning effort)
|
|
124
|
+
.planning/
|
|
125
|
+
quick/ # quick task directories and LOG.md
|
|
126
|
+
.continue-here.md # session checkpoint (created by pause)
|
|
127
|
+
```
|
|
128
|
+
|
|
129
|
+
## Files In This Framework
|
|
130
|
+
|
|
131
|
+
```
|
|
132
|
+
distilled/
|
|
133
|
+
DESIGN.md # design decisions and rationale (36 decisions, evidence-backed)
|
|
134
|
+
SKILL.md # primary entry point (plain markdown)
|
|
135
|
+
workflows/
|
|
136
|
+
new-project.md
|
|
137
|
+
map-codebase.md
|
|
138
|
+
plan.md
|
|
139
|
+
progress.md
|
|
140
|
+
execute.md
|
|
141
|
+
verify.md
|
|
142
|
+
audit-milestone.md
|
|
143
|
+
quick.md
|
|
144
|
+
pause.md
|
|
145
|
+
resume.md
|
|
146
|
+
templates/
|
|
147
|
+
spec.md
|
|
148
|
+
roadmap.md
|
|
149
|
+
agents.md # full AGENTS.md template (for tool adapters)
|
|
150
|
+
agents.block.md # bounded block payload for root AGENTS.md insertion
|
|
151
|
+
delegates/ # delegate instruction files (copied to .planning/templates/delegates/)
|
|
152
|
+
mapper-tech.md
|
|
153
|
+
mapper-arch.md
|
|
154
|
+
mapper-quality.md
|
|
155
|
+
mapper-concerns.md
|
|
156
|
+
plan-checker.md
|
|
157
|
+
researcher-stack.md
|
|
158
|
+
researcher-features.md
|
|
159
|
+
researcher-architecture.md
|
|
160
|
+
researcher-pitfalls.md
|
|
161
|
+
researcher-synthesizer.md
|
|
162
|
+
research/
|
|
163
|
+
stack.md
|
|
164
|
+
features.md
|
|
165
|
+
architecture.md
|
|
166
|
+
pitfalls.md
|
|
167
|
+
summary.md
|
|
168
|
+
codebase/
|
|
169
|
+
stack.md
|
|
170
|
+
architecture.md
|
|
171
|
+
conventions.md
|
|
172
|
+
concerns.md
|
|
173
|
+
```
|
|
@@ -6,7 +6,7 @@ Edit the source template in the GSDD framework instead.
|
|
|
6
6
|
### What This Project Uses
|
|
7
7
|
- Framework: GSDD (Spec-Driven Development)
|
|
8
8
|
- Planning dir: `.planning/` (specs, roadmaps, plans, research, templates)
|
|
9
|
-
- Lifecycle: `bootstrap (gsdd init) -> new-project -> [plan -> execute -> verify] x N -> audit-milestone` for roadmap work
|
|
9
|
+
- Lifecycle: `bootstrap (gsdd init) -> new-project -> [discuss-approach -> plan -> execute -> verify] x N -> audit-milestone` for roadmap work
|
|
10
10
|
- Supporting workflows: quick (sub-hour tasks), map-codebase (codebase analysis), pause/resume (session management), progress (status query)
|
|
11
11
|
|
|
12
12
|
### Rules You MUST Follow
|
|
@@ -83,8 +83,10 @@ If you are not confident about a domain/library/pattern:
|
|
|
83
83
|
|
|
84
84
|
How you run these workflows depends on your tool:
|
|
85
85
|
|
|
86
|
-
- **Claude Code / OpenCode:** Use slash commands — `/gsdd-new-project`, `/gsdd-plan`, `/gsdd-execute`, etc.
|
|
86
|
+
- **Claude Code / OpenCode / Cursor / Copilot / Gemini:** Use slash commands — `/gsdd-new-project`, `/gsdd-plan`, `/gsdd-execute`, etc.
|
|
87
87
|
- **Codex CLI:** Use skill references — `$gsdd-new-project`, `$gsdd-plan`, `$gsdd-execute`, etc.
|
|
88
|
-
- **
|
|
88
|
+
- **Other AI tools:** Open the SKILL.md file listed above and follow its instructions.
|
|
89
|
+
|
|
90
|
+
If this root `AGENTS.md` block is present in a Cursor, Copilot, or Gemini project, treat it as behavioral governance on top of the runtime's native slash-command discovery. Do not treat this file as the mechanism that makes the workflows discoverable.
|
|
89
91
|
|
|
90
92
|
Start with the new-project workflow to produce `.planning/SPEC.md` and `.planning/ROADMAP.md`.
|
|
@@ -0,0 +1,232 @@
|
|
|
1
|
+
# Phase Approach Template
|
|
2
|
+
|
|
3
|
+
Template for `.planning/phases/XX-name/{phase_num}-APPROACH.md` — captures implementation decisions and validated assumptions for a phase.
|
|
4
|
+
|
|
5
|
+
**Purpose:** Document decisions that downstream agents need. Planner uses this to know WHAT choices are locked vs flexible. Plan-checker verifies plans honor these decisions.
|
|
6
|
+
|
|
7
|
+
**Key principle:** The top-level structure (`<domain>`, `<decisions>`, `<assumptions>`, `<deferred>`) is fixed. Section names WITHIN `<decisions>` emerge from what was actually discussed for THIS phase — a CLI phase has CLI-relevant sections, a UI phase has UI-relevant sections.
|
|
8
|
+
|
|
9
|
+
**Downstream consumers:**
|
|
10
|
+
- `planner` — Reads decisions to constrain implementation choices. Locked decisions must be implemented. Agent's Discretion items allow planner flexibility.
|
|
11
|
+
- `plan-checker` — Reads decisions to verify plans implement chosen approaches (approach_alignment dimension). Flags plans that contradict explicit user choices.
|
|
12
|
+
|
|
13
|
+
---
|
|
14
|
+
|
|
15
|
+
## File Template
|
|
16
|
+
|
|
17
|
+
```markdown
|
|
18
|
+
# Phase [X]: [Name] - Approach
|
|
19
|
+
|
|
20
|
+
**Explored:** [date]
|
|
21
|
+
**Status:** Ready for planning
|
|
22
|
+
|
|
23
|
+
<domain>
|
|
24
|
+
## Phase Boundary
|
|
25
|
+
|
|
26
|
+
[Clear statement of what this phase delivers — the scope anchor. This comes from ROADMAP.md and is fixed. Discussion clarifies implementation within this boundary.]
|
|
27
|
+
|
|
28
|
+
</domain>
|
|
29
|
+
|
|
30
|
+
<decisions>
|
|
31
|
+
## Implementation Decisions
|
|
32
|
+
|
|
33
|
+
### [Gray Area 1 that was discussed]
|
|
34
|
+
**Chosen approach:** [name]
|
|
35
|
+
**Alternatives considered:** [Option B], [Option C]
|
|
36
|
+
**Why this one:** [reasoning from research + user preference]
|
|
37
|
+
- [Specific decision from questioning]
|
|
38
|
+
- [Another decision if applicable]
|
|
39
|
+
|
|
40
|
+
### [Gray Area 2 that was discussed]
|
|
41
|
+
**Chosen approach:** [name]
|
|
42
|
+
**Alternatives considered:** [Option B]
|
|
43
|
+
**Why this one:** [reasoning]
|
|
44
|
+
- [Specific decision]
|
|
45
|
+
|
|
46
|
+
### Agent's Discretion
|
|
47
|
+
[Areas where user explicitly said "you decide" — the agent has flexibility here during planning/implementation]
|
|
48
|
+
|
|
49
|
+
</decisions>
|
|
50
|
+
|
|
51
|
+
<assumptions>
|
|
52
|
+
## Validated Assumptions
|
|
53
|
+
|
|
54
|
+
### Confirmed
|
|
55
|
+
- [confident] [assumption confirmed by user]
|
|
56
|
+
|
|
57
|
+
### Accepted (not challenged)
|
|
58
|
+
- [assuming] [assumption user didn't challenge — planner should still honor but note it]
|
|
59
|
+
|
|
60
|
+
### Corrected
|
|
61
|
+
- [corrected] [original assumption] → [user's correction]
|
|
62
|
+
|
|
63
|
+
</assumptions>
|
|
64
|
+
|
|
65
|
+
<deferred>
|
|
66
|
+
## Deferred Ideas
|
|
67
|
+
|
|
68
|
+
[Ideas that came up during discussion but belong in other phases. Captured here so they're not lost, but explicitly out of scope for this phase.]
|
|
69
|
+
|
|
70
|
+
[If none: "None — discussion stayed within phase scope"]
|
|
71
|
+
|
|
72
|
+
</deferred>
|
|
73
|
+
|
|
74
|
+
---
|
|
75
|
+
|
|
76
|
+
*Phase: XX-name*
|
|
77
|
+
*Approach explored: [date]*
|
|
78
|
+
```
|
|
79
|
+
|
|
80
|
+
## Good Examples
|
|
81
|
+
|
|
82
|
+
**Example 1: Visual feature (Dashboard)**
|
|
83
|
+
|
|
84
|
+
```markdown
|
|
85
|
+
# Phase 3: Interactive Dashboard - Approach
|
|
86
|
+
|
|
87
|
+
**Explored:** 2026-03-22
|
|
88
|
+
**Status:** Ready for planning
|
|
89
|
+
|
|
90
|
+
<domain>
|
|
91
|
+
## Phase Boundary
|
|
92
|
+
|
|
93
|
+
Build an interactive dashboard with configurable widgets. Users can view metrics and rearrange layout. Widget creation and custom data sources are separate phases.
|
|
94
|
+
|
|
95
|
+
</domain>
|
|
96
|
+
|
|
97
|
+
<decisions>
|
|
98
|
+
## Implementation Decisions
|
|
99
|
+
|
|
100
|
+
### Chart rendering
|
|
101
|
+
**Chosen approach:** Recharts
|
|
102
|
+
**Alternatives considered:** D3 + custom components, Chart.js
|
|
103
|
+
**Why this one:** React-native, SSR-friendly, good defaults. Matches existing React patterns. D3 would give more control but requires more code for standard charts.
|
|
104
|
+
- Bar charts and line charts for metrics — no pie charts in v1
|
|
105
|
+
- Charts should be interactive (hover tooltips) but not editable
|
|
106
|
+
- Responsive: charts resize with widget container
|
|
107
|
+
|
|
108
|
+
### Widget layout
|
|
109
|
+
**Chosen approach:** react-grid-layout
|
|
110
|
+
**Alternatives considered:** CSS Grid + custom drag, @dnd-kit grid
|
|
111
|
+
**Why this one:** Purpose-built for dashboard grids. Layout serialization to JSON for persistence. Mature production usage.
|
|
112
|
+
- Drag-to-reorder enabled
|
|
113
|
+
- Resize handles on bottom-right corner
|
|
114
|
+
- 12-column grid, responsive breakpoints
|
|
115
|
+
- Layout persisted to localStorage (not server)
|
|
116
|
+
|
|
117
|
+
### Agent's Discretion
|
|
118
|
+
- Loading skeleton design
|
|
119
|
+
- Exact spacing and typography within widgets
|
|
120
|
+
- Error state handling for failed data fetches
|
|
121
|
+
|
|
122
|
+
</decisions>
|
|
123
|
+
|
|
124
|
+
<assumptions>
|
|
125
|
+
## Validated Assumptions
|
|
126
|
+
|
|
127
|
+
### Confirmed
|
|
128
|
+
- [confident] Using existing Tailwind patterns from Phase 1-2
|
|
129
|
+
|
|
130
|
+
### Accepted (not challenged)
|
|
131
|
+
- [assuming] Dashboard data comes from static JSON for v1 (no real API)
|
|
132
|
+
|
|
133
|
+
### Corrected
|
|
134
|
+
- [corrected] Dashboard is read-only → Widgets DO need drag reorder
|
|
135
|
+
|
|
136
|
+
</assumptions>
|
|
137
|
+
|
|
138
|
+
<deferred>
|
|
139
|
+
## Deferred Ideas
|
|
140
|
+
|
|
141
|
+
- Real-time data updates — future phase
|
|
142
|
+
- Custom widget creation — add to backlog
|
|
143
|
+
- Dashboard sharing/export — out of scope for v1
|
|
144
|
+
|
|
145
|
+
</deferred>
|
|
146
|
+
|
|
147
|
+
---
|
|
148
|
+
|
|
149
|
+
*Phase: 03-dashboard*
|
|
150
|
+
*Approach explored: 2026-03-22*
|
|
151
|
+
```
|
|
152
|
+
|
|
153
|
+
**Example 2: API feature (Authentication)**
|
|
154
|
+
|
|
155
|
+
```markdown
|
|
156
|
+
# Phase 1: Authentication - Approach
|
|
157
|
+
|
|
158
|
+
**Explored:** 2026-03-22
|
|
159
|
+
**Status:** Ready for planning
|
|
160
|
+
|
|
161
|
+
<domain>
|
|
162
|
+
## Phase Boundary
|
|
163
|
+
|
|
164
|
+
Users can register and log in with email/password. Session management via JWT. OAuth and MFA are separate phases.
|
|
165
|
+
|
|
166
|
+
</domain>
|
|
167
|
+
|
|
168
|
+
<decisions>
|
|
169
|
+
## Implementation Decisions
|
|
170
|
+
|
|
171
|
+
### Session handling
|
|
172
|
+
**Chosen approach:** HTTP-only cookies with JWT
|
|
173
|
+
**Alternatives considered:** localStorage JWT, session-based (server-side)
|
|
174
|
+
**Why this one:** HTTP-only cookies prevent XSS token theft. JWT avoids server-side session storage. Standard pattern for Next.js apps.
|
|
175
|
+
- Access token: 15-minute expiry
|
|
176
|
+
- Refresh token: 7-day expiry, rotation on use
|
|
177
|
+
- Logout clears both tokens
|
|
178
|
+
|
|
179
|
+
### Error responses
|
|
180
|
+
**Chosen approach:** Structured JSON errors
|
|
181
|
+
**Alternatives considered:** Plain text errors, RFC 7807 Problem Details
|
|
182
|
+
**Why this one:** Consistent with existing API patterns. RFC 7807 is overkill for this project size.
|
|
183
|
+
- Always include: status code, error code, user-facing message
|
|
184
|
+
- Never include: stack traces, internal IDs
|
|
185
|
+
- Rate limit errors: include retry-after header
|
|
186
|
+
|
|
187
|
+
### Agent's Discretion
|
|
188
|
+
- Password hashing library (bcrypt vs argon2)
|
|
189
|
+
- Exact JWT payload structure
|
|
190
|
+
- Email validation regex vs library
|
|
191
|
+
|
|
192
|
+
</decisions>
|
|
193
|
+
|
|
194
|
+
<assumptions>
|
|
195
|
+
## Validated Assumptions
|
|
196
|
+
|
|
197
|
+
### Confirmed
|
|
198
|
+
- [confident] Email/password only for v1 (no OAuth)
|
|
199
|
+
|
|
200
|
+
### Accepted (not challenged)
|
|
201
|
+
- [assuming] No email verification required for v1
|
|
202
|
+
|
|
203
|
+
### Corrected
|
|
204
|
+
- [corrected] Single-device sessions → Allow multi-device (don't invalidate other sessions on login)
|
|
205
|
+
|
|
206
|
+
</assumptions>
|
|
207
|
+
|
|
208
|
+
<deferred>
|
|
209
|
+
## Deferred Ideas
|
|
210
|
+
|
|
211
|
+
- OAuth providers (Google, GitHub) — Phase 4
|
|
212
|
+
- MFA/2FA — add to backlog
|
|
213
|
+
|
|
214
|
+
</deferred>
|
|
215
|
+
|
|
216
|
+
---
|
|
217
|
+
|
|
218
|
+
*Phase: 01-authentication*
|
|
219
|
+
*Approach explored: 2026-03-22*
|
|
220
|
+
```
|
|
221
|
+
|
|
222
|
+
## Guidelines
|
|
223
|
+
|
|
224
|
+
**This template captures DECISIONS for downstream agents.**
|
|
225
|
+
|
|
226
|
+
The output should answer: "What choices are locked for the planner? Where does the planner have discretion?"
|
|
227
|
+
|
|
228
|
+
**After creation:**
|
|
229
|
+
- File lives in phase directory: `.planning/phases/XX-name/{phase_num}-APPROACH.md`
|
|
230
|
+
- Planner reads decisions to constrain implementation tasks
|
|
231
|
+
- Plan-checker verifies approach_alignment: plans must implement chosen approaches
|
|
232
|
+
- Downstream agents should NOT need to ask the user again about captured decisions
|
|
@@ -0,0 +1,25 @@
|
|
|
1
|
+
**Role contract:** Read `.planning/templates/roles/approach-explorer.md` before starting. Follow its algorithm, scope, anti-patterns, and quality standards.
|
|
2
|
+
|
|
3
|
+
You are the approach explorer delegate for the plan workflow.
|
|
4
|
+
|
|
5
|
+
**Your job:** Identify gray areas in the target phase, research viable approaches for technical decisions, conduct an adaptive conversation with the user to capture locked decisions, and write APPROACH.md to the phase directory.
|
|
6
|
+
|
|
7
|
+
Read only the explicit inputs provided by the orchestrator:
|
|
8
|
+
- target phase goal and requirement IDs from `.planning/ROADMAP.md`
|
|
9
|
+
- locked decisions and deferred items from `.planning/SPEC.md`
|
|
10
|
+
- phase research file (if exists)
|
|
11
|
+
- relevant codebase files (existing patterns and conventions)
|
|
12
|
+
- approach template at `.planning/templates/approach.md`
|
|
13
|
+
|
|
14
|
+
## Gray Area Classification
|
|
15
|
+
|
|
16
|
+
Classify each gray area before acting on it:
|
|
17
|
+
- **Taste:** Ask directly, no research needed
|
|
18
|
+
- **Technical:** Research 2-3 approaches first, then present with trade-offs
|
|
19
|
+
- **Hybrid:** Research the technical part, ask about taste
|
|
20
|
+
|
|
21
|
+
## Output
|
|
22
|
+
|
|
23
|
+
Write `{padded_phase}-APPROACH.md` to the phase directory using the approach template.
|
|
24
|
+
|
|
25
|
+
Return structured summary: gray areas explored, decisions captured, assumptions validated/corrected, deferred ideas, path to APPROACH.md.
|