workgraph-planning-methodology-trial · Hunt 调研笔记 v1

任务：验证「按任务复杂度裁剪 work graph 形状」这类元规划判据能否被训出来。 调研范围：块A 外部方法论 / 块B 仓库内部权威源 / 块C 历史真实案例。每条结论标来源。

---

块A · 外部方法论（Web Search）

A1. Cynefin 框架（复杂度分类需要不同应对方式）

来源：Cynefin framework - Wikipedia、 The Cynefin Framework | Untools、 ModelThinkers - Cynefin Framework

• 提出者 Dave Snowden（1999），"Cynefin" 是威尔士语，意为「栖息地/熟悉之处」。
• 五个域，按因果关系的可辨识程度划分：
  • Clear/Simple/Obvious：因果关系直接、人人可见，"sense-categorize-respond"，有标准最佳实践（best practice）。
  • Complicated：因果关系存在但需要专家分析才能看清，"sense-analyse-respond"，靠"good practice"（多个可行方案里选一个）。
  • Complex：因果关系只能事后回溯地理解、不会重复出现，"probe-sense-respond"，需要并行试验去找出模式（emergent practice）。
  • Chaotic：因果关系不可辨识，必须先"act"稳定局面，再回头"sense-respond"。
  • Disorder：不知道自己处在哪个域，第一步是把问题拆开、把各部分分别归类。
• 对本任务的映射：这正是"不能一套流程套所有任务"的理论根据——Simple/Complicated 域适合走 已验证的标准流程（对应骨架"照抄不裁剪"），Complex/Chaotic 域需要探测式、增量式推进（对应"裁剪+边观察边调整"）。 Cynefin 本身不提供"如何把任务复杂度映射到具体流程步骤数"的量化方法，只提供定性分类， 这是它与 T-shirt sizing / INVEST 的互补关系（分类之后还需要一把可比较的尺子）。

A2. 敏捷估算：T-shirt sizing / Story Point（复杂度信号转可比较量表）

来源：T Shirt Sizing: Agile Estimation & Capacity Planning | Asana、 T-Shirt Sizing in Agile: Complete Guide | teachingagile

• T-shirt sizing 用 XS/S/M/L/XL 这类相对档位代替绝对工时估算，理由是"人类擅长相对比较（这个比那个大/小/差不多），不擅长绝对数字估算"。
• 常见做法是先用 T-shirt 档位做粗筛（适合早期、细节不足、只求方向不求准确工期的场景——路线图/发布规划）， 再把档位映射到具体 Story Point 数值区间（如 S=1-2 分、M=3-5 分）用于冲刺内的细粒度规划。
• Story Point 度量的是"相对工作量/复杂度"而非工时，允许团队用比数字更多维的方式思考（时间+难度+不确定性一起打包进一个点数）。
• 对本任务的映射：这套方法论提供了"复杂度信号→档位→流程形状"这条链路的中间一环—— 先给任务打一个粗档位（T-shirt size），再让档位决定要不要走全套骨架还是裁剪版。 当前 workgraph-planning/agent.md 里没有类似的显式打分/分档步骤，裁剪判断完全依赖 LLM 一次性通读输入后的直觉判断（见块B）。

A3. INVEST 原则与 SPIDR 拆分模式（需求独立性/够小的判据）

来源：SPIDR: Five Simple but Powerful Ways to Split User Stories - Mountain Goat Software、 SPIDR – five simple techniques - itemis

• INVEST：好的用户故事应该是 Independent（独立）、Negotiable（可协商）、Valuable（有价值）、 Estimable（可估算）、Small（够小）、Testable（可测试）。"够小"的判据之一是"6-10 个故事应该能在一个 sprint 内做完"。
• SPIDR（Mike Cohn 提出）是拆分故事的五种具体手法：Spike（先用一次探索性任务摸清未知再拆）、 Path（按用户可达成目标的不同路径拆，如"信用卡支付"vs"Apple Pay支付"）、Interface（按平台/设备拆）、 Data（按数据范围简化/限制来分批交付价值）、Rules（按业务规则的子集拆）。
• SPIDR 与 INVEST 是互补关系，不是替代关系："可以把 SPIDR 当 INVEST 的补充，也可以反过来看"。
• 对本任务的映射：INVEST 的"Independent"和"Small"两条，是判断"这个 work graph 节点是否值得单独拆出一个节点" 的天然判据——对照 workgraph-planning/agent.md 约束里"一个节点=一件能一句话说清「做完什么算成功」的事"， 与 INVEST 的精神一致，但仓库现有文档里没有引用 INVEST/SPIDR 本身，这条映射是本次调研新做的类比，未见仓库内部提及。

A4. 精益 / YAGNI 视角（过度流程是浪费，但裁剪也可能矫枉过正）

来源：YAGNI (You Aren’t Gonna Need It) | Laws of Software Engineering、 YAGNI is about much more than avoiding premature optimization | Hacker News 讨论

• YAGNI 出自极限编程：不要在真正需要之前添加功能，"做能work的最简单的事"。
• 核心论据是维护成本：每一行代码/每一个流程步骤都要被理解、测试、调试、在需求变化时更新； "研究显示 64% 的功能很少或从未被使用"（引自 codeCake 对 YAGNI 的综述，二手数据未见原始出处，此点标注未核实—— 搜索结果里这条统计数字反复出现在多篇二手博客中，但没有一篇给出可验证的一手研究链接）。
• 关键限制/矫枉过正的风险（Hacker News 讨论 + Laws of Software Engineering 页面共同指出）： YAGNI 与架构规划之间存在张力——"你不能靠以后加楼层来盖摩天大楼"，YAGNI 适用于功能与抽象层， 不适用于地基级的架构决策；平衡靠持续重构、自动化测试、增量式设计来维持，而不是靠一次性把流程砍到最少。
• 对本任务的映射：这正是本次训练要验证的判据的另一半——裁剪不是单向"越少越好"， 该保留的（比如"每个非入口节点必须有兜底边""数据契约必须声明"）属于"地基级"约束， 不受任务复杂度高低影响，这与块B里 workgraph-planning/agent.md 的"五项校验"（结构合法性）和 "裁剪授权"（内容取舍）是两个独立维度高度吻合——五项校验从不因任务简单而放松，裁剪只发生在节点数量/骨架选型上。

块A 小结：四套外部方法论覆盖了"识别复杂度类型（Cynefin）→ 打分定档（T-shirt/Story Point）→ 落到需求粒度的可执行判据（INVEST/SPIDR）→ 警惕两个方向的矫枉过正（YAGNI 的张力）"这条完整链路。 仓库现状（块B）目前只有 Cynefin 式的定性判断（"宿主角色定义+任务描述→选骨架"）和 YAGNI 式的裁剪授权， 缺 T-shirt sizing 式的显式复杂度打分环节，也没有引用或复刻 INVEST/SPIDR 的拆分判据—— 这是"元规划判据能否被训出来"这个问题里，外部方法论能提供但仓库尚未采纳的部分，留给 Digester/训练阶段参考。

---

块B · 仓库内部权威源精读（比外部资料更权威）

B1. system/agents/workgraph-planning/agent.md 全文精读

来源：system/agents/workgraph-planning/agent.md（664 行，全文已读，行号对照 2026-08-23 版本）

Step 2 · 读候选骨架（原文，L75-86）

每个模板的 whenToUse 字段是选型的唯一依据——它写清楚了适用场景、典型信号词、 以及与其他模板的区别。拿宿主 org node 的角色定义 + 任务描述对照着读，不要凭 id 猜。

这是起点集合，不是穷举枚举。目录里将来可能有更多文件，永远以 ls 的实际结果为准。

⚠️ 一条硬规则：宿主 org node 是 org-validator 时，必须用 validator.json 骨架， 第一个节点必须是 validator-triager。理由见 §硬性约束·约束五。

Step 4 · 规划（原文，L117-148，含裁剪授权原句）

综合 Step 1/2/3 三份输入，产出：节点列表 + 执行流边 + 边上的数据契约。

🚨 第三项不是可选的。 边上不声明数据契约（produces / needs）， 下游节点的提示词里就没有上游产物的路径，它会像第四次真跑那样直接失败。

你被明确允许：

• 裁剪：骨架五个节点，这次任务只需要三个 → 砍掉两个（比如任务不需要 BRD，直接从 PRD 起步）；
• 替换：把某个节点的本体换成更贴合本次任务的；
• 组合：拿 executor.json 做主干，把 planner.json 的验收产出节点接进去；
• 增删验收产出节点：goal-benchmark / goal-test-data / goal-test-script 三个是动态选入的 （27-E2E §十一），按本次 task-goal 的验收方式选一个、选几个、或一个都不选。

你不被允许：

• 不加思考地照抄某个骨架原样交回（那说明你没做 Step 1 的判断，而且骨架里没有数据契约， 照抄出来的图每条边都不传数据）；
• 留着 {{orgNode}} / {{implAgent}} 这类占位符就交回（引擎落出来是一张引用不存在 agent 的废图）；
• 把不同职能塞进同一个节点（一个节点 = 一件能一句话说清「做完什么算成功」的事）；
• 画出违反下面「五项校验」的图；
• 在节点内部再套一层四段式流转（约束四，最容易犯，务必读完）。

有 remediation_note 时的重规划三选一（27-E2E §四 #4 的判断留在这一层做，不上升到 org 层）：

判断	怎么画
上一轮图的形状就是错的（少了一步 / 拆错了）	重画一张新图
图没问题，只是某个节点干砸了	图形状照旧重画一张，把 remediation_note 作为该节点的输入上下文写进规划记录
归因是 infra_flake（进程超时 / 被杀）	不用重规划，直接向引擎汇报「原地重跑即可」——这类不烧任何计数

⚠️ 重要观察：Step 4 唯一给出的裁剪具体例句就是"任务不需要 BRD，直接从 PRD 起步"—— 这恰好是块C要核实的三个案例（及补充发现的第四个 planner 类案例）理论上最贴近的场景。 块C 的实测结果见下方，直接检验了这句例句在真实运行里有没有被落实。

Step 5 · 落盘规划记录，五项校验自查（原文节选，L163-209）

文件至少包含七节结构（原文列出的 markdown 模板，字段名逐一摘录）：

1. 输入 2. 候选骨架评估（模板 / whenToUse摘要 / 是否采用 / 理由）
2. 本体核实（节点 / 想要的本体 / 清单里有吗 / 最终用了什么）
3. 最终图 5. 与骨架的差异及理由 6. 五项校验自查 7. 招聘结果（Step 6 之后回填）

这一步不能跳。 27-P3/P4 §八.8 写明：图的规划质量没有硬校验，五项只保证图结构合法， 保证不了它适合这个任务。这份 md 是人类事后发现图不合理时唯一的决策线索。

⚠️ 关键约束：五项校验（无环/单一入口/可达性/回退边标注/fail 兜底边）验的是"结构合法"， 不验"是否适合这次任务的复杂度"——这句原文明确承认了"裁剪判断质量"目前没有任何自动化校验兜底， 完全依赖 LLM 单次判断，这与块A的 Cynefin/YAGNI 讨论里"矫枉过正"的风险直接对应： 裁剪多了/少了都不会被系统拦下来，只能靠事后人工审计规划记录发现。

约束一：五项校验原文（L405-424，逐条摘录）

1. 无环（仅针对 edgeKind='forward'）—— 三色 DFS。
2. 单一入口 —— 必须恰好有一个入度为 0 的 forward 节点，任务从这里进入。
3. 可达性 —— 每个节点都必须从入口可达，孤立节点直接拒绝。
4. 回退边必须显式标注 —— 任何指向"拓扑序更早节点"的边，edgeKind 必须是 backward； 引擎独立复核，不信任标注（反向也查：没构成回路的边不许标 backward）。
5. fail 兜底边 —— 除图的唯一入口节点外，每个节点都必须至少留一条 failReason 为空的兜底边（2026-08-21 收紧，见约束三：不再要求"先有别的 fail 边"这个前提）。

手工验算法（原文表格，L417-423）：

#	手工验算法
1	把所有 backward 边划掉，剩下的边必须能排出拓扑序
2	只数 forward 边的入度，入度为 0 的节点必须恰好一个
3	从入口沿 forward 边 BFS，必须覆盖 nodes 里每一个节点
4	任何 to 在拓扑序上早于 from 的边，必须带 "edgeKind": "backward"
5	除了第 2 条找出的那个唯一入口，逐个点名图里其余每一个节点，确认每个都至少有一条 condition:"fail" 且没写 failReason 的边——不能只挑"已经有 fail 边"的节点抽查

其余硬性约束（二至九）速记（未逐字摘录，仅记要点，来源同文件）：

• 约束二：nodeName（图内唯一，带宿主 org 节点前缀）≠ systemAgentId（跨图复用，不带前缀）。
• 约束三：除入口节点外每个节点都必须留一条兜底边（2026-08-21 收紧，判据不再要求"先有别的 fail 边"）。
• 约束四：不许在节点内部再套一层 RESEARCH→PLAN→EXECUTE→VERIFY 四段式（会导致两层 Context Flush 互相清空对方上下文）。
• 约束五：宿主是 org-validator 时归因节点（validator-triager）必须排第一位。
• 约束六：边不跨层，归因可以跨层（两件事）。
• 约束七/八：元 agent 与 workgraph-planning 自己都不许入图。
• 约束九：forward 边上必须声明数据契约（produces/needs，取值域仅 7 个 kind）。

B2. system/work-graph-templates/ 四份骨架 + README.md 精读

来源：system/work-graph-templates/{planner,executor,executor-fanout,validator}.json + README.md

骨架	id	宿主 org node	节点链（whenToUse 摘要）	dataContractNotes 要点
planner.json	planner	org-planner（规划类，产出文档/规格而非可运行产物）	brd→prd→sdd→benchmark→validator（5节点）	三份文档各自 produces 自己的 kind；prd 的产出方隔了一个节点给 benchmark，用 needs 中继；acceptance 是本图内唯一该沿边声明任务级共享 kind 的情形（产出方和消费方都在本图内）
executor.json	executor	执行类（org-coder/org-writer/org-monitor），单交付物	impl→test→validator（3节点）	交付物走 artifact，自测记录走 log；validator 既要看 log 也要看交付物本身，用 needs artifact 中继
executor-fanout.json	executor-fanout	执行类，任务能拆成互不依赖、可并行的分支	split→(impl/test)×N→merge→integration→validator（8节点，本文件示例2分支）	拆分节点产物声明成 contract 而非 artifact（避免被先跑完的分支产物顶掉）；merge 的已知上限是索引按 kind 只回最新一份，需要提示词自己按目录找齐
validator.json	validator	org-validator 专用，硬性约束	validator-triager→benchmark-validator→testdata-validator（3节点）	两条 forward 边只写 needs，不写 produces——判词/评分文件刻意不进产物索引，写 produces 会造成假警报；被验产物不在本图，required:false 是数据契约规则的合规逃生口

四张骨架的共同形状（README 原文，L29）：

四张图共享一个形状：做 → 自检 → 本层验收，验收失败沿 backward 边退回重做。差异只在中段。

planner.json 五节点之间的 needs 依赖链（核实原文 JSON，system/work-graph-templates/planner.json）：

org-planner-brd --success--> org-planner-prd      produces:[brd]
org-planner-prd --success--> org-planner-sdd      produces:[prd]
org-planner-sdd --success--> org-planner-benchmark produces:[sdd], needs:[prd]
org-planner-benchmark --success--> org-planner-validator produces:[acceptance], needs:[brd,prd,sdd]

如果砍掉 org-planner-brd（"不需要 BRD，直接从 PRD 起步"）会发生什么，逐条核实：

• org-planner-prd → org-planner-sdd 这条边只声明 produces:["prd"]，不 needs brd，砍掉 brd 节点不会破坏这条边；
• 真正依赖 brd 这个 kind 的只有 org-planner-benchmark --> org-planner-validator 这条边的 needs:["brd","prd","sdd"]—— 砍掉 brd 节点后，这个 needs 里的 brd 就会在图里找不到产出方，触发 README 里明确写的规则 6（data-contract）： 「needs 的每个 kind 在图里都有产出方，否则 rule=data-contract 整张图被拒」；
• 修法二选一（README 原文）：把 org-planner-benchmark → org-planner-validator 边上的 needs 从 ["brd","prd","sdd"] 改成 [{"kind":"brd","required":false}]（brd 变成可选输入），或者干脆把 benchmark/validator 也从 needs 列表里去掉 brd；
• 结论：Step 4 例句里"骨架五个节点，这次任务只需要三个 → 砍掉两个（不需要 BRD 直接从 PRD 起步）"这句话 在技术上是可行的，但不是简单删掉一个节点就完事——必须同步改掉下游 needs 声明，否则会触发 rule=data-contract 被引擎打回。这是"裁剪授权"原句里没有言明、但 README 数据契约规则里能推导出的一条隐藏成本， 值得在训练判据里显式化：裁剪一个节点前，先检查有没有下游节点的 needs 依赖它的产出。

README 里"当前模板"表（L20-28，逐字摘录节点链列）：

文件	id	宿主 org node	节点链
planner.json	planner	规划类（org-planner）	brd → prd → sdd → benchmark → validator
executor.json	executor	执行类（org-coder / org-writer / org-monitor），单交付物	impl → test → validator
executor-fanout.json	executor-fanout	执行类，可并行拆分	split → (impl/test)×N → merge → integration → validator
validator.json	validator	org-validator 专用	validator-triager → benchmark-validator → testdata-validator

---

块C · 历史真实案例核实（比外部方法论更重要）

⚠️ 首个重要发现：任务指定的三个案例（p-v82tpc / p-pyjha7 / p-iyshuc）经核实后， 没有一个是 org-planner 宿主节点——p-v82tpc 和 p-pyjha7 都是 org-validator（用 validator.json）， p-iyshuc 是 org-coder（用 executor.json，且有两版：首次规划 + infra_flake 重规划）。 也就是说，块B里 Step4 那句"不需要 BRD 直接从 PRD 起步"的裁剪例句，这三个指定样本天然无法验证—— 它们的骨架本身就不含 BRD 节点（validator.json/executor.json 都是 3 节点骨架，没有 brd/prd/sdd 这类文档节点）。 为了不遗漏"planner 类骨架实际有没有被裁剪过"这个问题，调研额外核实了同一批项目里唯一存在的 org-planner 案例（p-v1mpcl / T-mt1qx0c4-95bf），补在 C4，来源：data/companies/e2e-demo/projects/p-v1mpcl/workgraph-plan-T-mt1qx0c4-95bf.md。

C1. p-v82tpc / T-mt2r6fz0-125b（宿主 org-validator）

来源：data/companies/e2e-demo/projects/p-v82tpc/workgraph-plan-T-mt2r6fz0-125b.md

• 实际图：validator-triager → benchmark-validator → testdata-validator，与 validator.json 骨架 完全一致，节点数/边数一个不少不多（原文第4节：「与骨架 validator.json 完全一致，未裁剪未替换」）。
• 任务原文复杂度特征：任务本身是"apple.com 风格 lemonboss 官网首页"（单页静态站，无持久化，交付物单一）， 但这个宿主节点是 org-validator（判定"整个任务达成了吗"的验收环节），它的职责与页面本身复不复杂无关—— 它固定要走归因→评分校验→测试数据校验三步，任务描述的简单/复杂程度不影响这个骨架的形状。
• 是否真的裁剪过：没有。规划记录第5节原文：「无差异。任务描述里没有额外要求跳过 benchmark 或 testdata 校验……标准三节点骨架已覆盖这个诉求，不需要增删节点」。

C2. p-pyjha7 / T-mt45nzvc-2235（宿主 org-validator）

来源：data/companies/e2e-demo/projects/p-pyjha7/workgraph-plan-T-mt45nzvc-2235.md

• 实际图：同样是 validator-triager → benchmark-validator → testdata-validator，与骨架完全一致。
• 任务原文复杂度特征：同一类"apple.com 风格 lemonboss 官网首页"任务，附带更细的验收要求 （三个卖点区块、导航平滑滚动不出现 # 锚点、任意宽度不出现横向溢出），上游还带着一个前序失败上下文 （org-coder attempt-0 失败，fail_reason=body_not_ready）。
• 是否真的裁剪过：没有。规划记录第5节原文：「无差异，原样采用骨架三节点四边结构——本次验收任务 不需要额外验收产出节点……testdata-validator 按骨架保留（即使 goal-test-data/ 当前不存在，读取契约里 已标 required:false，不会因缺失而报错）」。这一点值得注意：即便 goal-test-data/ 这类下游依赖的 产物实际不存在，规划者也没有裁掉 testdata-validator 节点，而是依赖契约里的 required:false 逃生口让它 "跑但允许 skip"，没有触发结构层面的裁剪判断。

C3. p-iyshuc / T-mt5d3mi9-57cf 与 -retry2（宿主 org-coder，两版对照）

来源：data/companies/e2e-demo/projects/p-iyshuc/workgraph-plan-T-mt5d3mi9-57cf.md 与同目录下 -retry2.md

• v1（首次规划）实际图：org-coder-impl(coder) → org-coder-test(unit-tester) → org-coder-validator(coder-validator)， 与 executor.json 骨架完全一致。规划记录第5节原文：「完全采用 executor.json 三节点串行骨架，未裁剪、 未增删节点：任务是单一页面交付物……不在本图内重复」，并明确排除了 executor-fanout.json： 「首页三个卖点区块同属一个页面/一次实现，不是独立可并行的子任务」——这是唯一一处三个原始样本里 出现"骨架间比较+排除理由"的记录（其余两个案例只是确认必须用 validator.json，没有真正对比过其他骨架）。
• retry2（infra_flake 重规划）：归因是 infra_flake（进程被中断，非节点/图形状问题）。 规划记录第2节原文：「本次归因明确落在 infra_flake……图的形状没有被点名有问题……因此本轮不重新 设计图形状，直接复用上一份规划记录里验证过的同一张图……未做任何裁剪/替换/组合的变更」。 这直接对应块B agent.md Step4「重规划三选一」表格里的第三行（infra_flake → 不用重规划， 原地重跑），是一次真实发生、且规划者显式引用了该判据文字（"按 agent.md Step4「有 remediation_note 时的重规划三选一」"）的落地案例——证明这条判据至少在这一实例中被正确执行。
• 是否真的裁剪过：两版都没有。两次都是完整 3 节点骨架，唯一的差异是 retry2 版本的判断依据是 "沿用上一轮"而非"重新评估骨架"。

C4.（补充，非任务原指定，但为回答"planner 类骨架是否被裁剪过"这一问题而额外核实）

p-v1mpcl / T-mt1qx0c4-95bf（宿主 org-planner）

来源：data/companies/e2e-demo/projects/p-v1mpcl/workgraph-plan-T-mt1qx0c4-95bf.md

• 任务原文：「读 lemonboss 仓库文档+代码，产出 apple.com 风格的静态官网，讲清 why/how/what， 含核心价值点、功能模块、独特性说明，至少 3-4 张界面截图/示意图配说明」——这正是块B agent.md Step4 例句所指的场景类型（规划类交付、单一静态站点、无持久化、无多角色评审）。
• 实际图：org-planner-brd → org-planner-prd → org-planner-sdd → org-planner-benchmark → org-planner-validator， 完整 5 节点，一个没砍，与 planner.json 骨架逐字一致。
• 是否真的裁剪过：没有。规划记录第5节原文：「无差异，原样采用骨架——本次任务（读文档产出规格化的 静态网站）与骨架设计意图……完全吻合，不需要裁剪或替换」。
• ⚠️ 这是本次调研里唯一一个与块B Step4 裁剪例句"直接可比"的真实样本，结果是反例： 例句设想的场景（读文档产出规格化网站）与这个真实任务高度相似，但规划者保留了 BRD 节点， 没有执行例句里演示的裁剪动作。规划记录里给出的理由是"brd/prd/sdd 描述 why/how/what……完全对应骨架语义"， 即规划者认为"讲清 why"就等于需要 BRD，而不是把"BRD 对应的信息量是否足够小到可以并入 PRD"作为裁剪判据。

块C 总体发现（跨 4 个样本，5 份规划记录）

1. 裁剪发生次数 = 0/5。全公司当前可查到的全部 5 份 work graph 规划记录（覆盖 validator.json ×2、 executor.json ×2、planner.json ×1），没有一次真正执行过节点裁剪/替换/组合，全部是"骨架完整照搬"。
2. "骨架间比较并排除"的记录只出现过一次（C3 排除 executor-fanout.json 的理由）， 其余样本的"候选骨架评估"表格虽然按 agent.md 规定的格式填了四行，但除了命中的那一行都是 "❌ 宿主不是XX"这类基于宿主类型的硬性排除（几乎不需要任务复杂度判断，选型规则是确定性的： org-validator→validator.json，org-coder→executor.json/executor-fanout.json，org-planner→planner.json）， 真正需要在"同一骨架内部裁剪节点数量"这一层做判断的场景，目前 0 例真实发生。
3. C4 的反例价值最高：它是唯一一个任务特征与 Step4 裁剪例句高度吻合、却仍然选择"完整保留"的真实案例， 说明当前 agent.md 里的裁剪授权文字是"允许但从未被验证过是否会被正确执行"—— 这正是本次训练要验证的核心问题："按任务复杂度裁剪 work graph 形状"这条元规划判据， 在真实数据里目前没有一次正样本，只有反复出现的"完整保留"负样本（如果把"该裁剪却没裁剪"算作负样本的话， 但也存在另一种解读：这四个真实任务客观上都不满足裁剪条件，规划者的"不裁剪"判断本身是正确的—— 这一点无法仅凭规划记录本身判定，需要人工进一步核实"C4 的 BRD 节点产出物是否事后被证明是冗余的"， 本次调研未做这一步，如实标注为未核实）。
4. executor-fanout.json 目前 0 个真实落地样本——四个真实规划记录里没有一个选用它， C3 是唯一一次"考虑过它但排除了"的记录，其余样本连候选骨架表格里都是机械排除（宿主类型不对）。 这意味着"能不能拆并行分支"这条裁剪/扩展判据同样缺乏正样本可供训练参考。

---

汇总：三块调研对训练判据的启示

判据环节	外部方法论怎么说（块A）	仓库现状怎么写（块B）	真实数据怎么做（块C）
复杂度识别	Cynefin：先分类（Simple/Complicated/Complex/Chaotic），再定应对策略	靠"宿主角色定义 + 任务描述"人工通读判断，无显式分类步骤	4/5 样本的骨架选型完全由宿主类型（org-planner/coder/validator）确定性决定，未见任务复杂度参与选型
复杂度打分	T-shirt sizing/Story Point：先打粗档位，再细化	无对应机制	无对应机制，规划记录里没有任何"复杂度评分"字段
拆分/合并判据	INVEST（独立/够小）+ SPIDR（5种拆分手法）	"一个节点=一件能一句话说清的事"；裁剪/替换/组合三种授权	0 次裁剪，1 次"排除 fanout"，其余为宿主类型的硬性匹配
矫枉过正的平衡	YAGNI：警惕功能/流程的双向过度（多了浪费，少了架构塌方）	"五项校验"验结构合法性但不验"是否适合任务"，原文明说"没有硬校验"	C4 疑似"该裁未裁"的一个反例，但未核实是否属实（需要看产出物是否冗余）

给下一阶段（Digester/Trainer）的建议方向：

1. 当前样本量对"裁剪判据"这一具体能力是信息量几乎为零的（0 正样本），继续等真实数据积累裁剪案例， 或者需要主动构造几个"任务足够简单、骨架该裁"的合成场景来补足训练信号；
2. C4 反例值得单独立案追踪——建议找宿主（org-planner）事后确认「这次的 BRD 产出物内容， 是否本可以合并进 PRD 而不丢信息」，这能把"未核实"的猜测坐实成"确认过度设计"或"确认合理保留"；
3. 块B 发现的"裁剪节点必须同步检查下游 needs 依赖"这条隐藏规则，建议补进 agent.md Step4 的裁剪授权段， 作为显式的裁剪前置检查清单项（目前只在 README 的 data-contract 规则里间接可推导，容易被漏看）。