@therocketcode/gsd-core 1.6.0 → 1.6.2
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.
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "gsd-core",
|
|
3
3
|
"displayName": "GSD Core",
|
|
4
|
-
"version": "1.6.
|
|
4
|
+
"version": "1.6.2",
|
|
5
5
|
"description": "GSD Core is a meta-prompting, context engineering, and spec-driven development system for AI coding agents.",
|
|
6
6
|
"author": {
|
|
7
7
|
"name": "TheRocketCodeMX",
|
package/agents/gsd-roadmapper.md
CHANGED
|
@@ -441,6 +441,10 @@ Orchestrator provides:
|
|
|
441
441
|
- research/SUMMARY.md content (if exists - phase suggestions)
|
|
442
442
|
- config.json (granularity setting)
|
|
443
443
|
|
|
444
|
+
**Also read these project-level discovery artifacts if they exist** (e.g. on a new milestone, or when discovery was run before the roadmap):
|
|
445
|
+
- `.planning/DOMAIN-MODEL.md` — group phases so each delivers a coherent subdomain capability; keep core-subdomain work cohesive rather than scattered across unrelated phases.
|
|
446
|
+
- the latest `.planning/adr/*.md` — let the architecture topology inform phase dependencies (e.g. shared ports/adapters land before the features that use them).
|
|
447
|
+
|
|
444
448
|
Parse and confirm understanding before proceeding.
|
|
445
449
|
|
|
446
450
|
## Step 2: Extract Requirements
|
package/gemini-extension.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "gsd-core",
|
|
3
|
-
"version": "1.6.
|
|
3
|
+
"version": "1.6.2",
|
|
4
4
|
"description": "GSD Core — a meta-prompting, context engineering, and spec-driven development system for AI coding agents. Loads gsd's operating context into every Gemini CLI session.",
|
|
5
5
|
"contextFileName": "GEMINI.md"
|
|
6
6
|
}
|
|
@@ -70,6 +70,8 @@ Present banner:
|
|
|
70
70
|
<step name="analyze_implementation">
|
|
71
71
|
Extract the list of files modified by the phase from SUMMARY.md ("Files Changed" or equivalent section).
|
|
72
72
|
|
|
73
|
+
**If `.planning/TEST-STRATEGY.md` exists, read it first and let it drive classification** — map each changed file to its subdomain and use the strategy's per-subdomain test level (unit → TDD; integration → TDD-style but exercised against real dependencies; e2e → E2E) plus its gnarly-bits and what-not-to-test lists, instead of the generic heuristics below. When the strategy prescribes integration/e2e for a file, pull the test-infra references it links (`@~/.claude/gsd-core/references/test-containers.md`, `db-test-isolation.md`, `auth-in-tests.md`, `realistic-test-data.md`, `flaky-test-checklist.md`) into the generated test's setup. Use the heuristics below only for files the strategy doesn't cover.
|
|
74
|
+
|
|
73
75
|
For each file, classify into one of three categories:
|
|
74
76
|
|
|
75
77
|
| Category | Criteria | Test Type |
|
|
@@ -335,6 +335,8 @@ If spike/sketch findings skills exist, read their SKILL.md files to inform the q
|
|
|
335
335
|
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
|
336
336
|
```
|
|
337
337
|
|
|
338
|
+
**If `.planning/PRODUCT-BRIEF.md` exists, read it first.** It is a validated product definition from `/gsd:discover-product` (outcome, target user, narrowest wedge, demand evidence, four-risks status, prioritized scope, explicit "not in scope"). Ground the questioning in it — **confirm and fill gaps rather than re-asking what it already answers** — and carry its outcome, wedge, and prioritized scope into PROJECT.md (Core Value / What This Is) and the requirements (Steps 4 and 7). Frame PROJECT.md around the brief's *outcome*, not a re-derived feature list.
|
|
339
|
+
|
|
338
340
|
**Open the conversation:**
|
|
339
341
|
|
|
340
342
|
Ask inline (freeform, NOT AskUserQuestion):
|
package/package.json
CHANGED