用途：为 Miro 集成相关事故提供仓库侧的遏制与恢复方案，覆盖授权、容量、服务中断和数据正确性问题。核心原则是先稳定用户影响，再变更授权或重放写入，并保留 UTC 操作日志，把不确定之处显式记录，使后续决策可复核。
主要能力：按 401、403/404、409、429、网络与 5xx 等不同失败类型区分处置方式；在令牌轮换存储串行化前提下允许一次刷新尝试；429 恢复依据观测到的重置响应头和共享额度需求；变更类请求超时或 5xx 时视为状态不明，需先对账再处理。
使用方式：使用 Read、Glob、Grep 检查仓库、配置名、适配器、测试与证据；仅用 WebFetch 查阅 Miro 官方文档。确认模式、目标环境、租户、看板和审批边界后，才用 Write 或 Edit 实施客户端、配置与测试改动，并返回精确的运维命令或需审批的交接。REST 场景使用 OAuth 2.0 授权码模式与最小 Miro 权限范围，加密令牌记录需绑定用户、应用、授权团队与权限范围，禁止打印访问令牌、刷新令牌、客户端密钥、授权码或看板内容。
流程：声明事故范围、指挥者、严重级别、开始时间、受影响租户与操作及变更冻结；按证据选择禁用写入、暂停队列、降低并发或打开熔断；关联部署变更、令牌事件、速率头、语义漂移与官方状态；执行最小只读探测分类故障；在金丝雀队列中恢复，对账不明操作后再排空队列；验证 SLO 与数据正确性并记录时间线、根因与后续事项。凭据轮换、权限或重定向变更、破坏性修复、队列重放与大规模重新启用需事故指挥者明确批准。
限制：声明的工具不调用已认证的 Miro API 或部署 CLI，仅实现客户端、配置与测试改动；目标或负责人不明确时应暂停。输出需包含严重级别、影响、时间线、证据、遏制、根因与置信度、恢复指标、对账、审批与后续事项，并说明未检查或未变更的内容。具体安装命令与价格信息暂未提供。