feat(managed-agent): let creators change a bound Session's directory (W2) - #13247

E2E test report — W2 controlled same-Workspace cwd change

Plan + full notes: .qwen/e2e-tests/managed-workspace-w2-cwd-change.md (working-copy artifact, not committed). Verified on this PR's head 775565c286 (= origin/main a011f66944 + this commit), JDK 21, H2 MODE=MySQL, Node 22, freshly bundled dist/cli.js from the same tree.

Baseline (pre-change, earlier in the slice)

• npm run build && npm run typecheck && npm run bundle passed at main; the focused Java baseline (contract, operations, lifecycle, workspace admission) passed pre-change.
• The G0 hosted IT baseline first failed with Table "qwen_runtime_harness_drain" not found — the shared local ~/.m2 0.1.0-alpha runtime-broker jar had been overwritten by another worktree's build; reinstalling it from this tree restored parity (HostedPublicWorkspaceIT then passed). Both runtime-broker and qwencode alpha jars were reinstalled from this PR's tree again before every suite run below.
• Pre-change route status: both cwd routes existed only as planned, unmapped (drift-pinned).

Results (this PR's head)

Review notes and deferrals

• Readable non-creators answer 403 session_operation_forbidden — the exact pairing the merged bound lifecycle (feat(managed-agent): reliably close workspace-bound sessions #13135/feat(managed-agent): archive and delete closed workspace sessions #13194) ships; admission delegates to their requireWorkspaceCreator. A stranger (no read grant) stays invisible at 404 on every path.
• The final self-audit on the integrated base fixed and re-verified: a duplicate import, a merge-stray test signature line, one stale errorCode() call-site, the pre-rename V31 migration copy in the build output, and the lifecycle queue's database-time authority (feat(managed-agent): reliably close workspace-bound sessions #13135) — beginCwdChangeOperation anchors available_at to database time, complete/fail fence on a live lease exactly like upstream completeOperation, and the three clock-driven tests expire leases via direct SQL matching the upstream store-test precedent.
• Recorded deferrals (post-round-5 policy, Suggestion class): the design admission table omits the 401 step row (behavior is pinned in the contract description + exchanges); the WebShell @Size(128) over-length key classifies as 400 invalid_request while the public surface uses invalid_idempotency_key — disclosed in the WebShell route description.

MySQL lane: not run locally — CI runs the hosted MySQL suites; the H2 coverage uses MODE=MySQL with the production SQL. The reverse race (bound later-turn admission vs an open cwd operation) is N/A on main since post-creation bound turns still throw; the #13112 handshake is recorded in the design doc's follow-ups.

CI note — the first run's Runtime Broker and Managed Agent MariaDB / Java 21 lane is fixed in a2d7bd3b02 and every lane is now green.

Root cause: WorkspaceSessionRetentionMySqlIT pins a V31 schema before upgrading, and the operation mapper read the additive V34 columns (target_cwd_relative, expected_context_revision, result_context_revision) unconditionally — a pinned-schema read of managed_agent_operation failed with bad SQL grammar. The H2 suite never constructs a pinned schema, so it stayed red-free locally; this lane caught exactly the invariant it exists for.

Fix: additive reads go through a metadata existence check — an absent column maps to null, content no operation row can carry anyway — with the invariant pinned locally by a new H2 twin (ManagedOperationSchemaUpgradeTest: pinned V31 → read → upgrade → read). Post-fix local evidence: full module suite 67 classes / 488 tests, 0 failures/errors/skipped; mvn checkstyle:check clean. CI on a2d7bd3b02: all lanes pass, including the previously red MariaDB one.

Real-stack verification: W2 same-Workspace cwd change @ a2d7bd3b02

Verdict: the mechanism holds on a real stack. Before merging: rebase onto current main, renumber the migration (B1), and fix the settlement probe (F1). F1 was latent until 01:42 UTC today. Now that #13112 has merged, the unreadable-directory case is directly reachable on main.

Setup:

• macOS host, JDK 21, MySQL 8.4.7.
• The real Spring fat jar with its embedded Runtime Broker, the packaged Hosted Harness (dist/cli.js built from this head), a deterministic fixture model and a rig actor adapter. Everything goes over HTTP; facts are read back from MySQL.
• Arms:
  • head
  • merge base a011f669
  • head ⊕ main fa795e0232
  • head ⊕ main 2b15eac862: feat(managed-agent): let a Workspace-bound Session's creator submit, cancel and rename #13112 merged at d20a1895, which is the same commit as my earlier trial merge.
  • each of the above plus a candidate patch.

Merge items

B1 — Flyway V34 collides with main (blocker, mechanical). #13225 (merged 00:17 UTC) added V34__managed_tool_output_collection.sql.

• What happens: against fa795e0232, git merges cleanly, but the server fails at startup with Found more than one migration with version 34, and no migrations are applied.
• Why CI is green: it ran on the older merge ref.
• Since feat(managed-agent): let a Workspace-bound Session's creator submit, cancel and rename #13112 merged, the PR also conflicts textually in README.md and the OpenAPI info.version (1.30.0 vs main's 1.29.0). GitHub now shows CONFLICTING.
• Verified fix: renaming the file to V35__managed_cwd_operation.sql works.
  • A DB built by the main jar (V34) upgrades to V35.
  • A Session created by the main jar changes directory afterwards.
  • S1 passes 24/24, and so does head ⊕ 2b15eac862. On that tree the unit suite passes 553/553 and later Turns 6/6.
• Coordination: open feat(managed-agent): broker authentication and broker-provisioned writer credentials #13210 (V34) and fix(managed-agent): stop database amplification on session hot paths #13217 (V34, V35) claim the same numbers.

F1 — the settlement probe accepts a directory the worker will refuse (should fix).

• The cause: WorkspaceRuntimeResolver.requireDirectory checks containment, isDirectory(NOFOLLOW_LINKS) and realpath identity. It has no access check. The worker does have one: managed-context-worker.ts:123 calls fs.access(directory, R_OK | X_OK).
• The design names exactly this gap and says the divergence "surfaces at the first turn, still typed, never misdirected". The bot review reasoned the same way. "Never misdirected" holds; "typed" does not.
• On head ⊕ main 2b15eac862, with one fresh storage per trial and directory modes 000, 444 and 111 (3/3 each):
  • The cwd change reports completed.
  • The next later Turn claims storage and its install fails. The Harness logs recovery blocked: … HTTP 503 (runtime_session_acquire_failed). The qwen_runtime_session row stays ACQUIRING and the storage execution lease stays held, so the Turn stays RUNNING indefinitely.
  • Every other Session on that storage then fails its tool Turn: 409 workspace_busy → hosted_turn_failed. That includes other creators' Sessions in the same Workspace.
  • The Session itself refuses further cwd changes (409 session_context_busy). Later Turns get turn_active.
  • Neither chmod 755 nor a Spring + Harness restart cleared it: after 3 more minutes the Turn was still RUNNING and the lease still held. That was on the macOS non-durable stack; I did not exercise Linux durable recovery.
  • A worker running as root bypasses mode bits, but would hit the same path on any other access denial.
• Attribution: G0 creation straight into a mode-000 directory wedges the same way (no W2 involved), so the Turn-path wedge already exists on main. W2 is the first path that moves a working Session into it.
• Candidate fix: +7/−1 in the shared requireDirectory (Files.isReadable && Files.isExecutable). Because this PR moved requireDirectory into the resolver, one line covers both the W2 probe and acquire()'s pre-claim check, so it fixes G0 too. Results with the candidate:
  • 3/3 changes fail with failed/workspace_unavailable. The later Turn and the neighbour both complete, and the next change is admitted.
  • G0 into a mode-000 directory now fails hosted_turn_failed in 671 ms, with 0 leases held.
  • The unit suite passes 486/486 on head and 554/554 on the merge. checkstyle:check is clean.
  • The new test fails on unpatched head.
  • candidate.patch

T1 — ManagedOperationSchemaUpgradeTest does not pin the upgrade fix (test gap).

• The test only reads an empty table, so the RowMapper never runs.
• M18 makes additiveString read unconditionally. M18b also does it for additiveLong, which reproduces the pre-a2d7bd3b02 behaviour. The H2 test passes both mutants.
• Only WorkspaceSessionRetentionMySqlIT kills them. I ran it against MySQL 8.4.7: 16/16 on head, and an error under M18b.
• The candidate patch's version of the test first seeds a row admitted before the upgrade. It kills M18 and M18b and passes on head.

Minor notes (no merge impact)

• N1 "a stranger always gets 404". With workspace-files-enabled=false, a stranger (no grants) gets 409 workspace_unavailable for a real bound Session, but 404 for an unknown id and 404 on GET. That is an existence oracle inside the tenant, because steps 3–4 precede the visibility check. In the same configuration, replaying a completed change answers 409 instead of the original operation. For legacy Sessions, the 400 unsupported_feature a stranger gets is fine: those Sessions are tenant-visible (GET 200 for the same stranger).
• N2 rollback. "Old binaries ignore them" holds for completed changes: the base jar starts on V34, reads the Session and answers 400 invalid_request for GET of the cwd operation. A change still open at rollback stays open under the base jar, which logs IllegalArgumentException: No enum constant …OperationKind.CWD_CHANGE. It blocks that Session's admissions until a W2 binary returns, and the W2 binary then completes it exactly once.
• N3 lenient JSON. cwd_relative: 7 is admitted as "7". expected_context_revision: "1" and 1.9 are both accepted as 1. The contract says string and integer.
• N4. An operation sitting in retry backoff (state RUNNING, delivery PENDING) reads installing.
• N5 feat(managed-agent): let a Workspace-bound Session's creator submit, cancel and rename #13112 handshake (already recorded as a follow-up). Later-Turn admission does not consult open cwd operations. On the real stack this is safe:
  • A Turn admitted during an open change that is still running at commit fails the change with session_context_busy. The Turn completes in the old directory and the revision is unchanged.
  • If the Turn finishes first, the change commits afterwards.
• N6. M15 (digest over the raw spelling instead of the normal form) survives the full 485-test unit suite. Only HostedPublicWorkspaceIT kills it, which CI runs. Just noting where the normalization is pinned.

What holds

¹ D1 (can_read revoked) was confirmed from the operation row (FAILED / workspace_unavailable). The probe polled as the revoked actor and, correctly, got 404.

Evidence (rig, probes, MySQL fault/hold triggers, per-arm results, mutation ledger, candidate patch): wenshao/qwen-code@84e0818 → pr13247/

Merged origin/main (38a8185e89) — the PR was conflicting after #13112 (bound later turns), #13090, #13216, #12939, #13192 landed.

Textual resolutions: contract header stays v1.30.0 and now carries the upstream v1.28 changelog entry; the README capability inventory is unioned; the migration moved V34 → V35 after #13090 took V34.

Two integrations beyond text, because #13112's merged admission path did not gate bound later turns on open operations — the handshake this design reserved:

• insertTurnCommand now refuses 409 session_context_busy for a bound Session with an open operation (same Session row lock). A cancel during an open operation is still admitted and makes the in-flight settlement fail typed (session_context_busy, re-issuable) — never a wrong commit.
• HostedPublicWorkspaceIT gained the end-to-end pivot proof the design deferred to feat(managed-agent): let a Workspace-bound Session's creator submit, cancel and rename #13112: after the change settles, a bound later Turn's file writes land only in the committed directory.

Re-verified on the merged tree (JDK 21, Maven 3.9.11 — the new SpotBugs gate runs in clean verify): mvn clean verify checkstyle:check exit 0, 70 classes / 569 tests, 0 failures/errors/skipped, SpotBugs and checkstyle clean; HostedPublicWorkspaceIT via its dedicated invocation 3 passed + 1 skipped (durableClose is Linux-only); hosted harness rebuilt from this tree; root build/typecheck/bundle and the regenerated WebShell types all green. CI is re-running on the merge head.

R2 round disposition (fix commit 259790e12d)

All 28 threads of the R2 review are replied and resolved. The four Criticals each changed production order or a guard; the Suggestions drove sixteen accompanying fixes and one documented design choice.

Criticals. R2-1 replay now precedes the deployment gate, so a lost 202 resolves through the original operation even with execution disabled meanwhile (actor invisibility still precedes both); R2-2 the settlement probe verifies the candidate binding, so a change away from a destroyed current directory stays reachable; R2-3 the shared requireDirectory carries the worker's own access(R_OK|X_OK) checks on both the probe and the acquire path, so nothing completes a change the worker would refuse as an untyped wedge; R2-4 the bound later-Turn barrier counts context-changing operation rows only (operation_kind <> 'ACTION_RESPONSE'), so a stuck display mutation or an in-flight permission Action can never wedge the Session's only re-acquire path — while a cwd operation still blocks and releases on settle.

Suggestions. Highlights beyond the Critical follow-through: the admission service enforces 401-before-key itself (two exchanges pin it on both surfaces); the refusal log/failure code come from error.getCode() with class and message; both stale contract sentences (cwd operations remain gated) now point at the shipped operation; the WebShell cwd description enumerates unsupported_feature and the deleted-404 with the over-length classification divergence disclosed; the hosted IT runs a real initial tool Turn in directory A so the later Turn has an installation to escape, with fail-fast diagnostics; settlement calls in the pin suite route through a real transaction uniformly; both admission surfaces are asserted released after FAILED and COMPLETED settlements; the four-predicate fail fence is genuinely isolated conjunct by conjunct; the V34→V35 comment stragglers are gone; design twins were rewritten to the shipped truth (pipeline rows, citations, cancel's benign mechanism, the narrowed Turn barrier, probe parity claims).

Verification on 259790e12d (fenced -Dmaven.repo.local after the shared .m2 alpha jar was clobbered a third time — see the tracking comment for the fencing recipe): mvn clean verify checkstyle:check exit 0 — 70 classes, 578 tests, 0 failures/errors/skipped; hosted IT 3 passed + 1 skipped (durableClose is Linux-only); regenerated WebShell types + api test 2/2. The remaining deferrals: unit-lane schema validation of the projected cwd body (the hosted IT already proves the failed⇒failure_code conditional end to end), and the review body's own undisclosed-gap list.

R3 round disposition (fix commit 4f9e60b300)

All 17 threads replied and resolved — one Critical plus the Suggestions and fix-induced refiles.

Critical R3-1 was the sharpest: a cwd change could be admitted and committed while a permission Action was still requested and answerable — every other admission barrier consulted it, this one didn't. Both the admission and the settlement re-check now consult hasDecidableAction(session), matching the sibling lifecycle's 409 turn_active state, with release after the Action resolves pinned in tests.

Suggestions. Highlights: settlement splits a detached binding off from the CAS path (workspace_unavailable, not context_revision_conflict); transient probe I/O keeps its cause and retries through the delivery machine instead of certifying a verification that never happened (unavailableTransient + isRetryable() consulted at settlement); the busy barrier's wider settle disjunct is pinned on a planted second open operation; the two permission conjuncts are discriminated mode by mode with a uid-aware gate, and the shared rule is proven to fence acquire() before installContext; both guarded probes pin the negative half (verifyNoMoreInteractions); four key-form probes land including the published 129-char classification divergence on both surfaces; the new ManagedCwdOperationContractShapeTest instance-validates the cwd operation DTOs against the reviewed schemas, including the failed → failure_code required conditional and the enum bound; the reclaim tail re-reads the settled operation after the second dispatch; the IT's sentinel ("sentinel" written into the original directory before the later Turn) makes the pivot individually discriminating instead of byte-identical.

Docs. The design twins were rewritten where the PR had drifted from truth: pipeline row 14 lists the Action clause, the barrier's real premise with the stuck-rename consequence spelled out (deliberate trade), transient-vs-structural probe verdicts. The WebShell route description now enumerates its refusals in the actual wired order and the v1.30 changelog sentence names only context-changing operations on the handshaken Turn barrier.

Verification on 4f9e60b300 (fenced -Dmaven.repo.local): mvn clean verify checkstyle:check exit 0 — 71 classes, 585 tests, 0 failures/errors/skipped; HostedPublicWorkspaceIT 3 passed + 1 skipped (durableClose Linux-only). The review body's disclosed gaps remain as delivered context.

Real-stack re-verification (round 2) @ 4f9e60b300

Verdict: the round-1 merge items are resolved, the mechanism still holds, and I found no new blocker. B1, F1 and T1 are fixed and verified on the real stack, and so are N1 and N5. Three optional items before merging:

• Add the candidate tests (+65 lines). Two of R3's new claims are not pinned by any unit test or the Hosted IT; only the real stack catches them.
• Coordinate the V35 number.
• Decide on the unbounded transient retry (O2).

What blocks the merge today is the bot's standing CHANGES_REQUESTED on 259790e12d. Its review run for this head is still pending; everything else in CI is green.

Setup:

• Arms:
  • head 4f9e60b300
  • head ⊕ main 2c591ecc08: main has moved 19 commits; the merge is clean and the W2 migration is V35.
• macOS host, JDK 21, MySQL 8.4.7, the real Spring fat jar with its embedded Broker, the packaged Hosted Harness, a fixture model and a rig actor adapter.
• Every scenario was re-run on head ⊕ main; the key ones on head too.
• Main now contains feat(managed-agent): default durable local-process and trusted reboot recovery on #13211 (durable local-process on by default; it requires Linux). On this macOS rig the head ⊕ main arm sets durable-local-process=false and trusted-local-reboot-recovery=false. This is a rig setting, not a PR issue.

Round-1 items

• B1, resolved. head ⊕ main merges cleanly and starts. A DB built by the main jar (V34) upgrades to V35, and a Session created by the main jar changes directory afterwards (S7 8/8). Open feat(managed-agent): broker authentication and broker-provisioned writer credentials #13210 and fix(managed-agent): stop database amplification on session hot paths #13217 now also claim V35; whoever merges second has to renumber.
• F1, fixed (R2-3).
  • Directory modes 000, 444 and 111 now end failed/workspace_unavailable (3/3). The next later Turn and a neighbour Session on the same storage both complete, and the next change is admitted.
  • G0 creation into a mode-000 directory now fails hosted_turn_failed in 1.45 s with 0 storage leases held. In round 1 the Turn stayed RUNNING forever with the lease held.
• T1, fixed. The schema-upgrade test now inserts a row first. M18b (dropping the additive-column tolerance) is killed by the H2 test itself.
• N1, fixed (R2-1). With the opt-in off, a stranger gets 404, the same as for an unknown id. Replaying a completed change returns 202 replayed (S8 4/4).
• N5, fixed (handshake).
  • A later Turn during an open change gets 409 session_context_busy, and is admitted again once the change settles.
  • A stuck PENDING rename, or an open ACTION_RESPONSE operation, does not block later Turns but does hold the cwd change (R2-4, S19 3/3).
  • Cancelling a finished Turn during the change, or renaming during the change (409 session_operation_active), behaves as designed (S17 3/3).
• N2/N3/N4/N6, unchanged (minor). A rollback with an open op still leaves it open until the W2 binary returns, scalar JSON coercion is still lenient, the backoff state still reads installing, and M15 is still pinned only by HostedPublicWorkspaceIT.

New in this round

O1: two R3 claims are pinned only by the real stack (test gap). I ran 32 mutants of the new and old W2 guards; the PR's focused tests kill 27. I re-ran the survivors against the full unit suite (585) and HostedPublicWorkspaceIT, then against the real stack using mutant jars:

Why the unit tests miss them:

• aRequestedActionBlocksAdmissionAndSettlement plants its Action on a Session that already has an open cwd operation, so hasOpenOperation refuses before the Action clause is reached.
• coordinatorSettlesFailsTerminallyAndRetriesTransientErrors injects an IllegalStateException, not the new retryable RuntimeBrokerException.
• Nothing removes a mount root.

candidate-tests.patch adds three tests (+65 lines, test-only): an Action alone blocks admission; a unavailableTransient refusal keeps the operation open with attempt_count=1; a missing mount root is isRetryable() and heals when the root returns. They pass on head (37/37, checkstyle clean) and kill N5, N12 and N11 respectively.

O2: the transient retry has no attempt bound (decide or document). In S15 the mount root disappears for 9 s mid-settlement:

• While it is missing, the operation retries (attempt_count 3). The Session refuses later Turns and further changes (409 session_context_busy) and renames (409 session_operation_active). By code, close/archive/delete hit the same barrier; I could not exercise that because bound close is unavailable on macOS.
• When the same root returns, the operation completes. A replacement root with a new file key ends FAILED workspace_unavailable.
• If the root never returns, the operation retries forever: the delay is capped at 60 s but the attempt count is not. The comment at SessionLifecycleCoordinator.java:189 calls this the "bounded retry". Healing on return is a reasonable choice. I'd still either cap the attempts and end typed, or reword the comment and document that an unreachable mount holds the Session until an operator restores it.

O3, informational. A readable non-creator on a DELETED Session now gets 403 session_operation_forbidden on the cwd route (round 1: 404). The sibling close/archive/delete routes answer exactly the same, with the creator and strangers getting 404 (S18), so this is consistent with them.

O4, not W2. ManagedArtifactReadIntegrationTest.OverlappingReadsRefuseImmediatelyAndTimeoutReleasesPermit (80 ms read timeout) failed in 2 of 11 head ⊕ main runs and 0 of 10 runs on pure main, under host load of 80–140. Interleaved runs passed 6/6 on each arm, the PR does not touch that path, and the second full-suite run passed. I count it as a load flake.

What holds (head ⊕ main unless noted)

¹ D1 (can_read revoked) was read from the operation row (FAILED / workspace_unavailable). The probe polls as the revoked actor and, correctly, gets 404.
² Case C forces the Turn row terminal with SQL so that only the requested Action remains. S19 likewise seeds its PENDING rename and ACTION_RESPONSE rows with SQL.

Not covered:

• I ran nothing on Linux durable local-process, which is now main's default. So the storage-guard half of R2-2 (verify the candidate binding) was not exercised on a real stack. It is pinned in unit tests: mutant N9 (verify the current binding instead) is killed by aGuardedMountVerifiesTheProbeTarget.
• The head ⊕ main arm runs the main-built dist/cli.js. The PR itself changes no CLI code, only the generated WebShell types.

Evidence (rig, probes, per-arm results, mutation ledger and logs, candidate tests): wenshao/qwen-code@547aa9c → pr13247/r2/ · Round 1: issuecomment-5964450917

Merged origin/main (f1f76703c5) after three commits landed meanwhile — clean conflict-wise; one required follow-up: #13363's tool-profile migration took V35 while the cwd migration was under review, so the renumber to V36 (1a55a6b246) is the only change on top. The branch now carries the complete posted base — #13112 later turns, #13363's Druid pool, #13365's replay-probe fixes, #13146's workspace trust — with contract v1.30.0 and Flyway V36.

Re-verified on the merged tree (fenced -Dmaven.repo.local): mvn clean verify checkstyle:check exit 0 — 611 tests, 0 failures/errors across 71 classes; HostedPublicWorkspaceIT 3 passed + 1 skipped; hosted harness rebuilt from this tree. The testWhileIdle … validationQuery not set lines in the IT log are the new pool's startup notice from #13363, not a fault — the suite is green. R4 review traffic waits for the verifier bot's next pass on this head; CI is running on 1a55a6b246.

Real-stack re-verification (round 3) @ 1a55a6b246

Verdict: blocker again: the migration number collides with main once more (B1).

• fix(managed-agent): stop database amplification on session hot paths #13217 merged at 13:57 UTC with V36__managed_session_journal_activation.sql (plus V37–V39). That was 40 minutes after this PR renumbered to V36. The PR's own "Flyway migration version uniqueness" check had finished at 13:20:49 UTC, so it is still green.
• GitHub shows no text conflict. Merging as is would put two V36 files on main: the server stops starting, and the uniqueness check on the main push turns red.
• Everything else holds on head ⊕ main once the W2 file is renumbered.
• The round-2 optional items (candidate tests, unbounded transient retry) are still open; the W2 sources and tests are unchanged since 4f9e60b300.

B1 on head ⊕ main 17c182eda0 (11 commits past the PR's merge base):

• The real fat jar fails at startup with Found more than one migration with version 36 (V36__managed_session_journal_activation.sql and V36__managed_cwd_operation.sql). This happens both on a fresh MySQL database and on a database built by the main jar (V39).
• On the same tree, the CI's own scripts/check-flyway-migrations.js exits 1. On head alone it passes.
• Renaming the W2 file to V40 makes the server start. The uniqueness script then passes on 17c182eda0 and on the newer main 292c49ec4a, which has no further migrations; there the contract and W2 tests pass 40/40.
• V40 is not a safe pick either: open feat(managed-agent): add reliable ACTIVE Workspace deletion (L3) #13354, feat(managed-agent): H3 background Shell and Monitor runtime #13265, feat(managed-agent): broker authentication and broker-provisioned writer credentials #13210 and feat(runtime): add experimental Kubernetes CSI runtime and durable worker ACK #13289 all claim V40 (and V41–V43 are taken too).
• Suggestion: renumber to the next free version right before merging, then re-run the uniqueness check or CI on the current merge ref. A green check from before the latest main push proves nothing about the merge.

Everything else, re-run on head ⊕ main with V40:

¹ D1 (can_read revoked) was read from the operation row (FAILED / workspace_unavailable). The probe polls as the revoked actor and, correctly, gets 404.
² One H2 run errored in ownerAnswersHostedApprovalsThroughBothSurfaces, an approval test rather than a W2 one: the Turn was still RUNNING after 35 s at host load ~45. Three reruns passed on the merge, and three on main as a control; the MySQL run passed.

Still open from round 2 (non-blocking):

• O1: mutants N5 (admission ignores a requested Action), N11 and N12 (transient I/O classified structural, or a transient refusal made terminal) still survive the PR's tests on this head. The round-2 candidate-tests.patch applies cleanly, passes 37/37 with checkstyle clean, and kills all three.
• O2: the transient retry still has no attempt bound. S15 behaves exactly as in round 2.

Setup:

• macOS host, JDK 21, MySQL 8.4.7, the real Spring fat jar with its embedded Broker, the packaged Hosted Harness built from the merge tree, and a fixture model.
• The merge arm sets durable-local-process=false and trusted-local-reboot-recovery=false, as main's feat(managed-agent): default durable local-process and trusted reboot recovery on #13211 requires on non-Linux hosts.
• Not covered: Linux durable local-process.

Evidence: wenshao/qwen-code@c7e1cf9 → pr13247/r3/ · Round 2: issuecomment-5976428811 · Round 1: issuecomment-5964450917

复核提交：1a55a6b2467125033bb0747166543d6004a91c80；同时核对远端 main@292c49ec4a86416d7884cce0d355cc955fe69e50。

结论：当前仍有 1 个合并阻断；其余审阅路径未发现新增阻断问题。

[P1 / Critical] Flyway V36 撞号仍然成立。 本 PR 的 V36__managed_cwd_operation.sql 与已合入 #13217 的 V36__managed_session_journal_activation.sql 冲突。独立合并两端迁移命名空间后，仓库自己的唯一性检查返回 exit 1，明确报告这两个 V36；直接合并会使 Flyway 无法初始化、服务启动失败。当前主线已到 V39，合并前需要按届时主线协调空闲编号，并针对更新后的合并结果重跑迁移检查。旧的绿色 CI 和文本可合并状态不足以证明此处安全。

这是对已有 B1 报告的独立确认，不重复开新问题。

此前其余 6 条 Critical 已逐项对照当前源码复核：撤权后的重放保持不可见；重放先于部署开关；目录探针校验候选 binding；可读/可搜索检查先于存储 claim；后续 Turn 屏障排除展示 mutation 和 ACTION_RESPONSE；cwd 准入与结算均检查待决 Action。另检查了 revision CAS、租约与 claim generation、失败时保留原目录、提交与事件的事务一致性、两侧 operation DTO 和双语设计说明。

本轮独立验证：JDK 21 / Maven 3.9.11，使用隔离 Maven 仓库构建当前提交的依赖；7 个相关测试类共 70 个仓库测试通过，另 3 个独立探针通过（撤权后不同 payload 的重放仍为 404、关闭开关后重放已完成 operation、仅有待决 Action 时拒绝 cwd 准入）。git diff --check 通过。PR 单分支测试通过不抵消上述合并冲突。

验证边界：本轮没有重跑完整 Hosted/MySQL 栈；真实 verified-recovery storage guard 的额外探针被 macOS 平台限制拒绝（要求 Linux），候选 binding 路径仅有源码检查及现有 mock 测试证据，不声称完成了 Linux 真实守卫验证。

已报告的测试覆盖缺口和无限瞬时重试取舍继续留在原讨论中，本轮不把它们重复列为新发现。

Review round 4 disposition (1 Critical + 8 Suggestions — all 9 answered, threaded replies posted and resolved):

• The Critical (probe failure classification drawn at the exception's origin): both IO catch sites now split NoSuchFileException → the terminal workspace_unavailable from other IOExceptions → unavailableTransient, so a permanently vanished mount root or target settles typed instead of wedging the Session with unbounded retries; the fault's meaning, not the origin class, decides (fix f1c7cf242b).
• Observable split in both directions: terminal probe refusals assert !isRetryable() at every probe-suite call site plus a vanished-target/vanished-mount witness, and coordinatorRetriesARetryableProbeRefusalThenSettles is the red line for removing the coordinator's isRetryable() consult (witnesses c6a35b6a82).
• Retry prose aligned with the mechanism everywhere: unbounded in count, capped in delay — class Javadoc, inline comment and both design twins.
• The hasDecidableAction conjunct has its isolated admission witness (no op, no Turn); the settlement's ACTIVE re-check is pinned by closing the Session between claim and commit; the sealed-acquire test now proves no storage claim is recorded after refusal (holder_key count zero); the cwd instance suite also validates against the serving PublicOperation / WebShellOperation unions and credits the drift harness instead of claiming exclusivity; the published key-form sentence now counts both divergences (over-length AND blank), with blank-key exchanges pinned on both surfaces and the generated client regenerated.
• Self-audit after the fix commit caught two pieces its own message announced but never landed (the Critical's regression witness, the Javadoc reword) — both landed for real in c6a35b6a82.
• The merge with origin/main (bda7a7590e) collided a second time on the Flyway numbering: the session-journal chain took V36–V39 meanwhile, so the cwd migration is now V40 (3efa63c664); stale build copies purged, check-flyway-migrations.js reports 40 unique.

Verification on c6a35b6a82 (fenced Maven repo): mvn verify checkstyle:check — 681 tests, 0 failures / 0 errors / 1 skipped, SpotBugs + checkstyle clean; HostedPublicWorkspaceIT 3 passed + 1 skipped on a real Node 22 harness (cwd changes settle, sentinel isolation between old and new directories, failure_code surfaces on both APIs); root npm run build && npm run typecheck green. Awaiting the next review pass.

Review round 6 disposition (1 inline Critical, third narrowing of R4-1 — answered, threaded reply posted and resolved; the round's deferred list was recorded without requests):

• Critical (R4-1, [certifies-falsely] [regression]): both surfaces fixed in 7f1b9cb5d4. The pre-existing tool-turn acquire path is restored to its legacy semantics — boolean-predicate requireDirectory / verifyMountIntact with every I/O anomaly terminal, so an ENOTDIR-shaped persisted cwd fails the Turn immediately with the accurate workspace_unavailable instead of transientFailure retries into hosted_harness_unavailable or a RECOVERY_BLOCKED park. The settlement probe moves to explicit twins — requireDirectoryForProbe / verifyMountIntactForProbe — and since ENOTDIR/ELOOP reach some JDKs as a bare FileSystemException (no subclass to catch), the probe's residual IOException arm walks the ancestor chain: a plain-file or dangling/looping symlink ancestor is structural → terminal; whatever remains (ESTALE/EIO, ENAMETOOLONG) retries through the 8-attempt budget. Witnesses per the acceptance: assertProbeRefused("plain-file/lib") and assertProbeRefused("loop-a/lib") beside the nested suite, and WorkspaceRuntimeTest.refusesAPlainFileDescendantCwdTerminallyBeforeClaimingStorage; the fix-removed mutant makes both go red (measured), restored they are green; aMomentaryIoFailureClassifiesRetryable stays green and the budget's attemptCount == 1 witness stays intact.
• Also this cycle: upstream meanwhile landed feat(managed-agent): broker authentication and broker-provisioned writer credentials #13210's qwenSignature v1.30.0 (contract-version race resolved by the standing rule — this slice now ships v1.31.0 with both changelog sentences kept) and the V40–V44 migration band (so the cwd migration is V45, third landing-time renumber); the README conflict was resolved keeping both feature sections with the settle retry budget now recorded in its refusal paragraph; the generated client was regenerated. Two items on the round's deferred ledger were closed incidentally by that same resolution (the V40 collision note, and the README "refused changes never retry" wording).

Verification on 7f1b9cb5d4 (fenced Maven repo): mvn verify checkstyle:check — 990 tests, 0 failures / 0 errors / 1 skipped, checkstyle clean; HostedPublicWorkspaceIT 3 passed + 1 skipped on a real Node 22 harness; root npm run build && npm run typecheck green. Both design twins describe the twin rule shape now. Awaiting the next review pass.

Real-stack re-verification (round 4) @ 98e1ab90ae

Verdict: no blocker. The migration is V45, unique on main 69d5db2ff2. Main has not moved since the PR's last merge, so the head is the merge result. The round-2/3 items are closed: the transient retry is now bounded and the earlier test gaps (N5/N11/N12) are killed.

Two non-blocking findings with real-stack evidence:

• F2: ENAMETOOLONG is classified retryable, so a lexically valid over-long name holds the creator's Session for 124 s.
• T3: the acquire path's access checks, the ones that keep F1's wedge off the Turn path, are pinned only by the real stack. A candidate test is attached.

Merge-time caveat: open #13260, #13354 and #13265 also claim V45. Whichever merges second must renumber, so re-check uniqueness on the final merge ref.

What holds (head = merge result; macOS host, JDK 21, MySQL 8.4.7, real Spring + embedded Broker + packaged Harness)

¹ D1 (can_read revoked) was read from the operation row (FAILED / workspace_unavailable). The probe polls as the revoked actor and, correctly, gets 404.

F2: a deterministic input error is treated as a momentary fault (minor)

The admission's lexical rule allows 1024 code points per path but sets no per-component length limit. A component of 256 or more ASCII characters therefore passes admission and makes readAttributes throw a plain FileSystemException ("File name too long"). The probe files that under "momentary" and retries it through the budget.

S21 on a real stack, cwd_relative = "a" × 300:

• Probes at t = 0, 1, 2, 4, 8, 17, 32, 65 s; it ends FAILED workspace_unavailable at 124 s.
• Throughout, the creator's later Turn and any other change get 409 session_context_busy, and every deferral logs a full stack trace.
• Afterwards the Session is unchanged and usable.

This is what aMomentaryIoFailureClassifiesRetryable pins on purpose: it uses "a".repeat(256) as the only deterministic way to reach the transient arm. The input is permanent, though, and any creator can reach it through the API. On APFS, an 86-character CJK name (258 bytes) gets NoSuchFileException and is terminal in 1 s. On Linux ext4 (not run here), a component of 256 or more bytes is expected to hit ENAMETOOLONG.

Option: cap each component at 255 UTF-8 bytes in the lexical rule, giving 400 invalid_cwd at admission and writing no operation row. The transient-arm witness would then need an injected IOException instead.

T3: the acquire-side half of the F1 fix has no unit test (test gap)

Mutants R6 (drop isReadable from the acquire path's requireDirectory) and R7 (drop isExecutable) survive all 990 unit tests and the Hosted IT. The reason: refusesAnUnreadableSessionDirectoryBeforeClaimingStorage only uses mode 000, which fails both checks at once. On the real stack (S23, G0 creation straight into the directory):

candidate-acquire-modes.patch (test-only, +29/−22) runs that same test over 000, 111 and 444, releasing the rival claim each time. It passes on head (26/26, checkstyle clean) and kills R6 and R7.

R8 (the acquire path's catch made retryable) also survives. It is nearly unreachable, because the predicates never throw on ENOTDIR. So the comment above refusesAPlainFileDescendantCwdTerminallyBeforeClaimingStorage overstates what it guards when it says folding the anomaly into the transient arm "reddens this test".

Not covered: Linux durable local-process (main's default), and with it the real verified-recovery storage guard on the probe's candidate binding.

Evidence: wenshao/qwen-code@04e8404 → pr13247/r4/ · Earlier rounds: R3 · R2 · R1

Re-verified f583ec3774366f8424feef4f91ed85e594a7b044 against main f765bcf5d398798e54686f1b5437bf010136ee40. My previous migration blocker is fixed: the combined migration set now contains 46 unique versions, including V46__managed_cwd_operation.sql. The previously reported missing-directory/ENOTDIR/ELOOP cases, the typed probe retry budget, and the acquire-path regression also pass the focused checks.

One new blocker — [P1/Critical] Catch host-invalid target paths before they escape into unbounded delivery retries.

In WorkspaceRuntimeResolver.java:177–180, Path.of(root) and base.resolve(cwdRelative) now run before the try. This moved outside the terminal IllegalArgumentException catch when the probe/acquire helpers were split in 7f1b9cb5d4.

On a Windows local-process deployment with workspace files enabled and the Linux-only durable/reboot-recovery options disabled, a creator can submit cwd_relative="bad?name" with the current context revision. The existing lexical normalizer accepts it, but Windows Path.resolve throws InvalidPathException. That exception escapes the resolver and embedded broker unchanged. The coordinator's 8-attempt budget only handles RuntimeBrokerException, so this exception reaches the outer generic retry path instead. The durable operation stays open indefinitely: later Turns and cwd changes remain 409 session_context_busy; lifecycle operations remain blocked by session_operation_active.

Evidence on this exact head:

• The production lexical normalizer preserves bad?name unchanged.
• The official OpenJDK 21 Windows parser rejects it with InvalidPathException. Executing that parser on macOS, with only its package declaration changed, also rejects bad*name and dir/name:foo; child is accepted.
• An independent H2/coordinator probe injecting that exception through the warmer still observes this after 12 attempts, past the new budget:

state=RUNNING delivery=PENDING attempts=12 failure=null
 deliverable=1 revision=1
 later-turn=session_context_busy fresh-cwd=session_context_busy

Please include path construction/resolution in the probe's terminal exception handling, so an invalid host path settles as FAILED/workspace_unavailable and releases the admission barriers. A Windows regression case for bad?name should assert terminal settlement and a successful subsequent Turn admission. This can be fixed locally without changing generic lifecycle retry semantics.

Validation: 84 repository tests passed (0 failures/errors/skips), plus 3 independent probes covering guard I/O classification, candidate validation after deletion of the old cwd, and the retry defect above. The last probe deliberately asserts the defect; its green result is reproduction evidence. Current completed CI checks are green; web-shell E2E Smoke is still running. This was macOS/JDK 21 verification with an independently executed Windows parser and fault injection, not native Windows E2E; Linux native storage identity and a live hosted worker were not exercised locally. The already documented ENAMETOOLONG and acquire-access test suggestions are not new findings here.

中文结论：此前的迁移冲突及已报告的错误分类问题已修复；本轮发现一个新阻塞项——Windows 非法路径可绕过异常捕获和 8 次重试上限，使会话持续被未完成操作锁住。证据由官方路径解析器和精确提交上的故障注入测试组成，未声称运行过 Windows 全栈。

Real-stack re-verification (round 5) @ f583ec3774

Verdict: no new blocker on the real stack; same picture as round 4. The Windows-only P1 posted at 05:06 is not covered by this rig (see the note under the table). Since round 4 the PR has only merged main:

• feat(managed-agent): H3 background Shell and Monitor runtime #13265 (H3 background Shell and Monitor) took V45, so the W2 migration moved to V46. The contract went from 1.31.0 to 1.32.0.
• The W2 resolver, coordinator, service, lexical rule and tests are unchanged; only a migration-number comment in the schema-upgrade test moved.

Main has moved 6 more commits, including #13291 (durable local Runtime tool outcomes). So everything was re-run on head ⊕ main f765bcf5d3: the merge is clean, the uniqueness script passes, and main is still at V45 / contract 1.31.0.

¹ D1 (can_read revoked) was read from the operation row (FAILED / workspace_unavailable).
² The first merge run had 4 errors, all in Issue13180HardenedVerificationTest (from #13210, not W2): its Tomcat connector failed to bind port 59570, so the Spring context never loaded. Three reruns of that class pass on the merge, three pass on main, and a second full run passed.

On the 05:06 P1 (Windows InvalidPathException): the code shape it describes is real on this head. requireDirectoryForProbe builds Path.of(root) and base.resolve(cwdRelative) outside its try (WorkspaceRuntimeResolver.java:178–179), while the acquire-path twin requireDirectory builds them inside a try that catches IllegalArgumentException. So only the settlement probe can let the exception escape to the coordinator's generic retry. On macOS and Linux the only input that makes Path.resolve throw is NUL, and the lexical rule already rejects control characters with 400 invalid_cwd (S2). This rig cannot reach the case, and I did not run Windows, so I have nothing to add beyond confirming the code shape.

Still open from round 4 (non-blocking), unchanged:

• F2: a lexically valid "a" × 300 component still holds the creator's Session busy for 124 s. Probes run at t = 0, 1, 2, 4, 8, 15, 32, 64 s and it ends FAILED workspace_unavailable (S21). Later Turns and other changes get 409 session_context_busy meanwhile.
• T3: the acquire path's isReadable/isExecutable checks are still pinned only by the real stack. The round-4 candidate-acquire-modes.patch still applies cleanly.

Merge-time caveat: open #13260 and #13354 also claim V46. Re-check uniqueness on the final merge ref.

Not testable yet: #13265's child_run/monitor_run domains are still off in production config. Once they are on, a background Shell outlives its Turn, but the W2 barrier only counts active Turns, open operations and requested Actions. That handshake, and the "fresh Runtime Session per Turn" premise the design relies on, deserve a re-check when H3 is enabled. This note comes from reading the code; I have not tested it.

Evidence: wenshao/qwen-code@3b0e111 → pr13247/r5/ · Round 4: issuecomment-6007931423

@qwen-code /triage

Approve. Every Critical filed across all four rounds was re-verified in source at this exact head and is fixed; the current Critical-only scan found nothing blocking.