[doudouOUC]

What this PR does

The sandboxed verify lane now prepares a Java toolchain before the agent's clock starts, and only when the pull request diff touches packages/sdk-java. The agent gets Temurin JDK 21, Maven 3.9.11, a restore-only Maven repository, and qwencode plus runtime-broker installed from the merge ref. Other pull requests download nothing.

The repository is filled by a trusted producer on main and restored read-only. This repo's own jars are removed before the cache is saved, because the module versions are fixed and a jar built from main would otherwise be what Maven resolves. The skill's environment contract tells the agent what the lane provides, including that an A/B must reinstall the sibling modules for the base side, and that database-backed integration tests stay not covered.

Why it's needed

Whether a Java pull request was actually executed in this lane depended on whether that round's agent spent its own time budget downloading a JDK. Some rounds did, some did not, and a later round could silently stop executing Java that an earlier round had executed. sdk-java.yml already tests Java on pull requests. The gap is the verify agent's own A/B verdict.

Reviewer Test Plan

How to verify

Confirm a diff outside packages/sdk-java does not download a JDK or restore the Maven repository. Confirm a Java diff reaches the agent with QWEN_VERIFY_JAVA=1, JAVA_HOME, and MAVEN_ARGS set, or, when the download fails, without those variables and with a warning, while the agent still runs. Confirm the verify job never saves the Maven cache.

The cache hit itself can only be observed after this merges and the producer has run on main: comment @qwen-code /verify twice on the same Java pull request. The second step summary should contain verify Maven repo: hit=true, the report should execute the Java side, and the agent should not download a JDK.

Unit coverage: npx vitest run --config ./scripts/tests/vitest.config.ts scripts/tests/qwen-triage-workflow.test.js -t "qwen-triage verify Java toolchain|strips GitHub command files" and node --test .github/scripts/qwen-triage-workflow.test.mjs for the timeout floor (timeout-minutes >= 210). The node:test file also has pre-existing macOS failures in the flakiness-gate shell fixtures (/usr/bin/rm missing under that harness); the timeout assertion itself passed.

Evidence (Before & After)

N/A

Tested on

OS	Status
🍏 macOS	✅
🪟 Windows	N/A
🐧 Linux	✅

Environment (optional)

macOS: the workflow unit tests above. Linux: Lima node:22-bookworm (aarch64). The pinned x64 Temurin archive checksum matched the published file. On that arm64 guest the x64 binary cannot execute, and the script correctly leaves no ready marker. The same Temurin release's aarch64 build, after JAVA_HOME is exported, writes the marker: Java 21.0.12.1, Maven 3.9.11. Sibling installs of qwencode and runtime-broker succeeded as the node user. mvn test with only the agent environment: qwencode 208 tests, 0 failures. runtime-broker 754 tests with 1 failure and 1 error. managed-agent-server 1185 tests with 1 error. Those two modules include tests that start a Node fixture or a built CLI, and this rehearsal did not run npm run build first. The verify lane builds the TypeScript app before the agent starts.

Risk & Scope

• Main risk or tradeoff: a cold Java diff can spend up to about 20 minutes on the download and the two capped sibling installs. The job limit moves from 190 to 210 minutes so the agent can still ship a partial report. The Maven cache is restore-only; a miss or a cache outage degrades to a cold repository.
• Not validated / out of scope: MariaDB/MySQL failsafe integration tests, the hosted harness, the Java 11/17 matrix, and re-running Java tests through the flakiness gate. A cache hit on a second /verify of the same PR cannot be shown until the producer has saved on main.
• Breaking changes / migration notes: none. verify-pr: add follow-up-round, publish-guard, mutation and rig-hygiene rules from maintainer verification rounds #13732 rule 11 should treat Java as not covered only when QWEN_VERIFY_JAVA is unset.

Design: docs/design/verify-java-toolchain.md and docs/design/verify-java-toolchain.zh-CN.md.

Linked Issues

Closes #13741

中文说明

这个 PR 做什么

沙箱 verify 通道现在会在代理计时开始之前准备 Java 工具链，并且只在 PR diff 碰到 packages/sdk-java 时才做。代理会拿到 Temurin JDK 21、Maven 3.9.11、只恢复的 Maven 仓库，以及按合并引用装好的 qwencode 和 runtime-broker。其他 PR 不会下载这些东西。

仓库由 main 上的可信生产者填好，消费侧只恢复。保存前会删掉本仓库自己的 jar，因为模块版本是固定的，否则 Maven 会解析到 main 上构建出来的那一份。技能的环境约定写明通道提供什么，包括 A/B 时必须为 base 一侧重装同级模块，以及依赖数据库的集成测试仍然算未覆盖。

为什么需要

一条 Java PR 在这个通道里有没有被真正执行，取决于那一轮代理肯不肯花自己的时间去下载 JDK。有的轮次会下载，有的不会，后一轮还可能悄悄停掉前一轮已经执行过的 Java。sdk-java.yml 已经在 PR 上测试 Java。缺口是 verify 代理自己的 A/B 结论。

审阅者怎么验证

确认 packages/sdk-java 以外的 diff 不会下载 JDK，也不会恢复 Maven 仓库。确认 Java diff 到达代理时已设置 QWEN_VERIFY_JAVA=1、JAVA_HOME 和 MAVEN_ARGS；下载失败时则没有这些变量，并有 warning，同时代理仍然会跑。确认 verify 任务从不保存 Maven 缓存。

缓存命中只能在合并之后、生产者已在 main 上跑过才能看到：对同一个 Java PR 连续两次评论 @qwen-code /verify。第二次的步骤摘要应包含 verify Maven repo: hit=true，报告应执行 Java 侧，代理不应再下载 JDK。

单测：npx vitest run --config ./scripts/tests/vitest.config.ts scripts/tests/qwen-triage-workflow.test.js -t "qwen-triage verify Java toolchain|strips GitHub command files"，以及 node --test .github/scripts/qwen-triage-workflow.test.mjs 里的超时下限（timeout-minutes >= 210）。这个 node:test 文件在 macOS 上还有既有的抖动门 shell 夹具失败（该环境里找不到 /usr/bin/rm）；超时断言本身是通过的。

证据

不适用。

测过的环境

macOS 上跑了上面的工作流单测。Linux 上用 Lima 的 node:22-bookworm（aarch64）。钉死的 x64 Temurin 归档校验和与发布文件一致。在这台 arm64 客户机上 x64 二进制无法执行，脚本正确地不写 ready。同一 Temurin 版本的 aarch64 构建在导出 JAVA_HOME 之后会写 ready：Java 21.0.12.1，Maven 3.9.11。以 node 用户安装 qwencode 和 runtime-broker 都成功。只用代理环境跑 mvn test：qwencode 208 个测试、0 失败。runtime-broker 754 个测试里有 1 个失败和 1 个错误。managed-agent-server 1185 个测试里有 1 个错误。后两个模块包含启动 Node fixture 或已构建 CLI 的测试，这次演练没有先跑 npm run build。verify 通道在代理开始前会先构建 TypeScript 应用。

风险与范围

• 主要取舍：冷的 Java diff 最多花大约 20 分钟下载并做两次封顶的同级模块安装。任务上限从 190 分钟改为 210 分钟，代理仍然能交回部分报告。Maven 缓存只恢复；未命中或缓存服务故障会退化为冷仓库。
• 未验证 / 不在范围内：MariaDB/MySQL 的 failsafe 集成测试、hosted harness、Java 11/17 矩阵，以及用抖动门重跑 Java 测试。同一 PR 第二次 /verify 的缓存命中，要等生产者在 main 上保存之后才能看到。
• 破坏性变更 / 迁移：无。verify-pr: add follow-up-round, publish-guard, mutation and rig-hygiene rules from maintainer verification rounds #13732 第 11 条应只在 QWEN_VERIFY_JAVA 不存在时把 Java 视为未覆盖。

设计文档：docs/design/verify-java-toolchain.md 与 docs/design/verify-java-toolchain.zh-CN.md。

关联 Issue

Closes #13741

[qwen-code-review-bot]

✅ Qwen Triage finished — CI landed green on 1d81dfa and the deferred approval was posted. finalize run

✅ Qwen Triage 已完成 —— 1d81dfa 的 CI 全绿，延迟审批已提交。查看 finalize 运行

[qwen-code-review-bot]

Thanks for the PR!

Template looks good ✓ — every heading present, Risk & Scope filled in honestly (the "cannot be shown until the producer has run on main" line is exactly the right thing to volunteer), and the design doc ships in both languages with reciprocal links and a 1:1 heading structure.

Problem: observed, not theoretical. #13741 names five specific verify rounds (#13335, #13554, #13550, #13572, #12754) with links to the reports, including one where all 18 changed Java files went unexecuted — a regression against the previous round on the same PR. That is documented, recurring nondeterminism in a lane maintainers use for A/B verdicts, not a hypothesis.

Direction: aligned. This is the repo's own CI tooling, the issue was filed by a maintainer, and the shape follows an existing precedent instead of inventing one — pnpm-store.yml already establishes trusted-producer-on-main plus a restore-only consumer on the same runner, image, and actions/cache SHA pin. The new producer copies that contract rather than adding a second mechanism. Saying it plainly because it matters: this does touch the CI trust boundary, since it pulls external binaries into the container that later executes PR code. I read that part closely rather than waving it through — the findings are in Stage 2.

Size: no core paths (packages/core/src/**, packages/*/src/{auth,providers,models,config,tools,services}/**), so the two-tier core gate does not apply. Of +971/−17 across 8 files: ~436 lines are the two design docs, ~254 are workflow tests, ~298 are production (140 lines in qwen-triage.yml, the 124-line producer, 28 lines of skill contract, 3 of size baseline). Under the 1000-line advisory.

Approach: the scope feels right and I could not find anything worth cutting. The obvious smaller version — an unconditional actions/setup-java — makes every non-Java verify run pay for a JDK download, which is the cost #13741 explicitly asks to avoid; and leaving ~/.m2 to the agent is the thing being fixed. The path gate, the restore-only cache, and the artifact stripping are each load-bearing rather than decorative. No drive-by changes: outside the feature the only edits are the .size-baseline ratchet bump and one skill paragraph about Android that this change made factually wrong ("ships no JDK").

Risk: no elevated risk signals — none of the changed files match the revert-correlated path list.

Moving on to code review. 🔍

中文说明

感谢贡献！

模板完整 ✓ —— 各标题齐全，Risk & Scope 写得很实在（主动说明「缓存命中要等生产者在 main 上跑过才能看到」，这正是应该讲清楚的部分），设计文档双语齐备、互相链接、标题结构一一对应。

问题： 是已观测到的，不是理论性的。#13741 点名了五轮具体的 verify（#13335、#13554、#13550、#13572、#12754）并附了报告链接，其中一轮 18 个改动的 Java 文件完全没执行——相对同一 PR 的上一轮是倒退。这是维护者用来做 A/B 结论的通道里已被记录、反复出现的不确定性，不是假设。

方向： 对齐。这是仓库自己的 CI 工具，issue 由维护者提出，而且做法沿用了已有的先例而不是另造一套——pnpm-store.yml 已经确立了「main 上的可信生产者 + 只恢复的消费侧」模式，用同样的 runner、镜像和 actions/cache SHA 钉版。新的生产者照搬这套约定，没有引入第二种机制。有一点要讲明，因为它确实重要：这个改动碰到了 CI 的信任边界，它会把外部二进制拉进那个之后要执行 PR 代码的容器。这部分我是仔细读过的，不是放过——结论在 Stage 2。

规模： 没有触及核心路径（packages/core/src/**、packages/*/src/{auth,providers,models,config,tools,services}/**），所以两级核心门槛不适用。8 个文件 +971/−17 中：约 436 行是两份设计文档，约 254 行是工作流测试，约 298 行是生产代码（qwen-triage.yml 140 行、124 行的生产者、28 行技能约定、3 行体积基线）。低于 1000 行的大 PR 提示线。

方案： 范围合理，我没找到可以砍掉的部分。最直观的更小版本——无条件用 actions/setup-java——会让每个非 Java 的 verify 都为下载 JDK 付出代价，而这正是 #13741 明确要求避免的成本；把 ~/.m2 交给代理自己去填，则正是这次要修的问题本身。路径门控、只恢复的缓存、以及剥离本仓库产物，三者都是承重结构而不是装饰。没有夹带无关改动：特性之外只有 .size-baseline 的棘轮更新，以及技能里那段被本改动改写为事实错误的 Android 说明（「ships no JDK」）。

风险： 无升级风险信号——改动文件都没有命中与 revert 相关的路径列表。

进入代码审查 🔍

— Qwen Code · qwen3.8-max-2026-09-02

_{Reviewed at 1d81dfa7567e789a4b9045a6d0029b7eb528cd5d · re-run with @qwen-code /triage}

[qwen-code-review-bot]

Code review

I wrote down what I would have done before reading the diff: gate on the changed-file list, download a checksum-pinned Temurin + Maven before the agent's clock starts, warm ~/.m2 from a trusted producer on main that the PR lane only restores, strip this repo's own jars so a stale main build can't win dependency resolution, export a flag the skill can key on, raise the job timeout, and extend the workflow tests. The PR does all of that, and then adds four things I had not thought of — each of which closes a hole my version would have shipped with:

• the toolchain installs before checkout, so no PR tree is on disk while it runs, and /opt/verify-java is root-owned with a+rX, so the node user cannot plant the ready marker that gates the agent's environment;
• ready is written only after both checksums and java -version / mvn -version succeed, with JAVA_HOME exported first because the Maven launcher will not find the unpacked JDK on its own;
• the node-run mvn strips ACTIONS_RUNTIME_TOKEN / ACTIONS_CACHE_URL alongside the GitHub command files, so a plugin declared in a PR-owned POM cannot write to the shared cache — and actions/cache/save is asserted absent from the whole verify job;
• the strip list is not hardcoded prose: moduleCoordinates() reads every packages/sdk-java/*/pom.xml and asserts the list equals the set of artifact ids, so adding a fifth module without updating the producer fails a test.

No critical blockers. Correctness, the supply-chain surface, and the failure paths all hold up. Specifics I verified rather than assumed:

• MAVEN_VERSION / MAVEN_SHA512 match sdk-java.yml byte-for-byte, and the pins are asserted equal across consumer, producer, and sdk-java.yml so they cannot drift. packages/sdk-java/ has no parent POM, so hashFiles('packages/sdk-java/*/pom.xml') covers all four modules and the producer's key and the consumer's key are the same hash.
• managed-agent-server test-depends on qwen-managed-runtime-broker with <type>test-jar</type>, and the broker's maven-jar-plugin does bind the test-jar goal — so -DskipTests (not -Dmaven.test.skip) still compiles tests and publishes the jar the server needs. The producer's install order (qwencode → runtime-broker → managed-agent-server → client) satisfies that. None of the four POMs use frontend-maven-plugin or exec-maven-plugin, so the producer needs no node_modules.
• QWEN_ENV is consumed via runuser -u node -- env -i "${QWEN_ENV[@]}", and GNU env applies assignments left to right — so the appended PATH=/opt/verify-java/...:${PATH} really does override the earlier "PATH=$PATH". The comment claiming that is correct.
• Install Java modules and Run verification agent share the identical gate (decision == 'run' && prepare.outputs.verdict == ''), so there is no state where the agent gets QWEN_VERIFY_JAVA=1 while java-prepare.log was never written.
• .size-baseline is exact: the head blobs are 362377 and 5575 bytes, matching the recorded entries, so the ratchet neither trips nor banks slack.
• The runuser count assertion moving 7 → 8 is right — the new step contributes exactly one single-line runuser -u node -- env match inside the sliced region.

Two non-blocking things I'd want you to consider, neither of which I think should hold the merge:

1. Can the producer re-save over an existing key? The save key is content-derived with no run-unique component, but on.push.paths also includes .github/workflows/verify-maven-repo.yml itself and workflow_dispatch is enabled. My understanding is that actions/cache/save fails when the key already exists on the cache server, which would mean editing the producer without touching a POM turns the job red on main and — the part that actually matters — leaves the cache holding the previous contents. That is the opposite of the intent when the edit changed what belongs in the repo (a new populate line, an extended strip list). pnpm-store.yml cannot hit this because its only trigger path is the hashed file. I could not test it from here, so treat this as a question, not a finding: if the collision is real, evicting the entry before save (or dropping the workflow-file trigger and documenting a manual eviction for workflow_dispatch) would close it.
2. A cold cache pushes the cost back into the agent budget. On a restore miss the repo is empty, and timeout -k 30 300 will kill both sibling installs mid-download, logging qwencode=124 runtime-broker=124. The skill contract then says "reinstall that module from the tree", which is a full dependency download charged against the agent's 120 minutes — the thing ci(verify): provision a Java toolchain in the verify lane so sdk-java PRs are verified every time #13741 set out to remove. The JDK and Maven are still guaranteed, so the regression is bounded, and the PR body does disclose the ~20-minute cold path. It might be worth a distinct line in the contract for a timeout specifically: 124 means the repository is cold, so budget for a full resolve rather than retrying the install.

Files changed (8)

File	What changed
.github/workflows/qwen-triage.yml	The whole consumer side: java output from the paginated file list, the root-run toolchain install before checkout, the stale-clear plus restore-only cache pair, the capped node-run sibling install, the ready-gated agent env, and the 190 → 210 timeout with its budget comment rewritten.
.github/workflows/verify-maven-repo.yml	New producer. Trusted main-only context, same runner and image as the consumer, four modules resolved into a local repo, then this repo's own com/alibaba artifacts deleted before the save.
.qwen/skills/verify-pr/SKILL.md	The environment contract the agent reads: what the lane provides, where the exit codes live, why the base side of an A/B needs a sibling reinstall, and what stays under Not covered. Also corrects the Android paragraph that claimed the image ships no JDK.
.github/workflows/.size-baseline	Ratchet bump for the grown qwen-triage.yml and the new producer entry. Both verified exact against the head blobs.
docs/design/verify-java-toolchain.md	English design doc: problem, current state, goals and non-goals, the step-ordering flowchart, decisions, constraints, risks, validation, acceptance criteria.
docs/design/verify-java-toolchain.zh-CN.md	Chinese counterpart. Heading structure matches the English version one for one.
scripts/tests/qwen-triage-workflow.test.js	New verify Java toolchain suite covering the gate, the pre-checkout ordering, checksum-before-ready, cross-file pin equality, the restore-only property, the POM-derived strip list, the node-run caps, the env injection order, and the timeout. Plus the 7 → 8 runuser count.
.github/scripts/qwen-triage-workflow.test.mjs	The node:test timeout floor moves 190 → 210 with the budget comment updated to account for the Java steps.

Testing

This is an unattended CI run, so per the lane's rules I did not build or execute anything from this PR — the evidence below is the PR's own CI, read through the API for the reviewed commit. 61 check-runs in total: 10 reported a real conclusion, 50 were skipped (the platform and event matrices that this diff does not select), 1 is queued and 2 are still in progress, and none failed or were cancelled.

The two that matter most for this change — Lint & Static (ubuntu-latest, Node 22.x) and Test (ubuntu-latest, Node 22.x), the latter being where both workflow test suites run — had not finished when I fetched. I did not poll for them; the Qwen Triage Finalize job rewrites the table below in place once CI settles. triage in progress is this run.

Final CI results for 1d81dfa (auto-updated by the triage finalize job after CI completed):

Check	Conclusion
Classify PR	✅ success
Desktop Shell (ubuntu-22.04)	✅ success
Desktop Shell (windows-2022)	✅ success
Integration Tests (no-AK, No Sandbox)	✅ success
Lint & Static (ubuntu-latest, Node 22.x)	✅ success
Test (ubuntu-latest, Node 22.x)	✅ success
web-shell E2E Smoke (ubuntu-latest, Node 22.x)	✅ success

_{One row per check name (latest run); skipped checks omitted; failures sort first. / 每个检查名一行（取最新一次运行），省略 skipped，失败项排在最前。}

Because those two are unfinished, I am explicitly recording what this review does not carry: no local execution of either workflow test suite, and no observation of the producer or the provisioning path running. The author's rehearsal numbers in the PR body (Lima node:22-bookworm on aarch64, mvn test counts per module) are the author's claim about their own environment, not evidence I re-ran — and by their own account that rehearsal skipped npm run build, which the real lane does first.

Sandboxed verification would settle part of this, and it is worth being precise about which part: @qwen-code /verify (available directly — the author has write access, so this is not a sponsored run). This diff touches .github/, .qwen/, docs/, and scripts/tests/ but not packages/sdk-java/, so on this PR's own verify run steps.pr.outputs.java is false and none of the new steps execute. That run does prove the negative acceptance criterion — a non-Java diff downloads no JDK, restores no Maven repo, installs no siblings — and that the lane still completes end-to-end with the new steps present but inert. It cannot prove the positive path: QWEN_VERIFY_JAVA=1 reaching an agent, the sibling installs landing, or verify Maven repo: hit=true on a second run. Those need a Java-touching PR after merge, once the producer has saved on main. Not verified: the positive path, for exactly that reason — no pre-merge lane can exercise it, and I would rather say so than imply the CI table covers it. /tmux is not applicable; there is no TUI surface here.

中文说明

代码审查

在读 diff 之前，我先写下了自己会怎么做：按改动文件列表门控、在代理计时开始前下载钉版并校验的 Temurin 与 Maven、由 main 上的可信生产者预热 ~/.m2 而 PR 通道只恢复、剥离本仓库自己的 jar 以免 main 的旧构建在依赖解析中胜出、导出一个技能可以据此判断的开关、抬高任务超时、并扩充工作流测试。这个 PR 全都做了，而且还补了四点我没想到、而我的版本会带着漏洞上线的东西：

• 工具链在 checkout 之前安装，运行时磁盘上没有 PR 树；/opt/verify-java 属 root、权限 a+rX，所以 node 用户无法伪造那个决定代理环境的 ready 标记；
• ready 只在两个校验和以及 java -version / mvn -version 都成功之后才写，并且先导出 JAVA_HOME——Maven 启动脚本自己找不到刚解包的 JDK；
• 以 node 身份跑的 mvn 除了 GitHub 命令文件之外还剥离了 ACTIONS_RUNTIME_TOKEN / ACTIONS_CACHE_URL，所以 PR 自有 POM 里声明的插件无法写共享缓存；同时整个 verify 任务被断言不含 actions/cache/save；
• 剥离列表不是写死的文字：moduleCoordinates() 会读取 packages/sdk-java/*/pom.xml 下每个模块，断言列表与 artifact id 集合相等，因此新增第五个模块而没同步生产者会让测试失败。

没有阻断性问题。 正确性、供应链面、失败路径都站得住。以下是我实际核对过、而不是想当然的点：

• MAVEN_VERSION / MAVEN_SHA512 与 sdk-java.yml 逐字节一致，并且有断言保证消费侧、生产者、sdk-java.yml 三处钉版相等，不会漂移。packages/sdk-java/ 没有父 POM，所以 hashFiles('packages/sdk-java/*/pom.xml') 覆盖全部四个模块，生产者与消费侧的 key 是同一个哈希。
• managed-agent-server 以 <type>test-jar</type> 测试依赖 qwen-managed-runtime-broker，而 broker 的 maven-jar-plugin 确实绑定了 test-jar goal——所以用 -DskipTests（而不是 -Dmaven.test.skip）仍会编译测试并发布 server 需要的那个 jar。生产者的安装顺序（qwencode → runtime-broker → managed-agent-server → client）满足这一点。四个 POM 都没有用 frontend-maven-plugin 或 exec-maven-plugin，因此生产者不需要 node_modules。
• QWEN_ENV 是通过 runuser -u node -- env -i "${QWEN_ENV[@]}" 消费的，GNU env 从左到右应用赋值——所以后追加的 PATH=/opt/verify-java/...:${PATH} 确实覆盖了前面的 "PATH=$PATH"。那句注释是对的。
• Install Java modules 与 Run verification agent 用的是完全相同的门控条件（decision == 'run' && prepare.outputs.verdict == ''），所以不存在代理拿到了 QWEN_VERIFY_JAVA=1、而 java-prepare.log 从未被写出的状态。
• .size-baseline 是准确的：head 上的 blob 分别是 362377 和 5575 字节，与记录值一致，棘轮既不会触发也不会囤余裕。
• runuser 计数断言从 7 改成 8 是对的——新步骤在切片区域内恰好贡献一条单行 runuser -u node -- env 匹配。

两点不阻断、但我希望你考虑的事，我认为都不该拦住合并：

1. 生产者能在已存在的 key 上重新保存吗？ 保存 key 由内容派生、没有运行唯一分量，但 on.push.paths 同时包含了 .github/workflows/verify-maven-repo.yml 自身，并且开了 workflow_dispatch。我的理解是 actions/cache/save 在 key 已存在时会失败，那就意味着改动生产者而没动 POM 会让 main 上的任务变红，而真正要紧的是——缓存里留的是上一次的内容。当这次改动本意是改变仓库里该有什么（新增一行 populate、扩充剥离列表）时，这与意图正好相反。pnpm-store.yml 碰不到这个问题，因为它唯一的触发路径就是被哈希的那个文件。我在这里没法实测，所以请把它当作疑问而不是结论：如果冲突确实存在，保存前先驱逐该条目（或去掉工作流文件这个触发路径、把 workflow_dispatch 的手工驱逐写进文档）就能补上。
2. 冷缓存会把成本推回代理预算。 恢复未命中时仓库是空的，timeout -k 30 300 会在下载中途杀掉两个同级模块安装，日志里留下 qwencode=124 runtime-broker=124。而技能约定接着说「从代码树重装该模块」，那是一次完整依赖下载，计入代理的 120 分钟——正是 ci(verify): provision a Java toolchain in the verify lane so sdk-java PRs are verified every time #13741 想消除的东西。JDK 和 Maven 仍然是有保障的，所以倒退幅度有限，PR 正文也确实披露了约 20 分钟的冷路径。或许值得为超时单独写一行约定：124 意味着仓库是冷的，应当为完整解析留出预算，而不是重试安装。

测试

这是一次无人值守的 CI 运行，按通道规则我没有构建或执行本 PR 的任何代码——下面的证据是这个 PR 自己的 CI，通过 API 针对被审提交读取的。共 61 个 check-run：10 个给出了真实结论，50 个被跳过（本 diff 未选中的平台与事件矩阵），1 个排队、2 个仍在进行，没有失败或取消。

对这个改动最关键的两个——Lint & Static (ubuntu-latest, Node 22.x) 和 Test (ubuntu-latest, Node 22.x)（两套工作流测试都跑在后者）——在我取数时还没结束。我没有轮询等待；Qwen Triage Finalize 任务会在 CI 稳定后就地改写上面的表格。进行中的 triage 就是本次运行。

因为这两个尚未完成，我明确写下本次审查不包含什么：没有在本地执行任何一套工作流测试，也没有观察到生产者或供给路径真正运行。PR 正文里作者的演练数据（Lima node:22-bookworm，aarch64，各模块的 mvn test 计数）是作者关于自己环境的主张，不是我复跑的证据——而且按作者自己的说明，那次演练没有先跑 npm run build，真实通道是会先构建的。

沙箱验证能坐实其中一部分，值得说清是哪一部分：@qwen-code /verify（可直接触发——作者有写权限，所以这不是代跑）。本 diff 改的是 .github/、.qwen/、docs/、scripts/tests/，没有碰 packages/sdk-java/，所以在这个 PR 自己的 verify 运行里 steps.pr.outputs.java 为假，新步骤一个都不会执行。那次运行确实能证明否定向的验收标准——非 Java 的 diff 不下载 JDK、不恢复 Maven 仓库、不安装同级模块——也能证明带着这些新步骤（但处于惰性状态）的通道仍能跑完。它无法证明正向路径：QWEN_VERIFY_JAVA=1 抵达代理、同级模块安装落地、或第二次运行出现 verify Maven repo: hit=true。这些需要一个改了 Java 的 PR，在合并之后、且生产者已在 main 上保存过。未验证：正向路径，原因正是如此——合并前没有任何通道能执行它，与其让上面的 CI 表格显得已经覆盖，我更愿意直说。/tmux 不适用，这里没有 TUI 界面。

— Qwen Code · qwen3.8-max-2026-09-02

_{Reviewed at 1d81dfa7567e789a4b9045a6d0029b7eb528cd5d · re-run with @qwen-code /triage}

[qwen-code-review-bot]

Confidence: 4/5 — solid and better thought through than my own baseline; the two nits in Stage 2 are questions about a cold-cache path and a cache-key collision, neither of which can corrupt a verdict.

Going back to what I wrote down before reading the diff: the PR matches it and then beats it. My version would have installed the toolchain somewhere convenient, exported the flag, and called it done. It would have left three holes this one closes — the node user able to plant the readiness marker, a PR-owned POM plugin holding an Actions cache credential, and a strip list maintained by hand that quietly rots the day someone adds a fifth Java module. Those are not things I would have caught in review either, which is the part that raises my confidence rather than lowering it: the reasoning is written down where a future maintainer will find it, and the properties that matter are pinned by tests rather than by comments.

The thing I keep coming back to as the strongest signal is moduleCoordinates(). Deriving the strip list from the POMs on disk means the invariant "no main-built jar of this repo survives into the cache" is enforced by the repository's actual shape instead of by a list someone remembered to update. That is the difference between a design decision and a design decision that holds.

Is every change necessary? Yes. I looked for scope creep specifically and found none — the one edit outside the feature that is not a mechanical baseline bump is a skill paragraph this change made untrue, and leaving it would have told the agent the image ships no JDK.

Six months from now I would thank the author, not curse them. The producer/consumer split mirrors pnpm-store.yml, so there is one pattern to learn rather than two, and the failure modes all degrade in the direction the design doc says they do: a failed download warns and leaves Java under Not covered, a cache miss costs time but not correctness, a failed sibling install is logged with its exit code and the agent is told what to do about it. Nothing here can turn a TypeScript verification into a false fail, which was my main worry going in given the shared job.

What I am not confident about, stated plainly: the positive path has never been observed end to end, and cannot be before merge. The provisioning only runs for a diff touching packages/sdk-java/, so this PR's own verify run exercises the negative criterion and nothing else; the cache-hit criterion additionally needs the producer to have run on main first. That is not a defect in the PR — it is inherent to changing a lane from inside a PR that the lane gates on — and the author says so in the body rather than letting a reader discover it. The two Stage 2 questions are the residue of that: both concern paths (cold cache, producer re-save) that no pre-merge run can reach.

I would merge this. The unit suites and lint were still in flight when I finished, so I am not approving against a result that does not exist yet — approval is deferred until CI lands green on 1d81dfa7567e789a4b9045a6d0029b7eb528cd5d, and the finalize job posts it then. If Test (ubuntu-latest, Node 22.x) comes back red, the new Java suite is the first place to look, since it is the only new thing running there.

中文说明

Confidence: 4/5 —— 扎实，而且比我自己的基线方案想得更周全；Stage 2 里的两点是关于冷缓存路径和缓存 key 冲突的疑问，两者都不会污染结论。

回到我在读 diff 之前写下的方案：这个 PR 与它一致，并且更好。我的版本会把工具链装在一个顺手的位置、导出开关、就算完事。那会留下三个这个 PR 补上的洞——node 用户能伪造就绪标记、PR 自有 POM 里的插件握着 Actions 缓存凭据、以及一份靠手工维护、在有人新增第五个 Java 模块那天就悄悄失效的剥离列表。这些我在审查里也未必抓得到，而这恰恰是提高我信心的地方，不是降低：推理被写在未来的维护者会看到的位置，要紧的性质由测试钉住，而不是靠注释。

我反复想到、也认为最能说明问题的一点是 moduleCoordinates()。从磁盘上的 POM 派生剥离列表，意味着「本仓库由 main 构建的 jar 不会残留进缓存」这条不变量是由仓库的真实结构来保证的，而不是由某人记得去更新的列表来保证。这就是一个设计决定与一个能站得住的设计决定之间的差别。

每一处改动都必要吗？是的。我专门找过范围蔓延，没找到。特性之外唯一不是机械基线更新的改动，是被这次改动改写为不实的那段技能说明——留着它就会告诉代理镜像里没有 JDK。

六个月后我会感谢作者，而不是骂他。生产者/消费者的拆分与 pnpm-store.yml 同构，所以要学的是一个模式而不是两个；而且所有失败模式都朝设计文档所说的方向退化：下载失败只告警、把 Java 留在「未覆盖」，缓存未命中只损失时间不损失正确性，同级模块安装失败会连退出码一起记进日志、并告诉代理该怎么办。这里没有任何东西能把一次 TypeScript 验证变成假的 fail——考虑到共用同一个任务，这是我进来时最担心的点。

我不确定的地方，直说：正向路径从未被端到端观察到，合并前也无法观察。供给逻辑只在 diff 碰到 packages/sdk-java/ 时运行，所以这个 PR 自己的 verify 运行只验证了否定向标准，别的都没有；缓存命中那条标准还额外要求生产者先在 main 上跑过。这不是 PR 的缺陷——从一个被该通道门控的 PR 内部去改这个通道，本来就如此——而且作者是写在正文里的，没有留给读者自己去发现。Stage 2 的那两个疑问就是这件事的残留：它们都涉及合并前任何一次运行都到不了的路径（冷缓存、生产者重新保存）。

我会合并它。我看完时单测和 lint 还在跑，所以我不会针对一个尚不存在的结果去批准——批准推迟到 CI 在 1d81dfa7567e789a4b9045a6d0029b7eb528cd5d 上转绿之后，由 finalize 任务届时发出。如果 Test (ubuntu-latest, Node 22.x) 变红，第一个该看的地方是新增的 Java 测试套件，因为那是那里唯一新增的运行内容。

— Qwen Code · qwen3.8-max-2026-09-02

_{Reviewed at 1d81dfa7567e789a4b9045a6d0029b7eb528cd5d · re-run with @qwen-code /triage}

[doudouOUC]

@qwen-code /verify

[qwen-code-review-bot]

LGTM, looks ready to ship — CI landed green after the review. ✅

[qwen-code-review-bot]

Sandboxed verification: ❌ not passed — findings reported (agent verdict) - workflow run

Ran the PR in an isolated, token-free container: A/B against the base build, mock-free harness assertions, targeted gates. Advisory evidence for human reviewers — not a review, an approval, or a CI check.

Scripted assertions: 160 passed · 0 failed · 160 total

Flakiness gate: ✅ 2 changed test file(s) x 5 identical rounds, no divergence

中文 — 判定：❌ 不通过 · 报告了发现（agent 判定）

沙箱验证在隔离、无凭证的容器中执行了该 PR 的代码（与 base 构建 A/B 对照、无 mock harness 断言、定向门禁）。仅作为评审证据，不构成评审、批准或 CI 检查。

脚本断言：160 通过 · 0 失败 · 160 总计

抖动门：✅ 2 changed test file(s) x 5 identical rounds, no divergence

Verification report

PR #13763 deep verification — ci(verify): provision a Java toolchain for sdk-java PRs

Verdict: findings — 160 scripted assertions, 160 passed / 0 failed. The central claim holds and is load-bearing against the base build. Three findings are worth a reviewer's attention: the job-budget line understates the capped worst case by ~31 minutes, the PR's own cited test command cannot pass inside this lane, and the new suite does not pin the Maven sha512 guard. None of the three is a defect in the provisioning logic itself.

Verified head: 1d81dfa7567e789a4b9045a6d0029b7eb528cd5d (git rev-parse HEAD^2), base 4360b003a087fe9e57f6ffbe7ba48795980b59c3. Single commit — git rev-list HEAD^1..HEAD^2 matches the snapshot's one-element commits array, so per-commit attribution is complete despite the depth-2 checkout.

中文摘要

结论：findings —— 160 条脚本断言全部通过（160 passed / 0 failed）。中心主张成立，且相对 base 构建是 load-bearing 的：只有 diff 碰到 packages/sdk-java/ 时才会下载 JDK、恢复 Maven 仓库、注入 QWEN_VERIFY_JAVA=1；base 侧在同样输入下一律不注入。钉死的 Temurin sha256 与 Maven sha512 与真实发布文件逐字节相符，actions/cache 的 SHA 确实解析为 v4.3.0，只恢复入口的 manifest 里没有 post:，结构上不可能保存缓存。

三条 findings：

1. 任务预算算错了（Medium）。注释写 Java 部分「≤ ~20m」，但实测 curl --max-time 是每次尝试的上限，--retry 3 会把它乘以 4：单个下载最坏 1206 s = 20.1 分钟，已经超过整条预算行。两个下载加两次 timeout -k 30 300 的 mvn install 合计 ~51.2 分钟，而限额只从 190 提到 210。按该文件自己的口径最坏 ~231m > 210m，容器会被中途杀掉，正好绕过它自己注释里说的 ship-what-ran 路径。加一个 --retry-max-time（本镜像 curl 7.88.1 支持，实测把 18s 的探针降到 8s）即可让「≤ ~20m」变成真话。
2. 本通道里跑不出 PR 自己给的绿灯（Low，属通道行为而非 PR 缺陷）。verify 通道按设计把 .qwen 钉回 base 并设为只读，而新测试断言 HEAD 版 SKILL.md 的内容，所以 PR 描述里给出的那条 vitest 命令在本通道 1 failed | 8 passed；同一命令在 HEAD 内容的 scratch worktree 里 9 passed。抖动门会把这个变更过的测试文件当成持续失败来跑。
3. 新测试没有钉住 Maven sha512 校验（Suggestion）。变异矩阵 17 caught / 2 survived。删掉 sha512 校验后测试仍全绿（indexOf(...) === -1 满足 -1 < readyAt）；把该变异体真跑起来，喂一个格式完好但被替换过的 Maven 发行包，它会写下 ready 标记。head 本身行为正确（同样输入下 head 拒绝并告警），所以这是覆盖缺口，不是缺陷。另一个幸存者（删 java -version）经实测是冗余防御：mvn -version 会先失败，两者行为一致。

未覆盖：真实 MariaDB/MySQL failsafe 集成测试、hosted harness、Java 11/17 矩阵、缓存真实命中（要等生产者在 main 上跑过）、actionlint/yamllint（未安装固定版本二进制）、以及任何真机上跑 mvn install 同级模块（本通道未 provision Java，见下文）。

Central claim and A/B

Central claim. A PR diff that touches packages/sdk-java/ causes the verify lane to provision a Java toolchain and hand the agent QWEN_VERIFY_JAVA=1 + JAVA_HOME + MAVEN_ARGS before its clock starts; a diff that does not touch packages/sdk-java downloads nothing and injects nothing; an install failure degrades to a warning with no injection and the agent still runs.

Secondary claims. (1) The restore-only Maven cache can actually be hit by the consumer that restores it. (2) PR-executed code cannot forge the toolchain or reach a credential through it.

Oracle for every cell is an observable artifact — $GITHUB_OUTPUT contents, the ready marker on disk, the emitted QWEN_ENV array, the stub's own call log, the mvn child's environment — never a reading of the YAML.

01-ab-gate-toolchain-modules.png shows the arm-shape, gate and toolchain cells as they printed; 02-mutation-matrix-and-survivor-adjudication.png shows the matrix and the survivor adjudication.

Gate A/B — 8 file-list fixtures × both arms

The verbatim slice of Resolve PR and snapshot metadata was taken between the same two anchors in both arms (if grep -qE '(^|/) … # Snapshot PR metadata), so the PR's hunk is the only difference inside it, and executed under bash --noprofile --norc with the step's own set -euo pipefail.

fixture	base java	head java	head decision=na
this PR's real file list (no sdk-java)	false	false	–
packages/sdk-java/qwencode/… + pom	false	true	–
sdk-java only, deeply nested test file	false	true	–
packages/core/src/index.ts	false	false	–
docs-only (README.md, docs/index.md)	false	false	yes
near-miss prefixes (packages/sdk-java-docs/, sdk-java/, packages/sdk-javax/)	false	false	–
packages/sdk-java/README.md only	false	false	yes (docs-only wins)
401 files, sdk-java entry last (SIGPIPE shape)	false	true	–

16/16 cells as predicted: head flips on exactly the sdk-java inputs, base never provisions for any input. The last row is the one the code comment claims to defend (grep <<< rather than a pipe, which under pipefail previously misclassified code PRs as docs-only) — it holds with the match at the end of a 401-line list.

Toolchain step — verbatim, against the real published archives

The step's run: block was executed as extracted, with a stub curl serving the real archives downloaded from the two pinned URLs, and real sha256sum/sha512sum/tar/find/java/mvn.

cell	exit	ready	prefix dir	oracle
success (real archives)	0	written	present	openjdk version "21.0.12.1", Apache Maven 3.9.11, 2 curl calls, no warning
JDK archive corrupted	0	absent	removed	::warning::Java toolchain install failed
Maven archive corrupted	0	absent	removed	same warning
download fails (curl exit 7)	0	absent	removed	same warning

The three failure cells are the load-bearing proof that the checksum gate is not decorative: a single flipped byte in either archive removes the marker, which is what the agent's env injection keys on. All four exit 0, so a Java failure can never fail a TypeScript verification.

Agent env injection — verbatim QWEN_ENV region, both arms

cell	head entries	QWEN_VERIFY_JAVA	PATH entries	base arm
ready present	27	1	2, java one last	no injection
ready absent	23	absent	1	no injection

The base arm was run in both cells, including the positive one, per the symmetric-control rule. The comment's claim that "env applies QWEN_ENV left to right, so this PATH overrides the one above" was measured independently: env -i PATH=/first PATH=/second printenv PATH → /second.

Sibling module install — credential stripping measured at the real seam

The mvn stub dumps its own environment, i.e. what survives runuser -u node -- env -u …. ACTIONS_RUNTIME_TOKEN, ACTIONS_RUNTIME_URL and ACTIONS_CACHE_URL were deliberately planted in the parent with sentinel values so a missing -u would be observable rather than assumed absent.

cell	exit	mvn calls	last line of java-prepare.log	planted credential in child
toolchain missing	0	0	toolchain=missing	n/a
ready, mvn succeeds	0	2	qwencode=0 runtime-broker=0	none
ready, mvn fails	0	1 each, both fail	qwencode=1 runtime-broker=1	none

Both installs use the restored repo as -Dmaven.repo.local, qwencode gets -Dgpg.skip + -Dmaven.javadoc.skip, runtime-broker gets -Dspotbugs.skip, and the step summary carries verify Maven repo: hit=… key=… in all three cells including the cache-miss one.

Live-lane negative arm (production measurement, no harness)

This PR touches .github/workflows/, .qwen/skills/, docs/ and scripts/ — not packages/sdk-java/ — so the gate was off for this very run, and the container is a live sample of the lane:

• no QWEN_VERIFY_JAVA, JAVA_HOME or MAVEN_ARGS in the agent's /proc/self/environ; no java/mvn on PATH
• /opt/verify-java never created; /__w/_temp/verify-maven-repo never created; no java-prepare.log beside $QWEN_VERIFY_CONTEXT
• $RUNNER_TEMP is /__w/_temp (derived from QWEN_VERIFY_CONTEXT=/__w/_temp/verify-context/pr.json), and /home/runner does not exist in the container

Corrections to the PR description

Labelled as corrections to the description, not requests to change code.

1. "The node:test file also has pre-existing macOS failures … the timeout assertion itself passed." On this Linux lane the whole file is green: # tests 125 / # pass 125 / # fail 0. The macOS caveat does not apply here and could mislead a reader into discounting a red node --test run on Linux.
2. "The pinned x64 Temurin archive checksum matched the published file." Confirmed independently, and extended: the Temurin sha256 and the Maven sha512 both match the files the pinned URLs actually serve, byte for byte. Both archive layouts also satisfy the step's own post-extract checks (jdk-21.0.12.1+1/, apache-maven-3.9.11/).
3. "qwencode plus runtime-broker installed from the merge ref" is accurate for the consumer, but the producer populates the repo from all four modules (managed-agent-server and client via verify). The strip list correctly covers all four artifactIds, so an agent testing those two modules has their third-party dependencies but not their own artifacts — which the HEAD skill text does tell the agent to reinstall. Not a defect; the description just understates what the producer warms.

Findings

1. Medium — the job budget line understates the capped worst case by ~31 minutes

.github/workflows/qwen-triage.yml, the timeout-minutes comment block:

#   java toolchain + Maven repo
#   + sibling modules            ≤ ~20m, and only when the diff touches
#                                packages/sdk-java/. curl --max-time caps
#                                each download; `timeout 300` caps each
#                                mvn install
#   worst case                   ~200m  ⇒ 210 leaves 10m of headroom.

curl --max-time caps each attempt, and --retry 3 retries on a timeout, so the cap multiplies. Measured in this image (curl 7.88.1) against a server that accepts and never replies, with the flags scaled down 100× (curl-retry-measurement.txt):

--retry 3 --retry-delay 2 --max-time 3   → elapsed=18s   (= 4×3 + 3×2 exactly)
--retry 3 --retry-delay 2 --max-time 3 --retry-max-time 7 → elapsed=8s

At the step's real values:

item	cap
one download (1+3)×300 + 3×2	1206 s = 20.1 m
two downloads (JDK + Maven)	40.2 m
two timeout -k 30 300 sibling installs	660 s = 11.0 m
Java worst case	~51.2 m (line says ≤ ~20 m)
cache restore of the Maven repo	not priced at all

A single download's cap already exceeds the whole Java budget line. Against the file's own pre-PR items (120 m agent + 15 m install/build + 40 m gate + 5 m misc = 180 m) the worst case is ~231 m versus a 210 m limit — i.e. the 20-minute raise does not cover the addition it was raised for. The consequence is the one the comment itself names: the job timeout kills the container mid-run and bypasses the ship-what-ran path, so a Java PR in a network-degraded window loses its report entirely. The timeout-minutes >= 210 assertion in .github/scripts/qwen-triage-workflow.test.mjs encodes the understated figure, so the existing guard cannot catch this.

This is a budget-robustness finding, not a correctness bug: it needs a black-hole network (packets dropped, not refused) to reach, and the ordinary failure mode — a fast 404 or DNS error — is cheap. But that regime is exactly what --max-time --retry exists for, and this file's convention elsewhere is to sum the caps (the flakiness-gate line itemises -k 10 30, -k 30 120, -k 30 600).

Measured candidate fix (one flag per download)

--retry-max-time exists in this image's curl 7.88.1 and caps the whole retry loop. Adding --retry-max-time 300 to both curl invocations makes each download's cap 300 s, so the Java worst case becomes ~5 m + ~5 m + 11 m ≈ 21 m — the stated "≤ ~20m" becomes true and no limit raise is needed. Verified direction: the scaled probe above drops from 18 s to 8 s when the flag is added, with the same exit code 28 and the same warning path. Not applied to the PR; the arithmetic above is what a maintainer should re-check.

-          if curl -fsSL --retry 3 --retry-delay 2 --max-time 300 -o "$work/jdk.tar.gz" "$TEMURIN_URL" \
+          if curl -fsSL --retry 3 --retry-delay 2 --max-time 300 --retry-max-time 300 -o "$work/jdk.tar.gz" "$TEMURIN_URL" \

2. Low — the PR's cited test command cannot pass inside the verify lane

The Reviewer Test Plan gives:

npx vitest run --config ./scripts/tests/vitest.config.ts scripts/tests/qwen-triage-workflow.test.js \
  -t "qwen-triage verify Java toolchain|strips GitHub command files"

Run verbatim in this lane: 1 failed | 8 passed | 168 skipped. The failure is expect(verifySkill).toContain('QWEN_VERIFY_JAVA=1'). Run in a scratch worktree at HEAD content: 9 passed.

The cause is the lane, not the PR: Pin agent inputs from base replaces .qwen with git archive HEAD^1 -- .qwen and re-pins it root-owned and read-only (dr-xr-xr-x root root, verified), with the workflow's own note that "A PR that edits the skill is verified with the base version by design". So a PR that edits the verify skill is, by construction, unable to satisfy its own skill-content assertions in this lane.

Two consequences worth naming:

• The Test Plan step is not performable here. A reviewer following it inside a verify run will see red and has no way to tell the lane artifact from a real regression without repeating the run against unpinned content.
• The flakiness gate's signal for this file is degraded. scripts/tests/qwen-triage-workflow.test.js is a changed test file, so the gate re-runs it in the pinned tree across identical rounds. It will see the same failure every round — "no divergence", so the gate stays quiet — but the file can no longer distinguish a genuine break from the pinning artifact.

Not a request to weaken the pin, which is a real security property. A one-line note in the Test Plan ("these four assertions require an unpinned .qwen; inside the verify lane they fail by design") would close the gap, or the skill-content assertions could read the file from HEAD via git rather than from the working tree.

3. Suggestion — the new suite does not pin the Maven sha512 verification

Mutation matrix: 17 caught / 2 survived / 19, unmutated control green (9 passed), and a positive control (timeout-minutes: 210 → 190) caught in the same file as the survivors. Two mutants needed re-anchoring after their first anchors matched 2× and 0×; both were caught once applied.

survivor	classification	evidence
delete sha512sum --check --status	coverage gap	suite stays 9 passed; driving the mutant build with a well-formed but substituted Maven distribution and the real pin still in force writes ready (ready=true), where head refuses it (ready=false + warning)
delete "$prefix/jdk/bin/java" -version	redundant defence	driving the mutant with a broken JVM gives ready=false, identical to head, because mvn -version fails first — and that line is pinned, via expect(javaHomeAt).toBeLessThan(toolchain.indexOf('"$prefix/maven/bin/mvn" -version'))

The asymmetry is the finding: the Temurin sha256 check is pinned by an explicit toBeGreaterThan(-1), while the Maven sha512 check is only pinned by an ordering assertion of the shape indexOf(x) < readyAt, which -1 satisfies. The same shape leaves java -version unpinned, though there a sibling assertion covers the hazard. Head's behaviour is correct — the tamper cell in the A/B table above proves the sha512 gate fires — so this is a test to write, not code to fix. The fixture that would go red: assert expect(toolchain.indexOf('sha512sum --check --status')).toBeGreaterThan(-1) alongside the existing sha256 line.

Caught mutants, for completeness: timeout floor; sha256 removal; mvn -version removal; unanchored grep; herestring→pipe; cache/restore→cache; dropped continue-on-error; dropped acp-sdk from the strip list; removed QWEN_VERIFY_JAVA=1; removed MAVEN_ARGS; dropped timeout -k 30 300; dropped the ACTIONS_RUNTIME_* strip; producer cache path changed; producer moved to ubuntu-latest; dropped -Dspotbugs.skip; exit 1 on download failure; if true in place of the ready-marker guard.

Nit — one java-prepare.log state the skill contract does not describe

Read from the code, not measured: if chown -R node:node "$repo" fails, the step logs toolchain=chown-failed and exits before any mvn, so the log never gets the qwencode=<n> runtime-broker=<n> last line — yet /opt/verify-java/ready still exists, so the agent does receive QWEN_VERIFY_JAVA=1. The HEAD skill text tells the agent the exit codes are the last line and to reinstall "if either code is non-zero", which does not cover a missing line. Low likelihood (needs a non-root step or a read-only $RUNNER_TEMP).

Not covered

• Any real mvn execution. The gate is off for this PR, so no JDK was provisioned in this lane and QWEN_VERIFY_JAVA is unset — per the base-pinned skill, the Java side is not covered. The mvn invocations were verified as command lines and environment through a stub at the real runuser seam; no module was compiled or tested. The PR description's own mvn test counts (208 / 754 / 1185) were not reproduced.
• A real cache hit. Requires the producer to have saved on main first; the PR says so too. What was proven instead is that the mechanism can fire: getCacheVersion in @actions/cache@4.1.0 (the version the pinned action SHA depends on) hashes the literal resolved paths + compression method + salt; producer and consumer share runs-on, container image and options: '--init --user node' with the already-in-production pnpm-store.yml pair; neither image ships a zstd binary, so both fall back identically; and no /home/runner host path exists here, so $RUNNER_TEMP and ${{ runner.temp }} are the same directory (/__w/_temp). The restore-only entrypoint's own manifest has no post: step while the full action's has post: 'dist/save/index.js' — read from the manifests at the pinned SHA, not from the PR's description. Residual not measured: an actual round-trip through the cache service.
• Database-backed Java tests, the hosted harness, the Java 11/17 matrix, and re-running Java tests through the flakiness gate — all declared out of scope by the PR; not attempted.
• actionlint and yamllint. Not installed in this container and node scripts/lint.js --setup was not run for budget reasons. bash -n was run on all three producer run: blocks (all OK), and the consumer's changed blocks were executed, which is stronger. The size ratchet was run and its liveness proven (planting 100 for verify-maven-repo.yml yields exit 1 with grew to 5575 bytes); as committed both entries are byte-exact (362377, 5575) and the gate exits 0.
• Producer end-to-end. verify-maven-repo.yml was parsed, syntax-checked and its strip list checked against the real coordinates (acp-sdk, qwen-managed-agent-server, qwen-managed-runtime-broker, qwencode-sdk, all com.alibaba, all fixed non-SNAPSHOT versions — which is what makes the strip necessary). It was never executed: that needs a cold JDK plus a full Spring Boot resolve. Its day-one cost was not modelled either; the trigger is narrow (packages/sdk-java/*/pom.xml or the workflow itself, on main), so arrival rate is low, but confirming that needs gh api event history, which this token-free environment does not have.
• One harness limitation, stated for the record. The toolchain and modules scripts were executed with prefix=/opt/verify-java rewritten to a sandbox path, because /opt is root-owned and this agent is uid 1000 with no CAP_SYS_ADMIN (unshare → Operation not permitted). Everything else is byte-identical to the extracted step. The security property the rewrite gives up was measured directly against the live lane instead: mkdir -p /opt/verify-java as node → Permission denied, while run: steps in this job do execute as root (/etc/apt/sources.list.d/github-cli.list is root-owned), so the step can write /opt and PR code cannot forge the marker.

Methodology

Everything ran inside the lane's own node:22-bookworm container at the merge ref (head 1d81dfa7, base 4360b003), as uid 1000, with the pre-built tree already present. Three harnesses, all kept in this directory as .mjs so a maintainer can rerun them: ab-java-toolchain.mjs (103 assertions — arm shape, gate A/B over 8 fixtures × 2 arms, 4 toolchain cells against the real published archives, agent-env injection in both arms, sibling-install cells, cache identity) parses both workflow revisions from git show with the yaml package, extracts the run: blocks verbatim and executes them under bash --noprofile --norc keeping each step's own set line, stubbing only external tools (curl, runuser, mvn, chown) and asserting on their recorded call logs and child environments; followups.mjs (11) re-applies the two mis-anchored mutants and adjudicates both survivors by building and driving the mutant scripts against stand-in archives; gates.mjs (46) covers the supply-chain pins against the real downloaded files, the actions/cache manifests and getCacheVersion source at the pinned SHA, the strip list against the real POM coordinates, the repo's own gates and the size ratchet plus its liveness, and the live-lane negative arm. Repo gates were run separately: node --test .github/scripts/qwen-triage-workflow.test.mjs (125/125) and the full scripts/tests/qwen-triage-workflow.test.js + scripts/tests/workflow-size.test.js at HEAD content in a scratch worktree (400/400), plus the PR's cited filter both in the pinned lane tree and unpinned. Raw logs are ab-java-toolchain.log, mutation-matrix.log, followups.log, gates.log, gate-*.log, curl-retry-measurement.txt; third-party manifests and the real archive hashes are under vendor/.

Flakiness gate log

rounds=5 files=2 skipped=0
file .github/scripts/qwen-triage-workflow.test.mjs: (cd .) node --test ./.github/scripts/qwen-triage-workflow.test.mjs
file scripts/tests/qwen-triage-workflow.test.js: (cd .) npx --no-install vitest run --config ./scripts/tests/vitest.config.ts ./scripts/tests/qwen-triage-workflow.test.js


per-file results (P=pass F=fail I=infra-exit, one letter per run):
  .github/scripts/qwen-triage-workflow.test.mjs: PPPPP
  scripts/tests/qwen-triage-workflow.test.js: PPPPP

verdict: pass
summary: 2 changed test file(s) x 5 identical rounds, no divergence

--- per-invocation detail (full copy in the artifact) ---
round 1 · .github/scripts/qwen-triage-workflow.test.mjs: P (exit 0)
round 1 · scripts/tests/qwen-triage-workflow.test.js: P (exit 0)
round 2 · .github/scripts/qwen-triage-workflow.test.mjs: P (exit 0)
round 2 · scripts/tests/qwen-triage-workflow.test.js: P (exit 0)
round 3 · .github/scripts/qwen-triage-workflow.test.mjs: P (exit 0)
round 3 · scripts/tests/qwen-triage-workflow.test.js: P (exit 0)
round 4 · .github/scripts/qwen-triage-workflow.test.mjs: P (exit 0)
round 4 · scripts/tests/qwen-triage-workflow.test.js: P (exit 0)
round 5 · .github/scripts/qwen-triage-workflow.test.mjs: P (exit 0)
round 5 · scripts/tests/qwen-triage-workflow.test.js: P (exit 0)

Evidence images

Harness scripts and raw logs are in the workflow run artifacts (7-day retention).

— Qwen Code · sandboxed verification

[yiliang114]

Reviewed at head f4841fe — LGTM.

The trust model is the load-bearing part of a verify-lane change, and it holds up:

• Cache poisoning is closed on both sides: the consumer is restore-only (a save step in a job that executes PR code would let a PR write the shared cache), and the producer strips this repo's own artifacts before saving — necessary because the module versions are fixed, not SNAPSHOT, so a main-built jar would otherwise be what Maven resolves for the PR tree.
• The ready marker lives under root-owned /opt, so the node user (which runs PR code) cannot plant it, and the toolchain install happens pre-checkout with no PR tree on disk — the same supply-chain surface as the existing runner-tools step.
• Credential hygiene in the sibling-install step is explicit: GITHUB_TOKEN/GH_TOKEN blanked, ACTIONS_* cache tokens unset under runuser, each mvn capped by timeout, and the step always exits 0 so a sibling failure degrades Java to Not covered instead of failing a TypeScript verdict.
• The ^packages/sdk-java/ gate is deliberately narrower than sdk-java.yml's path list, and the comment says why (those paths are mostly core/CLI, and this lane cannot host the database-backed ITs anyway) — other PRs download nothing.
• The SKILL.md contract tells the agent the non-SNPAPSHOT A/B trap (reinstall siblings from the base worktree, or a copied repo) and pins the failure semantics (QWEN_VERIFY_JAVA unset with an sdk-java diff means the toolchain failed — report Not covered, do not self-provision).
• The 190→210 timeout raise states its cost in the comment (an ECS slot held ~3.5h instead of 1h), which is the right way to land it.

Producer/consumer runner and image are matched so cache entries are restorable, and the workflow-test pins (including the strip markers) keep the two copies from drifting. CI on this head: no failures; several lanes still running.

[qwen-code-review-bot]

Released in v0.25.1.