octopus-workflow/examples/preflight-evidence-loop.md

Preflight 证据闭环：66 次命中 / 31 张工单的统计

组织沉积教学案例；机制已入 Core，本文仅叙事。所涉机制见 core/rules/workflow-routing.md（routes.{Kind}.preflight）。

背景

一次跨周期复盘对首轮评审 FAIL/WARN 发现做了根因归类统计：某类根因在 观察窗口内累计命中 66 次，分布在 31 张不同工单上——同一类上游失误在 评审门被反复拦截，每次拦截都支付一轮评审 + 一轮修订的双倍成本。

统计闭环的构造

1. 数据面：每张多轮评审工单的首轮 FAIL/WARN 发现，按 （维度 × 根因标签）归类。
2. 阈值判定：命中次数与去重工单数同时过阈值的根因，成为 pre-flight 候选（生产者侧自检项）。
3. 落点：候选人工落入路由表 routes.{Kind}.preflight，由 implement 技能在派发开发子代理前注入自检清单。
4. 老化退出：落地后连续 N 个干净首轮 → 移除行，避免清单无限膨胀。

为什么有效

• 评审门的发现是最真实的上游质量信号——它就是下游实际会犯的错。
• 把拦截点前移到写代码之前，成本从"评审轮 + 修订轮"降到"自检一行"。
• 阈值（样本量 + 复现工单数）挡住了偶发噪声，只沉淀系统性根因。

教训

• 复盘的价值不在罗列问题，而在把重复出现的问题变成机制： 66/31 这样的统计数字就是"这值得机制化"的证据。
• 候选必须人工落地（复盘提议、人拍板），防止复盘自身成为无人审计的 自动改配置通道。