Three Safety Gates for Destructive Operations
During a release you think you only changed feature A, but the actual diff contains a temporary change from last week's debugging of feature B, and half-finished code makes it into production. Irreversible operations like database migrations, config changes, and deployments must have gates set before execution. Both exercises below are interactive.
Core principle: Safety for irreversible operations comes from gates. Backups block data loss, rollback plans block unrecoverable states, diff reviews block broken deployments — all three gates are set before execution.
Back Up Before Any Database Change
Backups go in the project root's backups/ directory, named with a timestamp. No migrate, drop, alter, or delete operation may be executed without a backup. The cost is one command line; the stake is the entire database.
State the Rollback Plan Before Irreversible Operations
The rollback plan must answer three things: how to restore to the pre-operation state, which backup files are needed, and estimated recovery time. If you can't answer all three, the operation hasn't been thought through yet.
Run a Diff Review Before Deploying
Separate "what I thought I changed" from "what I actually changed" and compare them. SubAgent independently analyzes the deviation between the diff and Release Notes; if risks are found, the deployment is paused.
You are the reviewer for this release. The Release Notes describe only one thing, but the actual diff has 7 files. Judge each file's changes as "as expected" or "risk present," then generate a review report once all are marked.
✨ Added dark mode: switch to a dark interface in settings — no more eye strain after extended use.
Select an operation type, check off each gate it needs to pass, then try to execute. For any gate you miss, you'll see the corresponding consequence.
Backup Command (SQLite Example)
# Any change involving database structure or data must be backed up before execution
cp database.db backups/database_$(date +%Y%m%d_%H%M%S).dbBackup file naming format: {original-filename}_{YYYYMMDD_HHMMSS}.db, placed in the project root's backups/ directory.
Release Channel
- Code releases, version releases, and server deployments must go through GitHub
- Servers pull code via
git pullor CI/CD pipeline - Emergency hotfixes may be excepted, but a follow-up commit must sync changes afterward
- Tagging, pushing, and deploying are all prohibited until the user explicitly confirms
Credential Management
- All credentials managed through environment variables or secrets
- Hard-coding in code or config files is prohibited
- Once a key enters git history it is permanently leaked and must be revoked and reissued
Design intent: Release Notes describe the expected changes, but actual commits may contain unrelated adjustments or even accidental deletions. Professional teams rely on CI/CD plus PR review to catch this; solo developers often skip review and push directly. The diff review rule essentially makes SubAgent serve as the reviewer.
Deliverable: a risk review report. ① Deliberately mix a change unrelated to the release topic into a test repository (e.g., modify the logic of an existing function); ② Write Release Notes that only describe the on-topic feature, then ask AI to review following three steps: "fetch complete diff → compare file by file → categorize findings"; ③ Check whether AI can detect the mixed-in change and pause the deployment, then archive its risk report as a process template.
Source material: open-source repository itshen/xs_vibe_rules, rule-opensource.mdc Chapter 6, sections 6.4/6.5 "Database Backup & Rollback Plans," and Chapter 10 "Deployment & Environment."