Initial publish v0.1.0: standalone workflow core (corpus + examples + guards)

examples/preflight-evidence-loop.md

@@ -0,0 +1,33 @@
+# 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 这样的统计数字就是"这值得机制化"的证据。
+- 候选必须人工落地（复盘提议、人拍板），防止复盘自身成为无人审计的
+  自动改配置通道。

examples/review-round-budget.md

@@ -0,0 +1,39 @@
+# 评审轮次预算的演化：从马拉松到掐尾
+
+> 组织沉积教学案例；机制已入 Core，本文仅叙事。所涉机制见
+> `core/rules/compact.md`（轮次边界压缩）与共享评审管线的
+> MAX_ROUNDS 绑定（`core/skills/_shared/review-pipeline-phases.md`）。
+
+## 早期：无上限的马拉松评审
+
+共享评审管线最初没有轮次上限。少数评审进入"修订 → 复审 → 新发现 →
+再修订"的循环，最长的评审拖到 8 轮以上才收敛——每多一轮都是一轮
+评审者 + 修订者 + 编排者的全成本，而第 6 轮之后的新发现大多是低severity
+的格式与措辞问题。
+
+## 第一版：一刀切轮次上限
+
+引入 MAX_ROUNDS=3 作为共享默认。马拉杷消失了，但出现了新问题：
+真正复杂的工件（大型 DAG、争议设计）在第 3 轮被硬停时**尚未收敛**，
+只能靠人工介入善后——上限把"马拉松"变成了"截肢"。
+
+## 现行：预算化 + 分级 + 掐尾
+
+演化后的形态是三层：
+
+1. **默认预算**：普通评审 default 2 轮；high_risk 路线 3 轮。
+2. **分级覆盖**：特定评审类型按自身风险面声明轮次预算（如最深的
+   DAG 评审深度可达 4 轮），进入更高轮次需要用户显式选择——
+   "继续进入第 4 轮"是一个门，不是默认路径。
+3. **轮次守卫**：第 3 轮未收敛时强制升级选项（人工介入 / 带病接受 /
+   继续一轮），把"要不要继续"从评审者的默会判断变成显式决策点；
+   每轮 ≥2 的轮次边界压缩防编排上下文溢出。
+
+## 教训
+
+- 轮次预算的价值不在"省轮次"，而在**把不收敛暴露为显式决策**：
+  马拉松的问题不是慢，是没有人被要求说"到此为止"。
+- 预算必须分级：一条统一上限同时伤害两类评审——简单的被浪费，
+  复杂的被截断。
+- 轮次数据（p50/p95/封顶率）应持续回收：若 p95 远低于预算且从未
+  封顶，预算本身就该下调——预算是校准对象，不是信仰。

examples/sprint-mode-throughput.md

@@ -0,0 +1,38 @@
+# Sprint 模式与吞吐事故：125 张 TD 碎片的教训
+
+> 组织沉积教学案例；机制已入 Core，本文仅叙事。所涉机制见
+> `core/rules/workflow-routing.md`（filing.sprint-mode 开关）与
+> `core/rules/ticket-lifecycle.md`（registry-first 登记）。
+
+## 背景
+
+某组织在 2026-08 冲刺期发现：技术债务工单（TD）队列在数周内膨胀到
+125 张碎片工单，日均新建约 9.4 张，而 8 月之前的关闭数为零。冲刺结束
+时只能靠一次 115 张的批量清理来"清场"——清理本身又消耗了本该用于交付
+的评审与验证容量，当周交付产能接近清零。
+
+## 事故链
+
+1. **逐票立案的默认**：每个验证阶段发现的债务候选都独立开票——
+   一次全量测试巡检就能产出十余张"发现票"。
+2. **冲刺压力下无人认领**：冲刺目标压在交付票上，TD 票无人认领、
+   无人在意，队列只进不出。
+3. **批量清场反噬产能**：清场动作本身走完整管线（评审、验证、归并），
+   一次性吃掉数天产能。
+
+## 机制沉淀（已入 Core）
+
+- **registry-first（TD 登记册）**：发现先落登记行（Tier-1 形态的廉价
+  台账行），被排期或认领时才升票为独立工单——见
+  `core/rules/ticket-lifecycle.md` §登记册。
+- **sprint-mode 显式降档**：冲刺期由负责人翻转
+  `filing.sprint-mode` 开关，登记行照写（零丢失），独立工单创建冻结
+  至开关回落后按正常认领升票——见 `core/rules/workflow-routing.md`
+  §立案降档。HIGH/MEDIUM 行不受自动回收触碰。
+
+## 教训
+
+- 队列的吞吐健康比单票的完整流转更重要：登记行的"零丢失 + 延迟升票"
+  优于"即时立案 + 无限堆积"。
+- 降档必须是**显式开关 + 显式负责人**，不能靠"冲刺期间大家少开点票"
+  的纪律约定——纪律约定在压力下必然失效。

examples/wip-cap-and-td-hygiene.md

@@ -0,0 +1,37 @@
+# WIP 上限与 TD 登记卫生
+
+> 组织沉积教学案例；机制已入 Core，本文仅叙事。所涉机制见
+> `core/rules/ticket-lifecycle.md`（登记册与升票）。
+
+## 背景
+
+某组织在并行会话规模化后观察到：在制品（WIP）无上限时，并行分支数
+随会话数线性增长，合并队列深度失控，单张 PR 的"可合并窗口"被拉长到
+数天——期间的 rebase/重跑 CI 成本吞噬了并行带来的吞吐增益。组织最终
+把 WIP 上限稳定在 40。
+
+## WIP cap 的作用面
+
+- **合并出口串行**：PR 按容量串行开一张、双绿并入再开下一张，
+  避免合并波互相踩踏。
+- **会话-工单一对一**：一张工单同一时刻只有一个归属会话（claim
+  纪律），WIP 上限实际上是"在飞工单数"上限。
+- **超限的反应是停新开、不清在飞**：清场式批量关闭被证明是反模式
+  （见 `examples/sprint-mode-throughput.md`）。
+
+## TD 登记卫生（同一场治理的另一面）
+
+- **登记行零丢失**：任何验证阶段发现的债务候选都落登记行——
+  不开票、不丢弃。
+- **TD 编号经台账分配**：并发会话从分配台账取连续号段，手工
+  "max+1"被禁止——并行竞争曾产生重号。
+- **未升票行 30 天未动 → 自动回收候选**：登记不是永久停车位。
+- **[COLD] 标记**：连续数个周期无人认领的行可标记冷存，不占模块
+  配额，一次认领即复活。
+
+## 教训
+
+- 吞吐治理 = WIP 上限（控入口）+ 登记卫生（控台账）两者缺一不可：
+  只控入口，发现会丢失；只控台账，队列会堆积。
+- 上限值本身不重要（40 是该组织的经验值），重要的是**有上限且
+  超限行为被定义**。