背景

前面 15 个 PR 的所有沉淀都是从开发者 / Agent 视角的"执行层"——回答"下一个写代码的人该怎么做"。但作为 workshop / 项目 / 团队的负责人，还需要一层回答"下一个 Leader 该怎么管"——这就是本 PR 新增的治理层 (governance)。

5 维度治理框架

新增 .codebuddy/governance/ 目录，6 份文档共 794 行：

三层架构

 Leader 视角   ←── governance/     （本 PR 新增）治理与复盘框架
     ↑               
 Agent 视角    ←── skills/          可复用工作流模板
     ↑
 开发者视角    ←── rules/           强制约束规则

分层原则：

• 上层不重复下层内容，只做导航与抽象
• 下层变更不引起上层级联修改
• 任一层的单条文档都应"拷到新项目可用"

抽象化判据达成

按 LESSONS §4"抽象化是可迁移的前提"：

治理层的核心产物

1. 交付流程 6 阶段契约

 ① 需求入口 → ② 需求扩写 → ③ 方案评审 →
 ④ 开发 & 测试 → ⑤ 合并 & CI → ⑥ 交付 & 复盘

每阶段显式五件事：入口条件 / 产出物 / SLA / 责任人 / 回滚点 / 失败处理。消除"靠默契推动"。

2. 三类质量门禁

• P0 硬门禁（9 项）：不通过阻塞合并，包括真实编译、CI 可执行性等
• P1 棘轮指标（5 项）：按 LESSONS §14 棘轮策略管理
• P2 健康度（5 项）：月度观测不阻塞（Lead time / CI 红灯修复 / PR review / FB 转化率 / 事故数）

3. 三档复盘机制

• 周会 15 分钟（3 问题 → 连提 3 次升级）
• 阶段复盘 1.5 小时（数据卡片 → 改进 4 选 1）
• 事故 48 小时内归档（FB 状态机：OPEN → RESOLVED / ACCEPTED）

改进项 4 选 1 强制：进规则 / 进 skill / 进 OKR / 明确拒绝。不允许"记录一下"。

4. 架构健康度自评

5 维度打分（禁止只打 3 和 4）：演进性 / 可测试性 / 可观测性 / 安全合规 / 工具链先进性。连续 2 月 ≤ 2 必须进入 OKR。

5. 管理工具全景

7 类工具 × 6 阶段 × 交接点。AI 辅助工具作为新类型纳入治理——Agent 产出强制 review、Agent 踩坑同样进 FB 归档。

改动总览

 9 files changed, 865 insertions(+), 7 deletions(-)

• 新增 .codebuddy/governance/ 6 份文档（794 行）
• .codebuddy/README.md 补三层分工表 + Leader 视角使用建议表
• LESSONS.md 新增 §六 治理层索引
• README.md 顶部入口表补"你是 Leader"一行

自举验证

• ✅ read_lints 0 错误
• ✅ 本地 Docker JDK 17 真实编译：15/15 单元测试 PASS + BUILD SUCCESS
• ✅ 抽象化扫描：0 处项目专属日期、0 处业务标识、工具名全部占位化

通用性声明

本 PR 的治理层内容与具体技术栈、PM 工具、CI 平台、AI 工具完全解耦。新团队落地 4 步：

1. 拷贝 .codebuddy/governance/ 目录
2. 填写 tooling-landscape.md §一 的 7 处工具占位符
3. 初始化 quality-dashboard.md 的阈值（棘轮策略）
4. 启动周会机制，4 周后复盘机制本身

迁移后无需修改任何硬约束、无需推翻任何方法论。