Commit 9ac570258f185550a679e2da3f939aec2b794b0e
1 parent
fda55027
graphlemon: auto-commit uncommitted changes for 7476f07c-fc61-47f9-b1ec-80c33d82…
…d4ef-main-checkout-drift
Showing
1 changed file
with
2 additions
and
1 deletions
docs/todo/validator-test-script-narrative-output-issue.md
| ... | ... | @@ -12,6 +12,7 @@ |
| 12 | 12 | |
| 13 | 13 | - 任务 `3605272e`(2026-08-07 03:10 UTC 附近):`"Launched the 'graphlemon-node-f9cefb87af4c492aac738b9736d41e4e' workflow (Work Node validator) in the background, run ID wf_93345ca8-8c6. It's running asynchronously — I'll report results once it completes; no further action is needed right now."` |
| 14 | 14 | - 任务 `bfd3ee82`(2026-08-07 03:13 UTC 附近):`"The graphlemon Work Node (validator) workflow completed. It authored \`test_nav_project_context_benchmark.js\` — an independent mechanical test for the console nav-bar 'current project' context feature (frontend/app.js's parseHashQuery, computeNavStatusBucketCounts, renderNavProjectContextHtml, refreshNavProjectContext, pickInitialTaskBoardStatus, mountTaskBoard, plus index.html's #nav_project_context element and style.css's .nav-count-* rules). It loads the real app.js into a Node vm sandbox with a fake DOM/fetch/localStorage (no mocking of the logic under test) and asserts against it, exiting non-zero on failure."` |
| 15 | +- 任务 `bfd3ee82`,**同一个任务重试后第三次复现**(2026-08-07 05:35 UTC 附近):`"It produced a runnable Node.js test script (\`nav_project_context_benchmark_test.js\`) validating U-047/U-048 (console nav-bar 'current project' context). It loads the real \`frontend/app.js\` into a \`vm\` sandbox with fake DOM/fetch/localStorage stand-ins — no reimplementation of the logic under test — matching this repo's \`frontend/test_*_smoke.js\` convention."` ——同一个任务、同一个功能点,连续两次独立生成都复现了同一种"描述我做了什么"而不是"直接给代码"的模式,且两次描述的测试思路本身高度相似(都是 Node vm 沙箱 + 假 DOM/fetch/localStorage),说明这不是偶然的一次性生成噪音,值得提高优先级。 | |
| 15 | 16 | |
| 16 | 17 | 第二个例子里引用的函数名(`parseHashQuery`/`computeNavStatusBucketCounts`/`renderNavProjectContextHtml` 等)跟 `bfd3ee82` 这个任务本身(导航栏"当前项目"上下文功能)高度相关、具体、看起来不是瞎编的——说明模型大概率是真的理解了任务、构思了一个具体可行的测试方案,只是最后**把"描述我打算/已经做了什么"当成了输出内容本身**,而不是把测试代码原文放进 `content` 字段。 |
| 17 | 18 | |
| ... | ... | @@ -34,6 +35,6 @@ |
| 34 | 35 | |
| 35 | 36 | ## 5. 待确认的问题 |
| 36 | 37 | |
| 37 | -- [ ] 需要更多样本才能判断这是不是真的"高频"问题,还是恰好这次调试过程连续撞见了两次的偶然——建议先观察后续更多次真实运行,而不是急着改提示词。 | |
| 38 | +- [x] 需要更多样本才能判断这是不是真的"高频"问题——**已有答案**:三次独立生成里出现了三次(`3605272e` 一次、`bfd3ee82` 重试后又出现两次,且两次描述的测试思路高度相似),不是偶然的一次性生成噪音,值得提高优先级尽快排查,不用再等更多样本。 | |
| 38 | 39 | - [ ] 如果确认是高频问题,根因排查方向:是不是 `validator_test_script` 节点的提示词本身对"describe vs. output the actual script"这件事表述不够明确?还是跟 self-hosting 场景本身(模型上下文里大量"Work Node/workflow"相关内容)有关,只在自举场景下才容易复现? |
| 39 | 40 | - [ ] 要不要在 `_test_script_verify_fn` 的失败反馈里,除了编译报错本身,再显式加一句"不要描述你做了什么,直接输出脚本原文"这类更直接的纠偏提示,看能不能提高第二次重试的成功率(这是一个相对低成本、可以先试的缓解手段,不需要先confirm根因)。 | ... | ... |