gsd-pi 2.4.0 → 2.5.1

package/src/resources/extensions/gsd/prompts/plan-milestone.md

@@ -12,7 +12,7 @@ Then:
 1. Read the template at `~/.gsd/agent/extensions/gsd/templates/roadmap.md`
 2. Read `.gsd/REQUIREMENTS.md` if it exists. Treat **Active** requirements as the capability contract for planning. If it does not exist, continue in legacy compatibility mode but explicitly note that requirement coverage is operating without a contract.
 3. If a `GSD Skill Preferences` block is present in system context, use it to decide which skills to load and follow during planning, without overriding required roadmap formatting
-4. Create the roadmap: decompose into demoable vertical slices — as many as the work needs, no more
+4. Create the roadmap: decompose into demoable vertical slices — as many as the work genuinely needs, no more. A simple feature might be 1 slice. Don't decompose for decomposition's sake.
 5. Order by risk (high-risk first)
 6. Write `{{outputPath}}` with checkboxes, risk, depends, demo sentences, proof strategy, verification classes, milestone definition of done, **requirement coverage**, and a boundary map. Write success criteria as observable truths, not implementation tasks. If the milestone crosses multiple runtime boundaries, include an explicit final integration slice that proves the assembled system works end-to-end in a real environment
 7. If planning produced structural decisions (e.g. slice ordering rationale, technology choices, scope exclusions), append them to `.gsd/DECISIONS.md` (read the template at `~/.gsd/agent/extensions/gsd/templates/decisions.md` if the file doesn't exist yet)
@@ -43,6 +43,38 @@ Apply these when decomposing and ordering slices:
 - **Don't invent risks.** If the project is straightforward, skip the proof strategy and just ship value in smart order. Not everything has major unknowns.
 - **Ship features, not proofs.** A completed slice should leave the product in a state where the new capability is actually usable through its real interface. A login flow slice ends with a working login page, not a middleware function. An API slice ends with endpoints that return real data from a real store, not hardcoded fixtures. A dashboard slice ends with a real dashboard rendering real data, not a component that renders mock props. If a slice can't ship the real thing yet because a dependency isn't built, it should ship with realistic stubs that are clearly marked for replacement — but the user-facing surface must be real.
 - **Ambition matches the milestone.** The number and depth of slices should match the milestone's ambition. A milestone promising "core platform with auth, data model, and primary user loop" should have enough slices to actually deliver all three as working features — not two proof-of-concept slices and a note that "the rest will come in the next milestone." If the milestone's context promises an outcome, the roadmap must deliver it.
+- **Right-size the decomposition.** Match slice count to actual complexity. If the work is small enough to build and verify in one pass, it's one slice — don't split it into three just because you can identify sub-steps. Multiple requirements can share a single slice. Conversely, don't cram genuinely independent capabilities into one slice just to keep the count low. Let the work dictate the structure.
+
+## Single-Slice Fast Path
+
+If the roadmap has only one slice, also write the slice plan and task plans inline during this unit — don't leave them for a separate planning session.
+
+1. Read the templates:
+   - `~/.gsd/agent/extensions/gsd/templates/plan.md`
+   - `~/.gsd/agent/extensions/gsd/templates/task-plan.md`
+2. `mkdir -p {{milestonePath}}/slices/S01/tasks`
+3. Write the S01 plan file at `{{milestonePath}}/slices/S01/S01-PLAN.md`
+4. Write individual task plans at `{{milestonePath}}/slices/S01/tasks/T01-PLAN.md`, etc.
+5. For simple slices, keep the plan lean — omit Proof Level, Integration Closure, and Observability sections if they would all be "none". Executable verification commands are sufficient.
+
+This eliminates a separate research-slice + plan-slice cycle when the work is straightforward.
+
+## Secret Forecasting
+
+After writing the roadmap, analyze the slices and their boundary maps for external service dependencies (third-party APIs, SaaS platforms, cloud providers, databases requiring credentials, OAuth providers, etc.).
+
+If this milestone requires any external API keys or secrets:
+
+1. Read the template at `~/.gsd/agent/extensions/gsd/templates/secrets-manifest.md` for the expected format
+2. Write `{{secretsOutputPath}}` listing every predicted secret as an H3 section with:
+   - **Service** — the external service name
+   - **Dashboard** — direct URL to the console/dashboard page where the key is created (not a generic homepage)
+   - **Format hint** — what the key looks like (e.g. `sk-...`, `ghp_...`, 40-char hex, UUID)
+   - **Status** — always `pending` during planning
+   - **Destination** — `dotenv`, `vercel`, or `convex` depending on where the key will be consumed
+   - Numbered step-by-step guidance for obtaining the key (navigate to dashboard → create project → generate key → copy)
+
+If this milestone does not require any external API keys or secrets, skip this step entirely — do not create an empty manifest.
 
 **You MUST write the file `{{outputAbsPath}}` before finishing.**
 

package/src/resources/extensions/gsd/prompts/plan-slice.md

@@ -12,7 +12,9 @@ Pay particular attention to **Forward Intelligence** sections — they contain h
 
 {{dependencySummaries}}
 
-Narrate your decomposition reasoning — why you're grouping work this way, what risks are driving the order, what verification strategy you're choosing and why.
+Narrate your decomposition reasoning — why you're grouping work this way, what risks are driving the order, what verification strategy you're choosing and why. Keep the narration proportional to the work — a simple slice doesn't need a long justification.
+
+**Right-size the plan.** If the slice is simple enough to be 1 task, plan 1 task. Don't split into multiple tasks just because you can identify sub-steps. Don't fill in sections with "None" when the section doesn't apply — omit them entirely. The plan's job is to guide execution, not to fill a template.
 
 Then:
 0. If `REQUIREMENTS.md` was preloaded above, identify which Active requirements the roadmap says this slice owns or supports. These are the requirements this plan must deliver — every owned requirement needs at least one task that directly advances it, and verification must prove the requirement is met.
@@ -20,43 +22,33 @@ Then:
    - `~/.gsd/agent/extensions/gsd/templates/plan.md`
    - `~/.gsd/agent/extensions/gsd/templates/task-plan.md`
 2. If a `GSD Skill Preferences` block is present in system context, use it to decide which skills to load and follow during planning, without overriding required plan formatting
-3. Define slice-level verification first — the objective stopping condition for this slice:
-   - For non-trivial slices: plan actual test files with real assertions. Name the files. The first task creates them (initially failing). Remaining tasks make them pass.
+3. Define slice-level verification — the objective stopping condition for this slice:
+   - For non-trivial slices: plan actual test files with real assertions. Name the files.
    - For simple slices: executable commands or script assertions are fine.
    - If the project is non-trivial and has no test framework, the first task should set one up.
    - If this slice establishes a boundary contract, verification must exercise that contract.
-4. Plan observability and diagnostics explicitly:
-   - For non-trivial backend, integration, async, stateful, or UI slices, include an `Observability / Diagnostics` section in the slice plan.
-   - Define how a future agent will inspect state, detect failure, and localize the problem.
-   - Prefer structured logs/events, stable error codes/types, status surfaces, and persisted failure state over ad hoc debug text.
-   - Include at least one verification check for a diagnostic or failure-path signal when relevant.
-5. Fill the `Proof Level` and `Integration Closure` sections truthfully:
-   - State whether the slice proves contract, integration, operational, or final-assembly behavior.
-   - Say whether real runtime or human/UAT is required.
-   - Name the wiring introduced in this slice and what still remains before the milestone is truly usable end-to-end.
-6. Decompose the slice into tasks, each fitting one context window
-7. Every task in the slice plan should be written as an executable increment with:
+4. **For non-trivial slices only** — plan observability, proof level, and integration closure:
+   - Include `Observability / Diagnostics` for backend, integration, async, stateful, or UI slices where failure diagnosis matters.
+   - Fill `Proof Level` and `Integration Closure` when the slice crosses runtime boundaries or has meaningful integration concerns.
+   - **Omit these sections entirely for simple slices** where they would all be "none" or trivially obvious.
+5. Decompose the slice into tasks, each fitting one context window. Each task needs:
    - a concrete, action-oriented title
    - the inline task entry fields defined in the plan.md template (Why / Files / Do / Verify / Done when)
-   - a matching task plan containing description, steps, must-haves, verification, observability impact, inputs, and expected output
-8. Each task needs: title, description, steps, must-haves, verification, observability impact, inputs, and expected output
-9. If verification includes test files, ensure the first task includes creating them with expected assertions (they should fail initially — that's correct)
-10. Write `{{outputPath}}`
-11. Write individual task plans in `{{sliceAbsPath}}/tasks/`: `T01-PLAN.md`, `T02-PLAN.md`, etc.
-12. **Self-audit the plan before continuing.** Walk through each check — if any fail, fix the plan files before moving on:
-    - **Completion semantics:** If every task were completed exactly as written, the slice goal/demo should actually be true at the claimed proof level. Do not allow a task plan that only scaffolds toward a future working state.
-    - **Requirement coverage:** Every must-have in the slice maps to at least one task. No must-have is orphaned.
-    - **Task completeness:** Every task has steps, must-haves, verification, observability impact, inputs, and expected output — none are blank or vague.
+   - a matching task plan file with description, steps, must-haves, verification, inputs, and expected output
+   - Observability Impact section **only if the task touches runtime boundaries, async flows, or error paths** — omit it otherwise
+6. Write `{{outputPath}}`
+7. Write individual task plans in `{{sliceAbsPath}}/tasks/`: `T01-PLAN.md`, `T02-PLAN.md`, etc.
+8. **Self-audit the plan.** Walk through each check — if any fail, fix the plan files before moving on:
+    - **Completion semantics:** If every task were completed exactly as written, the slice goal/demo should actually be true.
+    - **Requirement coverage:** Every must-have in the slice maps to at least one task. No must-have is orphaned. If `REQUIREMENTS.md` exists, every Active requirement this slice owns maps to at least one task.
+    - **Task completeness:** Every task has steps, must-haves, verification, inputs, and expected output — none are blank or vague.
     - **Dependency correctness:** Task ordering is consistent. No task references work from a later task.
-    - **Key links planned:** For every pair of artifacts that must connect (component → API, API → database, form → handler), there is an explicit step that wires them — not just "create X" and "create Y" in separate tasks with no connection step.
-    - **Scope sanity:** Target 2–5 steps and 3–8 files per task. 6–8 steps or 8–10 files is a warning — consider splitting. 10+ steps or 12+ files — must split. Each task must be completable in a single fresh context window.
-    - **Context compliance:** If context/research artifacts or `.gsd/DECISIONS.md` exist, the plan honors locked decisions and doesn't include deferred or out-of-scope items.
-    - **Requirement coverage:** If `REQUIREMENTS.md` exists, every Active requirement this slice owns (per the roadmap) maps to at least one task with verification that proves the requirement is met. No owned requirement is left without a task. No task claims to satisfy a requirement that is Deferred or Out of Scope.
-    - **Proof honesty:** The `Proof Level` and `Integration Closure` sections match what this slice will actually prove, and they do not imply live end-to-end completion if only fixture or contract proof is planned.
-    - **Feature completeness:** Every task produces real, user-facing progress — not just internal scaffolding. If the slice has a UI surface, at least one task builds the real UI (not a placeholder). If the slice has an API, at least one task connects it to a real data source (not hardcoded returns). If every task were completed and you showed the result to a non-technical stakeholder, they should see real product progress, not developer artifacts.
-13. If planning produced structural decisions (e.g. verification strategy, observability strategy, technology choices, patterns to follow), append them to `.gsd/DECISIONS.md`
-14. Commit: `docs({{sliceId}}): add slice plan`
-15. Update `.gsd/STATE.md`
+    - **Key links planned:** For every pair of artifacts that must connect, there is an explicit step that wires them.
+    - **Scope sanity:** Target 2–5 steps and 3–8 files per task. 10+ steps or 12+ files — must split. Each task must be completable in a single fresh context window.
+    - **Feature completeness:** Every task produces real, user-facing progress — not just internal scaffolding.
+9. If planning produced structural decisions, append them to `.gsd/DECISIONS.md`
+10. Commit: `docs({{sliceId}}): add slice plan`
+11. Update `.gsd/STATE.md`
 
 The slice directory and tasks/ subdirectory already exist. Do NOT mkdir. You are on the slice branch; all work stays here.
 

package/src/resources/extensions/gsd/prompts/replan-slice.md

@@ -31,7 +31,7 @@ All relevant context has been preloaded below — the roadmap, current slice pla
    - Ensure the slice Goal and Demo sections are still achievable with the new tasks, or update them if the blocker fundamentally changes what the slice can deliver
    - Update the Files Likely Touched section if the replan changes which files are affected
 5. If any incomplete task had a `T0x-PLAN.md`, remove or rewrite it to match the new task description.
-6. Commit all changes: `git add -A && git commit -m 'refactor({{sliceId}}): replan after blocker in {{blockerTaskId}}'`
+6. Do not commit manually — the system auto-commits your changes after this unit completes.
 7. Update `.gsd/STATE.md`
 
 **You MUST write `{{replanAbsPath}}` and the updated slice plan before finishing.**

package/src/resources/extensions/gsd/templates/plan.md

@@ -10,6 +10,8 @@
 
 ## Proof Level
 
+<!-- Omit this section entirely for simple slices where the answer is trivially obvious. -->
+
 - This slice proves: {{contract | integration | operational | final-assembly}}
 - Real runtime required: {{yes/no}}
 - Human/UAT required: {{yes/no}}
@@ -41,17 +43,11 @@
 
 ## Observability / Diagnostics
 
-<!-- Required for non-trivial backend, integration, async, stateful, or UI slices.
-     Describe how a future agent will inspect current state, detect failure,
-     and localize the problem with minimal ambiguity.
-
-     Prefer:
-     - structured logs/events over ad hoc console strings
-     - stable error codes/types over vague failures
-     - health/readiness/status surfaces over hidden internal state
-     - persisted failure state when it materially improves retries or recovery
+<!-- Include this section for non-trivial backend, integration, async, stateful, or UI slices.
+     OMIT ENTIRELY for simple slices where all fields would be "none".
 
-     Keep this section concise and high-signal. Do not log secrets or sensitive raw payloads. -->
+     When included, describe how a future agent will inspect current state, detect failure,
+     and localize the problem with minimal ambiguity. Keep it concise and high-signal. -->
 
 - Runtime signals: {{structured log/event, state transition, metric, or none}}
 - Inspection surfaces: {{status endpoint, CLI command, script, UI state, DB table, or none}}
@@ -60,6 +56,8 @@
 
 ## Integration Closure
 
+<!-- Omit this section entirely for simple slices with no meaningful integration concerns. -->
+
 - Upstream surfaces consumed: {{specific files / modules / contracts}}
 - New wiring introduced in this slice: {{entrypoint / composition / runtime hookup, or none}}
 - What remains before the milestone is truly usable end-to-end: {{list or "nothing"}}

package/src/resources/extensions/gsd/templates/preferences.md

@@ -8,6 +8,13 @@ custom_instructions: []
 models: {}
 skill_discovery:
 auto_supervisor: {}
+git:
+  auto_push:
+  push_branches:
+  remote:
+  snapshots:
+  pre_merge_check:
+  commit_type:
 ---
 
 # GSD Skill Preferences

package/src/resources/extensions/gsd/templates/secrets-manifest.md

@@ -0,0 +1,22 @@
+# Secrets Manifest
+
+<!-- This file lists predicted API keys and secrets for the milestone.
+     Each H3 section defines one secret with setup guidance.
+     The parser extracts entries by H3 heading (the env var name).
+     Bold fields: Service, Dashboard, Format hint, Status, Destination.
+     Guidance is a numbered list under each entry. -->
+
+**Milestone:** {{milestone}}
+**Generated:** {{generatedAt}}
+
+### {{ENV_VAR_NAME}}
+
+**Service:** {{serviceName}}
+**Dashboard:** {{dashboardUrl}}
+**Format hint:** {{formatHint}}
+**Status:** pending
+**Destination:** dotenv
+
+1. {{Step 1 guidance}}
+2. {{Step 2 guidance}}
+3. {{Step 3 guidance}}

package/src/resources/extensions/gsd/templates/task-plan.md

@@ -32,13 +32,13 @@ estimated_files: {{estimatedFiles}}
 
 ## Observability Impact
 
-<!-- If this task creates or changes a runtime boundary, async flow, API, UI state,
-     background process, or error path, explain how it improves or depends on
-     future agent observability. Use "None" when genuinely not applicable. -->
+<!-- OMIT THIS SECTION ENTIRELY for simple tasks that don't touch runtime boundaries,
+     async flows, APIs, background processes, or error paths.
+     Include it only when the task meaningfully changes how failures are detected or diagnosed. -->
 
-- Signals added/changed: {{structured logs, statuses, errors, metrics, or None}}
-- How a future agent inspects this: {{command, endpoint, file, UI state, or None}}
-- Failure state exposed: {{what becomes visible on failure, or None}}
+- Signals added/changed: {{structured logs, statuses, errors, metrics}}
+- How a future agent inspects this: {{command, endpoint, file, UI state}}
+- Failure state exposed: {{what becomes visible on failure}}
 
 ## Inputs