games-development-ai/tier2/contracts/mini-fei-e-fixture-spec.md

date, topic, status, owner, 映射源档

date	topic	status	owner	映射源档
2026-06-23	mini-肥鹅 靶子游戏规格（G2 · spike 对照组施工图）	建（tier2 待 0号 spike；本规格是 scaffold_init 与 harness driver 的施工图，Opus 或人预建）	契约线（6c6g）	docs/architecture/架构/生成引擎/tier2实现详设.md §靶子游戏:mini-肥鹅 / §0号 spike docs/architecture/架构/生成引擎/tier2细节图说-D-三层校验与九门.md 图 D3 参照富游戏 game-runtime/games/wanglanmei-ref/（肥鹅小卖部，12 src 文件，砍小照它）

mini-肥鹅 靶子游戏规格（G2）

这份是什么

0号 spike 要证「便宜/中等模型自治能不能稳定写出富游戏那约 56% 的表现层」，得有一个确切的靶子游戏才能预建对照组（人工预建骨架 + 人工预建 driver）。这份规格把那个靶子钉死——一个砍到能证、又保住富游戏三个本质难点（多系统耦合、重 UI 表现层、数值经济闭环）的最小经营游戏，代号 mini-肥鹅，结构参照仓内 wanglanmei-ref 但更小。砍掉任务弹窗、背包深度、上百物品，留三个联动系统。

它是两样东西的施工图：① scaffold_init（A7）按它预建经营骨架工程（三系统 + 耦合点的平台代码，先天过 boot）；② harness driver 按它预建确定性驱动序列（点合成→凑齐订单物品→交单→看金币涨）。富游戏三门（A5 richGameGates）的 assertAfterPlay 规格也照这个靶子写。

三系统 + 耦合点

mini-肥鹅 = 三个系统耦合在一起，考点正是它们不是三座孤岛。

系统一·资源系统（其余两系统的读写交汇点）

维护两种货币，状态是一张极小的表：

{ coins: number, ingredients: { [itemId: string]: number } }

它是合成与订单的读写交汇点：合成消耗食材、订单产出金币、解锁花金币。命令式 API（承袭 wanglanmei-ref shop-core.js createShopCore 注入受控 random/time、返 {ok,reason} 范式）：

• addCoins(n) —— 加金币（完单时调）。
• spendCoins(n) → {ok, reason} —— 花金币（解锁摊位/更高合成链时调；不足则 ok=false）。
• consumeIngredient(itemId, n) → {ok, reason} —— 扣食材（合成消耗时调；库存不足 ok=false）。
• addIngredient(itemId, n) —— 加食材（合成产出时调）。

系统二·合成系统（重 UI 表现层主承载）

一块 3×3 棋盘，玩家点两个相同物品合成上一级。这块是重 UI 表现层的主要承载——棋盘格渲染、点击命中、合成动画，全是 LLM 现写、最易崩的那 56%。合成链是数据表：

mergeChains: [{ from: string, to: string, cost: number }, ...]   // 6 条链，覆盖 12 物品

• 棋盘 3×3，每格放一个物品或空。
• 点两个相同物品 → 按 mergeChains 查 from→to → 消耗（调 consumeIngredient）→ 产出上一级（调 addIngredient / 落格）。
• 合成产出进资源系统库存。

系统三·订单系统

一个面板列 3~5 个顾客订单，每个要一组物品给一笔金币，耐心耗尽则流失。数据表：

orders: [{ id: string, requires: { [itemId: string]: number }, reward: number, patience: number }, ...]   // 5 个模板

• 完成订单：从库存扣物品（调 consumeIngredient）→ 给资源系统加金币（调 addCoins）。
• 耐心耗尽：订单流失（计入连续流失计数）。

确切耦合点（spike 考点，不是三个孤岛）

这四条耦合点是富游戏「三联动门」（A5/D3）的判据来源：

1. 跨表可达性：订单的 requires 必须能被合成系统产出的物品满足——静态从 mergeChains 推到 orders，证每个订单要的物品都在合成可产出集合里。
2. 合成 DAG 无环：mergeChains 必须是有向无环图（对它做拓扑检查、不许成环）。
3. 完单真调资源：完成订单时必须真调资源系统的 addCoins（F 门级真接线，非自绘伪装）。
4. 合成消耗真调资源：合成消耗时必须真调资源系统的 consumeIngredient。
5. 金币门控解锁：攒够金币解锁第 4、5 个摊位和更高合成链（调 spendCoins）。

胜负条件（两条路都要能被真输入驱动到终态并 latch）

• 赢 = 金币从开局 20 攒到 100（经「合成→交单→收金币」的正循环）。
• 输 = 连续 3 个订单流失（只合成不交单、或经济崩盘）。

关键约束（经济门 A5/D3）：两条路径都要能被 harness 真输入驱动跑到终态——「能算」和「能玩到」是两回事。终态落定后焊成 latch（readState().phase 置 'win'/'lose' 驻留不回弹，宿主轮询读，见 A4/A6）。

内容量（钉死，砍到能证而不让 spike 变重）

项	量
物品	12 个
合成链	6 条（覆盖 12 物品）
订单模板	5 个
货币	2 种（金币 coins + 食材库存 ingredients）
棋盘	3×3
同屏订单	3~5 个（带 patience）
开局金币	20
赢线	金币 100
输线	连续 3 订单流失

预建分工（spike 第一段·纯模型变量）

第一段是纯模型变量，固定人工骨架 + 人工 driver，只测便宜模型「填差异」：

• 人/Opus 预建（platform 代码，先天过 boot）：mini-肥鹅 经营骨架工程——三系统 + 五条耦合点的平台代码、留空数据表 schema（12 物品/6 链/5 订单，留空给 LLM 填值）、共用资产池占位图。骨架按三系统加耦合点预建，先天过 boot（A_boot 绿）。
• LLM 自治填（那约 56%）：在骨架上填数据表、写表现层——棋盘格渲染、点击命中、合成动画、事件到表现的接线、本游戏特色规则。自治循环：写源 → build → headless 快检 → L1 确定性门 → 读 verdict → 改。
• driver 人预建（agent 不碰）：经营品类确定性 harness driver，序列 = 「点合成格 → 凑齐订单物品 → 交单 → 看金币涨」。driven=true（有 driver），E_live/H_progress 恢复致命（A6/D4）。

driver 与 assertAfterPlay 规格（富游戏三门施工图）

driver 按确定性序列预建；assertAfterPlay 断言喂给 judge 判富游戏三门（A5 richGameGates 的 checks）。

driver 序列（business-sim 品类，确定性）：

1. 点合成格凑出某订单 requires 的物品（点两个相同 → 合成上级，重复到凑齐）。
2. 交该订单（触发 addCoins）。
3. 重复正循环把金币从 20 推到 ≥100（驱动赢路径）。
4. 破产路径变体：只合成不交单 / 放任 3 订单 patience 耗尽（驱动输路径）。

assertAfterPlay 断言（对应三门 checks）：

• 三联动门：
  • requiresReachable —— 静态：每个 order.requires 的物品 ∈ mergeChains 可产出集合。
  • dagAcyclic —— 静态：mergeChains 拓扑无环。
  • callsAddCoins —— 真玩：交单后 coins increased（且证调了 addCoins）。
  • callsConsumeIngredient —— 真玩：合成后对应食材 changed（且证调了 consumeIngredient）。
• 经济门：
  • 盈利路：驱动后 state.coins >= 100 ∧ state.phase == 'win'（从开局 20 经正循环攒到）。
  • 破产路：变体驱动后 state.phase == 'lose'（连续 3 订单流失）。
  • 两路都 reachedTerminal == true（真输入驱动到终态，非数据表算出）。
• latch 门：
  • 终态落定不回弹：多帧轮询 state.phase 恒定（win/lose 驻留）。
  • 宿主可读：探针 readState() 读到终局 phase。

证据：复用 game-e2e-cdp-harness 四件套（render → 截图时序 → 驱动 → verdict），每款产出可审计四件套（落 tier2-verdict.evidence.evidenceDir）。

砍小依据（对照 wanglanmei-ref）

wanglanmei-ref（肥鹅小卖部，12 src 文件约 180KB，三系统：进货定价/排队接待/结算）是已证存在过、过真输入 harness、赢输双路径可达的真富游戏。mini-肥鹅 照它砍小：保住三系统耦合 + 重 UI 表现层 + 数值经济闭环三个本质难点，砍掉任务弹窗、背包深度、上百物品。内容量定在 12/6/5/2 足够证数据驱动、又不让 spike 本身变重。