sql-merge-validate

name	sql-merge-validate
description	收到数据质量监控任务 monitorId（或落标检查任务 id）+ 合并预期描述，校验该任务所有规则包生成 SQL 的合并正确性（可合并/不可合并/抽样/分区/过滤条件/强弱/多规则包），终端逐包给 PASS/FAIL。发现缺陷转 defect-analyze 生成 bug。仅做静态扫描或写用例请转对应 skill。
argument-hint	<monitorId | 落标任务 id> + 合并预期
user-invocable	true
model	sonnet
effort	high

sql-merge-validate

校验数据质量/落标合并 SQL 的正确性。一次性 skill，脚本自包含于 scripts/，只读、不产文件。

工作流

flowchart TD
    A[monitorId 或落标任务 id + 合并预期] --> B[取参 AskUser：模式 dq 或 std，凭据，DB]
    B --> C[跑校验 run.py，得 verdict JSON]
    C --> D[读 verdict 字段：checks/customRules/globalFindings]
    D --> E[终端报告：逐包 8 维矩阵 + FAIL 证据]
    E --> F{有 FAIL 或 finding?}
    F -->|是| G[AskUser → 转 defect-analyze 生成 bug]
    F -->|否| H[结束：仅终端 PASS，不落盘]
    G --> H

1. 取参（AskUser）：模式（dq/std）、任务标识、baseUrl+cookie+X-Valid-Project-ID（dq）、 DB host/port/user/pass（默认 172.16.124.100:30882 / root，口令仅运行期传入、不落仓库），可选预期描述。
2. 跑校验：python3 scripts/run.py --mode <dq|std> --task-id <id> --host <h> --password <p> [--base --cookie --project-id] → 得到 verdict JSON。pymysql 缺失时先 pip install pymysql。
3. 读 verdict：解析 run.py 输出的 verdict JSON：checks（8 维，每维 PASS/FAIL/NA）、customRules （自定义 SQL 规则及 valid/defect）、globalFindings（白名单分歧等单列）。语义存疑时对照 references/ 复核。
4. 终端报告：逐包 8 维矩阵 + 每个 FAIL 的证据片段；8 维定义（①可合并 … ⑧规则SQL完整性）见 references/merge-rules.md 与 rule-dictionary.md。customRules 中 SQL 残缺（空/空 WHERE/悬空运算符）即 ⑧ FAIL，不放行。输出位置：仅终端 PASS/FAIL，不写入 feature 目录或落盘产物。
5. bug 联动：有 FAIL/finding → AskUser「是否转 defect-analyze 生成 bug/推禅道？」（推荐是）， 选是则带证据交接。

合并判定规则

flowchart LR
    K[DB merge_group_key] --> Q{非空且组内≥2?}
    Q -->|是| M[应合并]
    Q -->|否，空 key 或单条| I[应独立]

• 判定基准是 DB merge_group_key，具体阈值见上图。
• 文档白名单只用于发现「合并了规格外 function」（如 fn26）的 globalFindings，不左右 ①② 的 PASS/FAIL。
• 抽样：扫抽样表与脏数据 rand() 是独立信号；不可合并包可能扫抽样表却无 rand，不据此判 FAIL。

路由边界

• 纯静态 diff 扫描 → defect-analyze；写用例 → case-*；UI 自动化 → playwright-automation。
• DB 不可达 → 降级为「SQL 结构事实 + 预期文本」，并显式声明无法独立判定实际分组。
• std 落标当前环境无数据，仅结构校验，未端到端验证。

知识库

references/rule-dictionary.md、references/merge-rules.md、references/std-check-merge.md。