test_script re-enabled: each org agent self-plans whether to include it

Removed the "disabled" framing from docs/done/validator-test-script- narrative-output-issue.md (moved todo/ -> done/, root cause identified, structural fix landed, spot-check clean) -- the mechanism it described (_CANONICAL_DOC_CHAIN, e2e_pipeline._VALIDATOR_MANIFEST) no longer exists in production code, superseded by the 2026-08-08 self-planning rewrite and Org Graph unification Phase 2. Planner's and Validator's self-planning catalogs already carry test_script as a suggested (not required) option; _CODER_NODE_CATALOG was the one gap -- added a matching entry there (mechanical check_script_compiles judgment, same as Validator's). All three org agents now decide per-goal whether this node is worth planning, with no remaining "this node type is globally off" switch anywhere. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

test_script re-enabled: each org agent self-plans whether to include it
Removed the "disabled" framing from docs/done/validator-test-script- narrative-output-issue.md (moved todo/ -> done/, root cause identified, structural fix landed, spot-check clean) -- the mechanism it described (_CANONICAL_DOC_CHAIN, e2e_pipeline._VALIDATOR_MANIFEST) no longer exists in production code, superseded by the 2026-08-08 self-planning rewrite and Org Graph unification Phase 2. Planner's and Validator's self-planning catalogs already carry test_script as a suggested (not required) option; _CODER_NODE_CATALOG was the one gap -- added a matching entry there (mechanical check_script_compiles judgment, same as Validator's). All three org agents now decide per-goal whether this node is worth planning, with no remaining "this node type is globally off" switch anywhere. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
bboonnee
1 parent cfedd2b5
Showing 12 changed files with 33 additions and 17 deletions
docs/done/org-graph-unification-and-universal-self-planning-requirements.md
docs/done/org-graph-unification-phase1-review-gate-design.md
docs/done/org-graph-unification-phase2-universal-self-planning-design.md
docs/todo/validator-test-script-narrative-output-issue.md → docs/done/validator-test-script-narrative-output-issue.md
docs/done/work-graph-self-planning-and-loop-back-requirements.md
skills/planner-output-review/SKILL.md
skills/skill-defect-remediation/SKILL.md
skills/work-graph-node-review/SKILL.md
src/e2e_pipeline.py
src/scheduler.py
src/test_e2e_pipeline.py
src/work_graph_plan.py
@@ -4,7 +4,7 @@
 **性质**: 需求文档（BRD/PRD 层面），不含详细技术设计。融合并统领以下既有 `docs/todo/` 文档的相关内容：
 - `docs/todo/org-graph-as-work-graph-unified-loop-requirements.md`（已删除，内容 100% 并入本文档）——本文档是它的展开与拍板；该文档提出的"跨 Org Agent 精确 loop_back"诉求是本文档 FR-4 + §4 关键架构决策的正文。
 - `docs/done/task-execution-resume-assumes-planner-artifacts-exist.md`——它记录的 bug 与本文档 FR-1 改动的是**同一段** `run_or_resume_task_lifecycle()` 分支逻辑（见 §2.1 调研结论），折入 Phase 1 一并修，不再单独排期。
-- `docs/todo/validator-test-script-narrative-output-issue.md` 第 8 节提到的"另一份尚未撰写、关于给 Coder agent 加入 test_script 模块的文档"，即本文档 Phase 2（FR-2/FR-3）。
+- `docs/done/validator-test-script-narrative-output-issue.md` 第 8 节提到的"另一份尚未撰写、关于给 Coder agent 加入 test_script 模块的文档"，即本文档 Phase 2（FR-2/FR-3）。
  
 **触发场景**：任务 `2084590a`（修复 `work_node_run.py` 的 `execution_log_file` bug）里，Planner 自规划出的 `benchmark` 节点连续 4 次产出的都是"叙述我做了什么"的散文（跟 `validator-test-script-narrative-output-issue.md` 同一类问题，这次发生在 benchmark 上），LLM judge 的 `on_fail=retry_self` 循环耗尽 `max_attempts=3` 后任务直接 `blocked_pending_human`——暴露出 Validator 从来没有机会在 Coder 开始实现之前复核 Planner 自己的产出。用户随后 2026-08-08 提出四点架构改动设想（见 §1），与当天早些时候整理的 `docs/todo/` 待办优先级建议（P0~P3）高度交叉，要求重新盘点、融合、给出 phase 规划。
  
@@ -122,7 +122,7 @@ _REQUIRED_ARTIFACTS = {
 ### 5.1 新增：叙述文字启发式（复核阶段的辅助信号，非硬拦截）
  
 ```python
-# ponytail: 子串匹配，从 docs/todo/validator-test-script-narrative-output-issue.md
+# ponytail: 子串匹配，从 docs/done/validator-test-script-narrative-output-issue.md
 # 记录的真实复现文案里提炼——"以为在描述自己做了什么"的稳定措辞模式。只作为喂给
 # planner_reviewer 的提示信号，不是硬性机械拦截（跟 check_script_compiles 不同：
 # 这里没有客观的"编译通过/失败"可判断，误判成本是把合法的、恰好提到这些词的文档
@@ -396,7 +396,7 @@ def run_or_resume_task_lifecycle(conn, task_id, target_folder_path, goal_text):
 ### 8.2 新增 skill：`skills/planner-output-review/SKILL.md`
  
 内容要点（供实现阶段撰写，本设计只定范围）：
-- 判断对象：BRD/PRD/SDD/Benchmark 是否为结构化文档内容，而不是"我做了什么"的叙述文字（直接引用 `docs/todo/validator-test-script-narrative-output-issue.md` 记录的真实案例作为反面教材）。
+- 判断对象：BRD/PRD/SDD/Benchmark 是否为结构化文档内容，而不是"我做了什么"的叙述文字（直接引用 `docs/done/validator-test-script-narrative-output-issue.md` 记录的真实案例作为反面教材）。
 - 判断对象二：产出是否跟 goal_text 语义一致（复用 `_prd_consistency_verify_fn` 已经建立的"内部矛盾检测"思路，但这次是跨文档一致性，不是单文档内部一致性）。
 - 输出格式：必须以 `VERDICT: PASS|FAIL|INCONCLUSIVE` 收尾（复用 `_parse_verdict_line` 的既有解析约定，不新发明格式）。
 - 明确"只读，不改文件"——跟 `qa-task-validation` 的既有措辞风格一致。
@@ -7,7 +7,7 @@
  
 **2026-08-13 §2.1/§2.2 已实施**：`work_graph_run.org_node` 列彻底删除，`ux_work_graph_run_active` 收紧为 `UNIQUE(task_id) WHERE status NOT IN ('done', 'failed')`（'blocked' 故意算作活跃——恢复一个 blocked 的 run 现在总是走 `append_to_run_id` 追加进同一行，不会再 INSERT 新行）。新迁移函数 `schema.migrate_drop_work_graph_run_org_node()`（内部先幂等调用 `migrate_relax_org_node_constraints()`，再做 create-copy-drop-rename，`PRAGMA foreign_keys=OFF` 全程包裹，理由同 `migrate_add_reviewing_planner_output_status` 的真实重启事故记录——`work_graph_run` 是被多张表 REFERENCES 的父表）已接入 `backend_server.py::_ensure_schema()`。下游改动：`work_graph_plan.py`/`work_graph_fork.py`（含 `create_fork()`/`_reconstruct_build_prompt()`/`execute_fork()`，`fork_info["org_node"]` 改名 `fork_info["subagent_type"]`，源节点自己的执行身份）/`root_cause_trace.py` 的三处 INSERT 全部去掉 `org_node` 列；`work_graph_run_query.py`（`list_work_graph_runs`/`get_work_graph_run`）与 `task_query.py::get_task` 的返回形状从单值 `"org_node"` 改成 `"org_nodes_involved"`（从 `work_node_execution.subagent_type` 去重派生的列表，`org_node=` 查询参数语义从等值匹配改成 EXISTS 子查询），前端 `frontend/app.js` 对应改造（`getLatestRunForOrgNode`/`orgNodesLabel`/`renderOrgGraphTopology` 等消费点全部改用列表语义）。发现一处设计文档本节 §2.1.3 没预料到的遗漏点：`task_query.py::get_task` 也有同样的单值 `org_node` 读取，一并修完。`root_cause_trace.py::judge_root_cause_via_work_graph` 的 INSERT 有一个已知、记录在代码注释里的边界情况：索引收紧后，若这个函数被调到时对应 task 已有一个仍处于活跃/blocked 状态的共享 run，会撞索引——目前不是真实风险（这个函数唯一的调用方 `org_level_loop.run_fix_loop` 只在一个已经不可达的分支里被调用，且它自己的测试夹具里对应 task 从未预先插入过 work_graph_run 行），但如果未来重新接上这条路径需要重新评估。`python3 -m unittest discover -s src`（768 tests）+ `discover -s supervisor`（126 tests）+ 4 个 frontend smoke test 全绿。
  
-**2026-08-13 §7.1 已实施**：新增 `skills/work-graph-node-review/SKILL.md`——判断"自规划 Work Graph 节点（Coder/Validator/planner_reviewer 自己规划出的、声明 `judgment.kind="llm"` 的节点）的产出是不是真的、结构化的",不是叙述文字冒充产出;吸收了 `docs/todo/validator-test-script-narrative-output-issue.md` §6 的根因分析和 `_NARRATION_RETRY_HINT`（条件句而非断言句）的措辞教训,并明确跟 `planner-output-review`（Planner 固定文档链、任务级、Coder 开始前把关）、`qa-task-validation`（任务级整体验收）、`skill-defect-remediation`（改 Skill 文件本身）三者的边界——判断粒度是"这一个自规划节点",不是文档链/整任务/Skill 文件。已挂到 `roles/planner_reviewer`、`roles/coder`、`roles/validator` 三个 `role.json` 的 `skills` 列表（各追加一行，如 §9 核对清单当时预判）。未修改 `.claude/agents/*.md`——那是 `agent_profile.deploy_agent_definitions()` 从 `role.json` 编译出的部署产物，由 Deploy Supervisor 在真实 cutover 时重新生成，不是手动跟 `role.json` 同步维护的（观察到现有 `.claude/agents/coder.md` 已经缺了更早前 Phase 2a 加的 `design-dynamic-work-graph`，印证这个文件本来就不是手动保持同步的）。`python3 -m unittest discover -s src`（768 tests，含 `test_agent_profile.py`）全绿。
+**2026-08-13 §7.1 已实施**：新增 `skills/work-graph-node-review/SKILL.md`——判断"自规划 Work Graph 节点（Coder/Validator/planner_reviewer 自己规划出的、声明 `judgment.kind="llm"` 的节点）的产出是不是真的、结构化的",不是叙述文字冒充产出;吸收了 `docs/done/validator-test-script-narrative-output-issue.md` §6 的根因分析和 `_NARRATION_RETRY_HINT`（条件句而非断言句）的措辞教训,并明确跟 `planner-output-review`（Planner 固定文档链、任务级、Coder 开始前把关）、`qa-task-validation`（任务级整体验收）、`skill-defect-remediation`（改 Skill 文件本身）三者的边界——判断粒度是"这一个自规划节点",不是文档链/整任务/Skill 文件。已挂到 `roles/planner_reviewer`、`roles/coder`、`roles/validator` 三个 `role.json` 的 `skills` 列表（各追加一行，如 §9 核对清单当时预判）。未修改 `.claude/agents/*.md`——那是 `agent_profile.deploy_agent_definitions()` 从 `role.json` 编译出的部署产物，由 Deploy Supervisor 在真实 cutover 时重新生成，不是手动跟 `role.json` 同步维护的（观察到现有 `.claude/agents/coder.md` 已经缺了更早前 Phase 2a 加的 `design-dynamic-work-graph`，印证这个文件本来就不是手动保持同步的）。`python3 -m unittest discover -s src`（768 tests，含 `test_agent_profile.py`）全绿。
  
 **Phase 2c 至此全部完成**（§2.1/§2.2/§6 Validator 自规划改造/§7.1 均已实施；§7.2 收口分析已完成，决定不改代码，见上文）。**2026-08-08 修订**：写作过程中，需求文档 §7 的四个开放问题已被用户直接拍板（详见该文档 §7 对应条目），其中两条推翻了本文档最初的设计判断——Coder/Validator 自规划改为"建议节点清单"而非完全自由（§3），`work_graph_run.org_node` 改为彻底移除而非保留（§2.1）——本版本已按拍板结果改写，不是原始草稿。**2026-08-08 追加**（同日，见需求文档新增 §3.1）：FR-4 的目标被明确为"失败即进化"完整方法论（判断失败 → Reflection-review 动态诊断 → 系统性缺陷则先 Fix-Skill → 跳回执行），当时 §5 设计的 `dynamic_loop_back` 只覆盖第 1/2/4 步，第 3 步（Fix-Skill）是已知缺口。**2026-08-12 补齐**：§5 已扩写为完整四步设计（§5.4 Reflection-review 现在同时判断目标节点和缺陷性质，§5.5 新增 Fix-Skill，真实调用既有但从未真正投入使用的 `skill_update.py::update_skill()`），过程中发现两个既有事实（`skills:` frontmatter 只按名字动态加载内容、不需要重新部署；`org_level_loop.py` 的 `_ROUTE_FOR_CATEGORY` 从来没有 `skill_defect` 这个 key，`update_skill()` 在这个代码库里投产以来从未被真正调用过）——详见 §5 开头。由哪个身份执笔改 Skill 已通过 `AskUserQuestion` 确认（2026-08-12）：统一用 Validator，见 §5.5。
  
@@ -2,7 +2,7 @@
  
 **鏃ユ湡**: 2026-08-07锛堟渶鍚庢洿鏂 2026-08-13锛
 **鎬ц川**: 闂璁板綍鈥斺旀簮浜庣湡瀹炵敓浜у鐜帮紝鏍瑰洜宸插畾浣嶏紙搂6锛夛紝宸茶惤鍦颁袱杞紦瑙ｏ紙搂7/搂8锛夛紝缁撴瀯鎬т慨澶嶆帹杩熷埌鍙︿竴浠芥枃妗ｏ紙瑙佹椂闂寸嚎绗 6 杞級銆
-**鐘舵**: 鏍瑰洜宸插畾浣嶃傚綋鍓嶇敓浜х姸鎬侊細test_script/validator_test_script 鑺傜偣宸茬鐢紙搂8锛夛紝`_NARRATION_RETRY_HINT` 缂撹В浠ｇ爜淇濈暀浣嗗綋鍓嶄笉浼氳Е鍙戯紙搂7锛夈**缁撴瀯鎬т慨澶嶄笉鍦ㄦ湰鏂囨。鑼冨洿**鈥斺斿凡骞跺叆 `docs/done/org-graph-unification-and-universal-self-planning-requirements.md` Phase 2锛團R-2/FR-3锛孋oder 鎺ュ叆鑷鍒掓椂涓骞跺鐞嗭紝璇ユ枃妗ｉ潪鐩爣 搂5.2 璁板綍浜嗚繖鏉″凡鐭ュ鍙戦闄╋級銆**2026-08 Coder 鑷鍒掑満鏅笓椤瑰鏍革細鏈鐜**锛堟椂闂寸嚎绗 8 杞級鈥斺旂湡瀹為潪 self-target 浠诲姟锛孋oder 鑷鍒掑嚭鐨"鍏堟帰绱€佸啀浜у嚭瀹¤鎶ュ憡"鍐呭鍨嬭妭鐐癸紝浜у嚭鏄湡瀹炪佸叿浣撱侀愯寮曠敤璇佹嵁鐨勫璁″彂鐜帮紝涓嶆槸绌烘礊鍙欒堪锛涚粏鑺傝绗 8 杞
+**鐘舵**: 鉁 鏍瑰洜宸插畾浣嶃佺粨鏋勬т慨澶嶅凡钀藉湴锛026-08-13锛夈**搂8 璁板綍鐨"鐩存帴绂佺敤"宸茶 2026-08-08 鑷鍒掓敼閫 + Phase 2 鑷鍒掓敼閫犳暣浣撳彇浠ｏ紝涓嶅啀鏄綋鍓嶇敓浜х姸鎬**鈥斺攖est_script 鏄惁闇瑕佽繖涓妭鐐癸紝鐜板湪鏄 Planner锛坄_PLANNER_NODE_CATALOG`锛夈丆oder锛坄_CODER_NODE_CATALOG`锛夈乂alidator锛坄_VALIDATOR_NODE_CATALOG`锛変笁涓 org agent 鍚勮嚜鍦ㄨ嚜瑙勫垝闃舵鎸 goal 鑷鍒ゆ柇鐨勫缓璁」涔嬩竴锛圠LM 鍐冲畾瑕佷笉瑕佽鍒掑嚭杩欎釜鑺傜偣锛屼笉鏄浐瀹氬繀椤汇佷篃涓嶆槸纭紪鐮佺鐢級锛屼笉鍐嶆湁浠讳綍"杩欎釜鑺傜偣绫诲瀷琚暣浣撳叧闂"鐨勬満鍒垛斺擿check_script_compiles()` 鏈烘鎷︽埅缃 + `_NARRATION_RETRY_HINT` 绾犲亸鎻愮ず瀵逛笁杈归兘鐢熸晥銆俙_NARRATION_RETRY_HINT` 缂撹В浠ｇ爜瑙 搂7銆**2026-08 Coder 鑷鍒掑満鏅笓椤瑰鏍革細鏈鐜**锛堟椂闂寸嚎绗 8 杞級鈥斺旂湡瀹為潪 self-target 浠诲姟锛孋oder 鑷鍒掑嚭鐨"鍏堟帰绱€佸啀浜у嚭瀹¤鎶ュ憡"鍐呭鍨嬭妭鐐癸紝浜у嚭鏄湡瀹炪佸叿浣撱侀愯寮曠敤璇佹嵁鐨勫璁″彂鐜帮紝涓嶆槸绌烘礊鍙欒堪锛涚粏鑺傝绗 8 杞
  
 **鏇存柊鏃堕棿绾**锛堝帇缂╄嚜鍘熷厛鍏疆鍒嗘暎鏇存柊锛026-08-08锛夛細
  
@@ -16,6 +16,7 @@
 | 6 | 08-08 | 缁撴瀯鎬т慨澶嶇殑钀借剼鐐圭‘瀹氫负 `org-graph-unification-and-universal-self-planning-requirements.md` Phase 2鈥斺旇鏂囨。闈炵洰鏍 搂5.2 宸茶褰曡繖鏉″凡鐭ラ闄╋紝瑕佹眰 Phase 2 钀藉湴鏃朵笓闂ㄩ獙璇佹槸鍚﹀鐜般 |
 | 7 | 08-12 | **Phase 1 鐪熷疄绔埌绔獙璇佹湡闂翠笁娆＄嫭绔嬪鐜帮紝杩涗竴姝ュ潗瀹炵 5 杞殑鍒ゆ柇**锛氶獙璇 `org-graph-unification-phase1-review-gate-design.md` 钀藉湴鏁堟灉鏃讹紝`run_end_to_end()` 璧板畬鏁 Planner 鑷鍒掗摼璺紝杩炵画 3 娆＄湡瀹炶繍琛屻 涓笉鍚 goal锛屽叏閮ㄦ挒涓婂悓涓绫诲け璐モ斺(a) "add(a,b) 姹傚拰" goal锛歚benchmark_add` 鑺傜偣 `loop_back` 鑰楀敖 `max_attempts=2`锛(b) "shout(s) 杞ぇ鍐" goal锛歚test_script_shout` 鑺傜偣鍚屾牱鑰楀敖 `max_attempts=2`锛(c) 鎺ュ叆鐪熷疄鐢熶骇 backend_server锛堥噸鍚悗锛岃 `bd1404d` 鐨 FK 杩佺Щ淇锛夈佽蛋鐪熷疄 API 鍒涘缓鐨 "reverse_words(s)" goal锛坱ask `b4892aae-8a44-4a33-a53e-7521838baef5`锛夛細`benchmark` 鑺傜偣杩炵画涓よ疆琚 judge 鎷掔粷锛"material given is a narrative summary of scenario categories and counts... rather than actual scenario content with real input/expected-output pairs"锛夛紝绗簩杞殑 judge 鍙嶉鐢氳嚦绮剧‘鎸囧嚭"this same narrative-summary content class was already rejected once before for this goal"锛宍loop_back` 浠嶇劧鍘熸牱澶嶇幇锛屾渶缁 `task.status` correctly 钀藉埌 `blocked_pending_human`锛坄blocked_reason='prd_consistency_check_failed'`锛岃蛋鐨勬槸鏃㈡湁 `ConsistencyCheckFailedError` 璺敱锛屼笉鏄 Phase 1 鏂板鐨 `planner_review_loop_limit_reached`鈥斺斿洜涓哄け璐ュ彂鐢熷湪 `plan_documents()` 鍐呴儴锛宍planner_reviewer` 鏈韩鏍规湰娌¤瑙﹀彂鍒帮級銆備笁娆″鐜板叏閮ㄨ窡 Phase 1 鏈韩鐨勬敼鍔ㄦ棤鍏筹紙`plan_documents()` 鏄棦鏈変唬鐮侊紝鏈敼鍔級锛屼絾纭浜嗙 5 杞"瑙﹀彂鏉′欢鏄'浠诲姟闇涓嶉渶瑕佹ā鍨嬪厛缁欏嚭鍙垽瀹氱殑鍏蜂綋鍦烘櫙'锛屼笉鏄'鑺傜偣绫诲瀷鏄笉鏄 test_script'"鐨勫垽鏂斺斿嵆浣挎槸"瀹炵幇涓涓函鍑芥暟+鍗曟祴"杩欑鍑犱箮涓嶉渶瑕佹帰绱㈢湡瀹炰唬鐮佺殑鏋佺畝 goal锛屼篃浼氳璇卞鎴"鍙欒堪鍦烘櫙绫诲埆鍜屾暟閲忕殑鎬荤粨"鑰屼笉鏄"鍏蜂綋杈撳叆杈撳嚭瀵"銆 涓柊浠诲姟閲岋紝(a)(b) 鏄湰鍦颁复鏃朵粨搴擄紝(c) 鏄湡瀹炵敓浜 task锛堜繚鐣欏湪 `~/.graphlemon/graphlemon.db` 閲屾湭娓呯悊锛屼緵鍚庣画澶嶆牳锛夈 |
 | 8 | 08-13 | **Coder 鑷鍒掑満鏅笓椤瑰鏍革紙Org Graph unification Phase 2 钀藉湴鍚庯級锛岀湡瀹為潪 self-target 浠诲姟锛屾湭澶嶇幇**锛氫负闅旂"self-hosting 璇嶆眹姹℃煋"杩欎釜娣锋穯鍙橀噺锛屼笓闂ㄦ瀯閫犱簡涓涓叏鏂扮殑 tempfile 涓存椂 git 浠撳簱锛堜笉鏄 graphlemon 鑷繁锛夛紝绉嶅叆涓涓湡瀹炵殑銆佸甫涓涓簿蹇冭璁＄殑娴偣鎴柇 bug 鐨 `token_bucket.py`锛坄_refill()` 鐢 `int(elapsed * refill_rate)` 鎴柇灏忔暟 token 涓旀妸涓㈠純鐨勫皬鏁颁綑閲忕畻杩 `_last_refill = now`锛屽鑷村皬鏁 `refill_rate` 鍦烘櫙绯荤粺鎬у皯鍙 token锛夈俫oal 鏄庣‘瑕佹眰"鍏堣鎳傚凡鏈変唬鐮併佸啀浜у嚭涓浠界函瀹¤鎶ュ憡"锛坄docs/token_bucket_audit.md`锛屽惈璁捐璇存槑/閫愭潯闂璇佹嵁/淇寤鸿涓夋锛夛紝鏄 搂6.2 鏍瑰洜缁撹閲"鍏堟帰绱€佸啀浜у嚭鍐呭"杩欎釜瑙﹀彂鏉′欢鐨勭洿鎺ユ瀯閫犮傜洿鎺ヨ皟鐢ㄧ敓浜т唬鐮佽矾寰 `work_graph_plan.plan_work_graph(conn, "coder", ...)` + `work_graph_orchestrate.run_graph()`锛堣窡 `e2e_pipeline.implement_code()` 鍐呴儴璋冪敤搴忓垪瀹屽叏涓鑷达紝鍙槸鐪佺暐浜嗗畠澶栧眰鐨 code_diff/test_report 鍖呰锛屼究浜庣洿鎺ヨ姣忎釜鑷鍒掕妭鐐圭殑鍘熷 `content`锛夈**缁撴灉**锛欳oder 鑷鍒掑嚭鍗曡妭鐐瑰浘 `audit_token_bucket`锛坄node_type="impl"`锛夆斺斿嵆浣 `_CODER_NODE_CATALOG` 鐨 `impl` 鐩綍鏉＄洰鏈韩娌℃湁 `suggested_judgment`锛岃鍒 LLM 浠嶇劧鑷繁缁欒繖涓妭鐐瑰０鏄庝簡 `judgment.kind="llm"`锛宍judge_prompt` 鏂囧瓧鏄庣‘閽堝"narrative description of an action taken...standing in for the real content itself"锛堣窡 `_NODE_REVIEW_JUDGE_PROMPT`/`work-graph-node-review` skill 鐨勬柟娉曡楂樺害涓鑷达紝璇存槑璇 skill 鎸傝浇鍒 coder 瑙掕壊鍚庣‘瀹炲湪褰卞搷鑷鍒掕涓猴級锛屽鍔 `on_fail: retry_self`銆傜湡瀹炴墽琛屽悗锛坄work_node_execution` 琛ㄥ彧鏈変竴琛 `status='done'`锛屾病鏈 `-reflect` 閲嶈瘯琛岋紝璇存槑绗竴娆″皾璇曞氨閫氳繃浜嗚繖涓嚜鍔犵殑 LLM judge锛夛細`content` 瀛楁鏄"The graphlemon coder workflow finished 鈥 it audited `token_bucket.py`...`"寮澶达紙杩欏彞寮鍦虹櫧鎺緸璺熷巻鍙插彊杩颁簨鏁呯殑"The ... workflow completed"楂樺害鐩镐技锛屾槸涓涓畫鐣欑殑鏂囦綋灏惧反锛屽煎緱璁板綍锛夛紝浣嗙揣璺熺潃鏄 5 鏉″叿浣撳埌琛屽彿锛堝"L21-27"锛夈佸甫鍙繍琛屽鐜拌剼鏈瘉鎹紙濡"`refill_rate=2.5` 鏃剁悊璁哄簲鍙 25 涓 token锛屽疄娴嬩粎 20 涓"锛夈侀愭潯缁欏嚭淇寤鸿鐨勭湡瀹炲彂鐜扳斺斾笉鏄┖娲炲彊杩板啋鍏呬骇鍑恒傜鐩樹笂鐨勭湡瀹炰氦浠樼墿 `docs/token_bucket_audit.md`锛.5K+ 瀛楋級鍚屾牱鏄粨鏋勫畬鏁达紙涓夋寮忥級銆侀愭潯寮曠敤鐪熷疄浠ｇ爜琛/鐗囨浣滀负璇佹嵁鐨勫璁℃姤鍛婏紝绮剧‘鍛戒腑浜嗛鍏堝煁鍏ョ殑鎴柇 bug锛屽彟澶栬繕鍙戠幇浜 4 涓湭棰勮鐨勭湡瀹為棶棰橈紙璐熸暟 `n` 缁曡繃瀹归噺涓婇檺銆佹瀯閫犲嚱鏁版棤鍙傛暟鏍￠獙銆侀潪鍗曡皟鏃堕挓鍥炴嫧鍐荤粨鍒锋柊銆佸叕寮灞炴ф棤骞跺彂淇濇姢锛夈**缁撹**锛氳繖娆＄湡瀹為潪 self-target 澶嶆牳閲岋紝`content` 瀛楁鐨"浣撹"浠嶆湁鍘嗗彶鍙欒堪浜嬫晠鐨勬帾杈炵棔杩癸紙寮鍦虹櫧锛夛紝浣嗘病鏈夊鐜"鍐呭鏁翠綋琚彊杩版枃瀛楁浛浠ｃ佺湡瀹炰氦浠樼墿缂哄け"杩欎釜鏍稿績澶辫触妯″紡鈥斺旂湡瀹炰氦浠樼墿瀛樺湪銆佸叿浣撱佸彲楠岃瘉锛沗_CODER_NODE_CATALOG` 鐨 `impl` 鏉＄洰铏界劧鏈韩缂 `suggested_judgment`锛屼絾 Phase 2c 鏂板鐨 `work-graph-node-review` skill + `_NODE_REVIEW_JUDGE_PROMPT` 鐨勬柟娉曡宸茬粡澶栨孩鍒拌嚜鐢辫鍒掗樁娈碉紝瑙勫垝 LLM 浼氳嚜鍙戠粰鍐呭鍨嬭妭鐐硅ˉ涓閬撶瓑浠风殑鍙嶅彊杩 judgment锛屼笉鏄畬鍏ㄦ病鏈夐槻绾裤傛牱鏈噺涓 1 娆＄湡瀹炶繍琛岋紙鐢ㄦ埛浠呮槑纭悓鎰"璺戜竴娆"锛夛紝缁撹缃俊搴︽湁闄愶紝涓嶆帓闄や綆姒傜巼浠嶄細澶嶇幇鈥斺斿鏋滃悗缁敓浜х湡瀹炰换鍔￠噷鍐嶇湅鍒拌繖绫昏妭鐐瑰鐜板彊杩版 `content`锛屽簲閲嶆柊璇勪及瑕佷笉瑕佹妸 `_NODE_REVIEW_JUDGE_PROMPT` 鐩存帴鎺ュ埌 `impl` 鐩綍鏉＄洰鐨 `suggested_judgment` 涓婏紙鑰屼笉鏄畬鍏ㄤ緷璧栬鍒 LLM 鑷効澹版槑锛夈傚鏍歌剼鏈湭鍏ュ簱锛堜竴娆℃ч獙璇侊紝鏈浐鍖栦负鍥炲綊娴嬭瘯锛夛紝鏈疆鏈慨鏀逛换浣曠敓浜т唬鐮併 |
+| 9 | 08-13 | **鐢ㄦ埛鎸囧嚭 搂8 鐨"鏁翠綋绂佺敤"妗嗘灦宸茬粡涓嶅噯纭紝瑕佹眰鍘绘帀**锛氭牳瀹炲悗纭 Planner锛坄_PLANNER_NODE_CATALOG`锛夈乂alidator锛坄_VALIDATOR_NODE_CATALOG`锛夌殑鑷鍒掔洰褰曢噷 test_script 鏃╁凡鏄缓璁」锛堝垎鍒槸 08-08 鑷鍒掓敼閫犮丳hase 2c 钀藉湴鏃跺姞鍥炲幓鐨勶級锛屽敮鐙 Coder 鐨 `_CODER_NODE_CATALOG` 涓鐩存病鏈夎繖涓夐」鈥斺斾笉鏄"鏁呮剰璺宠繃"锛屾槸 Phase 2b 褰撳垵鍙粰浜 impl/unit_test/integration_check 涓夐」锛屾病浜哄啀琛ャ**淇**锛氱粰 `_CODER_NODE_CATALOG` 鏂板 `test_script` 寤鸿鏉＄洰锛坄suggested_judgment: {"kind": "mechanical", "check_ref": "check_script_compiles"}`锛岃窡 Validator 閭ｄ唤鍚屾鏈烘鎷︽埅缃戯級锛岃嚦姝や笁涓 org agent 鐨勮嚜瑙勫垝鐩綍閲 test_script 閮芥槸鍙夊缓璁」锛屼笉鍐嶆湁浠讳綍"杩欎釜鑺傜偣绫诲瀷琚暣浣撳叧闂"鐨勬満鍒躲傚悓姝ユ洿鏂版湰鏂囨。椤堕儴鐘舵佽鍜 搂8锛屾爣娉"鏁翠綋绂佺敤"鐘舵佸凡琚彇浠ｏ紝涓嶅啀鏄綋鍓嶇敓浜ц涓猴紙淇濈暀 搂8 鍘熸枃浣滀负鍐崇瓥閾捐矾鐨勭湡瀹炶褰曪級銆 |
  
 鍚庣画璁ㄨ鏂瑰悜璁板湪 `docs/done/org-graph-unification-and-universal-self-planning-requirements.md`锛堝師鑽夋 `org-graph-as-work-graph-unified-loop-requirements.md` 宸插苟鍏ユ鏂囨。骞跺垹闄わ級鈥斺斿寘鎷涓嶈缁 benchmark 涔熷姞涓涓被浼肩殑鍚彂寮忔満姊版鏌ャ佷互鍙婅涓嶈鍦 Coder 寮濮嬪疄鐜颁箣鍓嶅 Planner 浜у嚭澶氫竴閬撶嫭绔嬪鏍革紙鍚庤呭凡鍦ㄨ鏂囨。 Phase 1 SDD `docs/done/org-graph-unification-phase1-review-gate-design.md` 钀藉湴涓哄叿浣撹璁★級銆
  
@@ -99,7 +100,14 @@ self-hosting 鍦烘櫙锛坄target_folder_path` 鏄 graphlemon 鑷繁锛夊湪杩欎釜鏈哄
  
 ## 8. 宸插疄鐜帮紙2026-08-07锛岀浜屾鍐崇瓥锛夛細鐩存帴绂佺敤 test_script/validator_test_script 鑺傜偣
  
-鐢ㄦ埛鍐崇瓥锛氫笌鍏剁户缁湪鎻愮ず璇嶅眰闈㈡墦琛ヤ竵锛堢 7 鑺傜殑缂撹В宸茬粡璇佹槑鏈夋晥鎬ф棤娉曞湪涓嬫鐪熷疄澶嶇幇鍓嶇‘璁わ級,涓嶅鍏堟妸杩欎袱涓妭鐐逛粠鍥鹃噷鐩存帴鍘绘帀,鍚庣画鐪熺殑鏈夐渶姹傚啀閲嶆柊璁捐,鑰屼笉鏄"鎵鏈 goal 浠诲姟閮藉浐瀹氭湁杩欎釜鑺傜偣"銆傝繖涔熺壍鍑轰竴涓洿澶х殑鏋舵瀯闂锛歅lanner 鑷繁鐨勬枃妗ｉ摼锛坄work_graph_plan._PROMPT_TEMPLATE`锛夎櫧鐒惰繃浜嗕竴灞傜湡瀹炵殑 LLM 瑙勫垝璋冪敤,浣嗚繖娆¤皟鐢ㄧ殑鎻愮ず璇嶇‖缂栫爜瑕佹眰"蹇呴』涓 brd/prd/sdd/benchmark/test_dataset/test_script 鍚勫嚭涓涓妭鐐"鈥斺旀槸涓涓浐瀹氭灦鏋勫父閲忥紙2026-08-06 鐨勬棦鏈夎璁″喅瀹氾紝瑙 `docs/done/dynamic-work-graph-design-skill-design.md 搂3`锛,涓嶆槸鐪熺殑鐢 LLM 鎸 goal 鑷敱鍐冲畾鑺傜偣銆俈alidator 鑷繁鐨勯獙璇侀摼锛坄_VALIDATOR_MANIFEST`锛夋洿褰诲簳,杩"杩囦竴灞 LLM 瑙勫垝"閮芥病鏈,鏄‖缂栫爜鐨 Python 瀛楅潰閲忋傜湡姝"LLM 鑷繁鍐冲畾瑕佸嚑涓妭鐐"鐨勮兘鍔涘凡缁忓瓨鍦ㄤ簬 `_GENERIC_PROMPT_TEMPLATE`锛堢粰 Coder/Validator 鍏朵粬瀛愪换鍔＄敤),浣嗘病鏈夌敤鍦ㄨ繖涓ゆ潯鏂囨。閾句笂鈥斺旀槸鍚﹁鎶婅繖鏉¤兘鍔涗篃鐢ㄥ埌 Planner/Validator 鑷繁鐨勬枃妗ｉ摼涓,鏄竴涓洿澶х殑銆侀渶瑕佸崟鐙喅绛栫殑鍚庣画鏂瑰悜,涓嶅湪鏈鏀瑰姩鑼冨洿鍐呫
+**鈿狅笍 鏈妭璁板綍鐨"鏁翠綋绂佺敤"鐘舵佸凡浜 2026-08-13 琚嚜瑙勫垝鏀归犲彇浠ｏ紝涓嶄唬琛ㄥ綋鍓嶇敓浜ц涓**鈥斺斾繚鐣欐湰鑺傛槸涓轰簡鐣欎笅鍐崇瓥
+閾捐矾鐨勭湡瀹炶褰曪紝涓嶆槸鍥犱负杩欎釜绂佺敤鐘舵佽繕鐢熸晥銆傚綋鏃剁鐢ㄧ殑瀵硅薄锛坄_PROMPT_TEMPLATE` 鍥哄畾瑕佹眰鐨勬枃妗ｉ摼銆
+`_CANONICAL_DOC_CHAIN`銆乣e2e_pipeline._VALIDATOR_MANIFEST` 纭紪鐮 manifest锛夋湰韬湪鍚庣画鐨 2026-08-08 鑷鍒掓敼閫
+锛堟湰鑺備笅鏂瑰氨宸茬粡鎻愬埌"鐪熸 LLM 鑷繁鍐冲畾瑕佸嚑涓妭鐐圭殑鑳藉姏"锛夊拰 Org Graph unification Phase 2 閲岃鏁翠綋鏇挎崲鎺変簡鈥斺
+`_CANONICAL_DOC_CHAIN`/`_VALIDATOR_MANIFEST` 鐜板湪宸茬粡涓嶅瓨鍦ㄤ簬鐢熶骇浠ｇ爜璺緞锛堝悗鑰呬繚鐣欎竴浠芥湭浣跨敤鐨勫巻鍙蹭唬鐮侊紝
+浠呬緵鍙傝冿級銆傚綋鍓嶇姸鎬佽鏂囨。椤堕儴鐘舵佽鍜岀 9 鑺傘
+
+鐢ㄦ埛鍐崇瓥锛堝師濮嬭褰曪紝2026-08-07锛夛細涓庡叾缁х画鍦ㄦ彁绀鸿瘝灞傞潰鎵撹ˉ涓侊紙绗 7 鑺傜殑缂撹В宸茬粡璇佹槑鏈夋晥鎬ф棤娉曞湪涓嬫鐪熷疄澶嶇幇鍓嶇‘璁わ級,涓嶅鍏堟妸杩欎袱涓妭鐐逛粠鍥鹃噷鐩存帴鍘绘帀,鍚庣画鐪熺殑鏈夐渶姹傚啀閲嶆柊璁捐,鑰屼笉鏄"鎵鏈 goal 浠诲姟閮藉浐瀹氭湁杩欎釜鑺傜偣"銆傝繖涔熺壍鍑轰竴涓洿澶х殑鏋舵瀯闂锛歅lanner 鑷繁鐨勬枃妗ｉ摼锛坄work_graph_plan._PROMPT_TEMPLATE`锛夎櫧鐒惰繃浜嗕竴灞傜湡瀹炵殑 LLM 瑙勫垝璋冪敤,浣嗚繖娆¤皟鐢ㄧ殑鎻愮ず璇嶇‖缂栫爜瑕佹眰"蹇呴』涓 brd/prd/sdd/benchmark/test_dataset/test_script 鍚勫嚭涓涓妭鐐"鈥斺旀槸涓涓浐瀹氭灦鏋勫父閲忥紙2026-08-06 鐨勬棦鏈夎璁″喅瀹氾紝瑙 `docs/done/dynamic-work-graph-design-skill-design.md 搂3`锛,涓嶆槸鐪熺殑鐢 LLM 鎸 goal 鑷敱鍐冲畾鑺傜偣銆俈alidator 鑷繁鐨勯獙璇侀摼锛坄_VALIDATOR_MANIFEST`锛夋洿褰诲簳,杩"杩囦竴灞 LLM 瑙勫垝"閮芥病鏈,鏄‖缂栫爜鐨 Python 瀛楅潰閲忋傜湡姝"LLM 鑷繁鍐冲畾瑕佸嚑涓妭鐐"鐨勮兘鍔涘凡缁忓瓨鍦ㄤ簬 `_GENERIC_PROMPT_TEMPLATE`锛堢粰 Coder/Validator 鍏朵粬瀛愪换鍔＄敤),浣嗘病鏈夌敤鍦ㄨ繖涓ゆ潯鏂囨。閾句笂鈥斺旀槸鍚﹁鎶婅繖鏉¤兘鍔涗篃鐢ㄥ埌 Planner/Validator 鑷繁鐨勬枃妗ｉ摼涓,鏄竴涓洿澶х殑銆侀渶瑕佸崟鐙喅绛栫殑鍚庣画鏂瑰悜,涓嶅湪鏈鏀瑰姩鑼冨洿鍐呫
  
 **鍏蜂綋鏀瑰姩**锛
 - `src/work_graph_plan.py::_PROMPT_TEMPLATE`锛氫笉鍐嶈姹 test_script 鑺傜偣锛堝彧瑕佹眰 brd/prd/sdd/benchmark/test_dataset 5 涓級銆
@@ -8,7 +8,7 @@
  
 ### 1.1 现状：三条独立的、能力有限的机制
  
-- **Planner 自己的文档链**（`work_graph_plan.py::_PROMPT_TEMPLATE`）：过一层真实的 LLM 规划调用，但提示词硬编码要求"必须为 brd/prd/sdd/benchmark/test_dataset 各出一个节点"（test_script 已于 2026-08-07 从这个固定清单里移除，见 `docs/todo/validator-test-script-narrative-output-issue.md`）——节点集合本质是固定的，规划这一步只是在确认依赖关系，不是真的自由决策"要不要有某个节点"。这是 2026-08-06 的一次明确设计决定（`docs/done/dynamic-work-graph-design-skill-design.md` §3 原话："不是让 Claude 完全自由决定 Planner 要生成哪些节点——Planner 那条链是'架构常量'"）。
+- **Planner 自己的文档链**（`work_graph_plan.py::_PROMPT_TEMPLATE`）：过一层真实的 LLM 规划调用，但提示词硬编码要求"必须为 brd/prd/sdd/benchmark/test_dataset 各出一个节点"（test_script 已于 2026-08-07 从这个固定清单里移除，见 `docs/done/validator-test-script-narrative-output-issue.md`）——节点集合本质是固定的，规划这一步只是在确认依赖关系，不是真的自由决策"要不要有某个节点"。这是 2026-08-06 的一次明确设计决定（`docs/done/dynamic-work-graph-design-skill-design.md` §3 原话："不是让 Claude 完全自由决定 Planner 要生成哪些节点——Planner 那条链是'架构常量'"）。
 - **`_GENERIC_PROMPT_TEMPLATE`**（同文件，服务 Coder/Validator 的子任务图）：真正让 LLM 自由规划 `{node_id, depends_on, task_prompt}`，但目前只有 `work_graph_fork.py`（人工发起的 time-travel 调试功能）在用，没有接入任何生产路径的自动执行；且和 Planner 的固定链一样，只是一张纯 DAG，没有判断/回路概念。
 - **`work_graph_orchestrate.py::run_graph()` 的验证-重试机制**：`_verify_and_maybe_regenerate()` 只支持"某节点验证失败 → 原地重新生成同一个节点一次 → 还失败就整体 `ConsistencyCheckFailedError`"。这不是回路——失败结果不会被送回更早的节点，历史反馈也只保留最近一轮（`"; ".join(feedback)` 直接拼进 reflect prompt，不会累积多轮）。
  
@@ -38,7 +38,7 @@
 2. **不回退到 Claude Code 原生 Dynamic Workflow 原语**（见 1.3）。继续在 Python 层的 `work_graph_orchestrate.py` 里扩展执行引擎，保住 REQ-06 断点续跑。
 3. **不追求完全通用的图执行框架**。回路的触发方式限定为"某节点判断失败 → 跳回自己声明的 `on_fail.target_node_id`"，不支持任意节点间的条件分支、多目标跳转、或图结构在运行时被重新规划——这些是更大的能力，不在这轮范围内。
 4. **不重新设计跨 Org 的既有 loop 机制**（`org_level_loop.py`/`org_loop_route.py`：Validator FAIL/INCONCLUSIVE → 判根因 → 路由回 Planner/Coder，`loop_round` 封顶 3 轮）。本需求的回路是"同一个 Org Agent 自己的 Work Graph 内部"这一层，比跨 Org 的 loop 粒度更细，两者独立计数、不共享额度、不互相替代——内层耗尽自己的上限后照旧抛 `ConsistencyCheckFailedError`，外层机制不变地接管。
-5. **不在本需求里解决 test_script/validator_test_script 节点"叙述文字而非代码"的结构性根因**。这个节点已于 2026-08-07 因该问题禁用（`docs/todo/validator-test-script-narrative-output-issue.md`），根因是"探索后收尾习惯"，跟本需求要解决的问题（节点集合是否可以自由规划、失败能否形成回路）完全正交。用户已确认（见「8. 已确认的决策」第 7 条）：Part B 上线后，test_script 可以直接作为可选节点提供给 Planner 自由规划选择，不需要等这个结构性问题修复；该结构性问题的真正修复安排在另一份文档里，跟"给 Coder agent 加入 test_script 模块"一起解决——本需求只负责不阻塞它，不负责修它。
+5. **不在本需求里解决 test_script/validator_test_script 节点"叙述文字而非代码"的结构性根因**。这个节点已于 2026-08-07 因该问题禁用（`docs/done/validator-test-script-narrative-output-issue.md`），根因是"探索后收尾习惯"，跟本需求要解决的问题（节点集合是否可以自由规划、失败能否形成回路）完全正交。用户已确认（见「8. 已确认的决策」第 7 条）：Part B 上线后，test_script 可以直接作为可选节点提供给 Planner 自由规划选择，不需要等这个结构性问题修复；该结构性问题的真正修复安排在另一份文档里，跟"给 Coder agent 加入 test_script 模块"一起解决——本需求只负责不阻塞它，不负责修它。
 6. **不修改现有 `_GENERIC_PROMPT_TEMPLATE` 路径本身**（Coder/Validator 子任务图、`work_graph_fork.py` 用的那条）。如果这轮的 judgment/on_fail 字段设计得足够通用，未来可以顺带让这条路径也受益，但不是本轮的验收范围。
  
 ## 4. 功能需求
@@ -90,7 +90,7 @@
  
 ## 7. 风险与已知权衡
  
-- **用户已知情并接受：Part B 上线后 test_script 类节点可能被自由规划回来，narrative-output 问题可能重现**。`docs/todo/validator-test-script-narrative-output-issue.md` 记录的根因是"探索后收尾习惯"，跟本需求解决的问题（节点集合能不能自由规划、失败能否形成回路）完全正交，本需求不修它。用户决策（「8. 已确认的决策」第 7 条）：不等结构性修复，真正的修复安排在"给 Coder agent 加入 test_script 模块"那份文档里一起解决——本需求上线后，如果自举/真实任务里又复现了叙述文字问题，这是已知的、被接受的风险，不是本需求的回归。
+- **用户已知情并接受：Part B 上线后 test_script 类节点可能被自由规划回来，narrative-output 问题可能重现**。`docs/done/validator-test-script-narrative-output-issue.md` 记录的根因是"探索后收尾习惯"，跟本需求解决的问题（节点集合能不能自由规划、失败能否形成回路）完全正交，本需求不修它。用户决策（「8. 已确认的决策」第 7 条）：不等结构性修复，真正的修复安排在"给 Coder agent 加入 test_script 模块"那份文档里一起解决——本需求上线后，如果自举/真实任务里又复现了叙述文字问题，这是已知的、被接受的风险，不是本需求的回归。
 - **回路能力本身可能被滥用成隐藏的高成本重试**：一个设计不当的 `judgment`（例如过于严格的 LLM 判断标准）配合 `loop_back`，可能导致某个节点反复被打回、消耗大量 token 才勉强通过上限。FR-A5 的按 `(org_node, node 类型)` 可配置上限缓解了"一刀切"的问题，但初始默认值仍需要设计阶段给出具体理由，不能只是"抄一个数字"；上线后应该根据真实调用数据回头调整（这正是选择"DB 配置表"而不是"硬编码常量"的原因）。
 - **Part B 是对已有架构决定的正式推翻**，不是渐进式增强。`docs/done/dynamic-work-graph-design-skill-design.md` §3 需要在 Part B 实施后同步更新，避免文档和代码再次出现本 session 里多次遇到的"文档记录的意图与实际代码不一致"的问题。
 - **Part A + Part B 一并实施（已确认，见「8. 已确认的决策」第 5 条），没有中间的"仅 Part A 先跑一段时间验证稳定性"的缓冲阶段**——意味着 Part A 的回路引擎第一次被真实使用，就是在"节点集合本身也是自由规划、不受固定链条约束"这个更不可预测的场景下，两个新变量同时引入，出问题时定位"是回路引擎的 bug 还是自由规划出了一个奇怪的图结构"会比分阶段更难。这是用户已知情的权衡，不是本需求遗漏。
@@ -21,7 +21,7 @@ tags:
  
 ## 判断对象一:是否为真实结构化内容,而不是叙述文字冒充产出
  
-**真实反面案例**(`docs/todo/validator-test-script-narrative-output-issue.md` 记录的实际复现,同样的措辞模式在多个任务、多次独立触发中稳定重现):
+**真实反面案例**(`docs/done/validator-test-script-narrative-output-issue.md` 记录的实际复现,同样的措辞模式在多个任务、多次独立触发中稳定重现):
  
 - `"Launched the 'graphlemon-node-...' workflow (Work Node validator) in the background, run ID wf_.... It's running asynchronously — I'll report results once it completes; no further action is needed right now."`
 - `"The graphlemon Work Node (validator) workflow completed. It authored \`test_....js\` — an independent mechanical test for ...`（描述"我做了什么",不是文档/脚本本身的内容)
@@ -28,7 +28,7 @@ tags:
  
 ## 一个真实的参考案例:叙述文字冒充结构化产出
  
-这个代码库真实反复复现过的一类系统性 Skill 缺陷(`docs/todo/validator-test-script-narrative-output-issue.md` §6 完整根因记录):要求"先用工具探索、再产出最终内容"的节点(比如需要先读真实代码才能写 SDD/Benchmark 的场景),模型探索完之后的收尾话术天然倾向"汇报我刚才做了/启动了什么",而不是切换成"直接吐出最终内容"模式——即使 Skill 提示词已经写了"不要写叙述文字",这句话附加在提示词末尾的格式规则,不足以覆盖"多轮工具调用之后的收尾习惯"这个更底层的行为模式。
+这个代码库真实反复复现过的一类系统性 Skill 缺陷(`docs/done/validator-test-script-narrative-output-issue.md` §6 完整根因记录):要求"先用工具探索、再产出最终内容"的节点(比如需要先读真实代码才能写 SDD/Benchmark 的场景),模型探索完之后的收尾话术天然倾向"汇报我刚才做了/启动了什么",而不是切换成"直接吐出最终内容"模式——即使 Skill 提示词已经写了"不要写叙述文字",这句话附加在提示词末尾的格式规则,不足以覆盖"多轮工具调用之后的收尾习惯"这个更底层的行为模式。
  
 如果这次要修的 Skill 也有类似"先探索、再产出"的结构,而失败症状也是"产出的是进度汇报式散文,不是结构化内容",可以直接参考这个案例的诊断方式,但**不要机械照抄"加一句不要写叙述文字"这种已经被证明不够的修法**——真正管用的方向是把"探索阶段"和"最终作答阶段"在提示词结构上明确分开(比如要求模型先完成探索、再有一个清晰的"现在开始,你的下一段输出必须且只能是最终内容本身"的转折),而不是在末尾追加一句格式提醒。
  
@@ -30,7 +30,7 @@ Coder å¼€å§‹ä¹‹å‰ä¸€æ¬¡æ€§æŠŠå…³);æˆ‘ä¹Ÿä¸åˆ¤æ–&quot;æ•´ä¸ªä»»åŠ¡æ˜¯å¦éªŒæ”¶é€šè¿
  
 ## åˆ¤æ–æ ‡å‡†:æ˜¯ä¸æ˜¯å™è¿°æ–‡å—å†’å……äº§å‡º
  
-**çœŸå®žåå¤å¤çŽ°è¿‡çš„ä¸€ç±»ç³»ç»Ÿæ€§å¤±è´¥**(`docs/todo/validator-test-script-narrative-output-issue.md`
+**çœŸå®žåå¤å¤çŽ°è¿‡çš„ä¸€ç±»ç³»ç»Ÿæ€§å¤±è´¥**(`docs/done/validator-test-script-narrative-output-issue.md`
 Â§6 çš„å®Œæ•´æ ¹å› è®°å½•):è¦æ±‚"å…ˆç”¨å·¥å…·æŽ¢ç´¢ã€å†äº§å‡ºæœ€ç»ˆå†…å®¹"çš„èŠ‚ç‚¹,æ¨¡åž‹æŽ¢ç´¢å®Œä¹‹åŽçš„æ”¶å°¾è¯æœ¯å¤©ç„¶
 å€¾å‘"æ±‡æŠ¥æˆ‘åˆšæ‰åšäº†/å¯åŠ¨äº†ä»€ä¹ˆ",è€Œä¸æ˜¯åˆ‡æ¢æˆ"ç›´æŽ¥åå‡ºæœ€ç»ˆå†…å®¹"æ¨¡å¼â€”â€”å³ä½¿èŠ‚ç‚¹è‡ªå·±çš„æç¤ºè¯
 å·²ç»å†™äº†"ä¸è¦å†™å™è¿°æ–‡å—",è¿™å¥è¯ä½œä¸ºé™„åŠ åœ¨æç¤ºè¯æœ«å°¾çš„æ ¼å¼è§„åˆ™,ä¸è¶³ä»¥è¦†ç›–"å¤šè½®å·¥å…·è°ƒç”¨ä¹‹åŽ
@@ -475,7 +475,7 @@ def _test_script_verify_fn(node_artifact_types, script_artifact_type=&quot;test_scrip
     parameterized so this same function backs both the Planner's
     'test_script' node and the Validator's own 'validator_test_script' node.
  
-    2026-08-07 (docs/todo/validator-test-script-narrative-output-issue.md):
+    2026-08-07 (docs/done/validator-test-script-narrative-output-issue.md):
     `check_script_compiles`'s own detail string already says "not a
     narrative description", but that's a generic explanation of what the
     mechanical check looks for, buried ahead of two raw compiler
@@ -696,7 +696,7 @@ def plan_documents(conn, task_id, goal_text, target_folder_path, timeout=300):
     return {"run_id": run_id, "artifact_ids": artifact_ids}
  
  
-# ponytail: 子串匹配，从 docs/todo/validator-test-script-narrative-output-issue.md
+# ponytail: 子串匹配，从 docs/done/validator-test-script-narrative-output-issue.md
 # 记录的真实复现文案里提炼——"以为在描述自己做了什么"的稳定措辞模式。只作为喂给
 # planner_reviewer 的提示信号，不是硬性机械拦截（跟 check_script_compiles 不同：
 # 这里没有客观的"编译通过/失败"可判断，误判成本是把合法的、恰好提到这些词的文档
@@ -95,7 +95,7 @@ def _blocked_reason_for(exc):
     generalized the same exception/retry machinery to the test_script
     mechanical compile-check too -- without this, both show up in the
     console as the same misleading 'prd_consistency_check_failed' label
-    (see docs/todo/validator-test-script-narrative-output-issue.md), even
+    (see docs/done/validator-test-script-narrative-output-issue.md), even
     when the real failure has nothing to do with the PRD.
     ponytail: distinguishes by substring-matching the failing node's LLM-
     chosen node_id (e.g. 'n_test_script'/'validator_test_script') rather
@@ -344,7 +344,7 @@ class PlanDocumentsTest(PipelineTestBase):
         # must be persisted as artifacts, not silently discarded.
         #
         # test_script itself is disabled by default as of the same date
-        # (docs/todo/validator-test-script-narrative-output-issue.md) -- this
+        # (docs/done/validator-test-script-narrative-output-issue.md) -- this
         # test uses _fake_plan_subprocess_run_with_test_script to keep
         # exercising the salvage mechanism itself (generic, not specific to
         # test_script) rather than losing this coverage entirely.
@@ -116,7 +116,7 @@ GRAPH_MANIFEST_SCHEMA = {
 # what order, and how each one's judgment/on_fail should work. This
 # catalog is reference DATA the prompt hands the LLM, not a requirement
 # that every entry appears -- FR-B2. test_script (disabled 2026-08-07,
-# docs/todo/validator-test-script-narrative-output-issue.md) is back in
+# docs/done/validator-test-script-narrative-output-issue.md) is back in
 # this catalog per that decision's §8 item 7: Part B doesn't wait for the
 # narrative-output structural fix, that fix is tracked separately
 # alongside a future Coder-side test_script module.
@@ -227,6 +227,14 @@ _CODER_NODE_CATALOG = [
         "suggested_judgment": {"kind": "llm", "judge_prompt": _NODE_REVIEW_JUDGE_PROMPT},
         "suggested_promotes_to_artifact": {"artifact_type": "test_report"},
     },
+    {
+        "node_type": "test_script",
+        "description": "A real, runnable script that mechanically checks the SDD's acceptance scenarios --"
+                        "only include this if a genuine mechanical check beyond unit_test/integration_check "
+                        "is useful for this goal (e.g. a standalone repro/benchmark script this task's "
+                        "deliverable should ship with).",
+        "suggested_judgment": {"kind": "mechanical", "check_ref": "check_script_compiles"},
+    },
 ]
  
 _VALIDATOR_NODE_CATALOG = [