社媒危机响应预案：分级、暂停队列、声明库与复盘

当社媒舆情爆发或需要提前制定危机预案时，建立1-5级严重度阶梯、暂停发布规则、预批声明库、发言人矩阵与复盘流程。

适用场景

解决思路

1. 先判断模式：预案起草（无实时事件）、实时事件分级、或解除响应（stand-down）。先做两项路由检查：若 memory/launch-registry/ 显示处于发布窗口，交给 launch-day-conductor 并停止；若事件属于邮件送达类（被列入黑名单、垃圾邮件率飙升），交给 deliverability-qa 并停止。
2. 建立1-5级严重度阶梯：每级都要有触发阈值、指定负责人、首要动作、声明类别和更新节奏。默认触发条件（均为估算值，由用户调整）：提及量达到7天基线的3x/5x/10x 分别对应2/3/4级；抽样中持续出现情绪反转；记者或监管机构联系 = 至少3级；员工行为或安全类 = 至少4级。若无基线，速度行标为 NEEDS_INPUT，转给 social-pulse-monitor 重建，而不是凭空编造。
3. 写下并留痕「首要机械动作」规则：2级及以上，先暂停所有已排期帖子和付费推广，再起草声明。由人工在每个渠道/排期工具/广告平台各执行一次动作，并记录回执（执行人、时间、状态、平台证据）。暂停标记或已指派负责人不等于已暂停；任何缺失/部分/未知的回执都让该渠道保持 OPEN 并升级。标记单独提交给 registry 做对账。遵循 Social Human Action and Rights Control。
4. 建立预批声明库：每个场景族（产品故障、员工行为、账号被盗、品牌不实信息）和每个严重度级别各一条预批声明，每条都要有指定审批人和承诺的更新节奏（“下次更新不晚于<时间>”——错过承诺更新本身就是一次事件）。声明中任何产品/优惠主张必须与 claims ledger 一致；新措辞通过授权 operation: propose 请求提交到 registry-events.py 写入 memory/events/claims.ndjson，绝不直接写进声明。
5. 写下「何时不发帖」规则：无关内容保持暂停；3级及以上绝不争辩；法律/监管联系转交法务；不做静默删除。每次下架/删除都是独立动作，每个在线位置各留一份回执；缺失删除回执则队列保持开放。
6. 指定发言人/审批矩阵：按级别明确谁起草、谁审批、谁发布、谁对媒体发言，每项各有一名指定备份。把它接入收件箱升级路径，使 engagement-inbox-manager 的分类最终落到本阶梯，而不是落到一个无名的“升级”。
7. 执行解除响应（stand-down）：在全部解除后，对账暂停标记，把原队列包按原哈希重新跑一遍预发布门禁，再由人工逐个渠道解除暂停，每个动作各留一份回执。不要仅凭一条解除暂停提案就宣布 stand-down 完成；缺失回执保持开放。
8. 填写复盘模板并汇报：时间线、触发准确性（阈值是否在正确时刻触发）、声明更新节奏遵守情况、阈值重调建议，以及交接摘要。每个数字都标注为 Measured / User-provided / Estimated。
9. 交付后询问：“是否保存这些结果供未来会话使用？”确认后保存到 memory/social/crisis-response-planner/YYYY-MM-DD-<topic>.md。暂停/解除标记及任何渠道状态事实只能通过授权 operation: propose 请求提交到 registry-events.py 写入 memory/events/channels.ndjson（channel-registry 是 memory/channels/ 的唯一写入者）；声明主张措辞只能通过授权 operation: propose 请求提交到 registry-events.py 写入 memory/events/claims.ndjson。

适用边界 · 注意事项

• 邮件送达类事件（黑名单、垃圾邮件率飙升）——应使用 deliverability-qa。
• 处于进行中的发布窗口内——事件处理由 launch-day-conductor 负责。