Release Inspection Skill (上线巡检)

对需求的灰度/上线结果做巡检：采集证据 → 按比对原则分析 → 生成分层评估报告 → 经 dingtalk-notify 按需求级机器人配置推送。

巡检比对原则（必须遵守）

1. 同环境比对，同词（或同条件）比对
   • 指标比对必须在同一个环境内进行（灰度 vs 灰度、线上 vs 线上），且使用同一个关键词或同一组查询条件。
   • 禁止跨环境比对作为指标（如 线上 vs 灰度、UAT vs 生产）：不同环境的服务配置（Pod 副本数、资源限额、缓存、数据量、流量）不一致，差值混杂环境差异，不能归因于代码变更。
   • 跨环境数据只能作为背景参考，输出时必须标注「跨环境，仅供参考，不作为指标」，且不得写入性能结论的指标行。
   • 合法对照示例（均在同环境内、同词/同条件）：
     • 同环境发布前后对照：同词耗时在时间维度上的前后对比
     • 同环境冷查 vs 热查：缓存未命中 vs 命中
     • 同环境同时刻并发对照：不同用户同一时刻查同词（排除用户身份因素）
     • 灰度内新旧逻辑命中对照：同请求内命中新逻辑 vs 未命中新逻辑的分段耗时

（后续比对原则按编号继续追加在本节。）

2. 先核范围，再下结论（「未找到 ≠ 未完成」）
   • 判断某服务/链路/字段「未改造、未完成」之前，必须先核实需求范围：auto-flow getDeployChecklistsByDemandId（或 getDemandInfoByLeftJoin 反查 demandId）→ openspec/设计规格/需求单。范围内没有的链路，其字段缺失/旧格式属「范围外现状」， 只能作背景观察，禁止写入需求完整度缺口或异常点。
   • 日志中搜不到预期字段 ≠ 该改造未做：可能是字段名/文案与搜索词不一致（如展示文案「费用 $x 起」实际落字段 deliveryFee）、日志级别未开 TRACE、 采样窗口内无命中、或业务上本就不输出（超配送范围/打烊/活动态）。 搜不到时必须先换字段名/文案/时间窗复查，仍无则在报告标注「未能观测 + 原因」， 结论用「需补数复核」，不得直接判「未完成」。
3. 推送确认制
   • 巡检结论为「明确完成」（范围内验证通过、可灰度/可全量）→ 允许自动推送。
   • 结论为「关注/阻断/需补数复核/未完成/存在未核实项」→ 必须先把报告展示给用户， 征得确认后再推送；用户明确说「发送/推送」视为确认。
   • 勘误重发不受去重限制，但需在 sendHistory 追加记录并注明勘误原因。
4. 多服务变更与数据变更检查（≥2 个服务时必做）
   • 部署顺序与部分失败：核实各服务灰度/发布先后（上下游兼容、新旧协议并存窗口）， 评估「部分服务已升级、部分未升级」时的兼容表现，结论落到「需求完整度」或「异常点」。
   • 降级评估：多服务链路必须评估降级/兜底行为（下游超时、上游回退、开关/灰度命中率）， 无法从日志核实的写「降级未联动验证 + 原因」，不得默认正常。
   • 数据库刷新：变更涉及 DDL/DML/数据订正/缓存刷新时，必须在报告「异常点」特别标注 「关注」，写明刷新内容、影响范围、可回滚性与验证证据；未核实的数据库变更视为阻断项。
5. 回滚检查按需输出，禁止模板化套话
   • 回滚/回退类条目仅当变更涉及以下场景时检查并输出：数据库 DDL/DML/数据订正、 缓存刷新、不可逆操作、核心链路（下单/支付/退款）。
   • 普通代码变更不要求「回滚方案」条目，正文禁止出现「回滚方案未提供」 「异常时无法快速回退」等与本次变更无关的模板化文案。
6. 推送正文禁止工具信息与无关套话
   • 推送正文不得出现任何工具/框架来源信息（如「flowmind」「由 xx 自动生成」等署名标注）， 报告只保留业务内容本身。
   • 未参与比对的联动数据源不逐条输出「未联动：…」说明；仅当证据缺口影响结论时， 才在对应段落用一句话说明缺口及影响。
7. 功能分支 + 代码 + 需求三方一致性对照（核心检查）
   • 巡检核心动作：功能分支（分支名/提交范围）↔ 分支上的实际代码变更 ↔ 需求/设计文档（设计规格、openspec）三方逐项对照，确认「分支改的 = 需求要的 = 文档写的」。
   • 仓库地址联动入口：语雀需求文档的「GIT」管理段（## GIT 下的仓库/分支清单）。 以该段声明的仓库 + 分支为排查范围，逐仓库核对分支 diff 与需求条目； GIT 段未列出的仓库，其相关条目（如依赖升级）在报告标注「仓库未在 GIT 段声明」。
   • 分支有实现但需求未要求 → 过度引入，写入「需求完整度」；需求有要求但分支未实现 → 遗漏，写入「需求完整度」或「异常点」。
   • 无法获取代码或需求文档时，按比对原则 2 结论用「需补数复核」，不得默认一致。

Workflow

1. 输入：需求 ID 或需求文档链接（可选：环境、时间窗、关注接口/关键词）。 【技改】类设计规格文档等同需求编号；该类编号并非唯一，须以文档标题 + slug 区分与归档， 报告标题/需求行直接用「【技改】xxx」。
2. 核范围（先于一切采集）：auto-flow 查需求单与部署清单，确定改动的服务/仓库清单； openspec/设计规格补充字段级验收口径；无数字需求编号时（如【技改】文档）， 以该文档为范围基准。范围清单写入报告「需求完整度」段。
3. 采集：按下节「联动数据源」三路并行采集 —— SLS 日志、代码 review、历史资源评估。
4. 分析：按上方比对原则构造对照；跨环境差值一律降级为参考，不进入指标行； 范围外链路只作背景观察（比对原则 2）；涉及 ≥2 个服务或数据库刷新时执行 比对原则 4 的降级/部署/数据变更检查。无法构造同环境对照时，结论必须写 「需补数复核」而不是给出劣化/优化百分比。
5. 报告：使用 dingtalk-notify 的评估报告模版（结论先行、五段式、A/B 明细最多 展开 5 条其余折叠），三路证据落到对应段落（见下节映射）。
6. 推送：按比对原则 3 的推送确认制执行；查 <workspace>/source/dingtalk-report-config.json 解析该需求的机器人（关键词校验、contentHash 去重、发送后回写 sendHistory）， 由 dingtalk-notify 发送。

多服务巡检并行模式（全局唯一 → 服务内各自并行 → 结果合并唯一）

范围核对（步骤 2）确认涉及 ≥2 个服务/仓库时，采集与分析按下述三段式执行：

1. 全局唯一：一次巡检只有一份主报告与一个结论状态，由主 agent 创建、汇总并唯一推送； 比对原则 3 的推送确认制只在合并后执行一次。
2. 服务内各自并行：每服务派发一个 readonly 子 agent 并行采集分析（同一条消息派发， 并发 ≤ 4，超过分批），各自只读：
   • 本服务的 SLS 日志 / 网关耗时（同环境同词，比对原则 1）
   • 本服务仓库分支 diff 与需求条目对照（比对原则 7）
   • 返回结构化发现：级别 / 位置 / 证据 / 结论，每项一行式，不写正文长文
3. 结果合并唯一：主 agent 合并去重、按比对原则统一定级；跨服务链路（部署顺序、 降级联动，比对原则 4）由主 agent 统一评估后产出唯一报告并统一推送； 子 agent 不单独落报告、不单独推送。

单服务需求不启用并行模式，按上方 Workflow 串行执行。

联动数据源

巡检报告必须三路联动采集，缺一路时在报告对应段落标注「未联动 + 原因」，不得留空。

历史基线使用约束：历史报告中的耗时数据必须与其采集环境一致才可作为对照基线， 并遵守比对原则 1（同环境、同词）；跨环境/跨时期历史数据只作背景参考。

Trigger Patterns

种子触发词（仅初始集合，实际触发以本地学习为准）：

"上线巡检", "发布巡检", "灰度巡检", "巡检比对", "巡检报告", "release inspection"

关键词触发本地化学习

• 生效触发词存于 ~/.flowmind/learning/scenes.json 的 scene-release-inspection （keywords + patterns → 路由到本技能），不在 SKILL.md 里维护。
• 学习闭环：用户用新说法成功触发巡检后，把该说法原样追加进该 scene 的 keywords（去重）；发现某触发词误路由（本意不是巡检）时移除，并在 ~/.flowmind/learning/records/release-inspection/ 记录原因。
• 学习记录：records/release-inspection/2026-08-20-001.json （scene_mapping 类型），绑定摘要见 skill-bindings.json 的 release-inspection 条目。

Notes

• 巡检报告的结论必须区分：同环境指标结论 vs 跨环境背景参考。
• 推送去重、关键词校验规则见 dingtalk-notify SKILL.md 的 Demand-level robot config 一节。