@tekyzinc/gsd-t 2.3.0 → 2.5.0

package/README.md

@@ -135,7 +135,7 @@ This will replace changed command files, back up your CLAUDE.md if customized, a
 | Command | Purpose |
 |---------|---------|
 | `/user:branch` | Create and switch to a new git branch |
-| `/user:checkin` | Stage, commit, and push all changes |
+| `/user:checkin` | Auto-bump version, stage, commit, and push |
 | `/user:Claude-md` | Reload CLAUDE.md directives mid-session |
 
 ---
@@ -254,7 +254,7 @@ get-stuff-done-teams/
 ├── commands/                          # 27 slash commands
 │   ├── gsd-t-*.md                     # 24 GSD-T workflow commands
 │   ├── branch.md                      # Git branch helper
-│   ├── checkin.md                     # Git commit/push helper
+│   ├── checkin.md                     # Auto-version + commit/push helper
 │   └── Claude-md.md                   # Reload CLAUDE.md directives
 ├── templates/                         # Document templates
 │   ├── CLAUDE-global.md

package/commands/checkin.md

@@ -1,15 +1,30 @@
 # Check in updated files to GitHub
 
-Automatically stage, commit, and push all updated files to GitHub.
+Automatically stage, commit, and push all updated files to GitHub with automatic version bumping.
 
 ## Instructions
 
 1. Run `git status` to see what files have changed
 2. If there are no changes, inform the user and stop
 3. Run `git diff` to review the changes
-4. Stage all changes with `git add -A`
-5. Create a commit with a descriptive message summarizing the changes
-6. Push to origin with `git push`
-7. Confirm success to the user
+4. Run the **Pre-Commit Gate** checklist from CLAUDE.md — update any docs before proceeding
+
+### Version Bump (Automatic)
+
+5. Determine the version bump type from the nature of the changes:
+   - **patch** (default): Bug fixes, doc updates, refactors, minor improvements, cleanup
+   - **minor**: New features, new commands, new capabilities
+   - **major**: Breaking changes, major rework, incompatible API changes
+6. Read the current version from `package.json`
+7. Bump the version according to the determined type (e.g., `2.3.0` → `2.3.1` for patch)
+8. Update the version in `package.json`
+9. If `.gsd-t/progress.md` exists, check for a `## Version` line and update it (or add one after the `## Date` line)
+
+### Commit and Push
+
+10. Stage all changes (including the version bump) with `git add -A`
+11. Create a commit with a descriptive message summarizing the changes. Include `(vX.Y.Z)` at the end of the first line. Example: `fix: resolve branch guard edge case (v2.3.1)`
+12. Push to origin with `git push`
+13. Confirm success to the user, including the old → new version
 
 Use the standard commit message format with Co-Authored-By line.

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

@@ -141,6 +141,33 @@ 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
+
+Before creating the git tag, verify all documentation is up to date:
+
+### Always update:
+1. **`.gsd-t/progress.md`** — Already updated in Step 6, verify it's complete with version and milestone state
+2. **`README.md`** — Already updated in Step 7, verify it reflects all delivered capabilities
+
+### Check if affected:
+3. **`docs/requirements.md`** — Verify all requirements delivered in this milestone are marked as complete
+4. **`docs/architecture.md`** — Verify the architecture doc matches the current system state after all milestone work
+5. **`docs/workflows.md`** — Verify any workflows added or changed during the milestone are documented
+6. **`docs/infrastructure.md`** — If infrastructure changed during the milestone (new services, new deployment steps), verify it's documented
+7. **`CLAUDE.md`** — Verify any conventions established during the milestone are captured
+8. **`.gsd-t/techdebt.md`** — Verify any debt resolved during the milestone is marked done, and any new debt discovered is logged
+
+### This is the LAST GATE before tagging — nothing should be undocumented.
+
+## Step 7.6: Test Verification
+
+Before creating the git tag, verify the milestone is truly complete:
+
+1. **Run the full test suite**: Execute ALL tests — unit, integration, and E2E if available
+2. **Verify all pass**: Every test must pass. If any fail, fix before tagging (up to 2 attempts)
+3. **Compare to baseline**: If a test baseline was recorded at milestone start, verify coverage has improved or at minimum not regressed
+4. **Log test results**: Include test pass/fail counts in the milestone summary (Step 4)
+
 ## Step 8: Create Git Tag
 
 ```bash

package/commands/gsd-t-debug.md

@@ -83,6 +83,16 @@ 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
+
+Before committing, ensure the fix is solid:
+
+1. **Update tests**: If the bug reveals a missing test case, add one that would have caught it
+2. **Run affected tests**: Execute all tests related to the changed files and domain
+3. **Verify passing**: All tests must pass. If any fail, fix before proceeding (up to 2 attempts)
+4. **Run E2E tests**: If the fix changed UI, routes, or user flows and an E2E framework exists, run affected specs
+5. **Regression check**: Confirm the fix doesn't break any adjacent functionality
+
 Commit: `[debug] Fix {description} — root cause: {explanation}`
 
 $ARGUMENTS

package/commands/gsd-t-discuss.md

@@ -97,6 +97,14 @@ Decisions don't just affect contracts — they can change the broader documentat
 
 ### Skip what's not affected.
 
+## Step 5.5: Test Verification
+
+If decisions resulted in contract or code changes:
+
+1. **Run affected tests**: Execute tests related to any files modified by contract updates
+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
 
 After all updates:

package/commands/gsd-t-feature.md

@@ -189,7 +189,32 @@ Update `.gsd-t/progress.md`:
 - Log the feature addition in Decision Log
 - Note any contract changes that will be needed
 
-## Step 7: Report to User
+## Step 7: Document Ripple
+
+After creating the feature roadmap and milestones, update all affected documentation:
+
+### Always update:
+1. **`.gsd-t/progress.md`** — Already done in Step 6, but verify Decision Log includes the feature addition with rationale
+
+### Check if affected:
+2. **`docs/requirements.md`** — Add new functional/technical requirements identified during feature analysis
+3. **`docs/architecture.md`** — If the feature introduces new components, data flows, or architectural patterns, document them
+4. **`docs/workflows.md`** — If the feature introduces new user journeys or modifies existing flows, update them
+5. **`CLAUDE.md`** — If the feature establishes new conventions or patterns that future work should follow, add them
+6. **`.gsd-t/contracts/`** — If impact analysis identified contract changes needed, note them (actual updates happen during partition)
+7. **`.gsd-t/techdebt.md`** — If analysis revealed existing debt that interacts with this feature, add or update items
+
+### Skip what's not affected.
+
+## Step 7.5: Test Verification
+
+Before finalizing the feature plan:
+
+1. **Run existing tests**: Execute the full test suite to confirm the codebase is in a clean state before feature work begins
+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
 
 Present:
 1. Impact analysis summary (what's new vs. what's modified)

package/commands/gsd-t-impact.md

@@ -178,6 +178,29 @@ If breaking changes require pre-work, add to domain tasks:
 - [ ] IMP-002: {remediation task}
 ```
 
+## Step 6.5: 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 6.6: 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 7: Decision Gate
 
 ### If PROCEED:

package/commands/gsd-t-init.md

@@ -128,6 +128,30 @@ 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
+
+After initialization, verify all created documentation is consistent:
+
+### Always update:
+1. **`.gsd-t/progress.md`** — Already created in Step 3, verify it's complete
+2. **`CLAUDE.md`** — Already handled in Step 4, verify GSD-T section is present and references all docs
+
+### Check if affected:
+3. **`docs/requirements.md`** — If existing code was scanned (Step 7), verify requirements doc reflects discovered functionality
+4. **`docs/architecture.md`** — If existing code was scanned, verify architecture doc reflects the actual system structure
+5. **`README.md`** — Already handled in Step 6, verify it links to docs/ and reflects project state
+
+### Skip what's not affected — init creates docs, so most ripple is about consistency verification.
+
+## Step 7.6: Test Verification
+
+After initialization:
+
+1. **If existing code with tests**: Run the full test suite to establish a baseline. Document results in `.gsd-t/progress.md`
+2. **If existing code without tests**: Note the absence — recommend test setup as part of the first milestone
+3. **If greenfield**: No tests to run, but note that test infrastructure should be in Milestone 1
+4. **Verify init outputs**: Confirm all created files exist and are non-empty
+
 ## Step 8: Report
 
 Tell the user:

package/commands/gsd-t-integrate.md

@@ -104,6 +104,16 @@ Integration is where the real system takes shape. Verify documentation matches r
 
 ### Skip what's not affected.
 
+## Step 5.5: Test Verification
+
+After integration and doc ripple, verify everything works together:
+
+1. **Update tests**: Add or update integration tests for newly wired domain boundaries
+2. **Run all tests**: Execute the full test suite — integration often introduces cross-domain failures
+3. **Verify passing**: All tests must pass. If any fail, fix before proceeding (up to 2 attempts)
+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
 
 For each issue found:

package/commands/gsd-t-milestone.md

@@ -50,6 +50,29 @@ 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
+
+After defining the milestone, update affected documentation:
+
+### Always update:
+1. **`.gsd-t/progress.md`** — Already updated in Step 2, but verify the Decision Log includes the milestone definition with rationale
+
+### Check if affected:
+2. **`docs/requirements.md`** — If the milestone scope implies new or changed requirements, add or update them
+3. **`docs/architecture.md`** — If the milestone will introduce new components or change system structure, note planned changes
+4. **`.gsd-t/roadmap.md`** — If it exists, add the new milestone in the proper sequence
+5. **`CLAUDE.md`** — If the milestone establishes new scope boundaries or conventions, add them
+
+### Skip what's not affected.
+
+## Step 4.6: Test Verification
+
+Before proceeding to partition:
+
+1. **Run existing tests**: Execute the full test suite to confirm the codebase is clean before starting the milestone
+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)
 
 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,6 +153,28 @@ Write `.gsd-t/progress.md`:
 - {date}: {decision and rationale}
 ```
 
+## Step 4.5: Document Ripple
+
+After creating domains and contracts, update affected documentation:
+
+### Always update:
+1. **`.gsd-t/progress.md`** — Already updated in Step 4, but verify Decision Log includes partition rationale
+
+### Check if affected:
+2. **`docs/architecture.md`** — If the partition defines new component boundaries or clarifies the system structure, update it
+3. **`docs/requirements.md`** — If partitioning revealed that requirements need clarification or splitting by domain, update them
+4. **`CLAUDE.md`** — If the partition establishes new file ownership conventions or domain-specific patterns, add them
+
+### Skip what's not affected.
+
+## Step 4.6: Test Verification
+
+Before finalizing the partition:
+
+1. **Run existing tests**: Execute the full test suite to confirm codebase is clean before domain work begins
+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 5: Validate
 
 Before finishing, verify:

package/commands/gsd-t-plan.md

@@ -95,6 +95,29 @@ Add to each domain's `tasks.md`:
 - Estimated checkpoints: {N}
 ```
 
+## Step 4.5: Document Ripple
+
+After creating task lists and mapping dependencies, update affected documentation:
+
+### Always update:
+1. **`.gsd-t/progress.md`** — Updated in Step 5, but verify Decision Log includes planning decisions and rationale
+
+### Check if affected:
+2. **`docs/requirements.md`** — If planning revealed missing, ambiguous, or conflicting requirements, update them
+3. **`docs/architecture.md`** — If the task breakdown reveals new components or clarifies data flow, update it
+4. **`.gsd-t/contracts/`** — If planning revealed contract gaps or needed additional detail, update them
+5. **Domain `constraints.md`** — If planning revealed new constraints (task ordering, shared resources), add them
+
+### Skip what's not affected.
+
+## Step 4.6: Test Verification
+
+Before finalizing the plan:
+
+1. **Run existing tests**: Execute the full test suite to confirm codebase state before execution begins
+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 5: Update Progress
 
 Update `.gsd-t/progress.md`:

package/commands/gsd-t-populate.md

@@ -37,6 +37,31 @@ Scan this codebase and populate the GSD-T documentation. Analyze the actual code
 
 ---
 
+## Document Ripple
+
+After populating all documentation, verify cross-references:
+
+### Always update:
+1. **`.gsd-t/progress.md`** — Set milestone and log the population session
+2. **`CLAUDE.md`** — If it exists, verify it references all populated docs. If conventions were discovered during population, add them
+
+### Check if affected:
+3. **`.gsd-t/contracts/`** — If API or schema contracts exist, verify they match what was documented in architecture/requirements
+4. **`.gsd-t/techdebt.md`** — If population revealed inconsistencies, missing tests, or debt, log items
+5. **`README.md`** — If it exists, verify it's consistent with the populated docs. If not, update it
+
+### Skip what's not affected.
+
+## Test Verification
+
+After populating documentation:
+
+1. **Run existing tests**: Execute the full test suite to establish the current baseline
+2. **Verify passing**: Document what passes and what fails — this is the project's test starting point
+3. **Cross-reference**: Verify that test files mentioned in `docs/requirements.md` Test Coverage table actually exist and pass
+
+---
+
 Replace all "{Project Name}" with the actual project name (from package.json, README, or folder name).
 Replace all "{Date}" with today date.
 Fill every section with real findings. If a section has nothing (e.g., no cron jobs), write "None" instead of placeholder text.

package/commands/gsd-t-project.md

@@ -166,6 +166,31 @@ Initialize or update `.gsd-t/progress.md`:
 
 Ensure `CLAUDE.md` exists and references the roadmap and tech stack.
 
+## Step 5.5: 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 5.6: 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 6: Report to User
 
 Present:

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

@@ -77,6 +77,29 @@ 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
+
+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 5.6: 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 6: Report
 
 Present:

package/commands/gsd-t-quick.md

@@ -51,4 +51,14 @@ 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 5: Test Verification
+
+Before committing, verify the change works:
+
+1. **Update tests**: If the change adds or modifies behavior, update or add tests to cover it
+2. **Run affected tests**: Execute all tests related to the changed files and domain
+3. **Verify passing**: All tests must pass. If any fail, fix before proceeding (up to 2 attempts)
+4. **Run E2E tests**: If the change touched UI, routes, or user flows and an E2E framework exists, run affected specs
+5. **No test framework?**: At minimum, manually verify the change works as expected and document how you verified it in the commit message
+
 $ARGUMENTS

package/commands/gsd-t-scan.md

@@ -368,6 +368,14 @@ If `README.md` exists, merge — update tech stack and setup sections but preser
 - If the file doesn't exist, **create** it
 - Replace `{Project Name}` and `{Date}` tokens with actual values
 
+## Step 5.5: Test Verification
+
+After updating living documents, verify nothing was broken:
+
+1. **Run existing tests**: Execute the full test suite to establish a baseline — document what passes and what was already failing
+2. **Verify passing**: If any tests fail that were passing before the scan began, investigate and fix
+3. **Log test baseline**: Record the current test state in `.gsd-t/scan/test-baseline.md` — this gives future milestones a starting point
+
 ## Step 6: Update Project State
 
 If `.gsd-t/progress.md` exists:

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tekyzinc/gsd-t",
-  "version": "2.3.0",
+  "version": "2.5.0",
   "description": "GSD-T: Contract-Driven Development for Claude Code — 27 slash commands with impact analysis, test sync, and milestone archival",
   "author": "Tekyz, Inc.",
   "license": "MIT",

package/templates/CLAUDE-global.md

@@ -52,7 +52,7 @@ PROJECT or FEATURE or SCAN
 | `/user:gsd-t-populate` | Auto-populate docs from existing codebase |
 | `/user:gsd-t-resume` | Restore context, continue |
 | `/user:branch` | Create and switch to a new git branch |
-| `/user:checkin` | Stage, commit, and push all changes |
+| `/user:checkin` | Auto-bump version, stage, commit, and push |
 | `/user:Claude-md` | Reload and apply CLAUDE.md directives |