docs(34): 记录 coder-validator 在没有真实产物时给了满分这一验收缺口

真实回归任务 T-mt2r6fz0-125b 走到 completed 后回查产出，发现 org-coder-impl 从未写出任何 HTML/CSS/JS 文件（只有 _plan.md/_research.md/coder.log），但 org-coder-validator 给六个维度全打了 100 分。goal-benchmark.json 的 evidence_hint 里五个维度明确要求"打开 index.html/浏览器开发者工具检查"，这份评分显然没有真的执行过这些检查——是一次没有证据支撑的评分，不是 "查过但判错"。不是 31/33 号修复引入的新问题，是那两次修复让这条本会一直卡死的任务真的跑到 completed 之后，才把这个一直存在的验收缺口暴露出来。只记现象与证据，根因（提示词缺前置检查？validator 没有可用的浏览器/文件工具？是不是这次新招聘本体特有的一次性现象）留给下次调查，这次不深挖。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

docs(34): 记录 coder-validator 在没有真实产物时给了满分这一验收缺口
真实回归任务 T-mt2r6fz0-125b 走到 completed 后回查产出，发现 org-coder-impl 从未写出任何 HTML/CSS/JS 文件（只有 _plan.md/_research.md/coder.log），但 org-coder-validator 给六个维度全打了 100 分。goal-benchmark.json 的 evidence_hint 里五个维度明确要求"打开 index.html/浏览器开发者工具检查"，这份评分显然没有真的执行过这些检查——是一次没有证据支撑的评分，不是 "查过但判错"。不是 31/33 号修复引入的新问题，是那两次修复让这条本会一直卡死的任务真的跑到 completed 之后，才把这个一直存在的验收缺口暴露出来。只记现象与证据，根因（提示词缺前置检查？validator 没有可用的浏览器/文件工具？是不是这次新招聘本体特有的一次性现象）留给下次调查，这次不深挖。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
yibo
1 parent f74725ab
Showing 2 changed files with 98 additions and 0 deletions
docs/README.md
docs/todo/system-design/34-validator-scored-without-real-deliverable.md
@@ -49,6 +49,7 @@ Graph Agent 架构重构（27 系列）。**已完成的阶段文档已移入 `d
 | [29-dream-design.md](./todo/system-design/29-dream-design.md) | **dream（经验汇流）**— ✅ 已实现。定时整理所有 agent 在所有公司的记忆，提炼后跨公司沉淀（不泄漏公司信息）。四条取舍已拍板并实现：去敏独立判定、四落点分层写入（经验/`SKILL.md`/`soul.md`/`agent.md`，受管区块+三道闸门）、每日定时（串行+空转保护）、引用真伪自动查、REST+控制台入口（`/api/dream/*`、`/dream`）。`innovator-evolver` 真 CLI 跑通一次。**仍缺的**：「结论对不对」只能人抽查；「套进 org/work graph 来跑」评估后用户选了不做（作用域不匹配，见文内 §5.7） |
 | [30-task-delegation-reliability-gaps.md](./todo/system-design/30-task-delegation-reliability-gaps.md) | **任务委派可靠性现状**— 📝 调研记录，非设计方案。DevLoop `runUnit`、Company 招聘装配、Graph 执行三条链路核对结论一致：都是「失败预算耗尽 → 停等人工」，没有「卡住了主动通知人」这一层；DevLoop 当前还默认走 mock，真实 CLI 成功率无实证数据 |
 | [31-work-graph-fail-fallback-coverage.md](./todo/system-design/31-work-graph-fail-fallback-coverage.md) | work graph 兜底边覆盖不全 — ✅ 已完成（除入口节点外强制兜底边，`planner.json`/`executor-fanout.json` 补 6 条边），978/978 单测通过；2026-08-21 又用真实 LLM 起了一条新任务做端到端回归验证，`org-planner-sdd` 自判失败后自动打回 `org-planner-prd`（3 次，零人工介入），修复确认生效 |
+| [34-validator-scored-without-real-deliverable.md](./todo/system-design/34-validator-scored-without-real-deliverable.md) | 📝 **调研记录**。真实回归任务里 `org-coder-impl` 从未产出任何 HTML/CSS 文件，`org-coder-validator` 却给六个视觉/交互维度全打了 100 分——rubric 的 `evidence_hint` 明确要求打开真实页面检查，validator 显然没真查就评了分。只记现象与证据，根因（提示词缺前置检查？工具不可用？）留给下次 |
 | [33-needs-gate-role-filter-bug.md](./todo/system-design/33-needs-gate-role-filter-bug.md) | ✅ **已修复**。`executor.json`/`executor-fanout.json` 里 `produces:["log"]` 声明了一个 test/integration 类节点永远不会被索引到的 kind，导致 `org-coder-validator` 被 `missing_required_input` 反复误判 blocked；改成 `required:false`（对齐 `validator.json` 既有写法）。文档记录了一条**走过的弯路**（按 role 过滤 `inboundContracts` 会削弱 T-mt25ecbd 的产出闸门，已撤回），发现于 31 号文档的真实回归验证过程中，与兜底边问题无关 |
 ## todo/future/（暂缓，非当前重心）
+# 34-validator-scored-without-real-deliverable. coder-validator 在没有真实产物的情况下给了满分
+
+> **日期**: 2026-08-22
+> **状态**: 📝 **调研记录，非设计方案**——只记录现象与证据，不现场深挖根因（用户明确选择
+> 先记文档，验收链路本身的调查留给下次）
+> **触发**: `e2e-demo` 公司真实回归任务 `T-mt2r6fz0-125b`（goal `G-mt2r62ia-73af`，
+> root run `run_0e9074815130`）——[31 号文档](./31-work-graph-fail-fallback-coverage.md)
+> 兜底边修复 + [33 号文档](./33-needs-gate-role-filter-bug.md) 契约修复之后，把这条任务
+> 真正推到 `completed`，回头查"最终产出在哪"时发现的
+
+---
+
+## 一、现象
+
+任务最终状态：`completed`，`org-planner` / `org-coder` / `org-validator` 三个 org 节点
+全部 `success`。但查 `org-coder-impl`（`rn_e71be3641174`）的实际产出目录
+（`data/companies/e2e-demo/runs/run_0e9074815130/nodes/rn_e71be3641174/`），
+只有这些文件：
+
+```
+_plan.md        agent 自己的规划笔记
+_research.md    agent 自己的调研笔记
+coder.log       agent 自己的执行日志
+contract.json   跨节点契约快照
+```
+
+**没有任何 HTML/CSS/JS 文件**——任务原文要求的"apple.com 风格官网首页"从未被写出来过。
+`org-coder-test`（`rn_cd3e3a1c51e2`）同样只有 `_plan.md`/`_research.md`，没有测试对象。
+
+### `org-coder-validator` 的评分（`attempt-1.scores.json`）
+
+```json
+{
+  "hero_first_impression": 100,
+  "pitch_sections_completeness": 100,
+  "smooth_nav_no_anchor_jump": 100,
+  "responsive_layout": 100,
+  "resource_integrity": 100,
+  "pipeline_auto_recovery": 100
+}
+```
+
+六维度全部满分，`overall_pass_threshold=82`，加权后自然通过。
+
+## 二、这份评分明显没有真的检查过产物
+
+`goal-benchmark.json`（本次任务的验收契约）给每个维度都写了 `evidence_hint`，
+其中 5 个维度**明确要求打开真实页面检查**：
+
+| 维度 | `evidence_hint` 原话（节选） |
+|---|---|
+| `hero_first_impression` | 「打开 `index.html`，桌面宽度截图首屏；量 h1 与 tagline 的计算字号比值」 |
+| `pitch_sections_completeness` | 「滚动到底数区块数量与顺序；逐个检查 h2+p+visual 三要素是否齐全」 |
+| `smooth_nav_no_anchor_jump` | 「开发者工具 Elements 检查导航元素；点击时观察地址栏与 Network/Console 有无 hashchange」 |
+| `responsive_layout` | 「浏览器依次设置视口宽度 375/768/1440px 检查横向滚动条与重叠」 |
+| `resource_integrity` | 「打开浏览器开发者工具 Console + Network 面板刷新页面检查」 |
+
+这五项全都以"打开浏览器 / 打开 `index.html`"为前提——而 `index.html` 从来没有被
+`org-coder-impl` 写出来过。`org-coder-validator` 不可能真的执行了这些检查步骤，
+却仍然给出了 100/100。唯一有证据支撑的是第六维度 `pipeline_auto_recovery`
+（权重 0.25，本次回归验证真正要看的那一维）——它的 `evidence_hint` 是"读
+`attempt-*.json` 搜索 `fail_reason=input_underspecified`"，这条本身不依赖前端产物，
+`org-coder` 的 `remediationNote` 里也确实写了"检索本 run 下 nodes/\*/attempt-\*.json
+的 verdict/fail_reason 字段，未发现任何一条真实的判定"——这条像是真查过的。
+
+**结论**：`org-coder-validator` 至少在 5/6 维度上没有依据 `evidence_hint` 去核实
+产物是否存在就给了分，是一次**没有真实检查支撑的评分**（rubber-stamped），
+不是"检查过但判断错误"。
+
+## 三、影响面（未核实，留给下次）
+
+- 这不是 31/33 号文档改动引入的新问题——两次修复只是让流程**不再卡死**，
+  让这条原本会一直 blocked 的任务真的走到了 `completed`，才把这个一直存在的
+  验收缺口暴露出来。
+- 如果这是系统性行为（不是这一次运气差），意味着 `executor.json` 这类骨架的
+  `validator` 节点在**缺少真实产物**时可能倾向于给出宽松评分，而不是判 fail
+  或至少低分——这会让"任务显示已完成"和"任务真的达成了原始需求"之间出现
+  静默的落差，且这个落差**在界面上完全看不出来**（`org-coder` 的
+  `remediationNote` 里其实提到了"artifacts/ 下产物缺失"这类线索，但那是给
+  下一轮 agent 看的内部备注，不是给人看的告警）。
+
+## 四、留待下次调查的问题（不在本次范围内动手）
+
+- [ ] `coder-validator` 本体（`system/agents/unit-tester/agent.md` 或对应角色）的
+      提示词里，评分前有没有一步"先确认产物文件真的存在"的强制检查？如果没有，
+      这可能是这次跑分虚高的直接原因。
+- [ ] `coder-validator` 是否有可用的浏览器/文件读取工具去真的执行
+      `evidence_hint` 里描述的那些检查（截图、开发者工具）？如果工具不可用，
+      "满分"可能是它在无法验证时的默认基调，而不是主动撒谎。
+- [ ] 这是不是这次真实回归测试里 `org-coder`/`unit-tester` 两个新招聘本体
+      （见 [33 号文档提交时的记录](./33-needs-gate-role-filter-bug.md)）本身
+      还没配好角色提示词导致的一次性现象，还是所有 `executor.json` 骨架的
+      validator 节点普遍如此？
+- [ ] 是否需要给这类"需要打开真实产物检查"的维度加一道**引擎级的前置闸门**
+      （类似 T-mt25ecbd 的 produces 闸门）：`evidence_hint` 里点名要读的文件
+      如果在产物索引里查不到实例，直接判该维度 0 分或整体 blocked，不依赖
+      validator 自己主动去查。