# 生成式約束：動態世界結構如何生成而不退化成 AI 亂寫

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

---

# 摘要

第 4 篇已將動態通用世界狀態機的第一階段定義為：

$$
\boxed{
\text{Requirement-Driven Adaptive Composition}
}
$$

也就是先以 Reference World 與 Prototype Library 為錨點，完成 Retrieval、Compatibility Analysis、Composition、Adaptation 與 Gap Detection，最後才允許 AI 對真正無法覆蓋的剩餘部分進行：

$$
G_{\mathrm{residual}}
$$

但「只生成 Residual」本身仍不夠。

即使 AI 只生成世界的 $5\%$ ，如果這 $5\%$ 恰好涉及：

- 新 authority path；
- 新 state write scope；
- 新 transition；
- 新 event contract；
- 新 structural mutation；
- 新 external actuator；

它仍可能破壞整個世界的可重播性、安全邊界與因果一致性。

因此，本篇正式建立 **Generative Constraint Stack**。任何由 AI 生成、適配或補全的世界結構，都必須依序通過：

$$
\boxed{
C_{\mathrm{syntax}}
\cap
C_{\mathrm{schema}}
\cap
C_{\mathrm{semantic}}
\cap
C_{\mathrm{authority}}
\cap
C_{\mathrm{behavioral}}
}
$$

並額外接受：

- provenance / lineage；
- risk tier；
- generated diff review；
- shadow validation；
- regression gate；
- promotion；
- rollback。

本篇最重要的主張是：

$$
\boxed{
\text{Generated}
\neq
\text{Executable}
}
$$

以及：

$$
\boxed{
\text{Executable}
\neq
\text{Promoted to Live World}
}
$$

AI 可以生成世界結構，但它的輸出首先只是 **Candidate World Patch**。真正的世界真相仍然只能經過既有 Compiler、Contract、Scenario、Regression、Authority 與 Promotion 流程後才成立。

---

# 1. 現況：CompilableWorld 已有很多「約束元件」，但尚未形成完整生成治理鏈

目前 Repository 已經存在的關鍵設計包括：

- Authoring Layer、Compiled Package、Runtime State 分離；
- AI Adapter／UI 不得直接修改 StateStore；
- Module 只能提出 `StateDelta + EventIR`；
- Kernel 強制 Module write scope；
- FunctionIR 只允許受限純數值 AST；
- ScenarioIR 必須走正常 Runtime 管線；
- Studio import／mapping／preview 不能繞過 Compiler；
- MCP read-only adapter 不得取得 StateStore 直接寫入權；
- Snapshot restore 在碰 live Runtime 前先驗證 replacement structures；
- event visibility 採 fail-closed；
- Quest ambiguous transition 在編譯期拒絕；
- Core schema 已外化並由 Compiler 補跨檔案語意驗證。

這些不是零散規則。

它們其實已經共同指向一個思想：

$$
\boxed{
\text{World Change Must Cross Explicit Contracts}
}
$$

本篇不重新發明這些邊界，而是把它們組成未來 AI-generated world structure 的正式治理鏈。

---

# 2. 第一條總原則：生成結果不是世界真相

未來 AI 可能生成：

- Authoring data；
- mapping；
- FunctionIR；
- State schema；
- Transition；
- Scenario；
- ModuleContract；
- Module implementation；
- Projection；
- Domain-specific rule。

但無論生成內容多合理，都必須先被定義為：

$$
\boxed{
P_g=
\text{Generated Candidate Patch}
}
$$

而不是：

$$
P_g=
\text{World Truth}
$$

正確流程：

$$
\boxed{
\text{AI Output}
\rightarrow
\text{Candidate Patch}
\rightarrow
\text{Validation Pipeline}
\rightarrow
\text{Candidate Package}
\rightarrow
\text{Promotion}
}
$$

因此必須保留：

$$
\boxed{
W_{\mathrm{author}}
\neq
W_{\mathrm{compiled}}
\neq
W_{\mathrm{runtime}}
}
$$

AI 只能先改第一層，不能直接跳到第三層。

---

# 3. 第二條總原則：Generated 不等於 Executable

假設 AI 生成：

```yaml
module:
  id: smartdoor
  writes:
    - door.locked
```

語法正確，不代表：

- `door.locked` 是合法 state；
- Module 有權寫；
- event payload 完整；
- transition 不衝突；
- Scenario 能通過；
- 舊 Reference World 不受影響。

所以：

$$
\boxed{
\text{Syntactic Validity}
\ll
\text{World Validity}
}
$$

生成式約束必須至少分五層。

---

# 4. Constraint Layer 1：Syntax Constraint

第一層：

$$
C_{\mathrm{syntax}}
$$

只回答：

> 生成內容是否能被 parser 正確讀取？

例如：

- JSON 可 parse；
- YAML subset 合法；
- CSV column 格式正確；
- FunctionIR AST node 格式正確；
- expression token 合法。

這是最低門檻。

可以表示：

$$
C_{\mathrm{syntax}}(x)
\in
\{0,1\}
$$

若：

$$
C_{\mathrm{syntax}}=0
$$

直接拒絕。

不進後續階段。

---

# 5. Constraint Layer 2：Schema Constraint

第二層：

$$
C_{\mathrm{schema}}
$$

回答：

> 欄位、型別、版本、必要值與 contract 是否符合正式 Schema？

現有 repo 已有多個 versioned schemas，例如：

- FunctionIR；
- ScenarioIR；
- Runtime Package；
- rooms / exits；
- entities / items；
- Studio World IR；
- Studio mapping。

Schema Constraint 應檢查：

- required field；
- enum；
- type；
- version；
- unknown field policy；
- ID format；
- array/cardinality；
- schema `$id`。

所以：

$$
\boxed{
C_{\mathrm{schema}}
>
C_{\mathrm{syntax}}
}
$$

一份 JSON 可以合法 parse，但仍可能違反 schema。

---

# 6. Constraint Layer 3：Semantic Constraint

第三層：

$$
C_{\mathrm{semantic}}
$$

這是 Compiler 真正重要的地方。

它回答：

> 結構雖然符合 Schema，但是否在世界語義上自洽？

例如：

- entity reference 是否存在；
- item owner 是否合法；
- room graph 是否可達；
- Quest transition 是否指向合法 state；
- 同一 transition 是否 ambiguous；
- terminal state 是否又被轉移；
- Event payload 是否符合已知規則；
- Function input 是否完整；
- Prototype dependency 是否滿足；
- namespace 是否衝突。

因此：

$$
\boxed{
\text{Schema-valid}
\not\Rightarrow
\text{Semantically valid}
}
$$

這也是為什麼未來不能只讓 AI 產 JSON Schema 便自稱「生成已受約束」。

---

# 7. Semantic Constraint 應該能回答「世界是否自洽」

未來可以把 Semantic Constraint 拆成：

$$
C_{\mathrm{semantic}}
=
C_{\mathrm{reference}}
\cap
C_{\mathrm{graph}}
\cap
C_{\mathrm{transition}}
\cap
C_{\mathrm{dependency}}
\cap
C_{\mathrm{invariant}}
$$

例如：

### Reference

所有 ID reference 存在。

### Graph

World / task / dependency graph 合法。

### Transition

不存在未定義或不允許 transition。

### Dependency

Prototype / Module 所需能力已提供。

### Invariant

沒有破壞核心世界不變量。

---

# 8. Constraint Layer 4：Authority Constraint

第四層：

$$
C_{\mathrm{authority}}
$$

這是最不能被 AI 相似度取代的一層。

它回答：

> 即使行為語義合理，這個生成結構有沒有資格讀、寫、執行、訂閱、控制？

目前 `ModuleContract` 已經具備：

- actions；
- events；
- read；
- write；
- layer；
- version。

而 Kernel 已經實際 enforce write scope。

未來生成治理至少需要：

$$
C_{\mathrm{authority}}
=
C_{\mathrm{read}}
\cap
C_{\mathrm{write}}
\cap
C_{\mathrm{action}}
\cap
C_{\mathrm{event}}
\cap
C_{\mathrm{structure}}
$$

其中最後一個：

$$
C_{\mathrm{structure}}
$$

代表誰可以新增／修改：

- Schema；
- ModuleContract；
- authority policy；
- Prototype；
- Event contract。

這個權限應明顯高於普通 State mutation。

---

# 9. State Mutation Authority 與 Structure Mutation Authority 必須徹底分離

目前一般 Runtime 行為：

$$
\text{Action}
\rightarrow
\text{StateDelta}
$$

屬於：

$$
\boxed{
A_{\mathrm{state}}
}
$$

但新增：

- `combat.status_effects` 這種新 write path；
- 新 Module；
- 新 event type；
- 新 Schema；

屬於：

$$
\boxed{
A_{\mathrm{structure}}
}
$$

必須滿足：

$$
A_{\mathrm{structure}}
>
A_{\mathrm{state}}
$$

這裡的 $>$ 表示更高治理門檻，不是數值大小。

Repository 中已有一個很好的真實案例：新增 generic status-effect duration 時，CombatModule 原本沒有宣告 `combat.status_effects` write scope，導致整個 atomic commit 被 PermissionDenied 擋下。最後修正 ModuleContract 並補 live Kernel regression test。

這個 bug 反而證明：

> **新增世界能力時，Contract 同步更新不是文件工作，而是實際執行必要條件。**

---

# 10. Constraint Layer 5：Behavioral Constraint

第五層：

$$
C_{\mathrm{behavioral}}
$$

回答：

> 即使結構合法、語義自洽、權限正確，實際跑起來是否真的符合預期？

這就是 ScenarioIR 與 Regression 的角色。

基本形式：

$$
\text{Given}
\rightarrow
\text{When}
\rightarrow
\text{Then}
$$

未來生成任何 transition／module／prototype，都至少應附帶：

- happy path；
- denial path；
- boundary path；
- conflict path。

所以 AI 不應只生成：

```text
new transition
```

而應同時生成：

```text
new transition
+ scenario evidence
```

即：

$$
\boxed{
\text{Generated Behavior}
\Rightarrow
\text{Generated Test Obligation}
}
$$

---

# 11. 五層 Constraint Stack

完整表示：

$$
\boxed{
C(x)
=
C_{\mathrm{syntax}}
\cap
C_{\mathrm{schema}}
\cap
C_{\mathrm{semantic}}
\cap
C_{\mathrm{authority}}
\cap
C_{\mathrm{behavioral}}
}
$$

只有：

$$
C(x)=1
$$

才表示：

> 這個 candidate patch 通過第一階段執行資格。

但仍不代表可以直接進 live world。

---

# 12. 通過 Constraint 仍不等於可以 Promotion

因為還有一個更大的問題：

> 它是否破壞既有世界？

所以需要：

$$
\boxed{
C_{\mathrm{regression}}
}
$$

如果新 Patch 通過自己新增的 Scenario，但讓：

- combat；
- quest；
- snapshot；
- replay；
- MCP projection；
- Studio import；

其中任何已驗證能力失敗，仍然不能 Promote。

因此真正 gate 是：

$$
\boxed{
G_{\mathrm{candidate}}
=
C(x)
\cap
C_{\mathrm{regression}}
}
$$

---

# 13. Reference World 的真正價值在這裡出現

第 2 篇將 Game Runtime 定義為：

$$
\text{Regression Anchor}
$$

在生成治理裡，它的作用正式落地。

任何 Generalization / Prototype / Generated Patch 都要回答：

> 舊 Reference World 還能不能跑？

因此：

$$
\text{New Feature}
\not\Rightarrow
\text{Old World Broken}
$$

應成為 Promotion gate。

---

# 14. Risk Tier：不是所有生成內容都值得同樣審查

本篇正式提出生成風險分級。

---

## Tier 0：Projection-only

例如：

- 新 View；
- UI field；
- read-only report；
- diagnostic projection。

不能改 State。

風險最低。

---

## Tier 1：Pure Computation

例如：

- 新 FunctionIR；
- derived score；
- deterministic projection formula。

仍不能直接改 State。

---

## Tier 2：Scenario / Authoring Content

例如：

- 新 dialogue；
- 新 narrative；
- 新 non-authoritative content；
- 新 Scenario。

可以影響內容，但不改 Core authority。

---

## Tier 3：State / Transition Extension

例如：

- 新 state path；
- 新 transition；
- 新 status；
- 新 task state。

需要更嚴格 Scenario 與 regression。

---

## Tier 4：Module / Event / Authority Extension

例如：

- 新 Module；
- 新 write scope；
- 新 action；
- 新 Event contract；
- 新 read scope；
- 新 authority rule。

屬高風險。

---

## Tier 5：External Effect / Structural Runtime Mutation

例如：

- 真實設備控制；
- live structure mutation；
- 自動安裝新 Module；
- 修改 security policy；
- runtime schema hot migration。

最高風險。

---

# 15. Risk Tier 應影響 Promotion Policy

可以定義：

$$
\operatorname{ReviewDepth}(x)
=
f(\operatorname{RiskTier}(x))
$$

例如：

### Tier 0–1

可允許：

- automatic validation；
- automatic promotion under strict constraints。

### Tier 2–3

需要：

- generated diff；
- Scenario；
- regression；
- possibly reviewer approval。

### Tier 4

需要：

- explicit authority review；
- contract review；
- sandbox；
- human/independent-agent approval。

### Tier 5

預設：

$$
\boxed{
\text{No Automatic Live Promotion}
}
$$

---

# 16. Generated Diff Review 必須是第一級資產

AI 不應只輸出「新的完整檔案」。

最好輸出：

$$
\boxed{
\Delta W_{\mathrm{author}}
}
$$

即 Authoring Diff。

Diff 至少要標記：

```text
added
removed
changed
derived_from
risk_tier
new_authority
new_state_paths
new_events
new_transitions
new_dependencies
generated_fields
```

這讓 reviewer 不需要重新讀完整世界。

---

# 17. Diff 應分「語法 Diff」與「語義 Diff」

普通 Git diff 只能看到：

```text
+ writes: combat.status_effects
```

但世界狀態 Runtime 更需要：

```text
Semantic Diff:
  module combat.core
  gains write authority:
    combat.status_effects

  new state path:
    owner=character
    namespace=combat
    key=status_effects

  behavior impact:
    status can now persist across exchanges
```

所以未來 Studio 很適合提供：

$$
\boxed{
\text{Semantic World Diff}
}
$$

而不是只顯示文字行差異。

---

# 18. AI 生成 Patch 必須附「理由」，但理由不是權威

可以要求：

```yaml
rationale:
  reused:
    - prototype.status.timed_effect
  residual:
    - combat-specific refresh policy
  new_authority:
    - combat.status_effects
  scenarios_added:
    - shield_expiry
    - haste_decay
```

這有助於 review。

但：

$$
\boxed{
\text{AI Rationale}
\neq
\text{Validation Evidence}
}
$$

真正 evidence 仍然是：

- Compiler；
- Scenario；
- tests；
- trace；
- regression。

---

# 19. Shadow Validation：高風險生成應先存在於候選世界

未來可以建立：

```text
live package
candidate package
```

高風險 Patch 不直接取代 live。

而是：

$$
W_{\mathrm{live}}
+
\Delta W
\rightarrow
W_{\mathrm{candidate}}
$$

然後在 Candidate 上跑：

- compile；
- scenario；
- replay；
- benchmark；
- trace；
- migration dry-run。

直到：

$$
\operatorname{Promotable}(W_{\mathrm{candidate}})=1
$$

才切換。

---

# 20. Promotion 應該是一個顯式事件，而不是檔案「剛好被改了」

可以定義：

$$
\text{Candidate}
\xrightarrow{\text{Promote}}
\text{Active}
$$

Promotion metadata 至少包含：

- patch ID；
- source；
- reviewer；
- validation report；
- risk tier；
- target runtime version；
- migration ID；
- rollback target。

這讓世界結構演化本身也可稽核。

---

# 21. Rollback：生成治理沒有 rollback 就不完整

如果新 Candidate 在 live 後出現問題，需要能：

$$
W_{v+1}
\rightarrow
W_v
$$

但 Rollback 不只是 Git checkout。

因為 Runtime State 可能已經經歷：

$$
S_v
\rightarrow
S_{v+1}
$$

所以要區分：

### Code / Package Rollback

回到舊 Runtime Package。

### State Migration Rollback

把新 schema/state 轉回舊格式。

### Event Compatibility Rollback

確保新版本 event 不讓舊版本 replay 崩潰。

所以：

$$
\boxed{
\text{Rollback}
=
\text{Package}
+
\text{State}
+
\text{Event Compatibility}
}
$$

---

# 22. 如果 Rollback 不可能，必須在 Promotion 前明確標記

某些 migration 是 destructive。

例如：

- 合併 state；
- 刪除資料；
- one-way schema migration。

則 promotion report 應標：

```text
rollback_class:
  reversible
  forward-only
  snapshot-required
```

高風險 irreversible Patch 不應被 AI 默默升級。

---

# 23. AI 生成 Module 的最低要求

若 AI 真的生成新 Module，至少需要同時生成：

1. `ModuleContract`
2. action list
3. event list
4. read scope
5. write scope
6. dependency
7. failure semantics
8. Scenario
9. trace expectation
10. risk tier

也就是：

$$
\boxed{
\text{Module Code Alone Is Invalid Output}
}
$$

這是非常重要的工程規則。

---

# 24. AI 生成 State Schema 的最低要求

新 State path 不只是：

```text
weather.alert_level
```

還至少需要：

- owner type；
- namespace owner；
- value type；
- initial state；
- mutation policy；
- writer；
- reader；
- snapshot policy；
- migration policy；
- projection visibility。

所以：

$$
\boxed{
\text{State Field}
=
\text{Value}
+
\text{Governance}
}
$$

---

# 25. AI 生成 Event 的最低要求

新 Event type 至少要有：

$$
E_c=
(
type,
source,
payload\ schema,
visibility,
authority,
version
)
$$

並回答：

- 誰產生；
- 誰訂閱；
- 是否可公開；
- 是否可 replay；
- 是否可作為 transition trigger；
- payload version 如何 migration。

不能只是：

```text
emit "something_happened"
```

---

# 26. AI 生成 Authority 的最低要求

新增權限是最高風險類別之一。

任何 authority extension 都要回答：

$$
\operatorname{Grant}
(
subject,
action,
resource,
scope,
condition,
expiry
)
$$

並且預設：

$$
\boxed{
\text{Fail Closed}
}
$$

如果新 role／capability 無法判斷，應拒絕，而不是「大概可以」。

---

# 27. Constraint Failure 必須是可解釋的

生成系統不能只回：

```text
INVALID
```

應回：

```text
schema:
  missing: event.version

semantic:
  unknown_ref: entity.door.front

authority:
  write_not_allowed:
    module: room.light
    path: door.locked

behavioral:
  failed_scenario:
    visitor_must_not_unlock
```

這使 AI 可以：

$$
\text{Generate}
\rightarrow
\text{Fail}
\rightarrow
\text{Repair}
$$

而不是整份重生。

---

# 28. Repair 應優先局部修補，不重新生成整個 Patch

本篇延伸 Minimum Novelty Principle：

$$
\boxed{
\text{Minimum Repair Principle}
}
$$

如果只有：

```text
missing write scope
```

不要重新生成整個 Module。

只產：

$$
\Delta P_{\mathrm{repair}}
$$

並保留原 lineage。

---

# 29. 生成式驗證應保存 Failure Corpus

每次 AI 生成被拒絕，都可以留下：

```text
candidate
failure reason
repair
final outcome
```

形成：

$$
\boxed{
\text{Generation Failure Corpus}
}
$$

這會讓 Reference World 不只知道：

> 遊戲曾經怎麼壞。

還知道：

> AI 曾經怎麼把世界結構寫壞。

未來 Prototype Retrieval／Composer 可以用它避免重犯。

---

# 30. Auto-Promotion 應該極度保守

未來即使希望更自治，也應滿足：

$$
\text{AutoPromote}(x)=1
$$

只有在：

$$
Risk(x)\le\theta_r
$$

且：

$$
C(x)=1
$$

且：

$$
C_{\mathrm{regression}}=1
$$

且：

$$
Rollback(x)=\text{safe}
$$

且：

$$
AuthorityDelta(x)=0
$$

這類條件下。

因此自動 Promotion 最初只適合：

- projection；
- pure function；
- non-authoritative content；

而不是新的 authority 或 physical effect。

---

# 31. 生成治理與 MSSP 的關係

MSSP 的核心價值之一是：

> 世界能力以 Module 邊界被組合。

生成治理的目的不是取消 MSSP。

而是確保 AI 新增 Module 時：

$$
\boxed{
\text{Generated Module}
\subset
\text{Governed MSSP Runtime}
}
$$

也就是模型可以寫得非常複雜，但仍然被：

- ModuleContract；
- Kernel；
- Event；
- StateDelta；
- Scenario；

包住。

---

# 32. 生成治理與 RDR 的關係

RDR 未來可能讓大量 AI-generated rule 更有效地：

- dispatch；
- cache；
- break cycle；
- trace。

但 RDR 不能取代：

$$
\text{Generation Validation}
$$

RDR 回答：

> 已存在的規則如何有效執行？

本篇回答：

> 哪些生成規則有資格成為「已存在的規則」？

所以：

$$
\boxed{
\text{Validation}
\rightarrow
\text{Promotion}
\rightarrow
\text{Dispatch Optimization}
}
$$

順序不能倒過來。

---

# 33. 生成約束的第一版不需要複雜 AI Judge

v0.1 完全可以先用：

- schema validator；
- compiler；
- module contract validator；
- scenario；
- regression；
- static risk classifier；
- semantic diff report。

AI Judge 可以作為額外 reviewer，但不能是唯一 gate。

這使第一版非常務實。

---

# 34. 建議的 Candidate Patch Manifest

未來可以概念上輸出：

```yaml
candidate_patch:
  id: patch.smartroom.001
  generated_by: agent_x
  based_on:
    - reference.game.v0.5
    - prototype.timed_state.v0.2

  risk_tier: 4

  changes:
    state:
      add:
        - occupancy.present
    actions:
      add:
        - unlock_remote
    authority:
      add:
        - homeowner.remote_unlock

  lineage:
    reused:
      - prototype.action.authorized_write
    adapted:
      - prototype.door.lockable
    generated:
      - physical_ack_placeholder

  validation:
    syntax: pass
    schema: pass
    semantic: pass
    authority: pending
    behavioral: pending
    regression: pending

  rollback:
    class: reversible
```

這類 manifest 可以成為 Studio／Agent Review 的核心輸出。

---

# 35. 完整生成治理管線

本篇最後將流程正式收斂為：

$$
\boxed{
\begin{aligned}
&\text{RequirementIR}\\
\rightarrow\;&\text{Prototype Composition}\\
\rightarrow\;&\text{Residual Spec}\\
\rightarrow\;&\text{Generated Candidate Patch}\\
\rightarrow\;&C_{\mathrm{syntax}}\\
\rightarrow\;&C_{\mathrm{schema}}\\
\rightarrow\;&C_{\mathrm{semantic}}\\
\rightarrow\;&C_{\mathrm{authority}}\\
\rightarrow\;&C_{\mathrm{behavioral}}\\
\rightarrow\;&C_{\mathrm{regression}}\\
\rightarrow\;&\text{Risk Review}\\
\rightarrow\;&\text{Candidate Package}\\
\rightarrow\;&\text{Promotion}\\
\rightarrow\;&\text{Live Runtime}
\end{aligned}
}
$$

其中任一 Gate 失敗：

$$
\rightarrow
\text{Reject / Repair / Recompose}
$$

而不是：

$$
\rightarrow
\text{Force Deploy}
$$

---

# 36. 核心不變量

## G-1：Generated 不等於 Executable

生成輸出只能先成為 Candidate。

## G-2：Executable 不等於 Live

通過 Compiler 仍需要 Regression / Promotion。

## G-3：AI 不得直接寫 StateStore

既有 invariant 長期保留。

## G-4：Structure Mutation Authority 高於 State Mutation Authority

新增 Schema／Module／Authority 必須更嚴格。

## G-5：每個 Generated Behavior 都有 Test Obligation

不能只有 code。

## G-6：Authority Extension 預設 Fail Closed

不確定就拒絕。

## G-7：所有生成必須保存 lineage

可以追溯 Reference／Prototype／AI Generated 部分。

## G-8：高風險變更預設不可 Auto-Promote

尤其 Tier 4–5。

---

# 37. 禁止事項

## 禁止 A：Schema-valid 就直接執行

Schema 只是第二層。

## 禁止 B：AI Rationale 當 Evidence

模型解釋不是測試。

## 禁止 C：用 AI Judge 取代 Compiler

LLM reviewer 只能輔助。

## 禁止 D：生成 Module 不生成 Contract

無 Contract 的 Module 視為 invalid artifact。

## 禁止 E：生成 State 不定義 Governance

新 state field 必須知道誰能寫、怎麼 migration。

## 禁止 F：高風險 Patch 自動 Live Promotion

尤其 authority／external effect。

## 禁止 G：修一個錯誤時重生整個世界

優先 Minimum Repair。

---

# 38. 尚未實作

本篇以下結構目前都屬於未來提案：

- Generated Candidate Patch contract；
- risk tier metadata；
- semantic diff；
- shadow candidate package；
- promotion service；
- rollback manifest；
- generation failure corpus；
- auto-promotion policy；
- structure mutation authority；
- generated test obligation enforcement。

目前 repo 已經提供的是：

> 未來可以拿來實作這條治理管線的 Compiler、Schema、ModuleContract、Scenario、Snapshot、Replay 與 Regression 基底。

---

# 39. 驗證條件

未來要稱「生成式約束 v0.1」成立，至少要驗證：

## V-1

故意生成 syntax-invalid patch，第一層拒絕。

## V-2

syntax-valid 但 schema-invalid patch，第二層拒絕。

## V-3

schema-valid 但 reference 不存在／transition ambiguous，Semantic Gate 拒絕。

## V-4

semantic-valid 但 write scope 不合法，Authority Gate 拒絕。

## V-5

前四層合法但 Scenario 行為不符，Behavioral Gate 拒絕。

## V-6

新 Scenario 全過但破壞 Reference regression，不允許 Promotion。

## V-7

Tier 4 authority change 不能 Auto-Promote。

## V-8

被拒絕 patch 能產生結構化 failure report。

## V-9

局部 repair 不丟失 lineage。

## V-10

Rollback metadata 在 Promotion 前已存在。

---

# 40. 本篇結論

動態生成不是問題。

沒有治理邊界的動態生成才是問題。

因此未來 Dynamic General World-State Runtime 不應把 AI 定義為：

> 可以直接改世界的作者。

更準確的定位是：

$$
\boxed{
\text{AI}
=
\text{Candidate Structure Generator}
+
\text{Adapter}
+
\text{Repairer}
}
$$

而世界真正接受變化的方式仍然是：

$$
\boxed{
\text{Contract}
+
\text{Compiler}
+
\text{Authority}
+
\text{Scenario}
+
\text{Regression}
+
\text{Promotion}
}
$$

整個生成治理可以用一句話總結：

$$
\boxed{
\text{Generate Freely Inside a Strict Promotion Boundary.}
}
$$

也就是：

> **生成可以有彈性，但「什麼有資格成為世界真相」必須非常嚴格。**

到這一步，前五篇已完成封閉虛擬世界內的主要架構：

$$
\text{Reference}
\rightarrow
\text{Prototype}
\rightarrow
\text{Composition}
\rightarrow
\text{Residual Generation}
\rightarrow
\text{Constraint / Promotion}
$$

下一篇將跨過目前最重要的一條邊界：

# 《從封閉遊戲世界到開放現實世界：Observation、Belief 與 External Effect》

因為在遊戲裡：

$$
\text{State}
\approx
\text{Truth}
$$

但一旦進入真實設備、機器人、智慧空間或外部系統：

$$
\boxed{
\text{Observation}
\neq
\text{Truth}
}
$$

而：

$$
\boxed{
\text{Command Sent}
\neq
\text{World Changed}
}
$$

那會是通用世界狀態 Runtime 真正跨出遊戲世界的第一個巨大結構變化。

---

# Appendix A：Repository Grounding

2026-08-01 再次檢查 repository 最近提交，最新仍為：

- `72334d7881749c78d323684e3ddbbc2b8aab86da`：read-only MCP、world projection、event visibility；
- `c9a33185ac7df5863e76995b0ebb097578e6be7e`：Studio runtime authoring contracts、AMK、atomic snapshot restore、regression。

本篇亦使用 repo 既有的真實工程教訓作為生成約束依據：

- generic status-effect extension 曾因未同步更新 ModuleContract write scope 而被 Kernel PermissionDenied 擋下；
- ambiguous quest transition 已被設計為 compile-time fail closed；
- Studio mapping 尚未具備可執行語義時不得自動 compile；
- MCP read-only tooling 必須證明不改變 state/event/tick/action registry。

這些例子共同支持本篇的核心判斷：**世界結構的新增必須經過 contract 與 validation，而不能因為功能「看起來合理」就取得執行資格。**