D-20260725-08｜常數表與程式常數的硬比對閘

背景與驅動力

程式參數.md 是常數的文檔權威，主 repo 的常數套件是程式權威。兩者 刻意雙手編以保留各自的表達力——文檔要分節、註解與待校準標記，程式要型別與 fail-fast 不變式——但雙手編的代價是漏改一側完全沒有訊號。

材質表.md 側早已有逐欄硬比對在守，常數表側卻只停在工作區報告階段：報告 不在任何驗證鏈上，沒人跑就等於不存在。

考慮過的選項

• 由文檔生成程式常數（或反向生成）：必然犧牲另一側的表達力，且生成器出錯就是靜默錯值， 比人工漏改更難發現，棄。
• 維持工作區報告：不在 CI 上的檢查不算防線，棄。
• 方案 C——維持雙手編，把值比對升為主 repo 硬閘、紅燈先行（採納）。

決定

• 比對器移植進主 repo 成為常數檢查，與材質表側同為 sibling 跨 repo 本機檢查：兩個 repo 需並列於同一工作區才能執行。
• 硬閘只吃「值不一致」：兩側都能對應到的常數，值不同即紅燈。
• 覆蓋缺口分三類——只在表、只在碼、無法自動比對——一律只報告不紅燈。回填是另一件工作， 不讓未完成的覆蓋率擋住已經成立的 drift 防線。
• 純公式表與 schema 欄位型的表格不納入此閘：其內容不是可逐值比對的常數，硬套只會製造 假的覆蓋缺口。

後果與影響

共用常數改動時漏改另一側，主 repo 驗證鏈立刻紅燈；文檔與程式的數值漂移自此由機器接管， 不再依賴複審抽查。

代價是覆蓋缺口仍為人工盤點，且「無法自動比對」這一類會隨表格結構演進而變動。必須明確 理解閘的語意：綠燈只代表可比對的部分一致，不代表兩側已完整對齊——把綠燈讀成「全部對齊」 會重新引入本決策要消除的那種安全假象。