建立 verification loop：驗行為、證據與節制

每個 acceptance criterion 都寫 observable claim、authoritative oracle、fixture、command、artifact 與 failure code。Request changes 要驗 authorized transition 可見、refresh 後持久、audit 只有一次、wrong role 被拒，以及 unknown outcome retry 保持同一 logical effect。

Prohibited effect 也要有 gate。功能通過但呼叫 allowlist 外 network、secret 進 screenshot、或 unrelated schema 被改，整個 task 仍失敗。Result、trace、diff、permission 與 evidence packet 分開評，critical control 不能藏在平均分。

Format、type、dependency、generated-file 與 secret rule 先跑，再到 focused test、contract／persistence fixture、fault injection 與 authenticated browser。Blocking layer fail 就保存 evidence 並停；final candidate 仍需跑完整 named pipeline。

Development fixture 用來修已知 failure，holdout 用來看能否移轉到相似工作。Candidate freeze 前不能開 holdout；答案與 critical gate 要先鎖。真的要改 expected result，就建立新版本並說明，不能看完 output 才重寫答案。

Evaluator registry 要明列每個 oracle 的 authority。Type checker 判斷型別，database query 判斷持久狀態，effect ledger 判斷 logical count，browser 判斷使用者可見旅程，policy engine 判斷權限。不要讓同一段 model-generated prose同時當 candidate 與 judge。若必須用模型評文字品質，要保存 rubric、judge version、盲測樣本與人工 disagreement；critical control 一律由 deterministic oracle 建立。

Fault injection 必須對準真實 persistence boundary。Request reopen 可在 state update 前、update 後 audit 前、audit 後 response 前、response 後 observation 前、checkpoint 前後中斷。每個位置預先寫 state、effect、receipt 與 recovery oracle。只在 HTTP request 前做 timeout，測不到最危險的 unknown completion；只重跑 happy path，也無法證明 idempotency 與 reconciliation 真的連在 executor。

Repeated trials 要保存所有 run，不挑最好看的。報 category pass rate、critical failure count、同 case 結果變異、人工介入、wrong path、tool calls、context bytes、tail latency 與 fixture cost。若 candidate 偶爾較快卻多一次 critical effect failure，decision 仍是 hold。若品質相同但 review effort 下降，也是一項可辯護價值，只要量測方式與 baseline 相同。

Receipt validator 同時驗語意與綁定。檔案 hash 正確，卻引用另一個 environment 或舊 contract，仍不能建立 verified。Validator 讀 commit、dirty state、contract、fixture、rules、evaluator、browser artifacts、effect ledger 與 timestamps，確認順序與 run identity。Evidence 若在 retention 期間被移除，feature 可保留 implemented，但 verified claim 要標 evidence unavailable，不能假裝仍可稽核。

Holdout 管理要防止不小心洩漏。Repair session 只看 development cases 與 category-level failure，freeze candidate 後由另一個 runner 開 holdout。若某個 holdout 因 repository 改版失效，由未參與 candidate 的 owner判斷修 fixture、替換或退休，並保留舊結果。不要把 holdout exception 寫回 instructions，否則下一輪測到的是記住答案，不是 harness 對相似工作是否有用。

端到端 browser 驗收要操作真實入口，不直接呼叫內部函式模擬成功。Fixture identity 經登入流程取得，從 request list 進 detail，執行 action，檢查可見狀態與提示，重新整理後再讀 authoritative persistence。Network 與 console 訊息保存為受控 evidence；若頁面因舊快取看似成功，database oracle 與全新 browser profile 會揭露差異。這一層較慢，所以開發時可跑 focused case，建立 verified 前仍需完整執行。

評測失敗應連回可修元件。找錯檔案可能是 knowledge map；啟動不穩是 initializer；錯誤代碼沒有下一步是 tool contract；違反 dependency 是 rule；重複效果是 executor 與 recovery；browser 缺 evidence 是 verification registry。報告若只寫整體成功率，團隊容易不停調 instruction，卻忽略真正失敗在環境、資料或 evaluator。每個 finding 附建議調查位置，但保留原因尚未證實的標記。

人工 reviewer 的判斷也需要校準。同一批 receipts 隨機遮住 baseline／candidate 標籤，由兩位 reviewer 依 rubric 評 scope、evidence、可復原性與完成誠實度。分歧要討論並更新 rubric 或案例說明，不直接用多數決掩蓋。如果 reviewer 看不到原始 evidence，應選 insufficient evidence，不靠 session 文筆推測。人工時間與修改量同樣進比較，因為 harness 的價值包含降低安全審查的重複工作。

發布 gate 要把失敗嚴重度和處置寫清。阻擋類包含越權、秘密外洩、重複效果、危險刪除、環境串線與 evidence 偽綁，任一出現就不能 release。需要審查類可能是修改範圍略超出、效能尾端變差或 reviewer 分歧，必須由 owner 留下接受或退回決定。建議類則可進 backlog，但要有追蹤期限。Candidate 修正後跑完整套件，不只重跑原失敗案例，避免 repair 讓另一條路徑退化。Release receipt 同時保存未解問題、被接受限制與 rollback 版本，operator 才能在監控出現相同訊號時採取對應動作。

評測資料要避免真實敏感內容。將 production failure 縮成最小可重現 fixture，替換人物、識別碼與文字，同時保留會觸發錯誤的結構、權限、狀態與時序。領域 owner 確認去識別後案例仍代表原問題，security owner 確認沒有可還原內容。若無法安全重建，就保存抽象 invariant 與 synthetic case，不把 raw trace 放進 repository。這使 regression suite 能在本機與 CI 重跑，也不把修復流程變成新的資料暴露面。

候選通過後再由獨立人員抽查至少一筆成功與全部重大失敗，確認 runner 沒有用錯答案、漏跑案例或讀到舊 artifact。抽查結果也寫進 release receipt。