arkweb-security-patch-risk

ArkWeb Risk Assessment

Used for arkweb-security-patch-risk-assessor。

Output

Single issue mode writes .ace-outputs/{runId}/11_risk_assessment.md。

Batch mode must evaluate each issue individually, reading issues/{issue_id}/06_merge_result.md、issues/{issue_id}/08_code_review.md、issues/{issue_id}/09_build_verification.md as well as the input archive directory's 03_impact_decision.md/json. Each issue writes .ace-outputs/{runId}/issues/{issue_id}/11_risk_assessment.md, and the overview is written to .ace-outputs/{runId}/11_risk_assessment.md。

Stable scripts preferred

Prefer using built-in scripts to generate risk assessment artifacts; do not assemble temporary Python/Node/Shell scripts at runtime:

python3 skills/arkweb-security-patch-risk/scripts/generate_risk_assessment.py \
  --run-root <context.projectRoot>/.ace-outputs/<runId>

The script reads batch_status.json、09_build_verification.md and each issue's 03_impact_decision.json / 06_merge_result.json, and writes the root-level 11_risk_assessment.md/json and issue-level 11_risk_assessment.md/json. The script only includes active/ready issues as submission candidates;terminal_failed / deferred_for_archive only enters the archive list.

After the script executes, the agent reply may only contain:

• A one-line artifact path description;
• A one-line summary of the script execution result.

Do not paste complete prior artifacts, large risk tables, complete JSON files, tool output, or script source code in the reply. Detailed evidence is only written to 11_risk_assessment.md/json. The final reply is forbidden from using Supervisor-stage review phrasing, such as "current stage conclusion / whether to recommend continuing iteration / next-step guidance". The final reply is also forbidden from using review or guidance wording such as "overall recommendation / current state machine / the stage should be regarded as / recommend first / recommend next step / unless you are prepared to"; do not evaluate the state machine, do not propose process suggestions, and only report script artifacts. The final reply is forbidden from outputting JSON code blocks; state machine adjudication is only completed by the subsequent "Risk Assessment Adjudication" step reading 11_risk_assessment.json .

Must include:

1. Whether security risks are closed-loop.
2. Compatibility, stability, performance, ROM, and build risks.
3. Rollback recommendations.
4. Whether there are patches proven by prior artifacts to be unmerged or build false positives.
5. Build gate status:build_completed、build_status、exit_code、nonblocking_unrelated_build_failure、submit_eligible。

Rules

• Risk items are only recorded and do not block submission to the repository.
• Unknown items, manual tracking items, or items not belonging to the current step must not be used as fail reasons.
• When the given patch has actually been merged and the local build passes, or the build command fully exits with a failure that has been proven unrelated to this patch and recorded as a non-blocking build risk, submission to the repository must be allowed.
• Build process interruption, timeout, no real exit code, background process loss of contact, rerun still not completed, untrustworthy build.log,build_completed=false or submit_eligible=false do not count as non-blocking build risks; in such cases submission must be blocked and the process must enter result archiving.
• "The build failure is unrelated to this patch" must be based on one trustworthy complete build exit result; without a complete exit code, no unrelated pass-through may be granted.
• Only when prior artifacts prove that the given patch was not actually merged, or a build failure related to this patch was falsely reported as passing/unrelated, may a blocking conclusion be output; such blocking indicates that the prior artifacts are untrustworthy, should enter result archiving to record evidence, and must not suggest returning to automatic merging or build verification to form a loop.
• Batch mode must not mix the risks of multiple issues into one unified conclusion; each issue must independently record a risk summary.
• Batch mode must preserve overlap information: if multiple issues modify the same file, the automatic merge stage should already have selected a winner for each duplicate file group in ascending issue_id numeric order. The winner issue belongs to the active batch, and risk assessment must normally record its merge/build/submission risks; non-winner issues should already be marked deferred_for_archive and exit the active batch; in the risk assessment, only state that these issues were not included in this round's merge/compile/commit, and the final result archive lists them as leftovers; do not suggest combining multiple issues into one commit.
• The assessment must be based on the current issue's artifacts and the diff belonging to that issue in the current engineering target sub-repository; historical dirty changes do not belong to the current issue's risk.

Adjudication artifacts

Scripts and artifacts must be written to the complete 11_risk_assessment.json, with fixed fields:

{
  "verdict": "pass|conditional_pass|fail",
  "next_state": "提交上库|结果归档",
  "issues": [],
  "summary": "一句话总结"
}

The above JSON must not be output in the final reply; the Supervisor-style "current stage conclusion / whether to recommend continuing iteration / next-step guidance" must not be used to replace the artifacts.