diff --git a/docs/agent-specs/2026-06-16-视觉增强repair-review.md b/docs/agent-specs/2026-06-16-视觉增强repair-review.md
new file mode 100644
index 00000000..48a7e566
--- /dev/null
+++ b/docs/agent-specs/2026-06-16-视觉增强repair-review.md
@@ -0,0 +1,90 @@
+# ⛔ NO-GO（已否决，2026-06-16）—— 视觉增强 repair
+
+> **裁定：不做"视觉增强 repair"。** 三独立透镜一致否决，且被硬数据证伪——本稿存为**决策记录**（防再提）。
+>
+> 1. **对抗评审**：前提塌陷——`play.cdp.cjs:548 waitBoot 抛错 → :552 first-paint 永不写`，A_boot/D_render 早失败**无截图**；evidence 目录**零清场**→ M3 会读到上一轮陈旧图=系统性幻觉源；能数值判的门看图**冗余**、真需看图的软维度**软门(playerNode 视觉位)过门后已做**＝两头不靠；漏算诊断进 `K_FEEDBACK` 后**放大每个后续全量重出轮的 token**。
+> 2. **可行性评审**：同一 P0（A/D 失败无图，控制流证伪）；且 `judgeVision` 复用会带回 `playerSystem` 的 `verdict:pass/fix`＝**M3 又当了门**（自打"M3 不当门"红线）。
+> 3. **桌面统计（N=49 失败 / 87 运行，硬数据）**：**D_render = 0、C_frame = 0**——视觉失败象限**根本不存在**；真病灶 = **H_progress 85% + G_input/F_wiring 各 34%**，全是 game-loop 逻辑层，截图看不出、改渲染也修不了。`ts` 49/49 全 null（独立缺陷）。
+>
+> **数据指向的真高价值修复线**：**H_progress（game loop 终态驱动）+ G_input（输入响应）**——逻辑/prompt 问题，非视觉。
+>
+> **过程价值**：用 ~免费的两轮评审 + 桌面统计，在写 execution / 占端口 spike **之前**杀掉一个貌似合理、实则前提为假的提案。
+>
+> ---
+> *下文为当时考虑的提案原稿，仅存档。*
+
+---
+
+# 视觉增强 repair —— 硬门失败注入失败截图 + M3 诊断 · 评审版（已否决）
+
+> **状态**：review 版 · 2026-06-16 · ~~给创始人决策~~ **已 NO-GO，见顶部横幅**。基于对现行生成评测环的只读源码核证（`SaaStudioNodes.java`/`SaaPrompts.java`，file:line 见下）。
+> **定位**：生成评测环（W-G1 / HJ-GEN-001 / game-e2e-cdp-harness）的局部增强。**与 SAA 基建正交**——SAA 只换编排框架、节点逐字移植自 `studio.py`，本案不动框架、不动九门判定。
+
+---
+
+## 0. 结论先行
+
+- **现状缺口**：**硬门（九门 harness）失败时，repair 只拿到门的文字 verdict、没有失败截图/视觉诊断**；M3 视觉只在九门**过后**的软门（player 顾问轮）才跑。对"本质是视觉"的失败（黑屏 / 没渲染 / 卡帧 / 精灵缺失 / 布局崩），修复 agent 是"盲修"。
+- **建议**：在硬门失败路径，对**疑似视觉类**门失败追加一次 **M3 结构化视觉诊断**（读失败截图→出"缺什么 / 哪类问题 / 修复方向"），注入 repair feedback。**九门仍是唯一 pass/fail 权威，不变。**
+- **预期收益**：提修复成功率（尤其视觉类失败）、可能降平均修复轮数与成本。
+- **风险可控**：附加在失败路径、有界触发（仅特定门 + 轮次/成本上限 + M3 失败优雅降级不连坐），不改九门确定性、不引新框架、可 feature-flag 默认关。
+- **怎么定**：**A/B 用数据拍**，别空辩——#1 对比 harness 已产四件套截图证据，可复用。
+
+## 1. 背景：现行两层评测（已核证）
+
+| 层 | 角色 | 证据 |
+|---|---|---|
+| **九门 harness** | **硬地板**（确定性 CDP，pass/fail 唯一权威） | `SaaStudioNodes.java:712` playCondition「九门 pass→player；否则 repair/giveup，九门=硬地板」|
+| **M3 视觉位** | **软门顾问**（九门**过后**才跑，读首帧/玩后截图判进展/反馈可见/好不好玩） | `playerNode:437` + `judgeVision:537`（M3+截图+180s/≤3重试+失败优雅降级）；反馈经 `K_PLAYER_FEEDBACK` → `repairNode:628` 喂回生成 |
+
+> 即"喂图自修"在**软门路径已闭环**；生成 prompt 本就要求"反馈做得截图里看得见"（`SaaPrompts.java:130/179`）。**唯一盲区 = 硬门失败路径无视觉**（`repairNode` 此时走纯文字 `K_FEEDBACK`）。
+
+## 2. 现状 vs 提议（数据流）
+
+```mermaid
+flowchart LR
+  G[generate] --> V[validate] --> B[build] --> P[play 九门]
+  P -- pass --> PL[player 软门<br/>文本+M3视觉] -->|K_PLAYER_FEEDBACK| R[repair]
+  P -- fail --> R
+  R --> G
+  P -. 提议:fail且疑似视觉类 .-> VD[[visionDiagnose<br/>M3读失败截图出诊断]]
+  VD -. 注入 K_FEEDBACK .-> R
+  classDef new fill:#fde,stroke:#c39
+  class VD new
+```
+
+- **现状**：硬门 fail → repair 仅得文字 verdict。
+- **提议**：硬门 fail **且**门类型属"疑似视觉类" → 轻量 `visionDiagnose` 节点（复用 `judgeVision` 调用骨架，只换诊断向 prompt）读失败截图喂 M3 → 结构化诊断并入 `K_FEEDBACK` → repair → generate。
+
+## 3. 关键取舍
+
+| 取舍点 | 选项 | 建议 |
+|---|---|---|
+| 触发面 | 全失败都加视觉 / 仅"视觉类"门失败 | **仅视觉类**（成本+相关性）。D_render/C_frame 卡帧/H_progress 无进展=有视觉信号；B_uncaught/F_wiring=逻辑类，视觉帮助小→不触发 |
+| M3 职能 | 出 pass/fail 判决 / 只出诊断+修复方向 | **只出诊断**（守"done 由九门定、不让 LLM 自评"），绝不让 M3 当门 |
+| 动态盲区 | 喂视频/多帧补动态 / 不做 | **不做**（动态归九门：帧进/输入响应/进展确定性已覆盖），避免重+贵 |
+| 成本 | —— | 每次视觉类失败+1 次 M3 调用；需测**净收益**（修复轮数下降是否抵单轮视觉成本） |
+
+## 4. 爆炸半径 / 兼容
+
+- **改动面**：play 失败路由 + 新增 `visionDiagnose` 节点 + repair feedback 注入。**不动**九门判定、SAA 框架、8 类契约。
+- **复用**：`judgeVision`（M3+截图+超时重试+优雅降级）骨架现成，只换 prompt（诊断向）。
+- **兼容**：feature-flag 默认关 = 现行行为逐字不变。M3 失败优雅降级回落纯文字 verdict、不连坐。
+- **公平性**：评测设计是 Python/SAA 共享语义；A/B 须同臂对照（要么两侧都加、要么只在一侧量"加 vs 不加"的增量）。
+
+## 5. 验收（A/B 指标）
+
+主指标：**修复成功率 ↑ / 平均修复轮数 / 通过率 / 成本-每款**。
+诊断质量：**视觉诊断命中率**（M3 指出的问题，下一轮是否真被修掉）。
+分层：按**门失败类型**分布看（视觉类 vs 逻辑类，验证"只对视觉类有用"假设）。
+
+## 6. 待确认（创始人/团队）
+
+1. **触发门清单**：哪些门失败算"视觉类"、触发视觉诊断？（建议起步：D_render + C_frame 卡帧 + H_progress 无进展）
+2. **预算上限**：每款最多几次视觉诊断 / 成本闸？
+3. **落点**：先在对比 harness 离线 A/B，还是直接进 SAA 生产路径（feature-flag）？建议**先 A/B**。
+4. **值不值得**：用 A/B 数据决——若视觉类失败占比低或诊断命中率低，则不投。
+
+---
+
+> **下一步（确认本案方向后）**：① 两轮对抗评审；② 写 execution 版（节点契约/触发谓词/诊断 prompt/降级路径/A/B 跑法）；③ 待 #1 腾端口后 spike 一版去 A/B。