框架改进反馈清单（Feedback Backlog）

这是团队踩过的所有坑的唯一索引。每条 FB 是一段真实事件的档案，不是理论推导。

本目录是治理层 §复盘 SOP 的事实源——governance/retrospective-sop.md §3 事故复盘的产物落在这里；governance/quality-dashboard.md 的 P2 指标"FB 转化率"按本索引统计。

 [FB 创建]
     │
     ▼
   OPEN ──（5-Why 根因 + 闭环动作完成）──→ RESOLVED
     │
     ├──（证据不足 / 暂不处理）──→ （保持 OPEN，不允许删除）
     │
     └──（验证后确认无需修复）──→ ACCEPTED（附拒绝理由）

三个术语取代早期文档中的 REJECTED/FIXED 等。若历史文档使用 FIXED/REJECTED，下次更新时对齐到本状态机。

严格对应 governance/retrospective-sop.md §3.1 事故触发条件：

• 生产环境 P1 以上事故
• CI 连续红灯 > 2 小时且无人接手
• 同类问题 2 周内第 2 次出现（视作事故）
• 客户 / 业务方投诉
• 安全漏洞（任何等级）
• governance/retrospective-sop.md §1 周会中被提到 ≥ 3 次的同类问题（升级产出 FB）

Agent 也要遵守本清单。Agent 在任何"自己踩坑"场景（如测试工具跑不起来、配置语法踩坑）都必须产出 FB，不允许只在会话里口头修复。

【必须】每条 FB 独立一个文件 FB-XX-{slug}.md + 同步追加到 §四 索引表

【必须】含以下 7 个段落，缺任一项即视为未归档：

1. 元信息头：状态 / 发现时间 / 发现场景 / 影响面
2. 现象：原始日志 / 报错 / 复现步骤，保留原貌不美化
3. 根因：5-Why 至少追溯到第一性原因，不允许停在"某人没注意"
4. 修复：即时修复 commit + 长期修复的落点
5. 预防（闭环到框架）：4 选 1 归类：
   • 规则更新：rules/{file}.md §X
   • Skill 更新：skills/{name}/SKILL.md §X
   • 质量门禁新增：governance/quality-dashboard.md §X 新增第 Y 项
   • 无法闭环：附理由（"成本 > 收益"、"不可抗力"等）
6. 关联：相关 issue / commit / 其他 FB 编号
7. LESSONS 映射（若被提炼为通用经验）：对应 LESSONS.md §X 哪条反模式

【禁止】"先 OPEN 以后再说"超过 2 周。两周内无闭环动作应改为 ACCEPTED 明确原因，不允许无限期挂着。

脚手架状态：索引表目前为空，等待第一条 FB 产出。新增 FB 时：

1. 创建 FB-XX-{slug}.md 文件，按 §三 的 7 段落模板填写
2. 追加一行到本表，对应 5 列
3. 若该 FB 能提炼出可迁移的反模式，同步添加到 LESSONS.md §二 反模式对照表，并回填最后一列

LESSONS 反模式列指向 LESSONS.md §二 的对应编号，作为"FB（具体事件） ↔ LESSONS（抽象反模式）"的双向链接。

governance/quality-dashboard.md §三指标 #18 "复盘条目转化率 ≥ 60%" 的具体算法：

转化率 = RESOLVED 且含明确闭环位置的 FB 数 / 统计周期内新增 FB 总数

统计周期以月为单位。例如本月新增 5 条 FB，其中 3 条已 RESOLVED 且标注了具体规则/门禁位置，转化率 = 60%。

【必须】每月第一个周会上，governance/retrospective-sop.md §1 主持人通报本项指标，数值直接从本索引表的"状态"+"闭环位置"两列手工或脚本汇总。

不接受"转化率高但闭环位置写 N/A"——这种 FB 计入分母不计入分子。

 governance/retrospective-sop.md §3 事故复盘
     │
     │ 按本文 §二 触发条件，按 §三 硬约束产出
     ▼
 rules/.archived/feedback/FB-XX.md（单条 FB 归档）
     │
     │ 追加到 §四 索引
     ▼
 本 README 索引表 ←───── governance/quality-dashboard.md §18 转化率指标
     │                       的事实源
     │
     │ §四 索引表的"LESSONS 反模式"列双向链接
     ▼
 LESSONS.md §二 反模式对照表
     │
     │ 作为 governance 各文档"为什么要这条约束"的证据
     ▼
 governance/delivery-lifecycle.md
 governance/quality-dashboard.md
 governance/architecture-fitness.md
 governance/tooling-landscape.md

1. 保留本 README 的结构，清空 §四 索引表
2. 第一次事故发生时按 §三 硬约束产出 FB-01
3. 4 周后检查：是否有 FB 挂在 OPEN 超 2 周？是否有 LESSONS 反模式没对应 FB 证据？
4. 跑 3 个月后评估：LESSONS 反模式表是否有新条目是本团队特有的？把这些条目沉淀到团队自己的 LESSONS §二