-
§5.1 原来断言"没有浏览器工具，物理上做不到"，复盘时对照 p-bkhylu 的 org-coder （同样只有 bash/read_file/str_replace(+write_file)，没有专门的浏览器工具）却 真跑出了 Playwright + headless Chromium 测试，才发现这个判断错了：仓库自带 playwright 依赖，bash 里 `node verify.mjs` 沿目录树能 require 到仓库根的 node_modules，这条路今天的 coder/unit-tester 同样走得通。 真正的差异不是工具权限，是 unit-tester 的 agent.md 从未填充过（32 号文档那类 问题）、没有任何角色指导，而 org-coder/coder-validator 都是正常填充过的成熟 本体。根因从"平台缺工具"改判为"这次没有指导 agent 主动想到"，是一个不一样、 也更能采取行动的结论。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
对比 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> -
34 号文档追加调查（§五）： - coder-validator（预置 active 本体）的 agent.md 通篇是代码/契约正确性验证协议 （npx vitest run + 抓假绿五件套），压根不涉及视觉/交互检查；这次任务新招的 coder/unit-tester 两个本体 toolPolicy 都只有 bash/read_file/str_replace， 没有浏览器/截图工具——goal-benchmark.json 的 evidence_hint 要求"打开浏览器"， 在给定工具权限下物理上做不到，不是 agent 偷懒。 - 但也不是纯粹空手套白狼：data/companies/e2e-demo/projects/p-v82tpc/tests/ unit-tester.check.js 是一份真实可运行的零依赖静态断言脚本，对维度 1-3 的检查 （字号比例真解析 CSS clamp() 算出数字、三个卖点区块标题顺序、锚点跳转/平滑滚动） 与浏览器版本基本等价甚至更精确；维度 4/5（响应式断点、资源完整性）的静态版本 明显更弱，会放过断点内样式写错、本地资源路径错误这类情况。 顺带发现：这份脚本很可能是 unit-tester 在提示词完全没有测试方法论指导的情况下 自己想出来的——它的 agent.md 还是没填充过的 _base 原始骨架（隔壁 coder 正常填充 过），是 32 号文档"招聘装配没填充完"那类问题的又一个真实样本（发生在方案 B 修复提交 6a18379 落地前 1 小时，是旧行为的证据，不是新机制的回归；新机制下 会不会正常完成，仍未验证）。32 号文档 §四追加第 6 条记录这次样本。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
用户反馈：控制台原来只能逐个节点点「输入输出」tab 看产物，缺一个全局入口。 新增 TaskFilesPanel.vue，挂在页头，跨节点/跨 run 一次性列出这个任务的全部产物。 做的时候发现分两类、且第二类之前完全没覆盖： · 节点产出索引（graph_files，按 company+task 检索）——规划笔记/日志/契约快照 · 项目根（W2 ensureProjectRoot，data/companies/{cid}/projects/{pid}/）—— 真实交付物代码写的地方，跨节点共享，indexNodeOutputs 从不扫它 后端补 readProjectRootRecord 导出 + GET /api/graph-runs/:id 挂 projectRoot 字段； 项目根的文件列表复用已有的 GET /:companyId/files（此前零调用方），不新开列目录端点。 新增 graph-run-route-io.test.js 两例（分配前 null、分配后原样透传 + 幂等）。 顺带订正 34 号文档：当时断言"index.html 从未被写出来"是错的——真实网站文件 其实在项目根里，只是没查那个目录。34 号文档 §零 记录了订正过程，问题收窄成 "validator 有没有真的做过浏览器级检查"（仍未解决，留待下次）。 全量单测 1000/1000 通过。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> -
真实回归任务 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>
