failure-handling

Failure Handling

Consumers: /maigo:go 失敗處理段、/maigo:quick 同段、/maigo:team 同段、/maigo:address-comments step 5 都引用本 skill。

爽世擋下（NEEDS_CHANGES / BLOCKED）

1. 完整把爽世 (Soyo) 的輸出傳給愛音 (Anon)——must-fix 清單 + evidence 待補 + 具體改法
2. 愛音修完後，必須附上每條 must-fix 的對應 diff 與 evidence（不接受「都改好了」這種模糊回報）
3. 重新請爽世 review。爽世會逐條對照——任何一條沒清就維持 BLOCKED

修正輪閉環

套用任何 review 修正後，一律送回同一位 reviewer 複驗——同一個 context 才抓得到這輪 修正本身引入的新矛盾；換一個沒看過前情的 reviewer，等於失去對照歷史的能力。

1. 修到 PASS 為止——每一輪修正都可能引入新缺陷，改完就收工等於沒驗；verdict 未達 對應 command 的通過門檻前，流程不算完成。
2. reviewer 無法續用（原 agent session 已結束、必須開新 agent）時，視同重新審查： 附上完整前情——原始 diff、前幾輪 must-fix 清單、目前已套用的修正——不能只給「這是修正 後的版本」讓新 reviewer 從零判斷。

立希驗證紅

1. 把 failure 完整貼給愛音 (Anon)（command + exit code + output）
2. 愛音修完後立希 (Taki) 重跑——不接受愛音口頭說「修好了」
3. 修到全綠才算過

環境造成的假紅

測試紅燈被診斷為環境造成的假紅（Node/OS/工具版本行為差異，不是程式碼缺陷）時， 判準：乾淨環境會綠、紅的成因指向 Node/OS/工具版本而非被測程式碼本身。

優先順序：

1. 改環境設定讓它真的綠（例如 .claude/settings.local.json 的 env、正確的 flag、 對版本的工具）
2. 治本的 repo 改動（測試 setup 層的隔離），範圍合理時另開 PR
3. 最後才是遮蔽（本 repo 的 known-test-failures 機制）

Why：遮蔽名單是全檔粒度，遮掉噪音的同時把該檔案未來的真回歸一起遮掉；環境修法 沒有這個代價，還會讓別的 session 也直接受益。

不要把「加進 known-test-failures」當預設收尾動作——寫之前先問使用者，並在選項裡說明 代價；修完環境要回報「修掉幾個 / 還剩幾個」，剩下的說清楚為什麼修不掉。

Subagent 過載 / 不可用（如 529 Overloaded）

某個 agent 的 Task 因基礎設施問題（伺服器 529 Overloaded、逾時、暫時不可用）反覆啟動失敗，與該 agent 的工作品質無關時：

1. 有限次重試——重試 2-3 次。每次重試成本不低（subagent 啟動到報錯可能耗數分鐘），不要無聲地一直重撞。
2. 仍失敗 → 把選項攤給使用者，不自行決定：
   • 等久一點再試（短間隔重試只是重複燒時間；建議擱 20-30 分鐘讓尖峰過）
   • orchestrator 主線代打該 stage——繞過過載點立即解卡
   • 暫停，等基礎設施恢復後再接續
3. 使用者授權主線代打時：
   • 明示這違反該 command 的分工守則（orchestrator 本不該自己 review / 實作），且獨立性較弱（等於審 / 改自己流程的產出）
   • 嚴格度不打折——照對應 skill（如 strict-review 9 項）硬走，以 git diff / 實測為憑，不因「我自己跑」放水
   • review 類代打要實際構造場景驗證（不只讀 code 說 OK）；驗證類代打要貼真實 exit code
4. infra 恢復後，讓真人 agent 補跑一次複核——代打有真實盲點（代打者對該 repo 的慣例未必熟，且審/驗自己的產出獨立性弱）。基礎設施恢復可 spawn 時，對代打過的 stage 補跑真正的 agent 一輪；真人 agent 揪出代打漏掉的問題是常態，不是例外。