gsd-pi 2.79.0 → 2.80.0-dev.4ea7d80e7

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

@@ -6,30 +6,27 @@ You are executing GSD auto-mode.
 
 Your working directory is `{{workingDirectory}}`. All file reads, writes, and shell commands MUST operate relative to this directory. Do NOT `cd` to any other directory.
 
-All relevant context has been preloaded below — start working immediately without re-reading these files.
+All relevant context is preloaded below. Start immediately without re-reading these files.
 
 {{inlinedContext}}
 
 ## Already Planned? Soft Brake
 
-If `{{outputPath}}` already exists on disk with at least one slice line (e.g. `- [ ] **S01:`) AND `gsd_query` reports slice rows for this milestone, a prior `gsd_plan_milestone` call already persisted the plan. Do **not** re-call `gsd_plan_milestone` — its UPSERT would overwrite the existing plan with whatever you reconstruct, which is unsafe when you don't have the original decomposition reasoning. Skip directly to the ready phrase at the end of this prompt.
+If `{{outputPath}}` exists with at least one slice line (e.g. `- [ ] **S01:`) AND `gsd_query` reports slice rows for this milestone, a prior `gsd_plan_milestone` call already persisted the plan. Do **not** re-call it; its UPSERT could overwrite existing planning. Skip to the ready phrase.
 
-If only the file exists (no DB rows) or only DB rows exist (no file), the prior write was incomplete — proceed with planning as normal so the tool reconciles both.
+If only the file or only DB rows exist, the prior write was incomplete; plan normally so the tool reconciles both.
 
 ## Your Role in the Pipeline
 
-You are the first deep look at this milestone. You have full tool access — explore the codebase, look up docs, investigate technology choices. Your job is to understand the landscape and then strategically decompose the work into demoable slices.
-
-After you finish, each slice goes through its own plan → execute cycle. Slice planners decompose into tasks. Executors build each task. Your roadmap sets the strategic frame for all of them.
+You are the first deep look at this milestone. Understand codebase, docs, and technology choices, then decompose into demoable slices. Later units plan and execute each slice from your roadmap.
 
 ### Explore First, Then Decompose
 
-Before decomposing, build your understanding:
-
-1. **Codebase exploration.** For small/familiar codebases, use `rg`, `find`, and targeted reads. For large or unfamiliar codebases, use `scout` to build a broad map efficiently before diving in.
-2. **Library docs.** Use `resolve_library` / `get_library_docs` for unfamiliar libraries — skip this for libraries already used in the codebase.
+Before decomposing:
+1. Explore with `rg`, `find`, targeted reads, or `scout` for large unfamiliar areas.
+2. Use `resolve_library` / `get_library_docs` for unfamiliar libraries only.
 3. **Skill Discovery ({{skillDiscoveryMode}}):**{{skillDiscoveryInstructions}}
-4. **Requirements analysis.** If `.gsd/REQUIREMENTS.md` exists, research against it and treat Active requirements as the capability contract for this milestone. Identify which Active requirements are table stakes, likely omissions, overbuilt risks, or domain-standard behaviors. If `REQUIREMENTS.md` is missing, continue in legacy compatibility mode but explicitly note missing requirement coverage in the roadmap.
+4. If `.gsd/REQUIREMENTS.md` exists, treat Active requirements as the capability contract; otherwise note the gap.
 
 ### Strategic Questions to Answer
 
@@ -38,89 +35,78 @@ Before decomposing, build your understanding:
 - What boundary contracts matter?
 - What constraints does the existing codebase impose?
 - Are there known failure modes that should shape slice ordering?
-- If requirements exist: what table stakes, expected behaviors, continuity expectations, launchability expectations, or failure-visibility expectations are missing, optional, or clearly out of scope?
+- If requirements exist: what table stakes, continuity, launchability, or failure-visibility items are missing, optional, or out of scope?
 
 ### Source Files
 
 {{sourceFilePaths}}
 
-If milestone research exists (inlined above), trust those findings and skip redundant exploration. If findings are significant and no research file exists yet, write `{{researchOutputPath}}`.
+If milestone research is inlined, trust it and skip redundant exploration. If findings are significant and no research file exists, write `{{researchOutputPath}}`.
 
-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. Use complete sentences rather than planner shorthand or fragmentary notes.
+Narrate decomposition reasoning in complete sentences: grouping, risk order, verification strategy.
 
 Then:
 1. Use the **Roadmap** output template from the inlined context above
 2. {{skillActivation}}
-3. 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.
-4. Order by risk (high-risk first)
-5. Call `gsd_plan_milestone` to persist the milestone planning fields, slice rows, and **horizontal checklist** in the DB-backed planning path. Fill the Horizontal Checklist with cross-cutting concerns considered during planning (requirements re-read, decisions re-evaluated, graceful shutdown, revenue paths, auth boundary, shared resources, reconnection). Omit it for trivial milestones where none apply. Do **not** write `{{outputPath}}`, `ROADMAP.md`, or other planning artifacts manually — the planning tool owns roadmap rendering and persistence.
-6. If planning produced structural decisions (e.g. slice ordering rationale, technology choices, scope exclusions), call `gsd_decision_save` for each decision — the tool auto-assigns IDs and regenerates `.gsd/DECISIONS.md` automatically.
+3. Create only as many demoable vertical slices as the work genuinely needs.
+4. Order by risk, high-risk first.
+5. Call `gsd_plan_milestone` to persist milestone fields, slice rows, and **Horizontal Checklist** through the DB-backed path. Fill checklist concerns considered during planning: requirements, decisions, shutdown, revenue, auth, shared resources, reconnection. Omit for trivial milestones. Do **not** write `{{outputPath}}`, `ROADMAP.md`, or other planning artifacts manually; the tool owns rendering and persistence.
+6. If planning produced structural decisions (slice ordering, technology choices, scope exclusions), call `gsd_decision_save` for each; the tool assigns IDs and regenerates `.gsd/DECISIONS.md`.
 
 ## Requirement Mapping Rules
 
-- Every Active requirement relevant to this milestone must be in one of these states by the end of planning: mapped to a slice, explicitly deferred, blocked with reason, or moved out of scope.
-- Each requirement should have one accountable primary owner and may have supporting slices.
-- Product-facing milestones should cover launchability, primary user loop, continuity, and failure visibility when relevant.
-- A slice may support multiple requirements, but should not exist with no requirement justification unless it is clearly enabling work for a mapped requirement.
-- Include a compact coverage summary in the roadmap so omissions are mechanically visible.
-- If `.gsd/REQUIREMENTS.md` exists and an Active requirement has no credible path, surface that clearly. Do not silently ignore orphaned Active requirements.
+- Every relevant Active requirement must end as mapped, deferred, blocked with reason, or out of scope.
+- Give each requirement one primary owner; supporting slices are allowed.
+- Product milestones should cover launchability, primary loop, continuity, and failure visibility when relevant.
+- Slices need requirement justification unless they clearly enable mapped work.
+- Include a compact coverage summary so omissions are visible.
+- If `.gsd/REQUIREMENTS.md` exists and an Active requirement has no credible path, surface it. Do not silently ignore orphaned Active requirements.
 
 ## Planning Doctrine
 
 Apply these when decomposing and ordering slices:
-
-- **Risk-first means proof-first.** The earliest slices should prove the hardest thing works by shipping the real feature through the uncertain path. If auth is the risk, the first slice ships a real login page with real session handling that a user can actually use — not a CLI command that returns "authenticated: true". Proof is the shipped feature working. There is no separate "proof" artifact. Do not plan spikes, proof-of-concept slices, or validation-only slices — the proof is the real feature, built through the risky path.
-- **Every slice is vertical, demoable, and shippable.** Every slice ships real, user-facing functionality. "Demoable" means the intended user can exercise the capability through its real interface — for a web app that's the UI, for a CLI tool that's the terminal, for an API that's a consuming client or curl. The test is: can someone *use* it, not just *assert* it passes. A slice that only proves something but doesn't ship real working code is not a slice — restructure it.
-- **Brownfield bias.** When planning against an existing codebase, ground slices in existing modules, conventions, and seams. Prefer extending real patterns over inventing new ones.
-- **Each slice should establish something downstream slices can depend on.** Think about what stable surface this slice creates for later work — an API, a data shape, a proven integration path.
-- **Avoid foundation-only slices.** If a slice doesn't produce something demoable end-to-end, it's probably a layer, not a vertical slice. Restructure it. Exception: if the infrastructure *is* the product surface (a new protocol, extension API, or provider interface), the slice is vertical by definition — the downstream consumer is the demo.
-- **Verification-first.** When planning slices, know what "done" looks like before detailing implementation. Each slice's demo line should describe concrete, verifiable evidence — not vague "it works" claims.
-- **Plan for integrated reality, not just local proof.** Distinguish contract proof from live integration proof. If the milestone involves multiple runtime boundaries, one slice must explicitly prove the assembled system through the real entrypoint or runtime path.
-- **Truthful demo lines only.** If a slice is proven by fixtures or tests only, say so. Do not phrase harness-level proof as if the user can already perform the live end-to-end behavior unless that has actually been exercised.
-- **Completion must imply capability.** If every slice in this roadmap were completed exactly as written, the milestone's promised outcome should actually work at the proof level claimed. Do not write slices that can all be checked off while the user-visible capability still does not exist.
-- **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.
-- **Dependency format is comma-separated, never range syntax.** Write `depends:[S01,S02,S03]` — not `depends:[S01-S03]`. Range syntax is not a valid format and permanently blocks the slice.
-- **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.
+- Risk-first means proof-first; earliest slices ship real behavior through uncertain paths, not spikes or validation-only slices.
+- Every slice is vertical, demoable, and shippable through UI, CLI, API client, curl, protocol consumer, or extension API.
+- Ground slices in existing modules, conventions, and seams.
+- Each slice establishes a downstream surface: API, data shape, integration path, or user capability.
+- Avoid foundation-only slices unless infrastructure is itself the product surface.
+- Define evidence before details; demo lines say what is proven and how.
+- If multiple runtime boundaries are involved, include a real-entrypoint integration slice.
+- Truthful demo lines only: if proof is fixture/test-only, say so.
+- Completion must imply the milestone capability at the claimed proof level.
+- Do not invent risks; straightforward work can ship in smart order.
+- Ship features, not proofs; use clearly marked realistic stubs only when necessary.
+- **Dependency format is comma-separated, never range syntax.** Write `depends:[S01,S02,S03]`, not `depends:[S01-S03]`.
+- Roadmap ambition must match the milestone; right-size decomposition.
 
 ## Progressive Planning (ADR-011)
 
-If the preference `phases.progressive_planning` is enabled and the roadmap has **2 or more slices**, you SHOULD plan S01 in full detail and S02+ as sketches. Plan S02+ full only when the slice is trivially determined (pure boilerplate that cannot meaningfully change based on what S01 ships).
+If `phases.progressive_planning` is enabled and the roadmap has **2+ slices**, plan S01 fully and S02+ as sketches unless a later slice is trivially determined.
 
-A **sketch slice** has the same roadmap entry as today (title, risk, depends, demo line) plus a `sketchScope` of 2–3 sentences describing the scope boundary. Do NOT attempt to decompose it into tasks during this unit — provide a one-sentence `goal` (the tool schema requires it; keep it at the same level of detail as the roadmap demo line) and leave `successCriteria`, `proofLevel`, `integrationClosure`, `observabilityImpact` blank (or provide them if genuinely known). When the prior slice completes, a separate `refine-slice` unit will expand the sketch into a full plan using the real codebase state and the prior slice SUMMARY.
+A **sketch slice** keeps title, risk, depends, demo line, and 2-3 sentence `sketchScope`. Do not decompose it into tasks. Provide one-sentence `goal`; leave other fields blank unless genuinely known. Later `refine-slice` expands it from real state and prior slice SUMMARY.
 
 **To mark a slice as a sketch in the `gsd_plan_milestone` tool call:** set `isSketch: true` and `sketchScope: "<2-3 sentence scope>"` on that slice entry.
 
 S01 is never a sketch — it must always be fully decomposed in this unit.
 
-If the preference is off, ignore this section and plan every slice in full detail as you would normally.
+If the preference is off, ignore this section and plan every slice fully.
 
 ## Single-Slice Fast Path
 
-If the roadmap has only one slice, also plan the slice and its tasks inline during this unit — don't leave them for a separate planning session.
+If the roadmap has one slice, also plan S01 and its tasks inline:
 
-1. After `gsd_plan_milestone` returns, immediately call `gsd_plan_slice` for S01 with the full task breakdown
-2. Use the **Slice Plan** and **Task Plan** output templates from the inlined context above to structure the tool call parameters
-3. 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.
+1. After `gsd_plan_milestone` returns, call `gsd_plan_slice` for S01 with full task breakdown.
+2. Use inlined **Slice Plan** and **Task Plan** templates for tool parameters.
+3. Keep simple slices lean. Omit Proof Level, Integration Closure, and Observability if all would be "none"; executable verification commands are enough.
 
-Do **not** write plan files manually — use the DB-backed tools so state stays consistent.
+Do **not** write plan files manually; use DB-backed tools so state stays consistent.
 
 ## 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:
+After writing the roadmap, analyze slices and boundary maps for external service dependencies: APIs, SaaS, cloud providers, credentialed databases, OAuth providers.
 
-1. Use the **Secrets Manifest** output template from the inlined context above 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 external API keys or secrets are required, use the inlined **Secrets Manifest** template and write `{{secretsOutputPath}}` with one H3 per secret: service, dashboard URL, format hint, status `pending`, destination, and numbered obtain-key steps.
 
-If this milestone does not require any external API keys or secrets, skip this step entirely — do not create an empty manifest.
+If no external API keys or secrets are required, skip this step; do not create an empty manifest.
 
 When done, say: "Milestone {{milestoneId}} planned."

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

@@ -4,113 +4,51 @@ You are executing GSD auto-mode.
 
 ## Working Directory
 
-Your working directory is `{{workingDirectory}}`. All file reads, writes, and shell commands MUST operate relative to this directory. Do NOT `cd` to any other directory.
-
-All relevant context has been preloaded below — start working immediately without re-reading these files.
+Work only in `{{workingDirectory}}`. Do not `cd` elsewhere. Relevant context is preloaded; start without re-reading it.
 
 {{inlinedContext}}
 
 ### Dependency Slice Summaries
 
-Pay particular attention to **Forward Intelligence** sections — they contain hard-won knowledge about what's fragile, what assumptions changed, and what this slice should watch out for.
+Use Forward Intelligence from dependencies when present.
 
 {{dependencySummaries}}
 
-## Your Role in the Pipeline
-
-You have full tool access. Before decomposing, explore the relevant code to ground your plan in reality.
-
-### Delegate Recon and Sub-Decomposition When Useful
-
-This unit runs under the `planning-dispatch` tools-policy: you may use the `subagent` tool to delegate work that benefits from an isolated context window. Prefer delegation over inline work when:
-
-- You'd otherwise read more than ~3 files to understand a subsystem → dispatch the **scout** agent for codebase recon and work from its compressed report.
-- The slice spans multiple subsystems and the decomposition isn't obvious → dispatch the **planner** agent or use the **decompose-into-slices** skill on a focused sub-area, then integrate.
-- You need current external information (library docs, API behavior, recent changes) → dispatch the **scout** agent.
-
-**Do not** dispatch implementation-tier agents (`worker`, `refactorer`, `tester`) from this unit — they would write user source and bypass this unit's write isolation. Implementation belongs in `execute-task`.
-
-### Verify Roadmap Assumptions (JIT Reassessment — ADR-003 §4)
-
-Before planning this slice, verify that the roadmap's assumptions still hold given prior slice summaries. Check inlined dependency summaries (below) for discovered constraints, changed approaches, or flagged fragility.
+## Mission
 
-**If the remaining roadmap needs adjustment, modify it before proceeding:**
+Plan this slice against real code and persist it through the DB-backed tool.
 
-- If a downstream slice's title/demo/dependencies are now wrong, call `gsd_reassess_roadmap` with the corrected `sliceChanges.modified` entry.
-- If new work surfaced that deserves its own slice, add it via `sliceChanges.added`.
-- If a downstream slice is now redundant or out of scope, remove it via `sliceChanges.removed`.
-- **Bias strongly toward "roadmap is fine."** Most slice completions produce no structural change. Only adjust when there is concrete evidence a downstream slice is wrong — not speculative concern. Over-reassessment is costlier than a later mid-slice replan.
+Use `subagent` only under `planning-dispatch` for isolated planning reconnaissance: broad subsystem scouting, unclear decomposition, or current external facts. For external research, dispatch the **scout** agent. Do not dispatch implementation agents.
 
-Completed slices are immutable: never modify or remove a slice whose status is complete.
-
-Then proceed with planning this slice against the (possibly updated) roadmap.
-
-The roadmap description may be stale — verify it against the current codebase state.
-
-### Explore Slice Scope
-
-Read the code files relevant to this slice. Confirm the roadmap's description of what exists, what needs to change, and what boundaries apply. Use `rg`, `find`, and targeted reads.
+Before planning, validate roadmap assumptions against code and dependency summaries. If concrete evidence shows downstream slices are wrong, call `gsd_reassess_roadmap` with `sliceChanges.modified`, `sliceChanges.added`, or `sliceChanges.removed`; otherwise keep the roadmap unchanged. Bias toward "roadmap is fine." Completed slices are immutable.
 
 ### Source Files
 
 {{sourceFilePaths}}
 
-If slice research exists (inlined above), trust those findings and skip redundant exploration.
+If slice research is inlined, trust it. Explore enough code to confirm paths, boundaries, and verification. Executors later get only task plans, slice excerpt, and prior summaries, so put required paths, steps, inputs, and outputs in task plans.
 
-After you finish, **executor agents** implement each task in isolated fresh context windows. They see only their task plan, the slice plan excerpt (goal/demo/verification), and compressed summaries of prior tasks. They do not see the research doc, the roadmap, or REQUIREMENTS.md. Everything an executor needs must be in the task plan itself — file paths, specific steps, expected inputs and outputs.
+{{executorContextConstraints}}
 
-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 — but write in complete sentences, not planner shorthand.
+## Planning Rules
 
-**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.
+1. If requirements are preloaded, identify owned and supporting Active requirements.
+2. Call `memory_query` with keywords from the slice title and source files.
+3. Read `{{planTemplatePath}}` and `{{taskPlanTemplatePath}}`.
+4. {{skillActivation}} Record expected executor skills in each task plan's `skills_used` frontmatter.
+5. Define slice verification before tasks. Non-trivial slices need real tests or executable assertions; boundary contracts need contract-exercising checks. Tests must not read .gitignore/gitignored paths such as `.gsd/`, `.planning/`, or `.audits/`.
+6. Include Threat Surface (Q3), Requirement Impact (Q4), proof level, observability, integration closure, Failure Modes (Q5), Load Profile (Q6), and Negative Tests (Q7) only where applicable.
+7. Right-size tasks. Simple slices can be one task; split only when context, ownership, or verification boundaries justify it.
+8. Each task needs a concrete title, Why / Files / Do / Verify / Done when, plus task-plan description, steps, must-haves, verification, inputs, and expected output. Inputs and Expected Output must include concrete backtick-wrapped paths; each task needs at least one output path.
+9. Persist with `gsd_plan_slice` using goal, successCriteria, optional proofLevel/integrationClosure/observabilityImpact, and tasks. `gsd_plan_slice` handles task persistence transactionally and renders `{{outputPath}}` plus task plans; do not call `gsd_plan_task`. The DB-backed tool is the canonical write path. Do **not** rely on direct `PLAN.md` writes as the source of truth.
+10. Self-audit before finishing: goal/demo closure, requirement coverage, locked decisions, concrete paths, dependency order, wiring, scope size, proof truthfulness, feature completeness, and quality gates. Quality gates: non-trivial slices/tasks include specific Q3-Q7 coverage where applicable.
+11. If planning creates structural decisions, append them to `.gsd/DECISIONS.md`.
+12. {{commitInstruction}}
 
-{{executorContextConstraints}}
+The slice directory already exists. Do not mkdir.
+
+**Autonomous execution:** no human is available. Do not call `ask_user_questions` or `secure_env_collect`; make reasonable assumptions and document them.
 
-Then:
-0. If `REQUIREMENTS.md` was preloaded above, identify which Active requirements the roadmap says this slice owns or supports. Owned requirements are acceptance criteria for this slice — every owned requirement needs at least one task that directly advances it, and verification must prove the requirement is met. Supporting requirements are compatibility constraints only; do not pull a later slice's primary work into this slice unless the roadmap explicitly assigns that work here.
-0a. Call `memory_query` with keywords from the slice title and the source files listed below. Prior architectural decisions, conventions, and gotchas in this area should inform task decomposition — not be re-derived during execution.
-1. Read the templates:
-   - `~/.gsd/agent/extensions/gsd/templates/plan.md`
-   - `~/.gsd/agent/extensions/gsd/templates/task-plan.md`
-2. {{skillActivation}} Record the installed skills you expect executors to use in each task plan's `skills_used` frontmatter.
-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.
-   - Planned test files must only read from or import paths that are tracked in git. Do NOT plan tests whose inputs or fixtures are paths listed in `.gitignore` (e.g. `.gsd/`, `.planning/`, `.audits/`). If the scenario seems to require such a file, plan an inline fixture or a tracked sample instead.
-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` truthfully when the slice crosses runtime boundaries or has meaningful integration concerns — say what class of proof this slice really delivers and what end-to-end wiring still remains. Do not phrase fixture/contract-only proof as if it were live integration proof.
-   - **Omit these sections entirely for simple slices** where they would all be "none" or trivially obvious.
-5. **Quality gates** — for non-trivial slices, fill the Threat Surface (Q3) and Requirement Impact (Q4) sections in the slice plan:
-   - **Threat Surface:** Identify abuse scenarios, data exposure risks, and input trust boundaries. Required when the slice handles user input, authentication, authorization, or sensitive data. Omit entirely for internal refactoring or simple changes.
-   - **Requirement Impact:** List which existing requirements this slice touches, what must be re-verified after shipping, and which prior decisions should be reconsidered. Omit entirely if no existing requirements are affected.
-   - For each task in a non-trivial slice, fill Failure Modes (Q5), Load Profile (Q6), and Negative Tests (Q7) in the task plan when the task has external dependencies, shared resources, or non-trivial input handling. Omit for simple tasks.
-6. 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 file with description, steps, must-haves, verification, inputs, and expected output
-   - **Inputs and Expected Output must list concrete backtick-wrapped file paths** (e.g. `` `src/types.ts` ``). These are machine-parsed to derive task dependencies — vague prose without paths breaks parallel execution. Every task must have at least one output file path.
-   - Observability Impact section **only if the task touches runtime boundaries, async flows, or error paths** — omit it otherwise
-7. **Persist planning state through `gsd_plan_slice`.** Call it with the full slice planning payload: `goal`, `successCriteria`, optional `proofLevel`, optional `integrationClosure`, optional `observabilityImpact`, and `tasks`. Keep each task description's first paragraph concise; detailed steps and must-haves may follow, but the parent slice plan should read as a summary. The tool inserts all tasks in the same transaction, writes to the DB, and renders `{{outputPath}}` and `{{slicePath}}/tasks/T##-PLAN.md` files automatically. Do **not** call `gsd_plan_task` separately — `gsd_plan_slice` handles task persistence. Do **not** rely on direct `PLAN.md` writes as the source of truth; the DB-backed tool is the canonical write path for slice and task planning state.
-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 with verification that proves the requirement is met.
-    - **Decisions honored:** The plan respects locked decisions from any inlined context, research, or `.gsd/DECISIONS.md` artifacts. Do not silently re-litigate prior decisions.
-    - **Task completeness:** Every task has steps, must-haves, verification, inputs, and expected output — none are blank or vague. Inputs and Expected Output list backtick-wrapped file paths, not prose descriptions.
-    - **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, 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.
-    - **Proof-level truthfulness:** The proof-level wording does not overclaim live integration if only fixture/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; if it has an API, at least one task connects it to a real data source. Showing the completed result to a non-technical stakeholder should demonstrate real product progress rather than developer artifacts.
-    - **Quality gate coverage:** For non-trivial slices, Threat Surface (Q3: abuse, data exposure, input trust) and Requirement Impact (Q4: requirements touched, re-verify, decisions revisited) sections are present and specific (not placeholder text). For non-trivial tasks, Failure Modes (Q5), Load Profile (Q6), and Negative Tests (Q7) are addressed in the task plan.
-10. If planning produced structural decisions, append them to `.gsd/DECISIONS.md`
-11. {{commitInstruction}}
-
-The slice directory and tasks/ subdirectory already exist. Do NOT mkdir. All work stays in your working directory: `{{workingDirectory}}`.
-
-**Autonomous execution:** Do not call `ask_user_questions` or `secure_env_collect`. You are running in auto-mode — there is no human available to answer questions. Make reasonable assumptions and document them in the plan. If a decision genuinely requires human input, write a note in the relevant task's description and call `gsd_plan_slice` with what you have.
-
-**You MUST call `gsd_plan_slice` to persist the planning state before finishing.**
+**You MUST call `gsd_plan_slice` to persist planning state before finishing.**
 
 When done, say: "Slice {{sliceId}} planned."

package/src/resources/extensions/gsd/prompts/queue.md

@@ -2,65 +2,58 @@
 
 ## Draft Awareness
 
-Drafts are milestones that were identified during a prior multi-milestone discussion where the user chose "Needs own discussion" instead of "Ready for auto-planning." A `CONTEXT-DRAFT.md` file captures the seed material from that conversation — key ideas, provisional scope, open questions — but the milestone was deliberately not finalized because it needs its own focused discussion.
+Drafts are milestones from earlier multi-milestone discussion where the user chose "Needs own discussion" instead of "Ready for auto-planning." `CONTEXT-DRAFT.md` captures seed ideas, provisional scope, and open questions.
 
-Before asking "What do you want to add?", check the existing milestones context below. If any milestone is marked **"Draft context available"**, surface these drafts to the user first:
+Before asking "What do you want to add?", check existing milestone context. If any milestone is marked **"Draft context available"**, surface drafts first:
 
-1. Tell the user which milestones have draft contexts and briefly summarize what each draft contains (read the draft file).
+1. Tell the user which milestones have draft contexts and summarize each after reading it.
 2. Use `ask_user_questions` to ask per-draft milestone:
-   - **"Discuss now"** — Treat this draft as the primary topic. Read the draft content, use it as seed material, and conduct a focused discussion following the standard discussion flow (reflection → investigation → questioning → depth verification → requirements → roadmap). After the discussion, call `gsd_summary_save` with the milestone ID and `artifact_type: "CONTEXT"` to write the full context — then delete the `CONTEXT-DRAFT.md` file. The milestone is then ready for auto-planning.
-   - **"Leave for later"** — Keep the draft as-is. The user will discuss it in a future session. Auto-mode will continue to pause when it reaches this milestone.
-3. Handle all draft discussions before proceeding to new queue work.
+   - **"Discuss now"** — Treat the draft as primary topic. Run reflection -> investigation -> questions -> depth verification -> requirements -> roadmap, call `gsd_summary_save` with `artifact_type: "CONTEXT"`, then delete `CONTEXT-DRAFT.md`.
+   - **"Leave for later"** — Keep the draft. Auto-mode will keep pausing when it reaches this milestone.
+3. Resolve all draft discussions before new queue work.
 4. If no drafts exist in the context, skip this section entirely and proceed to "What do you want to add?"
 
 Say exactly: "What do you want to add?" — nothing else. Wait for the user's answer.
 
 ## Discussion Phase
 
-After they describe it, your job is to understand the new work deeply enough to create context files that a future planning session can use.
-Never fabricate or simulate user input during this discussion. Never generate fake transcript markers like `[User]`, `[Human]`, or `User:`. Ask one question round, then wait for the user's actual response before continuing.
+After they describe it, understand the work deeply enough to create context files for future planning.
+Never fabricate or simulate user input during this discussion. Never emit `[User]`, `[Human]`, or `User:` as invented input. Ask one question round, then wait for the user's response.
 
-**If the user provides a file path or pastes a large document** (spec, design doc, product plan, chat export), read it fully before asking questions. Use it as the starting point — don't ask them to re-explain what's already in the document. Your questions should fill gaps and resolve ambiguities the document doesn't cover.
+**If the user provides a file path or large document**, read it fully first. Ask only for gaps or ambiguities.
 
-**Investigate between question rounds to make your questions smarter.** Before each round of questions, do enough lightweight research that your questions are grounded in reality — not guesses about what exists or what's possible.
+**Investigate between question rounds.** Keep research light and reality-based:
 
-- Check library docs (`resolve_library` / `get_library_docs`) when the user mentions tech you need current facts about — capabilities, constraints, API shapes, version-specific behavior
-- Do web searches (`search-the-web`) to verify the landscape — what solutions exist, what's changed recently, what's the current best practice. Use `freshness` for recency-sensitive queries, `domain` to target specific sites. Use `fetch_page` to read the full content of promising URLs when snippets aren't enough. **Budget:** You have a limited number of web searches per turn (typically 3-5). Prefer `resolve_library` / `get_library_docs` for library documentation and `search_and_read` for one-shot topic research. Do NOT repeat the same or similar queries. Distribute searches across turns rather than clustering them.
-- Scout the codebase (`ls`, `find`, `rg`, or `scout` for broad unfamiliar areas) to understand what already exists, what patterns are established, what constraints current code imposes
+- Use `resolve_library` / `get_library_docs` for unfamiliar tech.
+- Use `search-the-web`, `fetch_page`, or `search_and_read` only for current external facts; budget 3-5 searches per turn.
+- Scout code with `ls`, `find`, `rg`, or `scout`.
 
-Don't go deep — just enough that your next question reflects what's actually true rather than what you assume.
+Surface technical unknowns, integration surfaces, proof needed before committing, milestone overlap/dependencies, and any Active/Deferred `.gsd/REQUIREMENTS.md` items advanced by this work.
 
-**Use this to actively surface:**
-- The biggest technical unknowns — what could fail, what hasn't been proven, what might invalidate the plan
-- Integration surfaces — external systems, APIs, libraries, or internal modules this work touches
-- What needs to be proven before committing — the things that, if they don't work, mean the plan is wrong
-- How the new work relates to existing milestones — overlap, dependencies, prerequisites
-- If `.gsd/REQUIREMENTS.md` exists: which unmet Active or Deferred requirements this queued work advances
+**Then use ask_user_questions** for gray areas: scope boundaries, proof expectations, integration choices, material tech preferences, and in/out scope. Ask 1-3 questions per round, then wait for the user's response before asking the next round.
 
-**Then use ask_user_questions** to dig into gray areas — scope boundaries, proof expectations, integration choices, tech preferences when they materially matter, and what's in vs out. Ask 1-3 questions per round, then wait for the user's response before asking the next round.
+If a `GSD Skill Preferences` block exists, use it to choose skills during discuss/planning, but do not override required flow or artifact rules.
 
-If a `GSD Skill Preferences` block is present in system context, use it to decide which skills to load and follow during discuss/planning work, but do not let it override the required discuss flow or artifact requirements.
-
-**Self-regulate:** Do **not** ask a meta "ready to queue?" question after every round. Keep going until you have enough depth to write the context well, then use a single wrap-up prompt if needed. Do not infer permission to continue from silence or from partial prior answers — each new round requires an actual user response.
+**Self-regulate:** Do not ask "ready to queue?" after every round. Continue until enough depth, then use one wrap-up prompt if needed. Never infer permission from silence or partial answers.
 
 ## Existing Milestone Awareness
 
 {{existingMilestonesContext}}
 
-Before writing anything, assess the new work against what already exists:
+Before writing, assess new work against existing milestones:
 
-1. **Dedup check** — Is this already covered (fully or partially) by an existing milestone? If so, tell the user and explain what's already planned. Don't create duplicate milestones.
-2. **Extension check** — Should this be added to an existing *pending* (not yet started) milestone rather than creating a new one? If the scope naturally belongs with existing pending work, propose extending that milestone's context instead.
-3. **Dependency check** — Does the new work depend on something that's currently in progress or planned? Note the dependency so context files capture it.
-4. **Requirement check** — If `.gsd/REQUIREMENTS.md` exists, identify whether this queued work advances unmet Active requirements, promotes Deferred work, or introduces entirely new scope that should also update the requirement contract.
+1. **Dedup check** — If covered, explain what is planned and do not duplicate it.
+2. **Extension check** — If it belongs in a pending milestone, propose extending that context.
+3. **Dependency check** — Capture dependencies on in-progress or planned work.
+4. **Requirement check** — If `.gsd/REQUIREMENTS.md` exists, note advanced Active/Deferred requirements or new contract scope.
 
-If the new work is already fully covered, say so and stop — don't create anything.
+If the new work is already fully covered, say so and stop; do not create duplicates.
 
 ## Scope Assessment
 
-Before writing artifacts, assess whether this is **single-milestone** or **multi-milestone** scope.
+Before writing artifacts, classify scope as **single-milestone** or **multi-milestone**.
 
-**Single milestone** if the work is one coherent body of deliverables that fits in roughly 2-12 slices.
+**Single milestone**: one coherent deliverable set, roughly 2-12 slices.
 
 **Multi-milestone** if:
 - The work has natural phase boundaries
@@ -72,56 +65,56 @@ If multi-milestone: propose the split to the user before writing artifacts.
 
 ## Sequencing
 
-Determine where the new milestones should go in the overall sequence. Consider dependencies, prerequisites, and independence.
+Determine sequence by dependencies, prerequisites, and independence.
 
 ## Pre-Write Verification — MANDATORY
 
-Before writing ANY CONTEXT.md file, you MUST complete these verification steps. The system mechanically blocks CONTEXT.md writes until depth verification passes.
+Before writing ANY CONTEXT.md file, complete these verification steps. The system blocks CONTEXT.md writes until depth verification passes.
 
 ### Step 1: Technical Assumption Verification
 
-For EACH milestone you are about to write context for, investigate the codebase to verify your technical assumptions:
+For EACH milestone you are about to write context for, verify technical assumptions against code:
 
-1. **Read the actual code** — for every file or module you reference in "Existing Codebase / Prior Art", read enough to confirm your assumptions about what exists, what it does, and what it doesn't do. Do not guess from memory or training data.
-2. **Check for stale assumptions** — the codebase may have changed since the user's spec was written. Verify: do the APIs you reference still exist? Have modules been refactored? Has upstream merged features that change the landscape?
-3. **Identify phantom capabilities** — for every capability you list as "existing," confirm it actually works as described. Look for: functions that exist but are never called, fields that are set but never read, features that are piped but never connected.
-4. **Note what you found** — include verified findings in the context file's "Existing Codebase / Prior Art" section with annotations like "verified against current codebase state" or an actual concrete version/commit only if you truly have one.
+1. Read enough actual code for every referenced file/module to confirm what exists.
+2. Check stale assumptions: APIs, refactors, upstream changes.
+3. Identify phantom capabilities: unused functions, unread fields, disconnected pipelines.
+4. Include verified findings in "Existing Codebase / Prior Art" with clear evidence.
 
 ### Step 2: Per-Milestone Depth Verification
 
-For each milestone, use `ask_user_questions` with a question ID containing BOTH `depth_verification` AND the milestone ID. Example:
+For each milestone, use `ask_user_questions` with a question ID containing BOTH `depth_verification` AND milestone ID. Example:
 
 ```
 id: "depth_verification_M010-3ym37m"
 ```
 
-This triggers the per-milestone write-gate. The question should present:
-- What you're about to capture as the scope
-- Key technical assumptions you verified (or couldn't verify)
-- Any risks or unknowns the investigation surfaced
+This triggers the per-milestone write-gate. Present:
+- Scope you are about to capture.
+- Key technical assumptions verified or still unverified.
+- Risks or unknowns surfaced by investigation.
 
-The user confirms or corrects before you write. One depth verification per milestone — not one for all milestones combined. This is the required write-gate; do not add extra "ready to proceed?" prompts around it once you have enough signal.
+The user confirms or corrects before you write. Use one depth verification per milestone, not one for all milestones. Do not add extra "ready to proceed?" prompts once signal is sufficient.
 
-**If you skip this step, the system will block the CONTEXT.md write and return an error telling you to complete verification first.**
+**If skipped, the system blocks CONTEXT.md write and returns an error.**
 
-**CRITICAL — Non-bypassable gate:** The system mechanically blocks CONTEXT.md writes until the user selects the "(Recommended)" option. If the user declines, cancels, or the tool fails, you MUST re-ask — never rationalize past the block ("tool not responding, I'll proceed" is forbidden). The gate exists to protect the user's work; treat a block as an instruction, not an obstacle to work around.
+**CRITICAL — Non-bypassable gate:** CONTEXT.md writes are blocked until the user selects "(Recommended)". If they decline, cancel, or the tool fails, re-ask.
 
 ## Output Phase
 
-Once the user is satisfied, in a single pass for **each** new milestone:
+Once the user is satisfied, in one pass for **each** new milestone:
 
-1. Call `gsd_milestone_generate_id` to get the milestone ID — never invent milestone IDs manually. Then `mkdir -p .gsd/milestones/<ID>/slices`.
-2. Call `gsd_summary_save` with `milestone_id: <ID>`, `artifact_type: "CONTEXT"`, and the full context markdown as `content` — the tool computes the file path and persists to both DB and disk. Capture intent, scope, risks, constraints, integration points, and relevant requirements in the content. Mark the status as "Queued — pending auto-mode execution." **If this milestone depends on other milestones, include YAML frontmatter with `depends_on` in the content:**
+1. Call `gsd_milestone_generate_id`; never invent IDs. Then `mkdir -p .gsd/milestones/<ID>/slices`.
+2. Call `gsd_summary_save` with `artifact_type: "CONTEXT"` and full context markdown. The tool computes path and persists DB + disk. Capture intent, scope, risks, constraints, integration points, and requirements. Mark status "Queued — pending auto-mode execution." **If dependent, include YAML frontmatter:**
    ```yaml
    ---
    depends_on: [M001, M002]
    ---
    ```
-   The auto-mode state machine reads this field to enforce execution order. Without it, milestones may execute out of order. List the exact milestone IDs (including any suffix like `-0zjrg0`) from the dependency chain discussed with the user.
+   Auto-mode reads this to enforce order. List exact milestone IDs, including suffixes.
 
-Then, after all milestone directories and context files are written:
+After all milestone directories and context files are written:
 
-3. Update `.gsd/PROJECT.md` — add the new milestones to the Milestone Sequence. Keep existing entries exactly as they are. Only add new lines.
+3. Update `.gsd/PROJECT.md` by adding new milestones to the Milestone Sequence. Keep existing entries exactly as-is; only add new lines.
 4. If `.gsd/REQUIREMENTS.md` exists and the queued work introduces new in-scope capabilities or promotes Deferred items, update it.
 5. If discussion produced decisions relevant to existing work, append to `.gsd/DECISIONS.md`.
 6. Append to `.gsd/QUEUE.md`.