diff --git a/docs/agent-specs/2026-06-20-OpenGame对照分析与复刻缺口.md b/docs/agent-specs/2026-06-20-OpenGame对照分析与复刻缺口.md
index d495283d..bd0789bc 100644
--- a/docs/agent-specs/2026-06-20-OpenGame对照分析与复刻缺口.md
+++ b/docs/agent-specs/2026-06-20-OpenGame对照分析与复刻缺口.md
@@ -6,6 +6,7 @@ status: 分析 · reference
 
 > **产出方式**:clone OpenGame 真源码(`github.com/leigest519/OpenGame`,CUHK MMLab,arXiv 2604.18394)到 `/root/oss/OpenGame`,5 个 agent 分片深读真代码(agent核心/子agent · 游戏生成工具 · Game Skill 经验进化 · MCP+环境 · OpenGame-Bench/端到端/GameCoder-27B),综合成本档;6c6g 编排 + 可读性打磨。结论锚在真源码。
 > **三部分**:我们是什么(SAA graph 配置式)→ OpenGame 怎么生成游戏(深析主体)→ 要复刻它我们 SAA 缺什么。
+> **定位更新(2026-06-20)**:本档现作 **OpenGame 外部标杆 prior-art 深析参考**——“我们要做什么”的复刻缺口已并入单一 SoT [`生成主线架构演进路线.md`](生成主线架构演进路线.md)(去那份拿统一 to-do)。本档保留供查 OpenGame 内部机理与逐项缺口的来龙去脉。
 
 # 造梦AI 生成主线架构分析:我们是什么,OpenGame 怎么生成游戏,以及要复刻它我们还缺什么
 
diff --git a/docs/agent-specs/2026-06-19-生成平台架构演进-review.md b/docs/agent-specs/_archive/2026-06-19-生成平台架构演进-review.md
similarity index 100%
rename from docs/agent-specs/2026-06-19-生成平台架构演进-review.md
rename to docs/agent-specs/_archive/2026-06-19-生成平台架构演进-review.md
diff --git a/docs/agent-specs/_index.md b/docs/agent-specs/_index.md
index 23ea1d9b..c221ac81 100644
--- a/docs/agent-specs/_index.md
+++ b/docs/agent-specs/_index.md
@@ -25,8 +25,8 @@
 - `2026-06-17-多session分工与任务总账.md` — 三阶段/两开发线/增量集成 + 角色分权（Mac 实现 / 6c6g 独立评审+真机验 / studio 前端）；取代 `生成引擎-并行编排`(模块切分版)
 
 ### 生成主线设计链（现行架构）
-- ★ `2026-06-19-生成平台架构演进-review.md` — **多架构师综合·架构演进总方案（review·待创始人评审）**：**零 rewrite/大面积 keep**；病根=策略下沉机制层(多源漂移)+生成质量未达门+验收 oracle Goodhart；演进=策略外置(数据驱动·prompt/模型/品类提为契约)+九门去自评闭环(**latch 胜利/弃守区分=P0**+fail-closed)+单轨化,全程 flag-off 不破灰度；迁移序列挂 plan-001/002 不另起。承 [[agentic编排-SAA]]+固定架构设计链。
-- ★ `2026-06-20-OpenGame对照分析与复刻缺口.md` — **OpenGame(CUHK MMLab,Qwen-Code 二次 fork)真源码深读 + 复刻缺口**(散文·5 agent 读真码综合)：它靠 4 原子工具+六阶段 SOP(system-reminder 接力·无中央编排)+物理优先分类→GDD 契约→多模态资产→确定性贴图;**我们 SAA 图比它命令式循环更确定,核心不落后**;真缺 3 处=①约束厚度(template_api+GDD 契约·最高价值)②经验复利层(Template/Debug Skill)③资产线(走 mmx);它两卖点:27B 专训刻意不走;VLM Bench **代码其实没开源(只论文)**,单比已开源的九门已更硬,但**九门只覆机制层(能不能跑),VLM 的意图/视觉那两轴对应我们偏弱的 player 软门、是待补强缺口,非已赢项**。源码 clone 在 `/root/oss/OpenGame`。
+- ★ `生成主线架构演进路线.md` — **生成主线“往哪走、先做什么”的单一 SoT（散文·待创始人评审）**：把两条线合一——**线 A 加固现有**(trace 抽取/prompt 同源解 split-brain/模型外置/latch 终态语义 P0/cutover)+ **线 B 补 OpenGame 证明值钱的能力层**(GDD 契约+template_api=最高价值/Debug Skill 落 diagnose-repair+checkpoint/Template Skill 按 gameDefinition 重写+入库过九门门/资产接 mmx);两处交汇点(品类独立交叉校验·player 软门做厚)已合并不重列;统一迁移序列对齐 plan-001/002/003 不另起。**吸收并取代** `_archive/2026-06-19-生成平台架构演进-review.md`。承 [[agentic编排-SAA]]。
+- `2026-06-20-OpenGame对照分析与复刻缺口.md` — **外部标杆 prior-art 参考 · OpenGame 真源码深读**(复刻缺口已并入 ↑《生成主线架构演进路线》;本档供查 OpenGame 内部机理)：它靠 4 原子工具+六阶段 SOP(system-reminder 接力·无中央编排)+物理优先分类→GDD 契约→多模态资产→确定性贴图;**我们 SAA 图比它命令式循环更确定,核心不落后**;真缺 3 处=①约束厚度(template_api+GDD 契约·最高价值)②经验复利层(Template/Debug Skill)③资产线(走 mmx);它两卖点:27B 专训刻意不走;VLM Bench **代码其实没开源(只论文)**,单比已开源的九门已更硬,但**九门只覆机制层(能不能跑),VLM 的意图/视觉那两轴对应我们偏弱的 player 软门、是待补强缺口,非已赢项**。源码 clone 在 `/root/oss/OpenGame`。
 - `2026-06-17-固定游戏架构与SAA-agentic-studio-execution.md` — **ACTIVE · 当前生成主线架构 execution**（固定游戏架构=轻量声明式领域模型+2D 适配器 / SAA studio 9+1+1 agent / 8 契约 / 救场阶梯 / 缓存三段式；**两 spike 已绿**：缓存经 new-api 透传 76-93%、classify tickModel 100%）
 - `2026-06-17-固定游戏架构与SAA-agentic-studio-review.md` — 配套**设计 review**（含深析 §10 + 创始人决策；承原 v2 生命周期原则）
 - `2026-06-12-游戏生成系统总体架构-review.md` — 生成系统总体架构纲领（三级生成 / W-G0~G4 路线 / 意图矩阵）
diff --git a/docs/agent-specs/生成主线架构演进路线.md b/docs/agent-specs/生成主线架构演进路线.md
new file mode 100644
index 00000000..61c4b0fe
--- /dev/null
+++ b/docs/agent-specs/生成主线架构演进路线.md
@@ -0,0 +1,118 @@
+---
+date: 2026-06-20
+topic: 生成主线架构演进路线
+status: SoT · 待创始人评审
+---
+
+> **这是生成主线“往哪走、先做什么”的单一 SoT。** 它把两条分析线合并成一张图:一条是从我们自己 SAA 代码出发的内部诊断与加固(**吸收并取代**《2026-06-19 生成平台架构演进方案》,后者已归档为历史过程档);另一条是对标最强外部系统 OpenGame 的补能力(其逐行源码深析单独留作外部标杆参考档 [`2026-06-20-OpenGame对照分析与复刻缺口.md`](2026-06-20-OpenGame对照分析与复刻缺口.md),本路线引其结论、不重复其考据)。
+> **产出方式**:多架构师评审 + OpenGame 真源码 5-agent 深读 → 合成散文,6c6g 编排+可读性打磨。承重锚点已抽查属实(见 §六 末)。
+
+# 生成主线架构演进路线
+
+## 一、定调:我们是什么,这份路线是什么
+
+造梦AI 的游戏生成主线,本质上是一台被刻意设计成可靠的、固定相位的生成机器。它不是一个让强模型自由发挥的开放式编码 agent,而是**用便宜通用模型驱动、用确定性的图编排约束控制流、用九门 harness 兜底验收**的一条流水线。它的骨架是 Spring AI Alibaba 的裸 StateGraph,一共 16 个节点——从 render、classify、design、generate、validate、scaffold、asset、build,到 play 与 player、nreview、modify、escalate、repair,再到 emit 与 giveup。这些节点不是声明式 YAML,而是一段段实打实的 Java NodeAction;控制流由图的节点和边预先固定,而非由模型在运行时自由决定"下一步调什么工具"。模型这一层,我们硬编码了 11 个便宜通用模型(以 deepseek-v4-flash 打底),没有任何一个是为游戏代码专训过的;成本策略明确是"便宜模型加 harness 门兜底",而不是去训一个专用大模型来扛质量。这台机器的当前真实状态是:**结构正确、控制流确定、底层验收很硬的流水线已经建成并合入主干,双证地基已经成立,但生成质量尚未稳定达到 80% 门,而且策略层下沉进了机制层。**
+
+这份路线要做的,是把过去两条独立的分析线**合并成一张演进图**。第一条是从我们自己的 SAA 代码出发的内部诊断——债压在哪里、阶段 0 到 5 怎么加固;它由本路线**完整吸收**,原《2026-06-19 生成平台架构演进方案》在此之后退役为历史过程档。第二条是从最强外部系统 OpenGame 出发的对照分析——它怎么把一句话变成游戏、我们缺哪几层能力;那份深析作为**外部标杆参考档**单独保留为 `2026-06-20-OpenGame对照分析与复刻缺口.md`,本路线在需要时引用它的结论,但不重复它的逐行源码考据。读这一份,就读到了"生成主线往哪走、先做什么"的当前真相;要看 OpenGame 内部机理的细节,再去翻那份参考档。
+
+需要先讲清的一个判断,它决定了整张图的取舍边界:OpenGame 是**命令式自主循环**(`while(true)` 里模型自由决定下一步调什么工具,控制流由模型驱动),我们是**声明式有向图编排**(节点、边、条件预先固定,控制流由图驱动)。这是两种正交范式。所以本路线**不把 OpenGame 的主循环嫁接进来**——硬塞就成了项目明令反对的"缝合设计",而且对卡 80% 成功率门这件事而言,图的确定性本就比"DO NOT STOP"那种口头督促更稳。我们要抄的,是 OpenGame 的工具层、韧性兜底、防脏脚手架与经验复利机制,把它们当成零件库,原样落进 SAA 节点内部的工具执行环节;我们不抄它"模型自由驱动主循环"那套范式。本路线因此天然分成两条并行的线:一条**向内加固现有架构**,一条**向外补齐 OpenGame 证明值钱的能力层**。
+
+## 二、现状诊断:我们的债在哪里
+
+把这台机器拆开看,真正的病根不是"没建成",而是**机制已通、生成质量未达门,且策略下沉进机制层造成了多源漂移**。债集中在三类。
+
+**第一类是策略下沉进机制层。** 本该作为可替换数据的策略,被焊死进了不该重编译重部署的代码里,造成三处倒置。其一是模型路由:11 个便宜模型的名字和 per-role 的采样面,全是 Java 常量,换一个模型要改代码、重新构建。其二是 prompt 正文:gamedef 的生成约定(系统提示、运行时面的写法约定、命名对齐)是 Java 字面量,而 Python worker 那一侧又镜像了一份——同一份约定存在两个源,这是一个潜在的 split-brain,虽然当前 worker 走的还是纯 iife 路、这条裂缝尚未被真正激活,但只要 cutover 依赖 worker 线的数据,它就会立刻变成承重的坑。其三是品类骨架:由 design-agent 自己产出,没有外部锚。这三处倒置的共同后果是,凡涉及跨 Python 与 SAA 双轨的策略,一旦"策略化"做得不干净,就会从"一处硬编码"恶化成"多处不同步",拆东补西。
+
+**第二类是验收 oracle 的 Goodhart 风险——九门是机制地板,不是质量 oracle。** 九门 harness 判的是**机制**:能不能装载、跑不跑帧、响不响应输入、到不到终态,全是确定性的,这一层我们确定性地领先,是这套架构最大的工程价值,零理由动它。但它有两个真实口子。一是 latch 终态语义不分胜负:当前 latch 由系统强加(expectLatch 恒为 true),弃守排空也能逼出一个 gameover——这意味着一个空壳游戏可以蹭过 latch 门,而 latch 正是机制进展那一门的承重件。它对"这到底是不是题面要的那个游戏"几乎零鉴别力,这个问题比给门加一个 selfAssessed 字段要紧得多。二是出题与被考同源:classify 自产 archetype、design 自产 gatespec,而 W-G1 的核心未知恰恰是便宜模型连 ball.x、driver:none 这种最基本的东西都会反复写错——让同一只待验模型既出题又答题,验收闭环就有一格没真正断开。
+
+**第三类是 factory 与 gamedef 双轨未 cutover。** 我们有两条生成产线并存:老的 factory 路(填参装配,默认产线,但实测成功率约 60%,低于 80% 门),和新的 gamedef 结构化源路(真结构化生成,双证已经成立但尚未切为默认)。双轨并存本身是健康的演进态——新路没稳前不该贸然切换——但如果不立一道硬退役门,演进态就会沉淀成永久债。与之伴生的还有一个成本侧盲区:generate 节点内部有一条回退链会静默切模型,但它不计 failCount、不进 escalationEvents,与图层的 escalate 升档是两套互不相通的机制;这导致"一次失败到底走了几层模型"算不清,而 cutover 的成本归因恰恰依赖这个数,盲区不补,60% 这个门的成本侧就不可信。
+
+还要顺带说清一个**已经被实证反掉的误判**,免得为已有资产重复建设:源项目持久层不是悬空的。`game_source_project` 的建表迁移真实存在(V18/V20 双副本),`landSourceQuietly` 与 `markSourceBuiltQuietly` 在回调实现里被真正调用(事务外层、source_hash 幂等)。所以它已经是一等公民,真实缺口只是血缘丰富度和 gamedef 路的端到端验证,这是 P2,不是要去补一条根本不存在的落库链。
+
+## 三、对标 OpenGame:我们缺哪几层
+
+把 OpenGame 看透之后,落到我们的现状上,真正的差距集中在三层。它们与第二节的内部债不重叠——内部债是"已有的东西没做对",这三层是"值钱的东西我们还没有"。要看每一层在 OpenGame 源码里的具体长相,去翻 `2026-06-20-OpenGame对照分析与复刻缺口.md`;这里只讲清楚缺的是什么、为什么缺它要紧。
+
+**第一层缺的是生成约束的厚度。** OpenGame 端到端能跑通的根本前提,是它有一套预建模板,外加每个 archetype 一份 `template_api.md` 的 hook 清单当"填空靶子"。它的生成质量不来自强模型自由发挥,而来自把开放问题收敛成填空题:一份 GDD(游戏设计文档)把"做个游戏"这件开放的事,结构化成一张每一节都硬绑下游工具入参或代码文件的待办清单——资产表喂给资产工具、ASCII 布局喂给贴图工具、数值合并进配置、行为去改关卡管理器。约束便宜模型不跑飞的,是三条铁律:数值只能进配置、只用模板已有行为、绝不许编造清单里没有的 hook。而 Hook Integrity 这条铁律之所以**能**约束便宜模型,正是因为有一份明确的 API 清单让它无从编造。我们这一侧,classify 和 design 节点是存在的,但 archetype 体系、物理优先的分类 prompt、GDD 的契约化程度、以及最关键的那份"LittleJS 增强发行版加插件库公开 API 清单"当我们的 template_api——都还没补齐。没有这份清单,便宜模型一定会编造 API。这一层 OpenGame 抄不来、必须我们自建,而它恰好和创始人定的"游戏等于长生命周期结构化源项目"基座、以及"玩法模板等于品类框架"的定位,是同一个东西。这是**最高价值**的缺口。
+
+**第二层缺的是经验复利层,我们几乎从零。** OpenGame 真正的护城河是两套同构的离线经验自进化机制,都遵循同一个闭环:完成任务、抽取经验、去具体化、沉淀回本地 JSON 库、下次先查库命中复用、重复达阈值再升格成可执行规则——纯本地、零向量、零 embedding,本质是基于案例的推理而非 RAG。其中 *Debug Skill* 是一本活协议:数据结构是(签名、原因、修复)三元组,签名匹配是纯算法零 LLM,只在诊断新错和归纳新规则两处兜底调 LLM;最实的一环是同一个反应式修复在重复出现三次后,会自动升格成执行前的预校验规则,经验从"救火"升级成"免疫",而且只有跑通验证的修复才进库。*Template Skill* 则从一个 game-agnostic 元模板出发,每完成一个项目跑一条五段流水线,把具体代码泛化成带 KEEP/copy/hook 分层的模板,以"物理三元组加 archetype 名"为匹配键复用整个家族。这一层我们规划过 Debug Skill 但 MVP 做了简化,Template Skill 那种"从完成的游戏项目反向生长品类骨架库"的能力则完全没有。它对便宜模型尤其划算——每一次签名命中都省一次 LLM 调用,把高频错变成确定性查表。
+
+**第三层缺的是资产线,以及偏弱的语义验收。** 资产这一块,OpenGame 走的是一整套"生成、抠图、视频抽帧、多级回退、清单装配"的重流水线,依赖视频模型加 ffmpeg 加抠图后端——便宜的文生图模型替不了动画质量,这是真壁垒。我们不照抄这套依赖,而是让 asset 节点接王蓝莓投资人版已经拍板的 mmx-cli,大幅降级的部分(静态帧加程序音)照它的多级回退思路兜底即可。语义验收这一块需要说准:OpenGame 论文最响的"三轴 VLM 验收"在开源代码里其实并不存在——README 描述得很全(headless 浏览器跑生成的游戏,VLM 沿 Build Health、Visual Usability、Intent Alignment 三轴打分),但全仓 grep 不到任何渲染真实像素、真实浏览器或 VLM judging 的代码,只留一句"will be released soon",它放出来的真实验收只到 build 加 test。所以**单比已经开源的东西,我们的真机九门已经更硬**。但这里要分清两层、别就此自满:九门判的是机制(Build Health 那一轴),我们确定性领先没有疑问;可 VLM 另外两轴——好不好看、是不是用户要的那个游戏——九门根本判不了,这两件事在我们这边对应的不是九门,而是 player 软门(M3 视觉模型看截图),而 player 软门是软的、跑便宜模型、不成体系,这恰恰是我们的弱项。所以正确的动作不是"把九门结果套个三轴外壳就交差",而是把 player 软门那条做厚——OpenGame 论文那套三轴设计,正是这一层值得我们抄的蓝本,哪怕它代码并没放出来。
+
+## 四、统一演进路线
+
+把内部债和外部缺口合起来,演进沿**两条并行的线**推进。线 A 向内加固现有架构,把硬编码的策略抽成数据契约、把跨进程对齐点锁成单一事实源、把验收信号补上独立的 ground-truth;线 B 向外补齐 OpenGame 证明值钱的能力层。两条线有两处天然交汇,必须合并、不能各列一遍,下面先讲两条线各自要做什么,再讲交汇点怎么合,最后给一张统一的迁移序列。
+
+贯穿两条线的总原则有三条。其一,**不重写任何主干**——接法 A 裸图是接法 B(ReAct)的躯干、九门是最大工程价值、源项目持久化已是一等公民,这些全留,改的只是策略层外置与 oracle 加固,而且全部 additive 加 fallback 回落。其二,**所有新增的质量门默认只观测不收紧**——当前是刻意宽门放量在攒数据(开闸两门焊死放行、三门只观测),任何新门若一上来就生效,会立刻掐断这条灰度闭环,所以新门一律默认 flag-off 只落 trace,达标率稳定后再一行 flip,对齐后端 Tier0 的范式。其三,**凡涉及跨 Python 与 SAA 双轨的策略外置,数据契约必须是语言无关的 JSON/YAML、两轨都读它、CI 卡 parity**——否则"策略化"就沦为"跨语言漂移",把一处硬编码换成多处不同步。
+
+### 线 A:加固现有架构
+
+线 A 有五件事。
+
+**trace 抽取与文件拆分**,是为后续一切改造铺路的纯重构。把内联在近九百行 dispatcher 里的 trace 抽取逻辑(约 280 行)抽成一个独立的纯函数 `SaaTraceExtractor`,补 snake 到 camel 的单测;同时把过载的 `SaaStudioNodes` 单文件(一千六百多行,节点工厂、路由谓词、RFC6901 工具、giveup dump IO 混居)按职责拆包。这两步都是包内方法移动、单测护航、零行为变更,把 dispatcher 从近九百行瘦到约六百行。要诚实标注这步的收益边界:它的价值仅仅是"纯函数可脱图单测",并不是"闭合双 Java 实现漂移"(HTTP 路的 trace 抽取在 Python worker 一侧,Java 侧本就不抽),把范围讲准才不会拿错误的理由去论证它。
+
+**prompt 同源,解 split-brain**,是线 A 的关键路径起点。把 gamedef 的生成约定(系统提示正文、运行时面的写法约定、命名对齐)从 Java 字面量提为 `contracts/prompts` 下的版本化资产,让 Java 的 `GAMEDEF_SYSTEM` 与 worker 的 prompt.py 都从这一份资产读、CI 卡到字节一致。Prompt Registry(`contracts/prompts/registry.yaml`)作为第 8 类契约已经存在,这一步不是从零起,而是把已有的 registry 真正接线进生成链路。它一举两得:既根除了那处 P0 级的 split-brain,又坐实了三段式缓存的前缀——前缀字节一致才能命中,spike 已证命中率有 76% 到 93%。这里有一条硬纪律:**split-brain 未解之前,不得拿 worker 线的数据去做 cutover 决策**。
+
+**模型外置**,把 11 个模型名加 per-role 采样面外置为 `models.yaml`,让加载逻辑从配置读、常量作 fallback。硬约束是必须指定单一权威——要么 Java 与 Python 读同一份 models.yaml,要么 CI 校验两侧 parity——否则换来的是跨语言的模型路由漂移。
+
+**latch 终态语义**,是线 A 里唯一的 P0、也是最要紧的一件,但它同时是与线 B 的一个交汇点,留到下面"交汇点"统一讲。
+
+**cutover**,是线 A 的收口里程碑:立一道硬退役门,gamedef 路成功率达到 80% 门后,切为默认产线、二分收敛退役 factory、fail-closed 门 flip、modify 的"从源真构建"闭合。它依赖 prompt 同源(才敢用数据做决策)、依赖质量信号可信(下面交汇点)、依赖 80% 达标率三个前置。与 cutover 同期还要补上前面说的成本侧盲区:给那条静默回退链 append 一个轻量的 `fallbackEvents` 进 trace,让成本归因可信。此外把 `failureReason` 全归桶 llm_error 的诊断盲区一并修了——扩出 failureDetail 子码(修复次数耗尽、升档耗尽、缺全局名、模型超时等),契约先行,注意 DB 列宽 32 字符的约束,additive 到消费侧不读即退现行。修复后数据回路才能按真因聚合,这是数据驱动闭环的承重件。
+
+### 线 B:补齐能力层
+
+线 B 有四件事,全部源自 OpenGame,且全部落在 SAA 图内,不引入外部主循环。
+
+**GDD 契约加 template_api,是最高价值项。** 把物理优先分类的 system prompt(含易错例)和五 archetype 体系做成 classify 节点加 JSON 容错解析;把 GDD 的"六节每节硬映射下游"契约、三铁律、按 archetype 动态拼三层规则做成 design 节点,内置规则可整段移植。但有一个范式级前提必须先立:**先得有那份"LittleJS 增强发行版加插件库公开 API 清单"当我们的 template_api**,否则 Hook Integrity 无从约束,便宜模型必然编造 API。这份清单和"结构化源项目"基座、"玩法模板等于品类框架"是同一个东西,是这一层乃至整条路线约束力的靶子。
+
+**Debug Skill 落地为 diagnose/repair 节点加 checkpoint。** 把验证驱动的 REPEAT 循环、(签名、原因、修复)三元组 JSON 账本、分组阈值升格这套机制,对应到 SAA 裸图里一个 diagnose 节点加 repair 节点加 checkpoint 持久化。签名匹配是纯算法零 LLM,便宜模型只在诊断新错和归纳新规则两处兜底调用,每次命中省一次 LLM 调用。种子协议里的错误码要从 Phaser 换成我们自己的 LittleJS 运行时和九门错误码,但结构原样可用。
+
+**Template Skill 按 gameDefinition 重写,且入库前过九门质量门。** 抄它的范式(结构化源项目模板的 KEEP/copy/hook 分层、经验计数、离线蒸馏),但实现要整体重写两处:它的物理信号正则和 hook 命名约定死绑了 Phaser 和它自家模板的类名,我们要换成"对 gameDefinition 结构做 archetype 分类、对源项目模块做抽取"。更关键的是,**原版入库前没有任何回验门,带病的骨架会直接沉进库;我们必须给它加一道"入库前过九门或可构建校验"的质量门**——这恰恰是我们相对它的强项,把我们最硬的东西用在它最弱的地方。另外要预警原版一个硬缺口:这套进化只有单调累积、计数强化、阈值升格,没有遗忘、淘汰、冲突消解,也没有向量检索,家族一多线性扫加物理三元组离散匹配会退化;等品类规模上来,我们可能需要补一层真正的检索。
+
+**资产线接 mmx。** asset 节点接 mmx-cli 替代 OpenGame 那套依赖视频模型加 ffmpeg 的重流水线,大幅降级的部分照它的多级回退思路兜底。这是中优先级、范式上"换替代方案"即可的一项。顺带可把它的确定性 bitmask 贴图(纯算法、与模型无关,用确定性算法绕开模型的空间推理)直接搬进来,只对 platformer/top_down 用瓦片地图、逻辑类品类走代码定义网格——这是 OpenGame 一个聪明的工程判断,几乎零成本可得。
+
+### 两处交汇点:必须合并,不能各列一遍
+
+**交汇点一:品类的独立交叉校验。** 线 A 第四阶段要做的"category 独立交叉校验",和线 B 要做的"物理优先分类",指向的是同一件事,合成一项。这一项的内核是:保留 classify/design 自产骨架的生成路径,但**验收 oracle 绝不能押在同一只待验模型的分类输出上**。具体做法是引入一个独立于 design-agent 的交叉校验——从 brief 关键词、从 player-panel 的视觉反推品类,与 design 自报的品类比对,不一致即降权乃至拒发。这比"把出题点从写 gatespec 前移到选 category"更治本,否则只是把自评闭环挪了一格而非真正断开。线 B 带来的物理优先分类(看重力方向、视角、移动方式而非品类名,含 Terraria 是 platformer 不是 top_down 这类易错例),正好为这个独立校验提供了高质量的判定依据。一件事,一处实现。
+
+**交汇点二:把 player 软门做厚,oracle 去自评。** 线 A 要的"九门去自评闭环",和线 B 要的"补强 VLM 语义层",是同一件事,合成一项。九门那一层(机制/Build Health)我们已经领先,不动它;要补厚的是判"好不好看、是不是要的那个游戏"的那一层,它对应的是 player 软门而非九门。动作是让这条软门更系统、可复现:做成独立于生成方的交叉校验,甚至一个离线 bench,蓝本就是 OpenGame 论文那套三轴(哪怕它没开源代码)。配套要把"模型靠 clickable 等运行时内置基元蹭过门,还是真写了交互逻辑"的占比、player/nreview 自评与九门 verdict 的交叉一致性,都进 trace(additive 扩展位已有),长期背离即告警——用数据积累"门的有效性"证据,而不是去堆一支评审舰队。
+
+### 统一迁移序列(对齐现有 plan,不另起编号)
+
+已有三份 plan 承接本序列:`2026-06-17-001`(后端 Tier0 生成主线)、`2026-06-18-001`(生命周期加 Tier-1 广度)、`2026-06-18-002`(Tier-1 广度后端)。下面的阶段**挂入这些 plan 的验收,不新建 plan 编号**;凡标"**[新增·需进 plan]**"的,是 OpenGame 对照带来的、现有 plan 里还没有的新工作项,需要补进对应 plan。关键路径标 ★。
+
+- **阶段 0(零风险·立桩)**:收敛 job 核心字段名、state 键集、trace camelCase 键集的常量来源。这里要切分清楚——Java 内部键名可以收敛到常量类,而 Java 与 Python 之间的 trace 键只能靠契约和测试夹具对齐,不能并入 Java 常量类(这是一处假锚)。纯重命名,无行为变化。
+- **阶段 1(线 A·重构)**:抽 `SaaTraceExtractor`、拆 `SaaStudioNodes` 分包、补单测,dispatcher 从近九百行瘦到约六百行,零行为变更。
+- **阶段 2 ★(线 A·解 P0)**:gamedef prompt 约定提为 `contracts/prompts` 版本化资产,Java 与 worker 两轨读它、CI 卡字节。关键路径:split-brain 未解前不得拿 worker 线数据做 cutover 决策。
+- **阶段 3(线 A·契约先行)**:models 外置加 CI parity;failureReason 扩 failureDetail 子码(注意列宽 32);GenerationJob record 化为 dispatcher 边界 DTO(图内 Map 不动,http 与 saa 同步切,灰度开关保非破坏)。全 additive 加 fallback。
+- **阶段 4 ★(质量加固·全 flag-off 落 trace)**:① latch 终态语义区分胜利与弃守/超时(P0);② 交汇点一——品类独立交叉校验(物理优先分类同址实现);③ 交汇点二——player 软门做厚加 Goodhart 可观测化;④ fallbackEvents 入 trace。全部默认 off、只观测、不改放行行为。
+- **阶段 B1 ★[新增·需进 plan]**:GDD 契约加 template_api(LittleJS 插件库公开 API 清单),classify 与 design 节点契约化。这是约束力的靶子和最高价值杠杆,建议优先排进 `2026-06-18-001`(它和"结构化源项目"基座同源)。其中"物理优先分类"的落地与阶段 4 的交汇点一是同一处实现,不重复建。
+- **阶段 B2 [新增·需进 plan]**:Debug Skill 落 diagnose/repair 节点加 checkpoint;Template Skill 按 gameDefinition 重写并强制入库前过九门质量门;asset 节点接 mmx 并搬入确定性 bitmask 贴图。这一组是经验复利层与资产线,可在 B1 之后并行推进。
+- **阶段 5 ★(里程碑门·cutover)**:gamedef 成功率达 80% 门后,切默认产线、二分退役 factory、fail-closed 门 flip、modify"从源真构建"闭合。依赖阶段 2(prompt 同源)、阶段 4(质量信号可信)与 80% 达标率三个前置。
+
+关键路径是一条线:阶段 2(prompt 同源解 split-brain)→ 阶段 4(质量信号可信)→ 阶段 5(cutover)。阶段 0/1/3 可与之并行(独立资源)。线 B 的 B1/B2 与线 A 在资源上基本独立,可并行推进,但 B1 的产物(GDD 契约、template_api 清单)会让阶段 4 的品类校验和阶段 5 的质量更扎实,排程上 B1 越早越好。按价值排,最该立刻动手的三件依次是:**先补 template_api 与 GDD 契约(B1,一切约束的靶子)、再把 Debug Skill 落成 diagnose/repair 加 checkpoint(B2 前半)、然后把 Template Skill 按 gameDefinition 重写并加九门质量门(B2 后半)**。
+
+## 五、我们刻意不做的
+
+有三件 OpenGame 看起来在做、但我们刻意不做的事,要讲清楚为什么,免得被论文的卖点带偏。
+
+**不专训 GameCoder-27B。** OpenGame 论文把一个为游戏定制的 27B 代码模型当作支柱,但它的权重、训练码、数据都不在仓里,实测代码默认接的反而是 openrouter 上的通用强模型,设一个环境变量就能换。这恰恰证明它的框架被刻意设计成 model-agnostic——专用模型不是跑通的必要条件。我们的路线明确是便宜通用模型加 harness 兜底,质量缺口靠模板约束加 Debug Skill 补,而不是靠把模型这一层做重。OpenGame 自己的设计反过来印证了这条路走得通。
+
+**不把 VLM 当硬门。** player 软门要做厚,但它的判定是 LLM 视觉判断,本质是概率性的,不能用来定一次生成"算不算完成"。把一个软判定提成硬门,会直接撞上我们的铁律——"完成"必须由确定性的门来定。所以 VLM 这条线只做软门、做离线 bench、做交叉校验与告警,产出的是"门的有效性"证据和质量趋势,而绝不进放行的确定性判定。九门是机制地板,VLM 是质量观测,两者职责不混。
+
+**不上重型 PTY 沙箱。** OpenGame 的 shell 执行是重型的——PTY 优先、ANSI 解析、独占进程组、SIGTERM 再 SIGKILL、docker/podman/seatbelt 沙箱,深度绑定 Node 生态。这是它"模型自由写代码再跑构建看报错"那套自主循环的物理基座。我们走图编排,build 节点的职责窄得多,MVP 阶段不需要这么重的沙箱;将来若真需要,Java 侧用 ProcessBuilder 或 pty4j 自建等价物即可,但绝不移植那套 JS 适配。同理,MCP 走 SAA v1.1.2.2 自带的支持,不试图搬 OpenGame 那套从上游继承的 JS MCP 适配层——何况 OpenGame 的游戏生成能力本就不来自 MCP,而来自内置确定性工具加工程模板,以为复刻它要复刻一堆 MCP server 是彻底读反了。
+
+## 六、风险与回滚
+
+| 风险 | 缓解 | 回滚 |
+|---|---|---|
+| 模型/prompt/category 外置成新双源漂移 | 单一权威加 CI parity/字节卡门 | 配置缺失回落常量;worker 不引用即回 iife-only |
+| 新门收紧放行掐断灰度闭环 | 全部默认 flag-off 只落 trace,达标后 flip | trace 字段 additive,缺键省略字节兼容 |
+| latch 修复误伤现有过门样本 | flag-off 观测期对比新旧 latch 判定差异 | 不 flip 即维持现行 latch |
+| category 独立校验误拒正常样本 | 先降权观测、不直接拒发,统计误拒率 | 关 flag 退回 design 自报 |
+| Template Skill Abstractor 把坏骨架沉进库 | 入库前强制过九门/可构建质量门 | 关进化、保留现有库快照 |
+| failureReason 契约改动破审核台 | 契约先行加 DB 列宽校验加 additive | 消费侧不读子码即退现行 |
+| gamedef cutover 后 factory 退役回归 | 80% 门加端到端验证为前置硬门 | 保留 sourceMode 开关一个 release,可切回 factory |
+| 串行门吞吐天花板为 1(已知债) | 本轮不改(过早优化),显式记 follow-up | 不适用 |
+
+**验证状态**:本路线为架构裁定文档,未改代码。承重锚点已抽查属实——V18/V20 建表 SQL 加 land/markBuilt 真调用链(反掉持久层悬空误判)、failureReason 归桶 llm_error、`contracts/prompts/registry.yaml` 已存在(prompt 外置非 greenfield)、SAA 四文件路径、OpenGame 结论锚在其真源码(`github.com/leigest519/OpenGame`)。未验证待落地时确认的是:worker 的 prompt.py 与 models.yaml 在 wg1 外部 worker 树(本仓不可见),其"纯 iife、零 gamedef 路"的论断采信对照分析的实证,阶段 2 落地前需在构建机侧复核。
\ No newline at end of file