@tekyzinc/gsd-t 2.50.12 → 2.53.10

package/commands/gsd-t-project.md

@@ -1,211 +1,211 @@
-# GSD-T: Project — Decompose a Full Project into Milestones
-
-You are the lead agent taking a complete project vision and breaking it into a logical sequence of milestones. Each milestone should be a shippable increment that builds on the last.
-
-## Step 1: Gather Project Context
-
-Read everything available:
-1. `CLAUDE.md` (if exists)
-2. `docs/` — any existing documentation
-3. User's project description from $ARGUMENTS
-4. Any uploaded files (requirements, designs, specs)
-
-If context is thin, ask the user targeted questions:
-- What problem does this solve?
-- Who are the users?
-- What's the tech stack (or preferences)?
-- What's the MVP — the minimum that proves the concept?
-- Are there hard constraints (timeline, budget, existing systems to integrate with)?
-- Any third-party integrations required?
-- Auth requirements (social login, SSO, email/password)?
-- Deployment target (cloud provider, serverless, containers)?
-
-Do NOT proceed until you have enough context to make informed milestone decisions. It's better to ask 3 good questions now than to repartition later.
-
-## Step 2: Identify the Full Scope
-
-List ALL major capabilities the project needs. Group them into functional areas:
-
-```markdown
-## Functional Areas
-
-### Foundation
-- Project scaffolding, tooling, CI/CD pipeline
-- Database schema, migrations, seed data
-- Authentication and authorization
-- Core API structure and middleware
-
-### Core Product
-- {primary feature set — the main thing the product does}
-- {secondary feature set}
-
-### User Experience
-- UI shell, navigation, responsive layout
-- Key user flows
-- Error handling, loading states, empty states
-
-### Integrations
-- Third-party APIs
-- Webhooks, notifications
-- Payment processing (if applicable)
-
-### Operations
-- Deployment pipeline
-- Monitoring, logging, alerting
-- Admin dashboard
-- Analytics and reporting
-
-### Polish
-- Performance optimization
-- Accessibility
-- Security hardening
-- Documentation
-```
-
-Adjust these categories based on the actual project. Not every project needs all of these.
-
-## Step 3: Sequence into Milestones
-
-Break functional areas into milestones following these principles:
-
-### Sequencing Rules:
-1. **Foundation first**: Infrastructure, schema, and auth before features
-2. **Each milestone is shippable**: It works and can be demonstrated, even if incomplete
-3. **Dependencies flow forward**: Milestone N never depends on Milestone N+1
-4. **MVP is early**: The minimum viable product should land by milestone 2-3, not milestone 8
-5. **Risk front-loaded**: Uncertain or complex work goes earlier so you learn faster
-6. **Integration points are milestones**: Don't bury third-party integrations inside feature milestones
-7. **Polish is last**: Performance, accessibility, hardening come after functionality works
-
-### Milestone Size:
-- Each milestone should be 2-5 domains when partitioned
-- Each milestone should be completable in roughly 1-3 focused sessions
-- If a milestone feels too big, split it. Too small, merge it.
-
-## Step 4: Write the Milestone Roadmap
-
-Create `.gsd-t/roadmap.md`:
-
-```markdown
-# Project Roadmap: {project name}
-
-## Vision
-{1-2 sentence project vision}
-
-## Target Users
-{who this is for}
-
-## Tech Stack
-{languages, frameworks, services, deployment}
-
----
-
-## Milestone 1: {name} — Foundation
-**Goal**: {what "done" looks like}
-**Scope**:
-- {capability 1}
-- {capability 2}
-- {capability 3}
-**NOT included**: {explicit exclusions}
-**Success criteria**:
-- [ ] {testable outcome}
-- [ ] {testable outcome}
-- [ ] {testable outcome}
-**Estimated domains**: {2-4 domain names}
-**Dependencies**: None (first milestone)
-
----
-
-## Milestone 2: {name} — Core Feature
-**Goal**: {what "done" looks like}
-**Scope**:
-- {capability 1}
-- {capability 2}
-**NOT included**: {explicit exclusions}
-**Success criteria**:
-- [ ] {testable outcome}
-- [ ] {testable outcome}
-**Estimated domains**: {2-4 domain names}
-**Dependencies**: Milestone 1 (foundation, auth, schema)
-
----
-
-## Milestone 3: {name} — {next logical increment}
-...
-
----
-
-## Future / Out of Scope
-- {things explicitly deferred}
-- {nice-to-haves not in current plan}
-```
-
-## Step 5: Update Project State
-
-Initialize or update `.gsd-t/progress.md`:
-
-```markdown
-# GSD-T Progress
-
-## Project: {name}
-## Status: ROADMAPPED
-## Date: {today}
-
-## Milestones
-| # | Milestone | Status | Domains | Est. Sessions |
-|---|-----------|--------|---------|---------------|
-| 1 | {name} | not started | TBD | {1-3} |
-| 2 | {name} | not started | TBD | {1-3} |
-| 3 | {name} | not started | TBD | {1-3} |
-
-## Decision Log
-- {date}: Project roadmap created with {N} milestones
-- {date}: Tech stack decision — {rationale}
-- {date}: MVP scope decision — {rationale}
-```
-
-Ensure `CLAUDE.md` exists and references the roadmap and tech stack.
-
-## Step 6: Document Ripple
-
-After creating the roadmap and updating project state, verify all documentation is consistent:
-
-### Always update:
-1. **`.gsd-t/progress.md`** — Already updated in Step 5, verify Decision Log includes project creation rationale and tech stack decisions
-
-### Check if affected:
-2. **`docs/requirements.md`** — If the project scope implies specific functional or technical requirements, add them now
-3. **`docs/architecture.md`** — If tech stack and architecture decisions were made, document them
-4. **`docs/workflows.md`** — If key user workflows are known from the project vision, outline them
-5. **`docs/infrastructure.md`** — If deployment targets and dev setup are known, document them
-6. **`CLAUDE.md`** — Ensure it references the roadmap, tech stack, and any conventions decided during project planning
-7. **`README.md`** — If created or exists, verify it reflects the project overview and tech stack
-
-### Skip what's not affected — early project stage means many docs are still minimal.
-
-## Step 7: Test Verification
-
-Before reporting to the user:
-
-1. **If existing code**: Run the full test suite to establish a baseline before milestone work begins
-2. **If greenfield**: Note that test infrastructure should be established in Milestone 1
-3. **Document baseline**: Record the test state so progress can be measured across milestones
-
-## Step 8: Report to User
-
-Present:
-1. The full milestone roadmap (summary view)
-2. Total milestone count and rough estimate
-3. Which milestone is the MVP
-4. Any scope decisions you made and why
-5. Questions or trade-offs that need user input
-
-Ask: "Ready to start Milestone 1? Run `/user:gsd-t-partition` to decompose it into domains."
-
-Or if the user wants to review first: "Review the roadmap in `.gsd-t/roadmap.md` and let me know if you want to adjust scope or ordering."
-
-$ARGUMENTS
-
-## Auto-Clear
-
-All work is committed to project files. Execute `/clear` to free the context window for the next command.
+# GSD-T: Project — Decompose a Full Project into Milestones
+
+You are the lead agent taking a complete project vision and breaking it into a logical sequence of milestones. Each milestone should be a shippable increment that builds on the last.
+
+## Step 1: Gather Project Context
+
+Read everything available:
+1. `CLAUDE.md` (if exists)
+2. `docs/` — any existing documentation
+3. User's project description from $ARGUMENTS
+4. Any uploaded files (requirements, designs, specs)
+
+If context is thin, ask the user targeted questions:
+- What problem does this solve?
+- Who are the users?
+- What's the tech stack (or preferences)?
+- What's the MVP — the minimum that proves the concept?
+- Are there hard constraints (timeline, budget, existing systems to integrate with)?
+- Any third-party integrations required?
+- Auth requirements (social login, SSO, email/password)?
+- Deployment target (cloud provider, serverless, containers)?
+
+Do NOT proceed until you have enough context to make informed milestone decisions. It's better to ask 3 good questions now than to repartition later.
+
+## Step 2: Identify the Full Scope
+
+List ALL major capabilities the project needs. Group them into functional areas:
+
+```markdown
+## Functional Areas
+
+### Foundation
+- Project scaffolding, tooling, CI/CD pipeline
+- Database schema, migrations, seed data
+- Authentication and authorization
+- Core API structure and middleware
+
+### Core Product
+- {primary feature set — the main thing the product does}
+- {secondary feature set}
+
+### User Experience
+- UI shell, navigation, responsive layout
+- Key user flows
+- Error handling, loading states, empty states
+
+### Integrations
+- Third-party APIs
+- Webhooks, notifications
+- Payment processing (if applicable)
+
+### Operations
+- Deployment pipeline
+- Monitoring, logging, alerting
+- Admin dashboard
+- Analytics and reporting
+
+### Polish
+- Performance optimization
+- Accessibility
+- Security hardening
+- Documentation
+```
+
+Adjust these categories based on the actual project. Not every project needs all of these.
+
+## Step 3: Sequence into Milestones
+
+Break functional areas into milestones following these principles:
+
+### Sequencing Rules:
+1. **Foundation first**: Infrastructure, schema, and auth before features
+2. **Each milestone is shippable**: It works and can be demonstrated, even if incomplete
+3. **Dependencies flow forward**: Milestone N never depends on Milestone N+1
+4. **MVP is early**: The minimum viable product should land by milestone 2-3, not milestone 8
+5. **Risk front-loaded**: Uncertain or complex work goes earlier so you learn faster
+6. **Integration points are milestones**: Don't bury third-party integrations inside feature milestones
+7. **Polish is last**: Performance, accessibility, hardening come after functionality works
+
+### Milestone Size:
+- Each milestone should be 2-5 domains when partitioned
+- Each milestone should be completable in roughly 1-3 focused sessions
+- If a milestone feels too big, split it. Too small, merge it.
+
+## Step 4: Write the Milestone Roadmap
+
+Create `.gsd-t/roadmap.md`:
+
+```markdown
+# Project Roadmap: {project name}
+
+## Vision
+{1-2 sentence project vision}
+
+## Target Users
+{who this is for}
+
+## Tech Stack
+{languages, frameworks, services, deployment}
+
+---
+
+## Milestone 1: {name} — Foundation
+**Goal**: {what "done" looks like}
+**Scope**:
+- {capability 1}
+- {capability 2}
+- {capability 3}
+**NOT included**: {explicit exclusions}
+**Success criteria**:
+- [ ] {testable outcome}
+- [ ] {testable outcome}
+- [ ] {testable outcome}
+**Estimated domains**: {2-4 domain names}
+**Dependencies**: None (first milestone)
+
+---
+
+## Milestone 2: {name} — Core Feature
+**Goal**: {what "done" looks like}
+**Scope**:
+- {capability 1}
+- {capability 2}
+**NOT included**: {explicit exclusions}
+**Success criteria**:
+- [ ] {testable outcome}
+- [ ] {testable outcome}
+**Estimated domains**: {2-4 domain names}
+**Dependencies**: Milestone 1 (foundation, auth, schema)
+
+---
+
+## Milestone 3: {name} — {next logical increment}
+...
+
+---
+
+## Future / Out of Scope
+- {things explicitly deferred}
+- {nice-to-haves not in current plan}
+```
+
+## Step 5: Update Project State
+
+Initialize or update `.gsd-t/progress.md`:
+
+```markdown
+# GSD-T Progress
+
+## Project: {name}
+## Status: ROADMAPPED
+## Date: {today}
+
+## Milestones
+| # | Milestone | Status | Domains | Est. Sessions |
+|---|-----------|--------|---------|---------------|
+| 1 | {name} | not started | TBD | {1-3} |
+| 2 | {name} | not started | TBD | {1-3} |
+| 3 | {name} | not started | TBD | {1-3} |
+
+## Decision Log
+- {date}: Project roadmap created with {N} milestones
+- {date}: Tech stack decision — {rationale}
+- {date}: MVP scope decision — {rationale}
+```
+
+Ensure `CLAUDE.md` exists and references the roadmap and tech stack.
+
+## Step 6: Document Ripple
+
+After creating the roadmap and updating project state, verify all documentation is consistent:
+
+### Always update:
+1. **`.gsd-t/progress.md`** — Already updated in Step 5, verify Decision Log includes project creation rationale and tech stack decisions
+
+### Check if affected:
+2. **`docs/requirements.md`** — If the project scope implies specific functional or technical requirements, add them now
+3. **`docs/architecture.md`** — If tech stack and architecture decisions were made, document them
+4. **`docs/workflows.md`** — If key user workflows are known from the project vision, outline them
+5. **`docs/infrastructure.md`** — If deployment targets and dev setup are known, document them
+6. **`CLAUDE.md`** — Ensure it references the roadmap, tech stack, and any conventions decided during project planning
+7. **`README.md`** — If created or exists, verify it reflects the project overview and tech stack
+
+### Skip what's not affected — early project stage means many docs are still minimal.
+
+## Step 7: Test Verification
+
+Before reporting to the user:
+
+1. **If existing code**: Run the full test suite to establish a baseline before milestone work begins
+2. **If greenfield**: Note that test infrastructure should be established in Milestone 1
+3. **Document baseline**: Record the test state so progress can be measured across milestones
+
+## Step 8: Report to User
+
+Present:
+1. The full milestone roadmap (summary view)
+2. Total milestone count and rough estimate
+3. Which milestone is the MVP
+4. Any scope decisions you made and why
+5. Questions or trade-offs that need user input
+
+Ask: "Ready to start Milestone 1? Run `/user:gsd-t-partition` to decompose it into domains."
+
+Or if the user wants to review first: "Review the roadmap in `.gsd-t/roadmap.md` and let me know if you want to adjust scope or ordering."
+
+$ARGUMENTS
+
+## Auto-Clear
+
+All work is committed to project files. Execute `/clear` to free the context window for the next command.

package/commands/gsd-t-promote-debt.md

@@ -1,123 +1,123 @@
-# GSD-T: Promote Debt — Convert Tech Debt Items to Milestones
-
-You are converting selected tech debt items into formal milestones on the project roadmap.
-
-## Step 1: Load Context
-
-Read:
-1. `.gsd-t/techdebt.md` — the debt register
-2. `.gsd-t/roadmap.md` — current milestone plan
-3. `.gsd-t/progress.md` — what's in progress
-
-## Step 1.5: Graph-Enhanced Impact Radius
-
-If `.gsd-t/graph/meta.json` exists (graph index is available):
-1. For each debt item, query `getCallers` on the affected entity to calculate impact radius — items with more callers have higher blast radius and may warrant higher priority
-2. Include caller counts in the promotable items display to help the user prioritize
-
-If graph is not available, skip this step.
-
-## Step 2: Identify Items to Promote
-
-From $ARGUMENTS, determine which items to promote:
-- Specific IDs: "TD-001, TD-003" → promote those exact items
-- Category: "security" → promote all security items marked as milestone candidates
-- Severity: "critical" → promote all critical items
-- Suggested group: "Security Hardening" → use the suggested grouping from the scan
-- "all" → promote all items marked `Milestone candidate: YES`
-
-If $ARGUMENTS is empty or vague, show the user all promotable items:
-```
-Promotable tech debt items:
-
-  TD-001: [CRITICAL] SQL injection in user search — effort: small
-  TD-003: [CRITICAL] Hardcoded API key in config — effort: small  
-  TD-010: [HIGH] N+1 queries on dashboard — effort: medium
-  TD-012: [HIGH] No rate limiting on auth endpoints — effort: small
-
-Suggested groupings:
-  1. "Security Hardening" — TD-001, TD-003, TD-012
-  2. "Performance" — TD-010
-
-Which items or groups should I promote to milestones?
-```
-
-## Step 3: Create Milestones
-
-For each group of promoted items, create a milestone entry.
-
-Determine placement in the roadmap:
-- **CRITICAL items**: Insert BEFORE the next unstarted feature milestone
-- **HIGH items**: Insert AFTER current in-progress milestone
-- **MEDIUM/LOW items**: Append to end of roadmap
-
-Append to `.gsd-t/roadmap.md`:
-
-```markdown
----
-
-## Milestone {N}: {name} — Tech Debt
-**Source**: Promoted from tech debt scan ({date})
-**Items**: {TD-001, TD-003, TD-012}
-**Goal**: {what "done" looks like}
-**Scope**:
-- {remediation 1 from techdebt.md}
-- {remediation 2 from techdebt.md}
-**Success criteria**:
-- [ ] {each debt item resolved and verified}
-- [ ] No regression in existing functionality
-- [ ] {item-specific criteria from techdebt.md}
-**Estimated effort**: {combined effort assessment}
-**Priority**: {CRITICAL — before next feature | HIGH — soon | MEDIUM — planned}
-```
-
-## Step 4: Update Tech Debt Register
-
-In `.gsd-t/techdebt.md`, mark promoted items:
-```markdown
-- **Promoted**: [x] — Milestone {N}: {milestone name}
-```
-
-## Step 5: Update Progress
-
-In `.gsd-t/progress.md`:
-- Add new milestones to the table
-- Log promotion in Decision Log: "{date}: Promoted {N} tech debt items to Milestone {N}: {name}"
-- Reorder milestones if critical items were inserted
-
-## Step 6: Document Ripple
-
-After promoting debt items to milestones, update affected documentation:
-
-### Always update:
-1. **`.gsd-t/progress.md`** — Already updated in Step 5, verify Decision Log includes promotion rationale
-
-### Check if affected:
-2. **`docs/requirements.md`** — If promoted debt items imply new or changed requirements (e.g., security requirements from a security hardening milestone), add them
-3. **`docs/architecture.md`** — If promoted debt involves architectural changes, note planned modifications
-4. **`CLAUDE.md`** — If promotion changes the project's priority order or introduces new constraints, add them
-5. **`README.md`** — If the roadmap change affects what's documented in README (e.g., known issues section), update it
-
-### Skip what's not affected.
-
-## Step 7: Test Verification
-
-Before reporting:
-
-1. **Run existing tests**: Execute the full test suite to confirm current state — promoted debt milestones should not change code yet
-2. **Verify passing**: Document any pre-existing failures that relate to the promoted debt items — these validate the promotion was warranted
-3. **Note test requirements**: For each promoted milestone, note what tests will need to be added or updated during execution
-
-## Step 8: Report
-
-Present:
-1. Milestones created (with item list)
-2. Updated roadmap order
-3. Any impact on in-progress work
-4. Recommended next action
-
-$ARGUMENTS
-
-## Auto-Clear
-
-All work is committed to project files. Execute `/clear` to free the context window for the next command.
+# GSD-T: Promote Debt — Convert Tech Debt Items to Milestones
+
+You are converting selected tech debt items into formal milestones on the project roadmap.
+
+## Step 1: Load Context
+
+Read:
+1. `.gsd-t/techdebt.md` — the debt register
+2. `.gsd-t/roadmap.md` — current milestone plan
+3. `.gsd-t/progress.md` — what's in progress
+
+## Step 1.5: Graph-Enhanced Impact Radius
+
+If `.gsd-t/graph/meta.json` exists (graph index is available):
+1. For each debt item, query `getCallers` on the affected entity to calculate impact radius — items with more callers have higher blast radius and may warrant higher priority
+2. Include caller counts in the promotable items display to help the user prioritize
+
+If graph is not available, skip this step.
+
+## Step 2: Identify Items to Promote
+
+From $ARGUMENTS, determine which items to promote:
+- Specific IDs: "TD-001, TD-003" → promote those exact items
+- Category: "security" → promote all security items marked as milestone candidates
+- Severity: "critical" → promote all critical items
+- Suggested group: "Security Hardening" → use the suggested grouping from the scan
+- "all" → promote all items marked `Milestone candidate: YES`
+
+If $ARGUMENTS is empty or vague, show the user all promotable items:
+```
+Promotable tech debt items:
+
+  TD-001: [CRITICAL] SQL injection in user search — effort: small
+  TD-003: [CRITICAL] Hardcoded API key in config — effort: small  
+  TD-010: [HIGH] N+1 queries on dashboard — effort: medium
+  TD-012: [HIGH] No rate limiting on auth endpoints — effort: small
+
+Suggested groupings:
+  1. "Security Hardening" — TD-001, TD-003, TD-012
+  2. "Performance" — TD-010
+
+Which items or groups should I promote to milestones?
+```
+
+## Step 3: Create Milestones
+
+For each group of promoted items, create a milestone entry.
+
+Determine placement in the roadmap:
+- **CRITICAL items**: Insert BEFORE the next unstarted feature milestone
+- **HIGH items**: Insert AFTER current in-progress milestone
+- **MEDIUM/LOW items**: Append to end of roadmap
+
+Append to `.gsd-t/roadmap.md`:
+
+```markdown
+---
+
+## Milestone {N}: {name} — Tech Debt
+**Source**: Promoted from tech debt scan ({date})
+**Items**: {TD-001, TD-003, TD-012}
+**Goal**: {what "done" looks like}
+**Scope**:
+- {remediation 1 from techdebt.md}
+- {remediation 2 from techdebt.md}
+**Success criteria**:
+- [ ] {each debt item resolved and verified}
+- [ ] No regression in existing functionality
+- [ ] {item-specific criteria from techdebt.md}
+**Estimated effort**: {combined effort assessment}
+**Priority**: {CRITICAL — before next feature | HIGH — soon | MEDIUM — planned}
+```
+
+## Step 4: Update Tech Debt Register
+
+In `.gsd-t/techdebt.md`, mark promoted items:
+```markdown
+- **Promoted**: [x] — Milestone {N}: {milestone name}
+```
+
+## Step 5: Update Progress
+
+In `.gsd-t/progress.md`:
+- Add new milestones to the table
+- Log promotion in Decision Log: "{date}: Promoted {N} tech debt items to Milestone {N}: {name}"
+- Reorder milestones if critical items were inserted
+
+## Step 6: Document Ripple
+
+After promoting debt items to milestones, update affected documentation:
+
+### Always update:
+1. **`.gsd-t/progress.md`** — Already updated in Step 5, verify Decision Log includes promotion rationale
+
+### Check if affected:
+2. **`docs/requirements.md`** — If promoted debt items imply new or changed requirements (e.g., security requirements from a security hardening milestone), add them
+3. **`docs/architecture.md`** — If promoted debt involves architectural changes, note planned modifications
+4. **`CLAUDE.md`** — If promotion changes the project's priority order or introduces new constraints, add them
+5. **`README.md`** — If the roadmap change affects what's documented in README (e.g., known issues section), update it
+
+### Skip what's not affected.
+
+## Step 7: Test Verification
+
+Before reporting:
+
+1. **Run existing tests**: Execute the full test suite to confirm current state — promoted debt milestones should not change code yet
+2. **Verify passing**: Document any pre-existing failures that relate to the promoted debt items — these validate the promotion was warranted
+3. **Note test requirements**: For each promoted milestone, note what tests will need to be added or updated during execution
+
+## Step 8: Report
+
+Present:
+1. Milestones created (with item list)
+2. Updated roadmap order
+3. Any impact on in-progress work
+4. Recommended next action
+
+$ARGUMENTS
+
+## Auto-Clear
+
+All work is committed to project files. Execute `/clear` to free the context window for the next command.