gsdd-cli 0.18.5 → 0.19.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/LICENSE +21 -21
- package/README.md +610 -608
- package/agents/DISTILLATION.md +421 -421
- package/agents/README.md +62 -62
- package/agents/approach-explorer.md +370 -361
- package/agents/debugger.md +82 -82
- package/agents/executor.md +473 -394
- package/agents/integration-checker.md +318 -318
- package/agents/mapper.md +103 -103
- package/agents/planner.md +342 -313
- package/agents/researcher.md +84 -84
- package/agents/roadmapper.md +296 -296
- package/agents/synthesizer.md +236 -236
- package/agents/verifier.md +337 -337
- package/bin/adapters/agents.mjs +34 -34
- package/bin/adapters/claude.mjs +193 -191
- package/bin/adapters/codex.mjs +85 -85
- package/bin/adapters/index.mjs +20 -20
- package/bin/adapters/opencode.mjs +280 -278
- package/bin/gsdd.mjs +123 -116
- package/bin/lib/cli-utils.mjs +28 -28
- package/bin/lib/evidence-contract.mjs +325 -112
- package/bin/lib/file-ops.mjs +186 -144
- package/bin/lib/health-truth.mjs +196 -178
- package/bin/lib/health.mjs +246 -226
- package/bin/lib/init-flow.mjs +247 -231
- package/bin/lib/init-prompts.mjs +248 -247
- package/bin/lib/init-runtime.mjs +193 -190
- package/bin/lib/init.mjs +17 -17
- package/bin/lib/lifecycle-preflight.mjs +760 -326
- package/bin/lib/lifecycle-state.mjs +356 -267
- package/bin/lib/manifest.mjs +116 -114
- package/bin/lib/models.mjs +411 -411
- package/bin/lib/phase.mjs +365 -358
- package/bin/lib/plan-constants.mjs +35 -30
- package/bin/lib/provenance.mjs +109 -106
- package/bin/lib/rendering.mjs +119 -83
- package/bin/lib/runtime-freshness.mjs +214 -214
- package/bin/lib/session-fingerprint.mjs +91 -14
- package/bin/lib/templates.mjs +225 -224
- package/bin/lib/workspace-root.mjs +2 -1
- package/distilled/DESIGN.md +2461 -2323
- package/distilled/EVIDENCE-INDEX.md +418 -392
- package/distilled/README.md +196 -193
- package/distilled/SKILL.md +86 -85
- package/distilled/templates/agents.block.md +21 -21
- package/distilled/templates/agents.md +6 -6
- package/distilled/templates/approach.md +272 -232
- package/distilled/templates/auth-matrix.md +78 -78
- package/distilled/templates/brownfield-change/CHANGE.md +99 -0
- package/distilled/templates/brownfield-change/HANDOFF.md +38 -0
- package/distilled/templates/brownfield-change/VERIFICATION.md +56 -0
- package/distilled/templates/codebase/architecture.md +110 -110
- package/distilled/templates/codebase/concerns.md +95 -95
- package/distilled/templates/codebase/conventions.md +193 -193
- package/distilled/templates/codebase/stack.md +96 -96
- package/distilled/templates/delegates/approach-explorer.md +28 -25
- package/distilled/templates/delegates/mapper-arch.md +26 -26
- package/distilled/templates/delegates/mapper-concerns.md +27 -27
- package/distilled/templates/delegates/mapper-quality.md +28 -28
- package/distilled/templates/delegates/mapper-tech.md +25 -25
- package/distilled/templates/delegates/plan-checker.md +78 -68
- package/distilled/templates/delegates/researcher-architecture.md +30 -30
- package/distilled/templates/delegates/researcher-features.md +30 -30
- package/distilled/templates/delegates/researcher-pitfalls.md +30 -30
- package/distilled/templates/delegates/researcher-stack.md +30 -30
- package/distilled/templates/delegates/researcher-synthesizer.md +31 -31
- package/distilled/templates/research/architecture.md +57 -57
- package/distilled/templates/research/features.md +23 -23
- package/distilled/templates/research/pitfalls.md +46 -46
- package/distilled/templates/research/stack.md +45 -45
- package/distilled/templates/research/summary.md +67 -67
- package/distilled/templates/roadmap.md +74 -62
- package/distilled/templates/spec.md +110 -110
- package/distilled/workflows/audit-milestone.md +303 -271
- package/distilled/workflows/complete-milestone.md +349 -332
- package/distilled/workflows/execute.md +457 -450
- package/distilled/workflows/map-codebase.md +253 -253
- package/distilled/workflows/new-milestone.md +242 -238
- package/distilled/workflows/new-project.md +398 -398
- package/distilled/workflows/pause.md +160 -156
- package/distilled/workflows/plan-milestone-gaps.md +183 -183
- package/distilled/workflows/plan.md +454 -448
- package/distilled/workflows/progress.md +227 -223
- package/distilled/workflows/quick.md +351 -347
- package/distilled/workflows/resume.md +220 -212
- package/distilled/workflows/verify-work.md +260 -260
- package/distilled/workflows/verify.md +431 -429
- package/docs/BROWNFIELD-PROOF.md +95 -95
- package/docs/RUNTIME-SUPPORT.md +80 -69
- package/docs/USER-GUIDE.md +394 -386
- package/docs/VERIFICATION-DISCIPLINE.md +59 -59
- package/docs/claude/context-monitor.md +98 -98
- package/docs/proof/consumer-node-cli/README.md +37 -37
- package/docs/proof/consumer-node-cli/ROADMAP.md +14 -14
- package/docs/proof/consumer-node-cli/SPEC.md +17 -17
- package/docs/proof/consumer-node-cli/brief.md +9 -9
- package/docs/proof/consumer-node-cli/phases/01-foundation/01-01-PLAN.md +34 -34
- package/docs/proof/consumer-node-cli/phases/01-foundation/01-01-SUMMARY.md +10 -10
- package/docs/proof/consumer-node-cli/phases/01-foundation/01-VERIFICATION.md +30 -30
- package/package.json +62 -61
|
@@ -1,110 +1,110 @@
|
|
|
1
|
-
# SPEC.md Template
|
|
2
|
-
|
|
3
|
-
Use this template when creating `.planning/SPEC.md` - the project's single source of truth.
|
|
4
|
-
|
|
5
|
-
> **Agentic PRD Constraint:** Do not write narrative prose or fluff. Use strict checklists, dense tables, and typed schemas. There is no artificial line limit, but every single line must be highly deterministic and actionable for a downstream Subagent.
|
|
6
|
-
|
|
7
|
-
---
|
|
8
|
-
|
|
9
|
-
```markdown
|
|
10
|
-
# [Project Name]
|
|
11
|
-
|
|
12
|
-
## What We're Building
|
|
13
|
-
|
|
14
|
-
[2-3 sentences. What does this product/feature do and who is it for? Use the developer's own language.]
|
|
15
|
-
|
|
16
|
-
## Core Value
|
|
17
|
-
|
|
18
|
-
[The ONE thing that matters most. If everything else fails, this must work.]
|
|
19
|
-
|
|
20
|
-
## Core Principles
|
|
21
|
-
|
|
22
|
-
[SOTA: 3-5 governing rules for the project (e.g., Code Quality, UI Consistency, Testing)]
|
|
23
|
-
|
|
24
|
-
## Typed Data Schemas
|
|
25
|
-
|
|
26
|
-
```typescript
|
|
27
|
-
// SOTA: Define the core shared data models here early to prevent agent hallucination during handoffs
|
|
28
|
-
// type User = { id: string; role: 'admin' | 'user' };
|
|
29
|
-
```
|
|
30
|
-
|
|
31
|
-
## Capability & Security Gates
|
|
32
|
-
|
|
33
|
-
// SOTA [OpenFang]: Define what autonomous agents are explicitly NOT allowed to do without human `/approve`.
|
|
34
|
-
- **Destructive DB actions:** Require human review
|
|
35
|
-
- **External Purchases:** Mandatory approval gate
|
|
36
|
-
|
|
37
|
-
## Requirements
|
|
38
|
-
|
|
39
|
-
### Must Have (v1)
|
|
40
|
-
|
|
41
|
-
- [ ] **[CAT-01]**: [User-centric, testable requirement] [Done-When: observable verification criteria]
|
|
42
|
-
- [ ] **[CAT-02]**: [User-centric, testable requirement] [Done-When: observable verification criteria]
|
|
43
|
-
- [ ] **[CAT-03]**: [User-centric, testable requirement] [Done-When: observable verification criteria]
|
|
44
|
-
|
|
45
|
-
### Nice to Have (v2)
|
|
46
|
-
|
|
47
|
-
- **[CAT-04]**: [Deferred requirement]
|
|
48
|
-
- **[CAT-05]**: [Deferred requirement]
|
|
49
|
-
|
|
50
|
-
### Out of Scope
|
|
51
|
-
|
|
52
|
-
- [Feature] - [why excluded]
|
|
53
|
-
- [Feature] - [why excluded]
|
|
54
|
-
|
|
55
|
-
## Constraints
|
|
56
|
-
|
|
57
|
-
- **[Type]**: [What] - [Why]
|
|
58
|
-
- **[Type]**: [What] - [Why]
|
|
59
|
-
|
|
60
|
-
## Key Decisions
|
|
61
|
-
|
|
62
|
-
| Decision | Rationale | Date |
|
|
63
|
-
|----------|-----------|------|
|
|
64
|
-
| [Choice] | [Why] | [When] |
|
|
65
|
-
|
|
66
|
-
## Current State
|
|
67
|
-
|
|
68
|
-
- **Active Phase:** Phase [X] - [Name] ([ ]/[-]/[x])
|
|
69
|
-
- **Last Completed:** [What was last done]
|
|
70
|
-
- **In Progress:** [What is currently being worked on]
|
|
71
|
-
- **Decisions:** [Any recent decisions]
|
|
72
|
-
- **Blockers:** [None / description]
|
|
73
|
-
|
|
74
|
-
---
|
|
75
|
-
*Last updated: [date] after [trigger]*
|
|
76
|
-
```
|
|
77
|
-
|
|
78
|
-
---
|
|
79
|
-
|
|
80
|
-
## Guidelines
|
|
81
|
-
|
|
82
|
-
- **Requirements** must be specific, testable, and user-centric ("User can X", not "System does Y")
|
|
83
|
-
- **Requirement IDs** use `[CATEGORY]-[NUMBER]` format (AUTH-01, DATA-02, UI-03)
|
|
84
|
-
- **v1 requirements** have checkboxes - check them off when verified as complete
|
|
85
|
-
- **Every v1 requirement** must include a `[Done-When: ...]` clause with observable verification criteria
|
|
86
|
-
- **Out of Scope** always includes reasoning (prevents scope creep discussions later)
|
|
87
|
-
- **Key Decisions** are appended throughout the project as they're made
|
|
88
|
-
- **Current State** is updated after each significant milestone - this is how agents resume work across sessions
|
|
89
|
-
- **No Narrative Fluff** - this is an executable Agentic PRD, not a novel. Details live in plans, but core Typed Schemas MUST reside here.
|
|
90
|
-
|
|
91
|
-
## When Codebase Already Exists (Brownfield)
|
|
92
|
-
|
|
93
|
-
If auditing an existing codebase during `init`:
|
|
94
|
-
- Add a **Validated** section under Requirements:
|
|
95
|
-
```markdown
|
|
96
|
-
### Validated (existing capabilities)
|
|
97
|
-
- [x] **[CAT-01]**: User can log in - existing auth system
|
|
98
|
-
- [x] **[CAT-02]**: Data persists across sessions - PostgreSQL database
|
|
99
|
-
```
|
|
100
|
-
- New requirements go under "Must Have (v1)"
|
|
101
|
-
- Document existing tech stack and patterns in Constraints
|
|
102
|
-
- Document any tech debt discovered in a separate concern note (not in SPEC.md)
|
|
103
|
-
|
|
104
|
-
## Archive Guidance
|
|
105
|
-
|
|
106
|
-
When a major milestone completes:
|
|
107
|
-
1. The SPEC.md "Current State" section reflects the new state
|
|
108
|
-
2. Completed phases have summaries in `.planning/phases/{N}-SUMMARY.md`
|
|
109
|
-
3. SPEC.md itself stays lean - don't accumulate history here
|
|
110
|
-
|
|
1
|
+
# SPEC.md Template
|
|
2
|
+
|
|
3
|
+
Use this template when creating `.planning/SPEC.md` - the project's single source of truth.
|
|
4
|
+
|
|
5
|
+
> **Agentic PRD Constraint:** Do not write narrative prose or fluff. Use strict checklists, dense tables, and typed schemas. There is no artificial line limit, but every single line must be highly deterministic and actionable for a downstream Subagent.
|
|
6
|
+
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
```markdown
|
|
10
|
+
# [Project Name]
|
|
11
|
+
|
|
12
|
+
## What We're Building
|
|
13
|
+
|
|
14
|
+
[2-3 sentences. What does this product/feature do and who is it for? Use the developer's own language.]
|
|
15
|
+
|
|
16
|
+
## Core Value
|
|
17
|
+
|
|
18
|
+
[The ONE thing that matters most. If everything else fails, this must work.]
|
|
19
|
+
|
|
20
|
+
## Core Principles
|
|
21
|
+
|
|
22
|
+
[SOTA: 3-5 governing rules for the project (e.g., Code Quality, UI Consistency, Testing)]
|
|
23
|
+
|
|
24
|
+
## Typed Data Schemas
|
|
25
|
+
|
|
26
|
+
```typescript
|
|
27
|
+
// SOTA: Define the core shared data models here early to prevent agent hallucination during handoffs
|
|
28
|
+
// type User = { id: string; role: 'admin' | 'user' };
|
|
29
|
+
```
|
|
30
|
+
|
|
31
|
+
## Capability & Security Gates
|
|
32
|
+
|
|
33
|
+
// SOTA [OpenFang]: Define what autonomous agents are explicitly NOT allowed to do without human `/approve`.
|
|
34
|
+
- **Destructive DB actions:** Require human review
|
|
35
|
+
- **External Purchases:** Mandatory approval gate
|
|
36
|
+
|
|
37
|
+
## Requirements
|
|
38
|
+
|
|
39
|
+
### Must Have (v1)
|
|
40
|
+
|
|
41
|
+
- [ ] **[CAT-01]**: [User-centric, testable requirement] [Done-When: observable verification criteria]
|
|
42
|
+
- [ ] **[CAT-02]**: [User-centric, testable requirement] [Done-When: observable verification criteria]
|
|
43
|
+
- [ ] **[CAT-03]**: [User-centric, testable requirement] [Done-When: observable verification criteria]
|
|
44
|
+
|
|
45
|
+
### Nice to Have (v2)
|
|
46
|
+
|
|
47
|
+
- **[CAT-04]**: [Deferred requirement]
|
|
48
|
+
- **[CAT-05]**: [Deferred requirement]
|
|
49
|
+
|
|
50
|
+
### Out of Scope
|
|
51
|
+
|
|
52
|
+
- [Feature] - [why excluded]
|
|
53
|
+
- [Feature] - [why excluded]
|
|
54
|
+
|
|
55
|
+
## Constraints
|
|
56
|
+
|
|
57
|
+
- **[Type]**: [What] - [Why]
|
|
58
|
+
- **[Type]**: [What] - [Why]
|
|
59
|
+
|
|
60
|
+
## Key Decisions
|
|
61
|
+
|
|
62
|
+
| Decision | Rationale | Date |
|
|
63
|
+
|----------|-----------|------|
|
|
64
|
+
| [Choice] | [Why] | [When] |
|
|
65
|
+
|
|
66
|
+
## Current State
|
|
67
|
+
|
|
68
|
+
- **Active Phase:** Phase [X] - [Name] ([ ]/[-]/[x])
|
|
69
|
+
- **Last Completed:** [What was last done]
|
|
70
|
+
- **In Progress:** [What is currently being worked on]
|
|
71
|
+
- **Decisions:** [Any recent decisions]
|
|
72
|
+
- **Blockers:** [None / description]
|
|
73
|
+
|
|
74
|
+
---
|
|
75
|
+
*Last updated: [date] after [trigger]*
|
|
76
|
+
```
|
|
77
|
+
|
|
78
|
+
---
|
|
79
|
+
|
|
80
|
+
## Guidelines
|
|
81
|
+
|
|
82
|
+
- **Requirements** must be specific, testable, and user-centric ("User can X", not "System does Y")
|
|
83
|
+
- **Requirement IDs** use `[CATEGORY]-[NUMBER]` format (AUTH-01, DATA-02, UI-03)
|
|
84
|
+
- **v1 requirements** have checkboxes - check them off when verified as complete
|
|
85
|
+
- **Every v1 requirement** must include a `[Done-When: ...]` clause with observable verification criteria
|
|
86
|
+
- **Out of Scope** always includes reasoning (prevents scope creep discussions later)
|
|
87
|
+
- **Key Decisions** are appended throughout the project as they're made
|
|
88
|
+
- **Current State** is updated after each significant milestone - this is how agents resume work across sessions
|
|
89
|
+
- **No Narrative Fluff** - this is an executable Agentic PRD, not a novel. Details live in plans, but core Typed Schemas MUST reside here.
|
|
90
|
+
|
|
91
|
+
## When Codebase Already Exists (Brownfield)
|
|
92
|
+
|
|
93
|
+
If auditing an existing codebase during `init`:
|
|
94
|
+
- Add a **Validated** section under Requirements:
|
|
95
|
+
```markdown
|
|
96
|
+
### Validated (existing capabilities)
|
|
97
|
+
- [x] **[CAT-01]**: User can log in - existing auth system
|
|
98
|
+
- [x] **[CAT-02]**: Data persists across sessions - PostgreSQL database
|
|
99
|
+
```
|
|
100
|
+
- New requirements go under "Must Have (v1)"
|
|
101
|
+
- Document existing tech stack and patterns in Constraints
|
|
102
|
+
- Document any tech debt discovered in a separate concern note (not in SPEC.md)
|
|
103
|
+
|
|
104
|
+
## Archive Guidance
|
|
105
|
+
|
|
106
|
+
When a major milestone completes:
|
|
107
|
+
1. The SPEC.md "Current State" section reflects the new state
|
|
108
|
+
2. Completed phases have summaries in `.planning/phases/{N}-SUMMARY.md`
|
|
109
|
+
3. SPEC.md itself stays lean - don't accumulate history here
|
|
110
|
+
|