Commit f41de172dace32479ca9aec8f11b2cc403fba58d
1 parent
867d5150
docs(34): 抽查另外两个项目根——验证严谨度完全不稳定，不是设计好的模式
对比 e2e-demo 现有的三个项目根：
p-v82tpc（今天的回归任务）—— 静态正则解析文本，零浏览器
p-bkhylu（"做一个 lemonai 官网"）—— 真实 Playwright + headless Chromium：
六档视口量 scrollWidth/clientWidth、getComputedStyle 量字号、手算 WCAG 对比度、
禁 JS/reduce-motion 验证、整体挪到 /tmp 用 file:// 重开验证可移植性
p-v1mpcl（31 号文档那条原始卡住任务）—— 无验证，任务在验收前就被取消
p-bkhylu 的 DELIVERY.md 里那句"未采信自证脚本，符合 SDD §0/§2 I-4 验收独立性
要求"，搜遍 system/、docs/ 都找不到这条规则——它是那次任务的 sdd-planning 会话
自己写进那次 SDD 的，不是仓库级别的通用约束。也就是说三条任务里，要不要认真
验证、认不认自证脚本，完全取决于哪次任务规划时 agent 会话恰好这么想，没有系统
保证。这就是 34 号文档 §三"影响面"判断的实锤：任务显示"已完成"与"真的达成
原始需求"之间的落差，目前只能靠运气。
34 号文档 §四 checklist 全部查完，状态行同步更新。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Showing
2 changed files
with
45 additions
and
10 deletions
docs/README.md
| ... | ... | @@ -49,7 +49,7 @@ Graph Agent 架构重构（27 系列）。**已完成的阶段文档已移入 `d |
| 49 | 49 | | [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） | |
| 50 | 50 | | [30-task-delegation-reliability-gaps.md](./todo/system-design/30-task-delegation-reliability-gaps.md) | **任务委派可靠性现状**— 📝 调研记录，非设计方案。DevLoop `runUnit`、Company 招聘装配、Graph 执行三条链路核对结论一致：都是「失败预算耗尽 → 停等人工」，没有「卡住了主动通知人」这一层；DevLoop 当前还默认走 mock，真实 CLI 成功率无实证数据 | |
| 51 | 51 | | [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 次，零人工介入），修复确认生效 | |
| 52 | -| [34-validator-scored-without-real-deliverable.md](./todo/system-design/34-validator-scored-without-real-deliverable.md) | 📝 **调研记录，原始前提已订正**。最初以为 `org-coder-impl` 从未产出任何 HTML/CSS，后来发现真实网站其实存在于 `graph_files` 索引不覆盖的「项目根」目录（已顺手修：控制台「产物」面板现在会展示项目根）。追加查了 validator 有没有真的做浏览器级检查——**没有工具，物理上做不到**，但有一份真实的静态断言脚本代替了 5/6 维度的检查，不是空手套白狼；顺带在新招聘的 `unit-tester` 本体上又撞见一次 [32 号文档](./todo/system-design/32-hire-body-fill-reliability.md) 那类装配未完成的真实样本 | | |
| 52 | +| [34-validator-scored-without-real-deliverable.md](./todo/system-design/34-validator-scored-without-real-deliverable.md) | 📝 **调研记录，checklist 已查完**。最初以为 `org-coder-impl` 从未产出任何 HTML/CSS，后来发现真实网站其实存在于 `graph_files` 索引不覆盖的「项目根」目录（已顺手修：控制台「产物」面板现在会展示项目根）。追加查清 validator 有没有真的做浏览器级检查——没有工具、物理上做不到，但有真实静态断言脚本代替了 5/6 维度；抽查另外两个项目根后发现**验证严谨度完全不稳定**（同类任务有的做了真实 Playwright 级验证、有的只做静态正则、有的没验证就被取消），"已完成"背后的验收质量目前全靠单次任务规划时 agent 即兴发挥，没有系统保证。顺带在新招聘的 `unit-tester` 本体上又撞见一次 [32 号文档](./todo/system-design/32-hire-body-fill-reliability.md) 那类装配未完成的真实样本 | | |
| 53 | 53 | | [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 号文档的真实回归验证过程中，与兜底边问题无关 | |
| 54 | 54 | |
| 55 | 55 | ## todo/future/（暂缓，非当前重心） | ... | ... |
docs/todo/system-design/34-validator-scored-without-real-deliverable.md
| 1 | 1 | # 34-validator-scored-without-real-deliverable. coder-validator 在没有真实产物的情况下给了满分 |
| 2 | 2 | |
| 3 | 3 | > **日期**: 2026-08-22 |
| 4 | -> **状态**: 📝 **调研记录，非设计方案**。§一/§二的核心前提已被 §零 推翻大半—— | |
| 5 | -> 原始判断（"index.html 从未被写出来"）是错的，真实网站文件其实存在，只是不在 | |
| 6 | -> `graph_files` 索引里。§五 追加查过"validator 有没有真的做浏览器级检查"： | |
| 7 | -> **没有浏览器工具，物理上做不到**，但确实有一份真实可运行的静态断言脚本代替了 | |
| 8 | -> 5/6 维度的检查（不是空手套白狼），且顺带在 `unit-tester` 本体身上又撞见一次 | |
| 9 | -> [32 号文档](./32-hire-body-fill-reliability.md)那类"招聘装配没填充完"的真实样本。 | |
| 10 | -> 剩下没做的：抽查这套"用静态脚本代替浏览器"是不是稳定行为，见 §四剩余 checklist。 | |
| 4 | +> **状态**: 📝 **调研记录，非设计方案，§四 checklist 已全部查完**。§一/§二的核心 | |
| 5 | +> 前提已被 §零 推翻大半——原始判断（"index.html 从未被写出来"）是错的，真实网站 | |
| 6 | +> 文件其实存在，只是不在 `graph_files` 索引里。§五追加查完三件事：① validator | |
| 7 | +> 没有浏览器工具，物理上做不到 rubric 要求的检查；② 但确实有一份真实静态断言 | |
| 8 | +> 脚本代替了 5/6 维度的检查，不是空手套白狼；③ 抽查另外两个已存在的项目根后 | |
| 9 | +> 发现**这种验证方式完全不稳定**——同类任务里有的做了真实 Playwright 级验证、 | |
| 10 | +> 有的只做了静态正则、有的没验证就被取消，"任务已完成"背后的验收严谨程度全靠 | |
| 11 | +> 单次任务规划时 agent 会话即兴发挥，没有系统性保证。顺带在 `unit-tester` 本体 | |
| 12 | +> 身上撞见一次 [32 号文档](./32-hire-body-fill-reliability.md) 那类"招聘装配没 | |
| 13 | +> 填充完"的真实样本。是否需要引擎级前置闸门统一验证严谨度，留给下次设计。 | |
| 11 | 14 | > **触发**: `e2e-demo` 公司真实回归任务 `T-mt2r6fz0-125b`（goal `G-mt2r62ia-73af`， |
| 12 | 15 | > root run `run_0e9074815130`）——[31 号文档](./31-work-graph-fail-fallback-coverage.md) |
| 13 | 16 | > 兜底边修复 + [33 号文档](./33-needs-gate-role-filter-bug.md) 契约修复之后，把这条任务 |
| ... | ... | @@ -129,9 +132,10 @@ contract.json 跨节点契约快照 |
| 129 | 132 | 实际靠的是一份零依赖的静态断言脚本（`unit-tester.check.js`），不是"回填数字"， |
| 130 | 133 | 是"跑一个真脚本、贴真实输出"，与 `coder-validator/agent.md` Step 2 的既有要求 |
| 131 | 134 | （"没跑过的测试等于不存在"）同一个纪律，只是换了检查对象。 |
| 132 | -- [ ] 抽查其他任务（比如 `p-bkhylu`/`p-v1mpcl` 这两个已存在的项目根）的 validator | |
| 135 | +- [x] 抽查其他任务（`p-bkhylu`/`p-v1mpcl` 这两个已存在的项目根）的 validator | |
| 133 | 136 | 评分记录，看这次"用静态脚本代替浏览器检查"是这条任务的一次性即兴发挥， |
| 134 | - 还是已经是这类骨架的稳定行为——仍未做，见 §五.2 末尾。 | |
| 137 | + 还是已经是这类骨架的稳定行为——**是一次性即兴发挥，三条任务三种做法**， | |
| 138 | + 完全不稳定。见 §五.3。 | |
| 135 | 139 | - [ ] 是否需要给"必须打开真实产物检查"的维度加一道**引擎级的前置闸门**：至少确保 |
| 136 | 140 | 被检查的文件（如 `index.html`）在 `evidence_hint` 点名的路径下真实存在 |
| 137 | 141 | （现在项目根已经可查，这道闸门补起来比 §零 之前容易）。§五.2 的静态脚本已经 |
| ... | ... | @@ -206,3 +210,34 @@ Node 脚本，读 `index.html`/`styles.css`/`script.js` 三个真实文件做静 |
| 206 | 210 | 验证新机制）。也就是说，这份相当机灵的静态断言脚本，很可能是 `unit-tester` |
| 207 | 211 | **在没有任何角色指导的情况下、纯靠通用 four-phase 骨架的常识自己想出来的**—— |
| 208 | 212 | 换一次任务、换一次会话，不保证还会有 agent 主动想到用这种方式弥补工具缺口。 |
| 213 | + | |
| 214 | +### 5.3 抽查另外两个已存在的项目根：三条任务三种做法，验证方式完全不稳定 | |
| 215 | + | |
| 216 | +`e2e-demo` 公司目前一共有三个项目根，正好覆盖三种局面： | |
| 217 | + | |
| 218 | +| 项目根 | 任务 | 状态 | 验证方式 | | |
| 219 | +|---|---|---|---| | |
| 220 | +| `p-v82tpc` | `T-mt2r6fz0-125b`（本文档，今天的回归任务） | completed | `tests/unit-tester.check.js`：静态正则解析 HTML/CSS/JS 文本，零浏览器 | | |
| 221 | +| `p-bkhylu` | `T-msyu6u9b-939c`（"做一个 lemonai 的官网"） | completed | **真实 Playwright + headless Chromium**：六档视口量 `scrollWidth`/`clientWidth`、`getComputedStyle` 量字号、手算 WCAG 对比度、禁 JS/reduce-motion 验证、把项目整体挪到 `/tmp` 用 `file://` 重新打开验证可移植性 | | |
| 222 | +| `p-v1mpcl` | `T-mt1qx0c4-95bf`（"apple.com 风格官网"，31 号文档卡住的那条原始任务） | **cancelled** | 无——只有 `index.html`/`script.js`/`style.css`，没有 `tests/`、没有 `DELIVERY.md`，任务在验收之前就被取消了，这批文件是留在项目根里的半成品 | | |
| 223 | + | |
| 224 | +**`p-bkhylu` 的证据链明显更扎实**：它的 `DELIVERY.md`（读了全文）逐维度贴了真实 | |
| 225 | +测量数字（六档视口零溢出的表格、四组元素真实对比度数值、`.section__title` 真实 | |
| 226 | +计算字号 48px），`content_fidelity` 维度因为"无法访问 lemonai.ai、内容全是占位" | |
| 227 | +这个真实限制，**老实评了 80 分而不是 100**（`run_9168bd24f46c` 的 | |
| 228 | +`attempt-0.scores.json` 可查）——这正是"真查过"该有的样子：有一项做不到就如实 | |
| 229 | +反映在分数里，不是全 100。`DELIVERY.md` 末尾还有一句"本轮…未运行或采信项目根内 | |
| 230 | +不存在的 `checks/check.mjs`（本项目未创建该自证脚本），符合 SDD §0/§2 I-4 关于 | |
| 231 | +验收独立性的要求"——**这条"不许自己写脚本自己判"的规则是那次任务的 SDD 自己写的 | |
| 232 | +（`SDD §0/§2 I-4` 搜遍 `system/`/`docs/` 都没有这个条目），不是仓库级别的通用约束**， | |
| 233 | +换句话说：**要不要认真验证、认不认可自证脚本，取决于那次任务恰好由哪个 sdd-planning | |
| 234 | +会话规划、恰好写没写这条规矩，不是系统保证的**。 | |
| 235 | + | |
| 236 | +**结论（回答 §四那条 checklist）**：`p-v82tpc` 这次"用静态脚本代替浏览器检查" | |
| 237 | +**不是稳定模式，是这一条任务的即兴发挥**——同一个公司、同类任务，`p-bkhylu` | |
| 238 | +做到了真实浏览器级验证，`p-v82tpc` 只做到了正则解析文本，`p-v1mpcl` 干脆没做到 | |
| 239 | +验证就被取消。三条任务的"完成"背后，验证严谨程度天差地别，而这个差异在任务列表 | |
| 240 | +/ 控制台上完全看不出来——三个都显示"已完成/已取消"，不会告诉你其中一个的验收 | |
| 241 | +证据比另一个扎实十倍。这本身就是 §三"影响面"那条判断的实锤：**"任务显示已完成" | |
| 242 | +与"真的做到了原始需求"之间的落差，在这个系统里目前完全依赖单次任务规划时 | |
| 243 | +agent 会话的即兴发挥，没有系统性保证**。 | ... | ... |