docs(architecture): 标记生成引擎子树为「架构演进中」

review 暴露生成域正处于 gameDefinition→src/ 终态迁移 + 产线化(plan 2026-06-18-001 U1–U4)。给 11 份子树档插「🚧 架构演进中」横幅 + L1 总索引/架构 README 导航处加注,提示现行结论可能随 plan 推进变化、以最新裁定为准。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

docs/architecture/README.md

@@ -45,7 +45,7 @@ flowchart LR
 
 ### 架构域 · 生成引擎旗舰子树
 
-生成引擎是绘境AI 护城河的关键路径,内容最厚,单独成一棵子树:
+生成引擎是绘境AI 护城河的关键路径,内容最厚,单独成一棵子树。**🚧 注意:这块架构正处于演进中**(gameDefinition→`src/` 终态迁移 + 产线化 plan `2026-06-18-001` U1–U4),子树内标注的现行结论可能随推进变化,以最新裁定 / plan 为准:
 
 | 子文档 | 讲什么 |
 |---|---|

docs/architecture/架构/README.md

@@ -400,7 +400,7 @@ erDiagram
 
 | 文档 | 回答什么 |
 |---|---|
-| [生成引擎](生成引擎/) | 生成主线的深层架构:SAA 16 节点拓扑、加节点方法、new-api 接入、checkpoint 框架坑、dispatcher 契约、九门 harness |
+| [生成引擎](生成引擎/) 🚧 | **架构演进中**(gameDefinition→`src/` 终态迁移、产线化 plan 2026-06-18-001 U1–U4)。生成主线的深层架构:SAA 16 节点拓扑、加节点方法、new-api 接入、checkpoint 框架坑、dispatcher 契约、九门 harness |
 | [前端域](../前端/) | game-studio / game-admin 的前端设计体系、组件分层、SDK 源码组织、运行时容器 |
 | [后端域](../后端/) | 后端模块的实现级设计、API 路径规范、错误码分配、Flyway 迁移、契约对齐 |
 | [运维域](../运维/) | 环境/部署/staging 运维、构建门、smoke 门、运行时打包与多渠道导出手册 |

docs/architecture/架构/生成引擎/OpenGame对照.md

@@ -1,5 +1,7 @@
 # OpenGame 对照 · 外部标杆深读
 
+> 🚧 **架构演进中** —— 生成引擎子树正处于 gameDefinition→`src/` 终态迁移 + 产线化(plan `2026-06-18-001` U1–U4)中,文中标注的现行结论可能随推进变化;以子树 [README](README.md) 与最新裁定 / plan 为准。
+
 > **这是什么**:绘境AI 生成引擎对外部最强开源标杆 **OpenGame** 的源码级深读,以及由此照出的复刻缺口。它回答两个问题——"**OpenGame 到底是怎么把一句话变成游戏的**",以及"**它身上哪三层东西值钱、我们还没有**"。
 > **给谁看**:负责生成主线的工程师、做技术选型与对标的架构评审、想看清护城河关键路径上"我们与最强开源系统差在哪"的人。
 > **怎么读**:先读 §1 的定位与一张对照全景图;§2 是主体——逐层拆 OpenGame 的真实机理(主循环 / 韧性 / 子 agent / 系统提示 / 六阶段生成 / 三大支柱);§3 落到我们的现状,把缺口分四类诚实交代。想要"往哪走、先做什么"的统一行动项,去[生成主线架构演进路线](../../../agent-specs/生成主线架构演进路线.md)拿——本档只负责把 OpenGame 的内部机理和逐项缺口的来龙去脉讲透。

docs/architecture/架构/生成引擎/README.md

@@ -1,5 +1,7 @@
 # 生成引擎 · 设计主文档
 
+> 🚧 **架构演进中** —— 本子树描述的生成架构正处于 gameDefinition→`src/` 终态迁移 + 产线化(plan `2026-06-18-001` U1–U4)中;文中标注的现行结论可能随 plan 推进变化。
+
 > **这是什么**:绘境AI 生成引擎子树的设计主文档,回答"**一句话怎么变成一款可上线的游戏**"这条技术主线——它的现行架构、要往哪走的演进路线,以及贯穿全程的一条范式原则。
 > **给谁看**:负责生成主线的工程师、新加入这条线的同事、架构评审、做尽调时想看清护城河关键路径的人。
 > **怎么读**:先读 §1 建立"这台机器是什么"的整体认知,再看 §2 那张端到端流程图;想了解当前债与未来路线读 §4–§6;想要更深的子系统细节,从文末的源档导航进去。

docs/architecture/架构/生成引擎/SAA编排.md

@@ -1,5 +1,7 @@
 # SAA 编排 · 生成引擎基建设计
 
+> 🚧 **架构演进中** —— 生成引擎子树正处于 gameDefinition→`src/` 终态迁移 + 产线化(plan `2026-06-18-001` U1–U4)中,文中标注的现行结论可能随推进变化;以子树 [README](README.md) 与最新裁定 / plan 为准。
+
 > **这是什么**：绘境AI 生成引擎的 AI 编排基建设计文档,回答"**用什么框架把一句话编排成一款游戏、为什么这样分层、有哪些不能破的约束**"。
 > **给谁看**:负责生成主线的后端工程师、架构评审、新加入参与生成模块的同事。
 > **怎么读**:先读第 1 节建立决策锚点(为什么是 SAA、它和"自治型 agent"是两种问题),再看第 2 节那张编排拓扑图建立全局;想了解硬约束读第 4 节六条不变量,想了解过渡期治理风险读第 5 节 split-brain 防线,想看清和旧编排器的职责边界读第 7 节。实现级的坑清单与逐键源码旁证不在本页,通过文末第 10 节的指针跳转。

docs/architecture/架构/生成引擎/SAA能力API-dossier.md

@@ -1,5 +1,7 @@
 # SAA 能力 / API / 接入 · 逐键源码证据底座
 
+> 🚧 **架构演进中** —— 生成引擎子树正处于 gameDefinition→`src/` 终态迁移 + 产线化(plan `2026-06-18-001` U1–U4)中,文中标注的现行结论可能随推进变化;以子树 [README](README.md) 与最新裁定 / plan 为准。
+
 > **这是什么**:绘境AI 生成引擎采用 SAA(Spring AI Alibaba,阿里在 Spring 生态里的 AI 编排框架)作为编排基建——这份文档是那一决策背后的**逐键源码证据底座**。它不重复"为什么这样分层、有哪些不能破的不变量"那套架构论证(那在[SAA 编排](SAA编排.md)),而是回答更下沉的一层:**照着写代码时,该调哪些 API、本期到底哪些能力能用哪些不能、引进 game-cloud 会撞哪些依赖、按什么范式落节点、最容易踩哪几个坑——每一条都钉在 SAA 某个类的某一行源码上。**
 > **给谁看**:真正动手把 SAA 图落进 `game-module-aigc-server` 的后端工程师、做依赖冲突评审的人、复核"这条结论有没有源码支撑"的架构评审。
 > **怎么读**:这是一份**技术参考册**,不必线性通读。先扫第 0 节那五条决策级结论建立锚点,然后按需跳——要照着写代码翻第 1 节 API 速查,要判断"这个能力本期能不能用"翻第 2 节能力矩阵,要落 Maven / 解依赖冲突翻第 3 节,要照范式骨架写节点翻第 4 节,**动手前务必先过一遍第 5 节那六个坑**。

docs/architecture/架构/生成引擎/WG1基准.md

@@ -1,5 +1,7 @@
 # W-G1 基准 · 20 款经典轻游戏靶集与 4 类能力缺口
 
+> 🚧 **架构演进中** —— 生成引擎子树正处于 gameDefinition→`src/` 终态迁移 + 产线化(plan `2026-06-18-001` U1–U4)中,文中标注的现行结论可能随推进变化;以子树 [README](README.md) 与最新裁定 / plan 为准。
+
 > **这是什么**:绘境AI 生成引擎用来回答一个很实在的问题的设计文档——**"便宜的通用模型 + 我们当前这套引擎和插件库,到底能造出什么样的游戏、又造不出什么"**。它把 20 款人人都玩过的经典轻游戏铺成一张靶集,既验证生成管线确实能端到端跑通,又拿这些游戏去压测能力上限、把引擎和插件库的短板逼出来。
 > **给谁看**:负责生成主线的工程师、想知道"哪些品类现在就能放量做、哪些还得先补能力"的产品与创始人,以及做技术尽调时想看清"生成能力真实边界在哪"的架构评审。
 > **怎么读**:先读 §1 那张图,搞清楚"靶集是什么、为什么要这么排";想看每款游戏的覆盖判定读 §3 那张大表;想看四类能力缺口的诊断与证据读 §4;想看怎么分批跑读 §5。

docs/architecture/架构/生成引擎/prompt治理.md

@@ -1,5 +1,7 @@
 # Prompt 治理 · 生成引擎设计文档
 
+> 🚧 **架构演进中** —— 生成引擎子树正处于 gameDefinition→`src/` 终态迁移 + 产线化(plan `2026-06-18-001` U1–U4)中,文中标注的现行结论可能随推进变化;以子树 [README](README.md) 与最新裁定 / plan 为准。
+
 > **这是什么**：绘境AI 生成引擎里「Prompt 治理」这一子系统的设计文档,回答"**为什么把 prompt 当成一份正式契约来管、它长什么样、改一条 prompt 要过哪些关、人在什么环节介入**"。
 > **给谁看**:负责生成主线的后端工程师、写 prompt 的工位负责人、做架构评审的人,以及想搞清楚"生成质量为什么可控、可回归"的新同事。
 > **怎么读**:先读 §1 建立"prompt 为什么要当契约管"的整体认知,再看 §2 的数据流图理解它在生成链路里的位置;§4 是这套体系的心脏(改一条 prompt 的四道关),§6 讲人怎么介入;想要落地细节从 §3、§5 看接口与目录结构。

docs/architecture/架构/生成引擎/固定游戏架构.md

@@ -1,5 +1,7 @@
 # 固定游戏架构 + SAA 智能工作室
 
+> 🚧 **架构演进中** —— 生成引擎子树正处于 gameDefinition→`src/` 终态迁移 + 产线化(plan `2026-06-18-001` U1–U4)中,文中标注的现行结论可能随推进变化;以子树 [README](README.md) 与最新裁定 / plan 为准。
+
 > **这是什么**：绘境AI「一句话造游戏」背后的生成引擎设计。它回答一个核心问题——**一个便宜的小模型,怎么可靠地造出一款能上线、能玩的游戏**。
 > **给谁看**:生成引擎方向的工程师、架构评审、新加入的同事。
 > **怎么读**:先读 §1 抓住"固定脚手架 + 便宜模型填槽"这一个主意,其余各节都是它的展开。

docs/architecture/架构/生成引擎/开闸接线.md

@@ -1,5 +1,7 @@
 # 开闸接线 · 一句话入口的端到端接线
 
+> 🚧 **架构演进中** —— 生成引擎子树正处于 gameDefinition→`src/` 终态迁移 + 产线化(plan `2026-06-18-001` U1–U4)中,文中标注的现行结论可能随推进变化;以子树 [README](README.md) 与最新裁定 / plan 为准。
+
 > **这是什么**:本文讲清楚"开闸"这件事——把绘境AI 的一句话创作主链,从用户在创作页敲下一句话,一路接到这款游戏被种子用户在游戏信息流里真人试玩。它回答的不是"生成引擎内部怎么造游戏"(那条线在[生成引擎主文档](README.md)与 [SAA 编排](SAA编排.md)里),而是"造游戏这台机器已经就绪,创作页那道『必须先选模板』的门又是怎么被拆掉、让一句话能直接驱动生成的"。
 > **给谁看**:接这条链路的后端与前端工程师、做开闸决策的创始人、想看清"护城河闭环对外开放的最后一公里走到哪了"的人。
 > **怎么读**:先读 §1 拿到结论(接线已落地、为什么风险低),再看 §2 那张接线图建立全局,然后按需深入 §3 的取证与 §4 的三处协同改动(均已上线,标注落地 commit)。

docs/architecture/架构/生成引擎/引擎与运行时.md

@@ -1,5 +1,7 @@
 # 引擎与运行时 · 架构设计文档
 
+> 🚧 **架构演进中** —— 生成引擎子树正处于 gameDefinition→`src/` 终态迁移 + 产线化(plan `2026-06-18-001` U1–U4)中,文中标注的现行结论可能随推进变化;以子树 [README](README.md) 与最新裁定 / plan 为准。
+
 > **这是什么**：绘境AI 游戏引擎层与运行时装载体系的架构设计主文档，回答「选了哪个引擎、为什么选、游戏怎么挂上去、包怎么交付」。
 > **给谁看**：后端 / 前端工程师、AI 生成链路开发者、引擎集成评审方。
 > **怎么读**：先读第 1–2 节建立全局认知（选型结论 + 一张架构图），再按模块深入第 3–5 节。

docs/architecture/架构/生成引擎/设计合理性裁决.md

@@ -1,4 +1,7 @@
 ---
+
+> 🚧 **架构演进中** —— 生成引擎子树正处于 gameDefinition→`src/` 终态迁移 + 产线化(plan `2026-06-18-001` U1–U4)中,文中标注的现行结论可能随推进变化;以子树 [README](README.md) 与最新裁定 / plan 为准。
+
 date: 2026-06-20
 topic: 生成设计合理性 · 对抗审查裁决
 status: 裁决 · 待创始人拍板(愿景分层)

docs/architecture/架构/生成引擎/验收门-W-G1.md

@@ -1,5 +1,7 @@
 # 开闸验收门 W-G1 · 生成对外放行的 6 道门
 
+> 🚧 **架构演进中** —— 生成引擎子树正处于 gameDefinition→`src/` 终态迁移 + 产线化(plan `2026-06-18-001` U1–U4)中,文中标注的现行结论可能随推进变化;以子树 [README](README.md) 与最新裁定 / plan 为准。
+
 > **这是什么**:绘境AI 生成引擎"对外开闸"那一刻必须先架好的 6 道验收门的设计文档。它回答的是一个很具体的问题——**当"一句话生成游戏"第一次向真实创作者放开时,我们到底要先焊死哪些门、可以并行补哪些门、又有哪两道前置必须先验过才许放行?**
 > **给谁看**:负责生成主线开闸的工程师、质量与审核台一侧的同事、做发布放行决策的产品与创始人,以及想看清"放量前的安全/可控边界"的架构评审。
 > **怎么读**:先读 §1 那张"6 门怎么排"的全景图建立整体认知,再按 §2–§4 顺着三组门看每道门具体检查什么;想确认"能不能放"读 §5 的两道开闸前置验证结果;残留待办在 §6。