規格檢查要機械化進 CI，不能靠紀律

規格層最大的弱點是不可證偽：散文寫錯了不會有任何東西變紅。補法不是「大家要記得檢查」，是讓 spec repo 也跑 pipeline。

可以機械化的檢查

• grep [NEEDS CLARIFICATION] 命中即 exit 1 —— 未解決的問題就是硬閘門，spec PR 不得合併
• 結構 linter：必填章節缺一即失敗（非目標／Glossary／AC／Contract／錯誤碼表／邊界例外／相依表）
• 覆蓋率交叉檢查：每條 User Story ≥1 條 Given/When/Then；每個 AC ≥1 個 contract endpoint / event；孤兒 AC 與孤兒 endpoint 都報錯
• Contract 可解析：OpenAPI 過 validator；欄位無 description、enum 沒窮舉、沒有錯誤碼表 → 失敗
• 名詞一致性：Glossary 以外的同義詞出現即警告（同一概念兩種叫法 ＝ 需求還沒收斂）
• 相依圖 DAG 檢查
• 實作端反向鎖：測試檔必須標註對應的 AC id，AC 無測試覆蓋即紅燈 → AC id 追溯鏈讓改規格的影響變成一個 grep

為什麼這件事是必要的而不是加分

「規格先行」的常見失敗不是方法錯，而是 spec 停在散文、沒落到可執行物件。三個把散文逼成可執行物的機制：

1. Contract 先行——先寫 OpenAPI / schema，寫不出欄位 ＝ 需求沒想清楚，當場暴露
2. [NEEDS CLARIFICATION] 當硬閘門
3. 驗收準則必須可執行——寫不出 Given/When/Then 的需求，就是還沒被理解的需求

補充：spec review 要有一個對抗性角色，專問「這裡失敗會怎樣」。

相關：規格的兩種洞：沉默與假具體