# 自我验证样本 v1 — workgraph-planning-methodology-trial

> 对应任务书用户步骤6，套用 `SKILL.md` v1（100分定稿版）的决策流程。
> 两个样本复杂度梯度差异明显：样本1是全公司唯一与 Step4 裁剪例句直接可比的
> 真实历史案例，样本2是构造场景（**非真实历史案例**，下文已按要求显式标注）。

---

## 样本1：回归案例 C4（p-v1mpcl / T-mt1qx0c4-95bf，真实历史案例）

**task-goal 原文**（`hunt/knowhow_v1.md` C4 引用）：「读 lemonboss 仓库文档+代码，
产出 apple.com 风格的静态官网，讲清 why/how/what，含核心价值点、功能模块、
独特性说明，至少 3-4 张界面截图/示意图配说明」。

### 信号取值（复用 `digest/complexity_signals_v1.md` 自身给出的 C4 校准结果）

| 信号 | 取值 | 判定依据 |
|---|---|---|
| S1 | 1 | 全部内容共享同一个网站、同一套验收标准，单一交付物 |
| S2 | 是 | "至少3-4张界面截图/示意图配说明"是可枚举的具体数值清单 |
| S3 | 否 | 纯展示型静态页面描述，原文无持久化/多模块字样 |
| S4 | 否 | 通篇没有提及需要说服的第二方（投资人/产品经理/安全团队等），单一执行链路 |
| S5 | 否 | 未提及任何历史参照/复用指令 |

### 代入决策流程

1. **G2（S3门）**：S3=否 → 不命中，继续。
2. **G3（S5门）**：S5=否 → 不命中，继续（此样本写于 S1-S5 体系引入之前，
   也不存在"先例"这个概念本身，即便 S5 被误判为是，也会因为找不到标注过
   S1-S4 的先例记录而按 fallback 归为 S5=否）。
3. **逐节点判定**：
   - **brd**：查表 §2.1，`S4=否, S1=1, S2=是` → 命中第3行 → **裁剪**。
   - **prd**：§2.2 恒定 → **保留**。
   - **sdd**：§2.3，`S1=1`（且已知S3=否） → 内容**精简**，节点**保留**。
   - **benchmark**：§2.4 恒定 → **保留**。
   - **validator**：§2.5 恒定 → **保留**。

**最终结论：裁 brd，保留 prd/sdd(精简)/benchmark/validator。**

与任务书给出的预期结论一致（"预期：裁brd，因为S1=1/S2=是/S3=否/S4=否"）。

### 应用 §四 连带修正清单，重新验算五项校验

裁剪后节点：`prd, sdd, benchmark, validator`（4个）。边：

| from | to | condition | 其他 |
|---|---|---|---|
| prd | sdd | success | produces:[prd] |
| sdd | benchmark | success | produces:[sdd], needs:[prd] |
| benchmark | validator | success | produces:[acceptance], needs:[{kind:brd,required:false}, prd, sdd] |
| sdd | prd | fail | edgeKind:backward |
| benchmark | sdd | fail | edgeKind:backward |
| validator | prd | fail | edgeKind:backward, failReason:input_underspecified |
| validator | sdd | fail | edgeKind:backward |

（原 `prd --fail--> brd` 已按 §四 第2条删除。）

| # | 手工验算法 | 结果 |
|---|---|---|
| 1 | 划掉 backward 边，剩 `prd→sdd→benchmark→validator`，可排出拓扑序 | 通过 |
| 2 | forward 入度为0的节点：仅 `prd` | 通过（恰好一个） |
| 3 | 从 `prd` 沿 forward 边 BFS 覆盖 `sdd, benchmark, validator` | 通过（4个节点全覆盖） |
| 4 | `sdd→prd`、`benchmark→sdd`、`validator→prd`、`validator→sdd` 的 `to` 均排在拓扑序更早处，且都标了 `backward` | 通过 |
| 5 | 除入口 `prd` 外：`sdd` 有 `sdd→prd`（空failReason）兜底边；`benchmark` 有 `benchmark→sdd`（空failReason）兜底边；`validator` 有 `validator→sdd`（空failReason）兜底边（另一条 `validator→prd` 带 failReason，不计入但不冲突） | 通过 |

五项全部通过，`prd` 作为新入口按约束五例外条款无需额外配兜底边。

### 合理性检查

结论"裁brd、保留其余四个"符合直觉：这是一个单人产出、无需向第二方解释立项
理由、验收标准已经写清楚的静态网站任务，把"why"并入 PRD 前言段不会丢失信息
（原 C4 真实规划记录选择完整保留是"骨架字面结构对应"式判断，而非信号驱动，
`complexity_signals_v1.md` S4 段已指出这一点——本表刻意不重复这个失效模式）。
没有出现"简单任务被误判为要保留全部/复杂任务被误判为可裁"的情况。

---

## 样本2：构造场景（**非真实历史案例，用于压力测试规则的另一端**）

**task-goal 原文（构造）**：「多租户 SaaS 后台，含权限体系（多角色 RBAC）与数据
导出功能，需要向产品经理和安全团队分别汇报设计方案」。

### 信号取值

| 信号 | 取值 | 判定依据 |
|---|---|---|
| S1 | 1 | "权限体系"和"数据导出功能"是同一个后台系统内的两个功能模块，原文没有说
它们各自有独立的验收标准或独立受众，按 `complexity_signals_v1.md` S1 判定法
（"两个产出物只有在验收标准不同或受众不同时才分别计数"），算同一个交付物 |
| S2 | 否 | 原文只有"多角色RBAC""数据导出功能"这类定性描述，没有出现具体数字/
可穷举清单（没有说"3种角色""导出为CSV/Excel两种格式"这类可点名的清单） |
| S3 | 是 | "多租户""权限体系（多角色RBAC）""数据导出"均指向需要持久化存储
（租户数据、角色权限、待导出的业务数据）和多模块（权限模块+导出模块），命中
`complexity_signals_v1.md` S3 判定法里的"账号体系""对接接口/后端"类结构性字样 |
| S4 | 是 | 原文显式提到"需要向产品经理和安全团队分别汇报设计方案"——两类需要
独立说服/汇报的第二方角色，命中 S4 判定法 |
| S5 | 否 | 未提及任何历史参照/复用指令 |

### 代入决策流程

1. **G2（S3门）**：S3=是 → **命中**，直接判定**全部5节点保留**，决策终止，
   不再往下走逐节点判定。

（补充核对：即便不走 G2 短路、继续假设走到逐节点判定，§2.1 BRD 表里
`S4=是` 那一行同样独立给出"保留"结论——S3 和 S4 两个独立信号在这个样本上
互相印证，没有矛盾，这也说明 G2 门的短路不是掩盖了一个本会冲突的判断，
只是提前给出了同一个答案。）

**最终结论：全部5节点（brd/prd/sdd/benchmark/validator）保留，不裁剪。**

与任务书给出的预期结论一致（"预期：全部5节点保留，不裁剪"）。

### 五项校验

因为没有任何节点被裁剪，图与 `planner.json` 骨架原样一致，五项校验天然
满足（骨架本身已验证合法，不需要重新手工验算）。

### 合理性检查（矫枉过正压力测试）

这个场景刻意设计了两个会让"裁剪判据"过度敏感的诱饵：
- 如果规则集只看 S1/S2/S4 这类"内容形态"信号而忽略 S3，可能会因为"S4=是"
  之外没有仔细检查 S1（单一后台系统，容易被误判成"简单交付物"）而错误地
  在 benchmark/sdd 上打折扣；
- 如果规则集的裁剪判据里没有把 S3 设成最高优先级的硬门，可能会在"这是一个
  后台管理系统，描述听起来不算复杂"这种主观印象下裁掉不该裁的节点。

本表的 G2 门直接堵死了这两种矫枉过正的可能——只要 S3=是，不管 S1/S2/S4
如何组合，都不会进入任何裁剪分支，验证了 §五（`benchmark_v1.md` D5 矫枉过正
平衡）声称的"地基级约束不受信号组合影响"在这个复杂样本上确实成立，没有
出现"复杂场景被错误裁剪"的情况。