.codebuddy/governance/ 治理层

读者：workshop / 项目 / 团队的负责人，而非单个开发者或 Agent。

本层目的：从"执行层"（rules + skills）升一层，提供团队维度的通用治理框架。任何一份文档都必须满足"拷到新团队/新项目直接能用"的判据，不含具体技术栈细节。

 Leader 视角   ←── governance/      （本层）治理与复盘框架
     ↑               ├── delivery-lifecycle.md    流程契约
     │               ├── quality-dashboard.md     质量仪表盘
     │               ├── retrospective-sop.md     复盘 SOP
     │               ├── architecture-fitness.md  架构健康度
     │               └── tooling-landscape.md     管理工具全景
     │
 Agent 视角    ←── skills/          可复用工作流模板
     ↑
 开发者视角    ←── rules/           强制约束规则
     ↑
 档案/历史     ←── rules/.archived/ 反馈归档

分层原则：

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

上述 5 份文档的事件证据都沉淀在同一个地方：

📁 rules/.archived/feedback/README.md —— FB 归档索引（状态机 / 模板 / 转化率算法 / 与 LESSONS 反模式双向映射）

与治理文档的关系：

 retrospective-sop.md  ─── 产出机制 ──→  FB 归档（事实源）
                                          ↑  ↑  ↑  ↑
        delivery-lifecycle ──流程断点──┘  │  │  │
        quality-dashboard  ──#18 转化率──┘  │  │
        architecture-fitness ──技术债触发──┘  │
        tooling-landscape ──告警/单点失效──┘

FB 归档虽然文件位置在 rules/.archived/（历史原因），本质上是治理层的第六份核心文档——它是所有上述 5 份治理文档引用的唯一事实源。

• 周一：读 quality-dashboard.md，核对上周门禁指标
• 周五：按 retrospective-sop.md §1 轻量周会 做 15 分钟团队复盘

• 每月：architecture-fitness.md §健康度自评表 打一次分
• 每季：按 retrospective-sop.md §2 阶段复盘 做一次深度复盘

• 发生严重事故：立刻按 retrospective-sop.md §3 事故复盘 启动，产出 FB 归档
• 工具链/技术栈变更：按 architecture-fitness.md §演进触发条件 走升级流程
• 交付流程卡壳：对照 delivery-lifecycle.md 找出哪个阶段的"入/出/SLA"被打破

1. 整份 governance/ 目录直接拷贝
2. 根据新团队规模、工具偏好调整 tooling-landscape.md 中的工具名（TAPD → Jira、企微 → Slack 等）
3. delivery-lifecycle.md 的 6 阶段结构保留，具体命令/工具替换
4. quality-dashboard.md 的指标表保留，数值按新项目基线初始化（棘轮策略，见 rules/testing-standards.md §1.3）

判据：整份 governance 层没有任何项目专属类名、业务模块名、具体工具商标（Maven/Gradle 之类可以出现但必须标注"示例"）。