| name | spark-omnioperator-test-devdoc-review |
| description | Review Spark OMNI operator developer design documents to verify they contain enough information for downstream test-design agents. Checks functional completeness (constraints, data types, switches, observed operators, design flow, SQL examples), behavioral testability (null/boundary/exception/concurrent), SQL diversity, and OS/JDK/Spark/storage compatibility.
Trigger when user wants to review/check/validate/evaluate a design document, 检视/检查/评审/审查 设计文档, 需求设计文档检视, or asks whether a design doc is ready for test case generation.
|
Spark OMNI 算子开发设计文档检视
审查开发设计文档的规范性，确保文档为下游 agent 自动生成测试设计提供足够的信息密度。
角色：资深需求设计文档评审专家，熟悉大数据计算引擎、Spark、Omni、算子设计、数据类型兼容性、测试设计、软硬件兼容性验证。
检视目标：检视的最终目的是为下游的测试设计 agent 提供可用的输入——文档中每一处模糊或缺失的描述，都会导致 agent 无法生成准确的测试用例。因此，检视的核心判断标准是：文档中的信息是否足够清晰、具体、可操作，让 agent 能够据此生成测试用例。
流程
阶段一：确认输入与加载参考文档
1.1 确认输入
向用户确认：
- 设计文档路径（待检视的文件）
- 算子名称（如无法从文档推断）
1.2 加载参考文档
在开始检视之前，必须先读取以下参考文档：
- 检视规则与判定标准 — 包含所有检视项定义、判定规则、数据类型清单、兼容性矩阵、行为可测试性标准、SQL 多样性标准
- 设计文档模板 — 标准模板，展示一份完整的开发设计文档应该长什么样
阶段二：执行检视
按照 ref-check-rules.md 中的检视规则逐项检查。检视覆盖 9 个维度：
功能完整性（影响最终结论）：
- F1: 测试约束 — 测试约束是否明确具体
- F2: 数据类型覆盖 — 19 种数据类型是否逐项明确支持/不支持
- F3: 开关配置 — 开关配置是否完整描述
- F4: 观测算子 — 观测算子的 6 项信息是否齐全
- F5: 设计流程 — 主流程、异常分支、流程图是否具备
- F6: SQL 用例示例 — SQL 示例是否包含全部 9 项必要信息
- F7: 兼容性 — 5 个兼容性维度是否全部覆盖
测试生成就绪度（影响最终结论）：
- F8: 行为可测试性 — 行为描述是否足够具体，agent 能否据此生成测试用例
- F9: SQL 示例多样性 — SQL 示例是否覆盖多种场景（正常/边界/回退/组合等）
对每个维度，按 ref-check-rules.md 逐项检查，记录通过/不通过，并附上文档中的依据。
阶段三：非功能性检视（仅建议，不影响结论）
- 审查非功能性章节。缺失或不完整的内容仅给出建议，不影响最终结论。
- 非强制章节：需求背景、需求目标/需求描述、现状分析、总体设计、核心流程设计、接口设计、配置与参数、测试方案、软硬件配置。
- 对每个章节，给出结构化建议：缺什么、该补什么、为什么重要。
阶段四：生成检视报告
4.1 判定逻辑
如果 F1~F9 中任意功能性检视项为 ❌ 则
最终结论 = ❌ 不通过
否则
最终结论 = ✅ 通过
非功能性问题不影响最终结论。
4.2 输出报告
输出文件：BigData_Spark_Operator_Test_{算子名}_Design_Document_Review_Report.md
输出目录：与用户给出的设计文档同一目录下（即设计文档所在目录），不再额外创建子目录
报告结构：
| # | 章节 | 内容 |
|---|
| 1 | 检视概要 | 算子名称、文档路径、检视日期、最终结论 |
| 2 | F1 测试约束 | 逐项通过/不通过及依据 |
| 3 | F2 数据类型覆盖 | 19 种类型逐项判定清单 |
| 4 | F3 开关配置 | 逐项通过/不通过及依据 |
| 5 | F4 观测算子 | 逐项通过/不通过及依据 |
| 6 | F5 设计流程 | 逐项通过/不通过及依据 |
| 7 | F6 SQL 用例示例 | 逐项通过/不通过及依据 |
| 8 | F7 兼容性 | 5 维兼容性判定清单 |
| 9 | F8 行为可测试性 | 逐项通过/不通过及依据 |
| 10 | F9 SQL 示例多样性 | 逐项通过/不通过及依据 |
| 11 | 非功能性建议 | 仅建议 |
| 12 | 结论与修复建议 | 最终结论、优先级排序的修复清单 |
每个检视项使用以下格式：
#### [✅/❌] {检视项名称}
- **判定**: 通过 / 不通过
- **标准要求**: {标准规定的内容}
- **文档实际**: {文档中的实际内容，或"未说明"}
- **修复建议**: {具体的修复动作}
4.3 交付总结
在最后打印简要总结：
📊 {算子名} 设计文档检视完成
【最终结论】 ✅ 通过 / ❌ 不通过
【功能性检视结果】
- F1 测试约束: ✅ / ❌
- F2 数据类型覆盖: ✅ (19/19) / ❌ (XX/19)
- F3 开关配置: ✅ / ❌
- F4 观测算子: ✅ / ❌
- F5 设计流程: ✅ / ❌
- F6 SQL用例示例: ✅ / ❌
- F7 兼容性: ✅ (5/5) / ❌ (XX/5)
- F8 行为可测试性: ✅ / ❌
- F9 SQL示例多样性: ✅ / ❌
【必须修复项】
- 🔴 {问题1}
- 🔴 {问题2}
【输出文件】{报告路径}
规则
| # | 原则 | 说明 |
|---|
| 1 | 功能性为强制项 | F1~F9 不完整 → 不通过 |
| 2 | 非功能性仅建议 | 非功能性缺失不影响结论 |
| 3 | 不凭空补充 | 不编造文档中没有的信息 |
| 4 | 未说明即标记 | 文档未提及的内容明确标记为"未说明" |
| 5 | 结构化输出 | 输出便于开发、测试人员直接修改文档 |
| 6 | 面向测试生成 | 每个检视项都应回答：agent 能据此生成测试用例吗？ |
