@tekyzinc/gsd-t 2.24.8 → 2.28.12

package/commands/gsd-t-init.md

@@ -20,11 +20,31 @@ If yes, read `.gsd/` state and create equivalent `.gsd-t/` structure.
 
 ## 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
-2. Copy `~/.claude/settings.local` → `.claude/settings.local.json`
-
-Skip silently if the source file doesn't exist or the target already exists.
+1. **Ensure `~/.claude/settings.local` exists**:
+   - If it does NOT exist, create it now with these default permissions:
+     ```json
+     {
+       "permissions": {
+         "allow": [
+           "Edit",
+           "Write",
+           "Bash",
+           "Read",
+           "WebSearch",
+           "WebFetch",
+           "Skill"
+         ]
+       },
+       "outputStyle": "default"
+     }
+     ```
+     After creating it, log: "Created ~/.claude/settings.local with default permissions — update the allow list to match your security preferences."
+
+2. **Copy to project**: If `.claude/settings.local.json` does NOT already exist in the project root:
+   - Create the `.claude/` directory in the project root if it doesn't exist
+   - Copy `~/.claude/settings.local` → `.claude/settings.local.json`
+
+Skip the copy (step 2) silently if the target already exists.
 
 ## Step 3: Create Directory Structure
 
@@ -36,7 +56,21 @@ Skip silently if the source file doesn't exist or the target already exists.
 │   └── .gitkeep
 ├── backlog.md
 ├── backlog-settings.md
-└── progress.md
+├── progress.md
+├── token-log.md
+└── qa-issues.md
+```
+
+Create `token-log.md` with header row:
+```
+| Date | Command | Step | Model | Duration(s) | Notes |
+|------|---------|------|-------|-------------|-------|
+```
+
+Create `qa-issues.md` with header row:
+```
+| Date | Command | Step | Model | Duration(s) | Severity | Finding |
+|------|---------|------|-------|-------------|----------|---------|
 ```
 
 ## Step 4: Initialize Backlog

package/commands/gsd-t-integrate.md

@@ -88,17 +88,26 @@ Result: PASS
 Result: PARTIAL — needs pagination contract addition
 ```
 
-## Step 5: Spawn QA Agent
+## Step 5: Contract Compliance Testing
 
-Spawn the QA teammate to verify contract compliance at domain boundaries:
+Spawn a QA subagent via the Task tool to verify contract compliance at all domain boundaries:
 
 ```
-Teammate "qa": Read commands/gsd-t-qa.md for your full instructions.
-  Phase context: integrate. Read .gsd-t/contracts/ for all contract definitions.
-  Run contract compliance tests at every domain boundary.
-  Report: boundary-by-boundary test results.
+Task subagent (general-purpose, model: haiku):
+"Run contract compliance tests for this integration. Read .gsd-t/contracts/ for all contract definitions.
+Test every domain boundary: verify that producers and consumers match their contract shapes.
+Run the full test suite.
+Report: boundary-by-boundary test results with pass/fail counts."
 ```
 
+**OBSERVABILITY LOGGING (MANDATORY):**
+Before spawning: run `date +%s` via Bash → save as START
+After subagent returns: run `date +%s` → compute `DURATION=$((END-START))`
+Append to `.gsd-t/token-log.md` (create with header `| Date | Command | Step | Model | Duration(s) | Notes |` if missing):
+`| {YYYY-MM-DD HH:MM} | gsd-t-integrate | Step 5 | haiku | {DURATION}s | {pass/fail}, {N} boundaries tested |`
+If QA found issues, append each to `.gsd-t/qa-issues.md` (create with header `| Date | Command | Step | Model | Duration(s) | Severity | Finding |` if missing):
+`| {YYYY-MM-DD HH:MM} | gsd-t-integrate | Step 5 | haiku | {DURATION}s | {severity} | {finding} |`
+
 QA failure blocks integration completion.
 
 ## Step 6: Document Ripple

package/commands/gsd-t-partition.md

@@ -175,20 +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 7: Spawn QA Agent
-
-After contracts are written, spawn the QA teammate to generate contract test skeletons:
-
-```
-Teammate "qa": Read commands/gsd-t-qa.md for your full instructions.
-  Phase context: partition. Read .gsd-t/contracts/ for contract definitions.
-  Generate contract test skeleton files for every contract.
-  Report: number of test files generated and total test cases.
-```
-
-Wait for QA agent to complete before proceeding. QA failure blocks partition completion.
-
-## Step 8: Validate
+## Step 7: Validate
 
 Before finishing, verify:
 - [ ] Every file in `src/` is owned by exactly one domain

package/commands/gsd-t-pause.md

@@ -0,0 +1,78 @@
+# GSD-T: Pause — Save Exact Position for Later Resume
+
+You are capturing the precise current position in an active GSD-T phase so the user can resume later with zero re-orientation overhead.
+
+## Step 1: Gather Current State
+
+Read the following (use whatever is already in context first — only read files if needed):
+
+1. `.gsd-t/progress.md` — milestone name, current status/phase, version
+2. `.gsd-t/domains/*/tasks.md` — identify which tasks are done, in-progress, or pending
+3. Last entry in the Decision Log (from progress.md)
+4. `$ARGUMENTS` — if user provided a note, capture it verbatim
+
+## Step 2: Determine Exact Position
+
+Identify:
+- **Milestone**: current milestone name
+- **Phase**: current phase (PARTITIONED, PLANNED, EXECUTED, etc.)
+- **Domain** (if in execute/test-sync): which domain was being worked on
+- **Task** (if in execute): which task number was in progress or next up
+- **Last completed action**: what was the last thing that finished
+- **Next action**: what should happen first when resuming
+- **Blockers**: any known blockers or open questions
+
+## Step 3: Create Continue-Here File
+
+Generate a timestamp: `{YYYY}-{MM}-{DD}T{HH}{MM}{SS}` (local time, no separators in time part).
+
+Create `.gsd-t/continue-here-{timestamp}.md`:
+
+```markdown
+# Continue Here — {YYYY-MM-DD HH:MM}
+
+## Snapshot
+- **Milestone**: {milestone name}
+- **Phase**: {phase}
+- **Version**: {version from progress.md}
+- **Paused at**: {domain} → Task {N} | Between phases | {other description}
+
+## Last Completed
+{description of the last thing that finished — specific task, commit, or action}
+
+## Next Action
+{exactly what to do first when resuming — specific, actionable}
+
+## Open Items
+{any known blockers, pending decisions, or things to watch out for}
+{None if clean}
+
+## User Note
+{$ARGUMENTS if provided, otherwise: _No note provided._}
+
+## Resume Command
+/user:gsd-t-resume
+```
+
+## Step 4: Confirm to User
+
+Output:
+
+```
+⏸ Paused: {milestone name} — {phase}
+
+Saved position: .gsd-t/continue-here-{timestamp}.md
+Next action:    {next action summary}
+
+To resume: /user:gsd-t-resume
+```
+
+## Step 5: Do NOT Stop Work (unless user asked to pause all work)
+
+This command only saves position. If the user invoked /pause mid-task intending to stop:
+- They will close the session themselves
+- Do not auto-continue executing tasks after creating the file
+
+If invoked with $ARGUMENTS containing "and continue" or similar, create the file and then continue the current task normally.
+
+$ARGUMENTS

package/commands/gsd-t-plan.md

@@ -12,6 +12,9 @@ Read ALL of these:
 5. `.gsd-t/domains/*/constraints.md` — every domain constraint
 6. `docs/` — requirements, architecture, schema, design
 7. Existing source code (if any) — understand current state
+8. `.gsd-t/CONTEXT.md` (if exists — from discuss phase) — **MANDATORY READ if present**
+
+**If CONTEXT.md exists:** Every Locked Decision listed in it MUST be mapped to at least one task in Step 2. Do NOT proceed to execute if any Locked Decision is unmapped.
 
 ## Step 2: Create Task Lists Per Domain
 
@@ -49,9 +52,25 @@ For each domain, write `.gsd-t/domains/{domain-name}/tasks.md`:
 5. **Ordered**: Tasks within a domain are numbered in execution order
 6. **No implicit knowledge**: Don't assume the executing agent remembers previous tasks — reference contracts and files explicitly
 
+### REQ Traceability
+
+After creating task lists, append a traceability table to `docs/requirements.md`:
+
+```markdown
+## Requirements Traceability (updated by plan phase)
+| REQ-ID | Requirement Summary | Domain | Task(s) | Status |
+|--------|---------------------|--------|---------|--------|
+| REQ-001 | {summary} | {domain} | Task 1, Task 3 | pending |
+| REQ-002 | {summary} | {domain} | Task 2 | pending |
+```
+
+- Every REQ-ID must map to at least one domain/task — orphaned requirements are a planning gap
+- Every task group should trace back to at least one REQ-ID — tasks with no REQ reference may be scope creep
+- Report: orphaned requirements (no task) and unanchored tasks (no REQ)
+
 ## Step 3: Map Cross-Domain Dependencies
 
-Update `.gsd-t/contracts/integration-points.md` with the full dependency graph:
+Update `.gsd-t/contracts/integration-points.md` with the full dependency graph **and wave groupings**:
 
 ```markdown
 # Integration Points
@@ -68,11 +87,37 @@ Update `.gsd-t/contracts/integration-points.md` with the full dependency graph:
 - UNLOCKS: auth Task 3 (user lookup), ui Task 3 (data fetching)
 - VERIFY: Lead confirms schema matches schema-contract.md
 
-### Second Checkpoint  
+### Second Checkpoint
 - GATE: auth Task 4 (auth middleware) must complete
 - UNLOCKS: ui Task 5 (protected routes)
 - VERIFY: Lead confirms auth endpoints match api-contract.md
 
+## Wave Execution Groups
+
+Waves allow parallel execution within a wave and sequential execution between waves.
+Each wave contains domains/tasks that can safely run in parallel (no shared files, no cross-domain dependencies within the wave).
+
+### Wave 1 — Independent (parallel)
+- data-layer: Tasks 1-3
+- auth: Tasks 1-2
+- **Shared files**: NONE — safe to run in parallel
+- **Completes when**: All listed tasks done
+
+### Wave 2 — After Wave 1 Checkpoint (parallel)
+- CHECKPOINT: Lead verifies schema-contract.md before Wave 2 starts
+- auth: Tasks 3-4
+- ui: Tasks 1-2
+- **Shared files**: NONE — safe to run in parallel
+- **Completes when**: All listed tasks done
+
+### Wave 3 — After Wave 2 Checkpoint (sequential)
+- CHECKPOINT: Lead verifies api-contract.md before Wave 3 starts
+- ui: Tasks 3-5
+- **Note**: Sequential — each task depends on the previous
+
+### Integration
+- INTEGRATION: Wire all domains together
+
 ## Execution Order (for solo mode)
 1. data-layer Tasks 1-3
 2. auth Tasks 1-2 (parallel-safe with data-layer)
@@ -84,6 +129,12 @@ Update `.gsd-t/contracts/integration-points.md` with the full dependency graph:
 8. INTEGRATION: wire everything together
 ```
 
+### Wave Grouping Rules:
+1. **Same wave** = no shared files, no dependency between them
+2. **Different wave** = one depends on the other's output, OR they modify the same file
+3. **CHECKPOINT between waves** = lead verifies contract compliance before unlocking next wave
+4. Always check domain `scope.md` files for file ownership — overlapping files → different waves
+
 ## Step 4: Estimate Scope
 
 Add to each domain's `tasks.md`:
@@ -118,18 +169,37 @@ 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 7: Spawn QA Agent
+## Step 7: Plan Validation
 
-After task lists are created, spawn the QA teammate to generate acceptance test scenarios:
+Spawn a Task subagent to validate the plan before proceeding:
 
 ```
-Teammate "qa": Read commands/gsd-t-qa.md for your full instructions.
-  Phase context: plan. Read .gsd-t/domains/*/tasks.md for task lists.
-  Generate acceptance test scenarios for tasks with user-facing deliverables.
-  Report: number of acceptance test scenarios generated.
+Task subagent (general-purpose, model: haiku):
+"Validate this GSD-T plan. Read:
+- .gsd-t/domains/*/tasks.md (all task lists)
+- .gsd-t/contracts/ (all contracts)
+- docs/requirements.md (including traceability table)
+- .gsd-t/CONTEXT.md (if exists)
+
+Check:
+1. REQ coverage: every REQ-ID in requirements.md maps to at least one task
+2. Locked Decisions (from CONTEXT.md if present): every Locked Decision maps to at least one task
+3. Task completeness: every task has files, contract refs, and acceptance criteria
+4. Cross-domain dependencies: all BLOCKED-BY references point to real tasks
+5. Contract existence: every task referencing a contract has that contract file present
+
+Report: PASS (all checks pass) or FAIL with specific gaps listed."
 ```
 
-Wait for QA agent to complete before proceeding. QA failure blocks plan completion.
+**OBSERVABILITY LOGGING (MANDATORY):**
+Before spawning: run `date +%s` via Bash → save as START
+After subagent returns: run `date +%s` → compute `DURATION=$((END-START))`
+Append to `.gsd-t/token-log.md` (create with header `| Date | Command | Step | Model | Duration(s) | Notes |` if missing):
+`| {YYYY-MM-DD HH:MM} | gsd-t-plan | Step 7 | haiku | {DURATION}s | {PASS/FAIL}, iteration {N} |`
+If validation FAIL, append each gap to `.gsd-t/qa-issues.md` (create with header `| Date | Command | Step | Model | Duration(s) | Severity | Finding |` if missing):
+`| {YYYY-MM-DD HH:MM} | gsd-t-plan | Step 7 | haiku | {DURATION}s | medium | {gap description} |`
+
+**If FAIL**: Fix the identified gaps (up to 3 iterations). If still failing after 3 iterations, STOP and report to user with the specific gaps. Plan cannot proceed until validation PASSES.
 
 ## Step 8: Update Progress
 

package/commands/gsd-t-quick.md

@@ -2,6 +2,23 @@
 
 You are executing a small, focused task that doesn't need full phase planning. This is for bug fixes, config changes, small features, and ad-hoc work.
 
+## Step 0: Launch via Subagent
+
+To give this task a fresh context window and prevent compaction during consecutive quick runs, always execute via a Task subagent.
+
+**If you are the orchestrating agent** (you received the slash command directly):
+Spawn a fresh subagent using the Task tool:
+```
+subagent_type: general-purpose
+prompt: "You are running gsd-t-quick for this request: {$ARGUMENTS}
+Working directory: {current project root}
+Read CLAUDE.md and .gsd-t/progress.md for project context, then execute gsd-t-quick starting at Step 1."
+```
+Wait for the subagent to complete. Relay its summary to the user. **Do not execute Steps 1–5 yourself.**
+
+**If you are the spawned subagent** (your prompt says "starting at Step 1"):
+Continue to Step 1 below.
+
 ## Step 1: Load Context (Fast)
 
 Read:
@@ -24,20 +41,17 @@ Should I proceed with quick mode or use the full execute workflow?"
 ### If it's within a single domain or pre-partition:
 Proceed.
 
-## Step 3: Spawn QA Agent
-
-Spawn the QA teammate to handle testing for this quick task:
+## Step 3: Execute
 
-```
-Teammate "qa": Read commands/gsd-t-qa.md for your full instructions.
-  Phase context: quick. Read .gsd-t/contracts/ for relevant contracts.
-  Write tests for the change, run the full test suite.
-  Report: test results and any coverage gaps found.
-```
+### Deviation Rules
 
-QA failure blocks the commit.
+When you encounter unexpected situations:
+1. **Bug blocking progress** → Fix it, up to 3 attempts. If still blocked, add to `.gsd-t/deferred-items.md` and skip.
+2. **Missing dependency clearly needed** → Add minimum required code to unblock. Note in commit.
+3. **Blocker (missing file, wrong API)** → Fix blocker and continue. Log if non-trivial.
+4. **Architectural change required** → STOP. Apply Destructive Action Guard. Never self-approve.
 
-## Step 4: Execute
+**3-attempt limit**: Stop looping after 3 failed fix attempts. Log and move on.
 
 1. Identify exactly which files need to change
 2. **Destructive Action Guard**: Check if this task involves destructive or structural changes (DROP TABLE, removing columns, deleting data, replacing architecture patterns, removing working modules, changing schema in ways that conflict with existing data). If YES → STOP and present the change to the user with what exists today, what will change, what will break, and a safe migration path. Wait for explicit approval.
@@ -46,7 +60,7 @@ QA failure blocks the commit.
 5. Verify it works
 6. Commit: `[quick] {description}`
 
-## Step 5: Document Ripple (if GSD-T is active)
+## Step 4: Document Ripple (if GSD-T is active)
 
 If `.gsd-t/progress.md` exists, assess what documentation was affected and update ALL relevant files:
 
@@ -65,7 +79,7 @@ If `.gsd-t/progress.md` exists, assess what documentation was affected and updat
 
 ### Skip what's not affected — most quick tasks will only touch 1-2 of these.
 
-## Step 6: Test & Verify (MANDATORY)
+## Step 5: Test & Verify (MANDATORY)
 
 Quick does not mean skip testing. Before committing:
 

package/commands/gsd-t-resume.md

@@ -15,8 +15,9 @@ You are resuming work after an interruption. This handles both same-session paus
 
 Read in this exact order:
 1. `CLAUDE.md` — project context and conventions
-2. `.gsd-t/progress.md` — current status, decisions, blockers
-3. `.gsd-t/contracts/` — all contract files
+2. **Check for continue-here files first**: List `.gsd-t/continue-here-*.md` files. If any exist, read the most recent one (highest timestamp). It contains exact position, next action, and open items — use this as the primary resume point.
+3. `.gsd-t/progress.md` — current status, decisions, blockers (always read this too)
+4. `.gsd-t/contracts/` — all contract files
 4. `.gsd-t/domains/*/scope.md` — domain boundaries
 5. `.gsd-t/domains/*/tasks.md` — task lists with completion status
 6. `.gsd-t/domains/*/constraints.md` — domain rules
@@ -25,13 +26,15 @@ Read in this exact order:
 
 ## Step 2: Determine Current Position
 
-From progress.md (or conversation context if same-session), identify:
+From the continue-here file (if present) OR progress.md (or conversation context if same-session), identify:
 - Current milestone and status
 - Which phase we're in
 - Which tasks are done, in progress, or blocked
 - Any pending decisions or user-input-needed items
 - Last entry in the Decision Log
 
+**If a continue-here file was found**: Use its "Next Action" field as the primary resume point. The continue-here file is more precise than progress.md alone. After resuming, delete the continue-here file (it has been consumed).
+
 ## Step 3: Report and Continue
 
 **Level 3 (Full Auto)**: Log a brief status line and auto-resume from the current task/phase. Do NOT wait for user input.

package/commands/gsd-t-scan.md

@@ -2,6 +2,24 @@
 
 You are the lead agent performing a comprehensive analysis of an existing codebase. Your job is to understand the architecture, identify business rules, surface vulnerabilities, find inefficiencies, and produce an actionable tech debt register.
 
+## Step 0: Launch via Subagent
+
+Scans are long-running and context-heavy. Always execute via a Task subagent for a fresh context window.
+
+**If you are the orchestrating agent** (you received the slash command directly):
+Spawn a fresh subagent using the Task tool:
+```
+subagent_type: general-purpose
+prompt: "You are running gsd-t-scan. Working directory: {current project root}
+Read CLAUDE.md and .gsd-t/progress.md for project context, then execute gsd-t-scan starting at Step 1.
+IMPORTANT: Step 2 requires team mode — spawn 5 teammates (architecture, business-rules, security, quality, contracts)
+running in parallel. Do not skip team mode or run dimensions sequentially."
+```
+Wait for the subagent to complete. Relay its summary to the user. **Do not execute Steps 1+ yourself.**
+
+**If you are the spawned subagent** (your prompt says "starting at Step 1"):
+Continue to Step 1 below. At Step 2, use team mode — spawn the 5 teammates in parallel.
+
 ## Step 1: Load Existing Context
 
 Read:
@@ -22,15 +40,15 @@ ALL TEAMMATES read first:
 - CLAUDE.md (if exists)
 - .gsd-t/contracts/ (if exists)
 
-- Teammate "architecture": Analyze project structure, tech stack,
+- Teammate "architecture" (model: haiku): Analyze project structure, tech stack,
   data flow, patterns. Write findings to .gsd-t/scan/architecture.md
-- Teammate "business-rules": Extract all embedded business logic,
+- Teammate "business-rules" (model: haiku): Extract all embedded business logic,
   validation, auth rules, workflows. Write to .gsd-t/scan/business-rules.md
-- Teammate "security": Full security audit — auth, injection, exposure,
+- Teammate "security" (model: sonnet): Full security audit — auth, injection, exposure,
   dependencies. Write to .gsd-t/scan/security.md
-- Teammate "quality": Dead code, duplication, complexity, test gaps,
+- Teammate "quality" (model: sonnet): Dead code, duplication, complexity, test gaps,
   performance, stale deps. Write to .gsd-t/scan/quality.md
-- Teammate "contracts": Compare .gsd-t/contracts/ to actual implementation,
+- Teammate "contracts" (model: haiku): Compare .gsd-t/contracts/ to actual implementation,
   find drift and undocumented interfaces. Write to .gsd-t/scan/contract-drift.md
   (skip if no contracts exist)
 

package/commands/gsd-t-status.md

@@ -2,6 +2,23 @@
 
 You are checking the current state of the project across all domains.
 
+## Launch via Subagent
+
+To keep the main conversation context lean, run status via a Task subagent.
+
+**If you are the orchestrating agent** (you received the slash command directly):
+Spawn a fresh subagent using the Task tool:
+```
+subagent_type: general-purpose
+model: haiku
+prompt: "You are running gsd-t-status. Working directory: {current project root}
+Read .gsd-t/progress.md and execute the full status report workflow."
+```
+Wait for the subagent to complete. Relay its output to the user. **Do not read files yourself.**
+
+**If you are the spawned subagent** (your prompt says "running gsd-t-status"):
+Continue below.
+
 ## Read These Files
 
 1. `.gsd-t/progress.md`

package/commands/gsd-t-test-sync.md

@@ -21,18 +21,17 @@ Identify:
 - Naming conventions
 - Test run commands (from package.json scripts, Makefile, or CI config)
 
-## Step 2: Spawn QA Agent
+## Step 2: Contract Coverage Audit
 
-Spawn the QA teammate to assist with test coverage analysis:
+Perform inline contract testing and gap analysis:
 
-```
-Teammate "qa": Read commands/gsd-t-qa.md for your full instructions.
-  Phase context: test-sync. Read .gsd-t/contracts/ for contract definitions.
-  Audit test coverage against contracts. Identify gaps and stale tests.
-  Report: coverage gaps, stale tests, and recommended test tasks.
-```
+1. Read all contracts in `.gsd-t/contracts/` — identify the interface each one defines
+2. For each contract, check whether a test file exists that validates it
+3. Run the full test suite: `npm test` (or project equivalent)
+4. Identify gaps: contracts with no tests, stale tests referencing removed APIs, uncovered code paths
+5. Report: coverage gaps, stale tests, and recommended test tasks
 
-QA agent works alongside the test sync process. QA failure blocks test-sync completion.
+Test-sync cannot complete if critical contract gaps remain unaddressed.
 
 ## Step 3: Map Code to Tests
 

package/commands/gsd-t-verify.md

@@ -12,18 +12,17 @@ Read:
 5. `docs/requirements.md` — original requirements
 6. All source code
 
-## Step 2: Spawn QA Agent
+## Step 2: Full Test Audit (Inline)
 
-Spawn the QA teammate to run the full test audit:
+Run the full test audit directly:
 
-```
-Teammate "qa": Read commands/gsd-t-qa.md for your full instructions.
-  Phase context: verify. Read .gsd-t/contracts/ for contract definitions.
-  Run full test audit — contract tests, acceptance tests, E2E suite.
-  Report: comprehensive test results with pass/fail counts and coverage gaps.
-```
+1. Run the full test suite: `npm test` (or project equivalent) — record pass/fail counts
+2. Read all contracts in `.gsd-t/contracts/` — verify each has at least one test validating it
+3. Check acceptance criteria from domain task lists — verify each is tested
+4. Run E2E suite if `playwright.config.*` exists
+5. Report: comprehensive test results with pass/fail counts and coverage gaps
 
-QA failure blocks verification completion.
+Verification cannot complete if any test fails or critical contract gaps remain.
 
 ## Step 3: Define Verification Dimensions
 
@@ -40,6 +39,12 @@ Standard dimensions (adjust based on project):
 5. **E2E Tests**: Run the FULL Playwright suite — all specs must pass. If new features lack specs, create them before proceeding.
 6. **Security**: Auth flows, input validation, data exposure, dependencies
 7. **Integration Integrity**: Do the seams between domains hold under stress?
+8. **Requirements Traceability Close-Out**: Mark verified requirements as complete and report orphans:
+   - Read `docs/requirements.md` traceability table (added by plan phase)
+   - For each REQ-ID that is fully implemented and tested: update Status to `complete` in the traceability table
+   - **Orphan report**: List any REQ-IDs with no task mapping (planning gap) and any tasks with no REQ-ID (potential scope creep)
+   - Orphaned requirements = WARN (not blocking unless critical)
+   - Update `docs/requirements.md` with the close-out results
 
 ## Step 4: Execute Verification
 
@@ -101,12 +106,7 @@ Teammate assignments:
   - Secret/credential handling
   Report: severity-ranked findings.
 
-- Teammate "qa": Read commands/gsd-t-qa.md for your full instructions.
-  Phase context: verify. Read .gsd-t/contracts/ for contract definitions.
-  Run full test audit — contract tests, acceptance tests, E2E suite.
-  Report: comprehensive test results with pass/fail counts and coverage gaps.
-
-Lead: Collect all reports (including QA), synthesize, create remediation plan.
+Lead: After receiving teammate reports, spawn a Task subagent to run the full test suite and contract audit. Collect all reports, synthesize, create remediation plan.
 ```
 
 ## Step 5: Compile Verification Report

package/commands/gsd-t-wave.md

@@ -120,14 +120,18 @@ Spawn agent → `commands/gsd-t-complete-milestone.md`
 
 ### Between Each Phase
 
-After each agent completes:
-1. Read `.gsd-t/progress.md` to verify the phase updated status correctly
-2. Report brief status to user:
+After each agent completes, run this spot-check before proceeding:
+
+1. **Status check**: Read `.gsd-t/progress.md` — verify the phase updated status correctly (no FAILED markers, status matches expected phase completion state)
+2. **Git check**: Run `git log --oneline -5` — verify commits were made during this phase (if execute/integrate: at least one commit per task completed)
+3. **Filesystem check**: Verify key output files exist on disk — e.g., for partition: `.gsd-t/domains/*/scope.md` and `.gsd-t/contracts/` files; for execute: newly created source files; for verify: `.gsd-t/verify-report.md`. Do not trust agent-reported completions alone.
+4. Report to user:
    ```
    ✅ {Phase} complete — {agent's one-line summary}
+   📋 Spot-check: {N} commits | {N} output files verified | no FAILED markers
    ```
-3. If status was NOT updated correctly: report error and stop
-4. Proceed to next phase
+5. If spot-check fails: report the discrepancy, re-spawn the phase agent once to correct it, then re-verify. If still failing: stop and report to user.
+6. Proceed to next phase
 
 ## Step 4: Autonomy Behavior
 

package/docs/GSD-T-README.md

@@ -112,6 +112,8 @@ GSD-T reads all state files and tells you exactly where you left off.
 | `/user:gsd-t-resume` | Restore context, continue | Manual |
 | `/user:gsd-t-quick` | Fast task with GSD-T guarantees | Manual |
 | `/user:gsd-t-debug` | Systematic debugging with state | Manual |
+| `/user:gsd-t-health` | Validate .gsd-t/ structure, optionally repair | Manual |
+| `/user:gsd-t-pause` | Save exact position for reliable resume | Manual |
 | `/user:gsd-t-log` | Sync progress Decision Log with recent git activity | Manual |
 | `/user:gsd-t-version-update` | Update GSD-T to latest version | Manual |
 | `/user:gsd-t-version-update-all` | Update GSD-T + all registered projects | Manual |