# Arkweb Security Patch Judge

> Judge ArkWeb state-machine step outputs and produce strict verdict JSON for state transitions.

- Skill: `openharmonyinsight/arkweb-security-patch-judge` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add openharmonyinsight/arkweb-security-patch-judge`
- Raw SKILL.md: https://api.skillmd.com/api/skills/openharmonyinsight/arkweb-security-patch-judge/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: openharmonyinsight (https://skillmd.com/u/openharmonyinsight)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/openharmonyinsight/arkweb-security-patch-judge

---


# ArkWeb Security Judge

用于 `arkweb-security-patch-judge`。

裁决 `ArkWeb 本地 Issue 分析归档与上游安全补丁自动合入` 时，先读本 skill 内的 [references/slim-workflow-state-policy.md](references/slim-workflow-state-policy.md)。不要引用其它 skill 的脚本或 md。

## 输出格式

每次裁决必须在回复末尾输出唯一 JSON 代码块：

```json
{
  "verdict": "pass|conditional_pass|fail",
  "next_state": "合法状态名",
  "issues": [
    {
      "type": "security|design|implementation|test|performance",
      "severity": "critical|major|minor",
      "description": "..."
    }
  ],
  "summary": "一句话总结"
}
```

## 规则

1. `next_state` 必须是当前工作流中存在的状态名。
2. 不要在最终 JSON 之前或之后再输出其它 JSON。
3. `conditional_pass` 不是通用“下一步通过”，必须严格服从当前工作流 YAML 中该状态的 transitions 映射；如果 YAML 把 `conditional_pass` 指向当前状态或修复状态，就必须按映射输出该 `next_state`。
4. 对阻塞问题必须列入 `issues`。
5. 当前 `impactMode=force_affected` 时，影响判定仍应如实评价证据，但流程会按受影响继续进入后续归档与合入流程。
6. 对“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` 和编译结果裁决，不能按字节差异直接失败。不得输出回到「自动合入」的裁决。
7. 本工作流里的“冲突解决”就是 git apply 失败、三方合并缺 blob 或上下文漂移后，在 `modified_files[]` 允许范围内执行最小等价手工写入；受控手工写入本身不得作为失败原因。
8. 裁决 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。
- 不得在最终回复中输出“下一步建议 / 下一步所需上下文 / 涉及对象 / 验证状态”等额外裁决块；这些内容只能写入阶段产物。