Ia Assertion Runner

Archived: 2026-08-12 · roadmap-id: game-web-phaser-template

Why

上游 web 侧（cogito-lib change acceptance-assertion-templates，2026-08-09 归档）已经把 验收项从「自由文本 + 一个标记」改成了「7 个断言模板 + 参数」，并在类型上强制 kind: 'machine' 必须带 templateId。它自己的文档写了一句必须被当真的边界：

🔴 本能力让 machine 变得可判定，但还没有任何东西在判定它。 把「可判定」说成「已判定」是这类系统最常见的自欺形式。

今天全库只有 AssertionFailure 这个契约类型，没有任何东西在生产它。下游两道门禁 （闸 2 本轮验收 / 闸 1 历轮回归）都以 machine 项为输入——输入有了，执法者没有。

核实出来的两个硬事实（它们决定了本刀的形状）

① jump() 是纯函数，驱动不了活着的游戏。

src/debug/state-jump.ts 的 jump(id, seed) 返回一个 plain snapshot，跟运行中的 Phaser Game 实例完全没有连线；panel.ts 点按钮也只是 JSON.stringify 打印一下。 它自己的注释很诚实：ships "the shape a future IA assertion runner will drive against"。

形状 ≠ 驱动器。 上游文档说「断言的驱动器就是 jump(state)」，但要把游戏真的送进某个 状态，还差一个把快照施加到活实例上的东西。这不是选择题，是必补的缺口。

② 7 个模板里，今天判得了的只有 1 个。

结论：光写一个脚本解决不了这件事。 缺的是游戏侧的内省与驱动契约——一个像 state-jump.ts 那样住在模板里、由每个生成项目实现的东西。运行器只是它的消费者。

为什么由模板自带契约，而不是让运行器去猜

猜就是启发式：从「按下 R 键」里抠出 R、从 canvas 截图里 OCR 找文字。把不确定性引回了 一道以确定性为存在前提的闸门——上游否掉 VLM（方案 A）的理由逐字适用：

一次性判分容忍不确定性；累积回归闸不容忍。 一个会随机变红的闸，必然在三、四轮之内被人关掉。

而且启发式判 fail 时无法追责：用户不知道是产物真差，还是运行器没看懂。

Non-goals

🔴 下面每一条都是本刀明确切出去的，不是执行时自行收窄。