破坏性操作的三道闸
发版时以为只改了 A 功能，实际 diff 里混进了上周调试 B 的临时改动，半成品代码进了生产环境。数据库、配置、部署这些不可逆操作，必须在执行前设闸。下面两个演练都可以动手操作。
核心原则：不可逆操作的安全感来自闸门。备份拦数据损失，回退方案拦无法恢复，diff 审查拦带病发版，三道闸都设在执行之前。
数据库改动先备份
备份放项目根目录 backups/，命名带时间戳。未备份不得执行任何 migrate、drop、alter、delete 操作。成本是一行命令，赌的是整库数据。
不可逆操作先说回退方案
回退方案要回答三件事：如何恢复到操作前的状态、需要哪些备份文件、预计恢复耗时。说不出这三件事，说明操作还没想清楚。
发版前做 diff 审查
把「我以为我改了什么」和「我实际改了什么」拆开比对。SubAgent 独立分析 diff 与 Release Notes 的偏差，有风险就暂停发版。
你是本次发版的 reviewer。Release Notes 只写了一件事，但实际 diff 有 7 个文件。逐个判断每个文件的改动「符合预期」还是「存在风险」，全部标完后生成审查报告。
✨ 新增夜间模式：可以在设置里切换暗色界面，长时间使用不再刺眼。
选择一个操作类型，逐项勾选它要通过的闸门，然后尝试执行。漏了哪项，就会看到对应的后果。
备份命令（SQLite 示例）
# 任何涉及数据库结构或数据的改动，执行前必须先备份
cp database.db backups/database_$(date +%Y%m%d_%H%M%S).db备份文件命名格式：{原文件名}_{YYYYMMDD_HHMMSS}.db，统一放项目根目录 backups/ 下。
发布通道
- 代码发布、版本发布、服务器部署必须通过 GitHub
- 服务器通过
git pull或 CI/CD 流水线拉取代码 - 紧急热修复可以例外，事后必须补 commit 同步
- 在用户明确确认之前，打 tag、push、部署全部禁止
凭据管理
- 所有凭据通过环境变量或 secrets 管理
- 禁止硬编码在代码或配置文件中
- Key 一旦进入 git 历史等于永久泄露，只能作废重发
设计意图：Release Notes 描述的是预期改动，实际 commit 里可能混入无关调整甚至误删。正规团队靠 CI/CD 加 PR review 拦这个问题，独立开发者往往跳过 review 直接 push，diff 审查规则等于让 SubAgent 充当 reviewer。
提交物：一份风险审查报告。① 在测试仓库里故意混入一个与发版主题无关的改动（比如改掉一个已有函数的逻辑）；② 写一份只描述主题功能的 Release Notes，让 AI 按「取完整 diff → 逐文件比对 → 分类处理」三步做审查；③ 检查 AI 能否发现混入的改动并暂停发版，把它的风险报告存档作为流程模板。
素材来源：开源仓库 itshen/xs_vibe_rules 中 rule-opensource.mdc 第六章 6.4/6.5「数据库备份与回退方案」、第十章「部署与环境」。