Measured / not asserted
實測基準
專案裡最容易被寫得漂亮、也最容易被含糊帶過的，就是效能。這一頁把兩個專案 自己量出來的數字放在一起：每一項都由專案內的程式跑出來、寫成機器可讀的 JSON，再由本頁直接讀取渲染。所以頁面上的數字不可能跟資料檔脫節——而且裡面 包含對專案本身不利的結果，那才是量測真正的價值。
機器人路徑追蹤：前瞻距離掃描
Robotic-Navigation-and-Exploration →
這個專案原本只有一組固定參數的參考執行，而且檔案裡明白寫著「不是 benchmark」。
在訓練權重沒有隨附的情況下，唯一誠實的做法是：把其他變數全部固定，只掃描古典
基準唯一的參數——前瞻距離 Ld。
載入中…
完整數據（10 個前瞻距離 × 6 個情境）
封包分析管線：階段成本
Real-time-Packet-Monitoring… →這個專案的 README 原本明說「專案各處都沒有回報任何量測結果」。補上這件事不需要 抓任何真實流量——只量管線在它自己產生的擷取檔上的成本，就足以回答「時間花在哪」。
載入中…
完整數據（4 種擷取大小）
方法與誠實護欄
- 沿用產生正式資料的同一條程式路徑。路徑追蹤的掃描直接 import 產生已發佈資料的模組、改它的模組層參數，每一列都走完全相同的 episode 迴圈、 獎勵函式與終止條件——沒有重新實作任何一段。
-
護欄是內建的，不是事後補的。掃描刻意包含已發佈的
Ld = 30，該列逐欄與已發佈的reference.json比對， 不符就非零退出。所以「掃描沒跑歪」是被驗證的，不是被相信的。 - 只量自己的成本。封包的基準不擷取、也不量測任何網路流量； 合成封包由固定種子產生，重複多次取中位數，並把執行環境寫進同一個檔案。 絕對時間取決於機器，跨機器可轉移的是縮放趨勢。
- 不利的結果照樣發佈。路徑追蹤那張圖上，專案原本採用的設定 並不是好的工作點——這件事就寫在圖上與表格裡，沒有被藏起來。
- 這一頁不寫死任何數字。最佳點、百分比、表格內容全部從 JSON 推導。重新量測、資料變了，這一頁自己就會跟著變。