@tekyzinc/gsd-t 3.26.10 → 3.26.11

package/CHANGELOG.md

@@ -2,6 +2,23 @@
 
 All notable changes to GSD-T are documented here. Updated with each release.
 
+## [3.26.11] - 2026-05-11
+
+### Changed — Effort estimates in GSD-T-native units
+
+Promoted `feedback_no_human_hour_estimates.md` from per-user memory to canonical global rule. Replaced all 7 `Estimated effort: {assessment}` placeholders that were silently producing developer-hour / dev-day / sprint output with explicit GSD-T-unit prompts.
+
+- `~/.claude/CLAUDE.md` + `templates/CLAUDE-global.md`: new MANDATORY section "Effort Estimates — GSD-T-Native Units" with the unit table (domain count, wave count, parallel-domain count, spawn count, token-spend range, rate-limit-window count) + acceptable-machine-time-references carve-out (5 min cache TTL, 14 day staleness, etc.) so the rule doesn't break legitimate system-timeout language.
+- `commands/gsd-t-milestone.md` Step 4: Pre-Partition Assessment now requires GSD-T units, presents the unit table inline.
+- `commands/gsd-t-scan.md`: 5 `Estimated effort: {assessment}` placeholders replaced with `Estimated scope: {N domains}/{N waves}/$X-Y token-spend` + memory reference.
+- `commands/gsd-t-promote-debt.md`: same swap.
+- `commands/gsd-t-scan.md`: "Dependency Update Sprint" → "Dependency Update".
+- `templates/stacks/design-to-code.md`: "estimate effort" → "scope in GSD-T units".
+
+Rationale: human-hour estimates ("30-min task", "2-3 day window") create false mental models for GSD-T workflows where the worker is Claude, not a human team. Token-spend, parallel-domain count, and rate-limit-window count are the actually-predictive units.
+
+Tests: 2547/2547 (unchanged — doc-only change).
+
 ## [3.26.10] - 2026-05-09
 
 ### Added — M56: Verify-Gate CLI Fan-Out + Upper-Stage Briefs

package/commands/gsd-t-milestone.md

@@ -68,13 +68,29 @@ Ask user: "Milestone {N-1} is still {status}. Archive it and start new? Or compl
 node scripts/gsd-t-watch-state.js advance --agent-id "$GSD_T_AGENT_ID" --parent-id "${GSD_T_PARENT_AGENT_ID:-null}" --command gsd-t-milestone --step 4 --step-label "Pre-Partition Assessment" 2>/dev/null || true
 ```
 
-Before formal partitioning, do a quick assessment:
+Before formal partitioning, do a quick assessment.
 
-- **Complexity estimate**: Simple (1-2 domains), Medium (3-4), Complex (5+)
+**Express scope in GSD-T-native units only.** Per `feedback_no_human_hour_estimates.md` (memory): never use developer-hours, dev-days, sprints, story points, or person-weeks. Use these instead:
+
+| Unit | Use for |
+|------|---------|
+| **Domain count** | Partition coarseness (1-2 / 3-4 / 5+) |
+| **Wave count** | How many serial gates the milestone needs |
+| **Spawn count** | Estimated `claude -p` / Task subagent invocations |
+| **Token-spend range** | `$X-Y` based on prior comparable milestones |
+| **Rate-limit-window count** | If the milestone might span > 1 5h Claude Max window |
+| **Parallel-domain count** | How many domains can run concurrently (file-disjoint) |
+
+Assessment template:
+
+- **Domain count**: Simple (1-2 domains), Medium (3-4), Complex (5+)
+- **Wave count**: estimated based on cross-domain dependencies
+- **Parallel-domain count**: how many can run in the same wave
+- **Token-spend range**: $X-Y based on prior comparable milestones (read `.gsd-t/token-log.md` for trailing-3 comparison)
 - **Recommended approach**:
-  - Simple: Consider using /gsd-t-quick for each piece
-  - Medium: Standard partition → plan → execute flow
-  - Complex: Partition → discuss → plan → execute → integrate → verify
+  - 1-2 domains: Consider using /gsd-t-quick for each piece
+  - 3-4 domains: Standard partition → plan → execute flow
+  - 5+ domains: Partition → discuss → plan → execute → integrate → verify
 
 Present the assessment and ask: "Ready to partition into domains now, or want to discuss first?"
 

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

@@ -67,7 +67,7 @@ Append to `.gsd-t/roadmap.md`:
 - [ ] {each debt item resolved and verified}
 - [ ] No regression in existing functionality
 - [ ] {item-specific criteria from techdebt.md}
-**Estimated effort**: {combined effort assessment}
+**Estimated scope**: {N domains} / {N waves} / $X-Y token-spend (express in GSD-T units only — never developer-hours/days/sprints per `feedback_no_human_hour_estimates.md`)
 **Priority**: {CRITICAL — before next feature | HIGH — soon | MEDIUM — planned}
 ```
 

package/commands/gsd-t-scan.md

@@ -351,7 +351,7 @@ Synthesize ALL findings into a **fresh** `.gsd-t/techdebt.md` (the previous vers
 - High priority: {N}
 - Medium priority: {N}
 - Low priority: {N}
-- Total estimated effort: {rough assessment}
+- Total estimated scope: {N domains} / {N waves} / $X-Y token-spend (GSD-T units only — see `feedback_no_human_hour_estimates.md`)
 - Previous scan archive: techdebt_{previous-date}.md
 
 ---
@@ -461,22 +461,22 @@ Review all items marked `Milestone candidate: YES` and group them into logical m
 
 ### Suggested: Security Hardening (Critical)
 Combines: TD-001, TD-003, TD-005
-Estimated effort: {assessment}
+Estimated scope: {domain-count} domains, {wave-count} waves, $X-Y token-spend (express in GSD-T units — domain/wave/spawn/token — never human-hours/days/sprints per `feedback_no_human_hour_estimates.md`)
 Should be prioritized: BEFORE next feature milestone
 
 ### Suggested: Performance Optimization (High)
 Combines: TD-010, TD-012, TD-015
-Estimated effort: {assessment}
+Estimated scope: {domain-count} domains, {wave-count} waves, $X-Y token-spend (express in GSD-T units — domain/wave/spawn/token — never human-hours/days/sprints per `feedback_no_human_hour_estimates.md`)
 Can be scheduled: AFTER current feature work
 
-### Suggested: Dependency Update Sprint (Medium)
+### Suggested: Dependency Update (Medium)
 Combines: TD-020, dependency table items with breaking=yes
-Estimated effort: {assessment}
+Estimated scope: {domain-count} domains, {wave-count} waves, $X-Y token-spend (express in GSD-T units — domain/wave/spawn/token — never human-hours/days/sprints per `feedback_no_human_hour_estimates.md`)
 Can be scheduled: During next maintenance window
 
 ### Suggested: Shared Service Extraction (if candidates found)
 Combines: all "Shared Service Candidates" from quality.md Reusability Analysis
-Estimated effort: {assessment}
+Estimated scope: {domain-count} domains, {wave-count} waves, $X-Y token-spend (express in GSD-T units — domain/wave/spawn/token — never human-hours/days/sprints per `feedback_no_human_hour_estimates.md`)
 Should be prioritized: BEFORE adding new consumer surfaces to the system
 Note: Use `/gsd-t-partition` Step 1.6 to design the SharedCore domain
 ```

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tekyzinc/gsd-t",
-  "version": "3.26.10",
+  "version": "3.26.11",
   "description": "GSD-T: Contract-Driven Development for Claude Code — 54 slash commands with headless-by-default workflow spawning, unattended supervisor relay with event stream, graph-powered code analysis, real-time agent dashboard, task telemetry, doc-ripple enforcement, backlog management, impact analysis, test sync, milestone archival, and PRD generation",
   "author": "Tekyz, Inc.",
   "license": "MIT",

package/templates/CLAUDE-global.md

@@ -572,6 +572,30 @@ BEFORE reporting "done" or presenting a summary:
 
 **The test for this gate**: If the user asks "did you update all the documents?" and the answer would be "no, I missed some" — you failed this gate. The user should never need to ask.
 
+## Effort Estimates — GSD-T-Native Units (MANDATORY)
+
+**NEVER express effort or scope in developer-hours, dev-days, sprints, story points, or person-weeks.** GSD-T operates on a different cost model — the worker is Claude, not a human team — and human-time estimates have no predictive value for GSD-T workflows. They actively mislead by suggesting a calendar shape that doesn't match how the system runs.
+
+Use GSD-T-native units instead:
+
+| Unit | When to use |
+|------|-------------|
+| **Domain count** | Milestone scope (1-2 simple, 3-4 medium, 5+ complex) |
+| **Wave count** | Cross-domain dependency depth — how many serial gates exist |
+| **Parallel-domain count** | How many domains can run concurrently (file-disjoint) |
+| **Spawn count** | Estimated `claude -p` / Task subagent invocations |
+| **Token-spend range** | `$X-Y` dollars based on trailing-3 comparable milestones in `.gsd-t/token-log.md` |
+| **Rate-limit-window count** | If the work might span > 1 5h Claude Max window |
+
+Where this applies:
+- `/gsd-t-milestone` Step 4 — Pre-Partition Assessment
+- `/gsd-t-scan` techdebt milestone suggestions
+- `/gsd-t-promote-debt` effort fields
+- `docs/requirements.md`, `progress.md` Decision Log entries
+- Any internal estimate the user might read
+
+Acceptable: machine-time references (e.g. "5 min cache TTL", "5h rate-limit window", "14 day staleness threshold") — these are concrete system properties, not effort estimates. The rule applies to **effort/scope**, not to **system timeouts**.
+
 ## Execution Behavior
 - ALWAYS check docs/architecture.md before adding or modifying components.
 - ALWAYS check docs/workflows.md before changing any multi-step process.

package/templates/stacks/design-to-code.md

@@ -176,7 +176,7 @@ MANDATORY:
   │
   ├── For each design requirement, assess:
   │     Supported → stack handles this natively, proceed
-  │     Partial → needs an addon/library — name it, estimate effort
+  │     Partial → needs an addon/library — name it, scope in GSD-T units (domain/wave/spawn/token, NOT dev-hours)
   │     Unsupported → stack CANNOT achieve this — flag as a blocker
   │
   ├── If ANY requirement is Unsupported: