D-20260725-06｜規則到測試的追溯制度

背景與驅動力

三域規則 ID（D-20260724-05）讓規則有了穩定名稱，但沒有 任何機制能回答「這條規則有沒有測試在驗」。共識規則的迴歸風險最高，與測試之間卻只有人腦 對應；新增共識行為時也沒有檢查點要求補測。

考慮過的選項

• 以行覆蓋率工具推算：行覆蓋不等於規則覆蓋，反而給出安全假象，棄。
• 缺測直接紅燈：上線當下覆蓋本就不足，硬閘會讓 CI 長期紅、訊號被噪音淹沒，棄。
• 測試側掛規則 ID 標註，檢查器先以報告模式上線（採納）。

決定

• 主 repo 測試檔以單行註解宣告所驗規則，括號形與 specs 主錨一致並共用同一組正規式， 讓兩側可以被同一支工具掃描。
• 對映採嚴格判準：只有「規則被違反時該斷言會失敗」才算覆蓋，寧缺勿濫。掛得多不等於 驗得好。
• 檢查器讀 specs 的 rules.json 並掃描全部測試檔：registry 不存在的 ghost ID 硬紅， 缺測只列報不紅燈——報告模式先行，是否升為硬閘待覆蓋補齊後另議。
• 與材質表比對同屬 sibling 跨 repo 本機檢查：兩個 repo 需並列於同一工作區才能執行， 不納入任一方的獨立 CI。
• 新增共識行為時須掛規則 ID 標註並確認無 ghost，寫入主 repo 貢獻指南。

後果與影響

規則與測試之間第一次有了機器可查的對應，缺測從印象變成可排程的清單。首輪即揭出兩條 互相對應的規則在實作與測試皆缺席——追溯矩陣因此也能反向暴露實作缺口，不只是測試缺口。

代價是標註為人工維護：測試改寫時若未同步調整標註，覆蓋數字會失真而檢查器不會察覺 （ghost 才紅、失效標註不紅）。嚴格判準同樣只能靠複審維持。本決策部分修訂 D-20260724-05：規則 ID 自此多一個消費端，掛號時需 一併考慮測試側是否掛得上。