@tekyzinc/gsd-t 2.23.0 → 2.24.6

package/commands/gsd-t-complete-milestone.md

@@ -17,7 +17,7 @@ If status is not VERIFIED:
 
 If `--force` flag provided, proceed with warning in archive.
 
-## Step 1.5: Gap Analysis Gate
+## Step 2: Gap Analysis Gate
 
 After verification passes, run a gap analysis against `docs/requirements.md` scoped to this milestone's deliverables:
 
@@ -33,7 +33,7 @@ After verification passes, run a gap analysis against `docs/requirements.md` sco
 
 This is a **mandatory gate** — the milestone cannot be archived with known gaps against its requirements.
 
-## Step 2: Gather Milestone Artifacts
+## Step 3: Gather Milestone Artifacts
 
 Collect all files related to this milestone:
 - `.gsd-t/progress.md` (current state)
@@ -43,7 +43,7 @@ Collect all files related to this milestone:
 - `.gsd-t/domains/*/` (all domain folders)
 - `.gsd-t/contracts/` (snapshot)
 
-## Step 3: Create Archive
+## Step 4: Create Archive
 
 Create milestone archive directory:
 
@@ -60,7 +60,7 @@ Create milestone archive directory:
     └── ...
 ```
 
-## Step 4: Generate Summary
+## Step 5: Generate Summary
 
 Create `summary.md`:
 
@@ -100,7 +100,7 @@ Create `summary.md`:
 {Summary of files created/modified/deleted}
 ```
 
-## Step 5: Bump Version
+## Step 6: Bump Version
 
 GSD-T tracks project version in `.gsd-t/progress.md` using semantic versioning: `Major.Minor.Patch`
 
@@ -119,7 +119,7 @@ Determine the version bump based on the milestone:
 5. Update `README.md` version badge or version reference if present
 6. Include version in the milestone summary and git tag
 
-## Step 6: Clean Working State
+## Step 7: Clean Working State
 
 Reset `.gsd-t/` for next milestone:
 
@@ -146,7 +146,7 @@ None — ready for next milestone
 {Keep the decision log — it's valuable context}
 ```
 
-## Step 7: Update README.md
+## Step 8: Update README.md
 
 If `README.md` exists, update it to reflect the completed milestone:
 - Add or update a **Features** / **What's Included** section with capabilities delivered
@@ -157,7 +157,7 @@ If `README.md` exists, update it to reflect the completed milestone:
 
 If `README.md` doesn't exist, create one with project name, description, version, tech stack, setup instructions, and link to `docs/`.
 
-## Step 7.5: Document Ripple
+## Step 9: Document Ripple
 
 Before creating the git tag, verify all documentation is up to date:
 
@@ -175,7 +175,7 @@ Before creating the git tag, verify all documentation is up to date:
 
 ### This is the LAST GATE before tagging — nothing should be undocumented.
 
-## Step 7.6: Spawn QA Agent and Test Verification
+## Step 10: Spawn QA Agent and Test Verification
 
 Before creating the git tag, spawn the QA teammate for a final test audit:
 
@@ -196,7 +196,7 @@ Then verify the milestone is truly complete:
 4. **Compare to baseline**: If a test baseline was recorded at milestone start, verify coverage has improved or at minimum not regressed
 5. **Log test results**: Include test pass/fail counts in the milestone summary (Step 4)
 
-## Step 8: Create Git Tag
+## Step 11: Create Git Tag
 
 ```bash
 # Stage any remaining .gsd-t changes
@@ -214,7 +214,7 @@ Domains: {list}
 Verified: {date}"
 ```
 
-## Step 9: Report Completion
+## Step 12: Report Completion
 
 ```
 ✅ Milestone "{name}" completed — v{version}
@@ -235,7 +235,7 @@ Next steps:
 - Or view roadmap: /user:gsd-t-status
 ```
 
-## Step 10: Update Roadmap (if exists)
+## Step 13: Update Roadmap (if exists)
 
 If `.gsd-t/roadmap.md` exists:
 - Mark this milestone as complete

package/commands/gsd-t-debug.md

@@ -40,7 +40,7 @@ The contract didn't specify something it should have. Symptoms:
 
 → Update the contract, then fix implementations on both sides.
 
-## Step 2.5: Spawn QA Agent
+## Step 3: Spawn QA Agent
 
 Spawn the QA teammate to handle regression testing:
 
@@ -53,7 +53,7 @@ Teammate "qa": Read commands/gsd-t-qa.md for your full instructions.
 
 QA failure blocks the commit.
 
-## Step 3: Debug (Solo or Team)
+## Step 4: Debug (Solo or Team)
 
 ### Solo Mode
 1. Reproduce the issue
@@ -77,7 +77,7 @@ Create an agent team to debug:
 First to find root cause: message the lead with findings.
 ```
 
-## Step 4: Document Ripple
+## Step 5: Document Ripple
 
 After fixing, assess what documentation was affected by the change and update ALL relevant files:
 
@@ -97,7 +97,7 @@ After fixing, assess what documentation was affected by the change and update AL
 
 ### Skip what's not affected — don't update docs for the sake of updating them.
 
-## Step 5: Test Verification
+## Step 6: Test Verification
 
 Before committing, ensure the fix is solid:
 

package/commands/gsd-t-discuss.md

@@ -97,7 +97,7 @@ Decisions don't just affect contracts — they can change the broader documentat
 
 ### Skip what's not affected.
 
-## Step 5.5: Test Verification
+## Step 6: Test Verification
 
 If decisions resulted in contract or code changes:
 
@@ -105,7 +105,7 @@ If decisions resulted in contract or code changes:
 2. **Verify passing**: All tests must pass. If any fail from contract changes, fix before proceeding (up to 2 attempts)
 3. **Flag test gaps**: If decisions created new requirements with no test coverage, note them for the plan phase
 
-## Step 6: Validate Contracts
+## Step 7: Validate Contracts
 
 After all updates:
 - [ ] All contracts are internally consistent (no conflicting types/shapes)
@@ -113,7 +113,7 @@ After all updates:
 - [ ] Every domain's constraints reflect the decisions made
 - [ ] Integration points are updated with any new dependencies
 
-## Step 7: Report and Stop
+## Step 8: Report and Stop
 
 Present to the user:
 1. Decisions made (with brief rationale)
@@ -123,14 +123,12 @@ Present to the user:
 
 Update `.gsd-t/progress.md` status to `DISCUSSED`.
 
-### If manually invoked:
-**STOP HERE.** Do NOT proceed to the plan phase or any other phase. Present your findings and ask the user:
+### Autonomy Behavior
 
-"Discussion complete. Here's what I found and recommend. Want to proceed with these decisions, revise anything, or explore further?"
+**When manually invoked** (any autonomy level): **STOP HERE.** Do NOT proceed to the plan phase or any other phase. Present your findings and ask the user: "Discussion complete. Here's what I found and recommend. Want to proceed with these decisions, revise anything, or explore further?" This is mandatory — even at Level 3 / bypass permissions. The user invoked discuss to THINK, not to auto-pilot.
 
-This is mandatory — even in bypass permissions / yolo mode. The user invoked discuss to THINK, not to auto-pilot. Respect that.
+**Level 3 (Full Auto) — when auto-invoked by wave**: Work through all open questions automatically, make recommendations, log decisions, and return control to the calling command. Do NOT wait for user input.
 
-### If auto-invoked (by wave):
-The calling command will handle the transition. Just report completion and return control.
+**Level 1–2 — when auto-invoked**: Present decisions and open questions. Wait for user confirmation before returning control to the calling command.
 
 $ARGUMENTS

package/commands/gsd-t-execute.md

@@ -19,7 +19,7 @@ Identify:
 - Which tasks are unblocked (no pending dependencies)
 - Which tasks are blocked (waiting on checkpoints)
 
-## Step 1.5: Spawn QA Agent
+## Step 2: Spawn QA Agent
 
 Spawn the QA teammate to handle testing alongside execution:
 
@@ -32,7 +32,7 @@ Teammate "qa": Read commands/gsd-t-qa.md for your full instructions.
 
 The QA agent runs in parallel — it writes and executes tests while you implement tasks. QA failure on any task blocks proceeding to the next task.
 
-## Step 2: Choose Execution Mode
+## Step 3: Choose Execution Mode
 
 ### Solo Mode (default)
 Execute tasks yourself following the execution order in `integration-points.md`.
@@ -108,7 +108,7 @@ Lead responsibilities:
 - Resolve any contract conflicts immediately
 ```
 
-## Step 3: Checkpoint Handling
+## Step 4: Checkpoint Handling
 
 When a checkpoint is reached (solo or team):
 
@@ -123,7 +123,7 @@ When a checkpoint is reached (solo or team):
 5. **Log** in progress.md: `CHECKPOINT {name}: PASSED/FAILED — {details}`
 6. **Unblock** downstream tasks
 
-## Step 4: Error Handling
+## Step 5: Error Handling
 
 ### Contract Violation
 A teammate implements something that doesn't match a contract:
@@ -147,7 +147,7 @@ A teammate finishes independent tasks and is waiting on a checkpoint:
 2. If not, have the teammate work on documentation, tests, or code cleanup within their domain
 3. Or shut down the teammate and respawn when unblocked
 
-## Step 5: Completion
+## Step 6: Completion
 
 When all tasks in all domains are complete:
 1. Update `.gsd-t/progress.md` — all tasks marked complete

package/commands/gsd-t-feature.md

@@ -206,7 +206,7 @@ After creating the feature roadmap and milestones, update all affected documenta
 
 ### Skip what's not affected.
 
-## Step 7.5: Test Verification
+## Step 8: Test Verification
 
 Before finalizing the feature plan:
 
@@ -214,7 +214,7 @@ Before finalizing the feature plan:
 2. **Verify passing**: If any tests fail, flag them — they must be fixed before or during the first milestone
 3. **Note test gaps**: From the impact analysis, identify which existing tests will need updates and which new tests will be needed — include these in milestone scope
 
-## Step 8: Report to User
+## Step 9: Report to User
 
 Present:
 1. Impact analysis summary (what's new vs. what's modified)

package/commands/gsd-t-impact.md

@@ -178,7 +178,7 @@ If breaking changes require pre-work, add to domain tasks:
 - [ ] IMP-002: {remediation task}
 ```
 
-## Step 6.5: Document Ripple
+## Step 7: Document Ripple
 
 After producing the impact report, update affected documentation:
 
@@ -193,7 +193,7 @@ After producing the impact report, update affected documentation:
 
 ### Skip what's not affected.
 
-## Step 6.6: Test Verification
+## Step 8: Test Verification
 
 Validate the test landscape before recommending proceed/block:
 
@@ -201,7 +201,7 @@ Validate the test landscape before recommending proceed/block:
 2. **Verify passing**: Confirm what passes today — any pre-existing failures should be noted in the impact report
 3. **Map test impact**: For each planned change in Step 2, identify which tests will need updating — include this in the "Test Impact" section of the report
 
-## Step 7: Decision Gate
+## Step 9: Decision Gate
 
 ### If PROCEED:
 "✅ Impact analysis complete. No blocking issues found. Ready for execution."
@@ -237,4 +237,10 @@ When run independently (not as part of wave):
 3. Produce report
 4. Do NOT auto-proceed — just inform
 
+### Autonomy Behavior
+
+**Level 3 (Full Auto)**: If PROCEED or PROCEED WITH CAUTION, log findings and auto-advance to execute phase. If BLOCK, stop and report breaking changes to user — do NOT auto-advance. When run standalone, always report and exit without auto-proceeding.
+
+**Level 1–2**: Present the full impact report. Wait for user confirmation before proceeding (PROCEED) or pause for remediation (BLOCK). For PROCEED WITH CAUTION, ask "These can be addressed during execution. Proceed?"
+
 $ARGUMENTS

package/commands/gsd-t-init.md

@@ -18,7 +18,7 @@ Report current state and ask if user wants to reset or continue.
 Offer to migrate: "Found legacy GSD structure. Want me to migrate to GSD-T?"
 If yes, read `.gsd/` state and create equivalent `.gsd-t/` structure.
 
-## Step 1.5: Copy Local Settings
+## Step 2: Copy Local Settings
 
 If `~/.claude/settings.local` exists and `.claude/settings.local.json` does not exist in the project:
 1. Create the `.claude/` directory in the project root if it doesn't exist
@@ -26,7 +26,7 @@ If `~/.claude/settings.local` exists and `.claude/settings.local.json` does not
 
 Skip silently if the source file doesn't exist or the target already exists.
 
-## Step 2: Create Directory Structure
+## Step 3: Create Directory Structure
 
 ```
 .gsd-t/
@@ -39,7 +39,7 @@ Skip silently if the source file doesn't exist or the target already exists.
 └── progress.md
 ```
 
-## Step 2.5: Initialize Backlog
+## Step 4: Initialize Backlog
 
 Create the backlog files from templates:
 1. Copy `templates/backlog.md` → `.gsd-t/backlog.md`
@@ -54,7 +54,7 @@ Read the project's `CLAUDE.md` (if it exists) to auto-populate backlog settings:
 3. **Default App**: Set `**Default App:**` to the most prominent app found (the one mentioned most, or the first one). If only one app is found, use it.
 4. **If nothing found**: Leave the placeholder values from the template — the user can configure later via `/user:gsd-t-backlog-settings`.
 
-## Step 3: Initialize Progress File
+## Step 5: Initialize Progress File
 
 Create `.gsd-t/progress.md`:
 
@@ -84,7 +84,7 @@ Create `.gsd-t/progress.md`:
 - {date}: Project initialized with GSD-T workflow
 ```
 
-## Step 4: Ensure CLAUDE.md Exists
+## Step 6: Ensure CLAUDE.md Exists
 
 If no `CLAUDE.md`:
 Create a starter template:
@@ -125,7 +125,7 @@ This project uses contract-driven development.
 
 If `CLAUDE.md` exists but doesn't reference GSD-T, append the GSD-T section.
 
-## Step 5: Create docs/ if Needed
+## Step 7: Create docs/ if Needed
 
 If no `docs/` directory, create it with all 4 living document templates.
 For each file, skip if it already exists:
@@ -140,7 +140,7 @@ docs/
 
 These are the living documents that persist across milestones and keep institutional knowledge alive. The `infrastructure.md` is especially important — it captures the exact commands for provisioning cloud resources, setting up databases, managing secrets, and deploying, so this knowledge doesn't get lost between sessions.
 
-## Step 6: Ensure README.md Exists
+## Step 8: Ensure README.md Exists
 
 If no `README.md` exists, create one with:
 - Project name and brief description
@@ -150,7 +150,7 @@ If no `README.md` exists, create one with:
 
 If `README.md` exists, leave it as-is — don't overwrite user content during init.
 
-## Step 7: Map Existing Codebase (if code exists)
+## Step 9: Map Existing Codebase (if code exists)
 
 If there's existing source code:
 1. Scan the codebase structure
@@ -159,7 +159,7 @@ If there's existing source code:
 4. Add findings to CLAUDE.md
 5. Log in progress.md: "Existing codebase analyzed — {summary}"
 
-## Step 7.5: Document Ripple
+## Step 10: Document Ripple
 
 After initialization, verify all created documentation is consistent:
 
@@ -174,7 +174,7 @@ After initialization, verify all created documentation is consistent:
 
 ### Skip what's not affected — init creates docs, so most ripple is about consistency verification.
 
-## Step 7.6: Playwright Setup (MANDATORY)
+## Step 11: Playwright Setup (MANDATORY)
 
 Every GSD-T project must have Playwright ready for E2E testing. If `playwright.config.*` does not exist:
 
@@ -196,7 +196,7 @@ Every GSD-T project must have Playwright ready for E2E testing. If `playwright.c
 
 Skip silently if `playwright.config.*` already exists.
 
-## Step 7.7: Test Verification
+## Step 12: Test Verification
 
 After initialization:
 
@@ -205,7 +205,7 @@ After initialization:
 3. **If greenfield**: Playwright is ready. Note that unit test infrastructure should be added in Milestone 1
 4. **Verify init outputs**: Confirm all created files exist and are non-empty
 
-## Step 8: Report
+## Step 13: Report
 
 Tell the user:
 1. What was created (including backlog files: `.gsd-t/backlog.md` and `.gsd-t/backlog-settings.md`)

package/commands/gsd-t-integrate.md

@@ -88,7 +88,7 @@ Result: PASS
 Result: PARTIAL — needs pagination contract addition
 ```
 
-## Step 4.5: Spawn QA Agent
+## Step 5: Spawn QA Agent
 
 Spawn the QA teammate to verify contract compliance at domain boundaries:
 
@@ -101,7 +101,7 @@ Teammate "qa": Read commands/gsd-t-qa.md for your full instructions.
 
 QA failure blocks integration completion.
 
-## Step 5: Document Ripple
+## Step 6: Document Ripple
 
 Integration is where the real system takes shape. Verify documentation matches reality:
 
@@ -117,7 +117,7 @@ Integration is where the real system takes shape. Verify documentation matches r
 
 ### Skip what's not affected.
 
-## Step 5.5: Test Verification
+## Step 7: Test Verification
 
 After integration and doc ripple, verify everything works together:
 
@@ -127,7 +127,7 @@ After integration and doc ripple, verify everything works together:
 4. **Run E2E tests**: If an E2E framework exists, run the full E2E suite — integration is where end-to-end flows break
 5. **Smoke test results**: Ensure the Step 4 smoke test results are still valid after any fixes
 
-## Step 6: Handle Integration Issues
+## Step 8: Handle Integration Issues
 
 For each issue found:
 1. Determine if it's a contract gap (missing specification) or implementation bug
@@ -135,7 +135,7 @@ For each issue found:
 3. **Implementation bug**: Fix it directly, document the fix
 4. Log everything in progress.md
 
-## Step 7: Update State
+## Step 9: Update State
 
 Update `.gsd-t/progress.md`:
 - Set status to `INTEGRATED`

package/commands/gsd-t-milestone.md

@@ -50,7 +50,7 @@ Before formal partitioning, do a quick assessment:
 
 Present the assessment and ask: "Ready to partition into domains now, or want to discuss first?"
 
-## Step 4.5: Document Ripple
+## Step 5: Document Ripple
 
 After defining the milestone, update affected documentation:
 
@@ -65,7 +65,7 @@ After defining the milestone, update affected documentation:
 
 ### Skip what's not affected.
 
-## Step 4.6: Test Verification
+## Step 6: Test Verification
 
 Before proceeding to partition:
 
@@ -73,7 +73,7 @@ Before proceeding to partition:
 2. **Verify passing**: If any tests fail, flag them as pre-existing — they should be addressed as part of this milestone or logged as tech debt
 3. **Baseline**: Record test state so the milestone has a clear starting point for quality measurement
 
-## Step 5: Auto-Partition (if user confirms)
+## Step 7: Auto-Partition (if user confirms)
 
 If the user wants to proceed immediately, execute the partition workflow (same as gsd-t-partition) for this milestone.
 

package/commands/gsd-t-partition.md

@@ -153,7 +153,7 @@ Write `.gsd-t/progress.md`:
 - {date}: {decision and rationale}
 ```
 
-## Step 4.5: Document Ripple
+## Step 5: Document Ripple
 
 After creating domains and contracts, update affected documentation:
 
@@ -167,7 +167,7 @@ After creating domains and contracts, update affected documentation:
 
 ### Skip what's not affected.
 
-## Step 4.6: Test Verification
+## Step 6: Test Verification
 
 Before finalizing the partition:
 
@@ -175,7 +175,7 @@ Before finalizing the partition:
 2. **Verify passing**: If any tests fail, assign them to the appropriate domain as pre-existing issues
 3. **Map tests to domains**: Note which test files belong to which domain — this informs task planning
 
-## Step 4.7: Spawn QA Agent
+## Step 7: Spawn QA Agent
 
 After contracts are written, spawn the QA teammate to generate contract test skeletons:
 
@@ -188,7 +188,7 @@ Teammate "qa": Read commands/gsd-t-qa.md for your full instructions.
 
 Wait for QA agent to complete before proceeding. QA failure blocks partition completion.
 
-## Step 5: Validate
+## Step 8: Validate
 
 Before finishing, verify:
 - [ ] Every file in `src/` is owned by exactly one domain

package/commands/gsd-t-plan.md

@@ -95,7 +95,7 @@ Add to each domain's `tasks.md`:
 - Estimated checkpoints: {N}
 ```
 
-## Step 4.5: Document Ripple
+## Step 5: Document Ripple
 
 After creating task lists and mapping dependencies, update affected documentation:
 
@@ -110,7 +110,7 @@ After creating task lists and mapping dependencies, update affected documentatio
 
 ### Skip what's not affected.
 
-## Step 4.6: Test Verification
+## Step 6: Test Verification
 
 Before finalizing the plan:
 
@@ -118,7 +118,7 @@ Before finalizing the plan:
 2. **Verify passing**: Document any pre-existing failures — assign them to appropriate domain tasks
 3. **Include test tasks**: Ensure each domain's task list includes test creation/update tasks where acceptance criteria require verification
 
-## Step 4.7: Spawn QA Agent
+## Step 7: Spawn QA Agent
 
 After task lists are created, spawn the QA teammate to generate acceptance test scenarios:
 
@@ -129,16 +129,16 @@ Teammate "qa": Read commands/gsd-t-qa.md for your full instructions.
   Report: number of acceptance test scenarios generated.
 ```
 
-Wait for QA agent to complete before proceeding.
+Wait for QA agent to complete before proceeding. QA failure blocks plan completion.
 
-## Step 5: Update Progress
+## Step 8: Update Progress
 
 Update `.gsd-t/progress.md`:
 - Set status to `PLANNED`
 - Update domain table with task counts
 - Record any planning decisions in the Decision Log
 
-## Step 6: Report
+## Step 9: Report
 
 ### Autonomy Behavior
 

package/commands/gsd-t-project.md

@@ -166,7 +166,7 @@ Initialize or update `.gsd-t/progress.md`:
 
 Ensure `CLAUDE.md` exists and references the roadmap and tech stack.
 
-## Step 5.5: Document Ripple
+## Step 6: Document Ripple
 
 After creating the roadmap and updating project state, verify all documentation is consistent:
 
@@ -183,7 +183,7 @@ After creating the roadmap and updating project state, verify all documentation
 
 ### Skip what's not affected — early project stage means many docs are still minimal.
 
-## Step 5.6: Test Verification
+## Step 7: Test Verification
 
 Before reporting to the user:
 
@@ -191,7 +191,7 @@ Before reporting to the user:
 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 6: Report to User
+## Step 8: Report to User
 
 Present:
 1. The full milestone roadmap (summary view)

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

@@ -77,7 +77,7 @@ In `.gsd-t/progress.md`:
 - Log promotion in Decision Log: "{date}: Promoted {N} tech debt items to Milestone {N}: {name}"
 - Reorder milestones if critical items were inserted
 
-## Step 5.5: Document Ripple
+## Step 6: Document Ripple
 
 After promoting debt items to milestones, update affected documentation:
 
@@ -92,7 +92,7 @@ After promoting debt items to milestones, update affected documentation:
 
 ### Skip what's not affected.
 
-## Step 5.6: Test Verification
+## Step 7: Test Verification
 
 Before reporting:
 
@@ -100,7 +100,7 @@ Before reporting:
 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 6: Report
+## Step 8: Report
 
 Present:
 1. Milestones created (with item list)