gsdd-cli 0.2.0 → 0.16.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 +67 -34
- package/agents/DISTILLATION.md +15 -13
- package/agents/planner.md +2 -0
- package/bin/adapters/agents.mjs +1 -0
- package/bin/adapters/claude.mjs +12 -3
- package/bin/adapters/codex.mjs +4 -0
- package/bin/adapters/opencode.mjs +13 -4
- package/bin/gsdd.mjs +64 -39
- package/bin/lib/cli-utils.mjs +1 -1
- package/bin/lib/file-ops.mjs +161 -0
- package/bin/lib/health-truth.mjs +188 -0
- package/bin/lib/health.mjs +65 -12
- package/bin/lib/init-flow.mjs +267 -0
- package/bin/lib/init-prompts.mjs +247 -0
- package/bin/lib/init-runtime.mjs +226 -0
- package/bin/lib/init.mjs +19 -378
- package/bin/lib/models.mjs +19 -4
- package/bin/lib/phase.mjs +100 -14
- package/bin/lib/plan-constants.mjs +30 -0
- package/bin/lib/provenance.mjs +146 -0
- package/bin/lib/templates.mjs +17 -0
- package/distilled/DESIGN.md +625 -41
- package/distilled/EVIDENCE-INDEX.md +297 -0
- package/distilled/README.md +49 -21
- package/distilled/SKILL.md +89 -85
- package/distilled/templates/agents.block.md +13 -82
- package/distilled/templates/agents.md +0 -7
- package/distilled/templates/delegates/plan-checker.md +11 -4
- package/distilled/workflows/audit-milestone.md +7 -5
- package/distilled/workflows/complete-milestone.md +297 -0
- package/distilled/workflows/execute.md +188 -19
- package/distilled/workflows/map-codebase.md +14 -7
- package/distilled/workflows/new-milestone.md +249 -0
- package/distilled/workflows/new-project.md +28 -24
- package/distilled/workflows/pause.md +42 -6
- package/distilled/workflows/plan-milestone-gaps.md +183 -0
- package/distilled/workflows/plan.md +78 -13
- package/distilled/workflows/progress.md +42 -19
- package/distilled/workflows/quick.md +171 -8
- package/distilled/workflows/resume.md +121 -11
- package/distilled/workflows/verify-work.md +260 -0
- package/distilled/workflows/verify.md +124 -33
- package/package.json +9 -7
|
@@ -1,90 +1,21 @@
|
|
|
1
1
|
## GSDD Governance (Generated)
|
|
2
2
|
|
|
3
|
-
|
|
4
|
-
Edit the source template in the GSDD framework instead.
|
|
3
|
+
Managed by `gsdd`; edit the framework template, not this block.
|
|
5
4
|
|
|
6
|
-
|
|
7
|
-
- Framework: GSDD (Spec-Driven Development)
|
|
8
|
-
- Planning dir: `.planning/` (specs, roadmaps, plans, research, templates)
|
|
9
|
-
- Lifecycle: `bootstrap (gsdd init) -> new-project -> [discuss-approach -> plan -> execute -> verify] x N -> audit-milestone` for roadmap work
|
|
10
|
-
- Supporting workflows: quick (sub-hour tasks), map-codebase (codebase analysis), pause/resume (session management), progress (status query)
|
|
5
|
+
Lifecycle: `new-project -> plan -> execute -> verify -> audit-milestone`.
|
|
11
6
|
|
|
12
|
-
|
|
7
|
+
Core skills: `gsdd-new-project`, `gsdd-plan`, `gsdd-execute`, `gsdd-verify`, `gsdd-progress`.
|
|
8
|
+
Planning state: `.planning/`. Portable workflows: `.agents/skills/gsdd-*/SKILL.md`.
|
|
13
9
|
|
|
14
|
-
|
|
15
|
-
- Roadmap work should follow: plan -> execute -> verify.
|
|
16
|
-
- Direct user requests do NOT need to be forced into a phase or plan unless the user explicitly wants roadmap tracking.
|
|
17
|
-
- Before coding roadmap work: read `.planning/SPEC.md`, `.planning/ROADMAP.md`, and the relevant phase plan if one exists.
|
|
18
|
-
- After coding: verify against the relevant success criteria before claiming done.
|
|
10
|
+
Invoke: `/gsdd-plan` (Claude, OpenCode, Cursor, Copilot, Gemini) · `$gsdd-plan` (Codex) · open SKILL.md directly elsewhere.
|
|
19
11
|
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
12
|
+
Rules:
|
|
13
|
+
1. Read before writing roadmap work: `.planning/SPEC.md`, `.planning/ROADMAP.md`, `.planning/config.json`, and the relevant phase plan when one exists.
|
|
14
|
+
2. Stay in scope. Implement only what the approved plan or direct user request says. Record unrelated ideas as TODOs.
|
|
15
|
+
3. Verify before claiming done: artifact exists, content is substantive, and it is wired into the system.
|
|
16
|
+
4. Research unfamiliar domains from real docs and code; never hallucinate paths or APIs.
|
|
17
|
+
5. Do not pollute core workflows with vendor-specific syntax; adapters are generated under `bin/`.
|
|
18
|
+
6. Git guidance in `.planning/config.json` -> `gitProtocol` is advisory; follow the repo's own conventions first.
|
|
27
19
|
|
|
28
|
-
|
|
29
|
-
- Implement ONLY what the approved plan or direct user request specifies.
|
|
30
|
-
- If you notice unrelated improvements, do not implement them. Record them as a TODO for a future phase.
|
|
20
|
+
If `.planning/` is missing, run `gsdd init` then `gsdd-new-project`.
|
|
31
21
|
|
|
32
|
-
Priority order when instructions conflict:
|
|
33
|
-
- Developer explicit instruction (highest)
|
|
34
|
-
- Current approved plan or direct task scope
|
|
35
|
-
- `.planning/SPEC.md`
|
|
36
|
-
- General best practices (lowest)
|
|
37
|
-
|
|
38
|
-
4. Version Control Protocol
|
|
39
|
-
- Treat `.planning/config.json` -> `gitProtocol` as advisory guidance, not a mandatory naming template.
|
|
40
|
-
- Follow the existing repo or team git conventions first.
|
|
41
|
-
- Do not mention phase, plan, or task IDs in commit or PR names unless explicitly requested.
|
|
42
|
-
- Tests must pass before committing.
|
|
43
|
-
|
|
44
|
-
5. Verify Your Own Work (Exists -> Substantive -> Wired)
|
|
45
|
-
Before reporting "done", verify each deliverable:
|
|
46
|
-
- Exists: artifact is present where the plan says it should be
|
|
47
|
-
- Substantive: real content/code, not placeholders or TODOs
|
|
48
|
-
- Wired: connected to the system (imported, called, rendered, tested)
|
|
49
|
-
|
|
50
|
-
6. Research Before Unfamiliar Domains
|
|
51
|
-
If you are not confident about a domain/library/pattern:
|
|
52
|
-
- Stop and research first (docs + existing code).
|
|
53
|
-
- Do not assume training data is current.
|
|
54
|
-
- Cite sources in `.planning/research/` (or `.internal-research/` for framework work).
|
|
55
|
-
|
|
56
|
-
7. Never Hallucinate Paths Or APIs
|
|
57
|
-
- Use only file paths you've confirmed exist.
|
|
58
|
-
- Use only APIs verified in docs or source.
|
|
59
|
-
|
|
60
|
-
8. Adapter Architecture Rule
|
|
61
|
-
- Do not pollute core workflows (`distilled/workflows/*.md`) with vendor-specific syntax.
|
|
62
|
-
- Tool-specific adapters are generated in `bin/` (generators, not converters).
|
|
63
|
-
|
|
64
|
-
9. Anti-YOLO
|
|
65
|
-
- Do not delete or rewrite code unless explicitly asked.
|
|
66
|
-
- If asked for analysis, answer first; propose changes separately.
|
|
67
|
-
|
|
68
|
-
### Where The Workflows Live
|
|
69
|
-
- Primary lifecycle:
|
|
70
|
-
- `.agents/skills/gsdd-new-project/SKILL.md` — project initialization (spec + roadmap)
|
|
71
|
-
- `.agents/skills/gsdd-plan/SKILL.md` — phase planning with optional independent checking
|
|
72
|
-
- `.agents/skills/gsdd-execute/SKILL.md` — plan execution with quality gates
|
|
73
|
-
- `.agents/skills/gsdd-verify/SKILL.md` — phase goal-backward verification
|
|
74
|
-
- `.agents/skills/gsdd-audit-milestone/SKILL.md` — milestone integration audit
|
|
75
|
-
- Supporting workflows:
|
|
76
|
-
- `.agents/skills/gsdd-quick/SKILL.md` — sub-hour tasks outside the phase cycle
|
|
77
|
-
- `.agents/skills/gsdd-map-codebase/SKILL.md` — codebase analysis and refresh
|
|
78
|
-
- `.agents/skills/gsdd-pause/SKILL.md` — session checkpoint
|
|
79
|
-
- `.agents/skills/gsdd-resume/SKILL.md` — session context restore and routing
|
|
80
|
-
- `.agents/skills/gsdd-progress/SKILL.md` — read-only status and next-action routing
|
|
81
|
-
|
|
82
|
-
### How To Invoke Workflows
|
|
83
|
-
|
|
84
|
-
How you run these workflows depends on your tool:
|
|
85
|
-
|
|
86
|
-
- **Claude Code / OpenCode:** Use slash commands — `/gsdd-new-project`, `/gsdd-plan`, `/gsdd-execute`, etc.
|
|
87
|
-
- **Codex CLI:** Use skill references — `$gsdd-new-project`, `$gsdd-plan`, `$gsdd-execute`, etc.
|
|
88
|
-
- **All other tools (Cursor, Copilot, Gemini, any AI agent):** Open the SKILL.md file listed above and follow its instructions. This AGENTS.md governance block keeps the agent aligned with GSDD discipline.
|
|
89
|
-
|
|
90
|
-
Start with the new-project workflow to produce `.planning/SPEC.md` and `.planning/ROADMAP.md`.
|
|
@@ -1,12 +1,5 @@
|
|
|
1
1
|
# AGENTS.md - GSDD Governance
|
|
2
2
|
|
|
3
|
-
This file is generated by `gsdd` when requested for runtimes that use AGENTS.md governance surfaces.
|
|
4
|
-
It provides the universal governance layer for agents that support the AGENTS.md convention.
|
|
5
|
-
|
|
6
|
-
See also:
|
|
7
|
-
- Skills (preferred workflow entrypoints): `.agents/skills/gsdd-*/SKILL.md`
|
|
8
|
-
- Planning workspace: `.planning/`
|
|
9
|
-
|
|
10
3
|
<!-- BEGIN GSDD -->
|
|
11
4
|
{{GSDD_BLOCK}}
|
|
12
5
|
<!-- END GSDD -->
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
**Role contract:** Read `.planning/templates/roles/planner.md` before starting. Reuse its planning vocabulary and quality standards, but this wrapper overrides your objective: you are reviewing plans, not authoring them.
|
|
2
2
|
|
|
3
|
-
You are the fresh-context plan checker for `/gsdd
|
|
3
|
+
You are the fresh-context plan checker for `/gsdd-plan`.
|
|
4
4
|
|
|
5
5
|
Read only the explicit inputs provided by the orchestrator:
|
|
6
6
|
- target phase goal and requirement IDs
|
|
@@ -21,12 +21,19 @@ Verify these dimensions:
|
|
|
21
21
|
- `key_link_completeness`: important wiring/integration links are planned, not just isolated artifacts
|
|
22
22
|
- `scope_sanity`: plans are sized so an executor can complete them without context collapse
|
|
23
23
|
- `must_have_quality`: success criteria and must-haves are specific, observable, and reflected in tasks
|
|
24
|
-
- `context_compliance`: locked decisions are honored and deferred ideas stay out of scope
|
|
24
|
+
- `context_compliance`: locked decisions are honored and deferred ideas stay out of scope. Additionally check scope consistency:
|
|
25
|
+
- **Must-have coverage?** Every must-have requirement mapped to this phase in SPEC.md must appear in at least one plan task. A must-have that silently disappears from the plan is a `blocker`.
|
|
26
|
+
- **Deferred exclusion?** Items marked "Nice to Have", "Deferred", or "Out of Scope" in SPEC.md must not appear as plan tasks. Present → `blocker`.
|
|
27
|
+
- **Cross-surface consistency?** If SPEC.md marks an item as must-have but APPROACH.md marks it as deferred (or vice versa), surface the contradiction → `blocker`. Include a `fix_hint` asking the planner to resolve the conflict with the user before proceeding.
|
|
28
|
+
- `goal_achievement`: does the plan, if executed perfectly, actually achieve the stated phase goal? Check:
|
|
29
|
+
- **Goal addressed?** Compare the phase goal statement to the plan's collective task outputs. Would successful completion of all tasks deliver the goal? If the goal says "users can authenticate" but tasks only set up database schema → `blocker`.
|
|
30
|
+
- **Success criteria reachable?** Are the phase success criteria from ROADMAP.md achievable through the planned tasks? Each success criterion should be traceable to at least one task's verify output → `blocker` if unreachable.
|
|
31
|
+
- **Outcome observable?** After execution, could a human or automated check confirm the goal was met? Plans that produce only internal artifacts with no user-visible or testable outcome → `warning`.
|
|
25
32
|
- `approach_alignment`: when APPROACH.md is provided, verify that plan tasks implement the chosen approaches from the user's decisions. Check:
|
|
26
33
|
- **Chosen honored?** Does each plan task align with the approach chosen in APPROACH.md for its gray area? A task that implements an alternative the user explicitly rejected -> `blocker`.
|
|
27
34
|
- **Discretion respected?** "Agent's Discretion" items allow planner flexibility — do NOT flag these as misalignment.
|
|
28
35
|
- **Deferred excluded?** Deferred ideas from APPROACH.md must not appear in plan tasks -> `blocker` if found.
|
|
29
|
-
- If no APPROACH.md was provided, skip this dimension entirely.
|
|
36
|
+
- If `workflow.discuss` is `true` in the project config and no APPROACH.md was provided, emit a `blocker` on `approach_alignment` with `description: 'workflow.discuss is true but no APPROACH.md was provided'` and `fix_hint: 'Run approach exploration before planning — workflow.discuss=true requires an approved APPROACH.md before a plan can be emitted.'` If `workflow.discuss` is `false` or the key is absent and no APPROACH.md was provided, skip this dimension entirely.
|
|
30
37
|
|
|
31
38
|
Return JSON only as a single object with this shape:
|
|
32
39
|
|
|
@@ -36,7 +43,7 @@ Return JSON only as a single object with this shape:
|
|
|
36
43
|
"summary": "One sentence overall assessment",
|
|
37
44
|
"issues": [
|
|
38
45
|
{
|
|
39
|
-
"dimension": "requirement_coverage | approach_alignment",
|
|
46
|
+
"dimension": "requirement_coverage | task_completeness | dependency_correctness | key_link_completeness | scope_sanity | must_have_quality | context_compliance | goal_achievement | approach_alignment",
|
|
40
47
|
"severity": "blocker",
|
|
41
48
|
"description": "What is wrong",
|
|
42
49
|
"plan": "01-PLAN",
|
|
@@ -160,6 +160,8 @@ Plus full markdown report body with tables for requirements, phases, integration
|
|
|
160
160
|
- `gaps_found` - critical blockers exist (unsatisfied requirements, unprotected sensitive flows, broken flows, or missing verifications)
|
|
161
161
|
- `tech_debt` - no blockers but accumulated deferred items need review
|
|
162
162
|
|
|
163
|
+
**MANDATORY: The milestone audit report must exist at `.planning/v{version}-MILESTONE-AUDIT.md` on disk before presenting results. If the file was not written, STOP and report the write failure. Do NOT present audit results from conversation context alone — this is the highest-cost artifact to regenerate. Do NOT downgrade a write failure into "results shown inline anyway."**
|
|
164
|
+
|
|
163
165
|
## 7. Present Results
|
|
164
166
|
|
|
165
167
|
Route by audit status:
|
|
@@ -203,17 +205,17 @@ Report the audit result to the user, then present the next step:
|
|
|
203
205
|
**Completed:** Milestone audit — created `.planning/v{version}-MILESTONE-AUDIT.md`.
|
|
204
206
|
|
|
205
207
|
If status is `passed`:
|
|
206
|
-
**Next step:** `/gsdd
|
|
208
|
+
**Next step:** `/gsdd-complete-milestone` — archive the milestone and prepare for the next
|
|
207
209
|
|
|
208
210
|
If status is `gaps_found`:
|
|
209
|
-
**Next step:** `/gsdd
|
|
211
|
+
**Next step:** `/gsdd-plan-milestone-gaps` — create gap-closure phases for the unsatisfied requirements
|
|
210
212
|
|
|
211
213
|
If status is `tech_debt`:
|
|
212
|
-
**Next step:** Either `/gsdd
|
|
214
|
+
**Next step:** Either `/gsdd-complete-milestone` (accept debt) or `/gsdd-plan` (cleanup phase)
|
|
213
215
|
|
|
214
216
|
Also available:
|
|
215
|
-
- `/gsdd
|
|
216
|
-
- `/gsdd
|
|
217
|
+
- `/gsdd-verify` — re-verify a specific phase before re-auditing
|
|
218
|
+
- `/gsdd-progress` — check overall project status
|
|
217
219
|
|
|
218
220
|
Consider clearing context before starting the next workflow for best results.
|
|
219
221
|
---
|
|
@@ -0,0 +1,297 @@
|
|
|
1
|
+
<role>
|
|
2
|
+
You are the MILESTONE CLOSER. Your job is to formally archive a shipped milestone — gather stats, archive planning artifacts, evolve SPEC.md, collapse the roadmap, and prepare for the next cycle.
|
|
3
|
+
|
|
4
|
+
Core mindset: archive facts, not intentions. Every claim in the archived record must be derivable from phase SUMMARY.md files or git history.
|
|
5
|
+
|
|
6
|
+
Scope boundary: you archive the current milestone. You do not start the next one — that is `/gsdd-new-milestone` territory.
|
|
7
|
+
</role>
|
|
8
|
+
|
|
9
|
+
<prerequisites>
|
|
10
|
+
`.planning/ROADMAP.md` must exist with phases.
|
|
11
|
+
`.planning/SPEC.md` must exist.
|
|
12
|
+
If `.planning/MILESTONES.md` does not exist, create it now (this is the first milestone completion — Step 8 will write the first entry).
|
|
13
|
+
|
|
14
|
+
If `.planning/milestones/` does not exist, create it before writing archive files.
|
|
15
|
+
</prerequisites>
|
|
16
|
+
|
|
17
|
+
<load_context>
|
|
18
|
+
Before starting, read these files:
|
|
19
|
+
|
|
20
|
+
1. `.planning/ROADMAP.md` — phase statuses, milestone name, phase range
|
|
21
|
+
2. `.planning/SPEC.md` — requirements, validated capabilities, current state section
|
|
22
|
+
3. `.planning/MILESTONES.md` — previous milestone entries (for format reference); if this is the first milestone, skip — no previous entries exist yet
|
|
23
|
+
4. `.planning/config.json` — `gitProtocol`, `mode` (for STOP gate behavior)
|
|
24
|
+
5. All phase SUMMARY.md files in `.planning/phases/` — accomplishments, task counts
|
|
25
|
+
6. Most recent `.planning/v*-MILESTONE-AUDIT.md` — audit status (passed / gaps_found)
|
|
26
|
+
</load_context>
|
|
27
|
+
|
|
28
|
+
<process>
|
|
29
|
+
|
|
30
|
+
## 1. Verify Readiness
|
|
31
|
+
|
|
32
|
+
Check:
|
|
33
|
+
- **Phase completion**: Are all ROADMAP.md phases for this milestone marked `[x]`? List any that are not.
|
|
34
|
+
- **Audit status**: Does a MILESTONE-AUDIT.md exist and have status `passed`? If it has status `gaps_found`, the milestone has open gaps.
|
|
35
|
+
- **Spent-branch guard**: Run `git branch --merged origin/main` (substitute `master` or the configured default branch from `config.json → gitProtocol.branch` if different) and verify HEAD is not a spent/already-merged branch. If the current branch already backs a merged PR, STOP - do not instruct any commit or tag operations. Prompt the user to check out a fresh active branch before continuing.
|
|
36
|
+
- **Integration-surface warning pass**: Inspect staged, unstaged, untracked, unpushed, and PR-less local truth separately from the milestone artifacts. Warn if the archive is being attempted from a mixed-scope or stale branch even when the milestone documents themselves look complete.
|
|
37
|
+
|
|
38
|
+
**If phases incomplete or audit not passed:**
|
|
39
|
+
|
|
40
|
+
Present options:
|
|
41
|
+
1. **Proceed anyway** — archive with known gaps noted in MILESTONES.md
|
|
42
|
+
2. **Run audit first** — `/gsdd-audit-milestone` (if audit is missing or stale)
|
|
43
|
+
3. **Close gaps first** — `/gsdd-plan-milestone-gaps` (if audit found gaps)
|
|
44
|
+
4. **Abort** — stop without archiving
|
|
45
|
+
|
|
46
|
+
**STOP. Wait for user selection.**
|
|
47
|
+
|
|
48
|
+
Exception: if `config.json -> mode` is `yolo`, skip the stop gate and proceed with a note about any gaps.
|
|
49
|
+
|
|
50
|
+
**If all phases complete and audit passed:** Proceed.
|
|
51
|
+
|
|
52
|
+
## 2. Determine Version
|
|
53
|
+
|
|
54
|
+
Parse the in-progress milestone version from ROADMAP.md (e.g., the `🚧` or active entry in the Milestones list). Confirm with user if unclear.
|
|
55
|
+
|
|
56
|
+
## 3. Gather Stats
|
|
57
|
+
|
|
58
|
+
Extract from phase SUMMARY.md files and git:
|
|
59
|
+
|
|
60
|
+
- Phase count, plan count, task count (aggregate from SUMMARY files)
|
|
61
|
+
- Test count if discernible from SUMMARY files
|
|
62
|
+
- Start date (first phase completion date) and end date (today)
|
|
63
|
+
- Brief git stats: `git log --oneline --since="[start date]" | wc -l` for commit count
|
|
64
|
+
|
|
65
|
+
Present a concise stats block for review.
|
|
66
|
+
|
|
67
|
+
## 4. Extract Accomplishments
|
|
68
|
+
|
|
69
|
+
Read each phase SUMMARY.md in the milestone's phase range. Extract a one-liner from each phase describing the key delivery.
|
|
70
|
+
|
|
71
|
+
Present 4-8 accomplishments for review. Trim or adjust with user before writing to archive.
|
|
72
|
+
|
|
73
|
+
## 5. Archive Roadmap
|
|
74
|
+
|
|
75
|
+
Create `.planning/milestones/v[X.Y]-ROADMAP.md` with full milestone details:
|
|
76
|
+
|
|
77
|
+
```markdown
|
|
78
|
+
# Milestone v[X.Y]: [Name]
|
|
79
|
+
|
|
80
|
+
**Status:** ✅ SHIPPED [date]
|
|
81
|
+
**Phases:** [N]–[M]
|
|
82
|
+
**Total Plans:** [count]
|
|
83
|
+
**Tag:** v[X.Y]
|
|
84
|
+
|
|
85
|
+
## Overview
|
|
86
|
+
|
|
87
|
+
[One paragraph describing what this milestone delivered and why it mattered.]
|
|
88
|
+
|
|
89
|
+
## Phases
|
|
90
|
+
|
|
91
|
+
### Phase [N]: [Name]
|
|
92
|
+
|
|
93
|
+
**Goal**: [goal from ROADMAP.md]
|
|
94
|
+
**Requirements**: [REQ-IDs]
|
|
95
|
+
|
|
96
|
+
Plans:
|
|
97
|
+
- [x] [plan summary from SUMMARY.md]
|
|
98
|
+
|
|
99
|
+
**Details:**
|
|
100
|
+
[Key implementation decisions and what was built]
|
|
101
|
+
|
|
102
|
+
**Success Criteria verified:**
|
|
103
|
+
1. [criterion]
|
|
104
|
+
2. [criterion]
|
|
105
|
+
|
|
106
|
+
---
|
|
107
|
+
|
|
108
|
+
[Repeat for each phase]
|
|
109
|
+
|
|
110
|
+
## Milestone Summary
|
|
111
|
+
|
|
112
|
+
**Key Decisions:**
|
|
113
|
+
- [Decision and rationale from phase summaries]
|
|
114
|
+
|
|
115
|
+
**Issues Resolved:**
|
|
116
|
+
- [What gaps/issues were closed this milestone]
|
|
117
|
+
|
|
118
|
+
**Issues Deferred (LATER):**
|
|
119
|
+
- [Any LATER-tagged items not addressed]
|
|
120
|
+
|
|
121
|
+
**Technical Debt Incurred:**
|
|
122
|
+
- [Any known shortcuts or deferred quality work]
|
|
123
|
+
|
|
124
|
+
---
|
|
125
|
+
|
|
126
|
+
*For current project status, see `.planning/ROADMAP.md`*
|
|
127
|
+
```
|
|
128
|
+
|
|
129
|
+
## 6. Archive Requirements
|
|
130
|
+
|
|
131
|
+
Create `.planning/milestones/v[X.Y]-REQUIREMENTS.md`:
|
|
132
|
+
|
|
133
|
+
```markdown
|
|
134
|
+
# Requirements Archive: v[X.Y] Milestone
|
|
135
|
+
|
|
136
|
+
**Archived:** [date]
|
|
137
|
+
**Milestone:** [name]
|
|
138
|
+
**Source:** `.planning/SPEC.md` requirements section at milestone completion
|
|
139
|
+
|
|
140
|
+
---
|
|
141
|
+
|
|
142
|
+
## v1 Must-Have Requirements (all satisfied)
|
|
143
|
+
|
|
144
|
+
| ID | Title | Status | Phase | Outcome |
|
|
145
|
+
|----|-------|--------|-------|---------|
|
|
146
|
+
| [ID] | [title] | ✅ verified | Phase [N] | [brief outcome] |
|
|
147
|
+
|
|
148
|
+
**Result: [N]/[N] requirements satisfied**
|
|
149
|
+
|
|
150
|
+
---
|
|
151
|
+
|
|
152
|
+
## Validated (pre-existing capabilities confirmed at milestone)
|
|
153
|
+
|
|
154
|
+
[Copy from SPEC.md Validated section]
|
|
155
|
+
|
|
156
|
+
---
|
|
157
|
+
|
|
158
|
+
## Nice to Have (v2 — deferred)
|
|
159
|
+
|
|
160
|
+
[Copy from SPEC.md Nice to Have section]
|
|
161
|
+
|
|
162
|
+
---
|
|
163
|
+
|
|
164
|
+
*Source: `.planning/SPEC.md` as of [date]*
|
|
165
|
+
*Next milestone requirements: defined via `/gsdd-new-milestone`*
|
|
166
|
+
```
|
|
167
|
+
|
|
168
|
+
## 7. Move Audit File
|
|
169
|
+
|
|
170
|
+
If `.planning/v[X.Y]-MILESTONE-AUDIT.md` exists, note its location in the MILESTONES.md entry. (Leave the file in `.planning/` — it is already in the gitignored planning directory. No move required unless you prefer to co-locate it with the other archives.)
|
|
171
|
+
|
|
172
|
+
## 8. Update MILESTONES.md
|
|
173
|
+
|
|
174
|
+
Append an entry to `.planning/MILESTONES.md`:
|
|
175
|
+
|
|
176
|
+
```markdown
|
|
177
|
+
## ✅ v[X.Y] — [Name] ([date])
|
|
178
|
+
|
|
179
|
+
**Phases:** [N]–[M] | **Plans:** [count] | **Tasks:** [count] | **Tests:** [N] assertions, 0 failures
|
|
180
|
+
|
|
181
|
+
**Delivered:** [One sentence summary of what shipped.]
|
|
182
|
+
|
|
183
|
+
**Key accomplishments:**
|
|
184
|
+
1. [Accomplishment 1]
|
|
185
|
+
2. [Accomplishment 2]
|
|
186
|
+
3. [Accomplishment 3]
|
|
187
|
+
4. [Accomplishment 4]
|
|
188
|
+
|
|
189
|
+
**Archive:** `.planning/milestones/v[X.Y]-ROADMAP.md`
|
|
190
|
+
**Requirements:** `.planning/milestones/v[X.Y]-REQUIREMENTS.md`
|
|
191
|
+
**Tag:** `v[X.Y]`
|
|
192
|
+
```
|
|
193
|
+
|
|
194
|
+
## 9. Evolve SPEC.md
|
|
195
|
+
|
|
196
|
+
Update SPEC.md to reflect the completed milestone:
|
|
197
|
+
|
|
198
|
+
**Move shipped requirements:**
|
|
199
|
+
- Move all Must Have requirements that were satisfied this milestone to the `### Validated (existing capabilities)` section
|
|
200
|
+
- Format: `- [x] **[ID]**: [title] — [brief outcome note]`
|
|
201
|
+
|
|
202
|
+
**Update Current State section:**
|
|
203
|
+
|
|
204
|
+
```markdown
|
|
205
|
+
## Current State
|
|
206
|
+
|
|
207
|
+
- **Milestone:** v[X.Y] [Name] — SHIPPED [date]
|
|
208
|
+
- **Phases:** [N]–[M] complete, all requirements verified ([N]/[N]), [test count] tests passing
|
|
209
|
+
- **Archive:** `.planning/milestones/v[X.Y]-ROADMAP.md`
|
|
210
|
+
- **Decisions:** [D1–DN] evidence-backed, all in [reference if applicable]
|
|
211
|
+
- **Blockers:** None — [list any LATER-priority gaps if applicable]
|
|
212
|
+
- **Next:** `/gsdd-new-milestone` to plan v[X.next] work
|
|
213
|
+
|
|
214
|
+
---
|
|
215
|
+
*Last updated: [date] after v[X.Y] milestone completion*
|
|
216
|
+
```
|
|
217
|
+
|
|
218
|
+
## 10. Collapse ROADMAP.md
|
|
219
|
+
|
|
220
|
+
Replace the active milestone phases in ROADMAP.md with a collapsed `<details>` block and add the milestone to the Milestones list:
|
|
221
|
+
|
|
222
|
+
```markdown
|
|
223
|
+
# Roadmap: [Project Name]
|
|
224
|
+
|
|
225
|
+
## Milestones
|
|
226
|
+
|
|
227
|
+
- ✅ **v[X.Y] [Name]** — Phases [N]–[M] (shipped [date])
|
|
228
|
+
|
|
229
|
+
## Phases
|
|
230
|
+
|
|
231
|
+
<details>
|
|
232
|
+
<summary>✅ v[X.Y] [Name] (Phases [N]–[M]) — SHIPPED [date]</summary>
|
|
233
|
+
|
|
234
|
+
- [x] **Phase [N]: [Name]** — completed [date]
|
|
235
|
+
- [x] **Phase [N+1]: [Name]** — completed [date]
|
|
236
|
+
[...]
|
|
237
|
+
|
|
238
|
+
Full details: [`.planning/milestones/v[X.Y]-ROADMAP.md`](milestones/v[X.Y]-ROADMAP.md)
|
|
239
|
+
|
|
240
|
+
</details>
|
|
241
|
+
|
|
242
|
+
---
|
|
243
|
+
*Created: [original creation date] | v[X.Y] archived: [today]*
|
|
244
|
+
```
|
|
245
|
+
|
|
246
|
+
## 11. Advisory: Git Tag
|
|
247
|
+
|
|
248
|
+
Suggest a git tag for the milestone. Do not mandate it — follow `config.json -> gitProtocol`.
|
|
249
|
+
|
|
250
|
+
```
|
|
251
|
+
Advisory: Tag this milestone in git:
|
|
252
|
+
git tag -a v[X.Y] -m "v[X.Y] [Name] — [one sentence summary]"
|
|
253
|
+
git push origin v[X.Y] # if pushing to remote
|
|
254
|
+
```
|
|
255
|
+
|
|
256
|
+
- Use only user-facing version identifiers and plain descriptions in tag messages, commit summaries, and PR text. Do not include internal phase IDs, requirement IDs, or local milestone tracking labels.
|
|
257
|
+
|
|
258
|
+
</process>
|
|
259
|
+
|
|
260
|
+
<success_criteria>
|
|
261
|
+
- [ ] Readiness verified (phases complete + audit passed, or user chose to proceed with gaps)
|
|
262
|
+
- [ ] Version confirmed
|
|
263
|
+
- [ ] Stats gathered from SUMMARY.md files and git
|
|
264
|
+
- [ ] Accomplishments extracted and reviewed
|
|
265
|
+
- [ ] `.planning/milestones/v[X.Y]-ROADMAP.md` created with full phase details
|
|
266
|
+
- [ ] `.planning/milestones/v[X.Y]-REQUIREMENTS.md` created with all requirement statuses
|
|
267
|
+
- [ ] `.planning/MILESTONES.md` updated with new entry
|
|
268
|
+
- [ ] SPEC.md Must Have requirements moved to Validated section
|
|
269
|
+
- [ ] SPEC.md Current State updated to reflect shipped status
|
|
270
|
+
- [ ] ROADMAP.md collapsed with `<details>` block pointing to archive
|
|
271
|
+
- [ ] Advisory git tag suggestion presented
|
|
272
|
+
</success_criteria>
|
|
273
|
+
|
|
274
|
+
**MANDATORY: All archive files (v[X.Y]-ROADMAP.md, v[X.Y]-REQUIREMENTS.md), MILESTONES.md, SPEC.md, and ROADMAP.md must be written to disk before this workflow is complete. If any write fails, STOP and report the failure. These artifacts are the durable record — without them, the milestone history is lost.**
|
|
275
|
+
|
|
276
|
+
<completion>
|
|
277
|
+
Report to the user what was archived, then present the next step:
|
|
278
|
+
|
|
279
|
+
---
|
|
280
|
+
**Completed:** Milestone v[X.Y] [Name] archived.
|
|
281
|
+
|
|
282
|
+
Archived:
|
|
283
|
+
- `.planning/milestones/v[X.Y]-ROADMAP.md` — full phase details
|
|
284
|
+
- `.planning/milestones/v[X.Y]-REQUIREMENTS.md` — requirements at milestone completion
|
|
285
|
+
- `.planning/MILESTONES.md` — updated milestone history
|
|
286
|
+
- `.planning/SPEC.md` — requirements evolved, current state updated
|
|
287
|
+
- `.planning/ROADMAP.md` — active phases collapsed to `<details>`
|
|
288
|
+
|
|
289
|
+
**Next step:** `/gsdd-new-milestone` — start the next milestone cycle
|
|
290
|
+
|
|
291
|
+
Also available:
|
|
292
|
+
- `/gsdd-progress` — check overall project status
|
|
293
|
+
- `/gsdd-audit-milestone` — re-audit before archiving (if you skipped the audit)
|
|
294
|
+
|
|
295
|
+
Consider clearing context before starting the next workflow for best results.
|
|
296
|
+
---
|
|
297
|
+
</completion>
|