openharmonyinsight ArkWeb Security Review
用于 arkweb-security-patch-reviewer 和 arkweb-security-patch-judge。
审查阻塞边界、手工改写是否可放行、非 active issue 如何处理，先读本 skill 内的 references/patch-landing-review-contract.md。不要引用其它 skill 的脚本或 md。
审查重点
- active batch 中给定 patch 是否已经真实合入到当前工程目标 git 子仓。
- 最终变更是否覆盖给定 patch 的目标修改文件和关键 diff 语义。
- 是否存在未解冲突、空 diff、合错仓/合错文件、范围外改动或明显遗漏关键 hunk 的情况。
- 手工改写是否仍在
modified_files[]或合入报告允许范围内。
阻塞边界
代码审查阶段只裁决 active batch 中“给定 patch 是否合入”。以下情况才能作为阻塞问题：
- 给定 patch 未应用，或最终 diff 为空。
- 关键 hunk、关键文件或关键语义缺失。
- 改动越过
modified_files[]或合入报告允许范围。 - 合错仓、合错文件，或目标子仓不匹配。
- 存在未解决冲突。
以下情况不是本阶段问题，不得作为阻塞或 fail 原因：
git apply因上下文漂移失败后，在modified_files[]范围内完成最小手工改写。- 手工改写带来的语义漂移担忧，但没有具体证据证明给定 patch 的关键语义缺失。
- 尚未进入编译阶段导致的编译或运行证据缺失。
如果要判阻塞，必须直接指向“给定 patch 没有合入”的证据，例如缺失的 hunk、缺失的关键文件、未解冲突或合入到错误仓库。
批量模式中，terminal_failed 和 deferred_for_archive issue 已经退出 active batch。代码审查只能在总览中把它们列为归档/遗留项，不能计入 blocked_issues，不能输出需要回到「冲突解决」的 issues，也不能因为这些 issue 让整批 fail。只要 pending_current_stage 为空且仍有 ready_for_next issue，审查裁决必须放行 ready 批次进入「编译验证」。
审查范围硬性限制
- 只审查本次 patch 实际修改的文件，文件列表应来自合入报告、冲突解决报告、编译修复报告或明确的本次 patch diff。
- 审查前必须读取自动合入阶段输出的
06_merge_result.md；批量模式还必须逐个 issue 读取issues/{issue_id}/06_merge_result.md。自动合入pass后这些文件应当已经存在；如果缺失，必须标记为artifact_missing:06_merge_result，不能假设 patch 已合入。 - 批量模式必须逐个 issue 审查，读取
issues/{issue_id}/06_merge_result.md、issues/{issue_id}/07_conflict_resolution.md、issues/{issue_id}/10_build_fix.md和当前工程目标子仓中属于该 issue 的 git diff。 - 批量模式禁止使用 git worktree；不同 issue 的改动、风险和结论不得混写。
- 工作区里的其它历史脏改、未跟踪文件、SDK、toolchain、构建产物、
src/out、.ace-outputs和无关删除必须忽略。 - 不得因为无关脏改给出 fail，不得要求清理无关文件，不得把无关脏改加入本次修复建议。
- 如果无法确认某个文件是否属于本次 patch，必须把它列为“待确认”，不能默认纳入审查范围。
输出
单 issue 模式审查步骤写入 .ace-outputs/{runId}/08_code_review.md。
批量模式每个 active issue 写入 .ace-outputs/{runId}/issues/{issue_id}/08_code_review.md，总览写入 .ace-outputs/{runId}/08_code_review.md。总览只能汇总，不得替代每个 active issue 的独立审查结论。非 active 的 terminal_failed / deferred_for_archive issue 只列入归档清单。
稳定脚本优先
优先使用内置脚本生成代码审查产物，不要在运行时拼接临时 Python/Node/Shell 脚本：
python3 skills/arkweb-security-patch-review/scripts/generate_code_review.py \
--run-root <context.projectRoot>/.ace-outputs/<runId>
脚本会读取 batch_status.json、06_merge_result.json 和 issues/{issue_id}/06_merge_result.json，为每个 active issue 写入 issues/{issue_id}/08_code_review.md，并写入根级 08_code_review.md 和 08_code_review.json。脚本只聚合 active/ready/pending issue；terminal_failed 和 deferred_for_archive 只进入归档清单，不参与 verdict。
脚本执行后，agent 回复只允许包含：
- 一句结果摘要；
- 产物路径；
- 最后一个完整 JSON 代码块。
不要在回复中粘贴脚本源码、完整工具输出、大段 06_merge_result 内容或完整 diff。详细证据只写入 08_code_review.md/json。
审查步骤和裁决步骤都必须在回复末尾输出最后一个完整 JSON 代码块。不要输出只有 remaining_issues 的半截 JSON；next_state 和 issues 不能省略。
{
"verdict": "pass|fail",
"next_state": "编译验证|冲突解决",
"issues": [],
"summary": "一句话总结"
}
JSON 判定规则：
- active batch 无阻塞、
pending_current_stage=[]且存在ready_for_nextissue 时，输出verdict=pass、next_state=编译验证、issues=[]。 - 只有 active batch 中存在给定 patch 未真实合入且需要回到最小手工写入的证据时，输出
verdict=fail、next_state=冲突解决，并在issues[]中列出具体 active issue 阻塞证据。 terminal_failed/deferred_for_archiveissue 只能写入归档清单，不得写入 JSONissues[]，不得影响verdict。