games-development-ai/docs/plans/2026-06-27-001-feat-cheap-worker-M2-node退役授权-plan.md

title, type, date, origin, slice, predecessor, reviewed, scope

title	type	date	origin	slice	predecessor	reviewed	scope
feat: 便宜档 M2 上线就绪 — auto-vs-golden delta 门 + Node 退役授权三条齐 + 灰度基础设施设计	feat	2026-06-27	docs/plans/2026-06-25-生成引擎统一执行计划-AgentScope三档-plan.md	切片一 · M2(上线就绪 · Node 退役条件齐)	docs/plans/2026-06-26-003-feat-cheap-worker-M1-达标门绿-plan.md	2026-06-27 双评审(plan 双评审门 §6.8)—— Opus 对抗评审权威(1 MAJOR + 6 MINOR 全在档内修);Codex 实跑评审但读完 plan① 后停在半途未产汇总(回落 Opus 单评 §6.8),其停前的方向性发现(gate 语义 vs 动机文案不一致)已纳入并修。创始人 2026-06-27 定门定性=建全门 + 诚实降权	创始人 2026-06-27 定 — M2 细化 plan 聚焦可本地执行的 auto-vs-golden 门;灰度切换基础设施只出设计、真接线随 M3

便宜档 M2 上线就绪(切片一第二里程碑)

Summary

M1 坐实了便宜档生成质量的本机地板:三个 tap-targets 品类按九门质量口径稳定 ≥80%,Python/AgentScope 框架与 Node 旧路对照等价。但「质量够格」与「能把生产默认路由切到 Python、让 Node 退役」之间还差一道核对。对照等价(002)和达标门(M1)采的证据都是金标 play-spec 驱动的——金标是人手写、干净、与具体游戏解耦的标准驱动器;而生产里每款游戏的驱动器是 ensure_play_spec 当场自动产的。两个驱动器不是同一个,自动 spec 通常比金标薄。所以「金标 spec 下两路等价、达标」不等于「自动 spec 下生产真能达标」——后者才是放 Python 上生产的真实条件。

M2 把这道核对做成一道可复跑的机器门:对同一款生成产物,分别用金标 spec 和生产自动 spec 各驱动一次九门,逐门比过门率,关键门(进对局 / 进展 / 输入)自动不得低于金标基线、其余门 delta 不得超容差。方向钉清(承 plan① M2「不得低于金标基线」口径):门防的是自动 spec 比金标驱动得差——薄 spec 可能驱不动游戏、让金标能玩起来的局在自动 spec 下进不去对局或没进展,过门率掉下来;退役后生产全靠自动 spec,这种「驱动更差」会把本可玩的游戏误报成不可玩、把达标率虚低。auto关键门 ≥ golden 正是查这一面。

这道门在 M2 的覆盖面(tap-targets 三品类)上鉴别力有限,得说在明处:M1 已把自动 spec 加厚到与金标字段同质(同 driver 族、同 expectedEngineCallPrefixes、同 assertAfterPlay / expectLatch,仅驱动步数微差),所以同款产物上自动与金标逐门 delta 几乎必为 0。这不是门失效——delta=0 正是「自动 spec 没驱动得更差」的合格证据;但它意味着在这三品类上,门主要确认的是「逐款自动 spec 据 smoke state 推断驱动器没失效」,而非「自动普遍不弱于金标」(后者的真鉴别场景在自动 spec 与金标断言不同质的 key-cycle 族,那族 M1 已延后)。因此 Node 退役授权的实质支撑是 M1 绝对达标 + 002 两路等价两条强证据,auto-vs-golden 门是其上的「不退化确认」,补足「生产用的自动 spec 没把达标驱虚」这一层,不是决定性独立闸。它与 M1 达标、002 对照等价三条齐,才构成「便宜档具备把默认路由切到 Python 的全部条件」。真正把路由 flag 切过去、扣退语义接进 D12,是 M3 的后端协同,不在 M2。

创始人 2026-06-27 定:M2 细化 plan 聚焦这道本机可执行的 auto-vs-golden 门;灰度切换基础设施(路由 flag / A2A 任务状态 / 幂等 key / 在途任务 / D12 扣退)在 M2 只出设计、不接线,真落地随 M3。

Problem Frame

M1 的 U2 verification 已经点出这道门的位置:tap-targets 族自动 spec 加厚到金标同质后,「auto-vs-golden 过门率 delta=0」是面向生产的 Node 退役授权的证据起点,M1 只证了单款同质、不产退役许可。M2 要把这个「证据起点」从一次性的人工核对,升成一道按品类、带 delta 阈值、带关键门地板、可复跑、可落盘的批量门——单款 delta=0 是个观察,一道门要回答的是「这三品类、N 款样本上,自动 spec 驱动的过门率系统性地不低于金标,低多少算可接受」。

为什么 M1 达标门量到 ≥80% 还要这道门:M1 达标门本身就是自动 spec 驱动的(它量的是「生产自动 spec 能不能稳定过九门」)。它告诉你「自动 spec 下过门率 ≥80%」,但没和金标基线对过——没回答「同样这批游戏,换金标 spec 驱动会不会过得更多」。若自动 spec 因为薄而驱动得差(驱不动、进不去对局),它会把一些金标能驱起来的好游戏判不可玩,达标率被虚低却看不出来。auto-vs-golden 门补的正是这一层:把自动 spec 和金标 spec 摆在同一款游戏上逐门比,自动低于金标(delta < 0)即暴露「自动驱动更差」。方向是单边的——查的是自动有没有比金标驱得差(plan① M2「关键门不得低于金标基线」),不是查自动有没有比金标松。后者(自动断言更宽、放过坏局)对 tap-targets 不成立:M1 已把自动 spec 的断言加厚到与金标逐字段一致,两者断言同质、自动不可能比金标更宽。两道门角色不同——达标门量绝对水平(够不够 80%),auto-vs-golden 门量相对不退化(自动驱动不弱于金标),后者是前者的诚实性背书。

证据起点钉在代码行:compare_node.py 已有的 run_pair_sync 是 Python-vs-Node 两路对照(两路都注金标、驱动器 held constant);M2 的 auto-vs-golden 是同一路、同一款产物、两个驱动器——换的是对照轴(驱动器金标 vs 自动),不是路(Python vs Node)。inject_golden / _write_spec_atomic(强制覆写金标到 staged)、ensure_play_spec(自动 spec)、cheap_run.play(九门 play)、gates_from_verdict(逐门取 verdict)、端口池 + 线程有界并发,全部现成可复用。M2 新增的只有「同游戏双驱动 play 编排」和「逐门 delta 判据」两块,加一个把三条退役条件聚合成授权判定的小判定。

一条边界先划清:auto-vs-golden 门覆盖 M1 已加厚到金标同质的 tap-targets occupied 三品类(点击得分 / 打地鼠 / 经营点客)。key-cycle 族(2048 / 躲避)的自动 spec 因缺「两路绑同一套输入键」契约在 M1 就延后了,M2 的 auto-vs-golden 门相应只判这三品类——这与 M1 达标门、002 对照的覆盖面一致,不在 M2 扩面。

Requirements

• R1 同游戏双驱动 play 编排:对一款生成产物(Python 生产路),在同一份 staged src/ 上分别用生产自动 spec(ensure_play_spec 据 smoke state 自动产)与金标 spec(inject_golden 覆写)各驱动一次九门,取两组逐门 verdict。两次 play 跑在同一款游戏上,隔离生成方差、只暴露驱动器差异。
• R2 auto-vs-golden 逐门 delta 判据(按品类 · 关键门地板):按品类聚合 N 款的逐门过门率,自动 spec 对关键门(E_live 进对局 / H_progress 有进展 / G_input 输入生效)不得低于金标基线(delta ≥ 0,容差 0);其余门容差至多允许一款样本的 flake(delta ≥ -1/N)。任一品类任一关键门自动低于金标即该品类 below;三品类全在阈值内才整体 PASS。判定纯走确定性九门 verdict、零 LLM。
• R3 Node 退役授权三条齐判定:聚合三个硬前置——① M1 ≥80% 达标(读 M1 收口报告 overallMeets)② 002 对照等价(读 002 对照报告逐品类 equivalent)③ M2 auto-vs-golden delta 门(R2)。三条全绿才出「Node 可退役授权」结论;任一缺或不绿即「授权未达成」并列出欠哪条。这是判定、不是动作——真把路由切过去在 M3。
• R4 真跑纪律:auto-vs-golden 门真跑走前台进程内有界并发(端口池 + 线程,复用 002 run_multi 范式),禁后台子代理 / tail -f monitor / 自我唤醒重试;并发不超过 15、本机 N=4–6 起步;gameId 用品类前缀隔离;报告按批次分文件不覆盖。小批(每品类 n=1–2)先联调判据与编排,full 批(每品类 ~7)作收口实测。
• R5 灰度切换基础设施设计(只设计 · 不接线):把 plan① §4 迁移安全契约的九项(路由 flag / 对照验证 / A2A 任务状态 / 幂等 key / 超时重试 / D12 配额扣退 / 在途任务 / 切换门槛 / 回滚触发)收敛成一份 M2 设计章节,讲清每项的语义、本地可验的部分与归 M3 接线的部分,不写后端代码。这一项产出是设计文档段落,不是可执行单元。
• R6 口径与边界:M2 是本机/实验室口径,auto-vs-golden 门覆盖 tap-targets occupied 三品类(与 M1、002 同覆盖面);key-cycle 族待输入键契约、不在 M2。生产真实 prompt 分布下的退役复验在 M3。auto-vs-golden 门是 delta 门(相对退化),与 M1 达标门(绝对水平)、002 对照门(两路等价)、tier2 n=5 收敛环各是独立口径,不混用。

Key Technical Decisions

• KTD1 双驱动跑在同一款产物上、不是跨款比。最干净的 auto-vs-golden 比较是:生成一次,在同一份 staged src/ 上 play 两次,只换驱动器。这样过门率差里没有生成方差(两次 play 面对的是同一款游戏),delta 纯反映「自动 spec 比金标驱得好还是差」。若改成「一批自动 spec 驱动的款 vs 另一批金标驱动的款」,过门率差就掺进了两批游戏本身的生成质量差,污染 delta。编排顺序:gen-only → smoke 取 state → 自动 spec(ensure_play_spec,此时 staged 无 spec、它正常写)→ play 取 auto_gates → inject_golden 强制覆写 → play 取 golden_gates。

• KTD2 关键门容差 0、其余门容差 1/N。plan① M2 要求「菜单 / H_progress / G_input 等关键门不得低于金标基线」。关键门 = {E_live 进对局、H_progress 有进展、G_input 输入生效},这三门恰好是九门里唯一对驱动器敏感的三门(未驱动时 E_live/H_progress 降 advisory、G_input 在无输入时 skip 直过,见 play.cdp.cjs),也正是「这游戏到底能不能玩」的判据。自动 spec 在这三门上低于金标(delta < 0)意味着自动驱动得比金标差——把金标能驱起来的可玩局判成进不去 / 没进展,退役后会虚低达标率,故容差必须 0(要求 delta ≥ 0)。除这三门外的六门(A_boot / B_uncaught / C_frame / D_render / F_wiring / I_control 静态 / 渲染 / 装载门)对驱动器不敏感,允许单款 flake 的容差(delta ≥ -1/N),避免一次无关抖动把整品类判 below。阈值数值写死在判据常量、注释标依据,不留 TODO(plan① 明示「阈值未填不得授权 Node 退役」)。

• KTD3 三条退役条件读既有报告、不重跑。M1 达标(bake-off-M1-final.json 的 overallMeets)与 002 对照等价(对照报告 summary.equivalentGenres 列三品类全在,即逐品类 perGenre[i].judge.status == "equivalent"——注意 status 嵌在 perGenre[i].judge 下、perGenre[i] 顶层无 status)都已落盘,Node 退役门读这两份报告 + M2 自己产的 auto-vs-golden 报告,聚合成授权判定。不重跑 M1/002——它们的证据已固化,重跑只是浪费 CPU 且引入新方差。002 对照报告 results/ 下有多份 compare-multi-*.json(口径可能不同),U3 不取「最新」(会被未来 stray 批次顶替),而是显式 pin 收口批次——首动作把 002 收口批 compare-multi-2.json 复制固化为 compare-multi-002-final.json(与 M1 的 bake-off-M1-final.json 同等待遇),U3 读固化名。报告路径缺失或字段不符即报「前置证据缺失」,不静默当通过。

• KTD4 auto-vs-golden 门判定零 LLM。与达标门、对照门同口径:逐门 delta 全由确定性九门 verdict 算,不引入任何模型当裁判。这既防 Goodhart(模型评分会优化成「看起来不退化」),也是门可复现的前提。

• KTD5 灰度基础设施 M2 只设计。创始人 2026-06-27 定 + plan① 把灰度切换基础设施的真接线划给 M3(路由 flag / A2A / D12 扣退是后端件)。M2 产设计:每项语义钉死、标本地可验 vs 归 M3 接线,作 M3 接线的施工图。不在 cheap-worker 或 game-cloud 写任何路由 / 扣退代码——M2 一行生产路由件都不碰。

• KTD6 零生产路由改动(承 M1 KTD6)。M2 全部落在 cheap-worker 本机验收侧:auto-vs-golden 门、退役授权判定、灰度设计文档。路由 flag、A2A 任务状态、幂等 key、D12 扣退、在途任务、灰度切换这些生产件 M2 一概不接线,归 M3。M2 不改任何用户当前在跑的链路。

High-Level Technical Design

auto-vs-golden 门是 Node 退役授权三条齐的最后一条;同游戏双驱动喂给逐门 delta 判据,delta 门绿 + M1 达标 + 002 对照三条聚合成退役授权:

flowchart TB
  subgraph U2["U2 同游戏双驱动 play(真跑)"]
    direction TB
    G["gen-only 生成一次<br/>→ 自动 spec play(auto_gates)<br/>→ 金标 inject play(golden_gates)<br/>同款产物、只换驱动器"]
  end
  subgraph U1["U1 逐门 delta 判据(纯逻辑)"]
    J["按品类聚合逐门过门率<br/>关键门容差 0 / 其余门容差 1/N<br/>零 LLM"]
  end
  subgraph U3["U3 Node 退役授权判定(纯逻辑)"]
    R["读 M1 达标报告 + 002 对照报告<br/>+ U1/U2 auto-vs-golden 报告<br/>三条齐 → 退役授权"]
  end
  subgraph D5["R5 灰度基础设施设计(只设计)"]
    DD["路由 flag / A2A / 幂等 / 在途 / D12 扣退<br/>语义钉死 + 本地可验 vs 归 M3 接线"]
  end
  subgraph OUT["M2 交付"]
    OUT2["便宜档具备切默认路由到 Python 的全部条件<br/>(本机口径;真接线在 M3)"]
  end

  G -->|auto_gates / golden_gates| J
  J -->|auto-vs-golden delta 门| R
  R --> OUT2
  DD -.设计施工图.-> OUT2

同游戏双驱动决定 delta 可不可信(隔离生成方差),逐门 delta 判据决定门绿不绿,退役授权判定把它和 M1/002 两条既有证据聚合。灰度设计不在数据流上,是 M3 接线的施工图。

Implementation Units

U1. auto-vs-golden 逐门 delta 判据(纯逻辑)

Goal:按品类聚合 N 款的逐门过门率,关键门容差 0 / 其余门容差 1/N,逐品类判 auto-vs-golden 是否退化,三品类全不退化才整体 PASS。判定纯函数、零 LLM。

Requirements:R2, R4, R6。

Dependencies:无(起点单元,纯逻辑可先于真跑落)。

Files:

• cheap-worker/auto_vs_golden.py(新建:judge_genre_delta 逐门 delta 判据 + aggregate_delta 按品类聚合 + 关键门常量;复用 compare_node._pass_rate 思路但比的是 auto vs golden 逐门、非整体率)
• 测试:cheap-worker/tests/test_auto_vs_golden.py(新建)

Approach:判据吃每品类 N 款的 [{autoGates, goldenGates}](每款两组逐门 {门: pass_bool},来自 U2)。对每道门 G,算该品类 auto 过门率 mean(autoGates[G]) 与 golden 过门率 mean(goldenGates[G]),delta = auto - golden。关键门集 {E_live, H_progress, G_input} 容差 0(delta ≥ 0 才过);其余门容差 -1/N(允许单款 flake)。任一门越容差即该品类 regressed 并记是哪门;全门在容差内即该品类 aligned。aggregate_delta 三品类全 aligned → 整体 meets=True;任一 regressed 或缺样本 → meets=False 并列原因。delta 取 round(,3),判据同输入恒同输出。

double-low 守卫(承 compare_node.doubleLowRed 同源风险):delta=0 有两种来源——「自动与金标都过」(合格)和「自动与金标都挂」(两路同坏、delta 仍 0)。后者在关键门上若被判 aligned 就成假等价。故对每道关键门,若该品类 auto 与 golden 过门率都低于 0.5,标 inconclusive(红)、不计 aligned,该品类整体 meets=False 并记「关键门双低」。这道守卫使 U1 单独绝不会把「两路同样驱不动」误判成不退化。约束(写死在 U1 文档与代码注释):U1 逐门 delta 判据绝不可单独作退役信号——它只回答「自动相对金标有没有退化」,回答不了「绝对上够不够格」;退役授权的绝对地板由 U3 把 M1 ≥80% 达标 AND 进来,缺了它 U1 的 delta=0 可能是「两路同烂」。

Patterns to follow:bake_off.py:judge_genre(纯逻辑 + 状态枚举 + 阈值常量注释依据)、compare_node.py:judge_genre(逐品类两层判据 + 标红枚举)、compare_node.py:_mean/_pass_rate。

Test scenarios:

• 自动每门 = 金标(delta 全 0)→ aligned、meets。
• 自动关键门 H_progress 比金标低一款 → 该品类 regressed(关键门容差 0)、整体 meets=False、原因记 H_progress。
• 自动非关键门低一款(delta = -1/N)→ 仍在容差内 → aligned。
• 自动非关键门低两款(delta < -1/N)→ regressed。
• double-low:某关键门 auto 与 golden 过门率都 < 0.5(两路同挂、delta=0)→ 该品类 inconclusive(红)、meets=False、记「关键门双低」,不被误判 aligned。
• 某品类缺样本 → 报缺样本、整体 meets=False(不被其余品类掩盖)。
• 判定零 LLM:纯函数、同输入恒同输出。

Verification:逐门 delta 判据单测全绿,关键门容差 0 / 其余容差 1/N 的边界用例逐一覆盖。

U2. 同游戏双驱动 play 编排(真跑)

Goal:对一款生成产物,在同一份 staged src/ 上先自动 spec 后金标各 play 一次,取两组逐门 verdict;批跑三品类按品类聚合喂 U1 判据,报告落盘。

Requirements:R1, R4, R6。

Dependencies:U1(逐门判据)。

Files:

• cheap-worker/auto_vs_golden.py(续:run_pair_dual_sync 同游戏双驱动整对 + run_avg/run_batch 端口池有界并发批跑 + 报告落盘;复用 compare_node.inject_golden / _port_pool / _next_report_path、cheap_run.smoke/ensure_play_spec/play、cheap_studio.run_studio、compare_node.gates_from_verdict)
• 测试:cheap-worker/tests/test_auto_vs_golden.py(续:mock run_studio/smoke/play 验编排顺序与产物形态,不真跑模型)

Approach:run_pair_dual_sync(genre, brief, gid, port, cdp) 同步整对(由批跑经 asyncio.to_thread 并发调度,每对一线程独立端口):① cheap_studio.run_studio(gid, brief, run_gates=False, port, cdp) 生成到 stage、不 play(run_gates=False 跳过内部 ensure_play_spec + play,核实 cheap_studio.py:153);② cheap_run.smoke(gid, port, cdp) 取 state;③ 断言 staged 无残留 play-spec.json(ensure_play_spec 是「已存在不覆盖」语义 cheap_run.py:253,gameId 撞号 / offset 重跑时残留旧 spec 会被静默复用、污染 auto_gates 且无报错;故 ensure 前显式断言无 spec 或先清,把隐式依赖变显式前置)→ cheap_run.ensure_play_spec(gid, state) 写自动 spec → cheap_run.play(gid, port, cdp) → auto_gates = gates_from_verdict(verdict);④ compare_node.inject_golden(gid, golden_spec_path(genre)) 强制覆写金标 → cheap_run.play(gid, port, cdp) → golden_gates(此时 auto_gates 已捕获、不被覆盖)。同一 gid、同一 staged src/ play 两次,返回 {gid, autoGates, goldenGates, realSrc}。批跑 run_batch(genre_keys, n, conc, offset) 复用 compare_node._port_pool + 信号量限并发(≤15、夹取),每品类 gameId 前缀 avg-<genre>-<k> 隔离,聚合 {genre: [{autoGates, goldenGates}]} 喂 aggregate_delta,报告经 _next_report_path 分批次落 results/auto-vs-golden-<idx>.json 不覆盖。

Patterns to follow:compare_node.py:run_pair_sync(generation-only + 注入 + play 整对、线程内 asyncio.run)、compare_node.py:run_multi(端口池 + to_thread + 信号量)、bake_off.py:run_bakeoff(批跑 + 聚合 + 报告不覆盖 + conc 夹取)。

Test scenarios:

• 编排顺序正确:gen-only → smoke → ensure_play_spec → play(auto)→ inject_golden → play(golden),两次 play 用同一 gid(mock 验调用序与参数)。
• 自动 spec play 在金标注入之前取(否则 auto_gates 被金标污染)。
• 不覆盖隐坑:staged 残留旧 play-spec.json 时,ensure_play_spec 前置断言触发(报错或先清),不静默用旧 spec 驱动 auto。
• 两次 play 跑在同一 staged 目录(realSrc 取自同一 game_dir)。
• 并发上限夹取 ≤15(复用 bake_off._clamp_conc 口径)。
• 报告分批次不覆盖(两次批跑产两份)。

Verification:小批(每品类 n=1)真跑跑通双驱动编排、auto/golden 两组 gates 都取到、报告落盘;编排单测(mock)全绿。

U3. Node 退役授权三条齐判定(纯逻辑)

Goal:聚合 M1 达标、002 对照等价、M2 auto-vs-golden 三个硬前置,三条全绿出「Node 可退役授权」,任一欠缺即列明欠哪条。

Requirements:R3, R6。

Dependencies:U1、U2(auto-vs-golden 报告);M1 收口报告与 002 对照报告(既有落盘产物)。

Files:

• cheap-worker/auto_vs_golden.py(续:retire_authorization 读三份报告聚合判定)或独立 cheap-worker/retire_gate.py(执行前定,倾向并入 auto_vs_golden.py 避免新文件)
• 测试:cheap-worker/tests/test_auto_vs_golden.py(续:mock 三份报告验三条齐 / 任一欠的判定)

Approach:retire_authorization(m1_report, compare_report, avg_report) 读三份报告路径(默认指向 results/ 固化产物):① M1 达标 = bake-off-M1-final.json 的 overallMeets is True;② 002 对照等价 = compare-multi-002-final.json(U3 首动作从收口批 compare-multi-2.json 固化而来)的 summary.equivalentGenres 含全部三品类,等价于逐品类 perGenre[i].judge.status == "equivalent"(字段嵌在 perGenre[i].judge 下、非顶层);③ auto-vs-golden = U2 报告 meets is True。三条 && → {authorized: True, conditions: {...}};任一 False 或报告缺失 / 字段不符 / 字段类型不对 → {authorized: False, missing: [...]}(显式存在性 + 类型校验,不静默当通过)。判定纯函数、零 LLM、零真跑(只读既有报告)。报告路径作参数注入,默认取 results/ 固化批次名(非「最新」,避免被未来 stray 批次顶替)。

Patterns to follow:compare_node.py:_read_verdict(读落盘 JSON 容错)、bake_off.py:aggregate(多条件聚合 + 列明欠项)。

Test scenarios:

• 三条全绿 → authorized=True,conditions 三项全 True。
• M1 overallMeets=False → authorized=False、missing 含 M1 达标。
• 002 某品类 regressed → authorized=False、missing 含对照等价。
• auto-vs-golden meets=False → authorized=False、missing 含 auto-vs-golden。
• 任一报告文件缺失 → authorized=False、missing 标「前置证据缺失」(不静默当通过)。
• 判定零 LLM、零真跑(只读 JSON)。

Verification:三条齐判定单测全绿(三条全绿 / 各缺一条 / 报告缺失逐一覆盖);真实读三份既有报告产一次退役授权判定落盘。

R5 灰度切换基础设施设计(只设计 · 非可执行单元)

产出:plan 内一份设计章节(下文「灰度切换基础设施设计(M3 接线施工图)」节),不写代码。把 plan① §4 迁移安全契约九项各自的语义、本地可验部分、归 M3 接线部分钉清,作 M3 后端协同的施工图。M2 不接线、不碰生产路由件。

灰度切换基础设施设计(M3 接线施工图)

承 plan① §4 迁移安全契约九项,逐项钉死语义与落地归属。M2 只产这份设计,真接线在 M3 与 game-cloud 后端协同。

• 路由 feature flag:Node / Python 由一个 flag 控,按比例灰度放量、任何时刻可瞬切回 Node。语义:flag 是路由决策的唯一开关,读 flag→选路→记录所选路到任务上下文。本地可验 = cheap-worker 侧已有 Python 路与 shell-out Node 路两套入口(run_studio / gen.mjs --mode saa),可本地按参数选路验证两路都能跑;归 M3 = flag 的存储、读取、按比例分流接进 game-cloud studio 模块。
• 对照验证:Python 与 Node 同输入逐项比产物与过门率,不达标不抬灰度比例。本地可验 = 002 对照门已坐实三品类 equivalent;归 M3 = 把「不达标不抬比例」接成灰度放量的自动闸。
• A2A 任务状态:两路产同一组状态(submitted / working / input-required / completed / failed / canceled),前端轮询不感知底层换实现。本地可验 = cheap-worker 的 run-summary 已有 finished / breaker 等终态信号,可映射到这组状态;归 M3 = A2A 任务状态机接进后端任务表与前端轮询。
• 幂等 key:创作请求维度稳定 key,灰度期同一 key 只一条路认领、产一份产物,防双跑双扣。本地可验 = gameId 前缀隔离已防本地产物互撞;归 M3 = 幂等 key 的生成、认领、去重接进后端任务入口。
• 超时重试:Python 已移植双层超时 / 重试退避 / JSON 容错(M1 实测 timeout / step_cap 熔断已在 cheap-worker 生效);done 门与墙钟上限语义随范式已搬过去。本地可验 = M1 已落;归 M3 = 仅复核生产配置阈值。
• D12 配额扣退:入口先扣,失败 / 取消按补偿退还;两路同一配额门,灰度不改扣退语义。本地可验 = 无(D12 在后端);归 M3 = 全部,M2 只钉语义(先扣后产、失败补退、两路同门)。
• 在途任务:切换 / 回滚瞬间在途的不强杀,原路跑完落 verdict;新进任务才按当前 flag 路由。本地可验 = 无;归 M3 = 全部,M2 只钉语义。
• 切换门槛:Python ≥80% 达标 + 对照等价 + auto-vs-golden 同等,才切默认路由。本地可验 = 这正是 U3 退役授权判定;归 M3 = 把 U3 的授权判定接成切换门禁。
• 回滚触发:成功率回退 / 九门通过率掉 / Python 框架级稳定性问题 → flag 切回 Node 旧路(保留它活跑到 Python 达标)。本地可验 = 无;归 M3 = 全部,M2 只钉触发条件。

一句话边界:M2 把这九项(对照验证 + 超时重试两项 M1/002 已落,余七项归 M3 接线)的语义和本地可验边界钉清,产出是 M3 的接线施工图;M2 不写任何路由 / 扣退 / 任务状态机代码。

迁移对账(承接 plan① 切片一 · M2 兑现的移交项)

plan① M2 列明项	M2 兑现	守的边界
auto-vs-golden delta 核对(Node 退役授权前置)	U1 逐门 delta 判据 + U2 同游戏双驱动	只 tap-targets 三品类、关键门容差 0
灰度切换基础设施设计	R5 设计章节(只设计)	不接线,真落地 M3
Node 退役门(三条齐)	U3 退役授权判定	判定非动作,切路由在 M3

Scope Boundaries

移交后续里程碑 / 他线(M2 不做):

• 路由 flag / A2A 任务状态机 / 幂等 key / 在途任务 / D12 配额扣退的真接线 → M3 与 game-cloud studio 模块协同。
• 把默认路由真切到 Python、Node 旧路真退役 → M3(M2 只产授权判定,不执行切换)。
• 生产真实 prompt 分布下的退役复验 → M3。
• key-cycle 族(2048 / 躲避)的 auto-vs-golden → 待输入键契约(WU-C 5.4),与 M1、002 同覆盖面边界。
• 对外开闸放行 6 门 → M3(独立 SoT 验收门.md)。

Deferred to follow-up:

• auto-vs-golden 门扩到 tap-targets 之外的品类族 → 输入键契约就位后。
• 切片二 tier2 n=5 收敛环 → 独立切片,前置 mini-desktop 可达 + DockerWorkspace harness 小验,不在切片一。

Risks & Dependencies

• R1 同游戏 play 两次的相互污染。第二次 play(金标)若没干净覆写第一次的自动 spec,或第一次 play 在 staged 留了脏态,会污染 golden_gates。缓解 = inject_golden 已是原子强制覆写(_write_spec_atomic 写 tmp 后 rename);play 只读 spec + src/、不写回 src/;两次 play 各自独立 spawn server+Chrome(端口池保证)。先小批验两组 gates 确实不同源再放量。
• R2 自动 spec 与金标本就同质(delta 恒 0)使门失去鉴别力。M1 已把 tap-targets 自动 spec 加厚到金标同质,delta 可能恒 0、门看似总过。这不是门失效——delta=0 正是「自动 spec 没比金标驱得差」的合格证据;门的价值在它能在自动 spec 退化时报警(测试用例构造关键门退化验证门会拦)。这道门在覆盖面内的鉴别力诚实定性为「不退化确认 + 逐款驱动器推断不失效」、非决定性独立闸(见 Summary 与创始人口径节),退役授权的强证据是 M1 达标 + 002 等价。若三品类 delta 恒 0,说明 U2 加厚到位、退役授权该条达成,如实判过。
• R3 关键门容差 0 过严、被单次 flake 误判退化。关键门一次无关 flake 就判整品类 regressed。缓解 = 按品类聚合多款(单款 flake 不拖垮品类率,delta 是品类级过门率之差非单款);关键门 delta ≥ 0 是对「品类级过门率」判,不是对单款判;full 批每品类 ~7 款稀释单次 flake。
• R4 三条退役条件的报告口径漂移。U3 读 M1 / 002 报告字段,若报告格式变则判定读错。缓解 = U3 读字段做存在性校验(字段缺 / 类型不符即报「前置证据缺失」不静默通过);报告路径作参数、默认取 results/ 既有产物名。
• R5 真跑成本与时延(继承 M1 R3)。同游戏双 play 比单 play 多一次 play(但省一次生成),整体时延约单驱动批跑的 1.x 倍。缓解 = 端口池有界并发(conc≤15、本机 ≤4 起步)+ 小批先联调判据再 full 批;auto-vs-golden 只 play 不重生成,比 M1 达标门轻。
• R6 过门不等于好玩(继承 plan① R6)。auto-vs-golden 门量的是「自动 spec 驱动不比金标差」,不是好玩度;后者归人工终审,M2 不声称门绿 = 游戏好玩。
• 依赖:复用 compare_node(inject_golden / 端口池 / gates_from_verdict)、cheap_run(smoke / ensure_play_spec / play)、cheap_studio.run_studio 现有接口,不改其签名;M1 收口报告 bake-off-M1-final.json 与 002 对照报告 compare-multi-*.json 须存在(U3 前置)。

Verification(里程碑收口)

M2 上线就绪的收口判据:

• U1:逐门 delta 判据单测全绿(关键门容差 0 / 其余 1/N 边界逐一覆盖、缺样本不被掩盖、零 LLM)。
• U2:同游戏双驱动编排小批真跑跑通(auto / golden 两组 gates 都取到、报告落盘)、编排单测(mock 调用序)全绿。
• U3:三条齐判定单测全绿(三条全绿 / 各缺一条 / 报告缺失逐一覆盖)、真实读三份既有报告产一次退役授权判定落盘。
• R5:灰度切换基础设施设计章节落档(九项语义 + 本地可验 vs 归 M3 边界钉清)。
• 里程碑级(硬收口):auto-vs-golden 门三品类实测(每品类 ~7 款、与 M1 同覆盖面)逐品类 delta 在阈值内(关键门 delta ≥ 0)、报告落盘;Node 退役授权判定三条齐(M1 达标 ✓ + 002 对照等价 ✓ + M2 auto-vs-golden ✓)产「authorized」结论——便宜档具备把默认路由切到 Python 的全部条件(本机口径,生产复验在 M3)。

Sources & Research

• 主计划 plan① docs/plans/2026-06-25-生成引擎统一执行计划-AgentScope三档-plan.md:§4 切片一 M2 定义(auto-vs-golden delta + 灰度基础设施 + Node 退役门)、迁移安全契约九项、§7 设计面对账(WU-C 5.4 / WU-F)。
• 前序 M1 docs/plans/2026-06-26-003-feat-cheap-worker-M1-达标门绿-plan.md:U2 verification 明示 auto-vs-golden 是 Node 退役授权的证据起点、M1 只证单款同质不产退役许可;质量口径与覆盖面边界。
• 前序 002 docs/plans/2026-06-26-002-feat-cheap-worker-multi-genre-plan.md:对照等价坐实(三品类 equivalent)、对照报告字段;成功定义「金标 spec 下」≠ 生产许可,退役授权另 gate 在 auto-vs-golden delta。
• 设计 SoT docs/architecture/架构/生成引擎/agentic运行时架构图说.md:§4.1 便宜档闭环、§5.4 三层校验与九门、§5.6 装载。
• 现状侦察(本会话只读):auto-vs-golden 无现成门;复用点 compare_node.py(inject_golden 174 / _write_spec_atomic 166 / run_pair_sync 213 / run_multi 312 / gates_from_verdict 55 / _port_pool 276)、cheap_run.py(smoke 174 / ensure_play_spec 239 / play 265)、cheap_studio.run_studio(run_gates 开关)、金标 spec fixtures/golden-specs/*.play-spec.json(driver + expectedEngineCallPrefixes + assertAfterPlay + expectLatch)。
• 蒸馏指针 .agents/skills/gen-path-parity-harness.md:对照公平铁律、达标门质量口径、自动 spec 期望外生防自证——auto-vs-golden 门是同源范式的第三道门(对照轴换成驱动器金标 vs 自动)。

创始人已定口径(2026-06-27)

• M2 范围切法:M2 细化 plan 聚焦可本地执行的 auto-vs-golden 门(U1–U3);灰度切换基础设施在 M2 只出设计(R5)、真接线随 M3。
• 下一步主线:M1 收口后走切片一 M2(价值排序切片一先于切片二);切片二 tier2 n=5 收敛环前置 mini-desktop 可达,不在本 plan。
• auto-vs-golden 门定性(2026-06-27,据双评审收敛定):建全门 + 诚实降权。U1–U3 全建并真跑(符合 plan① 明列的退役前置),但 plan 文案诚实写明——这道门在 tap-targets 三品类上鉴别力有限(自动 spec 已与金标字段同质、delta≈0 几必然,主要确认逐款驱动器推断不失效),真鉴别场景在延后的 key-cycle 族;Node 退役授权的实质支撑是 M1 绝对达标 + 002 两路等价两条强证据,本门是其上的「不退化确认」、非决定性独立闸。门的方向按 plan① 口径单边查「自动不比金标驱得差」(delta < 0 即退化),不是查「自动比金标松」(后者对断言同质的 tap-targets 不成立)。