論文自己寫出了推翻它的方法
這件事本身就值得放在前面。架構命題論文 §10.4 定義了它自己的強命題在什麼條件下不成立。以下全部是在一台 Windows 主機上對照那些條件實際量測的結果，好壞都報。
成立的部分
語義往返
在測過的每一種 codec 與每一種 block size 下，D(E(U)) = U 逐位元組成立。
錨點完整性
每一種組態下 H(decoded) = H(source)。
不偽裝成 UTF-8
容器正確地不能被當成純 UTF-8 解碼，符合 §8.1 的要求。
套件完整性
SHA256SUMS.txt 的 1,788 個檔案全數通過，無遺失、無不符。
測試收集
21 個模組、211 項測試，與基線文件完全一致。
在這台主機上不成立的部分
Windows 上 21 個測試模組只有 6 個通過。幾乎全部來自同一行。
_fsync_file 以 "rb" 開檔後呼叫 os.fsync。POSIX 允許對唯讀描述子執行 fsync；Windows 對應到 _commit()，需要可寫 handle，否則回 EBADF。由於 v0.10 到 v0.22 全部 import 該模組，這一行造成 14 個模組、約 125 項測試失敗。
在本機修掉之後會露出下一層 —— 暫存目錄清理時仍被持有的檔案與 mmap handle。這是一串 POSIX 假設而不是單一缺陷，也意味著這個專案目前在第二台機器上跑不完。
論文要求、但不存在的兩項量測
§10.2 的基線比對從未執行。 repo 裡沒有任何 gzip、brotli 或 zstd 的對照。本站以專案自己的 CJK 語料實測：純 brotli 達到 CR 0.0067，UTF-8X 最佳為 0.0313 —— 約小 4.7 倍。
§10.3 的隨機存取放大同樣從未被量測，而那正是這個架構真正會贏的軸。UTF-8X 刻意切成可獨立解碼的區塊，以壓縮率換取隨機存取。沒有 RA 數據，§10.4 的可證偽測試兩個方向都無法判定。這是目前最值得補上的一件事。
block size 決定一切
以 repo 內的 CJK 語料、auto profile 實測。區塊小的時候，標頭與索引成本會壓垮任何收益 —— 正是 §10.4 點名的條件。
| block size | CR | |
|---|---|---|
| 512 | 1.7061 | 比原檔大 70% |
| 4,096 | 0.2132 | 省 78.7% |
| 65,536 | 0.0323 | 省 96.8% |