@therocketcode/gsd-core 1.8.2 → 1.8.3

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "gsd-core",
   "displayName": "GSD Core",
-  "version": "1.8.2",
+  "version": "1.8.3",
   "description": "GSD Core is a meta-prompting, context engineering, and spec-driven development system for AI coding agents.",
   "author": {
     "name": "TheRocketCodeMX",

package/gemini-extension.json

@@ -1,6 +1,6 @@
 {
   "name": "gsd-core",
-  "version": "1.8.2",
+  "version": "1.8.3",
   "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.",
   "contextFileName": "GEMINI.md"
 }

package/gsd-core/references/domain-modeling.md

@@ -33,11 +33,12 @@ Classify each area of the system. This is the single highest-leverage output —
 | **Supporting** | Necessary, not differentiating. Tightly coupled to the core. | "Good enough," build simply or buy-and-extend. | Onboarding flows, internal admin, notifications |
 | **Generic** | Commodity every business needs; no edge. | Buy / off-the-shelf / library. | Auth, billing, email, logging, tax calculation |
 
-### Three nuances that prevent misclassification
+### Four nuances that prevent misclassification
 
 1. **Core = differentiating AND complex — not just complex (and not merely *critical* or *regulated*).** A complex-, critical-, or regulated-but-*generic* subdomain (tax, identity/auth, encryption, compliance) is a **buy**, not a build. Difficulty, security-criticality, and regulatory burden do not make something core — only competitive differentiation does. Don't invest core-grade effort there.
 2. **Generic ≠ low quality.** "Generic" means *not differentiating*, not *low effort*. A battle-tested auth library is high-quality and generic.
 3. **Watch for CRUD that will grow business rules.** The dangerous case is an app that "starts as a UI over the database, then evolves into real domain logic." Whenever an area is *described* as simple/CRUD — whatever type is being claimed — probe future features: *will this accumulate invariants and rules?* If yes, treat it as (emerging) core/supporting, not generic. "Core but just CRUD" is self-contradictory — challenge which half is wrong.
+4. **The strategic instrument — when the triad has no slot.** Some subdomains are venture-critical without being product-differentiating: a benchmark/eval suite, an open standard, a public SDK ecosystem, an internal framework — things whose value is *positional* (credibility, ecosystem, a standard you steward) and whose endgame may be neutrality or giveaway. Forcing these into the triad misallocates: "supporting" understates them, "core" steers tactical-DDD richness at the wrong place (you don't give away your core). Classify them as their **own candidate context** annotated *instrument — venture-critical*, allocate rigor by their derived complexity, and apply the rule: **core-grade rigor ≠ core**. The differentiation test stays structural: the core is what's hard to copy for *technical* reasons; an instrument's moat is usually *positional* (reputation, neutrality), and positions belong in their own context with their own destiny.
 
 ### What "complex" means — the complexity-signals rubric
 

package/gsd-core/templates/domain-model.md

@@ -9,7 +9,7 @@ The shared vocabulary. Use these terms consistently in code, docs, and conversat
 
 | Term | Definition | Used by | Aliases / not to be confused with |
 |------|-----------|---------|-----------------------------------|
-| [Term] | [What it means in THIS domain] | [team / users / both] | [aliases, or the term it's often confused with] |
+| [Term] | [What it means in THIS domain] | [team / end-users / both — for dev tools: maintainers vs developer-users] | [aliases, or the term it's often confused with] |
 
 > Polysemes (one word, two meanings across areas) are flagged here — they usually mark a bounded-context boundary.
 
@@ -32,6 +32,9 @@ Strategic classification — drives where to invest and (downstream) the archite
 **Generic** — commodity; buy / off-the-shelf / library:
 - [Subdomain] — [why]
 
+**Instrument — venture-critical (own context; only when one exists)** — positional value (standard/benchmark/ecosystem), not product differentiation; core-grade rigor ≠ core:
+- [Subdomain] — [its own destiny, e.g. "community standard — planned neutrality"]
+
 > Misclassification check applied: each Generic/CRUD area was probed for future business rules. Areas expected to accumulate invariants are marked emerging-core/supporting, not generic.
 
 ## Bounded Contexts

package/gsd-core/workflows/cicd-strategy.md

@@ -40,6 +40,9 @@ cat .planning/PROJECT.md 2>/dev/null || true
 
 **Read `@~/.claude/gsd-core/references/cicd-strategy.md` now** — it defines the GHA-default platform decision, OIDC-with-pinned-`sub`, the secrets split, the tier→stage mapping with the ≤10-min PR budget, the flaky canon, the merge-queue trigger, the deployment ladder, the free-six supply-chain table stakes, and the anti-pattern table.
 
+**Grounding maturity governs elicitation depth.** When upstream artifacts (spec, ADR, strategies, research) already answer a step, draft-from-docs and present for confirmation — cite the source, don't re-interview. Reserve questions for genuine decision points and contradictions. Honor a posture stated in `$ARGUMENTS` without re-asking.
+
+
 **If `NO_TEST_STRATEGY`:** tell the user "No test strategy found — the pipeline mapping is much better with one. (Consider `/gsd:testing-strategy` first.)" If they decline, proceed with generic tiers (small/unit → PR; medium/integration → merge; large/e2e → nightly) and note the gap in the output. From TEST-STRATEGY.md, extract: the per-subdomain level emphasis, the persistent e2e smoke list (the 3–7 flows), and the mutation-testing targets. From INFRA-STRATEGY.md / ADR / PROJECT.md, extract: target cloud + deploy target, repo host, team size, and blast radius (payments/PII/data = high). Ask only what's missing (header "Context"): team size, blast radius, expected merge volume.
 
 ## Step 3: Platform choice

package/gsd-core/workflows/infrastructure-strategy.md

@@ -41,6 +41,9 @@ cat .planning/TEST-STRATEGY.md 2>/dev/null || true
 
 **Read `@~/.claude/gsd-core/references/infrastructure-strategy.md` now** — it defines the compute ladder with quantified move-up triggers, the crossover numbers (Fargate-vs-EC2, the CAST AI utilization data, the <4-engineers floor), the per-cloud asymmetries and equivalences table, the observability floor, the when-you-actually-need triggers, the IaC floor, the anti-patterns, and the meta-tell.
 
+**Grounding maturity governs elicitation depth.** When upstream artifacts (spec, ADR, strategies, research) already answer a step, draft-from-docs and present for confirmation — cite the source, don't re-interview. Reserve questions for genuine decision points and contradictions. Honor a posture stated in `$ARGUMENTS` without re-asking.
+
+
 From the artifacts, extract: **scale expectations + traffic shape** (PRODUCT-BRIEF), **deployment topology** — how many independently deployed components (the ADR; monolith → one service is the normal answer), and **CI environment needs** (TEST-STRATEGY: test containers, e2e environments). **If `NO_ADR`:** tell the user "No architecture decision found — I'll ask briefly. (Consider `/gsd:recommend-architecture` first.)" then ask: how many deployables, and is anything stateful self-managed?
 
 Then gather the three inputs every crossover keys off (AskUserQuestion, header "Shape", or a text list): **traffic shape** (idle most of the day? bursty? steady?), **team size** (engineers who'd touch infra), and **expected monthly compute spend** (or "no idea" — fine, the default rung is the safe prior).

package/gsd-core/workflows/model-domain.md

@@ -45,6 +45,8 @@ From the project docs, build an internal draft:
 - Which nouns/verbs recur (candidate ubiquitous-language terms)?
 - Are there distinct business areas or user roles (candidate subdomains)?
 
+**Grounding maturity governs elicitation depth.** When the upstream docs are mature (a design spec, research corpus, or detailed brief already forged the vocabulary and areas), default every step to **draft-from-docs + confirm**: present complete drafts for correction, state which docs grounded them, and reserve actual questions for *genuine decision points* — contested classifications, the one-core call, complexity contradictions. The 2–3 probing rounds below are for thin grounding (a bare PROJECT.md), not a re-interview of what the docs already answer. Honor a posture stated in `$ARGUMENTS` without re-asking.
+
 **Check for an existing model:**
 ```bash
 ls .planning/DOMAIN-MODEL.md >/dev/null 2>&1 && echo "EXISTS" || echo "NEW"
@@ -77,6 +79,7 @@ Language — I drafted these terms: [list]. What needs fixing?
   3. Let me describe the vocabulary from scratch
 Reply with a number, or just tell me the corrections.
 ```
+**Text-mode batching:** when several questions are pending, present them as numbered *sections* in ONE message (each with its own option list) and accept combined replies ("1, 2" = first option of Q1, second of Q2) or free text per section — don't serialize one message per question.
 
 ## Step 4: Subdomain distillation (the pivotal step)
 
@@ -90,6 +93,7 @@ For each candidate area, classify it and **capture the rationale**. Apply the mi
 1. **Differentiation — not difficulty — decides Core.** If the user justifies Core by *difficulty, criticality, security, risk, or regulatory burden* rather than by competitive differentiation, test it: "Is this actually your competitive advantage, or a hard/critical-but-standard problem (e.g., tax, auth, encryption, compliance) you could buy?" If standard → **Generic (buy)**, not core. Critical ≠ differentiating; regulated ≠ differentiating.
 2. **CRUD that will grow.** Whenever an area is *described* as CRUD/simple/"just forms and dates" — regardless of the type being claimed — ask: "Will this accumulate real business rules and invariants over time, or stay simple data-in/data-out?" If it will grow → mark it **emerging Supporting** (the default for growing areas), not generic. It is Core only if it is itself the competitive differentiator — and there is normally exactly one of those. Claiming Core *while* describing it as trivial is a contradiction — Core means differentiating AND complex; probe which half is wrong.
 3. **Generic ≠ low quality.** Note to the user that "generic" means *not differentiating*, not *low effort*.
+4. **Strategic instrument.** A venture-critical area that is NOT product-differentiating (a benchmark/eval suite, an open standard, a public SDK ecosystem — value is positional, endgame may be neutrality/giveaway) doesn't fit the triad: record it as its **own candidate context** annotated *instrument — venture-critical*, rigor allocated by its derived complexity. **Core-grade rigor ≠ core** — you don't give away your core.
 
 **Complexity is derived, never asked.** For each non-generic area, elicit 2–3 of the reference rubric's five signals (invariants; lifecycle depth; derivation/optimization; temporal logic; policy variance) — usually one question: "What rules can never be broken here, and what's the hardest decision this area makes?" — then rate per the rubric, recording fired signals in the rationale cell. **Tripwire: Core+low is a contradiction** — probe: "If it's your differentiator but has no complex rules, what makes it hard to copy?" — it's either not core, or not low. Generic+high is a buy-harder signal.
 
@@ -141,9 +145,11 @@ DOMAIN-MODEL.md written — strategic domain foundation set.
   Subdomains: [N]  ([core] core · [supporting] supporting · [generic] generic)
   Bounded contexts: [N]  (or "deferred")
 
-Next: /gsd:plan-phase   (planning will use the subdomain complexity to shape architecture and tests)
+Next: /gsd:recommend-architecture   (uses the subdomain complexity) → testing → planning
 ```
 
+**Roadmap reconciliation:** ROADMAP.md was created before this model existed. Scan it — if a finding invalidates or reshapes a phase (a phase straddling two candidate contexts, a buy-decision making a build-phase moot, a core needing an earlier walking-skeleton), SAY SO explicitly and offer `/gsd:phase --edit` (or a roadmap refresh — the roadmapper re-reads discovery artifacts). Never leave a known contradiction between the model and the roadmap unspoken.
+
 </process>
 
 <critical_rules>
@@ -163,5 +169,6 @@ Next: /gsd:plan-phase   (planning will use the subdomain complexity to shape arc
 - Bounded contexts surfaced (with `--event-storming`), candidate-recorded, or explicitly deferred
 - No architecture prescribed
 - DOMAIN-MODEL.md written from the template and committed (when commit_docs is true)
-- User directed to /gsd:plan-phase
+- Roadmap reconciliation: contradictions with ROADMAP.md surfaced explicitly (revision offered, never silent)
+- User directed to /gsd:recommend-architecture
 </success_criteria>

package/gsd-core/workflows/recommend-architecture.md

@@ -38,6 +38,8 @@ cat .planning/DOMAIN-MODEL.md 2>/dev/null || true
 
 **Read `@~/.claude/gsd-core/references/architecture-decision.md` now** — it defines the two axes, the rung-signals, the "tall enough" gates, the Hard-Parts disintegrators/integrators, and the over-/under-engineering meta-tell.
 
+**Grounding maturity governs elicitation depth.** When upstream artifacts (DOMAIN-MODEL, a design spec, research) already answer a question below, draft-from-docs and present for confirmation — cite the source, don't re-interview. Reserve `AskUserQuestion` for genuine decision points: contested rungs, gate answers the docs don't record, and contradictions (the reconcile rule still ALWAYS runs). Honor a posture stated in `$ARGUMENTS` without re-asking.
+
 **If `NO_DOMAIN_MODEL`:** tell the user "No domain model found — I'll ask the complexity questions directly. (Consider `/gsd:model-domain` first for a sharper result.)" Then gather, per major area: is it core/supporting/generic, and how complex (rich rules vs CRUD)?
 
 From DOMAIN-MODEL.md (or the answers): extract each subdomain's type + complexity, **plus** the bounded contexts (owns / talks-to), the context-map relationships, and any flagged polysemes — Step 4.5 consumes them. The **core** subdomain's complexity is the primary driver of Axis A.
@@ -126,9 +128,11 @@ ADR-NNNN written — architecture decided.
   Fitness functions: [N] to enforce boundaries
   Promotion triggers: [N] recorded — re-check at /gsd:new-milestone
 
-Next: /gsd:plan-phase   (planning + test strategy will follow this shape)
+Next: /gsd:testing-strategy   (test shape follows this architecture) → plan-phase
 ```
 
+**Roadmap reconciliation:** ROADMAP.md predates this ADR. Scan it against the module map and topology — if a phase straddles module seams, the walking skeleton is missing/misplaced, or a buy-decision moots a build-phase, SAY SO explicitly and offer `/gsd:phase --edit` (or a roadmap refresh — the roadmapper re-reads discovery artifacts). Never leave a known ADR↔roadmap contradiction unspoken.
+
 </process>
 
 <critical_rules>

package/gsd-core/workflows/testing-strategy.md

@@ -41,6 +41,9 @@ cat TESTING-STANDARDS.md 2>/dev/null || true
 
 **Read `@~/.claude/gsd-core/references/test-strategy.md` now** — it defines behavior-over-implementation, sociable-by-default, test-once-at-cheapest-level, shape-follows-architecture (size axis), the gnarly-bits list, persistent-vs-transient e2e, and coverage-as-floor + mutation.
 
+**Grounding maturity governs elicitation depth.** When upstream artifacts (spec, ADR, strategies, research) already answer a step, draft-from-docs and present for confirmation — cite the source, don't re-interview. Reserve questions for genuine decision points and contradictions. Honor a posture stated in `$ARGUMENTS` without re-asking.
+
+
 **If `NO_ADR`:** tell the user "No architecture decision found — I'll ask briefly. (Consider `/gsd:recommend-architecture` first.)" Then, per major subdomain, get its rung (Transaction Script / Domain Model / Hexagonal / CQRS / Event Sourcing) and whether it's DB/integration-bound. Otherwise extract each subdomain's rung from the ADR.
 
 ## Step 3: Derive the shape FROM the architecture (per subdomain)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@therocketcode/gsd-core",
-  "version": "1.8.2",
+  "version": "1.8.3",
   "description": "GSD Core is a meta-prompting, context engineering, and spec-driven development system for AI coding agents.",
   "bin": {
     "gsd-core": "bin/install.js",