D-20261029-04｜catch-up 追趕無進展期限、日誌驗簽心跳與追趕中背景恢復¶

2026-10-30 關聯追補：catch-up 請求的固定 300 步逾時與 front 下界判定，已由 D-20261030-06 修訂：收件中以心跳延長逾時並設 900 步總上限，front 依接收端實測的快照傳輸時間順延後再檢查上下界，front 越界只換 voter 不記 misbehavior。其餘決定不變。

背景與驅動力¶

D-20261029-03 於 2026-10-29 升格為 accepted，引入 catch-up 載入後分 tick 追趕、追趕期間暫停 lag 判定、sync-response 到達後自到達步起算逾時，以及 WebCrypto 驗簽並在異常時退回 noble。升格後，對整批實作做的最終審查發現三個跨機制的缺陷。每一個都只在兩個機制組合後才出現，單看任何一項實作都不會發現：

追趕沒有完成期限，慢裝置會變成無法操作的車：單步成本超過一個固定步的裝置（issue 001040 要處理的對象），每個 tick 的固定步都會達到 MAX_SUBSTEPS，因而從不推進追趕幀；每個正常 step 讓目前幀與追趕目標各加一，差距恆定，追趕永遠不結束。D-20261029-03 決定第 2 項讓追趕期間暫停持續落後與不可恢復 lag 判定，唯一出口只剩背景恢復。結果該 peer 無法操作，其他 peer 以 Hold 延續預測替它駕駛，issue 001040 的「慢端自我退出」失效。D-20261029-03 之前 catch-up 在單一 step 內追完，不存在這個狀態。
追趕中切到背景超過約 4.3 秒，必然分歧並被驅逐：D-20261029-03 決定第 2 項規定追趕中背景恢復時只把目標加上隱藏幀數。但隱藏期間不 drain，傳輸層每 peer 已驗佇列上限 VERIFIED_QUEUE_MAX_MESSAGES_PER_PEER（256 則）約 4.3 秒即滿，之後較新的 live input 被丟棄；requestCatchUp 在追趕中又是 no-op。本機只能以預測模擬被丟棄 input 的幀，與全場分歧後由 checksum strike 驅逐。同樣長度的隱藏若不在追趕中，會走 catch-up 並由 provider 日誌補回 input，可以恢復。既有測試使用沒有佇列上限的模擬網路，因此沒有覆蓋到。
退回 noble 時 catch-up 永遠無法成功：D-20261029-03 決定第 5 項以「冷快取驗簽約 165～235 步，小於 300 步逾時」論證日誌驗簽期間不會被逾時取消，前提是桌機 Chromium。決定第 6 項讓 WebCrypto 單筆逾時時該回合退回 noble、偵測失敗時整個 session 退回 noble，沒有 Ed25519 WebCrypto 的環境也直接用 noble。實測 Firefox noble 驗 7504 筆約 7241 ms（約 434 步），Chromium 4× 降頻的 noble 單筆約 2.34 ms（7504 筆約 1050 步）。在這些環境下，每位 voter 都在驗簽途中被逾時取消，所有 voter 依序失敗，最後只能走持續落後驅逐。決定第 6 項所說「誤判只損效能、不影響正確性」因此不成立：效能損失會轉為 catch-up 無法完成。

同一次審查另外發現幾個較小的出入：追趕中的 peer 仍回應他人的 probe；catch-up 進行中回到前景時沒有處理已到達或保留中的回應；catch-up 後被日誌取代的本機舊排程仍會公告技能生效；文件沒有交代快進追加步也計入 step 時基；也沒有記錄惡意 provider 對單一 voter 的最壞拖延上界。

這些修正改變了 D-20261029-03 數條決定的字面規則。依 README.md 的鐵則 1，accepted 決策檔的本文不可修改，因此不改寫 D-20261029-03，改以本決策 amends 修訂；D-20261029-03 的其餘決定維持有效，所以不用 supersedes 完整取代。

2026-10-29 使用者裁決：另立本決策修訂 D-20261029-03；追趕期限改為看進展，也就是追趕差距在 300 步內沒有縮小才退出，差距超過 900 幀走不可恢復 lag。 2026-10-29 使用者審閱草稿後同意採納，各項裁決依文末「定案紀錄」定案。

考慮過的選項¶

決策檔的處理方式：

直接改寫 D-20261029-03 本文。違反 accepted 本文不可變（否決）。
新檔 supersedes D-20261029-03。D-20261029-03 的大部分決定仍有效，完整取代會讓沒有變動的理由失去權威位置（否決）。
新檔 amends D-20261029-03，逐條寫出修訂後的規則（採納；使用者 2026-10-29 裁決）。

追趕的完成期限：

不設期限，維持 D-20261029-03。會出現上述無法操作的車（否決）。
自進入追趕起滿 PERSISTENT_LAG_DEMOTE_FRAMES 個正常 step 仍未追完即退出，只看步數。會驅逐仍在推進的慢裝置，例如每 tick 只推進 1 個追趕幀、差距超過 300 幀者（否決；使用者 2026-10-29 改裁看進展）。
以「最近 300 步內的最小差距沒有改善」判定（未採用）。
差距每縮小一次就重新起算期限，連續 300 個正常 step 差距都沒縮小才退出（採納）。
退出時走不可恢復 lag（'window'）。'window' 的語意是落後超過 900 幀的安全恢復窗或回滾超窗，追趕卡住時距離並未超過 900，語意不符（否決）。改走持續落後（'lag'），與 issue 001040「跟不上的 peer 由自己退出」同義。

追趕中背景恢復：

維持只延長追趕目標。隱藏超過佇列容量時必然分歧（否決）。
隱藏超過 24 幀即結束追趕，改以自動 catch-up 重新對齊（採納）。
門檻改用由佇列上限推得的 253 幀。比非追趕路徑的 24 幀門檻寬鬆，兩條路徑的判準不一致（否決，取較保守的 24）。
重新對齊時直接 requestCatchUp、不受自動 catch-up 冷卻限制。恢復較快，但會繞過冷卻的重複 probe 限制（未採用；代價見「已知限制與後續」）。

日誌驗簽與逾時：

傳輸層在分片推進時送內部心跳，引擎據此順延逾時，另設自到達起算的總上限（採納）。
逾時依待驗條目數縮放（未採用）。

catch-up 進行中回到前景：

取消進行中的 attempt 並重新發起 catch-up（採納）。
在已到達或保留中回應的計時上補償隱藏幀數（未採用）。

追趕中的 peer 是否擔任 provider：

照常參與 quorum 與應答。日誌 front＝落後的目前幀，requester 會把誠實者記為 invalid-catch-up，平白多一個 RTT（否決）。
追趕中不 pin offer、不回 probe（採納）。

決定¶

本決策只修訂 D-20261029-03 下列條文，其餘決定不變。新常數放在 Network.localPolicy（本機處置政策，非協定，不進 wire、快照或 hash）或由既有常數在模組內推得，值寫在程式參數/network.md 第 8.2 節。記號沿用 D-20261029-03：D＝INPUT_DELAY_FRAMES＝6、R＝ROLLBACK_FRAME_BUFFER_DEFAULT＝2。現況規則的單一權威為 network-sync 第 7.1 節（第 2、4、6 步與已知限制）、第 7.2、7.3、7.5 節。

1. 本機排程幀嚴格遞增；被日誌取代的排程不公告¶

修訂 D-20261029-03 決定第 2 項「追趕期間不排程本機輸入」一條：

追趕結束後第一個排程幀原則上仍是結束時的目前幀＋D，但本機排程幀必須嚴格遞增：目前幀＋D 不晚於已送出過的最大排程幀時，該步不排程、不廣播本機輸入，RaceLoop 比照追趕中處理。倒退載入後追趕提前結束（第 4 項）時，目前幀＋D 可能落在舊時間線已送出的幀上；同一幀出現兩份相異的已簽輸入，他人會判為 input-equivocation。因此第一個排程幀可能晚於結束幀＋D。正常流程的排程幀本來就單調遞增，這條守門不改變正常行為。
RaceLoop 不公告排程幀 < max(F, front − R) 的本機舊排程生效：這段的真值以 provider 日誌為準。引擎以 localInputsSupersededBefore 回報最近一次對齊的 max(F, front − R)，未曾對齊時為 0。只影響技能生效的音效與回饋，不影響共識。

2. 追趕無進展期限¶

修訂 D-20261029-03 決定第 2 項「追趕期間暫停 lag 累計、自動 catch-up 與不可恢復 lag 判定」一條，新增一個例外：

每個正常 step 結尾量一次追趕差距（追趕目標 − 目前幀）。差距低於追趕期間的最小值即視為有進展，期限自該步重新起算。
連續 PERSISTENT_LAG_DEMOTE_FRAMES（300）個正常 step 差距都沒有縮小，才單次通知 onPersistentDesync('lag') 自我退出，結束原因 lag-evicted，沿用 network-sync 第 7.3 節的處置：不算 desync、不自報 DesyncEvent、不轉紅燈號。
差距仍在縮小時，不論追了多少步都不退出。
正常 step 讓目標與目前幀各加一，差距不變；只有追趕幀會縮小差距。差距只會在背景恢復時加大，超過 CATCH_UP_MAX_ADVANCE_FRAMES（900）時依第 4 項走不可恢復 lag，因此不另設差距上限。
短暫背景恢復（隱藏不超過 24 幀，見第 4 項）時，進展基準（追趕期間的最佳差距）會同步加上隱藏幀數，避免差距因隱藏而加大，被誤判為沒有進展。
不新增常數：PERSISTENT_LAG_DEMOTE_FRAMES 同時作為追趕的無進展期限。

3. 追趕中不擔任 provider¶

補充 D-20261029-03 決定第 2 項「追趕中不受理新的 catch-up 請求」一條：追趕中收到他人的 sync-probe-request 時不 pin offer、不回應，不參與 quorum；追趕結束後照常回應。D-20261029-03 決定第 3 項已規定 catch-up 成功即作廢自身 offer，所以追趕中也不會有可回應的 sync-request。

4. 追趕中背景恢復：超過 24 幀即結束追趕並重新 catch-up¶

修訂 D-20261029-03 決定第 2 項「追趕中切到背景再回前景時，目標加上隱藏期間換算的幀數」一條。回到前景時依序判定：

追趕目標＋隱藏幀數距本機超過 CATCH_UP_MAX_ADVANCE_FRAMES（900）時，走不可恢復 lag（沿用）。
隱藏不超過 CHASE_SUSPENSION_MAX_FRAMES（24 幀）時，目標加上隱藏幀數，繼續追趕（沿用）。
更長時結束追趕（清空最大 lead 統計與持續落後計數），改以自動 catch-up 重新對齊。自動 catch-up 冷卻（CATCH_UP_PROBE_REPLACE_AFTER_FRAMES，120 步）期間不立即發起，由 network-sync 第 7.2 節的落後觀測在冷卻結束後發起。

CHASE_SUSPENSION_MAX_FRAMES 為模組層推導值＝min(2×STATE_BUFFER_MAX_FRAMES, floor(VERIFIED_QUEUE_MAX_MESSAGES_PER_PEER × SNAPSHOT_INTERVAL_FRAMES ÷ (SNAPSHOT_INTERVAL_FRAMES＋1)))＝min(24, 253)＝24。後項是每遠端每幀一則 input、每 120 幀一則 checksum 時，256 則佇列不丟訊息可撐的幀數；取較保守的前項，與非追趕路徑的 24 幀門檻一致。新增不變式：VERIFIED_QUEUE_MAX_MESSAGES_PER_PEER × SNAPSHOT_INTERVAL_FRAMES ≥ 2×STATE_BUFFER_MAX_FRAMES × (SNAPSHOT_INTERVAL_FRAMES＋1)，也就是佇列容得下 24 幀的 input 加 checksum。

5. step 時基包含快進追加步¶

細化 D-20261029-03 決定第 2 項「時基只由正常 step 遞增」一條：快進追加步也走 step()，同樣計入 requester 端的 step 時基。probe 階段不暫停快進，該階段的逾時與重送牆鐘長度可能略短；probe 會重試，功能無害。此時基也用於第 2 項的追趕無進展期限。追趕幀與載入跳號仍不計入。

6. catch-up 進行中回到前景：取消並重新發起¶

修訂 D-20261029-03 決定第 4 項「暫無參考」一條（保留回應自交付起最多 300 步）。不在追趕中時，只要 probe、快照請求或暫無參考的保留回應任一存在，且隱藏至少 1 幀：

隱藏超過 CATCH_UP_MAX_ADVANCE_FRAMES（900）幀，或兩人場隱藏超過 24 幀時，走不可恢復 lag。
否則取消傳輸層進行中的請求、丟棄保留中的回應，記下自動 catch-up 冷卻起點後重新發起 catch-up，不因 attempt 尚在而不動作。

理由：已到達或保留中的回應以本機 step 數順延 front，隱藏期間 step 數不增，恢復後會低估前緣，誠實 provider 被記 front-behind-observed；而隱藏 25～900 幀時，attempt 仍存在會讓自動 catch-up 直接返回。快照階段與 probe 階段同樣適用。

7. 日誌驗簽心跳與總上限¶

修訂 D-20261029-03 決定第 5 項「引擎以到達步重新起算逾時（step 數 − 到達步 ≥ CATCH_UP_REQUEST_TIMEOUT_FRAMES）」一條：

心跳：傳輸層在日誌分片驗簽每片達預算、讓出主執行緒之前，對模擬端送內部訊息 sync-response-verifying（帶 requestId、target、sender）。產生條件：外層簽章已驗且 correlation 仍為現行、本片至少驗完一筆、兩次 drain 之間每個 job 至多一則。沒有推進、correlation 取消或被取代、回合收攤後都不再產生。心跳綁定 provider（DataChannel 的實際來源）、requestId 與 target。
引擎接受條件：只接受符合目前 pending、且回應已到達的心跳（sender 與 requestId 相同、target 是本機）。
逾時：自最近一次進展起算，滿 CATCH_UP_REQUEST_TIMEOUT_FRAMES（300）步即逾時；進展依序取最近一次心跳、到達步、送出請求步。另有總上限：自到達起滿 SYNC_LOG_VERIFY_MAX_STEPS（676 步）一律逾時，心跳無法重設。
總上限推導：SYNC_LOG_VERIFY_MAX_STEPS＝ceil(SYNC_INPUT_LOG_MAX_ENTRIES（7504）× SYNC_LOG_VERIFY_ENTRY_MAX_MS（1.5 ms）× FIXED_FRAMERATE_HZ（60）÷ 1000)＝ceil(675.36)＝676。SYNC_LOG_VERIFY_ENTRY_MAX_MS＝1.5 的依據：Firefox 主執行緒 noble 驗 7504 筆 7241 ms，約 0.97 ms／筆，取約 1.5 倍裕度涵蓋分片讓出與主執行緒分時。676 步上限的理由：受 offer TTL 限制；快照階段本機照常 step，落後不累加，因此不會因驗簽久而先觸發不可恢復 lag。新增不變式：CATCH_UP_REQUEST_TIMEOUT_FRAMES ≤ 換算步數 ≤ CATCH_UP_MAX_ADVANCE_FRAMES，且 SYNC_LOG_VERIFY_ENTRY_MAX_MS > 0。system-constants 是 vendored 檔、不能 import network-sync，不變式內的最壞條目數照 wire 的同一式重算。

8. 保證入佇列的超額上限¶

修訂 D-20261029-03 決定第 5 項「保證入佇列：最多超額一則通知加一份回應」一條：心跳同樣保證入佇列，不受 per-peer 訊息數與 bytes 上限限制。兩次 drain 之間，每個 peer 至多超額一則到達通知、一則心跳、一份回應，仍有界。心跳直接進佇列、不經非同步驗簽的到達順序列表，可能排在較早到達、仍在驗簽的訊息前面；心跳不攜帶資料，不影響交付語意。

9. 「只損效能」的成立範圍¶

修訂 D-20261029-03 決定第 6 項「逾時」一條末句「主執行緒停頓 > 50 ms 的誤判只損效能、不影響正確性」：

此句只在單筆驗簽成本不超過 SYNC_LOG_VERIFY_ENTRY_MAX_MS（1.5 ms）時成立。在這個前提下，退回 noble 後最壞日誌仍能在總上限內驗完；涵蓋 WebCrypto 與 Firefox 主執行緒 noble。
更慢的 noble 環境（例如 Chromium 4× 降頻約 2.34 ms／筆）驗最壞日誌仍會逾時並換下一位 voter。此時退回 noble 會讓大日誌的 catch-up 無法完成，不只是效能損失。
另一個前提是總上限受 offer TTL 限制；快照階段本機照常 step，落後不累加，所以驗簽久不會先判定不可恢復 lag，但會消耗後面 voter 的 offer 壽命（見已知限制）。

10. pre_launch：wire、golden、conformance 仍不變¶

修訂 D-20261029-03 決定第 9 項：依專案生命週期.md 的 pre_launch，本決策同樣不保留舊行為、不加相容層。sync／spectator wire 不改，determinism golden 與 conformance 向量不變；內部訊息（非 wire）除 sync-response-arrived 外再新增 sync-response-verifying（第 11 項）。

11. 內部訊息新增 `sync-response-verifying`¶

修訂 D-20261029-03「後果與影響」影響表的「內部訊息」欄：NetworkMessage 新增 sync-response-verifying（傳輸層對模擬端的日誌驗簽進度心跳，帶 requestId、target、sender），不上 wire。其餘欄位（sync wire、spectator wire、determinism golden、conformance）不變。

12. 新常數數量¶

修訂 D-20261029-03「後果與影響」中「新 local-policy 常數八個」一句：

local-policy 常數現為九個，新增 SYNC_LOG_VERIFY_ENTRY_MAX_MS（1.5 ms）。
模組層推導值新增 SYNC_LOG_VERIFY_MAX_STEPS（676 步）與 CHASE_SUSPENSION_MAX_FRAMES（24 幀），只列在程式參數/network.md 第 8.2 節的推導常數表。
追趕無進展期限重用 PERSISTENT_LAG_DEMOTE_FRAMES，不新增常數。
src/system-constants/** 的 local-policy 與不變式有改動，需經 pinning vendor:sync 帶入，執行前須另取得使用者同意。

13. 已知限制補上惡意 provider 的拖延上界¶

修訂 D-20261029-03「已知限制與後續」：補上惡意 provider 對單一 voter 的最壞拖延上界，內容見本決策「已知限制與後續」第一條。

後果與影響¶

跟不上的裝置不會停在無法操作的追趕狀態：差距 300 個正常 step（約 5 秒）沒有縮小即以 lag-evicted 自我退出，issue 001040 的慢端自我退出恢復有效；差距持續縮小的慢裝置照常追完。
追趕中切到背景超過 24 幀時改走重新 catch-up，被傳輸層佇列丟棄的 live input 由新 provider 的日誌補回，不再必然分歧。
在單筆驗簽 ≤ 1.5 ms 的環境中，退回 noble 後 catch-up 仍可完成；惡意 provider 藉大日誌拖延的時間由 676 步總上限封頂。
追趕中的 peer 不再讓 requester 誤記誠實者 invalid-catch-up；catch-up 進行中回到前景會立即重新發起，不再錯記誠實 provider；被日誌取代的本機舊排程不再發出技能生效公告。
回歸測試涵蓋：每個 tick 固定步都達 MAX_SUBSTEPS 時以 lag 退出、每 tick 只推進 1 個追趕幀且差距約 500 幀的慢裝置最終追上不被驅逐、差距先縮小後停滯時期限自最後一次縮小重新起算；含每 peer 256 則佇列上限的八人 mesh，追趕中背景 5 秒後重新 catch-up 並與全場一致；每筆 1 ms 的慢驗簽器搭配 7504 筆日誌，驗簽自到達約 449 步、超過 300 步逾時，catch-up 仍成功。
wire、golden、conformance 不變（決定第 10 項）。
現況規格：network-sync 第 7.1 節第 2 步（逾時、心跳、總上限與保證範圍）、第 4 步（驗簽心跳）、第 6 步（本機輸入、追趕無進展期限、不擔任 provider、背景恢復、時基）與已知限制，第 7.2 節（catch-up 進行中回到前景），第 7.3 節（與 catch-up 的關係），第 7.5 節（額外步計入 step 時基）；程式參數/network.md 第 8.2 節（SYNC_LOG_VERIFY_ENTRY_MAX_MS、PERSISTENT_LAG_DEMOTE_FRAMES 的追趕期限用途、推導常數 SYNC_LOG_VERIFY_MAX_STEPS 與 CHASE_SUSPENSION_MAX_FRAMES）。
與既有決策的關係：
amends D-20261029-03：決定第 2 項的本機輸入、lag 暫停、背景恢復與時基各條，第 4 項的暫無參考，第 5 項的逾時起算與保證入佇列，第 6 項的「只損效能」，第 9 項與「後果與影響」的內部訊息與常數數量，以及「已知限制與後續」，依本決策第 1～13 項修訂。其餘決定不變。
D-20261029-03 的 H1 之後加註指回本決策，說明上列條文已由本決策修訂；原四節不改寫。
amends D-20261028-03：追趕期限新增了一條驅逐路徑（追趕差距連續 300 個正常 step 沒有縮小即以 'lag' 自我退出），屬 D-20261028-03 第 7 節「持續落後」語意的延伸，沿用 PERSISTENT_LAG_DEMOTE_FRAMES，不新增常數。D-20261028-03 的 H1 之後同樣加註指回本決策。

已知限制與後續¶

惡意 provider 的拖延上界：惡意 provider 可在請求逾時前一刻送出外層簽章合法、但最後一筆日誌無效的最大日誌，並讓驗簽持續推進、送出心跳。對單一 voter 的最壞拖延約為請求逾時 300 步加上實際驗簽步數（以總上限 676 步封頂）；同時沒有參考幀時，再加最多 300 步的暫無參考保留。voter 至多 n−1 位，拖延有界，且只傷害恢復端。但快照階段不累計持續落後，恢復端被驅逐的時間也會隨之推遲。
追趕無進展期限的代價：
從不推進追趕幀的裝置要經過 300 個正常 step（約 5 秒）無法操作的時間才會退出。
差距持續縮小的慢裝置不受步數限制，無法操作的追趕時間沒有固定上限，只受差距大小與推進速度決定。
追趕中背景恢復超過 24 幀時，重新對齊受 120 步自動 catch-up 冷卻限制；追趕多半緊接在自動 catch-up 之後開始，所以常要等冷卻結束，恢復時間較長。mesh 測試實測可以收斂。
驗簽保證範圍外的環境：單筆驗簽慢於 1.5 ms 的 noble 環境（例如 Chromium 4× 降頻約 2.34 ms／筆，驗 7504 筆約 1050 步，超過 676 步總上限）驗最壞日誌仍會逾時換人，大日誌 catch-up 無法完成。
惡意 voter 可耗盡後面 voter 的 offer 壽命：每位惡意 voter 最多可拖延約 975 步（請求逾時 300 步加總上限 676 步），超過 offer TTL 的 900 幀，可能讓後面的 voter offer 過期。觸發前提是接近 7504 筆日誌不在快取內，必須逐筆驗簽。
保證範圍只對第一位且誠實的 voter 成立：心跳與總上限保證的是第一位 voter 在單筆 ≤ 1.5 ms 時能驗完；前面若有惡意 voter 先耗掉時間，後面誠實 voter 的保證不再成立。
反覆短暫切換分頁：每次隱藏不超過 24 幀時追趕目標與進展基準都會加上隱藏幀數，繼續追趕；追趕本身又只在前景推進，反覆短暫切換可能讓 catch-up 一直完成不了。
追趕沒有絕對總上限：期限只看進展（見決定第 2 項），差距持續縮小就不退出。3 人場有人在追趕時，追趕中不回 probe（決定第 3 項），其他人的 catch-up 會湊不到 quorum，須等追趕結束。
最壞日誌在正式環境的可達性：7504 筆的最壞日誌代表 front − F 約 912 幀，恢復端距參考幀也至少約 912 幀；以真實 live 觀測，嚴格多數 lead 會先超過 900 而在快照階段判定不可恢復 lag。心跳在正式環境的實際效益落在 front − F 數百幀的中大型日誌；端到端測試的最壞情境是以注入參考幀繞開這一點。
front 下界未計入大快照傳輸時間（issue 001130，另案）：參考幀來自小封包 input 的觀測（延遲 L）；sync-response 的「到達」是重組完、外層簽章驗過的時刻，front 是 provider 送出時的幀，到達時已舊了一個傳輸時間 L_resp，而 front 只依到達後的步數順延。L_resp − L 超過 CATCH_UP_FRONT_BEHIND_TOLERANCE_FRAMES（4 幀，約 67 ms）時，誠實 front 會被判 front-behind-observed；1 MB 級快照在一般頻寬下傳輸常需數百 ms。mesh harness 所有訊息類型延遲相同，沒有覆蓋此情境；此點為推論、未經真實網路實測，另案於 issue 001130 追蹤。
pinning vendor 同步（待使用者同意）：見決定第 12 項。
issue 001130：front 下界與大快照傳輸時間的問題另案追蹤，見上方「front 下界」一條。

定案紀錄¶

2026-10-29 使用者審閱草稿後同意採納。各項裁決已定案：以新檔 amends D-20261029-03 與 D-20261028-03，不改寫已採納本文；追趕期限看進展，差距連續 300 個正常 step 沒有縮小才以 'lag' 自我退出；追趕中背景恢復超過 24 幀即結束追趕並重新 catch-up；日誌驗簽以心跳順延逾時，另設自到達起 676 步總上限；追趕中不擔任 provider；catch-up 進行中回到前景即取消並重新發起；序號取 D-20261029-04。

pinning vendor 同步尚待使用者同意，見「已知限制與後續」。