# 通用核心、參數化原型與領域客製：世界狀態語義的三層分解

**系列：** 動態通用世界狀態機：內部架構與演化規格  
**篇次：** 03 / 07  
**版本：** v0.1  
**日期：** 2026-08-01  
**性質：** 內部技術白皮書／語義分層規格  
**基準 Repository：** `kakon77777-commits/compilableworld-runtime-mvp`

---

# 摘要

前兩篇已確立兩件事。

第一，現有 CompilableWorld Runtime 已經具有一批高度可泛化的 Kernel／IR／Contract，但整體仍然是遊戲世界狀態 Runtime，而不是已完成的通用系統。

第二，未來不應抽取出一個 Universal Core 後就丟棄 Game Runtime；現有 Game Runtime 應持續作為 Executable Reference World、Prototype Source、Regression Anchor、Failure Corpus 與 Generation Constraint Anchor。

本篇處理下一個更容易出錯的問題：

> **到底哪些東西應該被稱為「通用」？**

如果把所有遊戲概念都提升到 Universal Core，會得到一個偽通用、實際上仍然以 RPG 為中心的巨大 Schema；如果反過來把 Core 壓得太薄，只剩 `key/value` 與事件匯流排，那麼每一個新 Domain 又必須從頭定義 lifecycle、resource、ownership、location、task、relation 等反覆出現的結構，失去 Reference Prototype 的價值。

因此本篇提出三層語義分解：

$$
\boxed{
D
=
D_{\mathrm{universal}}
\cup
D_{\mathrm{adaptable}}
\cup
D_{\mathrm{specific}}
}
$$

其中：

- $D_{\mathrm{universal}}$ ：跨 Domain 應保持相同語義與不變量的通用核心；
- $D_{\mathrm{adaptable}}$ ：跨 Domain 高頻重現，但需要參數化、映射或政策差異的原型層；
- $D_{\mathrm{specific}}$ ：只能由特定領域自己定義的語義層。

核心結論不是「通用越多越好」，而是：

$$
\boxed{
\text{Generalize invariants, parameterize recurring patterns, customize domain truth.}
}
$$

也就是：**通用化不應吞掉領域語義；領域客製也不應重複發明已經驗證過的結構。**

---

# 1. 問題：通用化最容易犯的兩個相反錯誤

建立通用世界狀態 Runtime 時，最容易走向兩個極端。

---

## 1.1 極端 A：萬物共用巨大 Schema

例如把目前 Game Runtime 中已存在的：

- Character；
- Room；
- Item；
- Quest；
- Health；
- Inventory；
- Combat；
- Magic；
- Dialogue；

逐步改名，然後宣布：

```text
Character → Actor
Room → Space
Quest → Task
Item → Resource
```

最後形成一套號稱所有世界都能使用的巨大 ontology。

問題是名稱變抽象，不代表語義真的通用。

例如：

```text
Quest Failure
```

和：

```text
Medical Workflow Failure
```

雖然都可以叫：

```text
Task Failure
```

但：

- 是否可重試；
- 是否可 rollback；
- 是否允許平行分支；
- 失敗後是否仍可部分完成；
- 誰有修改權；

都可能完全不同。

所以：

$$
\boxed{
\text{Name Generalization}
\neq
\text{Semantic Generalization}
}
$$

---

## 1.2 極端 B：Core 薄到只剩 key-value

另一個極端是：

> 既然所有領域都不同，那 Universal Core 只保存 `entity + key/value + event` 就好。

這樣雖然看似最通用，但會把所有高頻重複結構丟回 Domain 自己處理。

例如：

- lifecycle；
- resource depletion；
- ownership；
- location；
- task transition；
- timed state；
- availability；
- dependency；
- permission scope。

Game、Robot、Smart Room、Agent workflow 都可能需要它們。

如果每個 Domain 都重新寫一次：

$$
\text{Domain}_1
\rightarrow
P
$$

$$
\text{Domain}_2
\rightarrow
P'
$$

$$
\text{Domain}_3
\rightarrow
P''
$$

最後只是製造三套長得很像、但無法互相驗證的實作。

因此：

$$
\boxed{
\text{Too Thin Core}
\Rightarrow
\text{Repeated Reinvention}
}
$$

---

# 2. 三層分解：Universal / Adaptable / Specific

本篇正式提出：

$$
\boxed{
D
=
D_{\mathrm{universal}}
\cup
D_{\mathrm{adaptable}}
\cup
D_{\mathrm{specific}}
}
$$

三者不是固定命名空間，而是語義治理層級。

---

# 3. 第一層：Universal Core

$D_{\mathrm{universal}}$ 應該只包含：

> **跨 Domain 必須維持同一組執行語義與不變量，否則整個 Runtime 失去可驗證性的能力。**

目前候選包括：

$$
\boxed{
\{
Entity,
State,
Action,
Event,
Time,
Authority,
Transition,
History,
Projection,
Contract
\}
}
$$

但每個詞的意義要非常窄。

---

## 3.1 Entity

通用 Core 不需要知道 Entity 是：

- 人；
- NPC；
- Robot；
- Door；
- Company；
- Weather Cell；
- Software Agent。

它只需要知道：

$$
e=
(
id,
type,
components,
metadata
)
$$

而且具有：

- 穩定 ID；
- 可引用；
- 可檢查存在性；
- 可被 State owner 指向。

現有 `EntityRegistry` 已經非常接近這個角色。

---

## 3.2 State

通用 Core 應負責：

- state path；
- value；
- version；
- read；
- proposed write；
- conflict detection；
- commit。

但不應知道：

```text
health.current
battery.level
weather.temperature
order.status
```

哪一個比較重要。

所以 Universal State 的核心是：

$$
\boxed{
\text{Addressability}
+
\text{Version}
+
\text{Mutation Semantics}
}
$$

而不是 Domain value 本身。

---

## 3.3 Action

Universal Action 應回答：

> 誰提出什麼操作、目標是什麼、參數是什麼、權限上下文是什麼？

而不預先定義所有 verb。

形式可維持：

$$
A=
(
actor,
verb,
target,
args,
authority,
correlation
)
$$

---

## 3.4 Event

Universal Event 應保持：

- identity；
- event type；
- source；
- target；
- causation；
- correlation；
- timestamp；
- visibility；
- authority；
- payload。

但 Event Core 不應規定：

```text
quest.completed
robot.arrived
door.opened
market.order.filled
```

哪些 event type 必須存在。

---

## 3.5 Time

Universal Time Core 應定義：

- ordering；
- scheduling；
- delay；
- temporal identity；
- possibly clock domain。

但不應把：

```text
turn
combat exchange
wall clock
simulation tick
calendar day
```

硬綁成一種。

目前 Scheduler 是這一層的早期原型。

---

## 3.6 Authority

通用 Core 應回答：

$$
\operatorname{CanRead}(x,r)
$$

$$
\operatorname{CanWrite}(x,p)
$$

$$
\operatorname{CanAct}(actor,verb,target)
$$

但不需要先知道：

- GM；
- 玩家；
- 管理員；
- robot owner；
- employee；
- doctor；

誰應該有什麼權力。

Domain 定義角色，Core 執行規則。

---

## 3.7 Transition

Universal Core 不一定必須擁有所有 transition rule。

它必須保證：

$$
\text{Proposal}
\rightarrow
\text{Validation}
\rightarrow
\text{Commit}
$$

並提供：

- atomicity；
- expected version；
- conflict handling；
- event emission；
- trace。

Transition semantic 可以由 Domain module 決定。

---

## 3.8 History

通用 Core 應區分：

$$
\text{Current State}
\neq
\text{Causal History}
$$

並保持：

- committed event；
- snapshot；
- replay；
- migration。

但不要求每個 Domain 全部採純 Event Sourcing。

---

## 3.9 Projection

Projection 應是：

$$
\phi(S,E,context)
\rightarrow
View
$$

而不是 state truth。

現有 Web View Model、Studio projection、MCP projection 都屬這個方向。

---

## 3.10 Contract

通用 Runtime 真正穩定的不是某個 class 名稱，而是：

- schema version；
- module contract；
- IR contract；
- projection contract；
- snapshot contract；
- migration contract。

因此：

$$
\boxed{
\text{Universal Core}
=
\text{Minimal Semantics}
+
\text{Stable Contracts}
}
$$

---

# 4. Universal Core 的判準

一個能力要進 $D_{\mathrm{universal}}$ ，至少應滿足：

## U-1：Domain-Neutral Invariant

在不同 Domain 中，不變量不應改變。

例如：

> Projection 不可直接覆蓋 authoritative State。

這在遊戲、機器人與智慧房間都成立。

---

## U-2：Kernel-Level Enforcement

若只是「大家通常這樣做」，不一定值得進 Core。

Universal 能力最好是：

$$
\boxed{
\text{可被 Runtime 強制}
}
$$

例如 version conflict。

---

## U-3：Cross-Domain Evidence

除非是執行本身必需的最小抽象，否則最好要有至少兩個 Domain 重用證據再正式升格。

---

## U-4：語義不可依賴 Domain 名詞

如果去掉 Game 名詞後，規則就失去意義，通常還不是 Universal。

---

# 5. 第二層：Parameterized Prototype

真正最容易被低估的是：

$$
D_{\mathrm{adaptable}}
$$

這一層不是 Universal Core，也不是 Domain-specific code。

它代表：

> **很多 Domain 都會遇到相似結構，但允許命名、狀態空間、政策、終態、時間尺度與 authority 不同。**

這一層將來很可能是 Prototype Library 最大的部分。

---

# 6. 第一批高價值 Adaptable Prototype 候選

以下是從 Game Reference World 可以優先抽出的 pattern 候選。

---

## 6.1 Lifecycle Prototype

通用形狀：

$$
L=
(
S,
T,
F
)
$$

其中：

- $S$ ：lifecycle states；
- $T$ ：allowed transitions；
- $F$ ：terminal / forbidden states。

Game：

```text
alive
dead
```

Robot：

```text
booting
ready
fault
offline
```

Workflow：

```text
draft
approved
executing
closed
```

這些不能共用同一 state enum。

但可以共用：

$$
\boxed{
\text{Lifecycle Transition Pattern}
}
$$

---

## 6.2 Location Prototype

Game：

```text
actor.position.room
```

Robot：

```text
robot.position.zone
```

Device：

```text
device.location.site
```

相同的可能是：

- current location；
- allowed containment；
- move transition；
- visibility projection。

不同的是：

- 空間模型；
- precision；
- movement constraints。

所以應做成可參數化 Prototype，而不是 Universal `room`。

---

## 6.3 Ownership / Custody Prototype

Game inventory 已經提供：

```text
item → carrier
```

但未來可能映射：

```text
device → custodian
asset → owner
document → controller
```

共同 pattern：

$$
\text{Resource}
\xrightarrow{\text{transfer}}
\text{Holder}
$$

但 Domain 可能加入：

- transfer approval；
- temporary lease；
- shared ownership；
- non-transferable；
- escrow。

因此 ownership 不應直接硬進 Core。

---

## 6.4 Task / Workflow Transition Prototype

Quest transition 可以提供：

$$
q_i
\xrightarrow{event}
q_j
$$

以及：

- branch；
- failure；
- terminal state；
- priority。

未來可映射：

- workflow；
- maintenance task；
- robot mission；
- approval process。

但各 Domain 的完成定義、rollback 與責任不同。

所以：

$$
\boxed{
\text{Task Transition}
\in
D_{\mathrm{adaptable}}
}
$$

而不是 Universal Core。

---

## 6.5 Resource Prototype

Game：

- HP；
- MP；
- FP；
- currency。

Robot：

- battery；
- payload；
- storage。

Cloud：

- quota；
- budget；
- tokens。

共同 pattern：

$$
r_{t+1}
=
r_t
+
\Delta r
$$

並帶：

- min/max；
- depletion；
- replenish；
- threshold event。

但 HP 與電池的意義完全不同。

所以通用的是 Resource Pattern，不是 Resource Truth。

---

## 6.6 Timed State Prototype

目前 Game status effect 已經存在：

- duration；
- refresh；
- decay；
- expiry。

未來可以對應：

- robot temporary mode；
- access lease；
- reservation；
- cooldown；
- temporary alert。

共同形式：

$$
x_t
\xrightarrow{\Delta t}
x_{t+1}
$$

直到：

$$
t\ge t_{\mathrm{expiry}}
$$

這是非常適合抽成 Prototype 的結構。

---

## 6.7 Availability / Preconditions Prototype

遊戲 action 常需要：

- target exists；
- same room；
- has key；
- state allows；
- resource enough。

其他 Domain 也會需要：

- device online；
- account authorized；
- sensor available；
- resource sufficient。

共同結構：

$$
\operatorname{Allowed}(A,S,C)
\in
\{0,1\}
$$

但條件本身由 Domain 定義。

---

# 7. Parameterized Prototype 應該有哪些欄位？

一個 Prototype 不能只是一個 base class。

可以形式化為：

$$
P=
(
I,
\Sigma,
\Theta,
\Gamma,
\Pi,
Q,
V
)
$$

其中：

- $I$ ：prototype identity；
- $\Sigma$ ：required structural schema；
- $\Theta$ ：parameters；
- $\Gamma$ ：guards / invariants；
- $\Pi$ ：authority template；
- $Q$ ：scenario templates；
- $V$ ：validation evidence。

例如 Lifecycle Prototype：

```yaml
prototype: lifecycle
parameters:
  states: [...]
  initial_state: ...
  terminal_states: [...]
  allowed_transitions: [...]
  failure_policy: ...
```

Game 與 Robot 都可以 instantiate，但不共享同一狀態列表。

---

# 8. Parameterization 與 Copy-Paste 的差別

Copy-paste：

```text
game.quest.py
→ 複製成 robot.task.py
```

之後兩者各自漂移。

Parameterized Prototype：

$$
P_{\mathrm{task}}
+
\theta_{\mathrm{game}}
\rightarrow
I_{\mathrm{game}}
$$

$$
P_{\mathrm{task}}
+
\theta_{\mathrm{robot}}
\rightarrow
I_{\mathrm{robot}}
$$

兩者共享：

- structural contract；
- scenario skeleton；
- trace vocabulary；
- invariants。

但保留不同 domain semantics。

所以：

$$
\boxed{
\text{Prototype}
\neq
\text{Shared Implementation Class}
}
$$

它首先是「可驗證的結構模板」。

---

# 9. 第三層：Domain-Specific Semantics

$D_{\mathrm{specific}}$ 是真正不應被通用化吞掉的內容。

目前 Game 例子包括：

- HP；
- MP；
- FP；
- phase tier；
- melee formula；
- magic symbol count；
- quest canon；
- narrative；
- NPC dialogue；
- combat exchange。

未來其他 Domain 可能有：

Robot：

- torque；
- odometry；
- motor current；
- localization covariance。

Weather：

- pressure；
- humidity；
- front；
- radar reflectivity。

Market：

- order book；
- price；
- position；
- settlement。

這些應該：

$$
\boxed{
\text{由 Domain 自己擁有}
}
$$

而不是因為都能放進 StateStore 就叫 Universal。

---

# 10. Domain-Specific 不代表沒有治理

客製化仍然必須使用通用執行邊界。

例如 Game Combat 可以完全 domain-specific，但仍需要：

$$
\text{ActionIR}
\rightarrow
\text{Combat Module}
\rightarrow
\text{StateDelta}
\rightarrow
\text{Kernel}
\rightarrow
\text{EventIR}
$$

所以：

$$
\boxed{
\text{Custom Semantics}
+
\text{Common Execution Contract}
}
$$

這是三層模型真正重要的地方。

---

# 11. 「通用的就通用，不通用的就客製」如何形式化？

對任意能力 $x$ ，定義分類函數：

$$
L(x)
\in
\{
U,
A,
S
\}
$$

其中：

- $U$ ：Universal；
- $A$ ：Adaptable；
- $S$ ：Specific。

分類不是依「抽象程度」決定，而應依：

$$
L(x)
=
f(
I_c,
R_d,
P_s,
D_v
)
$$

其中：

- $I_c$ ：invariant consistency；
- $R_d$ ：跨 Domain reuse；
- $P_s$ ：parameter stability；
- $D_v$ ：domain variance。

直覺上：

### invariant 高、domain variance 低

$$
\rightarrow U
$$

### invariant 中高、參數可描述、domain variance 中

$$
\rightarrow A
$$

### domain variance 高、語義特殊

$$
\rightarrow S
$$

---

# 12. 三層不是永久固定，允許升格與降格

某 pattern 一開始可能被判為：

$$
S
$$

後來發現三個 Domain 都在使用相同結構：

$$
S\rightarrow A
$$

再經更多驗證：

$$
A\rightarrow U
$$

反過來也可能發現：

> 原本以為通用，但第二 Domain 出現後語義根本不同。

則：

$$
U\rightarrow A
$$

甚至：

$$
A\rightarrow S
$$

因此需要：

$$
\boxed{
\text{Bidirectional Semantic Promotion / Demotion}
}
$$

這會避免通用化變成不可逆的架構宗教。

---

# 13. 通用化的最小原則：Generalize Invariants, Not Vocabulary

例如：

```text
Room
```

不是 Universal。

但：

> State owner 必須具有 stable identity。

可以是 Universal。

```text
Quest
```

不是 Universal。

但：

> 同一 state transition 的 authority 與 version conflict 必須可驗證。

可以是 Universal。

```text
Inventory
```

不是 Universal。

但：

> 某 Module 不可修改自己 write scope 之外的 state。

可以是 Universal。

所以：

$$
\boxed{
\text{Generalize Invariants}
>
\text{Generalize Nouns}
}
$$

---

# 14. 與目前 Repository 的對應

根據目前 repo，可初步作以下分類。

## 14.1 Candidate Universal

- `Entity`
- `StateCell`
- `StateDelta`
- `ActionIR`
- `EventIR`
- `ModuleContract`
- EventBus
- EventLog
- Scheduler primitive
- Snapshot / Replay contract
- FunctionIR purity boundary
- ScenarioIR normal-pipeline rule
- Projection read-only boundary
- Authoring / Compiled / Runtime separation

---

## 14.2 Candidate Adaptable

- lifecycle；
- quest transition；
- timed status；
- inventory carrier / ownership；
- location / room occupancy；
- resource pools；
- precondition；
- delayed action；
- dialogue conditional projection。

注意：

> 這些目前還不是正式 Prototype Library 實作，只是候選。

---

## 14.3 Clearly Game-Specific

- player template；
- HP / MP / FP；
- combat formulas；
- magic；
- phase tier；
- RPG quest content；
- NPC narrative；
- combat exchange；
- world canon。

---

# 15. Game-specific code 目前不需要急著搬走

即使已經辨識出三層，也不代表現在立刻把 repo 拆成：

```text
core/
prototype/
game/
```

如果為了漂亮目錄造成大量 regression，沒有價值。

目前更合理的是：

1. 先標記語義分類；
2. 補 contract；
3. 補 scenario；
4. 補 trace；
5. 觀察第二 Domain；
6. 再抽實體 package。

所以：

$$
\boxed{
\text{Semantic Separation}
\rightarrow
\text{Evidence}
\rightarrow
\text{Physical Refactor}
}
$$

而不是反過來。

---

# 16. Prototype 不應偷偷獲得 Kernel Authority

Parameterized Prototype 仍只是：

- schema；
- transition template；
- scenario；
- authority template。

它不能因為「被很多 Domain 共用」就繞過 Kernel。

仍需：

$$
\text{Prototype Instance}
\rightarrow
\text{Domain Module}
\rightarrow
\text{Delta/Event}
\rightarrow
\text{Kernel}
$$

這可防止 Prototype Library 演化成第二個隱藏 Runtime。

---

# 17. Domain Pack 的未來最小概念

未來一個 Domain Pack 可以概念上包含：

$$
D_p=
(
O,
P,
M,
F,
S,
Q
)
$$

其中：

- $O$ ：Domain ontology；
- $P$ ：選用／客製 Prototype；
- $M$ ：Modules；
- $F$ ：Functions；
- $S$ ：Schemas；
- $Q$ ：Scenarios。

例如 Game Domain Pack：

```text
ontology:
  character
  room
  item

prototypes:
  lifecycle
  location
  ownership
  task_transition
  timed_status

modules:
  combat
  quest
  magic
  inventory

functions:
  damage
  hit_rate
  hp_projection
```

這樣 General Runtime 不必知道 HP，但 Game Domain 可以完整運行。

---

# 18. Prototype Conflict：同一個 Domain 可能同時需要多個互斥原型

例如某個 Device 可能同時：

- 有 lifecycle；
- 有 ownership；
- 有 location；
- 有 resource；
- 有 scheduled maintenance。

Prototype composition 可能形成：

$$
P_1
\oplus
P_2
\oplus
P_3
$$

但若兩個 Prototype 都要求寫：

```text
status.current
```

就會衝突。

因此未來 Prototype Library 必須提供：

- state namespace ownership；
- action ownership；
- event ownership；
- conflict declaration；
- dependency；
- precedence。

這會直接銜接第 4 篇的 Adaptive Composition Engine。

---

# 19. 三層模型對 AI 生成的直接影響

AI 看到新需求後，不應問：

> 我要生成什麼？

而是先問：

### 第一問

哪些是：

$$
D_{\mathrm{universal}}
$$

直接使用 Core？

### 第二問

哪些是：

$$
D_{\mathrm{adaptable}}
$$

從 Prototype instantiate？

### 第三問

剩下哪些才是：

$$
D_{\mathrm{specific}}
$$

需要 Domain custom？

因此生成流程變成：

$$
\boxed{
D
\rightarrow
(U,A,S)
\rightarrow
\text{Reuse Core}
+
\text{Instantiate Prototype}
+
\text{Generate Specific Residual}
}
$$

這是後續「生成式約束」真正可以落地的基礎。

---

# 20. 三層分類的初步 Metadata

未來可以考慮讓 contract / prototype 帶：

```yaml
semantic_layer: universal | adaptable | specific

evidence:
  domains:
    - game
  regression_suite: ...
  invariants:
    - ...
  promotion_status: candidate
```

例如：

```yaml
id: prototype.task.transition
semantic_layer: adaptable
evidence:
  domains:
    - game
promotion_status: candidate
```

這清楚表示：

> 現在只有 Game evidence，因此不能偷偷宣布它已 Universal。

---

# 21. 核心不變量

## S-1：Universal Core 必須保持語義窄

Core 不吸收 Domain vocabulary。

## S-2：Adaptable Prototype 必須允許 Domain Override

若不能參數化，就不是真的 adaptable。

## S-3：Domain-specific 語義不得被迫泛化

$$
\boxed{
\text{Faithful Customization}
>
\text{False Generality}
}
$$

## S-4：所有三層仍共用 Kernel 執行邊界

三層是語義分層，不是三套 Runtime。

## S-5：升格必須有 Evidence

不能因為「看起來很通用」就進 Core。

---

# 22. 禁止事項

## 禁止 A：名稱抽象化冒充通用化

`Quest → Task` 不是證明。

## 禁止 B：把 Prototype 寫成第二個 Kernel

Prototype 不能直接 commit state。

## 禁止 C：所有 Domain 都硬套同一 state enum

Parameterization 必須允許不同 Domain 的合法差異。

## 禁止 D：通用化後刪掉原始 Domain evidence

Prototype 升格後，仍要保留來源 Reference World 與 regression。

## 禁止 E：過早 physical refactor

先完成語義與 evidence，再拆 package。

---

# 23. 尚未實作

本篇新增的以下結構目前仍是設計層：

- semantic layer metadata；
- Prototype parameter schema；
- Prototype Registry；
- Prototype conflict metadata；
- promotion / demotion record；
- Domain Pack manifest；
- automated layer classifier。

現有 repo 仍主要是 Game Runtime。

---

# 24. 驗證條件

未來三層模型要被認為有效，至少需滿足：

## V-1

一個新 Domain 能直接使用 Candidate Universal Core，而不需要修改其語義。

## V-2

至少一個 Game pattern 能透過 parameterization 在第二 Domain 重用。

## V-3

第二 Domain 仍能保留真正特殊語義，而不需要修改 Universal Core。

## V-4

Prototype 產生的 Module 仍只能透過 Kernel commit。

## V-5

Prototype 之間衝突可以被編譯期或 Runtime 前驗證偵測。

## V-6

Promotion／Demotion 不破壞既有 Reference regression。

---

# 25. 本篇結論

未來的 Dynamic General World-State Runtime 不應只有：

$$
\text{Universal}
\lor
\text{Custom}
$$

兩種選擇。

更合理的是：

$$
\boxed{
\text{Universal Core}
\rightarrow
\text{Parameterized Prototype}
\rightarrow
\text{Domain-Specific Semantics}
}
$$

其中：

### Universal Core

保存：

$$
\text{invariants}
+
\text{execution contracts}
$$

### Parameterized Prototype

保存：

$$
\text{recurring structures}
+
\text{parameterized behavior}
+
\text{validation evidence}
$$

### Domain-Specific

保存：

$$
\text{domain truth}
$$

最核心的工程句子可以寫成：

$$
\boxed{
\text{Generalize invariants, parameterize recurring patterns, customize domain truth.}
}
$$

這使「通用的就通用，不通用的就客製」不再是一個模糊口號，而變成可以實際管理 Prototype、Domain Pack 與 AI generation scope 的架構。

下一篇將正式進入：

# 《原型錨定式自適應組合：Reuse → Adapt → Residual Generation》

也就是開始回答：

> 當需求進來時，Runtime／Agent 到底如何找到可重用原型、如何判定適配程度、如何組合多個 Prototype、如何找出剩餘缺口，以及 AI 到底只准生成哪一部分？

---

# Appendix A：與目前 Repository 的對應邊界

## 目前已有，並被本篇視為 Candidate Universal 的主要來源

- `Entity`
- `StateCell`
- `StateDelta`
- `ActionIR`
- `EventIR`
- `ModuleContract`
- `EventBus`
- `EventLog`
- `Scheduler`
- Snapshot / Replay
- FunctionIR
- ScenarioIR
- Projection read-only boundary
- Authoring / Runtime separation

## 目前已有，但仍主要屬於 Game-specific / Adaptable Candidate

- Quest transitions
- inventory carrier
- timed status
- room location
- combat resource
- dialogue conditional projection
- player generation
- magic / combat formulas

## 本篇新增、尚未實作

- Universal / Adaptable / Specific metadata
- Parameterized Prototype contract
- Domain Pack
- promotion / demotion mechanism
- Prototype conflict declaration