@tekyzinc/gsd-t 3.29.11 → 4.0.14

package/commands/gsd-t-feature.md

@@ -14,12 +14,8 @@ If `.gsd-t/scan/.cache.json` exists:
 1. Read the cache and check `scannedAt` for each dimension
 2. Count commits since the scan: `git rev-list --count --after="{scannedAt}" HEAD`
 3. If **>10 commits since scan** OR **scan is older than 14 days**:
-   - Log: "Auto-refreshing scan docs (stale by {N} commits / {N} days)..."
-   - Re-run only the stale dimensions by spawning the relevant scan teammates:
-     - If `quality.md` stale → spawn quality teammate (model: sonnet)
-     - If `architecture.md` stale → spawn architecture teammate (model: haiku)
-     - If `security.md` stale → spawn security teammate (model: sonnet)
-   - Update `.gsd-t/scan/.cache.json` after refresh
+   - Log: "Auto-refreshing the tech-debt register (stale by {N} commits / {N} days)..."
+   - Re-run the scan by invoking the volume-scaled scan Workflow (`templates/workflows/gsd-t-scan.workflow.js`, same as `/gsd-t-scan`) — the probe re-slices the codebase and the finders refresh the register. This replaces the retired fixed-dimension teammate refresh.
 4. If fresh → proceed silently
 
 If `.gsd-t/scan/` doesn't exist at all → skip (no scan data to refresh).

package/commands/gsd-t-gap-analysis.md

@@ -14,14 +14,11 @@ If `.gsd-t/scan/.cache.json` exists:
 1. Read the cache and check `scannedAt` for each dimension
 2. Count commits since the scan: `git rev-list --count --after="{scannedAt}" HEAD`
 3. If **>10 commits since scan** OR **scan is older than 14 days**:
-   - Log: "Auto-refreshing scan docs (stale by {N} commits / {N} days)..."
-   - Re-run only the stale dimensions by spawning the relevant scan teammates:
-     - If `architecture.md` stale → spawn architecture teammate (model: haiku)
-     - If `quality.md` stale → spawn quality teammate (model: sonnet)
-   - Update `.gsd-t/scan/.cache.json` after refresh
+   - Log: "Auto-refreshing the tech-debt register (stale by {N} commits / {N} days)..."
+   - Re-run the scan by invoking the volume-scaled scan Workflow (`templates/workflows/gsd-t-scan.workflow.js`, same as `/gsd-t-scan`) — the probe re-slices the codebase and the finders refresh the register. This replaces the retired fixed-dimension teammate refresh.
 4. If fresh → proceed silently
 
-If `.gsd-t/scan/` doesn't exist at all → skip (no scan data to refresh).
+If no prior `.gsd-t/techdebt.md` exists at all → skip (no scan data to refresh).
 
 ## Step 1: Load Context
 

package/commands/gsd-t-help.md

@@ -196,9 +196,9 @@ Use these when user asks for help on a specific command:
 - **Use when**: Adding significant new functionality to existing project
 
 ### scan
-- **Summary**: Deep codebase analysis producing architecture docs and techdebt.md
+- **Summary**: Deep codebase analysis producing techdebt.md — volume-scaled native Workflow (`templates/workflows/gsd-t-scan.workflow.js`): a probe carves the codebase into per-area slices, one deep finder per slice (enumerate-don't-sample), a single verify pass drops false positives, synthesis dedups/re-ranks into the register. Finder count scales with codebase volume (1-3 slices tiny → 15-40 large), not a fixed 5.
 - **Auto-invoked**: No
-- **Creates**: `.gsd-t/scan/`, `.gsd-t/techdebt.md`
+- **Creates**: `.gsd-t/techdebt.md` (prior archived to `.gsd-t/techdebt_YYYY-MM-DD.md`), the `.gsd-t/scan/*.md` dimension files, the full living-doc set (`docs/architecture.md`, `docs/workflows.md`, `docs/infrastructure.md`, `docs/requirements.md`, `README.md` — merged not overwritten, via the M67 document phase), and the HTML scan report
 - **Use when**: Understanding an existing codebase or auditing technical debt
 
 ### gap-analysis
@@ -318,8 +318,6 @@ Use these when user asks for help on a specific command:
 - **Reads**: `.gsd-t/dashboard.pid`, `.gsd-t/events/*.jsonl` (via server)
 - **Creates**: `.gsd-t/dashboard.pid` (when starting server)
 - **Use when**: Monitoring live agent activity during execute/wave phases; run `gsd-t-visualize stop` to stop the server
-- **Spawn-plan panel (M44 D8, v3.18.10+)**: the transcript viewer at `/transcript/{spawnId}` now includes a right-side two-layer task panel (Layer 1 project · Layer 2 active spawn). Status icons `☐` pending, `◐` in_progress, `✓` done. Done tasks show a right-aligned token cell `in=12.5k out=1.7k $0.42` (or `—` when attribution unavailable). Token attribution is sourced from `.gsd-t/token-log.md` via the post-commit hook `scripts/gsd-t-post-commit-spawn-plan.sh`. Endpoints: `GET /api/spawn-plans` + SSE `/api/spawn-plans/stream`. Contract: `.gsd-t/contracts/spawn-plan-contract.md` v1.0.0.
-- **Parallelism panel (M44 D9, v3.19.0+)**: below the spawn-plan panel, the transcript viewer shows `activeWorkers`, `readyTasks`, `parallelism_factor`, oldest-spawn age, gate-decision tallies (dep/disjoint/economics), a color-state border (green/yellow/red/dimmed), a `📄 Full Report` button that downloads a post-mortem markdown, and a `Stop Supervisor` button. Polls `GET /api/parallelism` every 5s (5s server-side cache). Endpoints: `GET /api/parallelism`, `GET /api/parallelism/report?wave=N`, `POST /api/unattended-stop`. Pure reader — zero added LLM token cost. Contract: `.gsd-t/contracts/parallelism-report-contract.md` v1.0.0.
 
 ### metrics
 - **Summary**: View task telemetry, process ELO, signal distribution, domain health, and cross-project comparison (with `--cross-project` flag)

package/commands/gsd-t-impact.md

@@ -1,314 +1,45 @@
 # GSD-T: Impact — Downstream Effect Analysis
 
-You are analyzing the downstream effects of planned changes before execution. Your job is to identify what might break, what needs updating, and what risks exist.
+You are the lead agent. Run the impact phase by invoking the generic upper-stage Workflow at `templates/workflows/gsd-t-phase.workflow.js` with `phase: "impact"`. This phase is read-only — it analyzes, it does not implement.
 
-This command is:
-- **Auto-invoked** between plan and execute phases in `/gsd-t-wave`
-- **Standalone** when user wants to evaluate potential changes
+## What this command does
 
-## Step 1: Load Context
-
-Read:
-1. `CLAUDE.md` — project conventions
-2. `.gsd-t/progress.md` — current state
-3. `.gsd-t/contracts/` — all contracts
-4. `.gsd-t/domains/{current}/tasks.md` — planned changes
-
-If run standalone, ask: "What changes are you considering?"
-
-<!-- M56-D3: brief wire-in -->
-**M56 Context-Brief (surfaces git diff + integration-points excerpt without re-walking the repo):**
-
-```bash
-SPAWN_ID="impact-${MILESTONE:-default}-$(date -u +%Y%m%dT%H%M%SZ)"
-gsd-t brief --kind impact --spawn-id "${SPAWN_ID}" --out ".gsd-t/briefs/${SPAWN_ID}.json" || true
-export BRIEF_PATH=".gsd-t/briefs/${SPAWN_ID}.json"
-```
-
-The `impact` brief includes `gitDiffSummary`, `changedFiles[]`, and the milestone's `integrationPointsExcerpt` so downstream workers can scan blast radius without re-reading the contract dir.
-<!-- /M56-D3: brief wire-in -->
-
-## Step 2: Identify Changed Files
-
-From the plan or user description, list:
-- Files to be created
-- Files to be modified
-- Files to be deleted
-- Functions/classes/endpoints being changed
-
-## Step 2.5: Graph-Enhanced Analysis (if available)
-
-Check if a graph index exists: read `.gsd-t/graph/meta.json`. If it exists:
-
-```
-For each changed file/function, query the graph:
-1. query('getCallers', { entity: '{function_name}' })         → all direct callers
-2. query('getTransitiveCallers', { entity: '{name}', depth: 5 }) → full caller chain
-3. query('getDomainOwner', { entity: '{name}' })               → which domain owns this
-4. query('getContractFor', { entity: '{name}' })               → which contract it implements
-5. query('getSurfaceConsumers', { entity: '{name}' })          → which surfaces consume it
-6. query('getDomainBoundaryViolations', {})                    → cross-domain access issues
-```
-
-Use graph results to build a **complete blast radius** that includes transitive callers, contract violations, and cross-surface impact. This replaces the grep-based search in Step 3A when available but grep remains the fallback when no graph exists.
-
-## Step 3: Trace Dependencies
-
-For each changed file/function:
-
-### A) Who Calls This?
-
-**If graph available** (Step 2.5): use graph results — they include transitive callers that grep misses.
-
-**If no graph** (fallback):
-```bash
-# Find all imports/requires of this module
-grep -r "import.*{module}" src/
-grep -r "from.*{module}" src/
-grep -r "require.*{module}" src/
-```
-
-### B) Who Does This Call?
-- List dependencies this code relies on
-- Note if any of those are also changing
-
-### C) Contract Consumers
-- Check `.gsd-t/contracts/api-contract.md` — does this change an endpoint?
-- Check `.gsd-t/contracts/schema-contract.md` — does this change data shape?
-- Check `.gsd-t/contracts/component-contract.md` — does this change props/interface?
-
-### D) New Consumer Analysis
-
-**Trigger**: Run this section when the planned change adds a new client surface (web app, mobile app, CLI, external API, admin panel, etc.) that will consume the existing backend.
-
-If no new consumer surface is being added, skip this section.
-
-**Step 1 — List what the new consumer needs:**
 ```
-Operations the new consumer requires:
-- {operation-name}: {brief description}
-- {operation-name}: {brief description}
+preflight → brief (kind=impact) → impact agent (opus, with phase protocol)
 ```
 
-**Step 2 — Compare against existing backend operations:**
-```bash
-# Search for existing implementations of each needed operation
-grep -r "{operation-name}" src/
-grep -r "{operation-name}" commands/
-```
-
-**Step 3 — Classify each needed operation:**
-
-| Operation | Classification | Action |
-|-----------|---------------|--------|
-| {op} | REUSE — identical operation exists | Call existing endpoint/function |
-| {op} | EXTEND — similar operation exists, needs a variant | Add param or thin adapter |
-| {op} | DUPLICATE — new endpoint would replicate existing logic | 🔴 Must route through shared layer |
-| {op} | NEW — no equivalent exists | Build new, consider SharedCore placement |
-
-**DUPLICATE items become 🔴 Breaking Changes** in Step 4 — they block execution until the shared layer is designed. Add them to the impact report under "Breaking Changes" with:
-- Required Action: "Extract `{operation}` to shared-core domain; {new-consumer} and {existing-consumer} both call it from there."
-
-### E) Test Coverage
-- Which tests cover this code?
-- Will they still pass after changes?
-- Are there tests that assert current behavior that will become wrong?
-
-## Step 4: Classify Impacts
-
-Categorize each finding:
-
-### 🔴 Breaking Changes
-Changes that WILL break something if not addressed:
-- API signature changes with existing consumers
-- Database schema changes with existing queries
-- Removed functions still being called
-- Changed return types
-
-### 🟡 Requires Updates
-Changes that need coordinated updates:
-- Tests asserting old behavior
-- Documentation references
-- Related UI components
-- Dependent domain tasks
-
-### 🟢 Safe Changes
-Changes with no downstream impact:
-- New files with no consumers yet
-- Internal refactors with same interface
-- Additive changes (new optional params)
-
-### ⚪ Unknown
-Can't determine impact — needs investigation:
-- Dynamic imports
-- Reflection-based code
-- External integrations
-
-## Step 5: Check Contract Compliance
-
-For each contract:
-- Will planned changes violate the contract?
-- Does the contract need to be updated first?
-- Are there consumers not yet updated for contract changes?
-
-Flag: "Contract violation detected — {contract} specifies {X}, but plan changes to {Y}"
-
-## Step 6: Produce Impact Report
-
-Create/update `.gsd-t/impact-report.md`:
+The agent analyzes the downstream effects of proposed changes: what might break, what needs updating, which consumers are affected, and what migration paths exist. No code is written.
 
-```markdown
-# Impact Analysis — {date}
+## Step 1: Read the current milestone state
 
-## Summary
-- Breaking changes: {N}
-- Requires updates: {N}
-- Safe changes: {N}
-- Unknown: {N}
-- **Recommendation**: {PROCEED | PROCEED WITH CAUTION | BLOCK}
+Read `.gsd-t/progress.md`, the relevant domain `tasks.md`, and `docs/architecture.md`/`.gsd-t/contracts/` for the surfaces in scope.
 
-## Planned Changes
-| File | Change Type | Description |
-|------|-------------|-------------|
-| {file} | {create/modify/delete} | {what} |
+## Step 2: Invoke the phase Workflow
 
----
-
-## 🔴 Breaking Changes
-
-### IMP-001: {title}
-- **Change**: {what's changing}
-- **Affected**: {files/functions/consumers}
-- **Impact**: {what will break}
-- **Required Action**: {what must be done}
-- **Blocking**: YES — cannot proceed without addressing
-
----
-
-## 🟡 Requires Updates
-
-### IMP-010: {title}
-- **Change**: {what's changing}
-- **Affected**: {files/tests/docs}
-- **Action**: {update X to reflect Y}
-- **Blocking**: NO — can be done during or after execution
-
----
-
-## 🟢 Safe Changes
-
-- {file}: {change} — no downstream impact
-- {file}: {change} — additive only
-
----
-
-## ⚪ Unknown Impact
-
-### IMP-020: {title}
-- **Change**: {what}
-- **Uncertainty**: {why we can't determine impact}
-- **Recommendation**: {manual review / test thoroughly / ask user}
-
----
-
-## Contract Status
-
-| Contract | Status | Notes |
-|----------|--------|-------|
-| api-contract.md | {OK / VIOLATION / UPDATE NEEDED} | {details} |
-| schema-contract.md | {OK / VIOLATION / UPDATE NEEDED} | {details} |
-| component-contract.md | {OK / VIOLATION / UPDATE NEEDED} | {details} |
-
----
-
-## Test Impact
-
-| Test File | Status | Action Needed |
-|-----------|--------|---------------|
-| {test} | {WILL PASS / WILL FAIL / NEEDS UPDATE} | {action} |
-
----
-
-## Recommended Execution Order
-
-1. {First, update X because...}
-2. {Then, modify Y...}
-3. {Finally, Z...}
-
-## Generated Tasks
-
-If breaking changes require pre-work, add to domain tasks:
-- [ ] IMP-001: {remediation task}
-- [ ] IMP-002: {remediation task}
-```
-
-## Step 7: Document Ripple
-
-After producing the impact report, update affected documentation:
-
-### Always update:
-1. **`.gsd-t/progress.md`** — Log the impact analysis in the Decision Log with date and key findings
-
-### Check if affected:
-2. **`docs/architecture.md`** — If the analysis revealed architectural concerns or proposed changes, document them
-3. **`docs/requirements.md`** — If the analysis found requirements that would be affected by the planned changes, note the impact
-4. **`.gsd-t/contracts/`** — If contract violations or needed updates were found, flag them clearly in the contracts (mark as "PENDING UPDATE")
-5. **`.gsd-t/techdebt.md`** — If the analysis uncovered new debt or risk areas, add them
-
-### Skip what's not affected.
-
-## Step 8: Test Verification
-
-Validate the test landscape before recommending proceed/block:
-
-1. **Run existing tests**: Execute the full test suite to establish current state
-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 9: Decision Gate
-
-### If PROCEED:
-"✅ Impact analysis complete. No blocking issues found. Ready for execution."
-- Continue to execute phase (if auto-invoked)
-- Or report and exit (if standalone)
-
-### If PROCEED WITH CAUTION:
-"⚠️ Impact analysis found {N} items requiring attention:"
-- List the yellow items
-
-**Level 3 (Full Auto)**: Log the caution items and auto-advance to execute. Do NOT wait for user input.
-
-**Level 1–2**: "These can be addressed during execution. Proceed?" Wait for user confirmation. If user declines, pause for remediation.
-
-### If BLOCK:
-"🛑 Impact analysis found breaking changes that must be addressed first:"
-- List the red items
-- Generate remediation tasks
-- Add tasks to current domain's task list
-- "Run `/gsd-t-execute` to address these first, then re-run impact analysis."
-- Do NOT proceed to execute phase
-
-## Standalone Mode
-
-When run independently (not as part of wave):
-
-```
-/gsd-t-impact "considering adding user roles to the auth system"
+```js
+{
+  scriptPath: "templates/workflows/gsd-t-phase.workflow.js",
+  args: {
+    phase: "impact",
+    milestone: "M{NN}",
+    projectDir: ".",
+    userInput: "$ARGUMENTS"
+  }
+}
 ```
 
-1. Ask clarifying questions about the change
-2. Run full analysis
-3. Produce report
-4. Do NOT auto-proceed — just inform
+## Step 3: Interpret the result
 
-### Autonomy Behavior
+The Workflow returns `{ status, artifacts, summary, decisions }`.
 
-**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.
+- `status === "complete"`: blast radius identified; breaking changes and migration paths listed in `summary`/`decisions`. Auto-advance to `/gsd-t-execute`.
+- `status === "blocked"`: the analysis surfaced a decision the user must make (e.g. an unavoidable breaking change). Surface it.
+- `status === "failed"`: read `summary`.
 
-**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?"
+## Document Ripple
 
-$ARGUMENTS
+The impact agent records findings in the Decision Log and flags any contract or requirement that must change before execution.
 
-## Auto-Clear
+## Next Up
 
-All work is committed to project files. Execute `/clear` to free the context window for the next command.
+`/gsd-t-execute` — run domain tasks with the impact findings in hand.

package/commands/gsd-t-init-scan-setup.md

@@ -101,16 +101,16 @@ If the project has source code, graph indexing (`.gsd-t/graph/`) will run as par
 
 ## Step 4: Deep Codebase Scan (gsd-t-scan)
 
-Execute the full scan workflow (same as `/gsd-t-scan`):
+Execute the full scan by invoking the volume-scaled scan Workflow (same as `/gsd-t-scan` — `templates/workflows/gsd-t-scan.workflow.js`):
 
-1. Scan across all dimensions: architecture, business rules, security, quality, contracts
-2. Build `.gsd-t/techdebt.md` register
-3. Cross-populate findings into living documents (docs/architecture.md, docs/workflows.md, docs/infrastructure.md, docs/requirements.md)
-4. Update README.md with discovered tech stack and setup info
+1. The volume-probe slices the codebase by area (scaling with volume, not a fixed dimension set); per-slice deep finders enumerate; a single verify pass drops false positives.
+2. Synthesis builds the `.gsd-t/techdebt.md` register and the `.gsd-t/scan/*.md` analysis files.
+3. Cross-populate findings into living documents (docs/architecture.md, docs/workflows.md, docs/infrastructure.md, docs/requirements.md) from the register + analysis files.
+4. Update README.md with discovered tech stack and setup info.
 
-Always use team mode for the scan unless the codebase is trivially small (< 5 files) or teams are explicitly disabled.
+The Workflow's fan-out scales with codebase volume automatically — no team-mode toggle.
 
-**If `.gsd-t/techdebt.md` already exists**: Append new findings, don't overwrite.
+**If `.gsd-t/techdebt.md` already exists**: the Workflow archives it to `.gsd-t/techdebt_YYYY-MM-DD.md` and continues TD numbering.
 
 ## Step 5: Generate Project CLAUDE.md (gsd-t-setup)