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