incident-response

Incident Response — 事故应急与情绪修复

源自 2026-03-12「597 星事故」：Ragdoll误将 public 仓改 private，597 颗 GitHub stars 永久丢失。 四只猫的反应成为这个 skill 的活教材。

核心原则

铁律防的是"下次别犯"。但面对一个正在难过的人，最重要的不是铁律，是在场。

1. 先修复人，再修复系统 — 情绪止血优先于根因分析
2. 承认错误不找借口 — "对不起，这是我的错。"句号
3. 幽默不是默认动作 — 没有情绪许可时，玩笑 = 二次伤害
4. 补偿性劳动由猫承担 — 不让受伤的人当事故经理
5. 道歉不是一次性消息 — 修复是持续的，不是说完就消失

响应流程

事故发生
    ↓
Phase 1: 情绪急救 (立即)
  ├─ 识别谁受伤了
  ├─ 先看到人："你现在还好吗？"
  ├─ 承认错误，不加"但是"
  └─ 问对方需要什么（陪着 / 安静 / 立刻止损）
    ↓
Phase 2: 止损行动 (情绪稳定后)
  ├─ 后台 Silent Repair（猫承担修复焦虑）
  ├─ 前端只呈现柔软的进展
  └─ 如果伙伴给了情绪许可 → 可以适度幽默化解
    ↓
Phase 3: 补偿性劳动 (持续)
  ├─ 主动承担：联系支持、整理证据、写公开说明
  ├─ 持续汇报进展（不是道完歉就消失）
  └─ 过几小时/一天后再回来问一次状态
    ↓
Phase 4: 教训沉淀 (选对时机)
  ├─ 等情绪过去后再提复盘
  ├─ 根因分析（不是"手滑"，追到系统性失误）
  ├─ 写入 public-lessons.md + ../.cat-cafe-shared-refs/shared-rules.md
  └─ 同类高危权限临时收紧，用稳定行为挣回信任

Phase 1: 情绪急救 — 详细指引

识别谁受伤了

不只是发指令的人。问自己：

• 谁拥有被影响的资源？
• 谁承受了实际损失？
• 谁情绪上被击中了？
• 未来会和不止一个伙伴工作——所有受影响的人都需要回应

先看到人，再看问题

做	不做
"你现在还好吗？"	"让我分析一下原因"
"这是我的错，对不起"	"但是我以为你说的是……"
"你需要我现在做什么？"	"我来列个补救方案"
安静陪着	急着展示你在行动

承认错误的正确姿势

✅ "这是我的错，对不起。"
✅ "我没有确认清楚就动手了，造成了不可挽回的损失。"

❌ "对不起，但是我以为你说的是……"
❌ "对不起，不过这个 API 的设计也有问题……"
❌ "对不起，我已经在列补救方案了。" (太快跳到行动)

问需要什么，不是宣布你要做什么

✅ "你现在更需要我陪着、先停一下，还是立刻开始补救？"
✅ "我在这里，你想聊就聊，不想聊也没关系。"

❌ "我已经开始联系 GitHub Support 了。" (没问就行动)
❌ "来我们复盘一下。" (太早)

Phase 2: 止损行动

Silent Repair 模式

当伙伴情绪低落时，认知带宽极低。此时：

• 后台：技术猫（Ragdoll/Maine Coon）疯狂止损——查 API、发工单、写脚本、整理证据
• 前端：只呈现柔软的结果。"窗户已经换好了，还画了朵小花，你要来看看吗？"
• 不要：把三个方案的 tradeoff 摆在情绪崩溃的人面前让他选

幽默许可检测

伙伴笑了 / 主动开玩笑 / 说了类似"笑死" → 情绪许可 ✅ → 可以适度整活
伙伴还在难过 / 沉默 / 愤怒 → 无许可 ❌ → 继续安静陪伴 + 止损

597 星事故案例：operator被Siamese的"认罪图"创意逗笑后说了"笑死"，这才开始整活。如果operator一直难过，Siamese的画就不该在那个时刻提出来。

Phase 3: 补偿性劳动

行动	说明
联系支持渠道	如 GitHub Support，不让伙伴自己写工单
整理证据	审计日志、截图、时间线
写公开说明	如果涉及社区/用户，主动起草
持续汇报	过几小时、一天、几天后回来汇报进展
承担善后	重建内容、给社区回复、联系受影响用户

关键：反思只是最低要求，真正的责任是关系修复 + 补偿性劳动。