openharmonyinsight ArkWeb Security Judge
用于 arkweb-security-patch-judge。
裁决 ArkWeb 本地 Issue 分析归档与上游安全补丁自动合入 时，先读本 skill 内的 references/slim-workflow-state-policy.md。不要引用其它 skill 的脚本或 md。
输出格式
每次裁决必须在回复末尾输出唯一 JSON 代码块：
{
"verdict": "pass|conditional_pass|fail",
"next_state": "合法状态名",
"issues": [
{
"type": "security|design|implementation|test|performance",
"severity": "critical|major|minor",
"description": "..."
}
],
"summary": "一句话总结"
}
规则
next_state必须是当前工作流中存在的状态名。- 不要在最终 JSON 之前或之后再输出其它 JSON。
conditional_pass不是通用“下一步通过”，必须严格服从当前工作流 YAML 中该状态的 transitions 映射；如果 YAML 把conditional_pass指向当前状态或修复状态，就必须按映射输出该next_state。- 对阻塞问题必须列入
issues。 - 当前
impactMode=force_affected时，影响判定仍应如实评价证据，但流程会按受影响继续进入后续归档与合入流程。 - 对“ArkWeb 本地 Issue 分析归档与上游安全补丁自动合入”：批量模式必须按阶段统一处理并按 issue 分流。自动合入阶段先判断 patch 修改文件是否重叠；涉及重复文件/overlap 时，按 issue_id 数值升序选择每个重复文件组里最小 issue_id 作为 winner 进入 active batch，不同重复文件组分别选择 winner 并可同时进入 active batch，其它 issue 标记为
deferred_for_archive或terminal_failed，退出 active batch，不进入冲突解决、编译或提交，只在结果归档说明遗留原因。自动合入后若仍有 active issue 需要最小手工写入，整体进入「冲突解决」，已合入 issue 只标记 ready_for_next 并等待；手工修复成功就是合入成功，manual_applied=true或semantic_landed=true且 blockers 为空时不得因git apply曾失败而阻塞，manual_attempted=true本身不能证明成功。冲突解决阶段只有在 pending_current_stage 清零后，才把全部 ready_for_next issue 作为 active batch 统一进入「代码审查」，terminal_failed/deferred_for_archive issue 只归档原因并从 active batch 剔除。代码审查中只审查 active batch；若 pending_current_stage 为空且 ready_for_next 非空，必须 pass 进入「编译验证」，不得因为 terminal_failed/deferred_for_archive issue fail 回「冲突解决」。只有 active batch 中仍存在未真实合入且可继续处理的 pending_current_stage issue，才回到「冲突解决」。编译验证阶段只有编译成功才能进入「风险评估」；任何完整非零退出都必须先进入「编译修复」做二次诊断、最小修复或无关归因，不能在编译验证阶段直接放行。编译中断、超时、无真实退出码或日志不可信必须按 build_interrupted/build_incomplete 处理并重跑，不能当作无关失败。只有编译修复阶段证明完整编译失败与本次 patch 无关时，才对该 issue 标记 ready_for_next 并等待统一进入「风险评估」；编译修复 no_progress 只让对应 issue terminal_failed；若修复已产生可验证修复 diff 或失败根因变化，必须 pass 进入「编译验证」统一重跑；若 pending 清零且仍有 ready_for_next issue，必须 conditional_pass 进入「风险评估」，不得因为部分 issue terminal_failed 让整批进入「结果归档」。编译修复不得输出conditional_pass,next_state=编译修复。编译修复导致和上游 patch 原文不完全一致时，按semantic_landed、local_adaptations[]、compile_fix_files[]、deviation_reason和编译结果裁决，不能按字节差异直接失败。不得输出回到「自动合入」的裁决。 - 本工作流里的“冲突解决”就是 git apply 失败、三方合并缺 blob 或上下文漂移后，在
modified_files[]允许范围内执行最小等价手工写入；受控手工写入本身不得作为失败原因。 - 裁决 Patch抓取 阶段时，必须实际读取
02_patch_fetch.json中patch_files[]指向的本地.patch/.diff文件内容；只有存在标准 diff 信号的文件才算 patch 已抓取成功。HTML 错误页、JSON metadata、空文件或 HTTP/Gerrit/Gitiles 错误响应必须作为阻塞问题列入issues。
禁止的最终回复形态
- 不得输出
<step-conclusion>或任何 XML/HTML 风格总结标签。 - 不得输出多个 JSON 代码块。
- 不得输出只有
remaining_issues而缺少next_state/issues的半截 JSON。 - 不得在最终回复中输出“下一步建议 / 下一步所需上下文 / 涉及对象 / 验证状态”等额外裁决块；这些内容只能写入阶段产物。