jurislm 回答的問題
怎麼確認真的上線或通過了？證據怎麼算數？
副作用
可能觸發重新部署。需要人工核准時回 halted/authorization，不自行執行。
驗收對象
| 目標 repo | 驗收對象 |
|---|---|
| 有部署管道 | 監看部署到終態，確認 health check 通過（含 commit 比對） |
| 沒有部署管道（library、外掛市集、文件 repo） | 合併後預設分支的 CI 終態，且該 CI run 的 head SHA 必須等於本次的合併 commit |
沒有部署管道時不要去找一個不存在的部署來監看。
⚠️ **只看「預設分支的 CI 是綠的」不算驗收。**重查期間預設分支可能已經有別人的新 commit，
那次綠燈證明的是別人的改動。比對 head SHA 與本次合併 commit，並把該 ref 寫進
evidence[]——沒有 ref 的證據等於沒有證據。
失敗時的分工
先用 superpowers:systematic-debugging 判定根因類別，再據以回傳，一律附
recoverableByCode：
| 根因 | 終態 | recoverableByCode |
|---|---|---|
| 程式碼缺陷 | halted |
true |
| 需人工核准 | halted/authorization |
false |
| 回退目標不明或涉 migration | halted/risk |
false |
coordinator 依這個布林值決定是否回 N4，不讀 blocked.what 的文字。
回退前的三項確認
- 要退回的 commit 明確可辨識——上一個 health check 通過的 tag 或 sha，不憑印象猜。
- 本次改動是否含 migration——含的話單純退 app 層可能造成 schema 不相容，要另行評估。
- 是否需要人工核准。
三者有一不明 → halted/risk。都確認過才走該 repo 部署平台的手動重新部署。
宣稱通過之前
用 superpowers:verification-before-completion 跑實際請求、截圖或 log 佐證，看到實際
輸出才回 ok，payload 附 evidence[]。
⚠️ **證據進 evidence[] 之前先遮罩。**實際請求與 log 會夾帶 credential、token、cookie
與 shell 環境值，而 evidence[] 會被寫進 Linear 留言——那是一個比 repo 更多人看得到的
地方。遮罩後才寫入；無法確認某段輸出是否含密鑰時，記 ref 與摘要，不貼原文。