title

CWSR Paper 07｜CWSR Runtime：遊戲引擎整合與參考實作

english_title

CWSR Runtime: Engine Integration and a Reference Implementation for Causally Governed World-State Execution

series

CWSR — Causal World-State Runtime

paper

07 / 08

version

v0.1

date

2026-10-16

author

Neo.K

ai_research_collaborator

Aletheia / GPT-6

institution

EveMissLab / 一言諾科技有限公司

status

Research Draft — Engineering Extension / Reference-Implementation Specification; Hardware Validation Pending

canonical_source

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

language

zh-TW

predecessor

CWSR Paper 06 v0.1

next_paper

CWSR Paper 08 — 可證偽驗證與開放世界效能基準

CWSR Paper 07｜CWSR Runtime：遊戲引擎整合與參考實作

從因果工作票、跨尺度狀態、記憶體契約與 24／72 路由，到可隔離、可重播、可測量的遊戲執行核心

English: CWSR Runtime: Engine Integration and a Reference Implementation for Causally Governed World-State Execution

系列定位： CWSR Paper 07 / 08。本文是 Paper 00–06 的工程收斂與 Paper 08 的實驗入口，不重新定義全域計算論、24／72 或 Rust 語言語義。

本篇交付： 分層 Runtime 架構、資料及權威接口、階段性交付門檻、最小 Rust 標準庫參考核心原始碼、CPU 決定性測例、GPU 後端接入規則、Godot／EveWorld 適配規格、存讀檔與失效恢復契約、基準執行與反證矩陣。

交付證據等級： 本篇內含完整可供本地端複製的最小 Rust 參考候選，而非宣稱已經打包或測通商用引擎。當前寫作環境沒有 Rust 編譯器，因此本篇 Rust 範例未經 cargo test 實際驗證；也未在實機 GPU、Godot、Windows 驅動或 EveWorld Engine 上量測。該界線必須保留在正式原稿中。

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

摘要

CWSR 前六篇已建立若干互相獨立而不可混淆的義務：邏輯世界不等於活動工作；世界內容有效不等於已駐留；世界某部分休眠不等於其時間與因果責任消失；宏觀摘要不等於可任意反推微觀歷史；GPU kernel 完成不等於世界提交；24／72 計算形態不等於固定硬體或效能排名。若只把這些規則留在論文中，而沒有具體 Runtime 邊界，實作者很容易在優化、遊戲引擎回呼、MOD 熱更新、快轉與裝置故障時重新破壞這些區分。

本文的任務，是在單機、有限資源、權威世界狀態的工程邊界內，將前述契約落成可測試的執行結構。其核心不在於另造大型通用計算作業系統，而是採取極小、能驗證的垂直切片：固定 world fixture、明示的事件／期限、版本戳記、可撤回路由建議、容量門檻、候選結果、唯一 Commit Gate，以及可以與原始 CPU 參考語義比較的重播歷史。GPU 世界計算與引擎適配採逐步接入；沒有可驗證後端，就不得把 GPU 計畫當成已完成計算。

本文提出 WorldRegistry、WakeController、ScaleBridge、ResidencyManager、FormAnnotator、RoutePlanner、ResourceAllocator、CandidateExecutor、CommitGate、HistoryReplay 與 EngineAdapter 的最小責任分界，定義候選執行記錄與重播證據，並附帶不依賴第三方 crate 的簡化 Rust 轉帳式 world fixture。範例的保守設計刻意採全域 revision barrier + 單執行緒 CPU 計算，而不假裝已涵蓋依賴索引併發、GPU fencing、動態尺度細化或真實裝置分配；其作用是提供可供後續逐項擴充的語義對照錨點。

Paper 08 必須以同一世界規則、輸入事件、可觀測契約、精度與資源環境，對照成熟 CPU ECS、事件驅動、GPU Compute 與 FormBlind 異質路由，檢查 CWSR 是否在語義正確的前提下帶來真實收益，並允許結論為「沒有額外收益」。因此，Reference Runtime 的第一完成條件是可證偽與可恢復，不是最大化功能數或直接宣稱效能突破。

關鍵詞： CWSR；Reference Runtime；Game Engine Adapter；Rust；Deterministic CPU Oracle；Causal Ticket；World Revision；Commit Gate；Route Planner；24／72；Selective Materialization；GPU Compute；Device Fence；Multi-Scale Simulation；Replay；Mod Compatibility；Godot；EveWorld Engine；Falsifiability。

0. 任務界線與研究責任

0.1 這篇是實作規格延伸，不是第七套母理論

CWSR 的理論母源已存在於 GCM、GCCF、GCCFT、GCCWT，以及計算 24 範式與 72 格計算動力學候選系列。本篇只有一項新增責任：把前六篇在單機遊戲內的規範，以具體資料流、元件接口、失敗路徑和測試閘門表達。

這裏所稱 Runtime 是可被遊戲引擎呼叫、可回放世界結果的程式層與執行控制面。它不暗示重新實作 Windows 排程器、顯示卡驅動、編譯器、物理引擎、圖形 API 或 Rust 所有權機制。既有 ECS、Dirty Flag、Event Bus、Timer Wheel、GPU Compute、Fixed-Step Physics、快取、存檔與重播機制均是成熟工程來源；本篇研究它們如何在一組明確世界語義下被協調，而非冒稱發明之。

0.2 四個階層必須永久分開

1. 世界規則層： 身份、規則修訂、資產及歷史、模擬時間、精度與可觀測不變量。
2. 工作資格層： 必要事件、期限、依賴失效、候選喚醒、尺度／形式註記。
3. 物理執行層： CPU 工作、GPU dispatch、RAM／VRAM lease、fence、完成回執。
4. 權威修改層： 版本與證據驗證後的唯一世界提交、歷史追加、後繼事件生成。

不可用「GPU 寫進 buffer」「引擎節點更新」「路由分數最高」「模型認為已結算」取代第四層。

0.3 必須實作和可以延期的事項

這個表不是將未實現功能宣稱已完成，而是規定逐階段什麼叫做有證據的完成。

0.4 明確禁止的完成宣稱

• 沒有 cargo test 報告就不能稱 Rust 參考 crate 已編譯驗證。
• 沒有 adapter／GPU driver／shader hash 及 fence 測試就不能稱已完成 GPU 世界計算。
• 沒有實際 Godot／EveWorld build 與事件回放就不能稱已整合引擎。
• 沒有公平的 B0–B6 對照就不能稱 24／72 改善性能。
• 沒有存檔恢復、MOD 變更與時間快轉壓力測試，就不能稱大世界因果一致性已證明。
• 沒有世界規則等價證據，就不能把畫面顯示正常當成執行正確。

1. 從 Paper 00–06 的明確交接

1.1 共用世界記號

沿用前篇（本篇只引用、不修改）：

在本篇中， $N_t$ 表示不可丟失的規則義務， $A_t^Q$ 是已取得活動資格的工作， $P_t$ 是符合契約的待處理義務；三者都不等於現在 CPU 正在執行的函式集合。

1.2 候選與權威分離

令 $C_t(q,r)$ 為工作 $q$ 在路由 $r$ 上得到的候選結果， $\mathrm{Gate}$ 為權威提交檢查。只有通過 Gate，才能取得新世界 revision：

這是操作性要求，不表示任意 GPU 工作結果皆可直接套入同一個數值計算函式。跨尺度轉換、隨機更新與物理子步進仍需要各自證據策略。

1.3 參考版故意先使用更強的版本壁壘

為避免早期原型因細粒度索引缺陷而漏依賴，初版採 world-wide revision barrier：候選建立後若任何權威世界修改發生，候選必須拒絕並重跑，即使修改不在其 read set。這會犧牲吞吐量，卻提供簡單且可重現的 CPU oracle。後續才可把全域 barrier 放寬至經證明完備的 per-key 或 domain-based version vector。

1.4 提交權不得由引擎偷偷取得

Godot／EveWorld 可以呼叫 Runtime、接收只讀事件與渲染狀態，但不能因 Inspector、動畫事件、腳本回呼或模組熱更新而直接越過 Commit Gate 修改 canonical world。若某 gameplay 系統需要寫入，它應產生型別化的 Intent／WorldCommand，由同一個授權鏈安排。

2. Runtime 的最低模組邊界

2.1 WorldRegistry：世界身份與讀取快照

職責：維持 world ID、revision、rule/schema revision、受保護的 canonical state、可重播歷史索引及 snapshot token。最小讀取能力為 get_state_ref 與 snapshot_at_revision；直接修改權只存在於 Commit Gate。Registry 不以裸 GPU address 充當世界物件 ID。

2.2 WakeController：義務與工作票生命周期

職責：由已提交事件、到期時間、訂閱與恢復記錄生成 Ticket；記錄工作是否已完成、延期、取消或重試。所有延期需保留期限與因果義務；未知 Guard 必須阻止不安全休眠，或採保守輪詢／固定步進。

2.3 ScaleBridge：尺度投影與結果對齊

職責：提供 macro／meso／micro 的尺度視圖、聚合／條件細化、identity anchors、數量守恆、版本與 Temporal Cut。拒絕任何不能在既有事件帳本下合法還原的個體歷史；若尺度轉換帶近似，必須附誤差界限及可審計 policy ID。

2.4 ResidencyManager：物理載體管理

職責：RAM／VRAM working set 的預算與 lease、版本化 replica、重建成本、Pin／Evict 與裝置失效恢復。它可以管理 buffer，不能管理遊戲世界因果真值；卸載不得一併刪除尚未到期的事件。

2.5 FormAnnotator：分類不是指令

職責：在明確 observation context 下，給工作片段加上 24／72 profile；支援 Single、Set、Path、Stack、Unclassified，保留 basis version、rule revision 與分類證據。結果屬 metadata，可以撤回；不得直接觸發世界變化或決定某種硬體必然較快。

2.6 RoutePlanner：提出可撤回計畫

職責：先取得合法候選，再比較 CPU Serial、CPU Jobs、CPU SIMD、CPU Event、GPU Direct、GPU Resident、Cache Reuse 等路由，在 shape、成本、資源、期限和證據下選擇計畫。提供 FormBlind 和 FormAware 兩種對照配置，後者不可豁免原有 hard gates。

2.7 ResourceAllocator：物理預算與授權

職責：提供有限時間 lease、負載快照、裝置能力、render reserve、最大 outstanding work、RAM／VRAM headroom，以及明確的拒絕理由。計畫者說「GPU 可行」不等於 allocator 已保留該資源，lease 也不等於驅動已物理配置 VRAM。

2.8 CandidateExecutor：計算與候選回執

職責：從有效 snapshot、授權的 lease 與 verified algorithm/kernel 產生只讀候選回執。CPU 後端可先使用定義清楚的參考函式；GPU adapter 必須有 buffer generations、fence、寫集、精度／bitwise 契約和完成證據。

2.9 CommitGate：唯一的世界改寫門

職責：重驗 snapshot、規則、schema、MOD hash、ticket、read/write hazards、尺度和精度憑證、lease/fence 與可觀測不變量，然後一次提交，遞增 revision、追加歷史並產生下游因果事件。CommitGate 不必自己執行昂貴 kernel，但不能只相信 executor 宣稱成功。

2.10 HistoryReplay：審計與可恢復記錄

職責：保存輸入事件、logical time、ruleset hash、seed/counter、ticket、route、candidate evidence、commit／reject、world snapshot hash、版本及後端資料。預測性 preload 不得被當作已發生世界事件寫入 canonical history。

2.11 EngineAdapter：宿主引擎的薄接入層

職責：轉換遊戲事件到型別化命令、安排行為／畫面同步時點、發佈唯讀世界投影、遵守主執行緒限制；不改寫世界權威規則、圖形框架或第三方引擎內建物理正確性。

3. 由 Intent 到 Commit 的分段運行協定

3.1 事件不直接執行

建議的分段協定：

Engine Input / Simulation Timer / Committed Event
  -> Intake + Durable Event Key
  -> WakeController (necessary obligations)
  -> Work Descriptor + Versioned Snapshot
  -> ScaleBridge / FormAnnotator (optional, may return Unknown)
  -> RoutePlanner (FormBlind or FormAware)
  -> Hard Gate / ResourceAllocator / Reservation
  -> CandidateExecutor (CPU, GPU, hybrid, reuse)
  -> CandidateReceipt (not canonical)
  -> CommitGate (revalidate everything required)
  -> Canonical Revision + Event Journal
  -> Read-only World Projection / Engine Render

外部遊戲事件即使已抵達，也只代表存在需判定的意圖。禁止讓外部 callback 直接保證世界已完成某項計算。

3.2 五種生命週期必須互不混淆

這個生命周期不是必須建立五個 thread；它可以在小遊戲中由一個排程器處理。重點是語義可分，而非刻意把簡單程式拆成微服務。

3.3 排程同意與權威提交的兩次驗證

第一次 Admission 針對現在的 snapshot 及資源，第二次 Commit 針對實際 candidate 和提交當下的世界、規則、資源與依賴。兩次檢查間發生的世界修訂、MOD 替換、buffer 世代變化、deadline 超時或設備故障，均可能使第一次許可失效。

3.4 最低事件鍵與冪等處理

每個被提交的世界義務至少包含 world_id、work_id、source_event_id、epoch、rule_revision 與可選 attempt_no。Retry 與 Replay 不得僅靠 event name 判斷是否已執行；應以穩定的 semantic idempotency key 避免同一轉帳、傷害或資產事件二次生效。

3.5 Backpressure 與 Deadline

當工作超過容量時，系統可以延後符合契約的工作、降低合法的觀察精度、切換為 CPU fallback 或暫停接收非必要預載；不可透過刪除已承諾時間義務或改寫世界歷史來假裝系統跟上時間。無 admissible route 應返回帶證據的 typed failure，讓遊戲選擇等待、降載或中止目前操作。

4. 形式資料契約與核心不變量

4.1 最小 World Stamp

WorldStamp {
    world_id,
    canonical_revision,
    simulation_epoch,
    rule_revision,
    schema_revision,
    mod_digest,
    optional_scale_certificate
}

真正存取時可採 interned ID；文字欄位僅供持久化及可讀審計，避免高頻熱路徑大量複製字串。

4.2 Work Descriptor

WorldWork {
    work_id, source_event_id,
    expected_world_stamp,
    read_dependencies, candidate_writes,
    guard, due_time_or_step, max_completion_window,
    precision_contract, scale_context,
    required_authority, optional_form_profile,
    admissible_backend_capabilities,
    fallback_policy
}

read_dependencies 不得只列已存在的鍵。若工作依賴「附近沒有敵人」「某任務目前不存在」等負向查詢，必須使用 range/predicate subscription、版本索引或採全域版本壁壘。沒有這些證據，不能允許稀疏更新跳過對該依賴的檢查。

4.3 法律／語義上的 Guard 與硬門檻

令候選路由集合為 $\mathcal R(q,t)$，只有當其滿足所有不可降級要求時才算可行：

$g_j$ 應至少檢查必要的身份、世界修訂、依賴、權威、schema/rule、期限、精度、尺度不變量、資源容量、輸出副作用界限及回復條件。分類和估計模型只能用來縮小候選或排序，不能宣告一個 hard fail 候選為合法。

4.4 Revision 與 Epoch 不是同一個時鐘

canonical_revision 表示權威變更序列；simulation_epoch 表示規則中的世界時間或步進；wall_clock 表示外部真實時間。沒有外部規則指定，不得把三者視為同一個遞增量。某次快轉可在一個 wall-clock interval 內處理多個 simulation epoch，且有多次 canonical commit；反之，即使 wall-clock 流逝，遊戲可能合法暫停世界時間。

4.5 資源活動量與邏輯大小分離

其中 $B_{\mathrm{work}}$ 是當前資源契約給出的工作集界限；它不代表邏輯世界資料的理論上界。對固定 RAM／VRAM 也不能假設所有重新載入免費，物化和移動成本必須納入路由總成本。

4.6 參考版先不嘗試絕對最優

是一個可比較候選的研究方向，並非聲稱 Runtime 已計算出完全已知的最優 Pareto front。未知延遲、未知 VRAM 可用量及高度動態 render load 應被記為 Unknown 或保守估計，而不是填上憑空的精確分數。

5. Rust 實作工程的最小封裝與里程碑

5.1 建議 workspace 目錄

cwsr-runtime/
  Cargo.toml
  crates/
    cwsr-core/          # ids, world stamp, candidate, typed errors
    cwsr-wake/          # event & deadline obligations
    cwsr-scale/         # anchors, ledgers, transitions
    cwsr-memory/        # region budgets & replica leases
    cwsr-router/        # hard gates & B4/B5/B6 profiles
    cwsr-executor-cpu/  # canonical deterministic oracle
    cwsr-executor-gpu/  # optional verified GPU adapter
    cwsr-commit/        # only canonical writer
    cwsr-replay/        # journal, fixtures, replay
    cwsr-adapter-godot/ # optional host connector
    cwsr-adapter-eve/   # optional EveWorld connector
  examples/
    city_flow/
    weather_grid/
    travel_jump/
  tests/
    conformance/
    failure_injection/
    benchmark_fixtures/

這是建議的未來工程拆分，而非宣稱上述 crate 已建立在現有 GitHub 倉庫中。早期可以先用單一 cwsr-reference crate 實驗，以降低過早模組化成本；確認契約穩定後再拆分。

5.2 階段性驗收順序

5.3 可重現的完成物清單

每個 milestone 至少生成：原始碼與 commit SHA、cargo lock（如適用）、工具鏈版本、執行平台、測試命令及 exit code、fixtures、金標結果、失敗樣本、CPU/GPU 驅動詳情（若適用）、基準報告與已知不支援列表。沒有這些證據，設計草圖仍應標記為 Draft。

6. 最小 Rust CPU 參考核心：正式範圍與使用方式

6.1 為什麼以兩個帳戶的資源轉移開始

若第一個示範就同時包含一百萬 NPC、流體模擬、GPU Kernel、多尺度城市與即時場景，錯誤來源將難以分離。本篇選擇一個單一權威世界、兩個有身份的非負整數資源帳戶、可追蹤的合法轉移事件作為最小 oracle。它雖簡單，仍能強制檢查在大型世界中同樣重要的七項條件：

1. 提交前的 candidate 不得改動世界；
2. 新舊 world revision 不得混用；
3. 規則、schema 與 MOD 版本必須吻合；
4. Event/Ticket 的時間義務必須到期；
5. 每個成功提交的 work ID 在該世界不得重複生效；
6. 資源轉移遵守非負性及總量守恆；
7. 已提交事件可從相同初始世界重播，得到相同金標狀態。

這是語義參考而不是最佳化 benchmark；其中一個保守 world_revision barrier 會導致所有其他新 commit 使舊 receipt 失效，未來若要並行化，必須另立 per-key 或 domain-based dependency proof。

6.2 Rust 參考程式的驗證狀態

下列程式刻意使用 Rust 2021 Edition 與標準庫，不依賴 GPU 驅動及第三方 crate。其角色是 Paper 07 的可複製實作候選原始碼，包括 6 個 Rust #[test] 測例；本輪已做文本及不變量審閱，但無可用 rustc／cargo 執行環境，故不能宣稱已確認其編譯與測試結果。若本地 Agent 複製後編譯失敗，應把錯誤作為待修的工程證據，不得回寫研究稿為「測試通過」。

範例提供的是純 CPU reference；GPU、FormAware、真正的多尺度與引擎適配不是本段程式碼已實現的功能。

6.3 建議指令與目錄

在具有 Rust 工具鏈的本機工作區，建立 cwsr_reference 專案，分別填入以下 Cargo.toml 與 src/lib.rs，從專案根目錄執行：

cargo fmt --all -- --check
cargo check --all-targets
cargo test --all-targets
cargo clippy --all-targets -- -D warnings

在首次貼入時，可先執行 cargo fmt --all 統一 Rust 格式，再執行上列檢查。若 CI 執行 clippy，需要指定所用 Rust toolchain 的版本並記錄實際 exit code。

Cargo.toml

[package]
name = "cwsr_reference"
version = "0.1.0"
edition = "2021"
publish = false

[lib]
path = "src/lib.rs"

src/lib.rs

//! CWSR Paper 07: minimal single-writer CPU semantic oracle.
//! This is a deliberately narrow reference candidate, not a GPU runtime.
use std::collections::{BTreeMap, BTreeSet};

#[derive(Clone, Copy, Debug, PartialEq, Eq, PartialOrd, Ord)]
pub struct StateId(pub u64);

#[derive(Clone, Copy, Debug, PartialEq, Eq)]
pub struct WorldStamp {
    pub world_id: u64,
    pub revision: u64,
    pub epoch: u64,
    pub rule_revision: u64,
    pub schema_revision: u64,
    pub mod_digest: u64, // Toy fixture token; not a cryptographic hash.
}

#[derive(Clone, Copy, Debug, PartialEq, Eq)]
pub enum Precision { Exact }

#[derive(Clone, Copy, Debug, PartialEq, Eq)]
pub struct Transfer {
    pub from: StateId,
    pub to: StateId,
    pub amount: i64,
}

#[derive(Clone, Debug, PartialEq, Eq)]
pub struct Ticket {
    pub work_id: u64,
    pub source_event_id: u64,
    pub stamp: WorldStamp,
    pub due_epoch: u64,
    pub transfer: Transfer,
    pub precision: Precision,
}

#[derive(Clone, Copy, Debug)]
pub struct ResourceBudget {
    pub cpu_allowed: bool,
    pub ram_free_bytes: u64,
}

#[derive(Clone, Copy, Debug, PartialEq, Eq)]
pub struct CpuLease {
    work_id: u64,
    stamp: WorldStamp,
    expires_epoch: u64,
    reserved_bytes: u64,
}

#[derive(Clone, Debug, PartialEq, Eq)]
pub struct CandidateReceipt {
    work_id: u64,
    stamp: WorldStamp,
    writes: [(StateId, i64); 2],
    total_before: i128,
    total_after: i128,
    algorithm: &'static str,
}

#[derive(Clone, Debug, PartialEq, Eq)]
pub struct JournalRecord {
    pub ticket: Ticket,
    pub revision_after: u64,
    pub digest_after: u64,
}

#[derive(Debug, Clone, Copy, PartialEq, Eq)]
pub enum Failure {
    InvalidFixture,
    WrongWorld,
    StaleWorld,
    WrongRules,
    WrongSchema,
    WrongMod,
    NotDue,
    DuplicateWork,
    BadTransfer,
    UnknownState,
    InsufficientBalance,
    ArithmeticOverflow,
    CpuForbidden,
    CapacityExceeded,
    LeaseMismatch,
    LeaseExpired,
    ReceiptMismatch,
    WorldInvariantViolation,
    RevisionOverflow,
    ReplayMismatch,
}

#[derive(Clone, Debug)]
pub struct World {
    stamp: WorldStamp,
    balances: BTreeMap<StateId, i64>,
    applied: BTreeSet<u64>,
    journal: Vec<JournalRecord>,
}

impl World {
    pub fn new(stamp: WorldStamp, a: (StateId, i64), b: (StateId, i64))
        -> Result<Self, Failure>
    {
        if stamp.revision != 0 || a.0 == b.0 || a.1 < 0 || b.1 < 0 {
            return Err(Failure::InvalidFixture);
        }
        let mut balances = BTreeMap::new();
        balances.insert(a.0, a.1);
        balances.insert(b.0, b.1);
        Ok(Self { stamp, balances, applied: BTreeSet::new(), journal: Vec::new() })
    }

    pub fn stamp(&self) -> WorldStamp { self.stamp }
    pub fn get(&self, key: StateId) -> Option<i64> { self.balances.get(&key).copied() }
    pub fn journal(&self) -> &[JournalRecord] { &self.journal }
    pub fn total(&self) -> i128 {
        self.balances.values().map(|v| i128::from(*v)).sum()
    }

    fn check_ticket(&self, ticket: &Ticket) -> Result<(), Failure> {
        let s = ticket.stamp;
        if s.world_id != self.stamp.world_id { return Err(Failure::WrongWorld); }
        if s.rule_revision != self.stamp.rule_revision { return Err(Failure::WrongRules); }
        if s.schema_revision != self.stamp.schema_revision { return Err(Failure::WrongSchema); }
        if s.mod_digest != self.stamp.mod_digest { return Err(Failure::WrongMod); }
        if s.revision != self.stamp.revision || s.epoch != self.stamp.epoch {
            return Err(Failure::StaleWorld);
        }
        if self.stamp.epoch < ticket.due_epoch { return Err(Failure::NotDue); }
        if self.applied.contains(&ticket.work_id) { return Err(Failure::DuplicateWork); }
        let x = ticket.transfer;
        if x.amount <= 0 || x.from == x.to { return Err(Failure::BadTransfer); }
        let from = self.get(x.from).ok_or(Failure::UnknownState)?;
        self.get(x.to).ok_or(Failure::UnknownState)?;
        if from < x.amount { return Err(Failure::InsufficientBalance); }
        Ok(())
    }

    fn expected_writes(&self, t: &Ticket) -> Result<[(StateId, i64); 2], Failure> {
        let x = t.transfer;
        let a = self.get(x.from).ok_or(Failure::UnknownState)?;
        let b = self.get(x.to).ok_or(Failure::UnknownState)?;
        let next_a = a.checked_sub(x.amount).ok_or(Failure::ArithmeticOverflow)?;
        let next_b = b.checked_add(x.amount).ok_or(Failure::ArithmeticOverflow)?;
        Ok([(x.from, next_a), (x.to, next_b)])
    }

    /// Fixture digest only: stable across map iteration order, not collision-resistant.
    pub fn digest(&self) -> u64 {
        let mut h = 0xcbf29ce484222325_u64;
        for (key, value) in &self.balances {
            for byte in key.0.to_le_bytes().into_iter()
                .chain(value.to_le_bytes().into_iter())
            {
                h ^= u64::from(byte);
                h = h.wrapping_mul(0x100000001b3);
            }
        }
        h
    }

    pub fn verify_and_commit(&mut self, t: &Ticket, lease: &CpuLease,
        r: &CandidateReceipt) -> Result<u64, Failure>
    {
        self.check_ticket(t)?;
        check_lease(self, t, lease)?;
        let expected = self.expected_writes(t)?;
        let before = self.total();
        let after = before - i128::from(self.get(expected[0].0).unwrap())
            - i128::from(self.get(expected[1].0).unwrap())
            + i128::from(expected[0].1) + i128::from(expected[1].1);
        if r.work_id != t.work_id || r.stamp != self.stamp || r.writes != expected
            || r.algorithm != "cpu-transfer-v1" || r.total_before != before
            || r.total_after != after
        {
            return Err(Failure::ReceiptMismatch);
        }
        if before != after { return Err(Failure::WorldInvariantViolation); }
        let next_rev = self.stamp.revision.checked_add(1)
            .ok_or(Failure::RevisionOverflow)?;
        // All checks above; no fallible step is allowed after the first world write.
        self.balances.insert(expected[0].0, expected[0].1);
        self.balances.insert(expected[1].0, expected[1].1);
        self.stamp.revision = next_rev;
        self.applied.insert(t.work_id);
        let digest = self.digest();
        self.journal.push(JournalRecord {
            ticket: t.clone(), revision_after: next_rev, digest_after: digest,
        });
        Ok(next_rev)
    }
}

pub fn admit_cpu(world: &World, ticket: &Ticket,
    budget: ResourceBudget) -> Result<CpuLease, Failure>
{
    world.check_ticket(ticket)?;
    if !budget.cpu_allowed { return Err(Failure::CpuForbidden); }
    // A conceptual bookkeeping reservation; not an OS allocator reservation.
    const RESERVATION_BYTES: u64 = 128;
    if budget.ram_free_bytes < RESERVATION_BYTES {
        return Err(Failure::CapacityExceeded);
    }
    let expiry = world.stamp.epoch.checked_add(1)
        .ok_or(Failure::LeaseExpired)?;
    Ok(CpuLease { work_id: ticket.work_id, stamp: world.stamp,
        expires_epoch: expiry, reserved_bytes: RESERVATION_BYTES })
}

fn check_lease(world: &World, ticket: &Ticket,
    lease: &CpuLease) -> Result<(), Failure>
{
    if lease.work_id != ticket.work_id || lease.stamp != world.stamp
        || lease.reserved_bytes != 128
    {
        return Err(Failure::LeaseMismatch);
    }
    if world.stamp.epoch > lease.expires_epoch {
        return Err(Failure::LeaseExpired);
    }
    Ok(())
}

pub fn execute_cpu(world: &World, t: &Ticket,
    lease: &CpuLease) -> Result<CandidateReceipt, Failure>
{
    world.check_ticket(t)?;
    check_lease(world, t, lease)?;
    let writes = world.expected_writes(t)?;
    let before = world.total();
    let after = before - i128::from(world.get(writes[0].0).unwrap())
        - i128::from(world.get(writes[1].0).unwrap())
        + i128::from(writes[0].1) + i128::from(writes[1].1);
    Ok(CandidateReceipt { work_id: t.work_id, stamp: world.stamp,
        writes, total_before: before, total_after: after,
        algorithm: "cpu-transfer-v1" })
}

pub fn replay(initial: World, records: &[JournalRecord],
    budget: ResourceBudget) -> Result<World, Failure>
{
    let mut world = initial;
    for record in records {
        let t = &record.ticket;
        let lease = admit_cpu(&world, t, budget)?;
        let receipt = execute_cpu(&world, t, &lease)?;
        let revision = world.verify_and_commit(t, &lease, &receipt)?;
        if revision != record.revision_after || world.digest() != record.digest_after {
            return Err(Failure::ReplayMismatch);
        }
    }
    Ok(world)
}

#[cfg(test)]
mod tests {
    use super::*;

    fn stamp() -> WorldStamp { WorldStamp { world_id: 7, revision: 0,
        epoch: 10, rule_revision: 1, schema_revision: 1, mod_digest: 0 } }
    fn world() -> World {
        World::new(stamp(), (StateId(1), 100), (StateId(2), 10)).unwrap()
    }
    fn ticket(w: &World, id: u64, amount: i64, due: u64) -> Ticket {
        Ticket { work_id: id, source_event_id: id + 100,
            stamp: w.stamp(), due_epoch: due,
            transfer: Transfer { from: StateId(1), to: StateId(2), amount },
            precision: Precision::Exact }
    }
    fn budget() -> ResourceBudget { ResourceBudget {cpu_allowed:true, ram_free_bytes: 4096} }

    #[test]
    fn transfer_commit_and_replay() {
        let mut w = world();
        let first = ticket(&w, 1, 30, 10);
        let lease = admit_cpu(&w, &first, budget()).unwrap();
        let receipt = execute_cpu(&w, &first, &lease).unwrap();
        assert_eq!(w.get(StateId(1)), Some(100)); // Candidate does not mutate.
        assert_eq!(w.verify_and_commit(&first, &lease, &receipt), Ok(1));
        assert_eq!(w.get(StateId(1)), Some(70));
        assert_eq!(w.get(StateId(2)), Some(40));
        let saved = w.journal().to_vec();
        let reconstructed = replay(world(), &saved, budget()).unwrap();
        assert_eq!(w.digest(), reconstructed.digest());
    }

    #[test]
    fn duplicate_work_rejected() {
        let mut w = world();
        let t = ticket(&w, 1, 4, 10);
        let lease = admit_cpu(&w, &t, budget()).unwrap();
        let r = execute_cpu(&w, &t, &lease).unwrap();
        w.verify_and_commit(&t, &lease, &r).unwrap();
        assert_eq!(admit_cpu(&w, &t, budget()), Err(Failure::StaleWorld));
        let retried_with_current_stamp = ticket(&w, 1, 4, 10);
        assert_eq!(admit_cpu(&w, &retried_with_current_stamp, budget()),
            Err(Failure::DuplicateWork));
    }

    #[test]
    fn stale_candidate_cannot_overwrite_new_world() {
        let mut w = world();
        let old = ticket(&w, 4, 5, 10);
        let old_lease = admit_cpu(&w, &old, budget()).unwrap();
        let old_receipt = execute_cpu(&w, &old, &old_lease).unwrap();
        let new = ticket(&w, 5, 6, 10);
        let new_lease = admit_cpu(&w, &new, budget()).unwrap();
        let new_receipt = execute_cpu(&w, &new, &new_lease).unwrap();
        w.verify_and_commit(&new, &new_lease, &new_receipt).unwrap();
        assert_eq!(w.verify_and_commit(&old, &old_lease, &old_receipt),
            Err(Failure::StaleWorld));
    }

    #[test]
    fn altered_receipt_does_not_commit() {
        let mut w = world();
        let t = ticket(&w, 8, 5, 10);
        let lease = admit_cpu(&w, &t, budget()).unwrap();
        let mut r = execute_cpu(&w, &t, &lease).unwrap();
        r.writes[0].1 = 123;
        assert_eq!(w.verify_and_commit(&t, &lease, &r),
            Err(Failure::ReceiptMismatch));
        assert_eq!(w.stamp().revision, 0);
    }

    #[test]
    fn resource_deadline_and_rule_hard_gates() {
        let w = world();
        let future = ticket(&w, 1, 3, 11);
        assert_eq!(admit_cpu(&w, &future, budget()), Err(Failure::NotDue));
        let ready = ticket(&w, 2, 3, 10);
        assert_eq!(admit_cpu(&w, &ready, ResourceBudget {cpu_allowed:false,
            ram_free_bytes: 4096}), Err(Failure::CpuForbidden));
        assert_eq!(admit_cpu(&w, &ready, ResourceBudget {cpu_allowed:true,
            ram_free_bytes: 0}), Err(Failure::CapacityExceeded));
        let mut outdated = ready.clone();
        outdated.stamp.rule_revision = 99;
        assert_eq!(admit_cpu(&w, &outdated, budget()), Err(Failure::WrongRules));
    }

    #[test]
    fn invalid_transfer_is_never_proposed() {
        let w = world();
        let too_large = ticket(&w, 11, 200, 10);
        assert_eq!(admit_cpu(&w, &too_large, budget()),
            Err(Failure::InsufficientBalance));
        let reversed = ticket(&w, 12, -1, 10);
        assert_eq!(admit_cpu(&w, &reversed, budget()), Err(Failure::BadTransfer));
    }
}

6.4 程式碼對應的正式語義

WorldStamp 將世界身份、版本、時間、規則、schema 與 MOD digest 綁定。此處 mod_digest: u64 只是 fixture 用的識別 token，不是具碰撞抵抗能力的 hash；正式引擎應改用經驗證的內容摘要／簽章、來源鏈及版本策略。StateId 是穩定邏輯身份，不可使用 GPU buffer offset 取代。

World::new 只接受兩個非負的初始帳戶且 revision 為零；這是為了防止讀者誤以為示範已涵蓋一般市場、多資產、跨尺度事件或大規模 ECS。未來資料匯入需保留 schema validation、重複 ID、資產上限及事件帳本校驗。

admit_cpu 根據到期、身份與容量生成一張邏輯 CPU lease；reserved_bytes 是簡化簿記示範，沒有實際向 Windows 或 OS 預留實體記憶體。因此這個 128-byte 配額不應被用作記憶體最佳化測試證據。

execute_cpu 只讀世界，產生 CandidateReceipt；verify_and_commit 重算合法轉帳結果，檢查內容是否完全等價，並由唯一 writer 完成實際修改。此處的重算很便宜，所以採用最保守的 full oracle；將來 GPU 候選不能假設一律以全量 CPU 重算驗證，必須依錯誤契約選擇 hash、抽樣、區間證明、精確 oracle 或其他具證據的驗證方案。

World::digest 是純粹示範 deterministic fixture digest，未包含全部遊戲事件、規則資料及未完成義務，也不是密碼學證據。正式存檔必須採用更強的狀態／歷史摘要契約，不能把它當成 tamper-proof 簽章。

6.5 測例的涵蓋範圍

上述是預期測例，本輪無 Rust toolchain 的情況下未聲稱 PASS。對審稿或工程交接，務必附上可複製的真實 cargo test 輸出及編譯器版本。

6.6 單執行緒示例不等於跨執行緒安全

參考程式以 &mut World 維持單一可變 writer，在程序內可清晰表示「只有 Commit Gate 修改世界」。這並不自動保證：多執行緒中訂閱／事件的原子性、跨 CPU/GPU 記憶體可見性、裝置佇列完成順序、硬碟寫入原子性或 Rust FFI 的記憶體安全。擴充這些功能時必須另加競態、故障注入與 replay tests。

7. 從 CPU Oracle 走向可替換多後端 Runtime

7.1 工程化類型簽名

成熟版可將規劃、資源許可、計算及提交表示成四個接口。以下是設計草案，不是本篇第 6 章 lib.rs 已實現的四個 trait：

pub trait RoutePlanner {
    fn propose(&self, req: &WorldRouteRequest)
        -> Result<RouteProposal, RouteError>;
}
pub trait ExecutionAdmission {
    fn admit(&self, proposal: &RouteProposal)
        -> Result<Reservation, RouteError>;
}
pub trait CandidateExecutor {
    fn execute(&self, lease: &Reservation,
        input: &ImmutableSnapshot)
        -> Result<CandidateReceipt, RouteError>;
}
pub trait WorldCommitAuthority {
    fn verify_and_commit(&mut self, proposal: &RouteProposal,
        receipt: &CandidateReceipt)
        -> Result<CommittedWorldRevision, RouteError>;
}

WorldRouteRequest、RouteProposal、Reservation、ImmutableSnapshot 與 CommittedWorldRevision 應在正式 crate 中定義為具版本及審計能力的 typed structs，不應在 API 中隱藏成未受檢查的 serde_json::Value 或裸 void*。上述接口有意保持可由不同引擎實作；不能推斷此處已有通用跨平台 FFI ABI。

7.2 Snapshot Token 不應只是整數

正式 snapshot token 除世界 revision 外，還應攜帶 rule/schema/MOD lineage、時間切面、讀集合版本及使用的精度契約。若 GPU 在另一個 process 或佇列上持有更舊副本，僅比較 canonical revision 可能不足以判斷副本與候選是否有效。ReplicaRef、device generation、completion fence 和 snapshot identity 必須相互綁定。

7.3 候選結果需要證據族，不只是 bool success

推薦的 receipt 描述：

CandidateReceipt {
    work_id, route_id, input_world_stamp,
    dependency_versions, required_lease_ids,
    backend_name, backend_version,
    algorithm_hash, shader_hash_if_any,
    device_submission_id, device_fence_if_any,
    output_replica_generation,
    precision_evidence, scale_transition_evidence,
    output_candidate_writes,
    measured_costs, timestamp_and_epoch,
    error_or_recovery_code
}

CPU 可以沒有 shader 與 device fence，不能因此以虛假的 GPU 完成事件補齊欄位。當後端報告 device loss 時，其受影響候選都必須進入 invalid/retry，而不是由另一個未校驗 buffer 繼續寫入。

7.4 Backend Feature Negotiation

GpuComputeAvailable、GpuKernelVerified、ExactPrecisionSupported、BudgetReserved、RenderHeadroom、ReadbackPathAvailable 與 RecoveryPathVerified 應當分別檢查。裝置支援 Compute Shader 不等於指定世界 kernel 可以以相同數值語義運行；平台差異需要保守 fallback。

7.5 退出 GPU 路徑也要有成本

使用 GPU 的主要問題不只是 dispatch latency，而是進入、維持及退出某段設備常駐工作鏈的完整代價。CPU／GPU 決策至少比較 kernel、batch、transfer、synchronization、render contention、memory residency、readback、verification、fallback probability 及 route-switch cost。若 GPU kernel 很快，但必須每幀將小量結果同步回 CPU，選擇 CPU route 可能更合理。

8. 24／72 FormBlind／FormAware 雙軌路由

8.1 為什麼需要兩個真正公平的實驗組

若新 RoutePlanner 同時加入 SIMD、事件化、GPU 批次、資料布局優化和 24／72 classification，就算勝過舊遊戲迴圈，也不能分辨究竟是什麼帶來收益。Paper 06 已規定 B4／B5 近似「只差分類註記」的對照；Paper 07 必須在同一段演算法、硬體、硬門檻與成本證據上保存這個實驗能力。

8.2 Canonical Form 只描述語境中的計算形態

保留原始 24 格：

其中 $\mathfrak B_2$ 是 Continuous／Discrete 底空間， $\mathfrak U_4$ 是 Sequential／Jump／Parallel／Recognition 更新模式， $\mathfrak O_3$ 是 Continuous／Discrete／Single-Measure-Refusal 觀察類型。

72 格在此基礎上加入候選轉移律：

$\mathsf F$ 表示函數式／確定性型， $\mathsf K$ 表示機率核型， $\mathsf Q$ 表示相干／量子通道型。將 $\mathsf Q$ 寫入分類空間，不表示 PC 遊戲有量子硬體或必須模擬量子通道。未建立明確 semantics、分類證據或 hardware mapping 時，應標記為 Unclassified 或 UnsupportedForm，而不是假設任何 GPU 等價。

8.3 建議的 FormProfile 結構

FormProfile {
    basis_version, observation_context_id,
    rule_revision, scale_contract_id,
    kind = Single | Set | Path | Stack | Unclassified,
    forms[], classification_evidence_id,
    classification_cost, expiry_condition
}

對一個混合「天氣網格 + 局部豪雨觸發 + 城市洪水離散事件」的工作，不應強迫整條運算被貼成單一類別。它可能包含多個連續場與離散觸發組件，形式相對於不同工作片段而異。

8.4 硬門檻之前不能直接按 Form 選裝置

錯誤範例：

if update_mode == Parallel { backend = GPU; }
else if update_mode == Sequential { backend = CPU; }

正確方向：先建立合法工作候選，依依賴、精度、資源與 deadlines 做硬過濾，然後以 FormProfile、work shape 和成本證據縮小候選或排序；不具備有效證據時採同一個 FormBlind decision 或固定 CPU fallback。

8.5 Classification Tax 必須包含在總成本

假設加入 FormAware 後，分類和維護 metadata 的成本為 $C_{\mathrm{form}}$，優化路由節省的工作成本為 $\Delta C_{\mathrm{route}}$，則只有在指定工作條件下：

且沒有更差的義務期限、精度或尾延遲時，才可能形成淨效益。這不是全域性能定理；成本與差值須由 Paper 08 測量。

8.6 Form-aware ablation 清單

• 只停用 FormAnnotation，其餘 routing policy 不變。
• 只停用 Form-driven candidate pruning，保留 metadata trace。
• 只停用 hysteresis，觀察 churn 及 p99。
• 將 Unclassified 全部轉成 FormBlind，檢查未知比例。
• 對相同 workload 更換 observation resolution，檢查分類與效能是否穩定。
• 固定資料布局、batching、kernel、GPU clock 及 render workload，避免比較不公平。

9. GPU 世界小流的真正實作邊界

9.1 因果小流不是「一個事件對應一個 dispatch」

Paper 05 的 CausalMicroflow 指具備已驗證依賴、guard、期限與結果契約的局部世界工作。若每一個 NPC 狀態變化都產生一次 GPU submit，很可能因同步、驅動及資料搬移而比 CPU 更慢。Runtime 應由工作形狀及 hazard 安全規則決定 batch frontier，限制最大等待窗口與最大資料量。

9.2 GPU Candidate Batch

GpuCandidateBatch {
    world_stamp, sim_epoch, domain_id,
    stable_work_ids[], resource_lease,
    input_replica_refs[], output_replica_refs[],
    read_write_hazard_certificate,
    kernel_id, kernel_hash, dispatch_shape,
    deadline_bounds, precision_contract,
    submission_id, completion_fence,
    verification_policy
}

任何缺失依賴、共享寫入衝突、不可對齊時間切面的工作，都應在 batch 前被拆開或退回 CPU／序列執行；不能因為 GPU 很適合平行運算就忽略世界事件的可觀測次序。

9.3 完成事件的順序要求

CPU plan -> budget lease -> buffer creation/validation
-> GPU submission -> in-flight
-> fence reached -> readback or device-side evidence
-> candidate receipt -> Commit Gate -> world revision

GPU dispatch submitted、GPU command completed、candidate validated、world committed、render frame presented 至少是五個不同概念。若上游世界在 fence 前已變，完成後的 GPU 候選可能需要丟棄，不能為省成本繞過版本規則。

9.4 對消費級 GPU 的公平性

在 GPU 渲染高壓時應保留 graphics headroom，必要時降低背景 compute batch 而不是硬把顯示卡推到耗盡。RAM、VRAM、PCIe 傳輸、upload/readback queues 和 CPU 程式時間一起納入成本。不同顯示卡的 VRAM、記憶體頻寬與 compute capability 差異可能讓最佳路由不同，不能假設「消費級顯卡都應 GPU-first」。

9.5 裝置常駐資料鏈

若連續的 GPU 世界工作合法共用同一代版本的資料，結果可留在 GPU，讓下一個 kernel 使用，不必在每個階段回 CPU。這有可能降低傳輸與 staging 成本；但只要某階段存在 CPU-side authoritative decision、外部不可延遲事件或跨尺度證據義務，就必須按規則同步或產生可由 Gate 使用的等價證書。

9.6 GPU 故障與恢復程序

9.7 第一版 GPU kernel 應選低風險負載

優先選擇一個可精確對照 CPU 的城市商品需求更新或純數值網格算子；使用固定 input layout、已知精度契約及可重現 fixture。先處理單個 kernel family 的 device fence 和 CPU oracle，再擴充更多世界子系統；不宜一開始選擇帶大量腳本分支、MOD 可變規則或全域即時副作用的 NPC AI。

10. 宏觀—中觀—微觀模型的 Adapter 契約

10.1 Scale View 不是三個可互相覆蓋的世界副本

一個城鎮的微觀居民、街區活動、商品物流及宏觀經濟不是三份彼此競爭的 canonical world。它們是同一權威世界在不同尺度／時間精度下的合法視圖。粗尺度計算可使用摘要，但摘要無權擦除已提交身份、唯一物品、事件或資產帳本。

10.2 最小跨尺度輸入

ScaleWorkContext {
    world_stamp,
    target_domain_id,
    current_scale_view,
    proposed_scale_view,
    identity_anchor_index,
    event_journal_position,
    boundary_flow_ledger,
    temporal_cut,
    precision_contract,
    transition_policy_id,
    materialization_budget
}

粗尺度世界與細尺度世界不能僅依鏡頭距離判斷切換。若玩家遠在外地，但遠方發生會改寫重要角色命運的世界事件，也可能需要更細的因果處理；相反地，近處大量未參與互動的背景人口未必都要每幀具備完整行為樹。

10.3 Aggregation／Refinement 須有來源與不變量

假設微觀狀態集合為 $X_{\mu}$，中觀摘要為 $X_m$，宏觀摘要為 $X_M$。可考慮有條件的聚合映射：

但一般不成立：

因此 Runtime 在尺度細化時，必須從 identity anchor、event journal、既有保存個體資料與明示的生成政策產生與已提交事實一致的條件實現，不得將原本不可恢復的微觀歷史偽裝為觀測結果。

10.4 時間切面的提交責任

TemporalCut 不是單一 float time。它應記錄各尺度可讀取的已提交進度、跨區域事件邊界、尚未完成的高優先級義務及源規則 epoch。若跨城市物流在 epoch 20 已從 A 扣除、卻直到 epoch 25 才到達 B，狀態可以合法代表在途資產；但不允許 A 和 B 同時將同一批貨物記作自由可用的庫存。

10.5 區域交換 Ledger 的保守規則

• 流量須以穩定 Event ID 和來源／目的域記錄。
• 微觀事件造成的上行變化須在宏觀摘要中可追溯。
• 宏觀政策造成的下行變化須有生效 epoch，不得穿越既有已提交歷史。
• 對資產、人口等有守恆要求的量，需有跨域 ledger 與增減來源證據。
• 經過近似的群體狀態需綁定誤差界限，不能因 UI 不可見而默認精確。

10.6 具名 NPC 與匿名人口要分不同約束

具名角色的身份、關係、死亡、承諾及唯一持有物等資料可能具有不可丟失的敘事義務；匿名人口可按規則採統計描述或程序化條件細化，但兩者不能因為都叫 NPC 而互換恢復策略。ScaleBridge 應先判斷哪些資訊可聚合、哪些需要錨點或不可壓縮來源。

10.7 跨尺度候選的拒絕回條

不具備時間切面、identity anchors、不可逆歷史來源或合法誤差界限時，回傳 ScaleProofMissing、TemporalCutMismatch、UnrecoverableHistory 或 PrecisionContractViolation。FallbackToMicro 並非必然可行；若恢復資料已丟失，必須承認安全路由不存在。

11. 記憶體、所有權與版本化物化協定

11.1 Rust 語言所有權與遊戲世界權威不同

Rust 借用與生命週期可防止許多未定義記憶體操作；但 &mut T 不自動證明世界因果、跨尺度歷史或交易規則正確。需要另行區分：

1. Memory Owner： 誰管理 CPU/GPU buffer。
2. Logical Owner： 哪個狀態身份及版本被引用。
3. Execution Authority： 哪個計算工作能讀寫候選。
4. Mutation Authority： 哪個 Commit Gate 有權修改 canonical world。
5. History Custodian： 誰維護可恢復的事件及重播證據。

這些權限可以在同一進程內實作，但不能在資料模型上混同。

11.2 物化狀態機

Addressable -> MaterializeRequested -> Allocated -> Validated
  -> Resident -> Pinned / InFlight / Idle
  -> EvictionCandidate -> EvictionVerified -> Released
                         \-> RecoveryNeeded -> Rematerialize

Released 並不意味世界事實被刪除，前提是狀態存在可合法恢復的邏輯表示或歷史來源；對不能重建的資料，系統不得僅靠低優先級標籤就予以回收。

11.3 有界但可調整的記憶體宣告

每個區域可預先宣告：minimum_resident、soft_limit、hard_limit、growth_policy、eviction_priority、recovery_cost、pinned_generation、deadline_reserve 和 preferred_devices。這表示不必於啟動時實際配置所有容量，而非無成本無界使用記憶體。

11.4 Device Fence 與借用關係

如果 GPU kernel 正在讀取 input buffer，或渲染工作正在消費該 generation，CPU 端不得因 Rust 變數已離開 lexical scope 就提前重用裝置底層記憶體。GpuReplicaLease 應記錄 queue、submission、fence、generation 和所有尚未結束的讀寫使用者；只有確認沒有 in-flight 使用者且有合法恢復路徑時，才能 evict。

11.5 Copy-on-Write 不是版本安全的充分條件

即使使用 CoW，若新寫入頁面仍被標記為舊 ruleset 的合法計算結果，仍可能產生邏輯污染。版本判斷須包含計算結果真正依賴的 rule、schema、MOD、scale、precision 和 source evidence，不能只看 page pointer 是否變更。

11.6 Memory Pressure 不能破壞玩家畫面

背景 world compute 可使用被管理的 VRAM quota，但不能將 GPU 畫面輸出視為永遠低優先級。對玩家輸入延遲、渲染幀時間和已承諾世界期限，應提供可配置的 hard/soft constraints。當同時無法滿足所有 hard requirements，允許拒絕或暫停相關操作，而不是默默跳過必要世界事件。

12. Godot Engine 的薄適配規格

12.1 為什麼不需要取代 Godot

Godot 既有的 SceneTree、輸入、UI、動畫、物理、渲染、資源載入與場景編排可以繼續運作。CWSR 只對指定的世界模擬子系統提供一條可獨立測試的狀態與計算路徑。強行接管所有 Node 每幀邏輯，既不符合 CWSR 的選擇性原則，也會提高原型風險。

12.2 Host API 的建議邊界

CwsrHost.submit_intent(intent: TypedGameplayIntent) -> TicketId | Rejection
CwsrHost.advance_simulation(requested_epoch, budget) -> StepOutcome
CwsrHost.poll_world_revision() -> RevisionInfo
CwsrHost.read_projection(scope, revision) -> ReadOnlyProjection
CwsrHost.acknowledge_projection(revision) -> Ack
CwsrHost.query_pending_obligations() -> ObligationSummary
CwsrHost.pause_world_time(reason) -> TimePolicyResult

以上為建議 API，並非 Godot 當前已有的原生函式名。真正 GDExtension／FFI 綁定需要依正式 Godot 版本及 ABI 文檔另行實作驗證。

12.3 一個可行的 Godot host 循環

_process(delta):
    gather_ui_and_input_intents()
    enqueue_non_authoritative_intents()
    consume_read_only_projection_if_ready()
    update_visible_nodes_on_main_thread()

_physics_process(fixed_delta):
    if world_time_policy_allows:
        submit_due_simulation_epoch(fixed_delta)
    process_bounded_runtime_results()

它只是 Host-side pseudocode，不是可直接貼入的合法 GDScript。主執行緒與工作執行緒的實際互動應遵循特定 Godot 版本的資源與節點 thread-safety 規則；不可因 CWSR 使用 Rust 就默認任意 SceneTree 操作可並行。

12.4 UI 只讀投影，不是世界副本作主

玩家所看到的角色屬性、背包、城鎮商品價格與 NPC 日程，可由 Runtime 已提交 revision 生成唯讀 projection。UI 動畫、字串漸變與材質插值是呈現層效果，不得自行代表權威物品已增加或角色已死亡。UI 暫時落後於世界可被允許，但必須有 consistency/freshness policy。

12.5 既有物理及動畫系統可維持固定步進

連續碰撞、骨骼動畫和某些物理積分需要連續或固定更新時，保留既有 Godot 行為。CWSR 可管理周邊世界狀態、休眠與遠端區域經濟，但不能為了統一性而要求將所有高頻狀態轉成離散事件。

12.6 避免主迴圈中的同步等待

同步等待 GPU Readback、檔案序列化或跨執行緒鎖，可能造成可觀測掉幀。Host Adapter 應在設定的 frame budget 內收集已完成回執，不等待不必要的遠端事件；對不可延後的玩家操作，提供正確但可能較慢的 CPU 路徑，或給出明示的進度等待機制。

12.7 Engine Binding 的版本與錯誤面

Host adapter 的版本表至少包含：engine_version、cwsr_schema_version、ffi_abi_version、world_ruleset_digest、gpu_backend_version。若版本不兼容，應拒絕載入危險世界寫入接口，允許只讀診斷或 migration path。沒有正式轉換契約的舊存檔不得被強制解讀為當前版本。

13. EveWorld Engine 與其他引擎的抽象介接

13.1 不把 EveWorld 當成已完成的依賴

EveWorld Engine 可成為 CWSR 未來實驗 host，但本文沒有讀取並驗證其現有最新實作的全部接口，因此不聲稱存在相容的現成 Rust plugin。優先採 WorldHostAdapter 抽象：CWSR 保持對單一遊戲引擎的依賴最小化；EveWorld 可選擇從 GameLoop、WorldModel、Scheduler 或 SimulationServices 其中合適層級接入。

13.2 可共享的跨引擎契約

• 同一 WorldStamp 與 Ticket 格式。
• 同一提交策略及 idempotent work ID。
• 同一 fixture 與重播工具。
• 同一基本可觀測狀態核對。
• 不同 engine adapter 只可改變顯示與事件輸入映射，不能任意改寫核心世界規則。

13.3 三種合法整合模式

模式 A — Library Mode： Runtime 作為 Rust 動態／靜態庫；遊戲主迴圈直接呼叫。適合精簡、延遲敏感的單機測試。

模式 B — Process Mode： 世界模擬獨立進程，以本地 IPC 發送 intent 和 read-only projection。適合隔離故障及調試，但增加序列化與 IPC 成本。

模式 C — Offline Simulation Mode： 不開圖形視窗，只載入 fixture、跑世界時間、輸出可重播結果；適合 Paper 08 的大規模語義與效能測試。

三者可採相同語義但效能未必相同；初版通常應優先使用離線模式驗證規則，再導入 Library Mode 及引擎渲染壓力。

13.4 MOD 與腳本界限

若 MOD 直接改動世界規則、腳本工作或物件關係，必須重新評估依賴圖、規則 digest、GPU kernel 相容性與存檔契約。可以提供 Script Hook，但 Hook 不得繞過世界修改權；建議先把 script intent 轉成 checked command，再由 Runtime 接手後續流程。

14. 並發、事件訂閱與不漏喚醒

14.1 單執行緒參考核心的安全性只在受限論域成立

Paper 07 的 Rust 樣例因沒有第二個實際並發 writer，也沒有 GPU 執行佇列，因此不會遇到多執行緒 lost wake-up。這不是證明完整 CWSR 不會漏事件。當引入 Worker Threads、Godot 回呼和 GPU async jobs，必須正式加入 Paper 02 的 Subscription Barrier。

14.2 訂閱競態的典型反例

Thread A: 讀取「城市道路可通行」= true
Thread B: 提交道路被炸毀
Thread A: 之後才註冊道路變化訂閱
Thread A: 睡眠，永遠沒收到已發生事件

正確作法必須使用「訂閱與版本檢查不可漏掉中間事件」的協定。可以在同一把鎖下訂閱及檢查，或使用事件日誌位置與原子 epoch，再在訂閱建立後重查版本差異；不能僅依兩次普通讀取靠運氣避免競態。

14.3 建議的保守訂閱屏障

snapshot = read_world_versioned()
subscribe(event_index, work_dependencies, snapshot.revision)
current = read_committed_revision()
if current != snapshot.revision:
    revalidate_dependencies_or_requeue()
else:
    mark_dormant_with_subscription_certificate()

以上是邏輯協定，不表示任意 lock-free memory ordering 都正確。正式實作須指定線性化點、原子內存序、事件保留策略與 replay cursor，不應用 GIL 或 Rust Borrowing 當作完整併發正確性證據。

14.4 高扇出因果圖不必逐個物件熱更新

如果一次宏觀政策造成全國城市潛在影響，可以先持有版本化的 domain-level invalidation，對真正需要精細值的子域再展開。前提是觀察截止時刻、下游必要義務和依賴完整性受到保全；不能把數千個實際已到期的重要事件簡單標示為「域已失效」就不處理。

14.5 迴圈依賴的處理

對高耦合回饋（價格—供需—物流—價格），可採有界固定點迭代、明示 epoch phase、或模型允許的數值收斂策略。若不能證明收斂或容許誤差，應返回 UnresolvedCycle／保守 fixed-step，而不是無限制安排工作造成飢餓、或強行接受暫態值為權威。

14.6 跨 CPU/GPU 記憶體可見性

CPU 看到 fence signal 仍需依 graphics API／memory model 正確處理 buffer barriers、host/device coherency、cache invalidation 與 resource ownership transfer。不能把 fence reached 簡化為「隨意讀取同一塊 CPU 指標」。所有這些 API-specific 細節必須由被驗證的 GPU adapter 實作。

15. 持久化、崩潰恢復與確定性重播

15.1 存檔不能只存畫面與人物數值

真正的存檔最少應能重建：canonical world snapshot、規則和 MOD 版本、時間 epoch、唯一身份／資產、尚未完成的義務、可恢復依賴訂閱、事件去重鍵、跨尺度帳本及必要的 RNG counter／seed。對 in-flight GPU work，通常只保存可恢復的工作描述與來源版本，不能假設重開遊戲後舊 GPU fence 仍有效。

15.2 Crash-safe 提交的兩個正當方向

WAL-first： 先 durable append 已驗證的 commit intent 與交易標識，按照資料庫約束實際修改 snapshot，再標記 durable completion；恢復時依 idempotent record 重做或回滾。

Atomic Snapshot + Journal： 在明示檔案系統與儲存語義下寫入 versioned snapshot + journal，使用可驗證的原子替換／校驗和備援檔，恢復時由最後一致位置重播。

這兩種只是設計方向，不能從第 6 章記憶體中的 Vec<JournalRecord> 推論已具 crash durability。實際落地應指定 fsync／rename／directory sync 與 OS/filesystem 邊界及 fault injection 實測。

15.3 Replay 是重新執行規則，不是重播動畫

Replay engine 從固定初始狀態、規則版本、seed/counter 和事件順序，重新計算並比對每次 commit 的 semantic state hash。動畫、鏡頭和 GPU 畫面可不重放，除非研究目標另含視覺確定性。帶浮點差異的工作按 precision contract 使用指定容許誤差，而不是要求所有顯示卡 bitwise 一致。

15.4 隨機性不能被不斷重算任意消耗

若 NPC 使用 RNG 決定日常事件，跳過計算可能改變亂數消耗序列，進而影響其他角色。建議以 world/domain/entity/epoch/event-key 的 counter-based 或有明示隔離的 RNG streams 來固定語義；即使可重播，也要測試不同路由是否維持指定分布或確定結果。

15.5 預測預載不得出現在已提交歷史中

Causal Frontier 預估只用來提前準備資源、編譯 kernel、載入快取或暖化資料。預測中某個 NPC 可能去市場，不代表 NPC 實際去過市場；預熱事件不能產生遊戲故事、獎勵或紀錄，直到規則級真實事件通過 Commit Gate。

15.6 存檔的調試欄位

推薦持久化或旁路記錄：world_id、revision、sim_epoch、ruleset_hash、schema_hash、mod_digest、journal_offset、last_committed_event_id、rng_policy、resource_policy_version、allocator_version、router_policy_version、engine_adapter_version。其中 router 和硬體後端不一定屬於世界語義的一部分，但有助於定位回放性能與非決定性差異。

16. 端到端世界案例與範例事件軌跡

16.1 Case A：橋梁損壞、道路中斷與跨尺度供需

假設玩家在 epoch = 200 炸毀城市 A 與 B 之間的橋。此事件有穩定 source_event_id 並透過 Commit Gate 成為權威事實。系統不得只更新附近橋樑模型，還必須檢查：道路可通行性、預約中的貨車路線、兩地物流、在途貨物、城市商品供給、價格及影響 NPC 日程的義務。遠方城市可以保留中觀摘要，但與橋樑依賴的物流路由需要失效或重新評估。

合法工作流： 微觀橋樑狀態提交 → 地區交通 domain invalidation → 重新計算受影響物流 → 以中觀商品供需更新候選 → 跨區域 ledger 校驗 → macro summary 與 NPC 購物介面依訂閱更新。

不合法工作流： GPU kernel 直接改寫城市 B 的 canonical 價格，因為其計算完成而略過道路事件版本比對；或由宏觀總量逆推某具名 NPC 已經完成一趟不存在的送貨任務。

16.2 Case B：沉睡的具名 NPC 在十日快轉後重逢

玩家快速旅行十天，遠方具名 NPC 的完整行為樹平時未執行。合法的休眠方案應保留其身份、已有裝備、任務承諾、到期事件、必要隨機流及可能影響他者的約束。若從粗尺度日程直接細化成故事敘述，必須分清楚「已提交實際事件」與「在規則及已知事實下可接受的條件補全」。

重逢時不能偷偷新增一份具名角色副本，也不能憑人口統計平均值決定其生死。若某時間窗口需高精度事件模擬卻已被不當丟棄，安全策略可以是重新播放保存事件、進行保守回退，或明示 UnrecoverableHistory；不可偽裝為無損結果。

16.3 Case C：百萬居民的數值需求、GPU 與渲染壓力

遠方世界有大量匿名居民的簡單可平行需求更新。Runtime 可選擇以連續數值狀態批次在 GPU 上更新，但只在資料布局規整、路由依賴可證明、資料已合適駐留、kernel 精度被驗證並有 render headroom 時採用。若顯卡 VRAM 緊張、畫面需要高幀率或批次過小，使用 CPU SIMD／Job System 可能更好。

本案例需要至少三個證據：計算正確性與 CPU oracle 的對照、包含 device transfer/fence/commit 的完整延遲，以及遊戲渲染 p95/p99 frametime。只顯示 GPU kernel 吞吐不構成遊戲總體性能勝利。

16.4 Case D：MOD 增加經濟規則

原本居民需求只依賴收入與商品價格，MOD 新增疾病影響、派系禁令及倉庫封鎖條件。舊依賴圖、分類註記、GPU kernel、快取與跨尺度摘要可能同時失效。正確的更新程序先提升 rule/MOD revision，將舊計畫標記為 stale，重建或否決受影響的 cache/route/kernel，並保留所有尚未完成的合法義務；不得只熱替換函式指標再繼續沿用已 in-flight 的 GPU 世界結果。

16.5 Case E：遊戲停止在選單但世界時間由規則決定

當玩家打開暫停選單，遊戲可按設計合法暫停 simulation clock，並繼續 UI／畫面動畫；亦可設計為世界時間持續推進。CWSR 不能從「螢幕沒變」推導自動休眠全世界，而須根據 TimePolicy、事件期限及遊戲規則確定哪些工作需要繼續。此案例直接對應系列最初從 DOSBox-X 畫面與程式執行不對應的觀察。

17. Conformance Matrix：正式的工程正確性義務

17.1 檢查項目與失敗觸發

17.2 測試的分層驗收

Core Unit： C07-01–06、12、16、20、22、25、27；至少以不依賴引擎的 CPU fixture 先跑通。

Scheduler Concurrency： C07-07、08、17、23；需加入並發與 time-jump fault injection。

Scale／Memory： C07-09–11、28；需真實保存個體 identity anchors 與 ledger。

GPU／Host： C07-13–15、18、24、26；必須使用真實後端／驅動／引擎主線程驗證。

Research Controls： C07-21、29、30；驗證新路由不因分類或理論主張僭越正確性。

17.3 Conformance 不等於效能勝利

通過 C07-01–30 只能表示指定場景下契約有一定工程支持。它仍不能證明 CWSR 更快、更省電、更節省 VRAM、能同時模擬更多 NPC，或適用所有消費級硬體。這些必須由 Paper 08 的公平測試另行建立。

18. Benchmark Harness：提供 Paper 08 的強基線

18.1 對照組必須與前篇相同

18.2 最小 Fixture 組合

• sparse_npc_daily_001：居民長時間不變，偶爾有期限及物品交互。
• dense_population_002：大量居民的規整數值更新。
• bridge_trade_003：橋樑毀損、物流路由、價格、帳本。
• weather_field_004：連續網格與離散雨災觸發。
• fast_travel_005：時間跳進、具名 NPC、死亡或任務到期。
• mod_rule_shift_006：運行中合法規則版本切換與失效。
• render_pressure_007：GPU 世界計算與高畫面負載競爭。
• tiny_work_008：小任務，預期 CPU 固定路由可能勝出。
• high_conflict_009：多事件讀寫同一地區／資產。
• low_memory_010：小 RAM／VRAM 工作集、預載／回收抖動。

18.3 同規則、同義務、同期限

比較的每組必須滿足相同 world semantics、事件輸入、seed/counter、精度、可觀測量和時間截止條件。若某組使用更粗糙近似，其誤差界限及可接受玩法結果必須與其他組對齊。不得將減少規則義務或永久凍結遠方世界當成純性能改善。

18.4 必報指標

其中 $T$ 為工作端到端延遲分位數， $L_{\mathrm{world}}$ 為指定窗口內合法世界提交量， $D_{\mathrm{miss}}$ 為期限失誤， $F$ 為幀時間分位數， $M$ 為峰值記憶體， $B_{\mathrm{transfer}}$ 為資料搬移， $C_{\mathrm{route}}$ 為分類／路由額外成本。可再加入能源、GPU 占用、CPU thread time、replay divergence 與 failure recovery time。

18.5 測量條件不能省略

報告 CPU 型號、核心與記憶體、GPU 型號和 VRAM、OS、驅動、Rust 版本、Godot 版本、shader backend、裝置溫度／時脈政策、render resolution、場景幀率目標、素材設定、warm/cold cache 和測試時間。對不同硬體至少保留交叉結果；若尚無跨硬體資料，就直接標明限制。

18.6 B4 與 B5 必須能互相推翻

若 B5 沒有顯著改善，甚至因 classification tax 使 p99 或 frametime 變差，就應接受「24／72 在此路由負載沒有可觀察淨效益」的結論。分類理論仍可具有描述價值，但不能因此宣稱它帶來性能效益。

19. 可證偽命題與負面結果

19.1 P07-1：提交權限分離足以檢出部分錯誤候選

若同一 fixture 下改寫 receipt 內容、改變 world revision 或重播同 work ID，嚴格的 Commit Gate 應拒絕且 canonical world 不變。反例：任何不經合法驗證而改變世界者，否定當前實作的權威隔離宣稱。

19.2 P07-2：模組化不保證性能改善

Runtime 的路由、事件索引、證據與保存成本本身可能高於工作計算；如果 B4/B5/B6 在大多數負載落後優化良好的 B1/B2/B3，應以工作範圍、啟用門檻與算法精簡處理，而不是將性能下降解釋成測試失誤。

19.3 P07-3：CPU oracle 可以作為異質世界計算的精度基準

對純確定、整數或可明確建立 tolerance 的參考 kernel，可使用 CPU oracle 比對 GPU 候選。在浮點、統計或非交換耦合模型中，需擴展為相應的驗證契約；若完全無 oracle 或觀察不變量，就不能宣稱已有強正確性證據。

19.4 P07-4：類型化 route error 可以防止部分沉默失敗

當 VRAM 不足、時間期限不合法、rule revision 不同或 device loss 時，系統應回傳 typed failure，保留義務並進行受控 fallback；若系統只是刪除錯誤或默默使用舊副本，便不符合本篇契約。

19.5 P07-5：引擎適配可以保持 Gameplay World 的單一權威

若同一條規則在 Godot／EveWorld host 下產生等價已提交事件，即使畫面渲染／輸入來源不同，world semantic core 應可由相同 fixture 測試。然而使用者腳本和原生引擎節點可繞過接口是明確風險，需要配合權限隔離與契約測試，而不能只靠團隊約定。

19.6 P07-6：多尺度恢復的正確性取決於保留資訊

如果在粗尺度更新後沒有必要的 identity anchors、事件或條件化生成策略，就無法保證恢復到原本的微觀個體歷史。反例不是「演算法不夠強」，而是資料契約根本不成立。此時應否決精細化或重新設計世界規則。

19.7 P07-7：GPU residency 只有在端到端成本受控時值得使用

GPU kernel 更快並不意味總延遲、更少功耗或更平穩畫面；只有當資料搬移、同步、驗證與 render contention 被量測後，才有資格討論其適用域。若 GPU 只是轉移成本或擠壓顯示資源，應退回 CPU／混合策略。

20. 反例資產與失敗恢復優先序

恢復優先序： 保全 canonical world → 保全未履行義務與持久化事件 → 取消／隔離不可信候選 → 釋放合法租約 → 恢復保守已知路由 → 重跑受影響工作 → 重新量測成本。不得為了保留原來 FPS 而犧牲世界真值或玩家存檔。

21. Paper 08 的資料契約與交接要求

21.1 必要輸出文件

後續實作者完成真正 Runtime 後，至少生成：

runtime_manifest.json
world_fixture_manifest.json
backend_and_driver_manifest.json
rust_toolchain.txt
source_commit.txt
schema_rule_mod_digest.json
cpu_oracle_golden_results.json
conformance_test_report.json
route_trace_formblind.jsonl
route_trace_formaware.jsonl
resource_trace.jsonl
world_commit_journal.jsonl
replay_comparison_report.json
bench_latency_memory_render_energy.csv
fault_injection_report.json
negative_cases.md

此清單是可追溯性要求，不表示本篇已生成上述測試結果。實際格式可採 TOML／JSONL／CSV 或其他版本化機器可讀格式，但每個結果必須能回指同一輪 fixture 與原始程式碼版本。

21.2 首輪可提交的狀態聲明

• Paper 07 Specification Complete： 文本、接口、失敗邊界、測試義務完整。
• Rust Reference Code Candidate： 第 6 章提供 source；目前待本地 Cargo 編譯與測試。
• CPU Semantic Conformance Pending： Rust 真正執行結果尚未由此環境取得。
• GPU Native Adapter Pending： 尚無本篇實機 GPU 提交、fence 或性能證據。
• Godot／EveWorld Adapter Pending： 是可執行整合計畫，不是已整合完成。
• B0–B7 Comparative Evidence Pending： 全部公平效能比較留待 Paper 08 實作測量。

不得把第一行完成誤解成後面五行全部通過。

21.3 工程化下一步

1. 在本地 Rust 環境輸入第 6 章的兩個檔案並執行 cargo fmt、cargo check、cargo test；保留完整 log，修復任何編譯與 borrow/lifetime 問題。
2. 擴大 World Fixture，加入資產與 NPC identity、已提交事件日誌及 time advance authority。
3. 將 M1 CPU oracle 規格固定成相同輸入／預期輸出的金標集合。
4. 接 M2 的 typed gates、M3 的 FormBlind route，再測 M4 的 24／72 附註成本。
5. 只挑一個具精度 oracle 的 GPU kernel，完成 fence、buffer generation、device-loss 實驗。
6. 接入 Godot／EveWorld adapter 的最小場景，驗證 UI 仍由 main thread 控制。
7. 用 Paper 08 的公平 B0–B7 測試判斷各模組實際收益和可關閉的部分。

21.4 為什麼不需要立即啟動更大的母理論

若 Paper 07 的某個 Router 在現有 24／72 分類之外需要新的工作性特徵，例如 cache locality、predicated execution、time-to-deadline 或能耗界限，應優先把它記作執行策略的附加屬性。只有在明確證明原有分類的核心形式系統缺乏必要的描述維度，且工程特徵不能合理作為 metadata 處理時，才有理由另行回到上游修訂，而不是直接宣布出現第 25／73 種基礎範式。

22. 版本來源、已有研究與可追溯性

22.1 本輪核對的 CWSR 正式 UTF-8 原稿

1. Neo.K × Aletheia，CWSR Paper 00｜因果世界狀態運行：既有計算理論的單機遊戲 Runtime 延伸總綱，v0.1，2026-10-16，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，CWSR_Paper01_World_State_Ontology_and_Executable_State_Separation_v0.1_2026-10-16.md。
3. Neo.K × Aletheia，CWSR Paper 02｜因果觸發、執行休眠與條件喚醒機制，v0.1，2026-10-16，CWSR_Paper02_Causal_Trigger_Execution_Dormancy_and_Conditional_Wakeup_v0.1_2026-10-16.md。
4. Neo.K × Aletheia，CWSR Paper 03｜宏觀—中觀—微觀多尺度世界模擬，v0.1，2026-10-16，CWSR_Paper03_Macro_Meso_Micro_Multi_Scale_World_Simulation_v0.1_2026-10-16.md。
5. Neo.K × Aletheia，CWSR Paper 04｜動靜態記憶體契約與選擇性物化，v0.1，2026-10-16，CWSR_Paper04_Dynamic_Static_Memory_Contracts_and_Selective_Materialization_v0.1_2026-10-16.md。
6. Neo.K × Aletheia，CWSR Paper 05｜CPU／GPU 異質世界計算與因果小流，v0.1，2026-10-16，CWSR_Paper05_CPU_GPU_Heterogeneous_World_Computation_and_Causal_Microflows_v0.1_2026-10-16.md。
7. Neo.K × Aletheia，CWSR Paper 06｜24／72 計算範式的世界狀態自適應路由，v0.1，2026-10-16，CWSR_Paper06_24_72_Adaptive_World_State_Computation_Routing_v0.1_2026-10-16.md。

22.2 上游 EveMissLab 研究（繼承，不改寫）

8. Neo.K，《計算的二十四重範式》，正式版候選稿 v4.0，2026-07-19，計算的二十四重範式_正式版_v4.0.md。
9. Neo.K × Aletheia，《從二十四重計算形態學到七十二格計算動力學》，v0.1，2026-07-19，從二十四重計算形態學到七十二格計算動力學_v0.1.md。
10. Neo.K × Aletheia，Global Computation Methodology Series，2026，特別是 00 與 01 的全域一致性、有限活動實現及計算／觀察／物化分離。
11. Neo.K × Aletheia，GCCF 04｜全域可尋址狀態與選擇性物化，v0.1，2026-09-22。
12. Neo.K × Aletheia，GCCF 05｜因果流計算與預記載，v0.1，2026-09-22。
13. Neo.K × Aletheia，GCCF 06｜計算 24 範式與 72 格作為全域計算路由文法，v0.1，2026-09-22。
14. Neo.K × Aletheia，GCCWT Paper 04｜計算場與資源激發：跨 CPU／GPU／Memory／Agent 的動態執行域，Draft v0.2。
15. Neo.K × Aletheia，GCCWT Paper 06｜AI 原生全域調度：從 Task Scheduler 到 World Computation Planner，Draft v0.2。
16. EveMissLab，GCM Phase B：Deterministic Compute Allocator 技術白皮書，v0.1，2026-08-27。
17. Neo.K × Aletheia，《從有序計算到全域耦合計算》統合母論文，v0.1，2026-09-22。

22.3 成熟工程背景及尚待補齊的正式外部引文

本篇直接運用 CPU／GPU 一般計算、ECS／Job System、事件排程、Timer Wheel、Dirty Flag、Rust ownership、MVCC、Write-Ahead Logging、GPU command queue／fence、Godot Engine host 融合與可重播模擬等成熟技術。這些不是 CWSR 所原創，未在本輪逐項完成版本限定的外部文獻查核；正式投稿或對外公開技術白皮書時，應補充語言規格、GPU API、Godot 引擎文檔與學術性能比較的權威來源，區分已知技術、本文延伸接口與尚未證實的性能假說。

22.4 原始碼與再現性的規則

本文以 UTF-8 Markdown 另存 canonical source；數學唯一正式 delimiter 為 $...$ 及 $$...$$。聊天渲染與後續 PDF／網站投影不能作為正式 source of truth。未來若本地 Rust 參考碼經修正，應保留此 v0.1 原稿及對應來源 SHA／差異紀錄，另出新的程式 commit 與論文修訂，不得靜默把實驗後的程式碼當成本文當時已驗證的版本。

23. 結論：Reference Runtime 的責任是讓世界狀態可驗證地運行

本篇將 CWSR 從世界狀態分類、因果休眠、多尺度模型、記憶體駐留、CPU／GPU 工作流及計算形態路由，收斂為一個可以被單機遊戲引擎採用的最小工程分層。其第一原則仍是：世界存在不代表必須持續執行；執行發生不代表結果合法；運算完成不代表具有世界修改權。

Rust 所有權、可撤回的計算規劃、CPU oracle、GPU 裝置完成證據、ScaleBridge 和 Commit Gate 各自解決不同層的問題，不能因為共享 Runtime 名稱就互相取代。單一世界、保守 revision、完整讀寫檢查、候選與提交隔離，構成最小可測試錨點；之後再用實測證據判斷是否值得加入更細粒度路由、GPU 物化、宏中微尺度切換及 AI 輔助規劃。

本篇完成的是形式化工程原稿與可供本地驗證的 Rust 候選程式碼，不是已被編譯、實機測通的 CWSR 引擎產品。 這項限制不是缺陷被隱藏，而是下一篇可證偽測量的必要起點。Paper 08 將要求 CWSR 與成熟的 CPU／事件／GPU 路線在相同工作義務下競爭，並同時公開成功域、失敗域、效能收益及治理開銷。

如最終實驗發現，某些單機遊戲只需要成熟事件系統、簡單 CPU 更新與少量 GPU Compute，則 CWSR 應允許該系統保持簡單。真正值得保留的，不是強迫所有計算都進入新框架，而是讓每一項實際啟動的世界工作，都具有可理解、可計量、可撤回且不破壞因果的正當理由。

End of CWSR Paper 07 v0.1 — Engineering Specification and Rust Reference Candidate