用途：在 Procore 集成发生事故时，先区分服务商故障、身份失败、租户路由缺陷、权限漂移、速率耗尽、事件投递缺口与内部发布回归，再选择恢复动作，保护施工数据完整性。
主要能力：按六步流程执行——稳定（暂停高风险写操作、保留持久队列、停止重试风暴、只做有界只读取证）、分类（对比 Procore 状态与路由级 401/403/404/422/429/503、延迟、Webhook 投递与积压信号，按发布、环境、公司、项目、操作切分）、边界测试（用目标主体与公司上下文做一次只读连接验证，检查应用连接、DMSA 权限、允许项目、启用工具与速率头）、窄范围缓解（回滚坏发布、修复租户路由、仅在凭据证据支持时重新授权或轮换、降低并发、禁用受影响写路径）、数据恢复（确定缺口窗口、幂等重放持久工作、执行 REST 对账，校验记录数与状态哈希后再恢复下游发布）、收尾复盘（监控至目标恢复，记录根因与后续项，仅保留脱敏证据并设删除计划）。
使用方式：事故探针默认沿用现有 OAuth 2.0 主体，除非已证实身份失败是根因；令牌、客户端密钥、目标头与签名 URL 不得进入事故时间线或聊天。用 Read 与 Grep 检查遥测、配置、运行手册与脱敏日志；Write 或 Edit 仅用于已批准的缓解、恢复产物、时间线或回执，涉及服务商的重要变更需事故指挥官与管理员确认。输出分类、范围、时间线与缓解决策，缺口窗口对账与一致性证据，根因、回滚、后续项与脱敏事故回执，并返回当前严重级别、客户影响、安全动作、负责人、恢复信号与下一检查点。
适用场景：Webhook 在接收方停机期间投递失败等集成事故。
限制：资料未提供具体命令、代码示例、收费与平台支持信息；原因不明时应保持写操作暂停并补充一次有区分度的只读观察，事件缺口未知时应将范围扩大到最后一个可信检查点而非猜测。