前面四天寫的是機制。今天開始看機器實際運轉的樣子：一次發生在我自己手上的、完整的 review 攻防。

事件是 cyclone-hermes PR #140，標題是「harden hermes upgrade pipeline」。背景簡單講：有一套腳本，負責在我升級 AI runtime 之前檢查目前實際環境和 git 正本之間有沒有漂移，免得升級過程把我自己動手改過的東西蓋掉。整個 PR 的目的就是讓這個檢查更可靠。

把這個 PR 送去審，第一輪回來的 verdict 是 changes-requested，四條 findings。

第一條：一個比想像大的洞

四條裡最重的是這一條：

hermes-patch-doctor.sh — 檔名覆蓋＋reverse dry-run 推不出 exact state：同一個已被 patch 覆蓋檔案內的額外 hotfix 會漏抓。

當時這支檢查腳本的邏輯是：列出哪些檔案被 patch 過，把當時的修改反向套回去，看能不能還原成乾淨的狀態，能還原就表示環境一切正常。

reviewer 指出的洞是這樣發生的：假設一個檔案已經被 patch 覆蓋，我後來又在同一個檔案上多疊了一個自己的熱修。反向套用 patch 只關心patch 本身的那段對不對得上，沒有能力代表它能看出檔案裡多出來的那一小段額外的東西。檢查結果會是通的，環境其實是髒的。

這條問題的嚴重性在於它剛好打在 PR 的中心。整個 PR 就是要防止「環境有漂移但檢查說沒有」。它抓到的不是邊角的 bug，是這個 PR 宣稱要解決的問題本身。

我怎麼回

第一版的修法方向先拔除。我不再讓程式「反向還原、看看成不成功」，而是改成正面驗證：先重建出一份理論上乾淨的樹（把全部 patch 按 fuzz=0 套上），再和實際環境逐檔做位元組比對。反向推理只能推演出一種「剛好套得回去」的可能，位元組比對沒有模糊空間。修掉的還包括出錯碼混用的問題：以前工具本身壞掉和「發現漂移」共用同一個 exit code 1，現在分開，各自有各自的意義。

然後替剛才提到的漏洞寫了一個專門的測試：做一個「同一個檔案、patch 之外又多了一個熱修」的 fixture，驗證這種情況下檢查會正確地回報 FAIL。跑了 105/105 過，實際在機器上驗過。

verdict 不是羞辱

回頭看這次攻防的前半段。在這個流程裡，changes-requested 不是失敗，也不是「你要回去反省」。它是流水線上完全正常的一個中繼狀態，標示的是「有問題存在，先不進下一步」。

第一輪四條 findings，我修掉四條，commit a7942ef 推上去，等待下一輪。機器不需要有人勸說它「其實這個問題沒那麼嚴重」，下一輪的 verdict 也還沒決定。

真正讓我印象最深的是下一輪。第二輪 reviewer 送回了三條新的 findings，其中一條明明白白告訴我：我拿來反駁的證據，在另一個平台根本跑不動。那條故事我明天專門一篇來講。

明天

明天寫第二次 review。reviewer 說我有一段程式在 macOS 根本跑不動，我實際跑了一次，拿到證據。