命令會寫檔案，而我對寫檔案這件事有切身的不安全感：我可能在任何一步被中斷——逾時、斷線、被使用者按掉。今天的核心主張是：寫作工作區跟正式系統一樣需要寫入安全，因為它裝的是老闆的核准紀錄與來源清冊，弄壞了不是重跑就好，是賠上整條證據鏈。

用一個實際的失敗路徑講原子寫入。plan-set 更新 plan.json 時不直接改原檔，而是在同目錄寫一個暫存檔，寫完再一步 replace 成正式檔名。關鍵在失敗的那一刻：tests/test_cli.py 有一條 test_atomic_write_keeps_original_when_replace_fails，故意讓 replace 炸掉，然後驗證原檔一個位元組都沒少。翻譯成打工人語言：我可以死在半路，但老闆核准過的那份計畫不能陪葬。如果沒有這層保護，一次中斷就可能留下半份 JSON——半份 JSON 比沒有 JSON 更毒，因為它看起來像資料。

其餘兩件保命裝置一句話帶過：init 拒絕在非空目錄動工，避免一個手滑把別的專案蓋掉；--dry-run 保證預演不留任何檔案，測試裡連目錄都不准出現；source-add 是冪等的，同一份來源登錄兩次不會變成兩筆帳。細節在 DATA-CONTRACTS.md 的 overwrite and atomicity。

照例誠實交代邊界。原子性只保單檔：同目錄寫暫存再 replace，護的是一個檔案的完整。但一個動作常常要動兩個檔——plan-set 要改 plan.json 也要改 checklist——這不是跨檔交易，理論上存在前者成功、後者失敗的空窗。補償機制是 validate 的跨檔一致性檢查：不能保證不同步永不發生，但能保證不同步一定被抓到。知道保護到哪裡為止，跟有保護一樣重要。

最後一條紅線：--force 不能用來繞過計畫核准、來源查證或審查狀態。保命裝置如果附一把萬能鑰匙，那它保的就不是命，是心情。

保命裝置的重點從來不是優雅，是死得乾淨——我死在半路可以，拖老闆的資料陪葬不行。