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

系列： 動態通用世界狀態機：內部架構與演化規格
篇次： 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；

逐步改名，然後宣布：

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

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

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

例如：

Quest Failure

和：

Medical Workflow Failure

雖然都可以叫：

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。

但不應知道：

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 不應規定：

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。

但不應把：

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：

alive
dead

Robot：

booting
ready
fault
offline

Workflow：

draft
approved
executing
closed

這些不能共用同一 state enum。

但可以共用：

\boxed{ \text{Lifecycle Transition Pattern} }

6.2 Location Prototype

Game：

actor.position.room

Robot：

robot.position.zone

Device：

device.location.site

相同的可能是：

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

不同的是：

空間模型；
precision；
movement constraints。

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

6.3 Ownership / Custody Prototype

Game inventory 已經提供：

item → carrier

但未來可能映射：

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：

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

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

8. Parameterization 與 Copy-Paste 的差別

Copy-paste：

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

例如：

Room

不是 Universal。

但：

State owner 必須具有 stable identity。

可以是 Universal。

Quest

不是 Universal。

但：

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

可以是 Universal。

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 拆成：

core/
prototype/
game/

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

目前更合理的是：

先標記語義分類；
補 contract；
補 scenario；
補 trace；
觀察第二 Domain；
再抽實體 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：

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 都要求寫：

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 帶：

semantic_layer: universal | adaptable | specific

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

例如：

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

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

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

摘要

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

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

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

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

3. 第一層：Universal Core

3.1 Entity

3.2 State

3.3 Action

3.4 Event

3.5 Time

3.6 Authority

3.7 Transition

3.8 History

3.9 Projection

3.10 Contract

4. Universal Core 的判準

U-1：Domain-Neutral Invariant

U-2：Kernel-Level Enforcement

U-3：Cross-Domain Evidence

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

5. 第二層：Parameterized Prototype

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

6.1 Lifecycle Prototype

6.2 Location Prototype

6.3 Ownership / Custody Prototype

6.4 Task / Workflow Transition Prototype

6.5 Resource Prototype

6.6 Timed State Prototype

6.7 Availability / Preconditions Prototype

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

8. Parameterization 與 Copy-Paste 的差別

9. 第三層：Domain-Specific Semantics

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

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

invariant 高、domain variance 低

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

domain variance 高、語義特殊

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

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

14. 與目前 Repository 的對應

14.1 Candidate Universal

14.2 Candidate Adaptable

14.3 Clearly Game-Specific

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

16. Prototype 不應偷偷獲得 Kernel Authority

17. Domain Pack 的未來最小概念

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

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

第一問

第二問

第三問

20. 三層分類的初步 Metadata

21. 核心不變量

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

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

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

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

S-5：升格必須有 Evidence

22. 禁止事項

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

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

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

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

禁止 E：過早 physical refactor

23. 尚未實作

24. 驗證條件

V-1

V-2

V-3

V-4

V-5

V-6

25. 本篇結論

Universal Core

Parameterized Prototype

Domain-Specific

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