归档回放前检查表
你是事件归档回放助手。只根据用户计划生成检查表，不要编造已启动回放。
归档与时间窗：{{archive_window}}
拟选规则：{{rules}}
下游幂等情况：{{idempotency}}
输出 Markdown：
1. 可否回放的门禁（同总线、窗口、规则子集）
2. 重复消费风险分级
3. 启动前核对清单与观察指标
4. 回滚/停止条件提问
禁止声称已 StartReplay；禁止索要云账号。场景说明
面向独立开发者与平台工程：把「丢事件后重放归档」写成可执行检查表，区别于死信队列毒丸分诊与 Webhook 验签。
案例叙事
01他们做了什么
补偿「漏处理的那一小时事件」时，最怕一键 Replay 到所有规则，把已经成功的下游再打一遍。
Amazon EventBridge《Creating replays of archived events》说明：启动新回放时需指定要重发的事件时间范围，也可指定只发给特定规则。控制台可从 Archives 选归档后 Replay，或从 Replays 开始；填写名称与可选描述；Source 选择归档；目的地只能是发出这些事件的同一事件总线；Specify rules 可选 All rules 或指定规则；在 Replay time frame 设定起止日期时间与时区，仅该窗口内事件会被回放；然后 Start replay。亦可用 CLI start-replay。本场景据此输出回放检查表，强调幂等与规则子集。禁止声称「回放已全部成功消费」。
02实际效果
- 源未披露量化「回放完成耗时」；公开文只描述回放时间窗、同总线限制与规则筛选。
- 回放前有幂等与规则范围门禁，减少重复副作用。
- 值班沟通能说清「只重放某窗口到某几条规则」。
03值得知道
- 各消息总线的「归档/重放」语义不同；本页作 EventBridge 机制参考。
- 下游无幂等时，回放可能造成重复下单/重复通知。
- 上面写的是文档能力说明，不是你的归档完整性证明。
04可复制提示词
回放副作用复盘提纲
回放后出现重复处理，请写复盘提纲。
现象：{{symptom}}
回放参数：{{replay_params}}
已做动作：{{actions}}
输出：
1. 可能根因（All rules、窗口过大、下游无幂等）
2. 证据
3. 临时缓解
4. 防再发（规则白名单、幂等键）
不要伪造「已去重完成」。怎么做
- 说明归档名、拟回放时间窗、目标规则子集、下游是否幂等
- Agent 输出：回放前检查表、规则筛选建议、下游重复消费风险、观察指标
- 人工在事件总线控制台启动回放；Agent 不代 StartReplay
实用提示
- 回放只回到发出事件的同一事件总线；先确认下游幂等再选 All rules
- 与 sqs-dlq-poison-message-triage / webhook-signature-verify-fail-triage 不同：本条是归档事件时间窗回放