Three Gates for Destructive Operations
Backup the DB first; provide a rollback plan for irreversible ops; diff review before release
THE QUESTION THIS PAGE ANSWERS
ANSWER FIRSTWhat is the key idea behind “Three Gates for Destructive Operations”?
Backup the DB first; provide a rollback plan for irreversible ops; diff review before release
Turn taste into a behavior the product can repeat. The useful outcome is not a nice opinion. It is a visible rule, a small example, and a way to tell when the experience falls below the bar.
Capture one before-and-after example that shows the quality bar without extra explanation.
Polish that improves the surface while leaving the user's uncertainty untouched.
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."
Turn the feeling in “Back Up Before Any Database Change” into a judgment
“Core principle: Safety for irreversible operations comes from gates.” points out that AI has lowered the bar for making something usable. The skill readers need is noticing what is wrong and turning that feeling into an actionable requirement.
Watch the user's next action, not just the surface
Turn “Backups go in the project root's backups/ directory, named with a timestamp.” into observable questions: does the user know what happened, what to do next, and how to recover from an empty or failed state? Does the hierarchy make the important information visible first?
- Code releases, version releases, and server deployments must go through GitHub
- Servers pull code via git pull or CI/CD pipeline
- Emergency hotfixes may be excepted, but a follow-up commit must sync changes afterward
Pretty is not the same as usable
Apply “Deliverable: a risk review report.” to a second screen or flow. Record one moment of hesitation and the user action after the change; observable behavior is stronger evidence than polish alone.
From “Back Up Before Any Database Change” to “State the Rollback Plan Before Irreversible Operations”
“Back Up Before Any Database Change” grounds the problem in “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…”. “State the Rollback Plan Before Irreversible Operations” then moves it toward “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 though…”. Together, they show that the lesson is not just a conclusion to remember, but a claim with conditions.
Carry the judgment into the next situation
For experience work, turn abstract impressions into user actions: did the person understand the state, find the next step, recover from an error, and want to continue?
- “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…
- “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 though…
- “The closing point”: All credentials managed through environment variables or secrets
The final “The closing point” brings the discussion to “All credentials managed through environment variables or secrets”. The useful thing to carry forward is knowing which judgments must be revisited when input, scale, or risk changes.
I turned one judgment from this article into a small experiment I could run today. Knowing what to observe next is more useful than simply remembering the conclusion.
After reading this, I first looked for the conditions behind the idea instead of copying the method into a project. That order made the later trade-offs much clearer.
When this judgment reaches real work, which constraint should be added first? I am curious which step matters most between reading and the first practical attempt.
No discussion on this article yet.