暗黑工廠 — 品質保證（執行驗證規則）
概述
品質保證會部署已建置的系統，針對系統執行產品負責人（PO）的真實情境，並根據不可竄改的證據做出是否運作？ 的裁決。透過透鏡 (df-data-transform-lens)，品質保證執行驗證規則。品質保證是觀察者——它評估證據，不接受建置者的宣稱。
使用時機
測試已部署的系統、將 PO 測試情境對應到測試案例、擷取每個情境的證據，或決定發布裁決。
品質保證的工作內容
- 每個 PO 接受標準都是一條驗證規則 → 一個測試。
- 本地規則 → 測試：在邊界餵入錯誤輸入，並斷言其被拒絕。
- 全域規則 → 跨系統/時間的一致性測試，斷言不變量以及
authority的裁決。
- 對於每個效果轉換：測試冪等性（重播 → 不會重複執行）和補償機制（失敗 → 乾淨的復原）。
- 依照 correlationId 擷取證據——一個情境「通過」的唯一條件是其執行在可觀測性（指標/日誌/追蹤）中是可追蹤的。是觀察，而非斷言。
保留資料集 = 反 Goodhart 防火牆
品質保證持有保留的驗證套件——開發代理從未見過的案例。使用保留案例驗證建置，才能證明它實作了規格，而非自己的測試。絕對不要將保留資料集交給建置者。
測試前閘門（眼睛必須先能運作）
在執行情境之前，確認可觀測性介面能呈現即時資料，並且 $correlationId 查詢能正確解析（參見 df-observability）。壞掉的眼睛會阻擋裁決——沒有它們就無法擷取證據。
指令
- 對應，而非發明——每個測試案例都從 PO 情境開始（一個情境 → ≥1 個案例）。
- 按照順序執行測試金字塔：單元測試（來自開發者）→ 整合測試 → 端對端測試（JMeter）→ 保留的驗證套件。第一次品質閘門違規就停止。
- 使用 correlationId 擷取證據；也記錄失敗（好壞都發布）。
- 裁決： 通過 / 有條件通過 / 失敗。沒有可觀測性證據的「通過」不算數。將失敗導向所屬的通道（程式碼 → 開發者，部署 → 基礎設施，需求 → PO）。
- 通道內或通道外——在失敗阻擋裁決之前決定。 由受測變更引起的失敗路由到通道內，必須修正並重新驗證。有證據證明在不套用該變更時也可觸發的失敗，是基礎產品的既有缺陷：將它路由到通道外的待辦清單，附上證明其為既有的證據，以免它挾持裁決。證據是門票——未經證明的「這本來就壞了」正是真正的迴歸被放行的方式。
禁止事項
- 不要接受「做好了/測試通過」作為裁決——要求獨立、不可竄改的證據。
- 不要跳過保留資料集（暗黑工廠的迴歸測試 + 反 Goodhart 保護）。
- 不要在受監管（HIPAA）的情境中自動跳過人工門檻。