@tekyzinc/gsd-t 2.4.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-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

@@ -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)
 ```
@@ -83,6 +84,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-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-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

@@ -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)
 
@@ -51,4 +52,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/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.4.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.