title

CWSR Paper 02｜因果觸發、執行休眠與條件喚醒機制

english_title

Causal Triggers, Execution Dormancy, and Conditional Wake-Up: Obligation-Preserving Scheduling for World-State Runtimes

series

CWSR — Causal World-State Runtime

paper

02 / 08

version

v0.1

date

2026-10-16

author

Neo.K

ai_research_collaborator

Aletheia / GPT-6

institution

EveMissLab / 一言諾科技有限公司

status

Research Draft — Engineering Extension / Not an Independent Foundational Theory

canonical_source

UTF-8 Markdown; mathematical delimiters $...$ and $$...$$ only

language

zh-TW

predecessor

CWSR Paper 01 v0.1

next_paper

CWSR Paper 03 — 宏觀—中觀—微觀多尺度世界模擬

CWSR Paper 02｜因果觸發、執行休眠與條件喚醒機制

從世界狀態義務到不漏事件的選擇性執行、期限治理與安全回退

English: Causal Triggers, Execution Dormancy, and Conditional Wake-Up: Obligation-Preserving Scheduling for World-State Runtimes
系列位置： CWSR Paper 02 / 08；承接 Paper 00 的系列總綱與 Paper 01 的世界狀態、依賴、時間及候選提交契約。
研究性質： 對既有事件驅動、增量計算、計時器排程、物理休眠與工作佇列的整合性工程延伸；不聲稱發明上述技術，也不宣稱所有遊戲適合因果喚醒。
本篇交付： 觸發／休眠／喚醒契約、不可漏喚醒協定、時間義務保全、最小參考演算法、反例與驗證計畫。
未交付： 可運行 Rust 原型、Godot Adapter、CPU／GPU 基準測量、跨尺度聚合演算法；它們由 Paper 03–08 分別承擔。

作者： Neo.K
機構： EveMissLab / 一言諾科技有限公司
日期： 2026-10-16
版本： v0.1

摘要

單機遊戲的持續執行與世界因果進展並非一回事。畫面可維持不動，而底層主循環、輪詢、快取檢查、AI 更新、物理積分或記憶體搬移仍持續發生；反過來，畫面不動也不能推出世界時間、任務期限、隨機事件或不可見區域的狀態可被凍結。CWSR Paper 01 已將「邏輯世界」、「必要義務」、「活動工作」、「實際執行」及「權威提交」分離；本篇的核心問題因此變成：能否在不丟失任何規則級因果、時間、觀察與恢復義務的前提下，使部分工作進入可證明安全的等待／休眠狀態，並且只在有充分理由時喚醒？

本文提出 Obligation-Preserving Conditional Wake-up（義務保全的條件喚醒） 作為 CWSR 局部 Runtime 的設計目標。計算工作被視為具有明確 read/write/guard/clock/authority/precision 依賴的工作單元，喚醒可以來自已提交世界修訂、規則級依賴失效、模擬／單調時鐘期限、觀察需求、持續更新契約或恢復事件。當某工作進入休眠時，系統仍保留其版本／依賴訂閱、負向查詢或集合索引、期限、事件去重鍵與已承諾的完成要求；休眠的是不必要的實際計算，不是世界責任。

本文特別處理易使事件驅動優化失效的六類邊界：動態依賴與不存在條件、訂閱建立與提交之間的競態、跨時間窗或跳時漏結算、循環／高扇出因果傳播、候選結果過期提交，以及工作過量造成的期限違約。本文提出保守回退、度量調度額外成本、混合固定步進與事件化工作的必要性；將預測性因果前沿限制於預熱與準備，不得代替權威的必需觸發。

本篇結果是一套可由 Paper 07 實作、由 Paper 08 證偽的執行協定與測試規格。其效能假說只適用於可完整追蹤依賴、具有足夠低的有效變化率，且索引／排程成本低於被省略工作量的局部負載；不構成普遍最佳化定理。

關鍵詞： CWSR、Causal Trigger、Dormancy、Conditional Wake-up、Necessary Obligation、Subscription Barrier、Missed Wake-up、Dynamic Dependency、Time Contract、Deadline、Dirty Propagation、Event Log、Causal Frontier、Fallback、Game Runtime。

0. 研究定位與不能突破的邊界

0.1 本篇不是重新定義計算本體

GCM、GCCF、GCCFT 與 GCCWT 已處理全域計算、依賴、資源激發與異質執行的不同抽象層。本篇只選取一個明確子問題：在一個權威的單機模擬世界中，何時合法安排、跳過、延後或重新啟動一個可辨識的工作單元？

單機不代表沒有並行、不代表沒有非決定性排程，也不代表所有輸入與副作用都可忽略。Paper 02 將固定步進、輪詢、持續更新、事件驅動、期限驅動及混合執行全部視為可合法選擇的局部策略。

0.2 舊理論的必要承接與不可偷換

0.3 本篇的研究問題

1. 哪些事件構成不可省略的合法喚醒？
2. 如何讓工作休眠，而不失去動態依賴、負向查詢和時間到期通知？
3. 如何避免在「檢查有效性」與「註冊監看」的時間縫隙漏掉事件？
4. 如何在不可定量保證成本的循環、高扇出及高頻世界中保守回退？
5. 如何證明省略計算只影響成本，而不改變合約要求的世界行為？
6. 為什麼這些機制在某些負載上應被關閉，以避免治理成本反而高於原計算？

1. Paper 01 的固定記號與本篇操作性增量

1.1 邏輯世界與工作單元

沿用已定義的 CWSR 遊戲世界表示：

其內容分別是世界節點、規則依賴、狀態描述符、時間義務、歷史及規則／觀察語境；不代表所有狀態值已經同時駐留 RAM 或 VRAM。

令 $Q_t$ 為經型別區分的可執行工作單元集合， $A_t$ 為整體活動域，沿用 Paper 01：

注意： $A_t^Q$ 是取得目前執行階段排程資格的工作投影； $R_t^{\mathrm{run}}\subseteq A_t^Q$ 才是實際執行集合。工作即使不在 $A_t^Q$，其狀態、訂閱與義務記錄仍可存在。

1.2 必要義務集合

Paper 01 已定義候選必要義務：

• $D_t$：已提交變更或經確認的失效源。
• $C_t^Q(D_t)$：規則因果依賴閉包在工作集合上的型別化投影。
• $U_t^{\mathrm{due}}$：時間已到的義務。
• $U_t^{\mathrm{continuous}}$：規則要求持續更新的工作。
• $U_t^{\mathrm{demand}}$：觀察、查詢或物化新需求。
• $U_t^{\mathrm{repair}}$：恢復、重試或重新驗證。

本篇把外部輸入、玩家操作、資源通知等作為 $D_t$ 或上述各類集合的生成來源；不擅自增加一個與 Paper 01 衝突的同名定義。尚未提交的 speculative result 不得冒充 $D_t$ 的權威來源。

令 $P_t\subseteq Q_t$ 表示可合法延後的待辦義務集合，則最低保全條件為：

這個包含關係只是不遺失工作身份的必要條件，不足以保證按期完成。本篇將另加入期限與可持久化通知的要求。

1.3 有效性與執行資格分離

沿用 Paper 01 的五項有效重用條件：

ReuseOK 是可跳過重新計算的必要綜合判定，不是判斷「沒有任何因果事件」的替代函數；比如事件日誌和世界計時器仍可能需要記錄或更新。

本文新增：

• Wake Source：喚醒來源的可識別標記。
• Wake Contract：可檢查的監看、時間、期限、依賴與交付契約。
• Wake Ticket：單次或合併後的執行義務票據。
• Dormancy Certificate：准許進入休眠及恢復的證據。
• Subscription Barrier：建立監看與快照檢查之間的防漏協定。
• Fallback State：依賴不完整或排程不可行時使用的保守更新模式。

以上是 CWSR 本篇的工作性工程術語，不是 GCM 或 GCCF 原有公理。

2. 什麼是觸發？不能把所有訊號混成一種

2.1 事件、失效、義務與喚醒的四重區分

同一次遊戲行為可以產生多種不同層級的記錄：

1. Event： 可追蹤的發生事實或請求，例如玩家換裝、計時器達期限、道路關閉。
2. Invalidation： 已提交事件使某派生結果的有效性證據失效，或必須重新檢查。
3. Obligation： 按規則應完成的更新、查詢、重建或副作用。
4. Wake Ticket： 排程系統為相應工作建立的可去重、可重試執行要求。

事件可以無需觸發任何重新計算；某一事件也可能產生大量義務。失效有時只要求驗證一次依賴指紋，而不必真的重新執行完整函數。喚醒、執行、完成與提交不得視為同一個狀態轉移。

2.2 六類必要或候選喚醒來源

外部事件在沒有通過世界授權與規則前，不能直接將依賴提示升格為權威世界變更；但相關輸入也不能在處理前無故丟棄。

2.3 只有預測價值、沒有強制喚醒權的來源

GCCF 05 的因果前沿與預記載可為未來工作建立 Prepare Ticket：提前解析資產、暖化索引、編譯 kernel、保留有限記憶體或生成可撤銷候選結果。但：

同樣，機器學習預測未來會有交通堵塞，不足以讓目前世界直接提交道路封閉。預測可協助安排資源，不可創造無根據的因果事實。

2.4 觸發身份與語義去重

實作上，Wake Ticket 至少攜帶：

ticket_id、work_id、source_event_ids、cause_kind、world_revision、dependency_epoch、time_domain、not_before、deadline、coalescing_policy、authority_scope。

不能僅以 work_id 為鍵無條件合併所有事件。兩個必須個別發生的交易或事件效果，即使交給同一個工作處理，也不能被折疊成一次不可辨別的通知。

3. 休眠不是不存在：工作生命週期與有效性是兩個軸

3.1 工作生命週期狀態

提出以下有限狀態集合作為參考 Runtime 的候選：

PENDING 不應直接等於 READY；例如到期但資料未物化、世界區域鎖尚未解除，仍可先記為 Pending，並保存其期限。DORMANT 也不代表有權遺忘該工作。

3.2 生命週期不等於資料有效性

工作可能處於 DORMANT，但上次結果已失效，因目前沒有觀察需求且允許延後。工作也可能處於 RUNNING，卻因輸入版本變更而不能提交。為避免混淆，須將下列狀態作正交描述：

• 生命週期：等待、執行、待提交等。
• 結果有效性：valid、invalid、unknown、provisionally_valid。
• 物化／駐留：位於 RAM、VRAM、儲存、可重建或尚未載入。
• 權威：觀察、建議、執行及修改權限。
• 時間：未到期、到期、逾期、無合法期限。

在某些規則要求「狀態改變後必須立即修訂」的系統中，invalid + dormant 不合法；在只需被查詢時重新計算的純派生數據中則可能合法。合法性由 Wake Contract 決定。

3.3 Dormancy Certificate

允許工作 $q$ 進入休眠的證書可採：

• $\sigma_q$：已核對的依賴指紋，含動態集合／守衛版本。
• $\mathcal W_q$：有效的監看集合與建立屏障位置。
• $\tau_q$：下一個時間義務或可證明無此期限的憑據。
• $\pi_q$：允許延後、合併與休眠的規則政策。
• $\rho_q$：修復與回退方案。
• $\epsilon_q$：觀察誤差、時效與事件效果界限。

DORMANT 成立的最低條件：不存在現在必須立刻處理且未保留的義務，所有必要通知與期限可被可靠追蹤，並保留合法恢復途徑。缺少依賴證據時，不得用「目前看起來沒事」替代證書。

3.4 休眠與作業系統真的休息是兩件事

遊戲工作進入 DORMANT 不必然使 CPU 使用率下降：若引擎仍每幀遍歷所有 dormant 標記、所有工作仍有 busy-wait，或者音訊、視窗、渲染與 OS 其他工作仍活躍，實際耗電未必下降。

因此本篇評估的是遊戲世界工作級的免重算與可喚醒語義；Paper 08 才能另量測 CPU cycles、OS wake-ups、忙等、GPU dispatch 與耗電的真實變化。

4. Wake Contract：哪個變化有權重新啟動哪個工作？

4.1 最小契約的型別化描述

對每個工作 $q$，本篇提出：

依序為：

• $id$：工作身份與所屬世界／域。
• $R_q$：規則級 Read Set、依賴集合與動態查詢依賴。
• $W_q$：可合法變更的狀態身份集合，不表示已取得修改權限。
• $G_q$：Guard／Predicate、否定條件與集合範圍。
• $C_q$：模擬、單調或其他指定時間座標及到期條件。
• $\Omega_q$：觀察新鮮度、精度、即時性與完整歷史要求。
• $L_q$：工作生命周期中的允許休眠、延後、合併、取消策略。
• $S_q$：隨機性、副作用及重播／去重政策。
• $B_q$：資源上限、回退模式、錯誤處置與證據保留方式。

此 tuple 是 Paper 02 的工作性定義；其中部分欄位只是對 Paper 01 WorkContract 的細化，不要求在編譯器或遊戲語言層一次性強制所有工作具有完整宣告。宣告不完整時可選擇固定更新或經驗證的成熟引擎機制，不能自行推斷其已安全可休眠。

4.2 不應用「版本不變」等同「結果不變」

DependencyStamp 需涵蓋與結果有效性相關的：

1. 上次合法讀取的資料版本。
2. 世界規則與算子版本。
3. Guard／Predicate 及集合索引的版本。
4. 時間窗與時間座標。
5. 隨機來源或事件定位。
6. 精度與觀察契約版本。
7. 計算模式切換後可能改變的數值／舍入語義。

若版本相同且宣告齊全，可以嘗試重用；若值恰巧相同但依賴版本已變，應先證明該改變對本次輸出無效，不能一律直接沿用。

4.3 Wake Predicate 的兩類責任

定義兩種彼此區別的判定：

Inspect=1 表示事件值得重新檢查工作有效性或其依賴；MustExecute=1 表示契約確定要求執行、補做事件或完成副作用。前者成立不必然推出後者，例如：一個上游狀態版本變了，但有經驗證的局部證明顯示結果仍在容許誤差內；可以更新有效性憑據，而不是重做整個工作。

反之，時間事件、不可重播副作用或必須逐項保留的任務紀錄，可能要求執行／記錄，即使目前數值輸出與上次相同。

4.4 全部喚醒不等於全部立刻運算

喚醒代表一個工作重新進入決策範圍，可以採取：立即執行、合法合併、按期限排程、局部重新驗證、恢復有效快取、必要時回退固定更新。若新事件已使某工作具有嚴格立即處理語義，才不得任意延後。

於是 Wake 更恰當的工作性描述是：

而不是：

4.5 避免過度合併事件

合併政策至少區分：

若不確定是否可以合併，預設 ordered_log 或保守基準；不能把所有「短時間多次 dirty」都當成同一筆更新。

5. 因果失效傳播：只碰受影響的工作，但不能漏掉影響

5.1 權威事件入口

只有已提交世界修訂、合法時間到期、觀察需求或恢復事件，才可建立強制義務。用已提交事件紀錄：

表示某個世界修訂 $k$ 的因果變更描述。targets 是影響的狀態身份、集合索引、規則或時間範圍；causes 保存前驅事件或必要關聯，避免事件身份與交易來源不可追蹤。

5.2 從狀態修訂到工作投影

在可追蹤的規則級依賴索引中，對已提交變更集合 $D_k$ 構造保守的受影響工作集合：

這是語義集合，不是要求運行時先完整物化整張世界因果圖。實作可利用 reverse-index、版本範圍、群組節點、工作分片與局部遍歷，逐步把必要工作放入佇列。若因果閉包過大，分塊處理仍須滿足 deadline／history obligations；不得因為分塊而改寫世界真實性。

Project_Q 不能把狀態 ID 直接當成工作 ID；同一狀態變動可能使多個工作失效，單一工作亦可能讀取大量狀態。

5.3 失效索引的最低資料構造

參考 Runtime 可維持：

• reverse_reads[state_key] -> work_ids：該狀態變化時需檢查哪些工作。
• guard_watch[predicate_or_index] -> work_ids：Guard 或相關集合出現／消失時需檢查哪些工作。
• rule_watch[rule_version] -> work_ids：規則更新、模組熱載或 schema 變動。
• clock_queue[clock_id] -> deadlines：每個時間座標的下次到期義務。
• event_log[world_revision]：可追溯的提交與通知原始來源。
• work_registry[work_id]：狀態、證書、有效結果與過期資訊。
• pending_tickets[work_id]：已識別且不可丟失的工作義務。

這些可以放在不同記憶體層、壓縮索引或分區載入；本篇不要求所有依賴索引永遠常駐一個巨大 RAM 集合。若索引卸載或損毀，必須能恢復事件掃描與安全重建。

5.4 版本標記與暫停觀察

對某派生工作 $q$，設它上次驗證版本指紋為 $\sigma_q^{(k)}$。受影響來源版本變動後，允許標記為 needs_review，並於到期或被觀察之前合法延後重新計算；這要求 Wake Contract 明確容許延後，且不能讓不完整的派生值被其他工作當成新鮮權威資料。

當另一工作需要讀取 needs_review 的結果時，它必須：

• 阻塞等待相容版本；或
• 接受契約內明確標示的 stale／approximate 版本；或
• 觸發依賴計算；或
• 走已知正確回退路徑。

不能讓某個局部子系統的休眠，隱性污染其下游整個世界。

5.5 高扇出的直接風險

當城市稅法改變並影響十萬個商戶，世界中真正受影響的計算可能就是十萬筆。CWSR 不能因只想喚醒幾個工作，就憑空減少必須執行的全域事件負載。

合理策略包含群組失效標記、延遲按需細化、聚合式合法更新與時間分段；對需要立即逐實體完成的語義，仍可能必須執行全量。高扇出不屬於演算法可以無條件抹消的現實。

6. 動態依賴、否定條件與集合變更

6.1 動態 Read Set 的問題

假設 NPC 尋找最近的商店，其依賴不是永遠固定的三家店。當新商店開業、道路封閉或 NPC 移動時，必須重新評估候選商店集合。只監控上次選出的那一家店，即使該店自身完全不變，結果也可能過期。

因此 DependencyStamp 需同時保存：

• 本次實際讀取的狀態版本；
• 決定 Read Set 的查詢索引版本；
• 取樣區域／查詢邊界；
• Guard 與否定條件的範圍；
• 必須追蹤的資料新增／刪除事件。

這是對 Paper 01 DepMatch 的細化，不另造新的世界定義。

6.2 存在與不存在查詢不能只依賴舊命中

例如「城內沒有任何存活守衛」：

如果觀察時沒有守衛，Read Set 可能是空集合；但空 Read Set 不代表無依賴。新守衛生成、傳送進城、復活或職業變動都會使條件轉為假。因此必須訂閱集合索引、查詢結果範圍及其更新 epoch，而非只記錄舊守衛的個體 ID。

6.3 依賴先發現、後切換的協定

執行一個有動態依賴的工作時，可採工作性流程：

1. 保留舊依賴訂閱，直到新指紋準備就緒。
2. 在固定讀取快照／epoch 上評估工作與發現新依賴。
3. 先建立新依賴監看及相關版本屏障。
4. 檢查在讀取快照與監看生效期間有無相關提交修訂。
5. 若存在，重新評估或進入保守重算；若無，才在符合合法條件時移除舊訂閱。
6. 變更依賴集合的工作不能只覆寫索引而不保留期間事件記錄。

這不是通用 lock-free 演算法的證明；具體實作須選擇可線性化的鎖、序列化提交、版本化 RCU 或可靠的事件日誌屏障之一，並驗證其競態行為。

6.4 相關預測與形式依賴的邊界

機器學習可以猜測哪些鄰近 NPC 會在玩家移動後被喚醒，甚至可提前把其資產載入 VRAM。但若這條關係尚未被規則確認，不能以預測模型認為「不重要」為由刪除原有監看項。只有規則級證據或等價的保守驗證，才能支持安全省略。

7. 訂閱競態：防止最致命的漏喚醒

7.1 Check-Then-Sleep Race

一個看似合理但不安全的實作：

T1: 檢查 q 的依賴沒有變更
T2: 世界剛好提交了一次會影響 q 的事件
T3: q 才開始訂閱依賴變動
T4: q 進入 DORMANT

T2 的事件既沒有被 T1 的檢查觀察，也發生在 T3 的監看建立之前，因此可以永久漏掉。只靠多執行緒原子變數或 Rust 借用檢查，並不自動消除此語義競態。

7.2 Subscribe-Then-Validate 的原則

本篇建議一個保守程序：先使監看足以覆蓋後續提交，再以世界修訂屏障檢查先前快照是否仍有效。如使用全域單調提交修訂 $k$：

1. 取得合法世界快照及觀察到的修訂 $k_0$。
2. 登記對所有必要依賴及查詢索引的監看，形成可識別的 subscription_epoch。
3. 使訂閱對從 $k_0$ 起的相關已提交事件有效，或由權威事件日誌補讀其間差分。
4. 取得註冊完成屏障後的世界修訂 $k_1$，並重新檢查依賴指紋。
5. 若 $k_0$ 到 $k_1$ 之間有未證明無關的變更，立即重新核對／建立 Pending；否則才允許生成 Dormancy Certificate。
6. 在 DORMANT 期間，後續相關提交必須排入可靠通知或由可重播日誌恢復。

此處要求的不是全世界都使用唯一巨大的 global mutex，而是提交修訂與訂閱可用性的正確序列化關係。不同世界分區可各有權威 epoch，但跨分區訂閱必須定義一致性屏障或採保守重查。

7.3 Commit-Notify 的原子責任

一個提交改變資料值卻沒有留下通知，仍可能造成永久休眠。因此建議：

在具持久化需求的配置中，狀態提交與事件日誌紀錄應在同一可恢復交易中完成，或採用能在崩潰後補掃描的等價方案。通知實際發送可以延遲；但不可在權威版本更新後失去可恢復的通知線索。這與傳統 transactional outbox、write-ahead event log、版本增量掃描等工程技術相容，不宣稱其為 CWSR 獨創。

7.4 Exactly-Once Delivery 並非最低需求

分散或多執行緒事件系統要實現真正端到端 exactly-once 並不容易。CWSR 可以接受至少一次通知 + ticket 去重 + 冪等提交作為候選策略。重複喚醒允許增加成本，但不允許重複執行不可重複副作用或重複提交世界交易。

此處必須分開：

• Notification delivery 可重複。
• Work attempt 可重試。
• World effect 若契約規定恰好一次，需以權威世界事件鍵或交易約束確保。
• External effect 仍需獨立的 durable outbox／去重／補償策略。

7.5 Crash-Recovery 與事件游標

記錄 last_processed_revision、subscription_epoch 與尚未完成的 Wake Ticket。從故障狀態恢復時，必須根據權威世界修訂重新補齊未處理事件；不能只恢復工作「看起來 Dormant」的 enum 值。若歷史差分已被截斷或版本資訊不足，應重建保守依賴快照並觸發相應的完整檢查。

8. 三種時間、期限與跳時語義

8.1 Simulation、Monotonic 與 Presentation 不得混用

遵守 Paper 01 的時間區分：

• Simulation Time：世界內日夜、任務、冷卻、人口與經濟演化。
• Monotonic Runtime Time：真實系統上的等待、超時、效能和排程延遲。
• Presentation Time：影格呈現、動畫時間與輸入感知。

一個遊戲 UI 在世界暫停時仍可能需要刷新；實時 OS 計時器可能不受遊戲速度影響；遊戲內每日 09:00 的 NPC 工作排程則受模擬時間控制。不能把這些全部存成單一 next_tick 整數。

8.2 期限語義的候選定義

令 $d_s(q)$ 為工作承諾的模擬時間完成期限， $d_m(q)$ 為需滿足的單調時鐘／真實時間完成期限；若某一種時間維度不適用，該欄位應標示 none，而不是偷偷填入目前 frame。工作可另設 not_before、最大 staleness 與延後界限。

判定逾期前，必須經過指定的時間座標與縮放／暫停契約：

此式僅表示「工作可擁有不只一種期限來源」，不表示一個工作若同時帶兩種期限就可以任意選其中一種結算；具體限制仍應取兩者同時滿足的可行計畫。

8.3 事件期限佇列

對具明確下一個到期時點的工作，可使用依時鐘分開維護的 min-heap、timer wheel 或合適分桶結構。排程器只需查閱下一個期限，而不必每幀遍歷所有尚未到期的 NPC；但注意到期時間可能因規則變動、暫停、加速或世界時間回退而失效，故 Queue entry 必須帶版本與 epoch。

簡化的 deadline record：

(clock_domain, due_at, work_id, timer_generation,
 rule_revision, requirement_kind, completion_policy)

取出逾期 timer 前需確認 timer_generation 仍有效；否則過期條目可被丟棄，但必須保留其替代期限的證據。

8.4 時間跳躍不能直接跨過因果邊界

如果世界時間由第 1 天直接跳到第 30 天，不能只處理第 30 天的薪資數值而忽略可能發生在第 7 天的破產、第 10 天的交易、第 14 天的婚禮與第 20 天的道路關閉。合法的時間快進有兩種主要方式：

1. 逐事件處理： 依合法順序取出所有跨越的不可省略期限與事件，逐個結算或以可交換合併處理。
2. 經證明的快速推進： 僅在模型具有明確組合律、沒有必要揭露的中間分支、副作用可合法折疊、歷史仍可重建且滿足誤差界限時，使用解析或聚合進位。

Paper 01 的候選快速演化契約為：

若某一時間區間有外部輸入、事件驅動分支、非交換交易或不可預測隨機抽樣，上述律不必成立，不能藉由大步長假裝事件不存在。

8.5 暫停、倍速、存讀檔與倒轉

每個 Clock Contract 必須說明：

• pause 是否凍結對應時間域的期限；
• speed_multiplier 如何改變工作世界時間，而非改變計時器物理語義；
• 存檔是否保留世界時鐘、期限佇列版本、未提交候選和 Pending tickets；
• 讀檔時是否重建 last_processed_revision 或重播事件；
• 世界時間倒轉時，應恢復歷史快照還是建立新分支，而非在舊版本上繼續向前更新。

若時間回退不能由當前 Runtime 安全支持，應明確拒絕該操作或採快照恢復，不可用負 delta_time 直接反推不可逆過程。

8.6 漏期限偵測

即使 timer wheel 或 heap 存在 bug，仍須有低頻或恢復時的保守校核：比較最小應到期工作、世界修訂、各時間域 watermark 與尚未完成票據。校核頻率、成本及可容許最大延遲須列入合約；它不能被假裝為無成本、零延遲的全知檢查器。

9. 從休眠到恢復：Wake Ticket 的完整旅程

9.1 工作流不應有神祕跳躍

一張可靠的 Wake Ticket 建立後，參考流程如下：

Authority event / due time / demand / repair
    -> Event identity and version check
    -> Rule dependency / time index lookup
    -> Inspect and requirement classification
    -> Persist or register Wake Ticket
    -> Check readiness and dependencies
    -> READY or explicit PENDING with deadline
    -> Validity / safe reuse / coalescing decision
    -> CPU/GPU/baseline execution if needed
    -> Candidate staging
    -> Commit Gate / replay-safe resolution
    -> Update indexes and wake downstream obligations
    -> Re-register under subscription barrier
    -> DORMANT / fixed-step / continued RUNNING

最後一步不能自動推論為休眠：若下一個期限已到、下游事件尚未處理或工作具有連續義務，必須再進入合適階段，而非一律回到 DORMANT。

9.2 Ready、Pending 與被阻塞的差別

到期義務已生成但相關物件尚未從儲存恢復，仍然是合法 Pending；是否可以在等待期間保持世界一致，取決於其他工作能否繼續、觀察是否容許 stale，以及 deadline 是否可被滿足。排程器不可將 blocked_on_data 錯標為 finished 或 dormant。

建議對 Pending 保留：blocking_reason、dependencies、retry_policy、earliest_ready_time、deadline、fallback_route。若數值、索引或權限永遠不會滿足，Runtime 必須能偵測飢餓或死鎖，而非只是無限等待。

9.3 喚醒失敗與恢復屬於正常語義

Wake Ticket 運作中的錯誤包括：

• 索引缺項、版本過期；
• 工作被錯誤刪除或重命名；
• 當前後端不支援契約；
• 記憶體不足、VRAM 配置失敗；
• 候選結果未通過 Commit Gate；
• Deadline 不能被滿足；
• 事件日誌毀損或缺失。

安全策略是記錄、可重播、回退或顯示明確無法完成狀態；不能因為系統目標是高效能，就隱藏結果過期或喚醒失敗。

10. 循環依賴、高階耦合與重入事件

10.1 依賴圖不一定是 DAG

遊戲系統中的市場需求、價格、商隊供給與 NPC 工資可能形成回授：

市場價格 -> NPC 購買量 -> 庫存 -> 市場價格
       -> 稅收 -> 政策 -> 市場價格

若每次局部變動都同步喚醒其餘節點，可能造成事件風暴或永不收斂。CWSR 不要求所有循環立即展開直到固定點；而是將回授區域辨識為群組，並指定其合法時間步進、結算順序或數值收斂／停止條件。

10.2 Strongly Connected Component（SCC）工作單元

對強連通子圖 $S\subseteq Q_t$，可採以下保守策略：

1. fixed_step_region：保持成熟的固定步進更新；
2. bounded_iteration：當模型可證明／測量符合收斂契約時，用有限迭代與殘差檢查；
3. transactional_batch：以同一版本快照產生候選變更，再經 Commit Gate 一次提交；
4. delayed_aggregate：對允許延遲與聚合的世界級統計，按合法 epoch 結算；
5. fallback：若依賴圖、版本或界限無法確認，轉回已知正確的基準。

不能將 SCC 的一條更新邊「剪斷」後，宣稱其餘結果必然等價。這需要相應的模型性質和誤差／收斂證據。

10.3 重入與波次邊界

一個工作執行時可能提交新狀態，造成自己或其他工作再次得到 Wake Ticket。為避免遞迴堆疊爆炸與觀察不一致，參考 Runtime 可以將一次已提交世界修訂產生的喚醒視為一個 epoch wave；在候選提交完成後，由下一波處理新義務。

此「波次」只是排程工程組織，不是世界時鐘。每一波次需要記錄來源修訂，並遵守以下條件：

• 在某工作執行中到來的新事件不得被其舊快照默默吞掉。
• 同一提交修訂的重複通知可以去重；不同提交修訂不可無條件合併。
• 每波次對 CPU／GPU 的工作負載可批次化，但不能突破候選／權威提交隔離。
• 如規則要求「同一遊戲時間瞬間內的原子觀察」，需要在波次間設定明確的可觀察屏障。

10.4 高階依賴不能只看成兩兩喚醒

例如「三座城鎮都同時缺糧才啟動援助事件」；任何單一城市的缺糧都不足以執行援助任務，但三者的聚合條件確實有義務被重新判斷。

因此群組守衛、計數索引、超邊／聚合 predicate 可作為觸發單位。這是 GCCFT 高階耦合概念在本篇條件依賴層的可選參照；不代表必須引入一套新的通用高階計算本體，亦不聲稱所有高階條件在工程上只能用超圖實現。

11. 工作合併、背壓、期限與資源治理

11.1 成本不只取決於工作數

在一個以 Wake Ticket 驅動的 Runtime 中，總成本至少包含：

省略無關計算只可能降低部分 $T_{\mathrm{execute}}$ ；卻可能增加索引、隊列、驗證和同步成本。當節點極小、每幀本就簡單、或因果變化極廣時，CWSR 可能顯著慢於普通固定更新。

11.2 因果喚醒的粗細粒度

如果每一個布林狀態變更都單獨提交 GPU Dispatch，管理成本與資料搬移可能遠超實際運算。因此局部工作可以使用：

• fine-grained subscribe 追蹤可靠依賴；
• region-level invalidation 合併相近規則區域；
• epoch batch 在事件時間語義允許下把工作整合；
• backend-specific execution 依工作算術強度和資料位置選擇 CPU／GPU。

因果判定精細，不代表執行提交必須細碎。 GPU 因果小流及渲染資源競爭的詳細模型留給 Paper 05。

11.3 Backpressure 不能抹掉履行義務

當喚醒生成速度超過可完成速度，Wake Ticket 會積累。Reference Runtime 必須設計：

• 可持久／可恢復的 Pending queue；
• 容量上限和高水位告警；
• 批次合併的合法性策略；
• 期限敏感的優先級；
• 長等待工作的飢餓防護；
• 無法履約時的顯式違約／退化紀錄。

僅以「低優先級 NPC 暫時不模擬」掩蓋未結算的世界交易或事件歷史，不屬於合法節流。

11.4 期限可行性是執行前的約束

Paper 01 給出待處理義務的計畫條件：

本篇補充：此條件只在有可信的執行成本界、可用資源和合法排程策略時，才可做為期限承諾；若無法保證，應明確報告 deadline_at_risk 或 deadline_missed，並採取政策允許的降級，不得憑空推測成功。

11.5 最小公平性契約

對不具嚴格 deadline 的 Pending 工作，也需要考慮 starve 與週期性掃描。可提出工程性公平性：若工作長期保持 Ready、資源持續可用且系統未進入永久超載，排程策略應最終給予執行機會。此為受負載與資源假設限制的 liveness 目標，不是對所有情況都能保證的形式結果。

11.6 資源預算與版本安全

工作可依 ResourceHints 指定預期 CPU 時間、記憶體、GPU Batch Size、VRAM working set 及最大候選等待時間，供後續 GCM Phase B／CWSR Paper 06 的路由參考。但 Hints 不是保證值：排程器必須記錄實測偏差並容許任務拒絕、縮批或保守回退。任何因成本不足而延後的結果，仍要維持其正確 world revision 標籤。

12. 執行、觀察、物化與候選提交的共同閉環

12.1 喚醒不代表有權寫入世界

保持 Paper 01 的 Candidate／Canonical 分離，對工作 $q$：

候選 $\delta_q^{(k)}$ 仍須驗證 input versions、guard、rule revision、time、precision、write conflicts、authority、idempotency 及跨域不變量；只有 Commit Gate 可以授權改變對應權威世界修訂。

12.2 事件與提交的先後責任

一個合理的狀態閉環包含：

1. 由權威修訂建立事件紀錄，保留可靠修訂序號。
2. 依事件與時間契約建立義務 Ticket。
3. 排程器選擇合法工作，於指定快照上計算。
4. 產生候選變更並送交 Commit Gate。
5. Commit Gate 驗證並提交或拒絕；不得讓執行器直接寫入另一份隱性權威世界。
6. 若提交成功，原子性地留下後續因果監看證據。
7. 若提交拒絕，將重試、取消或錯誤升級結果與工作期限更新到待辦責任帳。

CPU、GPU 或外部設備差異不改變此接口。GPU 可以產生大量世界狀態候選，但世界因果與資源治理不能因設備快而失去版本／提交約束。

12.3 觀察觸發與世界觸發並非同一回事

玩家開啟角色欄，可能只需要讀取有效快取或重新呈現 UI，而無須修改世界。玩家在戰鬥中揮劍，則可能產生世界變更。玩家沒有看到某個城市，也不表示城市的薪資、補給與劇情義務可永久取消。

為了避免 UI 成為隱藏計算觸發源，建議每個 demand event 說明：

• 需要世界更新、資料物化還是單純渲染？
• 可接受哪個 world_revision 和 staleness？
• 查詢會否造成副作用？
• 是否允許當前回傳 unknown、pending 或帶明確誤差界限的近似值？

12.4 觀察一致性與渲染正確性

不應將「影格一樣」當作世界等價證據。兩個世界即使畫面相同，其背後的 NPC 債務、任務事件順序、隨機來源、交易歷史或未來到期義務可能完全不同。本篇的正確性比較必須同時涵蓋可觀察投影與不在畫面中但被規則要求的歷史／時間不變量。

13. 小型世界案例：從休眠到確實喚醒

13.1 案例 A：玩家穿戴裝備，傷害派生值按需更新

初始條件：角色物品、裝備槽、被動能力、戰鬥傷害輸出具有明確版本；使用者打開背包但未修改裝備。

傳統簡化基線： 每次 UI 或世界 tick 都重新讀取／計算整個傷害面板。

CWSR 候選： 在依賴指紋未變且時間／副作用合法時，沿用既有結果。裝備槽提交新版後，使依賴的傷害工作 needs_review；若當前無戰鬥或 UI 需求且允許延遲，工作可 Pending 或保持帶監看的 Dormant。需要顯示或戰鬥結算前必須產生合約正確值。

必要反例： 裝備外觀未變，但遊戲規則熱更新或裝備附魔時效過期。若只訂閱物品欄 ID，便會漏失效。

13.2 案例 B：畫面不動，但 NPC 的固定世界時間事件到期

初始條件：NPC 在城市中休息，玩家站在另一張地圖，世界時間仍推進。NPC 每日 09:00 需領薪水，且可能於欠薪達臨界值時辭職。

錯誤實作： 因玩家沒進城，NPC 永不更新；當玩家返回時直接套用最後一天薪資，而不檢查中途辭職事件。

候選做法： 記錄下一個 09:00 到期工作及其合法合併規則；模擬時鐘跨越到期點後，按事件邊界順序結算，或使用有證據的快速推進。玩家回城時，NPC 狀態與日誌必須與宣告的時間語義相容。

13.3 案例 C：新增守衛使「無守衛」條件失效

初始條件：某城門在城市沒有存活守衛時自動開啟；目前守衛集合為空。

錯誤實作： 工作記錄空 Read Set 後永久 Dormant。

候選做法： 對城市守衛集合的生成、死亡、移入、復活等事件維護集合版本監看；任何可能改變條件真值的集合事件都觸發重新核對 Guard。若索引版本無法可靠維護，使用明確的區域掃描基準。

13.4 案例 D：橋梁斷裂造成跨區域因果擴散

某座橋梁崩塌後：

• 微觀：物件碰撞、單位停步、道路阻塞。
• 中觀：商隊路由、城市補給批次重算。
• 宏觀：糧價、貿易量或政治壓力可能改變。

本篇只要求不漏掉應傳播的因果 Ticket；上行／下行資料聚合、誤差、局部細化與世界尺度轉換屬 Paper 03。不能憑本篇直接宣稱已解決跨尺度守恆。

13.5 案例 E：高頻粒子與碰撞系統反而不適合全部休眠

當場景內有數千個高速碰撞物件，且每個物件幾乎每步都可能影響鄰居，逐物件版本比較、建立巨大 subscription graph 可能比直接採用成熟物理引擎固定步進昂貴。

在此情況下 CWSR 應容許整個物理區域使用 fixed_step_region，僅對遠處且經引擎既有睡眠機制證明穩定的物件採休眠。這是正面承認本架構有適用域，不是實驗失敗後才增加的例外。

13.6 案例 F：規則與 Mod 熱更新

某個 Mod 調整 NPC 的飲食規則。受影響的不是某筆食物數值，而是判定可吃哪些食物的規則版本及依賴發現方式。

參考 Runtime 必須將 rule_revision 納入失效來源，必要時重新建立依賴索引、撤銷舊的 Dormancy Certificate，或進入 Fallback 全量更新。AI 自動修改遊戲碼不會自行保證依賴圖完整；修改行為需要回歸測試、靜態分析或有效的保守監看策略。

13.7 案例 G：GPU 批次候選完成後世界又變了

GPU 對某區域一萬筆供需狀態進行批次計算，輸入快照為世界修訂 $k$ ；但 CPU 在其間提交商隊意外事件至 $k+1$。

若該事件影響 GPU 批次所需的有效輸入，結果不得直接覆寫最新版世界；應依 read/write/guard 衝突契約拒絕或重試、局部重新計算或合法合併。此案例說明：GPU 能計算世界，但並不取得免驗證提交權。完整批次裝置路由交由 Paper 05。

14. 參考資料契約與概念性程式介面

14.1 機器可讀的契約草案

以下為候選 Rust 風格介面，不是已編譯、未聲稱通過任何單元測試的程式碼，僅用於精確說明字段邊界：

// CWSR Paper 02 — conceptual interface, not executable reference code.
struct WakeContract {
    work_id: WorkId,
    read_dependencies: DependencyDescriptor,
    guarded_queries: GuardDescriptor,
    clock_obligations: Vec<ClockObligation>,
    continuous_policy: ContinuousPolicy,
    observation_policy: ObservationPolicy,
    coalesce_policy: CoalescePolicy,
    side_effect_policy: SideEffectPolicy,
    fallbacks: Vec<FallbackMode>,
}

struct DormancyCertificate {
    work_id: WorkId,
    validated_world_revision: WorldRevision,
    dependency_stamp: DependencyStamp,
    subscription_epoch: SubscriptionEpoch,
    next_deadline: Option<ClockDeadline>,
    recovery_cursor: EventLogCursor,
}

struct WakeTicket {
    ticket_id: WakeTicketId,
    work_id: WorkId,
    cause_ids: Vec<EventId>,
    required_snapshot: SnapshotRequirement,
    not_before: Option<ClockDeadline>,
    deadline: Option<ClockDeadline>,
    completion_policy: CompletionPolicy,
    authority_scope: AuthorityScope,
}

SnapshotRequirement 不表示盲目要求讀取最新 RAM 值；它應指明需要哪個已提交世界修訂或某個符合時間與精度契約的有效範圍。

14.2 最小接收程序

on_committed_event(e, revision):
    assert e belongs to authorized commit evidence
    persist_or_recover event cursor
    affected = query_rule_index(e.targets, e.changed_predicates)
    for each typed work_id in affected:
        issue_or_merge_ticket(work_id, e, by_contract)
    update_deadline_index_if_rule_or_clock_changed(e)
    record delivered/handled cursor after ticket durability

query_rule_index 只處理已宣告可追蹤的規則依賴；若索引覆蓋不足，該區域應被標為 FALLBACK_REQUIRED。上述 for each 不是強迫逐次獨立 GPU Dispatch，而是可分塊、可批次的 ticket 建立操作。

14.3 最小休眠程序

attempt_dormancy(q):
    if q has immediate continuous or unhandled mandatory work:
        return NOT_DORMANT
    snapshot, k0 = read_consistent_world_snapshot(q)
    discovered = discover_guards_and_dependencies(q, snapshot)
    barrier = subscribe_with_revision_coverage(discovered, k0)
    if not barrier.is_valid:
        return FALLBACK_REQUIRED
    k1 = read_authoritative_revision()
    if any unproven relevant delta exists between k0 and k1:
        return RETRY_OR_PENDING
    if q has elapsed deadline or outstanding mandatory effects:
        return READY_OR_PENDING
    return create_dormancy_certificate(q, barrier, k1)

subscribe_with_revision_coverage 是需要明確實作與驗證的關鍵接口，不允許用普通的 subscribe() 函數名稱掩蓋沒有版本補讀保障的資料競態。

14.4 最小喚醒／執行程序

process_ticket(ticket):
    validate_ticket_identity_and_order(ticket)
    q = resolve_registered_work(ticket.work_id)
    if q missing or dependency evidence incomplete:
        return FALLBACK_OR_EXPLICIT_FAILURE
    if safe_reuse_allowed(q, ticket):
        fulfill_only_obligations_that_are_proven_reusable(ticket)
        return REUSED_WITH_EVIDENCE
    if not resources_or_dependencies_ready:
        retain_pending_ticket_with_deadline(ticket)
        return PENDING
    candidate = execute_on_versioned_snapshot(q, ticket)
    decision = commit_gate(candidate, ticket, current_world)
    if decision.accepted:
        atomically_record_commit_and_wake_evidence(decision)
        rearm_q_with_subscription_barrier(q)
    else:
        retain_or_retry_ticket_per_policy(ticket, decision.reason)

這一流程將調度、執行與世界變更權限區分開；參考架構的正式型別、後端適配與可編譯程式碼由 Paper 07 承擔。

14.5 事件日誌與最低可稽核證據

推薦最低 trace 欄位：

world_id, world_revision, rule_revision, event_id,
work_id, ticket_id, cause_ids, dependency_stamp,
subscription_epoch, clock_domain, due_at,
created_at_mono, scheduled_at_mono, completed_at_mono,
execution_backend, candidate_id, commit_decision,
fallback_reason, replay_cursor, result_equivalence_class

某些欄位可採取壓縮或抽樣策略以避免量測本身污染效能，但正式正確性測試不得因效能壓力省略會使錯誤不可追溯的必要證據。

15. 正確性主張：安全、活性與觀察等價要分開

15.1 安全性、活性與效能不是同一個目標

• Safety（安全性）： 沒有必要世界事件被默默遺失；未授權候選不會被提交；不完整依賴不能被當成有效省略證書。
• Liveness（活性）： 在明確的容量、排程公平性、外部事件到達與世界時間條件下，合法到期的工作能取得完成機會。
• Performance（效能）： 在滿足 Safety 與 Liveness 及觀察誤差契約的前提下，減少計算、記憶體活動、同步或能源成本。

若一個方案只讓平均 FPS 上升，卻漏掉 NPC 每日工資或任務事件，它是不正確的優化；若所有事件都不漏，但每幀依賴掃描造成額外三倍 CPU 消耗，則是工程上未獲得效益的正確候選。

15.2 條件命題 P02-1：已提交規則事件的喚醒可追溯性

前提 A： 對所有需要喚醒 $q$ 的規則級世界修訂，權威事件紀錄可完整追溯，且修訂與 wake evidence 在崩潰後具有可恢復的一致性。

前提 B： $q$ 的依賴契約完整，包含動態 Guard、負向查詢與規則版本；當契約不完整時，系統有保守掃描或基準更新作為有效替代。

前提 C： 進入 Dormant 前完成訂閱／版本屏障；後續事件通知可重複，但不得無憑據地遺失，且系統可由事件日誌游標補掃。

在這些前提下，對每一筆會產生強制義務的已提交相關修訂，應存在一條可回溯到該修訂的 Ticket、合併後票據、已完成證據或保守回退工作路徑。

此結論是參考協定在假設成立時的設計推論。其證明綱要是：訂閱屏障將事件分為建立監看前、建立期間與建立後；前兩者由重驗證或歷史差分涵蓋，後者由可靠通知或日誌補讀涵蓋。若有未涵蓋區間、動態依賴遺失或持久化失效，前提失效，本命題便不能成立。

非主張： 這不證明每個事件一定立即完成，也不證明資源不足時仍能滿足 deadline。

15.3 條件命題 P02-2：合法休眠不移除時間義務

對具有有效 Clock Contract 的工作 $q$，若其休眠證書包含正確的下一個到期點，時間隊列能在指定時間座標下可靠提供到期 Ticket，且跳時／存讀檔操作能保留或重建該義務，則 DORMANT 不會因自身生命週期狀態而使該時間義務消失。

此命題無法套用到未宣告期限、時間語義不明、事件隊列不可靠或存在不可重建時間歷史的工作；在該類工作上應採保守更新。

15.4 條件命題 P02-3：合法的純函數重用

沿用 Paper 01 的 P01-1：若工作為無副作用的確定函數、依賴指紋完整、輸入與規則版本相同、時間與精度要求一致，則可以重用已驗證結果。Paper 02 的新增責任只是：使重用後的下一個喚醒監看仍然完整。

有效重用不等於完成副作用，也不等於允許永遠不監看後續變更；新的依賴或時鐘事件到來時仍應重新核對。

15.5 觀察等價不能只用一個畫面比較

對固定輸入與世界事件序列 $I$，定義一個基準 Runtime $B$ 和候選 Runtime $C$ 的可觀察序列：

若採精確語義，候選應保持規則要求的事件身份、先後順序、提交版本、關鍵世界數值、隨機來源與規定觀察點的一致；這可在具確定重播的場景中檢驗。

若採允許誤差的模擬，應先指定觀察集合 $\mathcal O$ 、時間窗、誤差範圍 $\varepsilon$ 與可接受的歷史差異，而後檢驗：

此式不能單獨取代任務不可遺失、不可逆事件、權限、存檔及交易不變量。對有機率轉移的系統，還需固定亂數語義、共同隨機源，或進行事先註明檢驗力與誤差門檻的分布比較；不得把不同亂數軌跡天然視作錯誤或天然視作等價。

15.6 時效性與截止期限的條件承諾

若系統對 $q$ 作出 Deadline 承諾，須至少提供所採用的執行時間上界或保守估計、可用資源、被阻塞依賴及排程優先級證據。當無法保證完成時，應在義務簿上保留違約風險及回退政策，而非把所有期限都用簡單 eventual 掩蓋。

16. 成本假說、適用域與不可宣稱的複雜度改善

16.1 何時可能值得建索引？

一個有大量狀態節點、但局部變更率低、依賴可準確追蹤、單次計算昂貴且觀察範圍有限的開放世界，是 CWSR 的候選適用域。相對地，若高頻全域事件幾乎影響每個工作、每工作成本極低、動態依賴頻繁重建或工作具有密集同步副作用，使用複雜 Wake Contract 可能得不償失。

16.2 受條件約束的成本表示

對某時間窗口內共有 $n=|Q|$ 個工作、 $u$ 個實際觸發或到期的必要工作、 $a$ 條被依賴索引觸及的邊，且使用可有效查找的局部逆向索引時，部分管線成本可概念上表示為：

在非常具體的簡單索引、可界定事件頻率且 priority queue 操作有對數成本的模型裡，這些項目可能隨 $a$ 和 $u$ 而非每一 frame 的 $n$ 增長。但不能因此推論整體 Runtime 必然為 $O(u)$，因為：

• $a$ 可能與全世界依賴邊數量同階；
• 動態依賴發現可能需要全量搜尋；
• 群組與 SCC 更新可能需要多輪迭代；
• 精度驗證、資料搬移及 Commit Gate 仍有成本；
• 邏輯世界本身可能要求不可壓縮的全域工作；
• 事件隊列整理、存檔和恢復有額外成本。

因此研究目標不是寫出不具前提的「更新複雜度不依賴世界大小」，而是實驗測量在指定工作負載與正確性契約下，有效活動域縮小是否足以抵銷監看與路由成本。

16.3 可測的 Break-even 條件

設定相同場景、相同規則、相同硬體與可觀測一致性契約，在指定 workload $w$ 下：

當 $\Delta T(w)>0$ 且其他必要指標不劣於事先宣告門檻時，才可在該場景稱候選有淨時間效益；反之應回退，或研究在何種工作密度之上才值得啟用。$T$ 究竟測 CPU time、wall time 或 simulation-step latency，實驗前必須固定，不可混用。

16.4 不把低算力當作低品質的代名詞

本系列面向消費級硬體，是因為大型開放世界不應只依賴持續加大 RAM／VRAM 和高價 GPU 來改善動態性。但資源約束也不能成為故意降低遊戲因果正確性的藉口。合法節省的資源未來可分配到 NPC、城市經濟、交通或更高解析度的局部模擬；節省多少、能轉換多少品質，仍須先由 Paper 08 實測。

17. 最小可證偽測試矩陣

17.1 正確性及可靠性測試

上表是未執行的驗證需求，不是通過報告。Paper 07 應將其轉換為可重播測試與失敗證據；Paper 08 應確定基準、硬體與門檻。

17.2 最低效能工作負載

每個測試應至少覆蓋四種不同事件密度：

1. Sparse: 世界規模大而每窗僅少量因果變化。
2. Moderate: 有固定比例的活躍 NPC、商店、任務與時鐘事件。
3. Dense: 大量相互依賴、幾乎每步都變的系統。
4. Burst: 道路封鎖、稅法改動、災難或玩家快速連續操作造成短時間高扇出。

需要另測純 UI 場景、持續物理場景、世界倍速與存讀檔恢復，避免只挑最有利於 CWSR 的靜止世界。

17.3 對照組不能只使用最差的天真輪詢

至少比較：

• B0 — Naive Fixed Update： 合法但未優化的逐工作固定更新，作為問題觀察基線。
• B1 — Mature Fixed-Step / Engine Optimized： 使用既有有效優化後的引擎固定更新或物理休眠。
• B2 — Event + Dirty Flags： 傳統事件訂閱與局部 invalidation。
• B3 — Timer / Region / Incremental： 具成熟期限排程、分區或增量機制的較強基線。
• C — CWSR Candidate： 在相同契約下，加入 Wake Contract、屏障、保守合併和安全回退。

如果 CWSR 只比 B0 快、卻顯著慢於 B2／B3，不能宣稱本篇提出了超越成熟方法的整體性能收益。

17.4 必須量測的成本與正確性指標

17.5 實驗可重現性

每個性能結果至少要附：OS、CPU／GPU、RAM／VRAM、引擎版本、Rust／C++ 編譯器、release/debug 模式、工作負載種子、事件日誌版本、世界規則版本、圖結構生成法、測試時鐘策略、GPU 渲染負載與重複次數。

實測世界規模、有效事件比例、索引容量、低／高扇出分布和不可合併事件比例，必須隨結果一起公開或內部封存。不能只宣稱「百萬 NPC 運算成功」，卻不說其中實際活動者多少。

18. 反例與縮小適用域：必須允許本篇失敗

研究態度： 某些 workload 使用成熟事件機制就已足夠；某些 workload 確實需要每步計算。CWSR 的價值由其在明確適用域中能否保持正確性並改善成本決定，而不是由命名、理論篇數或複雜符號決定。

19. 與後續 Paper 03–08 的精確交接

不可提前推定： Paper 02 的契約完成不代表 Paper 03 的多尺度模型已正確、Paper 04 的 VRAM 已節省、Paper 05 的 GPU 有加速，也不代表 Paper 07 有可運行產品。

19.1 Paper 03 的直接研究入口

當世界事件可以可靠地喚醒「哪些工作」後，下一個問題就是：不同解析度的世界模型怎麼共同持有一致的時間、因果與身份？

例如商隊跨越遠方區域時，是否需要逐車逐馬模擬、還是可由中觀路網流量表示？某城鎮突然破產後，國家級供應指標應何時更新？宏觀聚合結果要如何重新細化為有一致歷史的 NPC 與商店？

Paper 02 只提供喚醒與義務底座，不搶先定義世界模型的近似、反聚合或守恆定理；後者由 Paper 03 明確處理。

20. 上游文件、既有技術背景與研究記錄

20.1 本篇實際核對的 EveMissLab 原始研究

以下指向先前版本化的研究檔案及其接口，並不代表外部獨立同儕審查。正式投稿時應按作者審定的版本與實際公開位置補齊可核實的出版資訊。

1. Neo.K × Aletheia，CWSR Paper 00｜因果世界狀態運行：既有計算理論的單機遊戲 Runtime 延伸總綱，v0.1，2026-10-16。原始 UTF-8 Markdown：CWSR_Paper00_Causal_World_State_Runtime_Series_Charter_v0.1_2026-10-16.md。
2. Neo.K × Aletheia，CWSR Paper 01｜世界狀態本體與可執行狀態分離，v0.1，2026-10-16。原始 UTF-8 Markdown：CWSR_Paper01_World_State_Ontology_and_Executable_State_Separation_v0.1_2026-10-16.md。
3. Neo.K × Aletheia，全域計算方法論：異質計算的全域一致組合，v0.1，2026-08-23。回收原稿：01_全域計算方法論_異質計算的全域一致組合_v0.1.md。
4. Neo.K × Aletheia，GCCF 04｜全域可尋址狀態：大內存之外的選擇性物化模型，v0.1，2026-09-22。回收原稿：GCCF_04_Globally_Addressable_State_and_Selective_Materialization_v0.1_zh-TW.md。
5. Neo.K × Aletheia，GCCF 05｜因果流計算與預記載：面向未來需求的分散式執行，v0.1，2026-09-22。回收原稿：GCCF_05_Causal_Flow_and_Predictive_Preloading_v0.1_zh-TW.md。
6. Neo.K × Aletheia，GCCWT Paper 04｜計算場與資源激發：跨 CPU／GPU／Memory／Agent 的動態執行域，Draft v0.2。回收原稿：GCCWT_Paper04_Draft_v0.2.md。
7. Neo.K × Aletheia，GCCWT Paper 06｜AI 原生全域調度：從 Task Scheduler 到 World Computation Planner，Draft v0.2。回收原稿：GCCWT_Paper06_Draft_v0.2.md。
8. EveMissLab，GCM Phase B：Deterministic Compute Allocator 技術白皮書，v0.1，2026-08-27。回收原稿：GCM Phase B：Deterministic Compute Allocator 技術白皮書 v0.1.md。
9. Neo.K × Aletheia，《計算的二十四重範式》，正式版候選稿 v4.0，2026-07-19，及 《從二十四重計算形態學到七十二格計算動力學》 v0.1，2026-07-19。此二者本篇僅作後續路由的上游分類來源，不重新定義分類軸。

20.2 外部成熟技術背景（非本篇原創宣稱）

• Event-driven programming 與各類事件循環；
• Incremental computation、Reactive programming、Dirty Flag／Dependency Tracking；
• Priority Queue、Timer Wheel、Deadline Scheduling、Fair Queueing；
• Database snapshots、MVCC、Event Sourcing、Transactional Outbox；
• ECS／Job System、Physics Sleeping、Simulation Level of Detail；
• GPU Compute、asynchronous compute、資料局部性和批次處理。

上述名稱用於界定可對照的成熟工程方法；本篇沒有把未核對過的精確書目、效能數值或外部引文假裝為已驗證文獻證據。若整理成正式公開論文，需依照實際使用的軟體版本與文獻做獨立核對。

20.3 研究限制

這是 v0.1 的工程推導稿，尚未提供：

• 經檢查的形式化模型與機器驗證；
• 已編譯 Rust Runtime 或引擎內的 hook；
• 高效動態依賴索引的記憶體上界；
• CPU／GPU 實作比較結果；
• 存檔／倒轉／跨尺度世界的完整模型；
• 消費級硬體的效能、能源與體驗測量。

未來如需把本篇提升為嚴格方法或效能主張，應先由 Paper 07 實作最小驗證台、再由 Paper 08 實驗校核；不應只因一組概念偽碼有邏輯說服力，就直接宣稱已達產品級品質。

21. 結論

CWSR Paper 02 的關鍵不是把所有 update() 改寫為事件 callback，也不是宣布所有 NPC 都能永久休眠。它真正建立的是義務保全的選擇性執行程序：當世界規則沒有要求重新計算，工作可進入可喚醒的休眠或合法待辦狀態；當已提交因果、時間、觀察或修復義務出現，必須能以完整的版本、依賴、事件身份與期限把它找回來。真正執行後的輸出，仍必須通過候選提交驗證，才能成為權威世界的新版本。

本篇認為，安全休眠至少必須同時具備：完整的必要依賴、可靠訂閱或事件補讀、到期義務、合併政策、合法延後條件、恢復途徑，以及在證據不足時自動退回可驗證基線的能力。尤其訂閱屏障、負向查詢、跳時與版本競態，是此類 Runtime 若想超越表面 Dirty Flag 優化就必須面對的具體技術責任。

因此，CWSR 的工作性原則可濃縮為：

可以讓計算休息，但不能讓因果責任消失；可以讓結果暫時沿用，但不能讓新世界事件被舊證書掩蓋；可以選擇性執行，但不能選擇性遺忘應履行的世界規則。

真正的效能價值只能在指定遊戲規則、工作負載、成熟對照與有限消費級硬體上實測。適合連續更新的物理與高度耦合場景，仍然可以繼續使用現有引擎的固定步進與成熟優化；CWSR 不要求對它們進行不必要的替換。

下一篇：CWSR Paper 03｜宏觀—中觀—微觀多尺度世界模擬。 Paper 03 將承接本篇可靠的事件與時間義務，具體研究不同世界解析度間的聚合、反聚合、上行／下行因果與精度一致性。

版本紀錄

• 2026-10-16｜v0.1： 繼承 CWSR Paper 00／01 的世界狀態、工作投影、必要義務集合、時間契約與候選提交接口；新增 Wake Contract、Dormancy Certificate、Wake Ticket、Subscription Barrier、動態依賴／負向查詢、deadline、SCC 處理、backpressure、可證偽測試矩陣 W01–W22 與反例 F02-01–F02-12。本文為未驗證的研究草稿；不宣稱已有 Rust／GPU 原型或性能實測。

End of CWSR Paper 02 — Research Draft v0.1.