复杂度信号定义 v1 — workgraph-planning-methodology-trial
生成者：innovator-digest（Phase 2 Digest） 输入：
../hunt/knowhow_v1.md（336行）+../hunt/sources.json日期：2026-08-23 首次训练（v1）
〇、这组信号回答什么问题，不回答什么问题
Hunt 阶段块C的核心发现（knowhow_v1.md 块C总体发现 #2）：全公司 5 份真实规划记录里，
骨架选型（选 planner.json 还是 executor.json 还是 validator.json）100% 由宿主 org
node 类型确定性决定，任务复杂度完全没有参与这一层判断——这一层选型本来就有 whenToUse
字段可查，不需要新判据。
真正没有判据覆盖的，是选定骨架之后、骨架内部节点数量要不要裁剪这一层——具体到本次训练
范围，就是 planner.json 五节点（brd/prd/sdd/benchmark/validator）要不要裁、能不能合并。
这组信号只服务于这一层判断，不涉及骨架间选型，也不涉及 executor.json/executor-fanout.json/
validator.json 内部（block B2 显示这三张骨架节点数已经很少，且 Hunt 全部 4 个真实样本里，
唯一涉及"骨架间比较"的 C3 案例排除 executor-fanout.json 靠的也是 whenToUse 字段本身，不是
本文档要定义的信号）。
每个信号必须满足的硬性门槛：判定方法必须是"给定 task-goal 原文，任何人（或规则引擎）不看 执行结果、不猜测宿主意图，就能给出同一个判定"。凡是判定方法本身含有"看起来简单""感觉不需要" 这类需要主观代入的词，一律不合格——这是 Hunt knowhow §汇总"根因"部分点名的失效模式，本文档 必须避免重犯。
一、五个信号
S1 · 交付物数量与形态
定义：task-goal 原文里出现的、彼此可以独立验收（有各自独立的验收标准/独立受众）的产出物 种类数。
判定方法：
- 逐个圈出原文中的"产出物名词短语"（如"官网首页""管理后台""数据看板"）；
- 两个产出物只有在验收标准不同或受众不同时才分别计数——如果它们共享同一套验收标准、 同一个访问入口，只算 1 个（例如"首页含三个卖点区块"仍是 1 个交付物，卖点区块不是独立 交付物，是同一交付物内的内容分区）；
- 取值：整数计数，≥1。
不合格判定法（反例）：用任务描述字数长短、或"听起来工作量大不大"来估计——这是 Hunt 汇总部分点名的失效模式（"任务简单"这类同义反复），字数与交付物数量无必然关系。
关联决策方向：S1=1 时，PRD 通常能在同一篇文档内完整叙述，SDD 若没有跨模块技术整合点， 存在与 PRD 合并的空间；S1≥2 时，SDD 需要独立展开"多个交付物之间如何整合/共享哪些技术决策"， 不应裁剪。
Hunt 案例校准：C4（p-v1mpcl，任务原文"产出 apple.com 风格的静态官网……含核心价值点、
功能模块、独特性说明，至少3-4张界面截图"）→ 全部内容共享同一个网站、同一套验收标准，
S1=1。C1/C2（"apple.com风格lemonboss官网首页"）同样 S1=1，但这两个案例宿主是 org-validator，
不在 planner.json 五节点裁剪的适用范围内，此处仅用于验证 S1 判定方法本身在不同文本上的
一致性，不能反推 planner 节点裁剪结论——如实标注这一限制。
S2 · 是否已有明确唯一的成功标准
定义：task-goal 原文本身是否已经包含可以直接落地为验收判据的具体数值/可枚举清单，不需要 下游再"翻译"一次才能变成可执行的验收脚本。
判定方法：
- 扫描原文，出现"数字+单位"组合（如"768px""3-4张""6档宽度"）或"可穷举的具体元素清单" （如"核心价值点、功能模块、独特性说明"——这是三个可点名的具体章节，不是抽象形容）即判 "是"；
- 只出现评价性形容词（"做得漂亮""满足需求""体验良好"）而没有可枚举清单或数值，判"否"。
不合格判定法（反例）：凭"读完感觉需求写得挺细"这种整体印象判断——必须能具体指出原文 第几句话是"数字/清单"，指不出来就不算"是"。
关联决策方向：S2=是 时，benchmark 节点的工作量从"从头设计验收维度"降为"格式转译"，
理论上存在与 PRD 合并的讨论空间；但这不构成直接裁剪 benchmark 节点的充分条件——
benchmark 节点的 produces 是下游 validator 的 needs 依赖来源（planner.json
needs 链：benchmark --success--> validator, produces:[acceptance], needs:[brd,prd,sdd]），
真裁掉这个节点必须同步处理这条边，不能只凭 S2=是 就删除节点本身。
Hunt 案例校准：C4 任务原文含"至少3-4张界面截图/示意图配说明"这类具体数值清单 → S2=是。
但 C4 的真实结果是完整保留全部 5 节点、一个没裁——这印证 Hunt 块C总体发现 #3：
"S2=是"这个信号即便成立，也没有在唯一真实样本里触发任何裁剪，说明该信号不能单独充当
裁剪的充分条件，必须和其他信号组合判断（详见 benchmark_v1.md D2 对"组合覆盖"的要求）。
S3 · 是否涉及数据持久化/多模块
定义：交付物是否需要跨请求/跨会话保存状态，或由多个可独立部署/独立测试的模块组成。
判定方法：
- 原文出现"存储""数据库""登录态""账号体系""多个页面互相跳转并共享状态""对接接口/后端" 等结构性字样，判"是"；
- 纯展示型静态单页描述（通篇只描述页面内容/排版/交互动画，无上述字样），判"否"。
关联决策方向：S3=是 时，无论其他信号如何组合，sdd/benchmark/validator 均不应裁剪——
这是块A YAGNI 张力讨论（knowhow §A4）在本任务里的具体落点：架构/数据形态是"地基级"决策，
不因任务表面看起来简单而放松，这条约束独立于复杂度信号存在，属于硬约束而非可裁剪判据
（详见〇末尾的补充说明）。S3=否 时才具备讨论裁剪 sdd 的前提，但仍不是充分条件。
Hunt 案例校准：C1-C4 全部 4 个真实样本都是纯展示型静态页面描述，原文均未出现持久化/ 多模块字样，S3=否（4/4）。把这一发现和"0次裁剪"（块C总体发现 #1）放在一起看：即便 "S3=否"这个理论上支持裁剪的信号在全部 4 个真实样本里都成立，规划者依然一次都没有裁剪， 说明 S3=否 只是裁剪的必要条件，不是充分条件，这一点必须在 benchmark 的确定性维度里 体现——一套只靠单一信号就下裁剪结论的规则集，本身就与真实数据不符。
S4 · 是否存在多个决策干系人
定义：完成这个任务的"为什么做"，是否需要向不止一类读者（如业务方/验收方/技术方）分别 说明理由，且理由内容因读者而异。
判定方法：
- 原文显式提到需要说服/汇报的第二方角色（如"给投资人看""需要产品经理确认""向客户展示 以获得续约"），判"是"；
- 任务描述通篇只面向单一执行链路（读文档→产出→自验收），未提及任何需要独立说服的第二方， 判"否"。
关联决策方向：BRD 的语义本身是"why"，其存在价值在于向不同于 PRD 读者的另一批人 解释做这件事的理由。S4=否 是"BRD 可以合并进 PRD 前言段而非独立成节点"的必要条件之一； S4=是 时 BRD 不可裁——多方决策场景下，"why"往往需要独立于"what"存在，服务于不同的 审阅节奏。
Hunt 案例校准：C4 任务原文（"读 lemonboss 仓库文档+代码，产出静态官网"）通篇没有提及
任何"需要说服的第二方"，是单一执行链路，S4=否。但 C4 的真实结果是保留了 BRD——这与
"S4=否 支持裁剪"的方向恰好相反。规划记录给出的理由是"brd/prd/sdd 描述 why/how/what，
完全对应骨架语义"（knowhow C4 原文引用），也就是说规划者的实际依据是"骨架字面结构对应"，
不是对 S4 这类信号的真实评估。这正是 Hunt 汇总部分指出的问题所在：现有裁剪判断不是信号
驱动的，而是"骨架长什么样就填什么"的字面匹配，benchmark_v1.md D2（确定性/可复现性）
必须重点抓住这一失效模式。
S5 · 是否有可直接复用的成熟先例
定义：本次任务是否明确指向一个已经跑通过的历史规划记录/模板，可以直接复用其节点集合而 不必逐节点重新评估。
判定方法：
- 原文出现显式复用指令（"参考上次""复用XX的结构""按同样流程再做一次"），判"是"；
- 任务描述是全新目标、未提及任何历史参照，判"否"。
与 agent.md 已有判据的边界：这条信号不等于 agent.md Step4"重规划三选一"表格里
的 infra_flake 分支（knowhow B1 引用原文第三行）——那条判据处理的是"同一个任务因基础
设施故障重跑，直接复用上一版图"，属于同任务内部复用；S5 处理的是"不同新任务，但显式
声明要照抄某个历史规划"，两者判定条件不同，不能混用同一条规则。C3 的 retry2 案例
（knowhow C3）是前者的合规样板，不能当作 S5=是 的正样本使用。
关联决策方向：S5=是 时可以直接复用先例的节点集合（图形状+节点粒度），跳过逐节点独立 评估；但"复用"不等于"不判断"——必须先核实先例任务与本次任务在 S1-S4 上是否真的可比， 否则会退化成"抄骨架不判断"的偷懒行为（与 Hunt 块B Step4 原文"不加思考地照抄某个骨架原样 交回"是被明确禁止的这条约束精神一致，只是这里的对象是"历史规划记录"而非"骨架模板"）。
Hunt 案例校准：本仓库当前可查的 5 份规划记录里，没有一个显式声明"复用某历史规划" （C3 retry2 是同任务重跑，性质不同，前文已说明不能算作正样本）。S5 在仓库内0 个可核实 的正样本，如实标注为未核实——这条信号目前只能靠合成场景校准，留给下一阶段 （Evolver/Trainer）在构造训练样本时专门补一条"任务描述里出现'和上次一样'"的合成用例。
二、独立于信号存在的硬约束（不是复杂度信号，不能被裁剪判据覆盖）
以下两条不属于"复杂度信号"，是块B/块A交叉验证出的地基级约束，任何裁剪规则集都不能
让它们参与"要不要裁"的判断——这一点在 benchmark_v1.md D5（矫枉过正平衡）里单独考核：
- 五项校验（无环/单一入口/可达性/回退边标注/fail 兜底边，knowhow B1 约束一）—— knowhow 原文明确写"五项校验从不因任务简单而放松"（B1 关键约束段），这是结构合法性， 与任务内容复杂度无关。
- 数据契约级联检查（knowhow B2，
planner.jsonneeds 依赖链推导）——裁剪任何一个 有produces的节点前，必须先检查图内是否有其他节点的needs依赖它的产出 kind； 如果有，要么同步把该needs项改成required:false，要么把该 kind 从needs列表 里移除，否则会触发rule=data-contract被引擎拒绝（knowhow B2 逐条核实"砍掉brd会 发生什么"一节，全文摘录）。这条隐藏规则目前只写在system/work-graph-templates/README.md里，agent.mdStep4 的裁剪授权段没有提及，是本次调研发现的、值得后续补进 agent.md 的显式检查清单项（knowhow 文末"给下一阶段的建议方向" #3）。