@tekyzinc/gsd-t 2.19.0 → 2.19.1

package/CHANGELOG.md

@@ -2,6 +2,11 @@
 
 All notable changes to GSD-T are documented here. Updated with each release.
 
+## [2.19.1] - 2026-02-16
+
+### Changed
+- **Quick**: Now runs the FULL test suite (not just affected tests), requires comprehensive test creation for new/changed code paths including Playwright E2E, and verifies against requirements and contracts. "Quick doesn't mean skip testing."
+
 ## [2.19.0] - 2026-02-16
 
 ### Changed

package/commands/gsd-t-quick.md

@@ -52,14 +52,23 @@ 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
+## Step 5: Test & Verify (MANDATORY)
+
+Quick does not mean skip testing. Before committing:
+
+1. **Write/update tests for every new or changed code path**:
+   - Unit tests: happy path + common edge cases + error cases
+   - Playwright E2E specs (if UI/routes/flows/modes changed): create new specs for new functionality, update existing specs for changed behavior
+   - Cover all modes/flags affected by this change
+   - "No feature code without test code" applies to quick tasks too
+2. **Run the FULL test suite** — not just affected tests:
+   - All unit/integration tests
+   - Full Playwright E2E suite (if configured)
+   - Fix any failures before proceeding (up to 2 attempts)
+3. **Verify against requirements**:
+   - Does the change satisfy its intended requirement?
+   - Did the change break any existing functionality? (the full test run catches this)
+   - If a contract exists for the interface touched, does the code still match?
+4. **No test framework?**: Set one up, or at minimum manually verify and document how in the commit message
 
 $ARGUMENTS

package/package.json

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