@tekyzinc/gsd-t 3.29.10 → 4.0.12

package/commands/gsd-t-prd.md

@@ -1,330 +1,44 @@
 # GSD-T: PRD — Generate a Product Requirements Document
 
-You are a Product Requirements Document generator optimized for the GSD-T (Get Stuff Done — Teams) contract-driven development methodology. Your job is to take a user's idea — however rough — and produce a PRD that feeds directly into GSD-T's automated workflow: `gsd-t-project`, `gsd-t-milestone`, `gsd-t-partition`, and `gsd-t-plan`.
+You are the lead agent. Generate a PRD by invoking the generic upper-stage Workflow at `templates/workflows/gsd-t-phase.workflow.js` with `phase: "prd"`. The output, `docs/prd.md`, feeds directly into `gsd-t-project`, `gsd-t-milestone`, `gsd-t-partition`, and `gsd-t-plan`.
 
-This command spawns a dedicated PRD subagent for fresh context, reads all available GSD-T project state, and outputs `docs/prd.md` ready for use.
-
-## Step 0: Launch via Subagent
-
-To give PRD generation a fresh context window:
-
-**If you are the orchestrating agent** (you received the slash command directly):
-
-**OBSERVABILITY LOGGING (MANDATORY) — wrap the PRD subagent spawn with `captureSpawn`:**
+## What this command does
 
 ```
-node -e "
-const { captureSpawn } = require('./bin/gsd-t-token-capture.cjs');
-(async () => {
-  await captureSpawn({
-    command: 'gsd-t-prd',
-    step: 'Step 0',
-    model: 'sonnet',
-    description: 'prd: {topic summary}',
-    projectDir: '.',
-    notes: 'prd: {topic summary}',
-    spawnFn: async () => { /* Task subagent (subagent_type: general-purpose):
-      'You are running gsd-t-prd for this request: {\$ARGUMENTS}
-      Working directory: {current project root}
-      Read CLAUDE.md and .gsd-t/progress.md for project context, then execute gsd-t-prd starting at Step 1.' */ },
-  });
-})();
-"
+preflight → brief (kind=prd) → PRD agent (opus, with phase protocol)
 ```
 
-`captureSpawn` parses `result.usage` and writes the row to `.gsd-t/token-log.md` under the canonical header. Tokens column renders as `in=N out=N cr=N cc=N $X.XX` or `—`, never `N/A`.
-
-Relay the subagent's summary to the user. **Do not execute Steps 1–6 yourself.**
-
-**If you are the spawned subagent** (your prompt says "starting at Step 1"):
-Continue to Step 1 below.
-
-## Step 1: Load Project Context
-
-Read all available GSD-T state to understand the project before asking the user anything:
-
-1. `CLAUDE.md` — tech stack, conventions, autonomy level
-2. `.gsd-t/progress.md` — current milestone, version, decision log
-3. `.gsd-t/backlog.md` (if exists) — queued items that may inform scope
-4. `docs/requirements.md` (if exists) — existing requirements to build on
-5. `docs/architecture.md` (if exists) — system design already established
-6. `docs/workflows.md` (if exists) — user flows already defined
-7. `.gsd-t/contracts/` (if exists) — domain interfaces already contracted
-
-From $ARGUMENTS, identify:
-- The product/feature topic (what the PRD is about)
-- Any scope hints (greenfield, feature addition, rebuild)
-- Any explicit constraints the user mentioned
-
-## Step 2: Classify the Build Type
-
-Based on the loaded context and $ARGUMENTS, determine:
-
-| Type | Signal | GSD-T Target |
-|------|--------|-------------|
-| **Project** | New app/system, no existing codebase or pre-init state | `gsd-t-project` |
-| **Feature** | Addition to existing system (progress.md exists with milestones) | `gsd-t-feature` |
-| **Multiple Features** | Several related additions to existing system | Multiple `gsd-t-feature` calls |
-
-State the classification in your opening response. If ambiguous, present the two most likely options with brief reasoning and ask the user to confirm.
-
-## Step 3: Adaptive Intake
-
-Ask targeted questions based on what's MISSING from the loaded context. Skip questions you can answer from existing docs. Ask ONE question at a time unless the user signals they prefer batch mode ("just ask me everything at once").
-
-### Always Required (fill from docs or ask):
-
-1. **Problem** — What problem does this solve? Who experiences it?
-2. **Users** — Who are the primary users? Any secondary types (admin, API consumer)?
-3. **MVP Boundary** — What is the absolute minimum that proves this works? (GSD-T milestone sequencing depends on MVP being defined by milestone 2-3)
-4. **Exclusions** — What is explicitly NOT in scope? (GSD-T requires exclusion lists at milestone, domain, and partition level)
-5. **Success Criteria** — How will you know it's working? Give measurable outcomes.
-
-### Tech Stack (fill from CLAUDE.md or ask):
-
-6. **Language & Runtime** — If not in CLAUDE.md
-7. **Database** — If not in CLAUDE.md
-8. **Auth Strategy** — If not in CLAUDE.md
-9. **Deployment Target** — If not in CLAUDE.md
-
-### Architecture (needed for partition):
-
-10. **Key Components** — What are the major pieces? (API server, worker, SPA, CLI, etc.)
-11. **Core Data Model** — What are the 3-5 most important entities? What are their relationships?
-12. **External Integrations** — Any third-party services? (payments, email, storage, AI APIs)
-
-### Feature-Specific (only when Type = Feature):
-
-13. **Integration Points** — Which existing screens, APIs, or flows does this touch?
-14. **DB Impact** — New tables, or extending existing ones? Which ones?
-15. **Auth/Permission Changes** — New roles, permissions, or access changes?
-16. **Breaking Changes** — API response shape changes? URL changes? UI flow changes?
-
-### Stop Asking When You Have:
-- Clear problem statement with target user
-- MVP boundary defined
-- Full tech stack (fill from CLAUDE.md where available)
-- Core data model entities and relationships (field-level)
-- Key components identifiable at file-path level
-- External integrations listed
-- Explicit exclusions stated
-- Measurable success criteria
-- (For features) Integration points and DB impact clear
-
-**Infer when possible.** If CLAUDE.md says "TypeScript/Node + PostgreSQL + Vercel", state those as assumed and ask for confirmation rather than re-asking. If the user says "React app with Supabase", you know the DB is Postgres and auth is likely Supabase Auth.
-
-## Step 4: Generate the PRD
-
-Once intake is complete, generate the PRD in this exact format. Every section exists because a specific GSD-T command reads it.
-
-```markdown
-# PRD: {Product/Feature Name}
-
-Generated: {YYYY-MM-DD}
-GSD-T Project: {project name from CLAUDE.md or progress.md}
-Build Type: {Project | Feature | Multiple Features}
-
-## Problem Statement
-
-{Who has this problem, what the problem is, why it matters. 2-4 sentences.}
-
-## Target Users
-
-| User Type | Description | Key Needs |
-|-----------|-------------|-----------|
-| {type} | {who they are} | {what they need from this system} |
-
-## MVP Definition
-
-{The minimum viable product — what must be true for the first usable version.}
-
-### MVP Includes
-- {capability 1}
-- {capability 2}
-
-### MVP Explicitly Excludes
-- {exclusion 1} — {brief reason}
-- {exclusion 2}
-
-## Tech Stack
-
-| Layer | Choice | Rationale |
-|-------|--------|-----------|
-| Language/Runtime | {e.g., TypeScript / Node.js 20} | {why} |
-| Framework | {e.g., Next.js 14 App Router} | {why} |
-| Database | {e.g., PostgreSQL 16} | {why} |
-| ORM/Query | {e.g., Drizzle ORM} | {why} |
-| Frontend | {e.g., React 18 + Tailwind CSS} | {why} |
-| Auth | {e.g., NextAuth.js with email + Google OAuth} | {why} |
-| Testing | {e.g., Vitest + Playwright} | {why} |
-| Deployment | {e.g., Vercel + Supabase} | {why} |
-
-## Functional Requirements
-
-| ID | Requirement | Priority | User Type |
-|----|-------------|----------|-----------|
-| REQ-001 | {User can register with email and password} | P1 | {end-user} |
-| REQ-002 | {User can log in and receive a session token} | P1 | {end-user} |
-| REQ-003 | {description} | P1/P2/P3 | {user type} |
-
-Priority guide:
-- P1: Must have for MVP
-- P2: Must have for v1 (post-MVP)
-- P3: Nice to have / future
-
-## Technical Requirements
+The agent takes a user's idea — however rough — reads available GSD-T project state, and produces `docs/prd.md` with functional and non-functional requirements traceable to acceptance criteria.
 
-| ID | Requirement | Priority |
-|----|-------------|----------|
-| TECH-001 | {API response times under 200ms for core endpoints} | P1 |
-| TECH-002 | {description} | P1/P2/P3 |
+## Step 1: Load context
 
-## Non-Functional Requirements
+Read any existing `docs/requirements.md`, `docs/architecture.md`, and `.gsd-t/progress.md`. Capture the user's idea from `$ARGUMENTS`.
 
-| ID | Requirement | Metric |
-|----|-------------|--------|
-| NFR-001 | {Page load time} | {< 2 seconds on 3G} |
-| NFR-002 | {description} | {measurable target} |
+## Step 2: Invoke the phase Workflow
 
-## Architecture
-
-### System Overview
-
-{2-3 paragraphs describing the high-level architecture — how components connect, data flows, deployment topology.}
-
-### Components
-
-| Component | Purpose | Suggested Path | Dependencies |
-|-----------|---------|---------------|--------------|
-| {API Server} | {Handles all backend logic} | `src/server/` | {Database, Auth} |
-| {Frontend App} | {User-facing SPA/SSR} | `src/app/` | {API Server} |
-| {Background Worker} | {Async job processing} | `src/workers/` | {Database, Queue} |
-
-### Data Model
-
-#### {Entity Name} (e.g., User)
-| Field | Type | Constraints | Notes |
-|-------|------|-------------|-------|
-| id | uuid | PK | auto-generated |
-| email | string | unique, not null | login identifier |
-| {field} | {type} | {constraints} | {notes} |
-
-### API Structure
-
-#### {Endpoint Group — e.g., Authentication}
-| Method | Path | Auth | Description |
-|--------|------|------|-------------|
-| POST | /api/auth/register | none | Create new account |
-| POST | /api/auth/login | none | Get session token |
-| GET | /api/auth/me | required | Get current user |
-
-### External Integrations
-
-| Service | Purpose | Auth Method | Notes |
-|---------|---------|-------------|-------|
-| {Stripe} | {Payment processing} | {API key} | {webhook for events} |
-
-### Key Design Decisions
-
-| Decision | Rationale | Alternatives Considered |
-|----------|-----------|------------------------|
-| {Use JWTs for auth} | {Stateless, works with serverless} | {Sessions — rejected due to serverless} |
-
-## Suggested Milestone Sequence
-
-Based on GSD-T's sequencing rules (Foundation → Schema → Core → Features → Polish):
-
-### Milestone 1: Foundation
-**Goal**: {e.g., Project scaffolding, CI/CD, dev environment}
-**Scope**: {list}
-**NOT included**: {list}
-**Success Criteria**:
-- [ ] {criterion}
-
-### Milestone 2: {Core / MVP}
-**Goal**: {outcome}
-**Scope**: {list}
-**NOT included**: {list}
-**Success Criteria**:
-- [ ] {criterion}
-
-### Milestone 3+: {as needed}
-
-## Open Questions
-
-Items that couldn't be resolved during PRD intake — these become inputs to `gsd-t-discuss` during the relevant milestone:
-
-- {question 1} — affects Milestone {N}
-- {question 2}
-
-## Out of Scope (Full Project)
-
-Everything explicitly excluded from the entire project, not just MVP:
-
-- {exclusion 1}
-- {exclusion 2}
-```
-
-## Step 5: Review and Finalize
-
-After generating the PRD, ask the user to review:
-
-"Here's your GSD-T-optimized PRD. Before I save it, a quick check:
-
-1. **Requirements** — I've identified {N} functional requirements (REQ-IDs). Anything missing or wrong?
-2. **Data model** — I've outlined {N} entities. Do the fields and relationships look right?
-3. **Exclusions** — Review the 'NOT included' and 'Out of Scope' lists. Anything misclassified?
-4. **Tech stack** — Any changes?
-5. **Milestone sequence** — Does the sequencing make sense for your delivery goals?"
-
-Iterate until the user approves or says "looks good / save it."
-
-## Step 6: Save and Hand Off
-
-Once approved, save to `docs/prd.md` (create `docs/` directory if it doesn't exist).
-
-Then update `.gsd-t/progress.md` Decision Log:
-```
-- {YYYY-MM-DD}: PRD generated for {product/feature name} — {N} functional requirements, {N} milestones, {N} entities. docs/prd.md created.
+```js
+{
+  scriptPath: "templates/workflows/gsd-t-phase.workflow.js",
+  args: {
+    phase: "prd",
+    projectDir: ".",
+    userInput: "$ARGUMENTS"
+  }
+}
 ```
 
-Output the handoff:
-
-```
-PRD saved to docs/prd.md.
-
-Next steps:
-```
-
-For a new project:
-```
-/gsd-t-project {one-line summary}
-```
-Then paste the PRD when prompted. The PRD's requirements table becomes docs/requirements.md. The architecture section seeds docs/architecture.md. The milestone sequence becomes your roadmap.
-
-For a feature on an existing project:
-```
-/gsd-t-feature {one-line summary}
-```
-Then paste the PRD when prompted.
+## Step 3: Interpret the result
 
-The REQ-IDs in the PRD are the source of truth — GSD-T's plan validation checker verifies every REQ-ID maps to a task. Missing IDs cause plan validation to FAIL.
+The Workflow returns `{ status, artifacts, summary, decisions }`.
 
-## Agent Behavior Rules
+- `status === "complete"`: `docs/prd.md` written, requirements traceable to acceptance criteria.
+- `status === "partial" | "blocked"`: the agent needs clarification on scope or priorities. Surface the questions.
+- `status === "failed"`: read `summary`.
 
-1. **Infer when you can** — if CLAUDE.md says TypeScript/Node + Postgres, state those as assumed in the PRD and skip asking about them
-2. **One question at a time** unless user requests batch mode
-3. **REQ-IDs are non-negotiable** — GSD-T plan validation fails without them
-4. **Exclusions at every level** — MVP level, milestone level, project level. GSD-T partitioning depends on knowing what's OUT
-5. **Data model must be field-level** — "a users table" is not enough. GSD-T schema-contract.md needs field names, types, and constraints
-6. **Components need suggested file paths** — "the API" is not enough. GSD-T partition draws domain boundaries by file ownership
-7. **Keep momentum** — if you have enough for a solid PRD with reasonable assumptions, produce it and let the user refine in Step 5
-8. **Flag risks early** — if choices have known pitfalls, mention as a consideration (e.g., SQLite for multi-user web app), not a blocker
-9. **Never ask what you can read** — check CLAUDE.md, progress.md, and docs/ before asking about tech stack, existing patterns, or current state
-10. **Respect GSD-T context** — if a milestone is already in progress, the PRD should describe a feature addition, not re-define the whole project
+## Document Ripple
 
-$ARGUMENTS
+The PRD agent writes `docs/prd.md` and a Decision Log entry.
 
-## Auto-Clear
+## Next Up
 
-All work is committed to project files. Execute `/clear` to free the context window for the next command.
+`/gsd-t-milestone` — define the first milestone from the PRD. (Or `/gsd-t-project` to decompose a full greenfield build.)

package/commands/gsd-t-quick.md

@@ -475,7 +475,7 @@ const { captureSpawn } = require('./bin/gsd-t-token-capture.cjs');
 2. Re-run Red Team after fixes
 3. If bugs persist, log to `.gsd-t/deferred-items.md` and present to user
 
-**If GRUDGING PASS:** Proceed to doc-ripple.
+**If GRUDGING-PASS:** Proceed to doc-ripple.
 
 ## Step 6: Doc-Ripple (Automated)
 

package/commands/gsd-t-resume.md

@@ -120,39 +120,6 @@ This prevents the child side of a headless spawn from reading a partial continue
 
 ---
 
-## Step 0.3: Orchestrator Run Recovery (M40 D6)
-
-```bash
-node scripts/gsd-t-watch-state.js advance --agent-id "$GSD_T_AGENT_ID" --parent-id "${GSD_T_PARENT_AGENT_ID:-null}" --command gsd-t-resume --step 0 --step-label ".3: Orchestrator Run Recovery (M40 D6)" 2>/dev/null || true
-```
-
-If an orchestrator run was interrupted (crash, SIGINT, kill, parent timeout), `.gsd-t/orchestrator/state.json` will still exist with a non-terminal `status`. Detect this and offer to resume it via the deterministic `--resume` path rather than attempting prose-driven reconciliation:
-
-```bash
-node -e "
-const fs = require('fs');
-const path = require('path');
-const fp = path.join('.gsd-t', 'orchestrator', 'state.json');
-if (!fs.existsSync(fp)) process.exit(0);
-let s; try { s = JSON.parse(fs.readFileSync(fp, 'utf8')); } catch { process.exit(0); }
-const TERMINAL = new Set(['done','failed','stopped','interrupted','completed']);
-if (!s || TERMINAL.has(s.status)) process.exit(0);
-const running = Object.entries(s.tasks || {}).filter(([,t]) => t && t.status === 'running');
-console.error('▶ Orchestrator run still in-flight (status=' + (s.status||'?') + ', ' + running.length + ' running task(s))');
-console.error('  Resume via: node bin/gsd-t-orchestrator.js orchestrate --milestone ' + (s.milestone || '<id>') + ' --resume');
-console.error('  This calls recoverRunState() to reconcile in-flight tasks (ok/ambiguous/failed) before continuing.');
-" || true
-```
-
-Rules:
-- **State absent or terminal** → nothing to do; fall through.
-- **Non-terminal** → surface the recovery hint and, at Level 3, auto-invoke the orchestrator with `--resume` when the current milestone matches `state.milestone`. Ambiguous tasks (commit but no progress entry) are flagged in the orchestrator output and require operator triage — do **not** silently claim them done.
-- The recovery algorithm, archiving, and ambiguous handling are covered by unit tests in `test/m40-recovery.test.js` and implemented in `bin/gsd-t-orchestrator-recover.cjs`.
-
-Contract: stream-json-sink v1.1.0, wave-join v1.x, completion-signal v1.x.
-
----
-
 ## Step 0.5: Headless Read-Back Banner (MANDATORY)
 
 ```bash