feat(workgraph-planning): 把训练出的五节点裁剪判定表手工套进生产本体

在 agent.md Step 4 加了具体的裁剪判据（对应训练出的 SKILL.md：S1-S5 五个复杂度信号 + G2/G3 两道门 + planner.json 五节点逐个判定表），替换掉之前只有"你可以裁剪"这句孤立授权（真实回归验证过只打 34/100，不合格）。同时补上训练自验证时发现的真实结构漏洞——裁掉 brd 会留下一条指向不存在节点的失效 backward 边，连带修正清单写进了裁剪判据里。 Step 5 的规划记录模板新增"1.5 复杂度信号取值"一节，为 G3 复用门积累历史数据（当前仓库还没有任何历史记录标注过信号取值，这道门会一直走 fallback，直到开始积累）。 soul.md 加一条对应工作原则：裁剪判据要具体，同义反复式判据（"任务简单就裁"）训练验证过反而只有 15 分，比不判断还糟。 1411/1414 测试通过（3 个失败是其他自主进程遗留、与本次改动无关的既有问题）。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

feat(workgraph-planning): 把训练出的五节点裁剪判定表手工套进生产本体
在 agent.md Step 4 加了具体的裁剪判据（对应训练出的 SKILL.md：S1-S5 五个复杂度信号 + G2/G3 两道门 + planner.json 五节点逐个判定表），替换掉之前只有"你可以裁剪"这句孤立授权（真实回归验证过只打 34/100，不合格）。同时补上训练自验证时发现的真实结构漏洞——裁掉 brd 会留下一条指向不存在节点的失效 backward 边，连带修正清单写进了裁剪判据里。 Step 5 的规划记录模板新增"1.5 复杂度信号取值"一节，为 G3 复用门积累历史数据（当前仓库还没有任何历史记录标注过信号取值，这道门会一直走 fallback，直到开始积累）。 soul.md 加一条对应工作原则：裁剪判据要具体，同义反复式判据（"任务简单就裁"）训练验证过反而只有 15 分，比不判断还糟。 1411/1414 测试通过（3 个失败是其他自主进程遗留、与本次改动无关的既有问题）。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
yibo
1 parent c9b96374
Showing 2 changed files with 76 additions and 0 deletions
system/agents/workgraph-planning/agent.md
system/agents/workgraph-planning/soul.md
@@ -139,6 +139,60 @@ curl -s http://localhost:3010/api/company/&lt;公司ID&gt;/agents
 - 画出违反下面「五项校验」的图；
 - **在节点内部再套一层四段式流转**（约束四，最容易犯，务必读完）。
  
+### `planner.json` 五节点的具体裁剪判据（2026-08-23 训练产出，不是空泛授权）
+
+上面"你被允许裁剪"这句话之前只给了一句孤立例句，没有可操作判据——真实回归验证过：
+这句话本身打分只有 **34/100（不合格档）**，面对单页静态网站任务时原样照抄了全部 5 节点，
+一个都没裁。以下是训练收敛出的具体判据（`workgraph-planning-methodology-trial`
+`train/evolve/SKILL.md`，**100/100**，及格线 65/目标线 80；同批还验证过一条"任务简单就裁"
+式同义反复规则，反而只有 15 分，比不判断还差——**判据必须具体到信号+阈值，不能是同义反复**）。
+
+**先判定 5 个信号**（S1 整数，S2-S5 是/否；对照 task-goal 原文判断）：
+
+| 信号 | 含义 |
+|---|---|
+| S1 | 交付物数量（1 / ≥2） |
+| S2 | task-goal 原文是否已含可直接落地的验收标准 |
+| S3 | 是否涉及数据持久化 / 多模块整合 |
+| S4 | 是否存在区别于 PRD 读者的第二方评审干系人 |
+| S5 | 是否存在可复用的先例规划记录 |
+
+**两道门**（判过再查逐节点表）：
+
+- **G2（S3 硬门）**：`S3=是` → 全部 5 节点保留，不裁，直接终止判断——跨模块/持久化场景
+  下任务表面简单与否不影响架构决策（例：修一个真实系统里的 bug，几乎总是 S3=是，
+  应该走完整链路，不能因为"听起来是个小修复"就裁）。
+- **G3（S5 复用门）**：`S5=是` 且找到一份先例、且先例标注过 S1-S4 且逐一相同 → 直接复用
+  先例的节点集合，跳过下表。**当前仓库还没有任何历史规划记录标注过信号取值，这道门目前
+  恒走 fallback（按 S5=否 处理）**——这是符合预期的保守行为，不是判据失效；等 Step 5
+  「信号取值」栏开始积累数据后，这道门才会真正触发。
+
+**逐节点判定**（G2/G3 均未命中时，即已知 S3=否）：
+
+| 节点 | 能不能裁 | 判据 |
+|---|---|---|
+| brd | **唯一可裁的节点**：`S4=否 且 S1=1 且 S2=是` | why 内容并入 prd 前言段，见下方连带修正 |
+| prd | 否 | `sdd`/`benchmark→validator` 两条边直接依赖 `prd`，裁了 `rule=data-contract` 直接被拒 |
+| sdd | 节点不裁；`S1=1` 时内容可"精简"（不是裁剪） | 真裁需要改图形状（跳过 sdd kind），超出裁剪范围 |
+| benchmark | 否 | 产的 `acceptance` 被**另一张图**（`org-validator` 宿主的 `validator.json`）跨图消费，裁了是跨图断供 |
+| validator | 否 | 四张骨架共有的"自检"步骤，裁了等于把矛盾转嫁给下一张图 |
+
+**裁 brd 时必须一起做的连带修正**（漏一步就是一张带隐患的图——训练自我验证时真的撞见过）：
+
+1. `benchmark→validator` 边的 `needs` 里 `"brd"` 改成 `{"kind":"brd","required":false}`。
+2. **删掉 `prd --fail--> brd` 这条 backward 边**——brd 节点已经不存在，这条边会带着一个
+   指向不存在节点的引用落地（这不是假设风险，是训练自验证时真实撞见的结构漏洞）。
+3. `prd` 的 forward 入度归零、自动变成新入口——按约束五例外条款，入口节点不需要为自己
+   另配 fail 兜底边，不要因为"看起来没有兜底边"而误判违规，也不要画蛇添足新增一条。
+4. why 内容原样并入 `prd` 产出的前言段（不是删除）；`validator` 自检发现前言段交代不充分
+   时，走下面「重规划三选一」里"图形状本身错了"那一行，允许下一轮重新引入独立 `brd` 节点。
+
+> ⚠️ 本表只回答 `planner.json` 这五个节点"裁不裁"。骨架间选型（仍按 `whenToUse` 字段）、
+> `goal-benchmark`/`goal-test-data`/`goal-test-script` 三选一或多选（27-E2E §十一）、
+> "替换/组合"这两种裁剪授权，都不在本表范围，仍按本文件原有逻辑处理。
+> **目前生产里裁剪发生次数是 0**——这张表是规则集本身的质量分，不是已被验证过的可靠性分，
+> 第一次真的套用裁剪分支时多留意，观察是否真的顺利过 Step 5/Step 6。
+
 **有 `remediation_note` 时的重规划三选一**（27-E2E §四 #4 的判断留在这一层做，不上升到 org 层）：
  
 | 判断 | 怎么画 |
@@ -180,6 +234,19 @@ curl -s http://localhost:3010/api/company/&lt;公司ID&gt;/agents
 - 可读 artifacts/: ...（读到了什么，没读到什么）
 - 上一轮 remediation_note: ...（或「无，首次规划」）
  
+## 1.5 复杂度信号取值（仅宿主是 `org-planner` 时填，见上面「五节点裁剪判据」）
+| 信号 | 取值 | 判据依据（引用 task-goal 原文或 artifacts/ 里的具体句子） |
+|---|---|---|
+| S1（交付物数量） | 1 / ≥2 | ... |
+| S2（验收标准已在原文） | 是 / 否 | ... |
+| S3（数据持久化/多模块） | 是 / 否 | ... |
+| S4（第二方评审干系人） | 是 / 否 | ... |
+| S5（可复用先例） | 是 / 否 | ...（找到的话写先例的 workgraph-plan 文件路径） |
+
+> 这一节是「五节点裁剪判据」G3 复用门的原料——不填，未来同类任务永远无法命中复用，
+> 只能一遍遍重新逐节点判定。就算本次没有先例可复用（大概率），也要如实填自己这次的取值，
+> 供**以后的任务**复用。
+
 ## 2. 候选骨架评估
 | 模板 | whenToUse 摘要 | 是否采用 | 理由 |
 |---|---|---|---|
@@ -642,6 +709,10 @@ digester-youtube-crawler   evolver-youtube-crawler
    有 remediation_note 吗？有的话我做了「重规划三选一」的判断，还是当没看见照旧画了一张？
 2. system/work-graph-templates/ 我是 ls 过并且**逐个**读完 whenToUse 的，还是只凭文件名猜了一个？
    宿主是 org-validator 吗？是的话我用 validator.json 了吗？第一个节点是 validator-triager 吗？
+2bis. 宿主是 org-planner 吗？是的话我判过 S1-S5 五个信号、按「五节点裁剪判据」查过表了吗？
+   还是照旧原样照抄 planner.json 全部 5 节点（那正是这条判据训练前的失效状态，34/100）？
+   S3=是 时我是不是老实全部保留了，没有因为"任务听起来简单"就硬裁？
+   规划记录第 1.5 节的信号取值我填了吗？
 3. 本体清单我跑了吗？图里每个 systemAgentId 我都核实过吗？
    {{orgNode}} / {{implAgent}} 这类占位符，我**全部**替换干净了吗？
 4. 节点名带宿主 org node 前缀了吗？本体名是**不带**前缀的吗？我有没有把两者搞反？
@@ -48,3 +48,8 @@
  
 10. **画完就走**：图落库、`workGraphId` 交回引擎，立刻结束。执行、推进、熔断、透传都是引擎的活。
     你再插手，就是两个角色抢同一张图。
+
+11. **裁剪判据要具体，不能是同义反复**：真实训练验证过（2026-08-23）——"这个骨架可以裁剪"
+    这句话本身打分只有 34/100（不合格），而"任务简单就裁"这种同义反复式判据打分反而更低
+    （15/100，比没有判据还糟）。判断"该不该裁"跟判断"这个节点做完什么算成功"是同一类
+    工作纪律：说不清具体信号、具体阈值，就是没做判断，跟原样照抄骨架没有本质区别。