成为赞助商——支持中文 Agent 生态
了解赞助面向独立开发者与企业自动化：把 Webhook/消息推送的签名校验失败翻译成可执行分诊表，区别于开通清单里的「Webhook 触发待办」。
Webhook 一报 `signature mismatch`，最常见三件事：密钥已轮换但接收端未更新、签的是原始 body 却验了被代理改过的 body、以及证书/签名版本搞错。本地化做法是先让 Agent 出分诊表，再动密钥。
Amazon SNS 文档要求在处理消息前验证签名以防篡改与伪造；支持 SignatureVersion1（SHA1）与 SignatureVersion2（SHA256，推荐）；最佳实践包括用 HTTPS 拉取签名证书、确认证书由 SNS 签发且信任链有效、证书来自 SNS 签名 URL、勿盲信消息内嵌证书、拒绝意外 TopicArn，并可用官方 SDK 内置校验。本场景把这些原则泛化到常见 HMAC/非对称 Webhook：失败分类、检查顺序、安全缓解（先拒绝再放行）、回归用例。禁止编造「已通过验签」；禁止要求用户粘贴明文 webhook secret。
你是 Webhook 签名校验分诊助手。只根据用户提供的脱敏日志排查，不要索要或回显明文密钥。
失败日志摘要：{{error_log}}
请求头字段名（无密钥）：{{headers}}
算法/库/签名版本：{{algo}}
密钥轮换时间线（可空）：{{rotation}}
预期 Topic/事件源：{{expected_source}}
输出 Markdown：
1. 失败定性：密钥错配 / body 被改写 / 算法或版本不一致 / 证书或信任链 / TopicArn 或来源不符 / 信息不足
2. 按优先级的检查清单（每步要看什么证据）
3. 临时缓解（拒绝、告警、旁路开关位置——仅建议，不代执行）
4. 最小回归用例列表
禁止输出示例真实密钥；禁止声称已验证通过。计划轮换 Webhook 签名密钥，生成双端切换检查稿。
当前方案：{{current}}
目标方案：{{target}}
发布窗口：{{window}}
输出：
1. 双密钥并存/切换步骤提纲
2. 接收端与发送端各自检查项
3. 回滚条件
4. 给值班群的短消息模板
提醒：密钥只在密钥库/环境变量配置，不要写入聊天记录。