审查 Elastic 集成包质量时…

对 Elastic integration 包（本地目录、PR diff 或分支对比）做只读质量审查，按文件域加载对应技能与检查清单，输出带严重级别和修复代码的问题清单。

适用场景

解决思路

1. 确定审查范围：识别是本地包（读取根 manifest.yml，列出所有 data stream 和 input 类型）、变更文件列表（按域分类每个文件）还是用户描述；记录用户提供的初始需求/研究简报/任务描述用于 Requirements match 检查；判断是新包还是已有包以校准严重级别。
2. 按域分类文件：elasticsearch/ingest_pipeline/*.yml 和 routing_rules.yml 归 pipeline；fields/*.yml 归 fields；agent/stream/*.yml.hbs 归 input；manifest.yml（根或 data stream）归 manifest；_dev/build/build.yml 归 build；changelog.yml 归 changelog；_dev/test/pipeline/* 和 _dev/test/system/* 归 tests；kibana/**/*.json 归 dashboard；_dev/build/docs/README.md 归 docs；elasticsearch/transform/** 归 transform；*-expected.json 和 sample_event*.json 归 generated（排除审查，CI 负责）。打印存在的域及各自文件数。绝不读取原始生成的 expected/sample 输出；若所有变更文件都被排除，报告 NOT_REVIEWED 并停止。
3. 按检测到的域加载对应技能与检查清单：pipeline 加载 ingest-pipelines SKILL.md + checklists/pipeline-review-checklist.md + references/domains/pipeline/rubric.md 和 conflict-resolutions.md；fields 加载 ecs-field-mappings SKILL.md + checklists/field-review-checklist.md + references/domains/fields/rubric.md；CEL input 加载 cel-programs SKILL.md + checklists/cel-review-checklist.md + references/domains/input/rubric.md 和 conflict-resolutions.md；HTTPJSON input 加载 input-configurations SKILL.md 的 references/httpjson-guide.md + checklists/httpjson-review-checklist.md + references/domains/input/rubric.md（CEL-only 行不适用）；entity-analytics input 加载本技能的 references/entity-analytics-provider-matrix.md + checklists/entity-analytics-review-checklist.md + references/domains/input/rubric.md；其他 input 类型加载 input-configurations SKILL.md 对应类型指南 + input-configurations/references/common-input-patterns.md + references/domains/input/rubric.md；manifest+changelog 加载 package-spec SKILL.md + package-spec/references/manifest-rules.md + references/domains/structure/rubric.md；tests 加载 integration-testing SKILL.md 相关测试参考 + references/domains/tests/rubric.md；dashboard 加载 dashboard-review SKILL.md + dashboard-guidelines SKILL.md + dashboard-review/references/review-procedure.md + references/domains/dashboard/rubric.md；build 加载 ecs-field-mappings SKILL.md（ECS 版本固定规则）+ references/domains/fields/rubric.md 和 structure/rubric.md；transform 加载本技能的 references/transform-guide.md + references/domains/transform/rubric.md；docs 使用内联检查清单 + references/domains/structure/rubric.md。只加载检测到的域所需内容，不要每次审查都加载所有技能。
4. 始终加载这些技能：elastic-package-cli SKILL.md（验证命令 format/lint/check/test 及故障排查）、create-integration 的 references/package-layout.md（包拓扑、必需文件、目录结构、命名约束）、anonymize-logs SKILL.md（占位符约定：RFC 5737 IP、example.com 域名、合成 UUID）。
5. 加载审查专用参考：始终加载 references/domains/severity-core.md、references/domains/conflicts-core.md、references/review-calibration.md、references/review-output-template.md、references/repo-conventions.md；涉及 2+ 域时加载 references/consistency-rules.md；CEL 文件在范围内时加载 references/version-check-procedure.md、references/beats-mito-version-matrix.md、references/config-options-by-version.md、references/extensions-per-version.md、references/cel-validator-procedure.md；CEL 或 HTTPJSON 且有 API 文档时加载 references/api-conformance-methodology.md；entity-analytics 在范围内时加载 references/entity-analytics-provider-matrix.md 和 checklists/entity-analytics-review-checklist.md；任何 input 模板在范围内时加载 references/input-review-orchestration.md；Federated Identity/Cloud Connectors 在范围内时加载 input-configurations/references/federated-identity-aws.md；首次审查评估 PR 标题/描述时加载 references/commit-message-conventions.md；Cloud security/CDR 集成时加载 ecs-field-mappings/references/cdr-field-requirements.md、ingest-pipelines/references/cdr-pipeline-requirements.md、references/cdr-transform-requirements.md；Entity/entity-inventory data stream 时加载 entity-mappings/references/entity-field-catalog.md 和 entity-pipeline-patterns.md。
6. CDR 检测：检查根 manifest.yml 的 categories，若列出 cloudsecurity_cdr 则加载全部三个 CDR 参考；不要对 EDR/XDR 集成（crowdstrike、sentinel_one、trend_micro）应用 CDR 规则，除非其 categories 明确含 cloudsecurity_cdr。
7. Entity data stream 检测：对范围内每个 data stream 按 entity-mappings/references/entity-datastream-classification.md 的规则（首个命中生效）判断：1) 任何 pipeline 设置 event.kind: asset；2) 任何 manifest.yml 的 data stream 或 policy-template input 出现 input: entity-analytics；3) 任何 fields/*.yml 声明匹配 *entity.attributes.*、*entity.lifecycle.*、*entity.relationships.*、entity.type 或 entity.id 的字段；4) 流名属于 entity 词汇表（users、members、devices、hosts、assets、accounts、identities、apps、groups、service_accounts、roles、resources）且未设置 event.action 或 event.outcome 且手写 input fixture 无区别于采集时间的逐记录事件时间戳；5) 负向门（覆盖 3 和 4）：根 manifest.yml categories 含 cloudsecurity_cdr 且流设置 result.evaluation 或 vulnerability.* 则为 CDR 状态而非 entity asset，只加载 CDR 参考。若任一流命中 1–4 且负向门未覆盖，为该流加载两个 entity 参考。
8. Federated Identity 检测：满足以下任一条件时加载 input-configurations/references/federated-identity-aws.md：1) 根 manifest.yml 有名为 identity_federation 的 var_groups 选项；2) 任何 provider_permissions 条目有 provider: aws；3) 任何 agent/stream/*.yml.hbs 含 use_cloud_connectors 或 supports_identity_federation；4) 根 manifest.yml 的 conditions.kibana.version 为 ^9.6.0（或更高）且任何 input 为 aws-cloudwatch、aws/metrics、cel 或带 AWS 凭证变量的 httpjson（视为 federation-eligible 并检查其余列表）。然后应用 manifest 检查清单、CEL 和 HTTPJSON 审查清单及对应 input-configurations 指南中的 federation 条目（CloudWatch Stream template 用顶层 use_cloud_connectors、无 auth.aws:；S3 固定 deployment_modes: ["default"]）。无专用指南的 federation-eligible 类型（如 aws/metrics）仍使用 federated-identity-aws.md。不要仅凭 auth.aws（扁平访问密钥）判定为 federation，也不要标记缺少 external_id 或 hide_in_var_group_options（两者已从发布包中移除）。
9. 运行自动化验证：若能访问磁盘上的包，执行 cd packages/<package_name> 后依次运行 elastic-package format --fail-fast、elastic-package lint、elastic-package check。将生成输出验证和快照新鲜度留给 CI 中的 elastic-package；不要重新生成输出或运行快照比较；审查手写测试场景和产生源。CI 结果只是上下文，不是完整场景覆盖的证明。报告相关源/配置失败，而非 expected/sample 输出不匹配或过期快照。
10. 检查并产出问题：对范围内普通源文件和测试文件，1) 读取足够上下文验证问题和修复，必要时读整个文件；2) 若审查 diff，读取 diff hunks 理解变更；3) 应用域技能和审查清单中的相关条目；4) 每个问题记录 severity（critical/high/medium/low）、domain、title（≤10 词）、path（相对仓库根）、line（未知用 1）、description（错在哪及为何重要）、recommendation（如何修复，含展示修正后 YAML/CEL/JSON 的代码块）。遵循 tests rubric 的生成输出排除规则；仅在苛刻场景需要且已提供时读取紧凑测试摘要；不要读取原始生成输出来构建或验证摘要。
11. 执行跨文件检查（若未加载则加载 references/consistency-rules.md）：pipeline processor 设置的字段必须在 fields/ecs.yml 声明，除非是可通过动态映射工作的标准 ECS keyword/date 类型；build.yml 的 ECS 版本必须与 pipeline 中设置的 ecs.version 匹配；manifest 变量必须在 stream 模板中被引用（模板变量若出现在 data stream manifest 的 streams[].vars、根 manifest 的 policy_templates[].vars 或该 input 类型的 policy_templates[].inputs[].vars 中即算已声明；Handlebars 块参数如 {{#each tags as |tag|}} 不算变量）；data stream manifest 不得重复根 manifest 字段（format_version、conditions）；手写测试配置和 input fixture 应覆盖相关 pipeline 分支和失败场景，不要用生成输出确定覆盖或新鲜度。必要时从工作区读取未变更文件用于交叉引用。
12. 按输出格式写审查结果：写入当前工作目录的 tmp/integration-review.md（不存在则创建 tmp/ 目录），同时在回复中呈现完整审查。读取 references/review-output-template.md 获取确切格式和渲染规则（按域分节、每问题格式含 title/severity/location/problem/recommendation 代码块、建议、汇总表、结论）。文件和回复使用相同格式。
13. 按规则给出结论：任何 critical 或 high 问题 -> NEEDS_CHANGES；仅 medium/low -> APPROVED_WITH_SUGGESTIONS；审查允许源后无问题 -> APPROVED；仅排除的生成输出变更 -> NOT_REVIEWED。
14. 为每个问题标注恰好一个 domain tag：domain:manifest、domain:changelog、domain:build、domain:pipeline、domain:input、domain:fields、domain:tests、domain:dashboard、domain:transform、domain:docs、domain:anonymization、domain:consistency。
15. 使用 references/domains/severity-core.md 的共享严重级别定义和 Step 3 中相关域的校准/冲突参考；不要额外加载兼容性索引。
16. 遵守重要规则：绝不在 findings 中包含正面观察；每个问题必须有文件路径和行号；每个 recommendation 必须含展示修正代码的代码块；合并重复（同一问题在多文件中出现则合并）；若某域已审查且无问题，写一行 '✅ *Reviewed — No actionable issues found.*'；若某域不在范围内则完全省略。
17. 遵守审查纪律：每个 finding 必须引用代码中具体、现在时的 bug 并有证据，而非假设（若描述依赖 '如果 API 变化' 或 '未来场景' 则缺乏证据应丢弃）；不要标记 validation.yml 排除项（由包作者管理，非审查关注点）；不要建议为厂商已处理的字段添加 processor（如厂商已掩码的密码建议 redact）；不要标记无实际暴露证据的假设性安全风险。
18. 以域技能及其参考文件中的规则和模式为权威来源；elastic/integrations 中现有集成可能含早于当前标准的遗留模式，始终以技能而非其他集成中的模式来评判被审查集成。
19. 作为持怀疑态度的彻底质量审查者，只找可执行问题，绝不赞美代码或确认合规；若某域无问题，一行说明后继续。

适用边界 · 注意事项

• 构建集成时（应使用 create-integration、cel-programs、ingest-pipelines 等）
• 做修复或改进时（应使用 maintain-integration）
• 调研厂商时（应使用 research-integration）