感谢贡献！这是一次重跑 —— head commit 与上一轮相同，变化的是证据，不是代码。

模板完整 ✓ —— 所有必需小节都已填写，并附有完整对应的中文翻译。

问题： 是已观测到的 bug，不是理论性加固。#13563（仍处于 open 状态）点名了三条路由，引用了真实异常（EmptyResultDataAccessException: Incorrect result size: expected 1, actual 0）和 500 internal_error 响应体，并给出了三步复现。现在还有已执行的 A/B 佐证：base 臂上三个新用例以 expected:<404> but was:<500> 失败，head 臂上通过。证据充分。

方向： 对齐 —— 而且方向非常明确：关联 issue 已经给出修复方案（沿用 operationStatus 的先例：404 加 managed_tool_publication_* 错误码），本 PR 正是这么做的。有一点值得明确记录而非默默继承：这改变了三条路由的 HTTP 状态码，因此「对 5xx 重试、把 4xx 当作终态」的 writer 在修复后行为会不同。PR 已在 Risk & Scope 中说明，而对「指名但不存在的资源」返回 404 本就是更正确的契约，所以我认可 —— 只是记录这是一次有意的契约变更，而非纯内部改动。

规模： 不适用。packages/sdk-java/managed-agent-server/src/main/java/… 不匹配 Stage 0 的任何核心路径模式，且只涉及一个 package。记录一下：生产代码 10 行（8+/2−），测试 104 行。即便按核心路径计算，10 行的 fix 既不触发 refactor 硬阻断，也不触发 500 行升级。

方案： 足够精简，和我自己会写的方案基本一致。只改两处 —— 正是 issue 指出的两处 —— 复用已有的 requireContract helper 和已有的 ApiException 响应结构。没有新增抽象，没有顺手重构，没有格式噪音。它还谢绝了 issue 讨论中两条可选建议，我认为两个谢绝都是对的：共享读取 helper（两个调用点不值得抽一个），以及兜底的 EmptyResultDataAccessException 处理器 —— 后者只会掩盖真实的数据完整性错误。

风险： 无升级风险信号 —— 我对两个改动文件重新跑了高风险路径检查，均不匹配。

与上一轮的差别： 该 fork 被挂起的 workflow 已放行。SDK Java 与 Qwen Code CI 现在都在这个 commit 上以 success 完成，全部 16 项真实检查均为绿。上一轮我转交的唯一原因 ——「有人真的看它跑过吗？」—— 现在有了答案，详见下方审查。

进入代码审查 🔍

代码审查

先说我自己的独立方案。 只看标题、「为什么需要」和 #13563 的根因分析（在权衡 diff 之前）：把两处未加保护的 queryForMap 读取换成 queryForList 加显式判空，抛出 ApiException(NOT_FOUND, "managed_tool_publication_unknown", …)，复用已有的 helper 而不是新增一个，并在已有的 api/ToolPublicationControllerTest.java 中按路由补 MockMvc 测试。这正是本 PR 所做的。它与我的方案一致（而非超越），我也没有找到它漏掉的更简路径。

没有阻断性问题，也没有违反 AGENTS.md。 以下是本轮我亲自核验、而非沿用上一轮结论的部分。

diff 中唯一真正的语义风险，以及它为何安全。 queryForMap 在「零行」和「多于一行」两种情况下都会抛异常；queryForList + getFirst() 只处理零行，所以纸面上这是把一次显式失败换成了默默取第一行。实际不会：V20__managed_tool_publication.sql:23 声明了 PRIMARY KEY (scope_key, publication_id)，而两处被改写的查询正好以这两列为过滤条件（外加 tenant/workspace/session）。最多只会匹配一行，因此判空之后的 getFirst() 不可能掩盖重复行。没有丢失任何不变量。

两个被改方法的全部调用方，逐一点名。 finishedInternal 有三个调用方（比路由清单暗示的多一个），我三个都查了：

• finished(key, publicationId, writerToken) —— 先执行 sessions.restore(...) 再查询。这就是 GET …/finished 路由，也是 prepareAdmission 的入口，所以两条路由确实都在新的 404 之前完成鉴权。
• finishedForBroker(execution) —— 仅供 broker 使用，它自己先做一次 queryForList 并 if (rows.isEmpty()) return null;。因此它绝不会带着「行不存在」走到新检查，broker 行为未变。（唯一可能是两次 SELECT 之间发生删除竞态，那时结果只是从一个未检查异常变成另一个 —— 不是行为回归。）
• finish(...) —— 只在 beginFinish 已认领该行之后调用，此时 publication 必然存在，新的 404 在该路径不可达。

verifiedStream 有两个调用方：readRangeInternal（由公开的 readRange 进入，同样先恢复 writer 会话 → POST …/range），以及 openReferencedStream —— 后者在 verifiedStream 之前调用 requireReferenced(...)，对未知 publication 返回 400 invalid_request，所以新的 404 在这条路径同样不可达。

一条不阻断的观察，且属于既有问题。 上面这点意味着：referenced-stream 路径对未知 publication 仍返回 400，而三条读取路由现在返回 404。这个不一致不是本 PR 造成的，修它还会扩大 diff，所以我不要求改动 —— 但如果在意 publication 读取接口的契约一致性，值得单独开一个 issue。

新错误码不属于已发布契约的变更。 managed-agent-public-api.openapi.json 中 managed-tool-publications 路径为 0 处、managed_tool_publication_* 错误码为 0 处 —— 这些是内部路由。因此无需更新 spec，OpenAPI 契约 workflow 也不受影响。

复用情况： requireContract(boolean, HttpStatus, String, String) 本来就已存在（抛 ApiException），且生产文件里 HttpStatus 已经 import。diff 没有新增 import、没有新增 helper —— 它用的是现成的东西，这个取舍是对的。

测试中一条不阻断的小问题。 六次参数化调用各自创建一个 DB_CLOSE_DELAY=-1 的新 H2 实例且从不关闭，因此该类每轮运行会泄漏六个内存数据库。这与仓库现有写法一致（WorkspaceCsiReservationStoreTest 等也是如此），所以我只是把它标为「有意识的选择」而非疏漏，并不要求修改。

测试证据

本评论携带的是通过 API 取回的 CI 检查结果 —— 与上次不同，这次是真实存在且在受审 commit 上全绿的。 我没有构建、运行或测试本 PR 的任何内容；triage 从不执行被审查代码树中的代码。该 fork 被挂起的运行已放行，因此 SDK Java 与 Qwen Code CI 都在 4f46d95 上以 success 完成，全部 16 项真实检查均为绿（见下表）。

关键不在于「CI 是绿的」，而在于是哪个 job 跑了这些测试。我读了日志，而不是只信检查名：

• 矩阵行（ubuntu-latest / Java 11|17|21、macos-latest / Java 21、windows-latest / Java 21）只在 qwencode 和 runtime-broker 里执行 mvn clean test —— 736 个测试，全部是 com.alibaba.qwen.code.runtimebroker.*，完全不涉及 managed-agent-server。这点必须说清楚，因为很容易把这些绿行误读成对本 diff 的覆盖。

• 真正覆盖本改动的是 Runtime Broker and Managed Agent MariaDB / Java 21，它在 packages/sdk-java/managed-agent-server 目录下执行 mvn -Pmysql-integration … clean verify checkstyle:check。其日志中包含：

  [INFO] Running com.alibaba.qwen.code.managedagent.api.ToolPublicationControllerTest
  [INFO] Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.496 s -- in com.alibaba.qwen.code.managedagent.api.ToolPublicationControllerTest
  [INFO] Tests run: 1268, Failures: 0, Errors: 0, Skipped: 0
  [INFO] BUILD SUCCESS
  

  也就是说，这 104 行新测试确实在 Linux 上完成编译，7 个用例（6 新 + 1 旧）确实执行并通过，而且整个模块 1268 个测试连同 checkstyle 全绿。这比两次本地运行都更强：作者的 Windows 环境有 60 个环境性 Workspace 文件系统失败，macOS 的 A/B 有两个计时 flake。同一个 job 还会执行 scripts/check-failsafe-reports.js non-hosted …，若有测试类被静默跳过就会失败 —— 所以这 7 个用例不可能靠「没跑」而通过。

这套绿色测试真的钉住了改动吗？ 是的，而这恰恰是单看 CI 无法证明的部分。@wenshao 做了双臂 A/B（head 4f46d953 对 base 9a02f405，把 PR 的测试文件覆盖到 base 臂作为唯一差异），其报告为：base 臂 4 绿 / 3 红 —— returnsNotFoundForUnknownPublication ×3，Status expected:<404> but was:<500> —— head 臂 7/7 全绿；另有一个不复用 PR 测试代码、直驱 ToolPublicationDataStore 的独立探针，显示 base 上为 EmptyResultDataAccessException → 500，head 上为 ApiException 404 managed_tool_publication_unknown，而 403 writer_credential_invalid 在两臂上均未变且仍先于 publication 查找。这是他的证据，不是我复跑的结果 —— 但「base 上红」加上「CI 上绿」正是让回归测试承重、而非装饰性的那一对证据。

上方表格给出了各检查项的真实名称与结论。未验证项及原因：

• 未由我在运行时验证： 我从未执行代码，所以 500 → 404 的转变是由 CI 日志和上述维护者 A/B 确立的，不是我亲自观测的。两者都是已执行的证据而非口头声明，因此我视为已定论。
• 无任何一方覆盖： MariaDB 与 fault-gate profile 在 CI 中跑过了，但真实 OSS、以及作者那六个 Windows Workspace 文件系统失败，没有人复现过。这些失败已被作者在未修改的上游复现，且 CI 的 windows-latest / Java 21 是绿的，所以我判断它们与本机环境相关且与本 PR 无关 —— 这是一个判断，不是实测结论。

上一轮我要求的沙箱通道是「放行被挂起的 CI 运行」，这件事已经发生并定论了那个行为性论断。不需要再跑 /verify 或 /tmux —— /tmux 本来就不适用，因为本改动没有 TUI 界面，且作者没有写权限。

真实场景 tmux 测试：N/A —— 本次为无人值守的 CI 路径运行（GITHUB_EVENT_NAME=issue_comment），triage 从不驱动产品；且无论如何，本改动是内部 HTTP 状态码，没有用户可见的 TUI 界面。

信心度：4/5 —— 那 10 行生产代码是正确的、精简的，并且现在两侧都有已执行的证据支撑（head 上 CI 全绿，维护者 A/B 中 base 臂为红）；扣掉的一分是给两条已点名的不阻断小问题，而不是对修复本身有任何怀疑。

退一步看，这是一个范围收得很好的修复该有的样子。两处改动，正是 #13563 指出的两处，复用了已有的 helper 和错误响应结构，而没有另起一套。作者还做了两个我同样会做的判断 —— 谢绝可选的共享读取 helper，以及谢绝兜底的 EmptyResultDataAccessException 处理器。第二个更有意思，因为兜底的防御性处理感觉上更安全，实际却会掩盖真实的数据完整性故障。

回到我的独立方案：本 PR 与之一致。我没有找到它漏掉的更简路径，它也没有过度设计 —— 真要说重，重的是测试脚手架，而它之所以重，是因为它接了真实的 store 和真实迁移后的 H2，而不是把被测对象 mock 掉，这个取舍是对的。diff 中每一处改动都是达成目标所必需的；没有可拆出去的东西，也没有夹带无关修改。半年后接手，我会感谢作者而不是抱怨。

这一轮为何与上一轮结论不同。 上一轮我给 3/5 并转交，只有一个原因：没有人看这段代码跑过。该 fork 的 CI 停在 action_required，所以这 104 行新测试除了在作者的 Windows 主机上之外没有见过编译器，而我不愿意让自己成为「从未编译过的测试代码」与 main 之间唯一的屏障。这个缺口现在是被证据、而不是被口头保证填上的 —— 而且我核实了是哪个 job 产出的证据，因为那些绿色的 Java 矩阵行根本不运行 managed-agent-server。真正运行它的 job（Runtime Broker and Managed Agent MariaDB / Java 21）显示 ToolPublicationControllerTest 7/7 通过、整个模块 1268 个测试 0 失败（含 checkstyle），并且带有一个「测试类被静默跳过就失败」的守护步骤。

我也补上了静态审查无法闭环的部分：finishedInternal 有三个调用方而不是两个，verifiedStream 有两个。这五处都已在上方审查中交代清楚 —— broker 路径先判空并返回 null，finish 路径只在行已被认领之后到达，referenced-stream 路径在触及新检查之前就已返回 400。因此可达的行为变化恰好是三条已记录的读取路由，别无其他。「点名每一个下游调用方」这条标准，达到了。

两条小问题，都不阻断。 新测试每轮运行会泄漏六个未关闭的内存 H2 数据库，但这与仓库现有写法一致，所以在这里改反而是不一致。另外 referenced-stream 路径对未知 publication 仍返回 400 invalid_request，而三条读取路由现在返回 404 —— 这是既有问题、超出本 PR 范围，但如果你在意 publication 读取接口的契约一致性，值得单独开 issue。

关于这一票。 @wenshao 在这个 commit 上的批准是另一票，不是我的，我也没有拿它当作免于核查的替代 —— 我独立重新推导了调用方清单、主键不变量和 CI 覆盖范围，并且读的是 job 日志而不是检查名称。main 要求一个批准 review 加 code owner 审查，且没有任何 required status check，所以这里的批准是有决定性的；这也正是我在给出批准之前一定要看到已执行证据的原因。这个 commit 上没有任何待完成的检查（两个 pull_request 运行均已完成），fork refactor 护栏也不适用 —— 这是一个 fix。

已批准，并绑定到受审 commit。✅

结论：可以合并 ✅（本地 A/B 验证，macOS 15 Intel + JDK 21 + Maven 3.9.9）

• 双臂设置：head 4f46d953 与 base 9a02f405（当前 origin/main 顶）各一个 detached worktree；PR 的测试文件覆盖到 base 臂作为唯一差异，同一套测试跑两个代码版本。
• 回归测试承重成立：ToolPublicationControllerTest 7 个用例在 base 上 4 绿 3 红（returnsNotFoundForUnknownPublication ×3，期望 404 实际 500），在 head 上 7/7 全绿。
• 独立探针（不复用 PR 的测试代码，直驱 ToolPublicationDataStore，真实 H2+Flyway、真实会话/写凭证存储，仅 broker 仓库与对象存储用惰性代理）：base 上未公开 publication 抛 EmptyResultDataAccessException（经通用异常处理器映射为 500 internal_error）；head 上为 ApiException 404 managed_tool_publication_unknown。无效写凭证在双臂上均为 403 writer_credential_invalid，且先于 publication 查找——鉴权顺序未变。
• 全套测试归因：managed-agent-server 全量 1268 例，base 3F+2E、head 1F+1E。base 的 3F 正是覆盖进去的 PR 测试；其余失败均为本机计时 flake：HarnessCoordinatorTest 取消观察用例在双臂间双向飘（head 全量红→单跑绿；base 全量绿→单跑红），ToolPublicationStoreTest 两个 1s/500ms 截止期断言在双臂相同报错。按臂隔离重跑后 head 独有失败族 = 0。
• 静态门：head checkstyle:check 通过；与当前 main 的试合并干净无冲突（真实 merge-base ad6039aa）。
• 披露：base 臂取 main 顶 9a02f405 而非作者的 ad6039aa，两者仅差 web-shell 的 feat(web-shell): Add fullscreen viewing for history tables #13589（零 Java 影响，已用 diff 验证）；每臂运行前删除并从该臂重装 ~/.m2 的 qwencode-sdk/qwen-managed-runtime-broker 快照以防交叉污染（两模块 base↔head 字节级一致）；因 SpotBugs 插件要求 Maven ≥ 3.8.9，全程使用 Maven 3.9.9。
• 本地未覆盖：MariaDB profile（CI 已过）、fault-gates profile、Windows/Linux 主机、Node/web-shell 侧（本 PR 未触及）。作者在 Windows 上的 6 个 Workspace 文件系统套件失败未在本机复现，本机跑该模块无此现象。

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

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

抖动门：不适用 — no runnable changed test files (0 out-of-scope file(s) noted in the log)

PR 13602 deep verification — fix(managed-agent): return 404 for unknown tool publications

Verdict: findings — 34/34 scripted assertions passed (pass=34 fail=0); the central claim is load-bearing and the full-module gate is green. One concrete problem worth a reviewer's attention: the changed shared read has a fourth HTTP consumer the description does not name (artifact download), where a missing publication row now returns 404 managed_tool_publication_unknown instead of the deliberately-retryable 503 artifact_unavailable. Not a regression in the central claim; a scope/contract decision for the maintainer.

Verified head: 4f46d953f647b55e14166055e79d0a03542b4140 (HEAD^2)
Base (control) arm: 6936c77e60da8897c71bb9700ae57b7021e7db78 (HEAD^1, the merge-ref parent)
Merge commit measured: 39fd278c229f9ad37bcb495a8e4026462616685f
Diff: 2 files, +112/−2 — one production file (ToolPublicationDataStore.java, 2 hunks) + one test file.

Central claim + A/B

Central claim. An authenticated writer requesting an unknown tool publication receives 404 managed_tool_publication_unknown from GET …/finished, POST …/admissions/prepare, and POST …/range, where base returned 500 internal_error; writer authentication still runs before the publication lookup.

Secondary claims. (1) The refusal is a domain error, not a swallowed server exception. (2) Nothing else on the publication surface changes.

A/B cells — the PR's own test file, run unchanged on both arms

The instrument is the PR's new ToolPublicationControllerTest (7 cases). The control arm is a scratch worktree at HEAD^1 with only the test file copied in; production code is unmodified base.

Failing assertion on the control arm, verbatim:

[ERROR]   ToolPublicationControllerTest.returnsNotFoundForUnknownPublication:55 Status expected:<404> but was:<500>

This is the intended assertion (expected-vs-actual status values), not a compile/import/fixture break — so the revert reaches the behaviour the test exists to catch.

Per-route flip (index → route, from the test's @ValueSource):

3/3 flip from broken to fixed; 4/4 unrelated cases unchanged. Witness: 01-ab-base-500-vs-head-404.png.

Scenario axes

The diff changes how a request is refused (not cancelled/parked/retried), so the relevant axes are credential validity, route, and publication existence. Settings that ran:

Mutation matrix (marker-verified)

Every mutant was proven to reach the compiled artifact before counting: javap -c -p on ToolPublicationDataStore.class, scoped to the mutated method's bytecode, asserting the expected instruction/constant is present (or absent). All 6 markers read ok.

6/6 killed, 0 survivors. No coverage gap, no dead code, no redundant defence: the two hunks guard a disjoint route set, so neither masks the other (this is the combination-row question, and revert-both is that row — it adds no red beyond the union of the two single-hunk rows, confirming disjointness rather than layered defence).

Two facts the matrix settles that reading cannot:

• /admissions/prepare's 404 comes from site 1, not from ToolPublicationStore.requireStagedCall. That method returns immediately when no transaction is active (if (!TransactionSynchronizationManager.isActualTransactionActive()) return;), and prepareAdmission calls it before opening one — so it cannot be the source. revert-site1 turning [2] red is the proof.
• The pre-existing rejectsCoercedOrOverflowedRangeNumbersBeforeReading case is untouched by every mutant — it never reaches the store.

Witness: 03-mutation-matrix-marker-verified.png.

Sibling sweep — is the bug class closed?

The mechanism here is a parser-shaped one: queryForMap on qwen_tool_publication throwing EmptyResultDataAccessException, which falls through to ApiExceptionHandler's generic @ExceptionHandler(Exception.class) → 500 internal_error + LOG.error. The three routes in the issue are three doors into that room, so I drove every publication route with an unknown id, on both arms, under one valid writer credential and lease.

12 routes swept per arm; 3 changed; 9 byte-identical. Zero 500s remain at head (base had exactly 3). So the bug class is closed across the whole writer-reachable publication surface, and the change carries no collateral effect on any route the PR did not intend to touch. The other two writer routes already refused via queryForList + require(...), which is why they were never 500s.

Witness: 02-route-sweep-sibling-base-vs-head.png.

Targeted gate — full managed-agent-server module at head

Tests run: 1983, Failures: 0, Errors: 1, Skipped: 85

The single error is RuntimeBrokerDefaultOnTest.defaultCombinationBootsWithTheYmlDefaultsBound, a Spring context-load failure whose root cause is java.nio.file.NoSuchFileException: /etc/machine-id. A/A control: the same test run on the base arm errors identically (Tests run: 1, Failures: 0, Errors: 1, same root cause), and /etc/machine-id genuinely does not exist in this container (ls: cannot access '/etc/machine-id': No such file or directory). This is the sandbox, not a regression — measured, not assumed. No other test class failed or errored.

Note this is a stronger result than the PR body reports: the author measured 1268 tests: 1204 passed, 1 failure, 59 errors on a Windows host and attributed 60 failures to filesystem/mount behaviour. On Linux the same module is green apart from one container-specific missing file, which supports the author's attribution rather than contradicting it.

Checkstyle / SpotBugs

Measured at head on the module: mvn -DskipTests checkstyle:check spotbugs:check → You have 0 Checkstyle violations., BugInstance size is 0, BUILD SUCCESS, exit 0 (gate-head-static.log). This independently confirms the PR body's static-check claim.

Gate liveness

The gates above are only evidence if they can fail, so each was proven live rather than assumed green: the A/B control arm is the liveness proof for the test suite (it goes red 3/7 on base with the intended assertion); the two positive-control mutants (ctl-status-conflict, ctl-code-marker) are the liveness proof for the new assertions, each turning all three cases red; and the mutation runner requires the unmutated baseline green before any row counts. The full-module gate's one error is attributed by an A/A control on the base arm, not by inspection.

Corrections

Two statements in the PR description are inaccurate in ways that would mislead the next reader. Both are corrections to the description, not requests to change the code.

1. "The two shared reads check for a missing record" understates the reach. verifiedStream (site 2) is not private to the range-read route — it is also entered by ManagedArtifactReader.openReferencedStream, i.e. by the artifact-download API. The description's scope statement ("from the finished-result, admission-prepare, and range-read routes") and its breaking-change note ("callers requesting a missing publication receive the new status and error code") both read as covering three routes; a fourth API family is affected. Evidence and consequence in Finding 1.

2. "gives the caller a consistent refusal" holds for the three routes changed, but not across the writer surface. After this PR an unknown publication yields 404 managed_tool_publication_unknown on three writer routes and 400 invalid_request ("The request body is invalid.") on the other two (/receipts/commit, /receipts/verify). Measured — see the sweep table. Those two 400s are pre-existing (identical on both arms) and are not this PR's doing; the correction is only that "consistent" is scoped to three of five writer routes.

Findings

1. Medium — an unnamed fourth consumer: artifact download turns a retryable 503 into a permanent 404

Status: inferred from code, not driven end-to-end. The call chain and the handler are quoted below; building a REFERENCED artifact and then deleting its publication row was out of budget (see Not covered).

Chain to changed site 2:

ManagedArtifactService.read(...)                       // HTTP artifact download
  → reader.readRange(artifact, …) / reader.open(artifact, …)
  → ManagedArtifactReader.verified(artifact, lease, guard)          :121
  → data().openReferencedStream(source.sessionKey(), artifact.publicationId(), …)  :135
  → ToolPublicationDataStore.verifiedStream(…)          // ← changed site 2

ManagedArtifactService's handler for that block (ManagedArtifactService.java:275-287):

} catch (RuntimeException error) {
    if (response.isCommitted()) {
        throw new IOException("Artifact stream interrupted", error);
    }
    if (error instanceof ApiException api) {
        if ("tool_output_session_retired".equals(api.getCode())
                || "tool_output_read_expired".equals(api.getCode())) {
            session(tenant, sessionId);
            throw unavailable();          // 503 artifact_unavailable
        }
        throw api;                        // ← the new 404 escapes here, untranslated
    }
    throw unavailable();                  // ← base: EmptyResultDataAccessException landed here → 503
}

with unavailable() = new ApiException(SERVICE_UNAVAILABLE, "artifact_unavailable", "Artifact content is unavailable.").

Why this deserves attention rather than a shrug:

• The allowlist shows intent. The author of this handler explicitly enumerated the publication-side codes that must be translated back into the artifact vocabulary, and mapped them to a retryable 503. managed_tool_publication_unknown is a new member of exactly that family and is not in the list, so it bypasses a deliberate translation layer.
• A retryable signal becomes permanent. If a publication row is transiently invisible to a reader whose artifact row still exists (retention/GC race, a mid-migration window), a client that previously retried on 503 will now treat the artifact as gone and may drop it. This is the "rank by observability" case: the loud, retryable failure became a quiet, terminal one.
• Namespace leak across an API boundary. An artifact-download client switching on artifact_not_found / artifact_unavailable now receives a managed_tool_publication_* code on an artifact_* route.

Blast radius — exactly one surface, and I narrowed it by checking the other candidate. Artifact download is the only consumer whose behaviour changes: both its full-read and its partial/range-read branches go through ManagedArtifactReader.verified(…) (:121 → :135), and ManagedArtifactService is the only caller with an ApiException-specific translation that the new code escapes.

The other consumer of changed site 2 is the async projection path ManagedToolResultProjector.project(claim) → resolve(…) → reader.verified(artifact, lease, guard) at ManagedToolResultProjector.java:222. That path is unchanged, and I verified it rather than assuming it: its handler is

} catch (NoSuchElementException error) {
    fail(claim, "UNSUPPORTED", "public_turn_mapping_missing", error);
} catch (IllegalArgumentException error) {
    fail(claim, "QUARANTINED", "tool_result_source_invalid", error);
} catch (RuntimeException | IOException error) {
    fail(claim, "RETRYABLE", "tool_result_source_unavailable", error);
}

ApiException extends RuntimeException (ApiException.java:6), and base's EmptyResultDataAccessException is also a RuntimeException; neither is a NoSuchElementException or an IllegalArgumentException. Both therefore fall into the same third catch and produce the same RETRYABLE / tool_result_source_unavailable outcome — no behaviour change, and the retry semantics that Finding 1 loses on the HTTP path are preserved here. Note the line that looks like the call site, ManagedToolResultProjector.java:248 (reader.readRange(selected, stream, …)), is not one: it consumes the already-built VerifiedStream from the map populated at :222.

Sites 1 and 2 are reached only from these consumers plus the three writer routes already measured.

What this is not. It is not a failure of the central claim (that A/B is clean), not a new 500, and not an authentication or tenancy change — the guard runs after sessions.restore(...), and the sweep confirms the three writer routes and all nine untouched routes behave as intended. No data loss or security consequence was demonstrated.

if (error instanceof ApiException api) {
    if ("tool_output_session_retired".equals(api.getCode())
            || "tool_output_read_expired".equals(api.getCode())
            || "managed_tool_publication_unknown".equals(api.getCode())) {
        session(tenant, sessionId);
        throw unavailable();
    }
    throw api;
}

2. Suggestion — the suppressed LOG.error is correct, and the reason still reaches the caller

Checked per the "follow the value" rule, because this PR suppresses output. Base path: EmptyResultDataAccessException → generic @ExceptionHandler(Exception.class) → LOG.error("Managed Agent request failed", error) + 500. Head path: ApiException → @ExceptionHandler(ApiException.class) → no logging, but the cause is carried in the response envelope the caller reads (error.code = managed_tool_publication_unknown, error.message = "Publication is unknown").

So the information survives in a field with a reader, and the suppression is exactly what the description intends — not a finding. One residual tradeoff worth naming: for the genuinely anomalous variant (a publication row that vanished underneath a live writer lease), operators lose the server-side log line entirely and see only a client-reported 404. Acceptable for an expected missing-resource case; just not free.

3. Suggestion — pre-existing, not this PR: two writer routes answer "unknown publication" with a misleading 400

/receipts/commit refuses via require(candidates.size() == 1, "Admission candidate is missing") and /receipts/verify via require(rows.size() == 1, "Original committed publication is missing or ambiguous"). ToolPublicationContract.require throws IllegalArgumentException, which ApiExceptionHandler.invalid(...) renders as 400 invalid_request / "The request body is invalid." — but the body is fine; the publication does not exist. Each predicate also conflates "publication unknown" with "publication exists but has no admission object".

Measured identical on both arms, so pre-existing and out of this PR's scope; recorded only because it bounds correction 2 above and because it is the same bug class in a milder costume. A follow-up could map these to the same 404.

Checked and disproved (no finding)

• queryForMap → queryForList().getFirst() does not weaken a uniqueness check. queryForMap also throws IncorrectResultSizeDataAccessException on >1 row, which getFirst() would silently swallow. That concern does not apply: qwen_tool_publication has PRIMARY KEY (scope_key, publication_id) (V20__managed_tool_publication.sql:23), and both queries filter on exactly those two columns plus narrowing tenant/workspace/session predicates. At most one row can match, so getFirst() is total after the isEmpty() guard and no duplicate-row behaviour changed.
• No catch clause on the path is bypassed by the new exception type. The only EmptyResultDataAccessException catches in managed-agent-server and runtime-broker are ManagedAgentStore.java:3572,3592 — a different store, unrelated to publications. (The ApiException catch that does matter is Finding 1.)
• 404 follows existing house precedent. GET …/operations/{op} already returns 404 managed_tool_publication_operation_unknown (measured in the sweep), so a scoped 404 + specific code is the established shape, not a new convention.

Not covered

• Finding 1 was not driven end-to-end. No fixture was built for "REFERENCED artifact whose publication row is missing". The chain and handler are quoted from source at head; the 503→404 delta is inferred from code, not observed on the wire. What would close it: a ManagedArtifactReadIntegrationTest-style case that deletes the publication row and asserts the status.
• Cross-scope existence leak — inferred only. A publication that exists under a different tenant/workspace/session takes the same empty-result branch (the WHERE clause carries tenant_id, workspace_id, session_id), so it should return the identical 404 managed_tool_publication_unknown with no existence leak. I did not plant a row in a second scope to measure it.
• Broker-only path finishedForBroker. It also reaches changed site 1, and is not exercised by the PR's HTTP tests. Inferred unchanged: its own scope-less query finds the row, it derives the key from that row's tenant/workspace/session, so the scoped re-query in finishedInternal matches. Not measured.
• MySQL/MariaDB failsafe integration profiles and the hosted harness — need a real database and a bundled dist/cli.js; this lane is JDK 21 + H2 only.
• Real OSS object storage — ToolPublicationObjectStore was mocked in every harness (as it was in the PR's own).
• Java 11/17 matrix — stays on sdk-java.yml; this lane has Temurin 21 only.
• Node/TypeScript gates — not run. The diff touches no Node code (git diff HEAD^1..HEAD --stat: 2 Java files), so there is nothing to gate.
• Trial merge into current main — the CI checkout already is the merge ref, and the full-module gate ran on it. The metadata snapshot's baseRefOid (9a02f405…) differs from HEAD^1 (6936c77e…), i.e. main moved between snapshot and merge; the merge ref is what lands and is what I measured. Depth-2 history cannot enumerate what main added in between, so I cannot list base-side deltas — the green 1983-test gate on the merged tree is the coverage for semantic-conflict risk.
• Per-commit attribution — not needed and not skipped: git rev-list HEAD^1..HEAD^2 returns 1 commit, matching the metadata commits array length of 1, so the aggregate diff is the single commit.
• Real OSS-backed large-output tail read after replacing the store instance (Reviewer Test Plan step 3, second half) — needs real object storage. The in-process half of step 3 (an existing publication can still be finished/admitted/range-read) is covered by the 1983-test module gate, which includes the publication storage and admission acceptance suites.

Reviewer Test Plan, walked step by step

No step was structurally impossible to perform.

Methodology

CI verify lane: node:22-bookworm container, no GitHub token, working tree at refs/pull/13602/merge (depth 2). Temurin JDK 21.0.12.1 + Maven 3.9.11, MAVEN_ARGS=-Dmaven.repo.local=/__w/_temp/verify-maven-repo; qwencode and runtime-broker were pre-installed from this checkout (java-prepare.log: qwencode=0 runtime-broker=0).

The A/B control arm is a scratch worktree (git worktree add tmp/base-tree HEAD^1). Reusing the shared Maven repository for the sibling modules is a clean control here because the PR leaves them untouched — asserted, not assumed: git diff HEAD^1..HEAD --stat -- packages/sdk-java/qwencode packages/sdk-java/runtime-broker is empty, and qwencode/runtime-broker are consumed as installed jars, not as symlinks into the head tree, so no head code can leak into the base arm.

All harnesses are mock-free with respect to the unit under test: real H2 + Flyway (63 migrations applied), real ManagedSessionStore / WriterCredentialPolicy / ToolPublicationStore / ToolPublicationDataStore / ToolPublicationAdmissionStore, real controller mappings and the real ApiExceptionHandler, driven over Spring MockMvc. Only ToolExecutionRepository, RuntimeBindingRepository and ToolPublicationObjectStore — none of which these read paths touch — are mocked. Oracles are HTTP status plus the parsed error.code from the response envelope, taken from the handler's output rather than from any store-internal signal.

The route sweep is an arm-agnostic recorder: the identical VerifyRouteSweepTest.java (harness only, not part of the PR, removed from both trees after running — git status --porcelain clean) prints one SWEEP|route|status|code line per route and asserts no statuses, so base and head outputs are directly diffable. The mutation runner (run-mutants.sh + mutate.mjs) restores the pristine source from a copy before each mutant, aborts unless every anchor matches its expected count exactly, verifies each mutant in the compiled bytecode via method-scoped javap -c -p, and restores the tree at the end (SOURCE-RESTORED-OK).

Every number in this report is produced by score.mjs from the raw logs in this directory — none is hand-counted. Raw artifacts: head-test-1.log, base-test.log, sweep-head.log, sweep-base.log, mutant-*.log (7), mutation-matrix.txt, gate-head-full-module.log, gate-base-RuntimeBrokerDefaultOnTest.log, assertions-detail.txt, assertions.json.