破壞性操作的三道閘
發版時以為只改了 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「數據庫備份與回退方案」、第十章「部署與環境」。