候選版本必須同時滿足 schema 有效性、遷移有效性、API 相容性、Runtime 驗收與 release policy。彼此不能互相替代，也不會被平均。
以下每一項都必須成立。它們是硬性下限與成本上限，不是權重。
因為低作用量不蘊涵高邊界正確率，高成功率也不蘊涵零誤提交。壓成單一加權數字，等於允許候選版本用安全性質去換成本改善 —— 而這正是閘門存在的目的所要拒絕的交易。
v1.0 的 release certificate 寫著 release_passed: true。以當時接線的閘門而言這是真的。不真的是：閘門根本看不見它正在背書的東西。
這是這個專案自己的命題反過來作用在自己身上，所以值得直說，而不是埋進 changelog。五項缺陷都是在 Windows 主機上實際執行發行版時發現的 —— 發行版是在 POSIX 上打包的，而這幾項在那裡要嘛看不見，要嘛在哪裡都看不見。
sandbox.py 有三處寫成 with self.connect() as c:。那是 sqlite3 的交易 context manager —— 它 commit 或 rollback，從不 close。每一次建構、put 與 get 都洩漏一個開啟的連線，外加 WAL 模式產生的 -wal 與 -shm 檔。
POSIX 允許 unlink 開啟中的檔案，所以在那裡測得過。Windows 在清理暫存目錄時拋出 WinError 32，使 v1.0 在 Windows 上實際是 70 passed／5 failed，而不是記錄的 75。這是執行期的 handle 洩漏，不只是測試環境的產物。
Finalizer 直接把寫死的 1.0 交給閘門。因此任何測試失敗都不可能擋下放行 —— 上面那五個失敗就是這樣在一張「通過」的證書底下出貨的。政策要求 test_pass_rate = 1.0，而 finalizer 用斷言把它供應了出來。
一樣寫死 1.0，但真正的量測方式一直都在：schema registry 可以驗證每一筆已遷移的證書，現在也確實這麼做了。
它把當前 manifest 拿去跟自己剛建好的第二份副本比對。那在結構上必然相容。把 ReleaseGate 從 stable 符號中刪掉、再把一個簽名改壞，它依然回報 compatible: true —— 這是實測，不是推論。現在改為與磁碟上凍結的 baseline 比對。
Path.write_text 預設 newline=None，會把 \n 轉成 os.linesep。每一個被雜湊的 artifact 都經過它，因此相同內容會依打包主機不同而產生不同摘要，一台機器產生的 SHA256SUMS.txt 在另一台會驗證失敗。對一個用摘要綁定證據的系統，這不是外觀問題。
閘門現在量測它所背書的東西：實際執行 pytest 並從 JUnit 報告讀回計數、對全部 13,600 筆已遷移證書做 registry 驗證、候選 manifest 與凍結的 v1.0 baseline 比對。Artifact 寫入固定 LF，因此在 Windows 上重新產生 schema 檔案，會與凍結的 v1.0 逐位元組相同。
每一項修補都有回歸測試，而且每一個測試都先確認過在從封存還原的 v1.0 原始程式碼上會失敗。sandbox 測試刻意使用 tempfile.TemporaryDirectory 而不是 pytest 的 tmp_path —— tmp_path 是延遲清理的，這正是 v1.0 自己的 sandbox 測試在 Windows 上通過、而四個使用 TemporaryDirectory 的 suite 卻失敗的原因。
25 個凍結的公開符號沒有變動。這一點現在是與儲存的 baseline 比對後確認的，而不是宣稱的。