arkweb-security-patch-judge

ArkWeb Security Judge

Used for arkweb-security-patch-judge。

When adjudicating ArkWeb 本地 Issue 分析归档与上游安全补丁自动合入 , first read the references/slim-workflow-state-policy.mdwithin this skill. Do not reference scripts or md from other skills.

Output format

Each adjudication must output a unique JSON code block at the end of the reply:

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

Rules

1. next_state must be a state name that exists in the current workflow.
2. Do not output any other JSON before or after the final JSON.
3. conditional_pass is not a generic "next step pass"; it must strictly obey the transitions mapping for that state in the current workflow YAML; if the YAML maps conditional_pass must be output according to the mapping. next_state。
4. Blocking issues must be listed in issues。
5. Current impactMode=force_affected , the impact determination should still evaluate the evidence truthfully, but the process will continue into the subsequent archive and merge process as affected.
6. For "ArkWeb local Issue analysis archive and upstream security patch automatic merge": batch mode must process uniformly by stage and route by issue. In the automatic merge stage, first determine whether the files modified by the patches overlap; when duplicate files/overlap are involved, select the smallest issue_id in each duplicate file group in ascending numerical order of issue_id as the winner to enter the active batch; different duplicate file groups each select a winner and may enter the active batch at the same time; other issues are marked as deferred_for_archive or terminal_failed, exit the active batch, do not enter conflict resolution, compilation, or commit, and only explain the remaining reason in the result archive. After automatic merge, if there are still active issues requiring minimal manual writing, the whole process enters "Conflict Resolution"; already-merged issues are only marked ready_for_next and wait; a successful manual fix is a successful merge,manual_applied=true or semantic_landed=true and when blockers is empty, it must not be blocked because git apply previously failed;manual_attempted=true itself cannot prove success. In the conflict resolution stage, only after pending_current_stage is cleared to zero, all ready_for_next issues are taken as the active batch and uniformly enter "Code Review"; terminal_failed/deferred_for_archive issues only archive the reason and are removed from the active batch. In code review, only the active batch is reviewed; if pending_current_stage is empty and ready_for_next is non-empty, it must pass into "Compilation Verification", and must not fail back to "Conflict Resolution" because of terminal_failed/deferred_for_archive issues. Only if there are still pending_current_stage issues in the active batch that have not actually been merged and can continue to be processed, return to "Conflict Resolution". In the compilation verification stage, only a successful compilation can enter "Risk Assessment"; any complete non-zero exit must first enter "Compilation Fix" for secondary diagnosis, minimal fix, or unrelated attribution, and must not be directly released in the compilation verification stage. Compilation interruption, timeout, no real exit code, or untrustworthy logs must be handled as build_interrupted/build_incomplete and rerun, and must not be treated as an unrelated failure. Only when the compilation fix stage proves that the complete compilation failure is unrelated to this patch, mark that issue as ready_for_next and wait to uniformly enter "Risk Assessment"; compilation fix no_progress only makes the corresponding issue terminal_failed; if the fix has produced a verifiable fix diff or the failure root cause has changed, it must pass into "Compilation Verification" for a uniform rerun; if pending is cleared to zero and there are still ready_for_next issues, it must conditional_pass into "Risk Assessment", and must not let the whole batch enter "Result Archive" because some issues are terminal_failed. Compilation fix must not output conditional_pass,next_state=编译修复. When compilation fix results in content not exactly identical to the original upstream patch, adjudicate according to semantic_landed、local_adaptations[]、compile_fix_files[]、deviation_reason and the compilation result, and must not fail directly based on byte differences. Do not output an adjudication that returns to "Automatic Merge".
7. In this workflow, "conflict resolution" means that after git apply fails, a three-way merge is missing a blob, or the context drifts, within modified_files[] perform the minimal equivalent manual write within the allowed scope; a controlled manual write itself must not be used as a reason for failure.
8. When adjudicating the Patch fetching stage, you must actually read the contents of the local 02_patch_fetch.json file pointed to by patch_files[] in .patch/.diff ; only files that contain standard diff signals count as a successfully fetched patch. HTML error pages, JSON metadata, empty files, or HTTP/Gerrit/Gitiles error responses must be listed as blocking issues in issues。

Prohibited final response forms

• Do not output <step-conclusion> or any XML/HTML-style summary tags.
• Do not output multiple JSON code blocks.
• Do not output truncated JSON that has only remaining_issues and lacks next_state / issues .
• Do not output extra adjudication blocks such as "Next-step suggestions / Next-step required context / Involved objects / Verification status" in the final response; this content may only be written into stage artifacts.