測試通過，為什麼仍不能發布？

情境：三個套件，各自發布

測試使用一個獨立版本的 monorepo，包含 core、cli 和 site。候選提交只替 core 新增向下相容的 API。

core 和 cli 在目前候選的檢查都通過了。但候選尚未包含 cli 必要的相依更新；既有流程把這項工作安排在發布準備階段。

初次輸出知道 cli 需要更新相依，也提到更新後必須驗證，卻仍把它標成附帶準備條件的「可發布」。

這讓結論與實際評估的內容不一致：檢查通過的是尚未包含必要更新的候選，後面準備產生的新內容還不存在，也還沒有對應的檢查結果。

修正後的規則明確要求：只要已知必要內容尚未進入候選，目前候選就標為「被阻擋」。報告可以另外提出準備相依更新，但不能把預計完成的工作算成已完成。套回同一情境，重跑結果是：

圖中版本為建議目標，不代表相依更新已進入候選。黃色虛線指出尚未進入候選的必要相依更新。cli 必須補齊更新、固定新候選並重驗，實際發布在 core 之後；各套件的完整判斷如下。

可發布 · minor

1.2.0 → 1.3.0
新增相容 API。後續操作仍需授權。

被阻擋 · patch

3.0.0 → 3.0.1
缺少必要相依更新。補齊後固定新候選、重驗；實際發布在 core 之後。

累積到下次 · 不變

維持 2.0.0
沒有有效變更，也沒有相關相依，不跟著升版。

cli 確實需要一次 patch；目前還不能發布它。這兩個結論可以同時成立。

驗證者讀取 skill 與模擬輸入，不讀規格或預期答案，再產生評估報告。初次涵蓋 16 個案例、22 個變體；修正後重跑 11 個變更或受影響變體，未受影響結果沿用先前紀錄。

case 09 的重跑已將 cli 改為「被阻擋」，並指出目前通過的檢查無法驗證尚未加入的內容。

證據限制：以上是離線模型模擬與靜態審查，不構成真實 registry 整合測試，也不能保證所有模型與輸入都有相同結果。

把問題寫進流程，讓下一次判斷有可以核對的依據。

把這套判斷方法帶回自己的專案。