arkweb-security-patch-gitcode-pr

ArkWeb GitCode PR

Used for arkweb-security-patch-submitter. The path, target repository, and target branch must come from the workflow context or the preceding merge result, and personal local paths must not be hardcoded in the skill.

Required references

• Archive input and symlink handling:references/archive-input-contract.md
• Set of files that can be submitted for the current issue:references/submit-scope-contract.md
• GitCode Issue/commit/PR process:references/pr-flow.md
• Public text sanitization boundary:references/public-text-redaction.md
• HTTP 413 / large pack diagnosis:references/http-413-diagnosis.md
• Copy template:
  • references/gitcode-issue-template.md
  • references/commit-message-template.md
  • references/pr-body-template.md

Scripts of this skill

All scripts are in this skill's scripts/ directory and do not call across skills:

node skills/arkweb-security-patch-gitcode-pr/scripts/resolve_archive_dir.mjs <archive-dir>
node skills/arkweb-security-patch-gitcode-pr/scripts/compute_submit_scope.mjs --merge-result <06_merge_result.json> --build-fix <10_build_fix.json>
node skills/arkweb-security-patch-gitcode-pr/scripts/preflight_commit_scope.mjs --repo <target-git-repo> --scope <submit_scope.json>
node skills/arkweb-security-patch-gitcode-pr/scripts/create_isolated_issue_commit.mjs --repo <target-git-repo> --scope <submit_scope.json> --base-ref <manifest_remote>/<targetBranch> --branch <fork-branch> --message-file <commit-message-file>
node skills/arkweb-security-patch-gitcode-pr/scripts/scan_existing_submit_targets.mjs --run-dir <.ace-outputs/runId> --repo <target-git-repo> --upstream-repo <owner/project> --fork-remote <fork-remote>
node skills/arkweb-security-patch-gitcode-pr/scripts/validate_public_text.mjs <commit_msg> <issue_body> <pr_body>

During the submission phase, it is forbidden to temporarily generate large shell/Python/Node scripts to replace the above scripts. If the existing scripts lack a capability, first add it to this skill's scripts/, then perform the repository submission.

Input sources

Preferentially read the preceding artifacts of the current issue:

• 01_issue_analysis.*
• 02_patch_fetch.*
• 03_impact_decision.*
• 04_final_archive.*
• issues/{issue_id}/06_merge_result.*
• issues/{issue_id}/09_build_verification.*
• issues/{issue_id}/10_build_fix.*
• issues/{issue_id}/11_risk_assessment.*
• The diff belonging to this issue in the current target git sub-repository

In batch mode, 00_batch_plan.* and batch_status.* may be read only for local submission queue determination; the batch overview, other issue information, and overlap summary must not be written into the current issue's GitCode Issue, commit message, or PR body.

deferred_for_archive / overlap non-winner issues are not part of the submission queue; no commit, branch, GitCode Issue, or PR may be created.

Target repository rules

• Submission repository: the target git sub-repository in the preceding merge result.
• Upstream repository: preferentially use the <owner>/<project>。
• derived from the manifest project/remote. Common mappings:src -> chromium_src，src/v8 -> chromium_v8，src/arkweb -> chromium_arkweb。
• Target branch: use context.automation.gitcode.targetBranch, and only use master。
• PR method: from a personal fork branch to the upstream target branch.
• Baseline for the range to be pushed: the target branch of the manifest/upstream remote must be used <manifest_remote>/<targetBranch>, for example tpc/master; the personal fork remote is only used as the push destination, and personal/master..HEAD must not be used as the minimum commit range determination.

Hard rules

1. Each Chromium issue corresponds to one GitCode Issue, one commit, one fork branch, and one PR.
2. Forbidden git add -A、git add .、git add -u、git commit -a。
3. It is forbidden to submit SDKs, toolchains, build artifacts, compressed packages, temporary patches,.ace-outputs、src/out , or unrelated dirty changes.
4. Unrelated dirty changes can only be recorded as ignored, and must not be cleaned up, rolled back, staged, or committed.
5. Tokens must not be written into repository files, remote URLs, commit messages, PR bodies, Issue bodies, or report text.
6. GitCode Issue、commit message、PR title/body、12_submit_result.md must not leak local machine paths, run directories, local archive file names, temporary directories, tokens, or complete workflow reports.
7. Public materials submitted to GitCode should preferentially be in Chinese; English is only used as field names, upstream links, or necessary supplements.
8. A detailed vulnerability description must be written; it is not acceptable to write only a single line "Apply upstream Chromium security fix".
9. The Chromium issue is the vulnerability source; the GitCode Issue is the repository submission process issue, and the numbers must not be mixed up.
10. The upstream Chromium issue in the GitCode Issue, commit message, and PR title/body must be written as a complete link https://issues.chromium.org/issues/<issue_id>; a bare issue id must not be written alone.
11. The PR body and GitCode Issue body must include the current issue's impact analysis summary, responsibility field, reason for responsibility field attribution, impact feature tree, five properties/RAM/ROM, and test suggestions; these fields preferentially come from 03_impact_decision.*, and only when missing are they taken from 04_final_archive.* 's ownership_and_quality Complete. Missing fields must not be omitted directly; write "To be confirmed" and explain the evidence gap.
12. The commit message must contain Signed-off-by: and the fixed line Co-Authored-By: Agent; the signature comes from the current commit repository's git config user.name/user.email。
13. For a cross-repo PR, the --head must be forkOwner:branch。
14. After the PR is created and the associated GitCode Issue is confirmed, you must comment start build and confirm that the comment exists.
15. upstream_patch_applied_exactly=false does not fail directly; as long as semantic_landed=true, blockers are empty, and the local adaptation record is complete, the adapted files may be submitted.
16. On HTTP 413 or remote large-pack rejection, diagnose according to this skill's HTTP 413 reference; repeated blind pushes are prohibited.
17. Do not fail the entire batch because the fork target branch is behind or personal/master..HEAD is very large; only block the corresponding issue when the manifest/upstream range, staging area scope, file size, or actual push return proves that the scope is abnormal.
18. When the batch worktree already contains the uncommitted aggregate diff of multiple issues, or the current HEAD already has commits for other issues, you must use create_isolated_issue_commit.mjs to construct an independent commit from the manifest/upstream baseline and the current issue's whitelist files; do not directly git commiton a contaminated branch, do not switch/clean the current worktree, and do not use git worktree.
19. If the push is reported by the Git LFS pre-push hook as Unable to find source for object, and the current issue submit scope has no LFS-tracked files, you must retry the same branch once with GIT_LFS_SKIP_PUSH=1 ; this is a fork/baseline LFS hook issue, and the entire batch must not be directly marked as unable to be submitted.
20. If personal/master..HEAD is very large or has no merge-base with the manifest/upstream, first ensure that a temporary baseline branch pointing to the manifest/upstream baseline SHA exists on the personal fork (for example aceharness-upstream-master-YYYYMMDD). You may use oh-gc branch create <base-branch> --repo <forkOwner>/<project> --ref <manifest_base_sha>; after the baseline branch is created successfully, push the issue branch.
21. Batch mode must proceed issue by issue. If a single issue's push, Issue, or PR fails, you may only mark that issue submit_failed and continue with subsequent ready issues; only shared infrastructure problems that will inevitably cause all issues to fail, such as authentication failure, network unreachability, or missing configuration, may stop the entire batch.
22. Before push, you must first execute scan_existing_submit_targets.mjs to perform a remote idempotency scan, and write or reference the result in 12_submit_result.md. If the scan finds that the same issue already has an open PR, it must be reused directly, and no new commit, branch, GitCode Issue, or PR may be regenerated.
23. If the fork branch already exists and points to this issue's isolated commit, you must not stop repeatedly at push; you must continue to create or reuse the GitCode Issue, and create a PR and comment start build. If a fork branch with the same name already exists but the commit is inconsistent, blind git pushis prohibited, automatically adding -r2/-r3 a new branch is prohibited, and force push is prohibited; you must first query whether a PR already exists. If there is no PR, mark submit_failed(branch_exists_commit_mismatch) and record the remote SHA, local isolated commit, and manual decision requirements.
24. Batch recovery submission must first perform a remote idempotency scan: query existing fork branches and existing PRs by issue id. As long as an open PR already exists for that issue pointing to ringking0:<arkweb-security-{issue_id}-...>, that PR must be reused and marked submitted; no new commit, new branch, new GitCode Issue, or new PR may be generated.
25. If a fork branch already exists but the PR is missing, the branch can only be reused to create the PR; no second branch may be created for the same issue, unless the original branch's commit is clearly inconsistent with the current issue scope and the reason for discarding it is recorded in the result file.
26. When using create_isolated_issue_commit.mjs the out-of-scope dirty changes, untracked files, SDK/toolchain deletions, or build artifacts in the current working tree are only recorded as ignored_worktree_state and must not block the current issue submission; the actual commit objects can only be constructed from the submit scope whitelist files and the manifest/upstream baseline. Blocking occurs only when the submit scope itself contains a forbidden path.

Output

Write to .ace-outputs/{runId}/12_submit_result.md; in batch mode, also write each issue's issues/{issue_id}/12_submit_result.md。

Each issue must record at least: target git sub-repository, upstream repository, target branch, committed files, commit id, fork branch, GitCode Issue, PR,start build comment result, ignored unrelated dirty changes, failure reason, or manual follow-up actions.