用户贴来一段散文：单文件 67KB、Three.js、炮弹在墙上反弹、微信聊天窗里就能玩。产线全库核查发现——这款游戏根本不在仓库里。于是把散文当规格立项：双分析、设计、开发；评审揪出 P0 反弹法线 bug，独立 harness 复核修复；部署时顺手合并了分叉的注册表；无头浏览器实测 10/10。8 步全绿，全程无人插手。
tech ⇄ ux 两位分析师并行核查：全库 grep + origin/main 复查，描述的 2852 行坦克游戏无命中——判定为新游戏需求，散文即规格。架构落点全部取自仓库先例：弹道直接沿用 022-cupid-ricochet 的模板（120Hz 固定子步 + 共享 traceSegment + MAX_BOUNCES 硬上限）——上一个案例造的游戏，成了这一案的工程模板。
产线运行中 · 分析师正在交锋：dt clamp 取 33ms 而非 50ms——低端聊天 WebView 持续 25-30FPS，50ms 会把整局变成慢动作
「核查发现：请求描述的 2852 行坦克游戏不在库中（Three.js 仅 005，坦克仅 2D 的 084），按“新游戏需求 + 仓库惯例”撰写。」 — ux-analyst → lead · 运行实录
设计工位产出交互式规格板：零白屏 boot / 菜单 / 战斗 HUD 实机演示 / 胜败双结算，外加 5 张规格卡——预判线与飞行弹道共用 traceSegment()、MAX_BOUNCES 10 硬上限、dt clamp 33ms，散文里的每一句机制都被翻译成了可执行约束；lint P0 = 0、critique 22/25 后注册画布。
设计工位 · 先搜仓库前例（cupid-ricochet 设计稿）对齐惯例，再产出规格板，md5 双副本校验一致
设计稿全貌 · BOOT / MENU / HUD（预判虚线 + 菱形反弹点）/ VICTORY / DESTROYED + 色板、字阶、触控热区、性能红线
首版提交后，评审在反弹核心里揪出 P0 法线符号 bug（两处 s=-s，西/北墙反弹方向全错）。修复不是嘴上说说：独立 120Hz harness 48 项全过、四向墙壁存活对齐；更狠的是负向对照——往内存副本里把 bug 种回去，精确复现首轮故障签名，证明测试真的测得出这个 bug。
8/8 全绿终态 · 22 个产物落盘：双分析、设计稿、游戏本体、两轮测试报告、评审与复审、部署与 web-test 报告
deployer 发现部署机与仓库的游戏注册表已分叉（主机 43 条 vs 仓库 41 条）。它没有拿一边硬覆盖另一边，而是合并成 52 条、零丢失；三个文件逐一 sha256 校验；重启网关前先用标记确认「这是我该管的进程」，健康检查全过才收工。
web-tester 无头 Chrome 实测 PASS 10/10：零白屏、boot→菜单→战斗→大厅全程 0 console 报错、预判线与菱形反弹标记、弹道拖尾、爆炸粒子、致命的敌方 AI。下面四张是我们自己再玩一遍的实拍——第四张败局结算屏，就是被那个「致命 AI」15 秒击杀的证据。
线上实机 · 菜单弹道动画 / 战斗 HUD 与弹药条 / 按住瞄准：预判虚线 + 菱形反弹点落在油桶上 / 败局结算——散文里的机制，一条条都能在屏幕上指出来
修过老游戏、救过消失的游戏、从 0 造过新游戏——这一次，连需求里的游戏都不存在：描述即规格，散文即立项。
把它描述清楚就行——核查、立项、设计、开发、评审、部署、验收，产线自主完成。人管定义，AI 管执行。