U3 - onParameterParseFailure teardown boundary

Part of the upstream PR 1066 split. Own issue: 1936. Content source of record: 72143527fd33306e5541116093c2cbf803cce9e0..pr-1066-audit).

Why this unit exists: BaseTool.onParameterParseFailure() teardown boundary plus the WriteToFileTool override, so a truncated final block still finalizes the open partial ask.

Boundaries

• base: efc22ed9f6f75975106f170cf29cc9bcc0b86682 (org main tip; it is also git merge-base of main tip and head, recomputed in a worktree checked out at the head)
• head: 41f156527c64a06d49a377ebcc7d9b1a5b10e87f (tree 200b3f660a48ee46875a6e031a2903015e1a769d, parent 899e1dfaeb4cd28b69467093449354bf4c9b95b2, 6 commits from that base, none of them a merge of the base). This is the head the pull object reports and the tip my own transport read-back confirmed at 2026-11-12T09:17:52Z.
• head this PR carried until that push: 4ca8b97015090c48d00e7db0d8c8f308cb86443e (tree f3bbfef7be3af560f68bd2dfe57e2a8d3e1eaad6, also 6 commits from that base, one of them the merge of the base itself). The unit content of record is still tagged at e3c10401f, but that tag is not an ancestor of either head (git merge-base --is-ancestor e3c10401f 4ca8b9701509 exits 1 and the same for the current head); what the tag pins is content, and the head is the coordinate to price against. Every figure below that names 4ca8b9701509 is a measurement of the replaced head and is kept as history with that head named, not restated.
• content source: 72143527fd33306e5541116093c2cbf803cce9e0..pr-1066-audit (local)

Fidelity (machine-verified)

zdt split verify --contract U3.json --worktree <wt> --head e3c10401f

Result: PASS - standalone 253 a+d / 3 files (UNDER-SOFT), measured at the tagged head e3c10401f. The head has moved since; see Cleanup added after the tag for what was added on top and how each addition is pinned.

• src/core/tools/BaseTool.ts: OK (content subset of source)
• src/core/tools/WriteToFileTool.ts: OK (content subset of source)
• src/core/tools/__tests__/writeToFileTool.spec.ts: OK (content subset of source)

Design contract

• issue: the split plan

Chain position

Merge order is fixed: U12 (1927) -> U4 -> U5 -> U3 -> U6 -> U7 -> FINAL (1928). This PR is opened against main because the split branches live on the fork; the diff GitHub shows is therefore cumulative through this unit. The unit's own content is the delta from the previous unit head (U5), listed under Fidelity above. The sole merge target of the series is the FINAL integration PR (1928); merging the chain in order keeps every bot-visible diff clean.

Cleanup added after the tag (e3c10401f -> 7c11c26ae)

GitHub's diff for this PR at 662691423 was 9 files, +1863 / -32 (cumulative through the chain, as noted under Chain position); at the head 4ca8b9701509 that this PR carried until 2026-11-12T09:17:52Z, GitHub's diff was 10 files, +3342 / -139, and git diff against the merge base efc22ed9f6f7 in a worktree checked out at that head returned the same 10 files and the same +3342 / -139. The head the PR now carries, 41f156527c64a06d49a377ebcc7d9b1a5b10e87f, reads 12 files, +3899 / -139 on the same command in a worktree checked out at it (my measurement). On top of the tagged head the unit carried 11 commits, 3 files, +457 / -19, all in WriteToFileTool.ts and its two specs:

• rollback-hazard reporting from the failed-partial-stream cleanup, teardown scoped to one task, the failed retry's ask finalized, a completed teardown not reported when the diff revert fails, and the stream state released on execute()'s early returns;
• isPartialStreamStillLive() plus a cancellation check after each of the four provider awaits in handlePartial() (provider.getState(), fileExistsAtPath(), task.ask(), diffViewProvider.open()) - the same fix as 1929 2f356e6f7 and 1928 876a93b22. A TaskAborted during any of those awaits tears the state down, and the delta already in flight used to re-ask, re-open a diff view, or stream a partial delta into a view the teardown had released.
• The same helper checked at the top of handlePartial()'s catch (662691423): a cancellation that lands while open()/update() is in flight runs the TaskAborted teardown and can reject the call in flight, and the catch then marked the already-released state failed, finalized the ask and ran the failed-stream cleanup a second time - a fresh ask row plus a second rollback for a cancelled task. It now logs and returns, leaving the teardown to own the outcome. Same fix as 1928 3a0065091.

Each addition is pinned by its own negative control rather than a re-measured coverage number: removing one liveness guard -> exactly 1 failed (five separate runs); restored -> green.

Verification (this unit, as pushed at 662691423)

• Tests: core/tools 657 passed / 5 skipped (31 files)
• changed-line coverage: 20 covered / 0 uncovered - PASS, measured at the tagged head e3c10401f; not re-measured at 662691423, the additions above are pinned by negative controls instead
• ESLint: clean on every touched file; suppression counts unchanged
• No .changeset file, no CHANGELOG edit.

Recreate policy

If the bot stalls on a pre-merge check and the existing head cannot obtain bot review/approval (empty-commit re-trigger attempted and failed), the unit is recreated from the tagged content source of record - never from a per-PR head. At most 1 PR per issue.

Linked issue

Closes #1936 (unit U3 of the upstream PR 1066 split).

Round update - Lifecycle Resource Cleanup

Shared root cause behind the Lifecycle Resource Cleanup row (all five units of 1066). handlePartial() registers this task's partial-stream entry - and its TaskAborted listener - before it checks the prevent-focus-disruption experiment. With the experiment enabled the delta returns without ever showing a preview and never reaches execute()'s teardown, so the entry and the listener stay attached for the rest of the task's life, and a streamFailed mark armed by an earlier failed delta keeps suppressing this task's later diff previews. The sibling units carry the same release in their own PRs, each verified red-first with a negative control.

This unit (U3): the execute() exits already tear down explicitly (the validation returns, both approval denials, success and the catch each call super.resetPartialState() + resetTaskPartialState(task)), so only the suppressed-preview return in handlePartial() was missing; it now releases too.

Red first: the new test failed with expected 1 to be +0. Green: 49 passed / 5 skipped. Negative control: removing the release turns exactly that one test red; restored green.

Main refresh. Merged org main 036245c5e (U1 1927). U1's content no longer appears in this diff: 9 files +1863/-32 -> 6 files +1416/-27, 0 behind main. Conflicts were confined to src/core/task/__tests__/Task.spec.ts (and Task.ts on U7) - the region U1 rewrote; resolved by taking main's version of the shared save-stage tests (try/finally plus the fixed-task-id ui_messages.json cleanup from cf9206a42) rather than re-implementing U1.

Verification after the merge: Task.spec 172 passed, writeToFileTool.spec 49/5, presentAssistantMessage-custom-tool 20, DiffViewProvider.spec 71, eslint 0/0.

Rows from the 2026-10-09 review

The scope extension needed by the Persistence Integrity row was issued in the split plan before the fix was pushed.

• Persistence Integrity - diff-open is now transactional: the catch awaits revertDiffChangesBeforeReset() before resetting, and DiffViewProvider.revertChanges() (ported verbatim from 1930 7b783452c / 6cae369d9) removes the placeholder and only the directories this operation created, even when open() failed before an editor existed.
• Lifecycle - execute()'s guarded scope starts before the preflight filesystem work and ends with an unconditional finally { resetTaskPartialState(task) } (same shape accepted on 1930).
• Regression Evidence - focused execute() tests seeding the task's stream state first: missing content, successful completion, a failing write, the preflight throw, and the open()-failure rollback.

Fix commit: 41ccb425b. Negative controls: neutering the finally -> exactly the five exits it owns go red; moving the try back -> exactly the preflight test red; removing the revert call -> exactly the open-debris test red.

CodeRabbit rows at head 1b09bab32 (fixed in 2a9bfabfb)

• Major - saveChanges() persists the document and then keeps working (closing the diff
  views, tab bookkeeping, diagnostics), and trackFileContext() / pushToolWriteResult() run
  after it. A failure past that point rolled the tool call back and restored the previous
  content, or unlinked a file the user had just approved being created. saveChanges() now
  signals its commit point at the document save through an optional callback, and the rollback
  stands down from there; the saveDirectly() branch marks the same point when it returns,
  since performing the write is what it does (its signature is untouched).
• Minor - the prevent-focus-disruption rejection exit returned without resetting the
  provider, leaving this call's adopted created directories and editType for the next write's
  open() to fold into its own rollback.
• Minor - the catch called diffViewProvider.reset() directly, so a rejecting reset skipped
  reportRevertFailure(); it now uses the resilient helper the other two teardowns use.

Same invariant as the landed rule in Follow-up 11 (6092123982), delivered in 1921:
the commit point is where a write becomes irreversible, not where the call finished.

Four new tests; each is the only failure when its own guard is removed. 5ff7bea73 is
formatting only: pnpm format:check became a required step of the compile job on main in
667ff58 and runs on the merge commit, and these four files - all inside this unit's own diff

• were already flagged at 1b09bab32. No file outside the diff was reformatted.

Refresh onto main tip efc22ed -- 2026-11-12, run by u9-1917 (every figure in this section is that lane's measurement, taken at the head its refresh produced, 4ca8b9701509, which f0-1528 replaced later the same day)

What the refresh did. A fresh worktree was installed from the lockfile (install exit 0, 36.8 s) so the husky hooks resolve to files that exist: .husky/pre-commit 562 B, .husky/pre-push 1,385 B, the dispatchers _/pre-commit and _/pre-push 39 B each, _/h 551 B. The branch content was replayed onto the main tip efc22ed9f6f75975106f170cf29cc9bcc0b86682 with git rebase --rebase-merges. The rebase is a no-op and printed no conflict: the merge commit fbbf7bc76b87b8a6008a7efff89a3993f8567dc9 already merges that tip (its second parent is efc22ed9f6f7), so the tip is an ancestor of the head and git merge-base main-tip head returns the tip itself. The merge was kept as a merge, not squashed, and git diff between the pre-rebase and post-rebase heads is empty. The head did not move: 4ca8b97015090c48d00e7db0d8c8f308cb86443e. Nothing was pushed for this unit because there was nothing to push; this prose patch is the only publication in this leg.

Gates as re-run at that head, in a worktree checked out at 4ca8b9701509 (the head the refresh produced, not the head the PR carries today; gates at the head now carried are in the last section):

• tsc --noEmit from src: exit 0.
• eslint --max-warnings=0 over the 10 carried files: exit 0. src/eslint-suppressions.json at the head is blob ae3d504003d7e616b129986c252cc97a35b7b568, byte-identical to the copy at main tip; no suppressed count moved.
• prettier --check over the 10 carried files: exit 0, "All matched files use Prettier code style!".
• knip --treat-config-hints-as-errors at the repo root: exit 0, no findings printed.
• vitest --globals from src: writeToFileTool.spec.ts, writeToFileTool-partial-state-cleanup.spec.ts, DiffViewProvider.spec.ts and removeClineFromStack-delegation.spec.ts together -> 4 files, 201 passed / 5 skipped, exit 0. presentAssistantMessage-custom-tool.spec.ts -> 24 passed. parser.spec.ts -> 37 passed. extension.spec.ts -> 24 passed. Those last two run together -> 61 passed. All exit 0.

Price rows, priced with the instrument blob 7dfe0006d2d5c7e4d2282f65f68b8ed5f16866bc (that blob copied out of the priced head, not a working copy, and run inside a worktree checked out at the head, which is the footing its selectFromGit requires):

• Cumulative-through-this-unit shape, at GitHub's footing: base efc22ed9f6f75975106f170cf29cc9bcc0b86682, head 4ca8b97015090c48d00e7db0d8c8f308cb86443e, changedExecutableLines 404 across 6 files, 141 selectors, measured by lane u9-1917. Caps as quoted by the tool itself: "the instrument enforces 500 changed executable lines per package and 400 valid mutants per package".
• The file doing the carrying: src/core/tools/WriteToFileTool.ts, 203 of those 404 lines. The rest: src/integrations/editor/DiffViewProvider.ts 167, src/core/tools/BaseTool.ts 14, src/core/assistant-message/presentAssistantMessage.ts 11, src/utils/fs.ts 8, src/core/webview/ClineProvider.ts 1.
• Unit-only shape, as the Chain position section defines it (the delta from the previous unit head u5-streaming-failure-capture at 2dd4c696bf38): a two-dot count there reads 12 files, +2991 / -1825. Reported as measured, and it is not a clean unit delta: 2dd4c696bf38 is not an ancestor of this head and carries 1825 lines this head does not, so those two branch heads are alternatives rather than a stack, and the instrument cannot price that footing as a unit delta because it selects from a merge base, which resolves to the same efc22ed9f6f7. The two shapes are therefore the same 404-line reading at this footing, because this branch sits on main tip and its diff is cumulative through this unit. A forward cumulative shape -- this unit's rows carried upward under another unit's head -- was not measured in this leg.
• Instrumented mutant count, from the instrument's own preflight line: "Instrumented 6 source file(s) with 384 mutant(s)". 384 mutants over 6 source files, 16 inside the 400 cap. That is an instrumented count only, produced by lane u9-1917 at the replaced head: no killing-stage count is claimed for it. The same instrument blob run by f0-1528 at either head stops at the launcher with spawnSync <worktree>\node_modules\.bin\stryker ENOENT and therefore claims no selector or mutant figure at all. On Stryker 10 with the vitest runner, killing-stage counts come only from a full run and are subject to the runtime-activation defect.
• The local mutation run at this head ended incomplete. Stryker's dry run reported "One or more tests failed in the initial test run: CodeParser parseFile should handle file read errors gracefully / TelemetryService not initialized" and exited with a ConfigError, so the digest records changedLines 404, valid 0, empty blocking, result "Advisory incomplete". The named test is src/services/code-index/processors/__tests__/parser.spec.ts:110; that spec passes standalone at this head (37 tests, exit 0), src/__tests__/extension.spec.ts passes standalone (24 tests, exit 0), and the two run together pass (61 tests, exit 0), so the failure appears only inside the runner's related-test dry run. It was not fixed here. CI's own row for the same head reads mutation-diff completed with conclusion success, started 2026-11-12T03:03:04Z, completed 2026-11-12T03:05:47Z.

Required contexts for the replaced head 4ca8b9701509, read from the repository that carries the runs (Zoo-Code-Org/Zoo-Code) by lane u9-1917. Ruleset 15494382 Protect Main, enforcement active, updated_at 2026-05-23T21:51:54.945Z, strict_required_status_checks_policy false, six required contexts. The check-run door for this head returns 23 rows, every one completed with conclusion success, and all six required names are visible in it:

• check-translations: completed success, started 2026-11-12T03:03:04Z, completed 2026-11-12T03:03:38Z
• platform-unit-test (ubuntu-latest): completed success, started 2026-11-12T03:03:04Z, completed 2026-11-12T03:10:19Z
• platform-unit-test (windows-latest): completed success, started 2026-11-12T03:03:04Z, completed 2026-11-12T03:12:25Z
• compile: completed success, started 2026-11-12T03:03:04Z, completed 2026-11-12T03:06:30Z
• knip: completed success, started 2026-11-12T03:03:04Z, completed 2026-11-12T03:04:15Z
• e2e-mock: completed success, started 2026-11-12T03:03:04Z, completed 2026-11-12T03:08:16Z
  None of the six is in progress, queued, or absent, and the door can see every one of them. The remaining 17 rows are advisory -- they are not in the required list -- and they all read completed success: mutation-diff (03:03:04Z to 03:05:47Z), extension-host-visual (03:03:03Z to 03:15:04Z), webview-visual (03:03:04Z to 03:06:34Z), theme-fixtures, invisible-chars, validate-release, dependency-review, Build test VSIX, Analyze (javascript-typescript), CodeQL, CodeRabbit, codecov/patch, codecov/patch/webview-patch, and two generations each of Zoo Code / reconcile PR review state (1931) and Zoo Code / resolve PRs to reconcile.
  mergeable reads true. mergeable_state read blocked at 2026-11-12T08:46Z and unstable at 2026-11-12T09:07Z, both on this same head. What is not satisfied is the review side, not the checks: the ruleset's pull_request rule asks for one approving review, code-owner review and extra approval for unattributed changes; the requested reviewers are taltas, navedmerchant, edelauna, JamesRobert20; the label reads awaiting-author; and the newest state-bearing reviews are CHANGES_REQUESTED from coderabbitai[bot] at 2026-11-12T03:19:45Z and from edelauna at 2026-10-28T23:35:59Z.

Housekeeping. This patch replaces the em dash, the minus sign and the right-arrow elsewhere in this body with ASCII -, - and -> so the body is ASCII end to end; no figure or claim was changed by that substitution.

Split-unit issue reference

No approved upstream issue exists for this change. This pull request is one unit of a declared split of a larger change, and the split plan, the unit boundaries and this unit's acceptance criteria are recorded on the tracking issue in this repository: #1989. That issue is the home for this unit's review dispositions and follow-up registrations, which is why no approved issue is linked above.

Round 2026-11-12 17:08 +0800 -- linearised onto main tip, then split the two shared specs -- run by f0-1528

Door readings before the push (my own transport reads, git ls-remote --refs, no API core): fork branch tip 4ca8b97015090c48d00e7db0d8c8f308cb86443e; org main tip efc22ed9f6f75975106f170cf29cc9bcc0b86682. The PR head and base read from the anonymous REST door (api.github.com, unauthenticated, x-ratelimit-remaining 30 of 60 at 09:14Z) matched them, so nothing had moved since the refresh leg above and no hunk had drifted since that leg measured it. The same transport read after the push returned 41f156527c64a06d49a377ebcc7d9b1a5b10e87f for the branch at 09:17:52Z, and the anonymous required-contexts read for that head at 09:25:47Z returned 21 rows in which both platform twins are completed success in run 43190229127 (windows job 131087364068, 09:18:03Z to 09:23:41Z; ubuntu job 131087363748, 09:18:01Z to 09:23:50Z) with compile 131087363386, knip 131087363729, check-translations 131087363932, dependency-review 131087363755, invisible-chars 131087363769 and mutation-diff (run 43190228848, job 131087499380, 09:18:18Z to 09:21:04Z) also completed success, and only extension-host-visual (run 43190228863, job 131087362602) in progress and nothing queued.

Linearisation. The branch carried main tip inside a merge commit, so the merge was dropped and the unit's own commits were replayed onto efc22ed9f6f7 by explicit cherry-pick, each exit 0, no conflicts: 1cec8b8109f8 (was 2fa500ae46), 9895779dce52 (was 7699e362cb), 90b18494a739 (was e8940caf77), 193e99ae623b (was 91413d8915), 899e1dfaeb4cd28b69467093449354bf4c9b95b2 (was 4ca8b9701509). That chain tip carries tree f3bbfef7be3af560f68bd2dfe57e2a8d3e1eaad6, the same tree as the head it replaces, and git diff 4ca8b9701509 899e1dfaeb4c printed nothing. The first attempt, git rebase --onto efc22ed9f6f7 73931fe8be HEAD, replayed 20 commits and halted with content conflicts in src/core/task/Task.ts and src/core/task/__tests__/ask-queued-message-drain.spec.ts because the upstream argument is an ancestor of main tip, so main's own commits entered the replay range; it was aborted in favour of the cherry-picks. Of the fifteen commits between the pre-merge base and main tip, none touches any of the ten paths this unit carries, so there was no drifted hunk to repair and none was flattened.

The split. Five describes that this unit created went from src/core/tools/__tests__/writeToFileTool.spec.ts (1531 lines to 1041) into a new src/core/tools/__tests__/writeToFileTool-stream-state.spec.ts (807 lines, 25 it), covering path stabilization predicate, resetPartialState, per-task stream state isolation, early-return stream state cleanup and partial-stream failure teardown and directory ownership. Two blocks of created tests went from src/integrations/editor/__tests__/DiffViewProvider.spec.ts (2858 lines to 1941) into a new src/integrations/editor/__tests__/DiffViewProvider-rollback-teardown.spec.ts (1157 lines, 26 it), both children of describe("userTouchedDocument close/keep behavior") as they were before. Each new file re-opens the describe its tests were children of and copies the module mocks and describe-level doubles it needs, so no full test name changed and nothing is excluded. Vitest's own counter returns 173 tests for the two pre-split files and 173 for the four post-split files; the six run together return 346. writeToFileTool.spec.ts keeps 44 it and DiffViewProvider.spec.ts keeps 77, which are the counts main carries plus this unit's edits to main's own tests; the unit created 45 and 32 respectively, and all of that weight is now in the two new files.

What the moved text had to give up. The copies are copies, not rewrites, except: the prelude's const mockCline: any = {} becomes a structural ClineDouble interface (the shared spec's five any sit under no-explicit-any count 5 in src/eslint-suppressions.json and a new file cannot inherit a suppression), so the cline reaches handle, execute, clearTaskState and one state object through nine as unknown as Task assertions, the repo's documented last resort -- the tenth such assertion in the new DiffViewProvider file belongs to main's own makeTaskDouble; this and task in the copied pushToolWriteResult mock and the two nativeArgs casts in the stream-state helper are typed rather than any; one test constant and one fs/promises import became unused when the tests moved and were pruned; and revertChanges() reports a close the editor refused instead of deleting underneath it now calls vi.mocked(vscode.workspace.applyEdit).mockResolvedValue(true) itself, because in the shared spec it inherited that default from an earlier test and without it the run reported the restore wrapper message instead of the close it means to assert. No suppression was added or removed, no Stryker directive appears, and the non-ASCII character count of all four files is 0.

Gates at the landing head (my measurements, in a worktree installed from the lockfile so the husky hooks resolve to files that exist): pnpm run check-types exit 0, 12 of 12 tasks. eslint --max-warnings=0 --no-warn-ignored over the four spec files exit 0, and exit 0 again with --prune-suppressions; that run rewrote src/eslint-suppressions.json cosmetically (1326 added / 1326 removed with no count moved) and was reverted, so the file is byte-unchanged, and the entry for core/tools/__tests__/writeToFileTool.spec.ts read no-explicit-any count 5 before and after it. prettier --check over the four files: "All matched files use Prettier code style!". Vitest over the four files: 168 passed / 5 skipped, exit 0. test:core: 200 files, 4324 passed / 9 skipped, exit 0, 25.52 s. test:misc: 120 files (119 passed, 1 file skipped), 2134 passed / 13 skipped, exit 0, 14.67 s.

Price rows, instrument blob 7dfe0006d2d5c7e4d2282f65f68b8ed5f16866bc copied out of the priced head and run inside the checked-out head, its selectFromGit footing. Caps as the tool states them: 500 changed executable lines per package, 400 valid mutants per package.

• landing head 41f156527c64a06d49a377ebcc7d9b1a5b10e87f against base efc22ed9f6f7...: prints "Mutation-testing 1 package(s) from merge base efc22ed: extension (404 lines)" and the row | extension | 404 | 0 | 0 | 0 | 0 | 0 | Advisory incomplete | with blocking:0 advisories:1, node exit 0. Under the 500-line cap. The mutant columns are the zeros of a run that could not start, not a measured zero: extension Stryker preflight could not start: spawnSync <worktree>\node_modules\.bin\stryker ENOENT. node_modules/.bin here does contain stryker, stryker.CMD and stryker.ps1; it is the extensionless shim that spawnSync cannot exec on this Windows footing. No mutant count is claimed for this head by that ci-mode row, and the 384-mutant figure in the refresh section above is lane u9-1917's measurement at the head this PR replaced. Two rows added under this section carry the same instrument blob through a second mode at both heads, so the zeros in the ci-mode row read as a run that did not reach the launcher and not as a measurement of nothing.
• control at the replaced head 4ca8b9701509 (tree f3bbfef7be3a), same base, same footing: the same line and the same row, 404, blocking:0 advisories:1, same advisory, node exit 0. The two heads carry identical source files, and specs are not executable lines, so the split moved no priced content; that equivalence is stated here as two measurements, not as an inference.
• second mode at the head this PR carries, 41f156527c64a06d49a377ebcc7d9b1a5b10e87f (tree 200b3f660a48ee46875a6e031a2903015e1a769d), against the same base efc22ed9f6f75975106f170cf29cc9bcc0b86682 -- my measurement, added 2026-11-12T10:2xZ. Same instrument blob 7dfe0006d2d5c7e4d2282f65f68b8ed5f16866bc, taken from the checked-out tree, and its selectFromGit run in a worktree checked out at that head, which is the footing it requires; the selector list it returns is handed to Stryker 10 with the vitest runner as mutate under --dryRunOnly, the child stopped when the instrumenter line prints. It prints 141 selectors over 6 changed source files and Instrumented 6 source file(s) with 384 mutant(s). The ci-mode row above dies at the extensionless shim that spawnSync cannot exec on this Windows footing; this mode reaches the same preflight by spawning the store's @stryker-mutator/core 10.0.0 bin/stryker.js directly. Two shapes of one instrument at one coordinate, both recorded.
• second mode at the head this PR replaced, 4ca8b97015090c48d00e7db0d8c8f308cb86443e (tree f3bbfef7be3af560f68bd2dfe57e2a8d3e1eaad6), same base, same harness, same instrument blob: 141 selectors over 6 changed source files and the same Instrumented 6 source file(s) with 384 mutant(s). So the 141-selector and 384-mutant figures quoted in the refresh section reproduce at both coordinates in my hands and not only at the replaced one, which is the equality the pair of 404-line rows above was pointing at with its selector and instrumented-mutant stage filled in.
• what those two rows count and what they do not. 141 is the instrument's own selector count. 384 is an instrumented count taken from the preflight line: it is not a killed count and not a surviving count, neither mode reaches the killing stage on this footing, and no verdict is claimed from either. The caps stay stated apart from every result rather than folded into one: the instrument enforces 500 changed executable lines per package and 400 valid mutants per package, so 404 lines sits 96 inside the line cap and 384 instrumented mutants sit 16 inside the mutant cap.
• delta footing base 4ca8b9701509 head 41f156527c: the tool resolves the merge base to efc22ed9f6f7 and prints the same cumulative 404-line row rather than a zero row, because the replaced head and the landing head are alternatives that meet at main tip rather than a linear pair.
• shapes apart. Unit shape at the landing head, git diff --shortstat efc22ed9f6f7..41f156527c: 12 files, +3899 / -139. At the replaced head the same command reads 10 files, +3342 / -139. Carrying set at both heads (my git diff --numstat against main tip, non-spec): src/core/tools/WriteToFileTool.ts 532+/81-, src/integrations/editor/DiffViewProvider.ts 331+/26-, src/core/tools/BaseTool.ts 40+/3-, src/core/assistant-message/presentAssistantMessage.ts 20+/1-, src/utils/fs.ts 13+/3-, src/core/webview/ClineProvider.ts 6+/0-. The instrument reports package-level totals only at this footing, so the per-file executable-line split quoted above (203 of 404 in WriteToFileTool.ts) is that lane's reading, not a re-measurement here.

Hooks as they ran. Cherry-pick does not invoke .husky/pre-commit, so the replayed commits ran none. The split commit ran it: lint-staged backed up the working tree into git stash (2c1f92f37a, kept, not dropped), ran the staged-file tasks over the 4 staged files (src/**/*.ts and the json/css/md glob) and then the hook's repo-wide pnpm lint step printed nothing; commit exit 0. The message was amended once, for four wrong line counts and a wrong assertion count; that amend re-ran the hook and lint-staged reported "could not find any staged files", which is why the amended run shows no staged work. .husky/pre-push (pnpm run check-types) runs on this push, and its output is reported from the push log rather than inferred.

Re-measurement at the landing head 41f156527c64 - 2026-11-12T10:00Z-10:12Z, run by u9-1917

Why this section exists. The branch tip moved from 4ca8b9701509 to 41f156527c64 after this lane priced the unit at the old head, and the move took 917 lines out of src/integrations/editor/__tests__/DiffViewProvider.spec.ts into a new DiffViewProvider-rollback-teardown.spec.ts and 490 lines out of writeToFileTool.spec.ts into a new writeToFileTool-stream-state.spec.ts. Those are the files the surviving mutation rows of the sibling unit live in, so lead's instruction was that nothing priced here may be called current until it is measured at the tip. This section is that measurement. It costs 1 token core, the PATCH that carries it: every git read, both price runs, the sweep and the smoke run below cost nothing, the price drivers load the instrument blob rather than a working copy, and the pull and check-run reads went through the anonymous door on a public repository.

The price, re-run from a worktree checked out at the tip. git worktree add --detach at 41f156527c64, git status --short empty, the instrument at that head is blob 7dfe0006d2d5c7e4d2282f65f68b8ed5f16866bc, 30,108 B, the same blob this lane priced with at 4ca8b9701509. Run through its own selectFromGit with base efc22ed9f6f75975106f170cf29cc9bcc0b86682, which is also the merge base it resolves to: 1 package extension, 404 changed executable lines, not over the 500-line cap, 6 files, src/core/tools/WriteToFileTool.ts 203, src/integrations/editor/DiffViewProvider.ts 167, src/core/tools/BaseTool.ts 14, src/core/assistant-message/presentAssistantMessage.ts 11, src/utils/fs.ts 8, src/core/webview/ClineProvider.ts 1, and src/eslint-suppressions.json at this head is blob ae3d504003d7e616b129986c252cc97a35b7b568, the same object this lane holds at the upstream main tip, the fork main, U4, U5a, U5b and 5bc7709dfe51. The 404-over-6 row is therefore now printed three times by two lanes on two heads. The advisory figures are two different counts and both are stated rather than reconciled: this driver prints what the selection pass returned, which is 0 selection advisories, and the unit's own lane quotes advisories:1 from the gate summary line, which counts advisories raised over the mutants. One is not a correction of the other.

Why the number cannot move on this content, read rather than inferred. git diff --numstat 4ca8b9701509 41f156527c64 lists four paths and all four are spec files, and the provider this unit carries, blob e2ee190cf82b88712bfa5b2bef52090070a9e75d, 60,856 B, is the same object at both heads. The rewrite moved tests and commit topology, not source lines. So the re-measurement agrees with the row it replaces, and it is stated as a re-measurement because agreement is a result and not an inheritance.

What the 22 rows that survived a hand-applied substitution at 5bc7709dfe51 reach at this head. Each row was located by the five lines around it in 5bc7709dfe51's provider file rather than by its short replacement text, because three of those rows sit at positions that carry two mutants with the same mutator and status and text-only matching hands one row another row's payload. That gives three classes:

• 5 rows carry a determinate site here: ids 3, 5 and 8, the three guard mutations on typeof error === "object" && error !== null, which sit at line 24 at 5bc7709dfe51 and at line 24 here; id 130, the tab-selection mutation, whose five-line context is present at line 1035; and id 158, { cause: closeError }, at line 1231 there and line 1076 here.
• 17 rows have no context here at all: the two NoCoverage rows 60 (698:78) and 172 (1254:61), the guard rows 46 and 95 (653:7, 792:7), the teardown rows 51 and 52 (684:5, 685:5), the restore-text rows 55, 171, 172 and 186 (698:7, 1254:37, 1254:61, 1556:23), the tab rows 133, 138, 160, 162, 163, 174, 176 and 177 (1195:6, 1196:6, 1247:18 x3, 1270:18 x3). Those lines are not in this head's provider file: the file here has 1532 lines and the file at 5bc7709dfe51 has 1669, different blobs, and the content those rows mutate belongs to the sibling unit's diff. They are recorded as absent at this footing, which is not the same as equivalent and not the same as killed.
• 1 row is carried but not mutable: id 130's context is present, yet the multi-line span recorded at 5bc7709dfe51 occurs 0 times in this file, so nothing was substituted there and no claim is made about it.

The sweep at those sites, and what it printed. The 4 mutable sites were each written into the provider at that head, run, and restored. The run set is the 23 spec files this head carries that reach this neighbourhood: all 19 of the spec files chosen by that rule at 5bc7709dfe51 still exist here, and 4 more are new or rewritten here - DiffViewProvider-rollback-teardown.spec.ts (1157 lines), writeToFileTool-stream-state.spec.ts (807), writeToFileTool-partial-state-cleanup.spec.ts (200) and the rewritten writeToFileTool.spec.ts (1041), against 476 lines of the same file at 5bc7709dfe51. Baseline with the provider untouched: exit 0, 23 files passed, 1011 passed and 5 skipped of 1016, in 26 s, no failing file and no selection abort. All four substituted runs exited 0 with no failing test file, and the provider came back to sha256 1978b8c770d2d37316fd6d6b8a23c31fef2859fcc9e5a61ca91d97a35f3ed1ec, the digest it had before them, after each of the four. So the question the move raised has a negative answer at the head that carries the new content: none of these rows is turned red by the tests that move introduced.

The row a reader would expect the new content to catch, and why it does not. Id 158 is { cause: closeError }, the cause attached when a dirty vscode.diff tab refuses to close, ObjectLiteral, 1 covering selector in the killing stage at 5bc7709dfe51. Written as {} it stayed green here. The new rollback-teardown spec does assert on cause, three times, and all three sit on revertChanges() paths that keep a workspace rejection as the cause of a failed restore or of a failed existing-file revert. None of them reads the cause attached to a failed tab close. That is the evidence for calling the row untested rather than equivalent, and it is the kind of near miss the next test for this unit should close.

Why the new content cannot be judged from the other side either. The two brand-new spec files were copied into a worktree checked out at 5bc7709dfe51 and run there against that head's untouched provider: exit 1, Test Files 2 failed (2), Tests 41 failed and 10 passed of 51, in 1.23 s, with 22 distinct assertion failures including diffViewProvider.adoptCreatedDirs is not a function. The content is written against the provider API this unit adds, so it cannot evaluate a sibling unit's provider file, and the files were removed again rather than left in that worktree, whose git status --short reads only the untracked reports/ tree.

The footing that would let the two contents meet, read from git rather than asserted. git merge-tree --write-tree --name-only for 5bc7709dfe51 and 41f156527c64 exits 1 in both orders and names the same two conflicted paths - src/integrations/editor/DiffViewProvider.ts and src/integrations/editor/__tests__/DiffViewProvider.spec.ts - producing tree efc45ab8c15c7b0fae978498acbda14b3f845b5d with U6a first and tree beed1a6650fb59c178a50e2eac3080441758c45b with this unit first. Both sides edit the same provider lines and the same spec, so the merged footing has no price, no killing stage and no row verdict until somebody decides how those hunks resolve. That is a content decision about the merge, and this lane did not make it: no commit was created, no branch was written, nothing was pushed.

State at the tip, from the door that carries it, taken before this body write. GET /repos/Zoo-Code-Org/Zoo-Code/commits/41f156527c64.../check-runs at 10:05:56Z returned 23 runs, every one completed, every one success, mutation-diff among them, and the six contexts ruleset 15494382 requires are among those names. The pull reads head 41f156527c64, base efc22ed9f6f7, mergeable true, mergeable_state unstable, updated_at 09:42:59Z. So this PATCH cancelled nothing that was still running.

What this section does not claim. No killing stage was run at this head: the runs above are Vitest over 23 named spec files, which is not Stryker's related-test selection, so the incomplete dry run recorded above is neither retracted nor confirmed by it. The 17 absent rows are reported as absent at this footing and not as equivalent, killed or settled. Id 130 was not mutated because its recorded span is not verbatim in the carried context. The sweep mutates one site at a time against a green baseline and restores byte-identically, and no row was answered by cutting across another unit's content, per the standing ruling that ownership of a row follows the unit that adds the line. This lane did not re-cut any body for merge ordering, and the ordering disagreement between this body's Chain position section and the sibling unit's body is still filed as a human-visible item on #1989 (comment 6819809725) rather than resolved here.