feat(checkpoints): per-write checkpoints, task-start baseline, and perWriteCheckpoints setting (B1, #1375) - #1404

Persistence Integrity (CodeRabbit pre-merge check): Task.initiateTaskLoop starts the task-start baseline checkpoint and only waits with Promise.race, so a later per-write save could run while the baseline is still staging or committing.

checkpointSave now runs every save through a per-task promise queue, so stageAll + commit never overlap for the same task and a per-write save always waits for a still-running baseline. The queue entry is dropped once it drains so finished tasks do not leak.

Coverage: a concurrency test drives two checkpointSave calls and asserts the second never reaches saveCheckpoint until the first settles; checkpoint suite 29/29, apply_patch + DiffViewProvider + atomicWrite suites 131 passed (+2 POSIX-only skipped); eslint and tsc clean.

…checkpointable

Security Boundaries (pre-merge check + two review threads): every staging file is now created with mode 0o600 before any content is written, and the intended destination mode/ownership is applied afterwards, in both writeFileAtomically and the apply_patch move path.

Persistence Integrity (pre-merge check): handoffPending was only raised when a handler returned true, so a handler that mutated the workspace and then failed (a move whose destination was already replaced before the source unlink failed) produced a retained write with no rollback metadata. Handlers now return { ok, mutated }: mutated is set at the first filesystem mutation, and the partial-state checkpoint uses it.

Review threads: the recoverySuffix condition now names the backup path only when a pre-move destination exists (it previously claimed a preserved original for a no-destination move), and the DiffViewProvider test reads vi.mocked(fs.writeFile).mock.calls instead of a double assertion.

Tests: rollback cases now assert the partial-state checkpoint is recorded (they previously asserted no checkpoint); apply_patch + DiffViewProvider + atomicWrite + checkpoints: 132 passed (+2 POSIX-only skipped); eslint/tsc clean.

… files

…dary

Persistence Integrity (pre-merge check): a handler can commit a workspace write and then reject during later bookkeeping (for example diagnostics/pushToolWriteResult), so the outer catch saw no pending handoff and skipped both the partial-state checkpoint and the queued-message handoff.

execute() now owns a committed-mutation tracker that handlers set at the write boundary (add, delete, update, and the move destination commit). The catch and finally blocks use it, so a mutation that never returned a result is still checkpointed and handed off.

Regression test: an add-file patch whose write succeeds but whose pushToolWriteResult rejects must record the partial-state checkpoint, hand off queued messages, and report through handleError.

apply_patch suite 31/31, affected suites 133 passed (+2 POSIX-only skipped); eslint/tsc clean.

The e2e-mock lane failed in its restart phase: `[restart:verify] [createTaskWithHistoryItem] taskScheduler.schedule failed: TaskMessagesReadError: Failed to read task messages ... at /tmp/roo-vscode-e2e-restart-...` followed by 'Timeout after 30s'. This PR does not change task messages, task history, or the task scheduler (it changes apply_patch, the atomic writer, and checkpoint serialization); the same lane passed on the current main baseline and on sibling PRs. Re-run the lanes.

…doff-count vacuity, make the move recovery write owner-only

Three review rows on fc11d6d measured true and are addressed here:

1. applyPatchTool.execute.spec - unlink is one shared double and mockRejectedValueOnce orders by
   call, not by path, arming the rejection on the FIRST delete while the case comment claimed the
   second. Armed after a resolved call now, and the case asserts both paths were attempted and that
   exactly two unlinks happened - a first-delete failure stops the loop before the second path.
2. Same file - a handoff that never happened used to be the strongest pass: `invocationCallOrder[0] ??
   Infinity` makes any checkpoint order beat an absent handoff. The call count is asserted before the
   order in both cases (a comparison against Infinity cannot fail when the call never happens).
3. ApplyPatchTool.ts recovery write now uses { encoding: "utf8", mode: 0o600, flag: "wx" } to match
   the staging write in the same function: a recovery copy holds private content, and truncating
   whatever already stands at that name would destroy a file instead of preserving it.
4. ClineProvider.spec gained a handler-side round trip for perWriteCheckpoints (updateSettings through
   the message handler, then globalState.update and getState). Every other per-write assertion in
   that file drives contextProxy directly, so a handler that dropped the key left them all green.

Control (pinned node v22.23.4, .tmp-node22): with the parent impl blob 14ad81b on disk - parent
blob verified by git hash-object - a mode/flag assertion on the recovery write fails; with 0827272
it passes. The recovery branch itself still has no test: driving it needs the staging rename, a
failing source unlink and a failing destination removal through doubles that are shared and not reset
between cases, and two attempts to arm that combination through the execute harness did not reach the
branch (logs 1404-recovery-*-node22.log). git grep shows zoo-recovery appears once in the tree - the
write site - so no existing assertion covered it before and none was altered. The behavioural change
therefore lands with the row left answered-and-open pending a test.

Gates: applyPatchTool.execute.spec 31/31 and ClineProvider.spec 322/322 on pinned v22.23.4;
vitest.core.config.ts and vitest.misc.config.ts green (core 4158 passed / 9 skipped, misc 2014 passed
/ 15 skipped) on the same pinned runtime; tsc --noEmit and knip clean on box node v25.9.0; eslint
--prune-suppressions --max-warnings=0 clean on all three touched files with .eslintcache cleared after
the last prettier write; src/eslint-suppressions.json byte-identical to the parent 32555c4; the
new handler test uses no cast because that file sits at its suppressed no-explicit-any budget of 195.
No locale file touched: check-translations compares keys across locales and all 18 settings.json files
already carry perWriteCheckpoints, so the wording clarification is a translator-visible change left
answered-and-open rather than 17 machine-translated strings pushed on a maintainer's behalf.

Co-Authored-By: Claude <[email protected]>

…e the tools

CodeRabbit round against 7f9ebb4 on Zoo-Code-Org#1404:

- checkpointRestore now runs through the same per-task queue the saves use, so a
  queued save can never stage + commit while a restore is resetting the
  workspace, and a restore asked for during a save waits for it (thread 7pkO).
- handleAddFile records the mutation at the write boundary and untracks it only
  when the save left no file behind, so an add whose save rejects after its bytes
  landed still gets the partial-state checkpoint before the queued-message
  handoff (thread 7pkV).
- The move write-catch reports where the destination's bytes survived when the
  restore rename fails as well, and treats the missing destination as a workspace
  mutation (thread 7pkb).
- The perWrite description names write_to_file, edit_file and apply_patch and
  says that saving from the editor records no checkpoint, in all 18 locales
  (thread 7pkh).

Rows: 1 in checkpoint.test.ts, 2 in applyPatchTool.execute.spec.ts, 19 in
CheckpointSettings.spec.tsx; each one fails against 7f9ebb4 on its own.

…heckpoint rows

CI's compile and core-unit arms build the PR merge tree, not the branch head: the job
checks out refs/remotes/pull/1404/merge, and 1404's base is Zoo-Code-Org/Zoo-Code main,
which absorbed 5319fe9 (Zoo-Code-Org#2283) - the commit that turns Task.abort into a get-only
accessor fed by the run-state latches (at main tip e487cd7: Task.ts:3582
'get abort(): boolean', Task.ts:3586 'get abortReason()', no setter anywhere). My head
still carries the plain field at Task.ts:392, so the same rows typecheck clean in my
worktree and fail in that tree:

  core/task/__tests__/Task.spec.ts(7279,9): error TS2540: Cannot assign to 'abort' because it is a read-only property.
  core/task/__tests__/Task.spec.ts(7305,9): error TS2540: Cannot assign to 'abort' because it is a read-only property.
  core/task/__tests__/Task.spec.ts(8387,8): error TS2540: Cannot assign to 'abort' because it is a read-only property.
  core/task/__tests__/Task.spec.ts(8391,9): error TS2540: Cannot assign to 'abort' because it is a read-only property.

Reproduced with git merge-tree --write-tree 8415547 e487cd7 (clean, tree
c77e366), commit-tree d4e3ed011, and a worktree of that commit whose node_modules
junctions map @roo-code/* to that tree's own packages: tsc --noEmit there printed
exactly those four lines and nothing else.

The three rows are this unit's own (the two baseline rows and the queued-message row),
so the adaptation is on my side, in the shape 1405 took at 94dc7c4: ask the class to
raise its own latch instead of writing the field. task.requestAbort(false) is public on
both spellings - it writes the field and drives the run-state event here (Task.ts:3539),
and it drives the kernel that main's getter reads (Task.ts:3594 there). It is also the
smallest exposed entry point that fits: abortTask() disposes the task, and the
queued-message row would then read an empty queue instead of the message the
cancellation is supposed to leave for the resume flow. The assertions are unchanged.

Measured: tsc --noEmit in the merge tree 0 errors (was 4); tsc at this head 0; the core
lane in the merge tree 198 files, 4309 passed | 9 skipped (4318); Task.spec.ts under
vitest.core.config.ts 222 passed in the merge tree and 212 at this head; affected src
set 141 passed | 7 skipped; affected webview set 563 passed; eslint --max-warnings=0
clean on the changed files with suppressions unchanged; prettier --check clean.

…elf-move deleting its own file

The unit is at 295 of the gate's 500 counted executable lines, so these are implemented here rather than
deferred: this reconciliation adds 30 counted lines (src/core/checkpoints/index.ts +27,
src/core/tools/ApplyPatchTool.ts +3), measured with scripts/stryker-diff.mjs's own functions against
48be786 before the commit, for 325 of 500 afterwards. The five new test rows are free budget because the
counter excludes __tests__ paths.

Checkpoint queue (threads 7pkQ on Task.ts and 7p-r on checkpoints/index.ts). The per-task queue serialized
checkpoint work but never expired it: after a baseline whose git add/commit outlives checkpointTimeout, the
caller was released by the Promise.race in initiateTaskLoop while the queued saves still started, however
late, committing whatever the workspace had become by then, and a save queued by a task that had already been
canceled still performed checkpoint work. The queue now gates the start of each save: one past its
checkpoint window, or requested by a canceled task, is dropped instead of started late and resolves to the
caller exactly as a missing service does - with no commit - which is how the task-start baseline already
treats a save that produced no commit, by retrying it on a later loop entry. Restores keep no expiry:
dropping a queued restore would silently discard an explicit user action. Four rows in
src/core/checkpoints/__tests__/checkpoint.test.ts cover the expired drop, the canceled drop, a fresh save
running normally after the stall settles (the drop does not poison the queue) and a restore that is never
dropped; one row in Task.spec.ts covers the case the reviewer asked about - a save that commits after the
task already gave up on it does not retire the baseline.

Self-move (thread 7p-w on ApplyPatchTool.ts). A patch whose Move to resolves onto its own Update File path
is a rewrite of that path, not a relocation: the staged content is renamed onto it and the trailing source
unlink then deletes the file that was just committed. The unlink is skipped when the two resolved paths match.
A row in applyPatchTool.execute.spec.ts asserts the rename happened and no unlink happened.

Nothing else from the review's open rows is implemented here: preserving a symlink destination instead of
replacing it (7pkY), the recovery artifact for a host exit between the two renames (7p-u), and the resolved-
target workspace and protection checks belong to the single guarded writer in unit 2 of the split proposed on
PR 1408 (refs/tmp/s3-1408-u2-guardedwrite), where the compare-and-swap write, its rollback and its lock live.
Implementing symlink semantics twice, once in this move path and once in that writer, would give the workspace
two rollback stories.

…state fixture

 pnpm check-types fails on src in this tree:
   core/webview/__tests__/ClineProvider.spec.ts(3159,9): error TS2322: Type   '{ version: string; clineMessages: never[]; ... }' is not assignable to type   'ExtensionState'. Property 'perWriteCheckpoints' is missing ... but required in   type '{ lockApiConfigAcrossModes?: boolean | undefined; version: string; ... }'
 That is the command .husky/pre-push line 19 runs, and the command the compile context runs (code-qa.yml line 112, run: pnpm check-types).
 Attribution with the parents named: the required declaration is branch-side - e406c09 packages/types/src/vscode-extension-host.ts line 373 declares perWriteCheckpoints: boolean, while that blob at base e487cd7 and at main tip 18861b2 declares it nowhere, and main added zero lines to that path between those tips. The fixture at line 3159 is byte-identical in the base blob, the branch blob and this merge, so the branch carried the defect into the merge rather than main introducing it. CI reads compile success at e406c09; both readings are recorded here instead of one being chosen.
 Fix: the fixture is a fully specified ExtensionState literal, so it carries the field the branch made required; true matches the branch's own documented default when unset. No production line changed and no assertion changed.
 Measured in this worktree (wt-r234-1404, node v22.23.4): eslint over the edited file exits 0 with --max-warnings=0 --no-warn-ignored; src/eslint-suppressions.json is left untouched because the run deliberately omits --prune-suppressions so this unit does not rewrite that file; pnpm run check-types reports 12 successful over 12 tasks.

…tion row this lineage renders

The extension-host visual lane fails on electron-chat-dark-sidebar.png with 5061
differing pixels (ratio 0.03) and reproduced identically in all three attempts of run
42763454719 (check run 129654326411, completed/failure 2026-11-10T05:39:08Z to
05:51:15Z). The published -diff.png holds exactly three pure-red bands - rows 241-258
(2423 px), rows 268-279 (238 px), rows 295-309 (2400 px), totalling 5061 - and the
published -expected.png is byte-equal to the committed blob dfc6fee, so the
recorded picture did not move. Both images carry the same mask fills, 3216 pixels (the
token counters at rows 85-100 plus a 2400 px timestamp box), so nothing is being masked
over: the 2400 px band is the same timestamp box sitting 54 rows lower (rows 241-255 in
the baseline, rows 295-309 in the received image) because a row of See New Changes and
Restore Changes buttons sits between the message text and its timestamp.

Causation, measured rather than inferred. The row does not render on main today. Another
lane of this campaign measured the upstream extension-host-visual leg green at
check run 130448771750, completed/success 09:50:49Z to 10:03:41Z on head
371acb9, a test-only head on main tip 53cb5b5, and
that head carries this same stale blob dfc6fee at this same path, so the stale
baseline matches what main renders. What changes the render is this lineage: 1404 own
patch sets DEFAULT_PER_WRITE_CHECKPOINTS = true in
packages/types/src/global-settings.ts (+13 -0, read from the pull file patch), and the
affordance lives in webview-ui/src/components/chat/SeeNewChangesButtons.tsx, whose
component pre-exists upstream - added by 0084cc8, "Add
completion change actions (Zoo-Code-Org#633)", 2026-06-25, blob 09cac11, byte-identical at the
tip and at 2399 head. So the component is not the trigger and main is not the home: the
regeneration belongs in the pull that changes what the UI renders, because a
row-bearing baseline placed on main would be diffed against a render main does not
produce.

The bytes committed are the CI -actual.png from that artifact (32757 bytes, sha256-64
b8b22a6a126821404f6a422ed4e1ddadbf476bde1a946cd8f5b1801f8d1f2a05), not a locally
rendered screenshot: this lane cannot run the Electron visual lane on Windows. Both
images are 300x743, bit depth 8, colour type 2, so it is the same crop. The other three
committed baselines under apps/vscode-e2e/src/visual/__screenshots__ are untouched,
which matches the artifact: only this scenario produced a -diff.png, in all three
attempts.

The mutation instrument prices nothing for this change and that is its own statement
about a binary fixture, not a claim that the fix is cheap: SOURCE_EXTENSIONS at
scripts/stryker-diff.mjs:84 lists js, jsx, mjs, cjs, ts and tsx, and packageForPath at
:203-215 returns undefined for a path outside that set, so this file maps to no package
and contributes no changed executable lines and no mutants. Git says the same in its own
words: 1 file changed, 0 insertions(+), 0 deletions(-), Bin 28998 -> 32757 bytes.

Merge order, stated because this PNG is a fixture that stacked pulls share: 1404 head
58c889d, main tip 53cb5b5, 1406 head e3dd44c and 2399 head 720b2bf
all still carry the stale blob dfc6fee at this path, so whichever of them lands
after this commit has to take this blobs blob at this path. A conflict created by moving
a shared fixture is a merge-order fact, not a defect.

No changeset file and no CHANGELOG edit, because the repository instructions put both
under maintainer control; the commit touches exactly one path.

Unproved and stated as such: whether the row is intended in the state the scenario mocks,
which is a product question for a maintainer; which upstream change made the appearance
conditional on the per-write default; and whether regenerating turns the lane green,
which only a CI re-queue can say.

The task-start baseline cases in Task.spec stub Task#checkpointSave (the spies at 7181,
7451 and 7476) and assert call counts and flags; the checkpointSave cases in
checkpoint.test.ts stub the checkpoint service itself. Neither layer can show that the
commit a save returns holds the workspace file's bytes: a save that staged the wrong
worktree, recorded nothing, or committed bytes that had since moved on would satisfy
every count and flag assertion above.

Add checkpointSaveShadowGit.spec.ts: three cases that run the real
RepoPerTaskCheckpointService over a real workspace git repo in a temporary directory
and read the contents back out of the shadow git's own commits - the bytes the
task-start baseline records, two successive saves each keeping their own bytes, and a
new file the workspace repo never tracked. checkpoint.test.ts:143-181 is untouched.

…till in flight

A second lookup waits on the initialization it joined, bounded by its own
checkpointTimeout. When that window closed the shared TimeoutError was handled as an
initialization failure: the webview was told the initialization had timed out,
checkpoints were disabled for the whole task, and the initializing flag was released
while the lookup that started the initialization was still awaiting initShadowGit.
The released flag let a later lookup create a second RepoPerTaskCheckpointService
over the same task directory while the first was still committing, and the disabled
flag meant the baseline save that gave up could never be retried on a later loop
entry, even if the initialization it waited on succeeded a moment later.

Track the in-flight initialization in a per-task map that is cleared only when the
operation settles, so a wait that retains the lock until the operation settles or
cancellation is confirmed has something to retain: a caller whose own window expires
now reports no service with a WAIT_TIMEOUT warning and changes nothing else, and a
later lookup joins the same operation instead of racing it into a second shadow git.
With no handle left to join the wait still reports an initialization timeout and
releases the task, exactly as before.
Churn note: git diff --numstat for src/core/checkpoints/index.ts on this commit is 77
added and 34 removed, while git diff -w --numstat on the same commit is 44 added and 1
removed, so about a third of the growth the size instrument charges - extension 321 to 368
against a 500 cap - is the re-indentation the try block and the async closure force,
not new logic. The wait could be extracted into a helper to dodge that re-indentation;
not done here because 368 against 500 leaves the pull under the size cap and re-cutting
to shave indentation churn buys nothing today.

…er than record the write as the pre-task state

saveCheckpoint stages when it executes: stageAll captures whatever the workspace holds at that
instant. The per-task queue orders a task-start baseline against the first per-write save, but
ordering is not content, so a baseline still running when the first write lands committed the
write bytes as the pre-task state, and the per-write save queued behind it then found nothing to
commit. The baseline mislabelled the bytes and the write cost no record of its own; the
pre-write content survived only in the initialization commit, which is not a checkpoint anything
can restore to. Measured on 092a2e9 before this change:

  AssertionError: expected { Object (author, branch, ...) } to be undefined
  + Received: { "commit": "8a1766aad44abf7d6c7c8d34ab65fcb3f262b903", "summary": { "changes": 1,
    "deletions": 1, "insertions": 1 } }
    at src/core/checkpoints/__tests__/checkpointSaveContentPremise.spec.ts:180:20
    expect(baseline).toBeUndefined()

Of the two branches review thread 607pkQ names - preserve pre-write content, or avoid publishing
a baseline - this takes the second: a baseline whose content premise is gone at staging time
resolves with no commit and costs the shadow git nothing, and the write keeps its own record
whose diff base is the content the task started with.

The other branch is worse. Freezing what the baseline stages means capturing the workspace at
request time, which is either a copy of it or a stage-and-write-tree at request time. Both do
their expensive git work outside the very lock whose comment claims it makes late work safe, and
they double the git work a baseline exists to bound. A copy can also catch a file mid-write, so
it records a state that is neither pre-write nor post-write - it does not deliver pre-write
content either - and it leaves the shadow git meaning two different things by what the workspace
looked like. Declining costs the caller nothing it does not already handle: a resolve with no
commit is how a dropped save is reported today, which is how the task-start baseline already
treats it - by retrying on a later loop entry.

A task-start baseline now carries a content premise - no agent write had happened when it was
requested - and saveCheckpoint evaluates it immediately before stageAll, with no await between
the check and the capture, so nothing this task does can slip in after the answer is taken.
Per-write saves carry no premise: recording the workspace as it stands when the save runs is
exactly what a per-write save is for.

The existing assertion in checkpoint.test.ts that pins the baseline call shape now names the
premise it gained, rather than being relaxed to an objectContaining.

The compile job at 58d5fa1 is red, and it is red on me at its first step: the job runs
pnpm format:check (prettier --check .) before lint and check-types, and that step named exactly
the two files the previous commit added or edited:

  [warn] src/core/checkpoints/__tests__/checkpointSaveContentPremise.spec.ts
  [warn] src/services/checkpoints/ShadowCheckpointService.ts
  [warn] Code style issues found in 2 files. Run Prettier with --write to fix.

Run by hand against the pushed head, 15:10:50Z to 15:11:28Z, exit 1. After prettier --write on
those two files the same command exits 0 and prints "All matched files use Prettier code style!"
(15:11 run, saved with the run windows). eslint over the four touched files is still exit 0 with
suppressions unchanged, and the two test files that cover this path pass 43/43 after formatting
(checkpointSaveContentPremise.spec.ts and checkpoint.test.ts), so nothing but whitespace moved.

The premise logic itself is unchanged: a task-start baseline whose content premise is gone at
staging time declines to publish, and the write keeps its own record.

…a real shadow git

The half of review thread 607pkQ that asks for a regression test covering both cases, the second
case: a save queued behind a held save whose checkpoint window expires before its turn arrives must
resolve with no commit, and a later loop entry must retry it rather than leave the task start with
no baseline at all. This is the case the code already got right; it is now pinned so a later change
cannot quietly make an expired save publish, and it is pinned against a real shadow git rather than
a double.

Cherry-picked from 98db7122ae09d471b8513ba9f4ae45590b1d7ced, which was written against
53d221e and held locally until the arms at its successor were read
green. Three deliberate changes on the way over, each measured:
  - the blob stored 215 CRLF pairs against a repo that normalises to LF (core.autocrlf false,
    core.eol lf, and the sibling committed specs in this directory store 0 pairs), so line endings
    were normalised first, 9,253 bytes to 9,038;
  - prettier --write reformatted 70 lines of it, 9,038 bytes to 9,080 and 216 lines to 228, because
    the compile job runs pnpm format:check as its first step and that command flagged this file;
  - the circular return annotation was removed. tsc rejects
    "type Setup = Awaited<ReturnType<typeof setupCheckpointTask>>" annotated "Promise<Setup>" as
    TS2456 plus TS2577, and src check-types reports it for this file and for the premise spec:
      core/checkpoints/__tests__/checkpointSaveInFlight.spec.ts(96,6): error TS2456: Type alias
      Setup circularly references itself.
      core/checkpoints/__tests__/checkpointSaveInFlight.spec.ts(98,53): error TS2577: Return type
      annotation circularly references itself.
    The alias was only ever the function own annotation, so the function now infers its return
    type, which is precise and adds no assertion.

It is a spec, so it charges 0 extension lines under the mutation instrument either way.

Verified at this head: pnpm --dir src run check-types exit 0 (15:31:39.022Z to 15:31:44.275Z);
both checkpoint test dirs together Test Files 7 passed (7), Tests 98 passed (98), Duration 88.64s;
eslint with --prune-suppressions --max-warnings=0 exit 0 with the suppressions file unchanged;
pnpm run format:check exit 0, All matched files use Prettier code style.

(cherry picked from commit 98db7122ae09d471b8513ba9f4ae45590b1d7ced)

…than alias it to itself

The same defect the cherry-pick commit removes from its own file: the premise spec declared
  type Setup = Awaited<ReturnType<typeof setupCheckpointTask>>
and annotated its own setup function "Promise<Setup>", which is circular by construction and tsc
reports at src check-types:
  core/checkpoints/__tests__/checkpointSaveContentPremise.spec.ts(107,6): error TS2456: Type alias
  Setup circularly references itself.
  core/checkpoints/__tests__/checkpointSaveContentPremise.spec.ts(109,53): error TS2577: Return
  type annotation circularly references itself.
That is a compile-leg failure, since check-types is a step of the compile job, and it reached the
pushed head because a turbo run whose first failing leg aborts the rest hid the extension leg:
Tasks: 10 successful, 12 total, Cached: 10 cached, 12 total, Failed:
@roo-code/vscode-webview#check-types counts a task that started and was aborted as neither
successful nor failed, so the missing error lines in that summary were never a passing leg and I
read them as one. Running the leg by itself, pnpm --dir src run check-types, printed them (exit 2
before this change, exit 0 after, 15:31:39.022Z to 15:31:44.275Z). The alias only ever served as
the function own annotation, so the annotation goes away and the return type is inferred.

The behaviour under test is untouched: both checkpoint test dirs pass with this in place,
Test Files 7 passed (7), Tests 98 passed (98), and eslint and format:check are exit 0.

Review thread 7pkY: a destination symlink was renamed to the backup name and replaced by a regular file at the requested path while its own target kept the pre-move bytes, and the .rooignore, write-protection and workspace checks only ever saw the requested spelling. Resolve the destination through its link target before anything is read or renamed, run the same three checks against the resolved target, and move the backup and the staged rename against the target so the link survives, including a dangling link and the failed-source-delete rollback.

Rows added in applyPatchTool.execute.spec.ts for the symlink write, the target-byte rollback and the dangling link. Failing without the fix: 3 failed, 34 passed over the same spec.

…ebased head

main declares toolCallId as a required member of ToolCallbacks in
src/core/tools/BaseTool.ts, and the 24 fixture call sites that carried it
entered this branch through a merged upstream snapshot rather than through a
commit of this branch, so the linear replay dropped them and the standalone
type check reported 24 errors for this path.

The target content is fixed by blob identity: the pre-rebase head blob and the
blob of git-s own conflict-free merge of main with the pre-rebase head are the
same object for this path, and the rebased head differed from it by exactly
those 24 added lines and by nothing else.

…name

writeFileAtomically stages into a sibling file and renames it into place. POSIX
rename(2) only needs write permission on the containing directory, so the rename
replaced a destination the user marked read-only where the direct write this helper
replaced failed with EACCES. Check the resolved destination for writability before a
staging file exists, so a refused write leaves the previous bytes and no leftovers.

The spec case states its own premise: it runs only where access(2) actually refuses
a 0444 file, asserts EACCES on POSIX and EPERM on Windows, and shows the directory
holds nothing but the original file afterwards.

Addresses review comment 4347051548 on pull 1404.

…ption copy

Adds two rows that fail without the content they name, both inside __tests__ paths the
mutation instrument excludes, so the priced changed-line counts do not move.

- packages/types/src/__tests__/global-settings.test.ts asserts the shared default constant
  DEFAULT_PER_WRITE_CHECKPOINTS is true, mirrors the sibling setting rows for the schema
  round trip and key inclusion, and kills the BooleanLiteral mutant on global-settings.ts
  line 122 that the reviewer-facing mutation record names as surviving.
- webview-ui/src/components/settings/__tests__/CheckpointSettings.spec.tsx asserts the
  description copy renders and that the setting registers in the settings search index
  under its translated label, which kills the two StringLiteral mutants on
  CheckpointSettings.tsx lines 42 and 51.

Measured at head 94240dc with the trees own instrument and
its own priced selectors, same population measured twice: types Valid 1 Killed 0 to Killed 1,
webview Valid 8 Killed 5 to Killed 7, blocking rows 4 to 1, Timeout 0 and No coverage 0 in
both legs. The surviving mutant on SettingsView.tsx line 449 is left standing and reported
as an equivalence candidate. src/eslint-suppressions.json is byte-identical after the
pruning pass and 0 suppressions were added.

…oundary

SettingsView.tsx:449 coalesces an unset perWriteCheckpoints with
DEFAULT_PER_WRITE_CHECKPOINTS when building the updateSettings payload, and no
webview test separated that from a bare read: createInitialExtensionState seeds
true, so the pre-existing unset case never delivered undefined to that line. These
cases mount the buffered state and assert both halves: unset sends true, explicit
false sends false. With the source at ?? the suite is green (47 passed); replacing
?? with && (the mutant CI generated at that line) or with a plain read fails the
unset case. Test-only: no product file changed.

The staging entry was opened with the default flag, so a name an interrupted
move left behind was truncated rather than refused. Open it with flag wx, and
on EEXIST re-stamp the staging and backup names - both come from the same
pid-and-clock stamp - and try again, up to three attempts. Any other error
rethrows unchanged.

Two rows in applyPatchTool.execute.spec.ts pin the flag and the re-stamp. The
collision row restores the writeFile default the way the dangling-link row
restores readFile, so a change that stops retrying fails only that row. The
staging-options row in the same file gains the flag it now has to see.

Answers the exclusive-create half of the review row at
src/core/tools/ApplyPatchTool.ts:671; the interrupted-move half stays open and
is named in the thread reply.

…ed file

The destination was written as a plain path, so a symlinked destination took
the content to its target while a chain longer than eight links or a
non-symlink hop was accepted unexamined. Walk the chain, cap it at eight hops,
and write through the resolved target so the destination entry keeps its own
type. One row in applyPatchTool.execute.spec.ts pins the walk.

The row restores the lstat and readlink defaults it consumed, the way the
dangling-link row restores readFile, so the file stays order safe.

Answers the chain-following half of the review row at
src/core/tools/ApplyPatchTool.ts:644; the rename side of that row is answered
in the thread reply, not here.

The premise tests replaced the checkpoint content by identity and only checked
the replacement afterwards, so they proved the callback swapped a string, not
that the save path is handed the premise it writes. The new row supplies its
own premise and asserts synchronously inside the callback that the value
passed to the save path is the premise the test named.

Test-only: no production line changes, and the row is the fourth in the file,
so no stub ordering is involved.

Answers the content-premise review row at src/services/checkpoints/index.ts;
the pin that costs one counted line and two mutants is named there and left
unauthored.

…int in Catalan

The Catalan per-write checkpoint description read "Desarxivar un fitxer des de l'editor no en registra cap.". Desarxivar is unarchive (TERMCAT gives desar for save), so the control described unarchiving rather than an editor save. Takes the wording the review row itself proposed: "Desar un fitxer des de l'editor no en registra cap." Only this locale string changes.

Review row: 4509636283 (pull 1404, thread root 4504115391).

… that save

The ask names the order the existing cases do not cover: not a save queued
behind other work, but a restore requested while a save is still in flight. The
case is added beside the save side cases in
src/core/checkpoints/__tests__/checkpointSaveInFlight.spec.ts and no production
file changes.

It holds a real save inside saveCheckpoint before it reaches the shadow git,
requests a restore behind it, and asserts that the restore reaches nothing until
the save has run and recorded the write bytes, that the workspace is returned to
the restored state afterwards, and that the shadow git's HEAD then names the
restored commit. Against src/core/checkpoints/index.ts with the queue call at
:415 replaced by a direct service.restoreCheckpoint, the case fails at the
mid-flight assertion, so the pass is the queue doing the ordering rather than the
case passing for an unrelated reason.

Review row: 4509635555 (pull 1404, thread root 4504115353)

…, refuse an over-long destination link chain, and report a backup only once it landed

Three asks on this pull that needed executable lines:
- src/core/checkpoints/index.ts: the queue deadline bounded only the start of an operation,
  so a caller queued behind a stalled predecessor waited for it indefinitely. The caller is now
  released by its own window while the predecessor keeps the lock, and the gate still drops the
  released operation when that predecessor settles. Row: checkpoint.test.ts:186.
- src/core/tools/ApplyPatchTool.ts: a destination link chain longer than the 8-hop walk left the
  walk stopped on an entry that is still a link, and the rename would have replaced that link
  with a regular file. The move is now refused with nothing staged and no path moved.
  Row: applyPatchTool.execute.spec.ts:333.
- src/core/tools/ApplyPatchTool.ts: a staging-write failure before the backup rename attempted a
  restore over a backup entry that was never created and reported its location as preserved.
  The restore and the reported location now require the rename to have landed.
  Row: applyPatchTool.execute.spec.ts:680.

…rt late

The start gate asked only whether the clock was past expiresAt, so a reading equal to the deadline
read as not expired, and a caller whose wait had already been released could still start its save
when the predecessor settled in that same millisecond. The release is now recorded before the
caller is let go, and the gate drops a released caller under its own reason, which makes the claim
the surrounding comment already makes - that a released operation never starts late - true at that
millisecond instead of true except at it.

A new row pins the boundary by pinning the clock, so the release and the settle are one reading of
Date.now. The existing release rows settle the predecessor only after the caller was already
released, which is why none of them reached that millisecond; run against the previous code the new
row fails with the released save starting after the release, which is the behaviour being fixed.