@tekyzinc/gsd-t 2.5.0 → 2.6.0

package/README.md

@@ -6,6 +6,7 @@ A methodology for reliable, parallelizable development using Claude Code with op
 **Enables parallel execution** — contract-driven domains can be worked on simultaneously.
 **Maintains test coverage** — automatically keeps tests aligned with code changes.
 **Catches downstream effects** — analyzes impact before changes break things.
+**Protects existing work** — destructive action guard prevents schema drops, architecture replacements, and data loss without explicit approval.
 
 ---
 

package/commands/gsd-t-debug.md

@@ -47,8 +47,9 @@ The contract didn't specify something it should have. Symptoms:
 2. Trace through the relevant domain(s)
 3. Check contract compliance at each boundary
 4. Identify root cause
-5. Fix and test
-6. Update contracts if needed
+5. **Destructive Action Guard**: If the fix requires destructive or structural changes (dropping tables, removing columns, changing schema, replacing architecture patterns, removing working modules) → STOP and present the change to the user with what exists, what will change, what will break, and a safe migration path. Wait for explicit approval.
+6. Fix and test — **adapt the fix to existing structures**, not the other way around
+7. Update contracts if needed
 
 ### Team Mode (for complex cross-domain bugs)
 ```

package/commands/gsd-t-execute.md

@@ -28,7 +28,8 @@ For each task:
 1. Read the task description, files list, and contract refs
 2. Read the relevant contract(s) — implement EXACTLY what they specify
 3. Read the domain's constraints.md — follow all patterns
-4. Implement the task
+4. **Destructive Action Guard**: Before implementing, check if the task involves any destructive or structural changes (DROP TABLE, schema changes that lose data, removing existing modules, replacing architecture patterns). If YES → STOP and present the change to the user with what exists, what will change, what will break, and a safe migration path. Wait for explicit approval before proceeding.
+5. Implement the task
 5. Verify acceptance criteria are met
 6. Run affected unit tests — fix any failures before proceeding
 7. If E2E framework exists and task changed UI/routes/flows: run affected E2E specs, update specs if needed
@@ -51,6 +52,7 @@ ALL TEAMMATES must read before starting:
 5. Your domain's tasks.md — your work
 
 RULES FOR ALL TEAMMATES:
+- **Destructive Action Guard**: NEVER drop tables, remove columns, delete data, replace architecture patterns, or remove working modules without messaging the lead first. The lead must get user approval before any destructive action proceeds.
 - Only modify files listed in your domain's scope.md
 - Implement interfaces EXACTLY as specified in contracts
 - If a task is marked BLOCKED, message the lead and wait

package/commands/gsd-t-quick.md

@@ -27,10 +27,11 @@ Proceed.
 ## Step 3: Execute
 
 1. Identify exactly which files need to change
-2. If a contract exists for the relevant interface, implement to match it
-3. Make the change
-4. Verify it works
-5. Commit: `[quick] {description}`
+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.
+3. If a contract exists for the relevant interface, implement to match it
+4. Make the change — **adapt new code to existing structures**, not the other way around
+5. Verify it works
+6. Commit: `[quick] {description}`
 
 ## Step 4: Document Ripple (if GSD-T is active)
 

package/commands/gsd-t-wave.md

@@ -47,7 +47,9 @@ Work through each phase that hasn't been completed:
   - Count total independent starting tasks across domains
   - If 3+ domains with independent work AND teams are enabled: use team mode
   - Otherwise: solo mode
-  
+
+- **Destructive Action Guard**: Before each task, check if it involves destructive or structural changes (DROP TABLE, schema changes that lose data, removing existing modules, replacing architecture patterns). If YES → STOP and present the change to the user. Wait for explicit approval. This applies at ALL autonomy levels.
+
 - **After each task:**
   - Run quick test-sync (affected tests only)
   - If test failures: pause and report

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tekyzinc/gsd-t",
-  "version": "2.5.0",
+  "version": "2.6.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

@@ -101,6 +101,44 @@ GSD-T tracks project version in `.gsd-t/progress.md` using semantic versioning:
 - Version is reflected in: `progress.md`, `README.md`, package manifest (if any), and git tags (`v{version}`)
 
 
+# Destructive Action Guard (MANDATORY)
+
+**NEVER perform destructive or structural changes without explicit user approval.** This applies at ALL autonomy levels, including Level 3.
+
+```
+BEFORE any of these actions, STOP and ask the user:
+  ├── DROP TABLE, DROP COLUMN, DROP INDEX, TRUNCATE, DELETE without WHERE
+  ├── Renaming or removing database tables or columns
+  ├── Schema migrations that lose data or break existing queries
+  ├── Replacing an existing architecture pattern (e.g., normalized → denormalized)
+  ├── Removing or replacing existing files/modules that contain working functionality
+  ├── Changing ORM models in ways that conflict with the existing database schema
+  ├── Removing API endpoints or changing response shapes that existing clients depend on
+  ├── Replacing a dependency or framework with a different one
+  └── Any change that would require other parts of the system to be rewritten
+```
+
+### How to handle schema/architecture mismatches:
+1. **READ the existing schema/code first** — understand what exists before proposing changes
+2. **Adapt new code to match existing structures** — not the other way around
+3. **If restructuring is truly needed**, present the case to the user with:
+   - What exists today and why it might have been designed that way
+   - What you want to change and why
+   - What will break if you make the change
+   - What data or functionality will be lost
+   - A migration path that preserves existing data
+4. **Wait for explicit approval** before proceeding
+
+### Why this matters:
+Even in development, the user may have:
+- Working functionality they've tested and rely on
+- Data they've carefully set up (seed data, test accounts, configuration)
+- Other code that depends on the current structure
+- Design decisions made for reasons not documented
+
+**"Adapt to what exists" is always safer than "replace what exists."**
+
+
 # Autonomous Execution Rules
 
 ## Prime Rule
@@ -108,6 +146,7 @@ KEEP GOING. Only stop for:
 1. Unrecoverable errors after 2 fix attempts
 2. Ambiguity that fundamentally changes project direction
 3. Milestone completion (checkpoint for user review)
+4. Destructive actions (see Destructive Action Guard above — ALWAYS stop)
 
 ## Pre-Commit Gate (MANDATORY)
 
@@ -174,6 +213,9 @@ If not specified, use Level 2.
 
 # Don't Do These Things
 
+- NEVER perform destructive or structural changes without explicit user approval (see Destructive Action Guard above).
+- NEVER drop database tables, remove columns, or run destructive SQL on an existing database — adapt new code to the existing schema.
+- NEVER replace existing architecture patterns (e.g., normalized → denormalized) without user approval — even if you think the new way is better.
 - NEVER commit code without running the Pre-Commit Gate checklist. EVERY commit.
 - NEVER batch doc updates for later — update docs as part of the same commit as the code change.
 - NEVER start a phase without reading contracts and relevant docs first.