发布日应急备案：当日事故的三套预案
B 方向·OPC 最佳实践（执行件）。opc-premortem-ritual 找出交叉风险，opc-launch-runbook 是顺境剧本——本篇是当日事故的三套预案（certification 被拒/系统故障/恶意攻击）。
背景与问题
D-Day 当天最可能砸场子的三件事，各自的当日应对脚本要提前写好。
发现（预案设计，来自既有课题的组合）
预案 A：LINE OA 认证未通过 / Paddle 审核未过
- 概率与影响：认证合否理由非公开（japan-app-launch-basics）——可能卡在 D-30 才知道。
- 预案：无认证也可发布（认证徽章是信任加分项不是功能项）——发布照常、认证窗口持续沟通；Paddle 未过则 konbini/IAP 侧先行（japan-senior-payment-methods 的矩阵切换）。
- 沟通：不对外说明「认证中」（弱信号），只正常运营。
预案 B：系统故障（LLM API 故障/LINE 平台事故）
- 三层告警架构（japan-sms-fallback-alert）本身冗余——当日故障的应对：①降级模式声明（AI 功能暂停、人工值班）②status 页/LINE 一键通知③SLA 内补救承诺。
- solo 的现实：发布日当天不排任何不可逆动作（大促/送金/大额广告）——故障恢复期内无二级损失。
预案 C：恶意差评攻击 / 冒充仿冒
- 低价竞品/被拦截的推销业者可能的报复性差评——平台举报流程预先 bookmark（App Store/Play/LINE 的举报入口）；冒充 NTT 型诈骗反过来冒充我们（japan-call-blocking-basics 警告同构）——官网公告「当社を装った連絡に注意」模板预写。
- 判断纪律：真实差评 vs 攻击的区分交给数据模式（时间聚集性），回应永远礼貌+事实，不对喷（opc-feedback-triage）。
推测
- 三预案的共同点：当日的资源只够执行预案、不够创作预案——所有文案/入口/流程在 D-7 就位（opc-launch-runbook 的 T-7 行加三预案附件）。
结论
可行动启发：
- 三预案文档化进 runbook（每套=触发条件+当日动作+沟通模板，各半页）——D-7 就位，D-Day 只执行。
- 发布日「无不可逆动作」纪律：大促/汇款/大额投放永不排 D-Day——降低事故的二阶损失。
- 降级模式设计提前做：AI 功能可独立开关（feature flag，opc-ai-automation-2026 栈内）——故障时声明「AI 機能一時停止、记录機能は正常」而非全站宕机感。
- 攻击型差评的回应模板预写：礼貌+事实+不情感纠缠——写好放着，hopefully 永远用不上。
待办 / 下次继续
关联
- 执行件族：opc-launch-runbook（顺境）× 本篇（逆境）× opc-premortem-ritual（预演）；架构支撑 opc-ai-automation-2026、japan-sms-fallback-alert。