U9 re cut, rung 1 of 4: safe write primitives (379 counted lines, 123 selector ranges, headroom 121) - #2443

Merge Risk: Low · up to bae31

This adds safe file-write primitives that nothing in production calls yet. A few edge-case gaps remain: cleanup can delete another writer's staged file, a crash during the EPERM fallback may not recover cleanly, and an unreadable target mode can widen permissions. They are narrow and fixable before or shortly after merge.

Failed checks: 1 error · 2 warnings

Check name	Status	Explanation	Resolution
Persistence Integrity		The changed locked write path in src/utils/safeWriteJson.ts has a partial-failure recovery gap. The PR introduces it, and the current head still contains it. Causality: - Base (`refs/coderabbit/pre-…	1. In src/utils/safeWriteJson.ts (lines 236-242), compute the recovery key under the lock with resolveLockKey(absoluteFilePath) and pass that key to recoverInterruptedReplacement. For a dangling link, the key is the referent, so the s…
Description check		The description does not follow the repository template. It lacks the required 'Related GitHub Issue' section with a 'Closes: #' link (it cites planned issue #1991 and pull 1917, which is not the temp…	Add a 'Related GitHub Issue' section with a 'Closes: #' line that links an approved issue. Add a 'Description' section that explains how safeWriteText and the safeWriteJson changes work, with key design choices and points for carefu…
Regression Evidence		The PR adds changed error and negative branches in src/utils/safeWriteJson.ts with no focused test. The standing prior FAIL still holds at the current head. 1. _copyTargetMode chmod refusal (safeWrite…	Add focused unit-layer tests in src/utils/tests/safeWriteJson.test.ts or a safeWriteJson.*.spec.ts file: 1. Target mode 0o600. Make fs.chmod on the staged file reject, and make the staged mode differ from the target. Assert that safeWri…

Passed checks: 5 passed

Check name	Status	Explanation
Title check		The title names the rung and the main change, safe write primitives, which matches the added safeWriteText.ts module and the updated safeWriteJson.ts. It is long and includes counting metrics (379 lin…
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.
Security Boundaries		The check fails only for a changed path that leaks secrets or PII, trusts or executes unvalidated input, or bypasses approval or allowlist controls. I found no such path in the PR's changed files. - C…
Lifecycle Resource Cleanup		Summary: No changed lifecycle path leaks a listener, watcher, provider, timer, task, or handle, and none duplicates work after cancellation, disposal, or restart. The check passes. **Evidence revi…

Full details: Title check

Explanation

The title names the rung and the main change, safe write primitives, which matches the added safeWriteText.ts module and the updated safeWriteJson.ts. It is long and includes counting metrics (379 lines, 123 selector ranges, headroom 121) that add noise and do not help a reviewer scanning history. The title also uses the internal term 'U9 re cut' without context.

Full details: Security Boundaries

Explanation

The check fails only for a changed path that leaks secrets or PII, trusts or executes unvalidated input, or bypasses approval or allowlist controls. I found no such path in the PR's changed files. - Command execution: src/services/file-safety/safeWriteText.ts calls execFile("icacls", [...args]) at lines ~167-191. It passes an argument array with no shell. The arguments are internal paths (the target, and a dump path created by the module), so no shell injection path exists. - Caller-supplied staging path (tempPath, lines 339-389): the code validates the path before use. It must sit in the target's directory (path.dirname check). It must be a regular file, not a symlink (lstat). It must not be the target by device/inode identity. Any comparison failure other than ENOENT rejects the write. This is validation of untrusted input, not a bypass. - New confineTo option in src/utils/safeWriteJson.ts (lines ~160-267): this adds a confinement control. It checks the canonical target and lock key against the canonical scope before filesystem side effects, and again under the lock. It does not weaken any existing control. - No secrets, tokens, or PII are logged or written by the changed code. Error logs name only paths and error objects. Residual concerns from the review threads are not security-boundary failures under this check. The _copyTargetMode fallthrough on non-ENOENT stat errors can publish a staged file with a umask-derived mode. The recovery lookup and the same-target race (StagingReplacedError after commit) are data-integrity and correctness issues. Those are for code review, not this criterion. The mode case needs a stat error on an existing target and is not an attacker-triggerable approval or allowlist bypass. Evidence came from the diff inventory (8 files), the safeWriteText.ts and safeWriteJson.ts source at the cited ranges, and a search for execFile, spawn, exec, process.env, and confineTo.

Full details: Lifecycle Resource Cleanup

Explanation

Summary: No changed lifecycle path leaks a listener, watcher, provider, timer, task, or handle, and none duplicates work after cancellation, disposal, or restart. The check passes. Evidence reviewed (PR range refs/coderabbit/pre-merge-check/base..head, 8 files): - File handles in safeWriteText.ts: Both branches open a descriptor with openSync and close it in finally (lines 430–445 and 460–468). The backup seed and fsync descriptors close in finally (lines 562–573). The parent-directory descriptor closes in finally (lines 614–618). _stagingDir runs before the outer try, but it only creates the directory and throws nothing that would skip cleanup. - Staged and backup residue in safeWriteText.ts: Pre-commit failures unlink tempPath, rmdir the self-created staging directory, unlink the DACL dump, and remove the backup (lines 678–710). A partial backup is unlinked on copy failure (lines 574–579). Successful writes unlink the backup (lines 655–661). - Retained backup after commit: On post-commit failures, safeWriteText.ts keeps the backup on purpose (lines 679–685). PostCommitDurabilityError exposes backupPath. StagingReplacedError does not, so a race-triggered post-commit replacement leaves a hidden copy the caller cannot find. This is a recovery and discoverability issue. It is a retained copy written by design, not a handle, listener, timer, or task leak, so it does not meet this check's failure condition. - Lock lifecycle in safeWriteJson.ts: resolveLockKey and the confinement checks run before acquireFileLock (lines 197–217). If acquisition fails, no lock is held. releaseLock runs in the finally block (lines 399–409). Recovery, target resolution, merge, staging, and commit all run inside the locked try (lines 223–398). - Staged file cleanup in safeWriteJson.ts: The _copyTargetMode stat-failure path returns without leaking anything. A chmod mismatch throws inside the locked try, and the catch unlinks the staged file (lines 300, 380–394, 447–479). - Flush helpers: _flushFileToDisk closes its handle in finally (lines 516–527). _flushDirectoryToDisk closes its descriptor in finally (lines 489–508). - DACL helpers: _saveDaclWindows and _restoreDaclWindows return booleans and never throw, so no partial dump escapes the cleanup path (lines 164–199). - Pre-existing stream code: _streamDataToFile is unchanged from the base revision, so its error-path stream handling is outside this PR's changes. - Timers and async work: The changed code adds no timers, watchers, or listeners. The warn sink is not awaited, so warning delivery cannot delay or repeat a write. Conclusion: I found no changed lifecycle path that meets the failure condition.

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

Review status

Thanks for contributing. This comment tracks the review sequence and the next action.

Current step: Address automated review findings and push fixes.

After fixes are pushed and required CI passes, automated review restarts.

Review-state labels are managed by this workflow; do not edit them manually. community-approved is managed the same way — do not add or remove it manually. It signals a fresh community code approval for the current head as an advisory priority only; maintainer review is still required.

Codecov Report

❌ Patch coverage is 88.88889% with 33 lines in your changes missing coverage. Please review.

📢 Thoughts on this report? Let us know!

Changed-code mutation testing

Report for PR head bae313db57fd.

pnpm install --frozen-lockfile
node scripts/stryker-diff.mjs ci --base d76dffa860939f79ce4657bee56364ed272d3523 --head 98604e4103f1d346c14f005e7dcb23e965f92dd6

knip at this head: which pass fails, and one question for the maintainers.

Measured, with the door each fact came from.

1. The failing step is the production pass. In check run 131666359369 (knip), the step 'Verify Knip guardrails' and the step 'Run knip checks' both completed success; the step 'Run production Knip checks' completed failure, 03:23:53Z to 03:24:00Z. Source: GET actions/runs/43358563290/jobs. The commands behind those step names, from .github/workflows/code-qa.yml at this head, are line 94 'pnpm knip' and line 96 'pnpm knip:production'.
2. The annotations carry no cause for it. This check run returns 2 annotations, both at path .github: line 15 level failure 'Process completed with exit code 1.' and line 1 level notice about the ubuntu-latest migration. Source: GET check-runs/131666359369/annotations. No knip report line appears in them, and the door that would carry the tool's own output - GET actions/runs/43358563290/jobs/131666359369/logs - answers 'Not Found' with documentation_url at the REST root for this session's identity, so this comment quotes no knip line.
3. The next rung shows the same property in a form the compiler does state. At 5dd5882 the compile check run 131665371730 annotates src/utils/jsonFileRecovery.ts line 8 column 32: Cannot find module '../services/file-safety/safeWriteText' or its corresponding type declarations. That module is present in this head's tree and absent from main at merge base f98fcf7, from which all four units were cut. Source: GET check-runs/131665371730/annotations, plus local git queries at the three commits.
4. Locally, at this head e77527f: of 536 non-test TypeScript files under src, 11 import the two write modules; 10 import safeWriteJson and the eleventh is safeWriteJson.ts itself, which imports only resolveLockKey and resolvePublishTarget from src/services/file-safety/safeWriteText. The exported function safeWriteText, and the exported error classes StagingPathError, PostCommitDurabilityError and ConfinedPathEscapeError, are named outside their own file only by test files. Their production consumers arrive with later rungs.
5. A unit that lands a primitive before the units carrying its consumers has this property by construction and not by defect: a unit branch carries only its own delta, so a production-only reachability pass sees the primitive as unreachable, and a later rung that imports it cannot compile until the earlier rung is in main. That is why the declared landing order for the four units is 2443 -> 1917 -> 2444 -> 2445, and why no unit waits on a circle.
6. Pricing, in the instrument's own words at merge base f98fcf7: 'Mutation-testing 1 package(s) from merge base f98fcf7: extension (379 lines)' at this head, 416 lines at 5dd5882, 492 lines at 3361738, 463 lines at d41618a - every one inside the 500 changed-executable-line ceiling in scripts/stryker-diff.mjs lines 11 and 12. The mutant figure I can quote is my own local preflight at this head: 360 generated mutants against the 400 ceiling. CI's own generated figure is unread from this session for the door reason in item 2, so that number is mine and is labelled as mine.

One question for the maintainers, which the stack cannot answer from inside itself: would you rather (a) land this primitive unit together with the units that consume it so no pass sees it unreachable, (b) see a stated ignore entry for it in knip.json - the configuration this pass reads - as a reviewed part of this PR, or (c) land the four units as a group in the declared order and treat the intermediate reds as expected. This session will not change knip.json on its own.

Owner gate on this unit, and what is left for a human to do.

1. github/CODEOWNERS - spelled .github/CODEOWNERS - is two lines and one rule. Line 1: # These owners will be the default owners for everything in the repo. Line 2: * @taltas @JamesRobert20 @navedmerchant @edelauna. That file is byte-identical in the trees of all four units.

2. Line 2 is a catch-all basename pattern, so every path all four units change carries those same four handles and no narrower owner exists anywhere in the file. Any one of the four handles approving satisfies the code-owner gate for any one of the four units.

3. This session acts as easonLiangWorldedtech, which is not one of the four, so no act of this session can satisfy that gate, however many comments or pushes it makes.

4. The branch ruleset discards an existing approval when a push arrives, so an approval is worth collecting only after this unit's content is final. This session will not push it further unbidden.

5. The one required check red here is the step named in the comment I posted on this pull today. What remains on this pull is one approving review from one of those four handles plus an answer to that question, and nothing else.

Knip, run locally on this box at this head e77527fb65c7bb21609c0f0740c8d07b740c0f88 and at the trunk tip 5f42a918b9458b0383b7a3a0c86b901a5b311664 in one scratch worktree, in the order code-qa.yml runs them. Footing, stated because it is not the CI footing: package.json, knip.json and pnpm-lock.yaml are byte-identical at the two footings and node_modules is junctioned from a shared install rather than installed per tree, and pnpm here is a .CMD shim this sandbox cannot spawn, so the same programs were run with the same arguments: node --test scripts/knip-policy.test.mjs, knip --treat-config-hints-as-errors, knip --production --treat-config-hints-as-errors.
Step 1, Verify Knip guardrails, code-qa.yml line 92: exit 1 at this head, exit 1 at the trunk tip. Both print pass 7 and fail 1, the failing test being visual entries cannot hide helpers unused by the production application at scripts/knip-policy.test.mjs:188, asserting 1 !== 0 against {"files":["webview-ui/src/index.tsx"],"issues":[]}. Once every timing digit is replaced the two outputs are identical.
Step 2, Run knip checks, line 94: exit 1 at this head, exit 1 at the trunk tip, and stdout and stderr are byte-identical between the two footings: Unused files (1), Unused dependencies (1), Unused exports (1), Unused exported enum members (4), Configuration hints (2), plus stderr Remove from ignoreBinaries: dotenvx and Remove from ignoreUnresolved in packages/config-typescript: vitest/globals.
Step 3, Run production Knip checks, line 96: exit 1 at this head, exit 1 at the trunk tip. Both report Unused files 306, Unused dependencies 57, Unused exported types 1, Unused exported enum members 4.
Everything this pull changes in that production output is one row: Unused exports reads 6 at this head against 5 at the trunk tip, and the added row is safeWriteText function src/services/file-safety/safeWriteText.ts:266:23. The file is listed as unused at neither footing, because src/utils/safeWriteJson.ts, which this pull modifies, imports resolveLockKey and resolvePublishTarget from it at its line 9, and safeWriteJson is imported by production files including src/core/task-persistence/TaskHistoryStore.ts:11 and src/api/providers/fetchers/modelCache.ts:12.
So both halves of the answer, stated because both are true: the red is not this pull's doing, since the trunk tip fails all three steps before this pull exists, and this pull is not clean either, since it adds exactly one flagged symbol, an export no production file calls yet.
Choice 1, answer the flag with code: give safeWriteText a production consumer inside this unit by bringing guardedWrite.ts forward from rung 2. Cost: a re-cut of the unit, the gate of record re-run on both sides, a push, and a change to a declared unit boundary that a person has to approve. Most expensive of the three in work, 0 door points.
Choice 2, make the export stop counting as production API: one line in knip.json for src/services/file-safety/safeWriteText.ts, the gate re-run, a push, then the follow-up write at 2 lane points. Removes exactly the one row and is the cheapest act available to me here, and it is the config suppression AGENTS.md discourages, which is why I have not taken it.
Choice 3, leave it as measured, corrected on the flag I over-read: 0 points and 0 files for this lane, but not zero for a person. The ruleset prints "strict_required_status_checks_policy": false, and that flag governs whether a branch must be brought up to date before merging - it does not say a check named on the required list may be red. The same reply prints "current_user_can_bypass": "never" for this identity, bypass_actors absent, and on the merge queue "grouping_strategy": "ALLGREEN", so leaving the row is a request that a person carry a required check, which only a person can do.
Least cost, restated on the corrected flag: for this lane choice 3 spends nothing, and for the pull it is not free - it asks a human to carry a red required context. Of the acts available to me, choice 2 is the cheapest that turns the context green for this row (one knip.json line, the gate re-run, a push, 2 points for the follow-up write), choice 1 is the honest one (bring guardedWrite.ts forward from rung 2: a re-cut plus a declared boundary change a person must approve), and a fourth route neither list held - removing the export the tool names - was measured after this comment was first written and is carried in the following comment.
For re-measuring: the six Unused exports rows at this head are defaultPrompts src/shared/modes.ts:133:14, getRoleDefinition src/shared/modes.ts:207:17, getDescription src/shared/modes.ts:217:17, getWhenToUse src/shared/modes.ts:227:17, getCustomInstructions src/shared/modes.ts:237:17 and safeWriteText src/services/file-safety/safeWriteText.ts:266:23. The first five are the trunk tip's entire tally and the sixth is this pull's, and the 306 unused files are the same set at both footings, differing only in the order the tool prints them.
This is a local measurement, not a CI read: the trunk tip check-run state was not bought in this leg. Nothing landed, pushed, configured, suppressed or directed by this comment.

Re-anchored to the head this pull carries now, appended rather than written over. This answer was written against e77527fb65c7bb21609c0f0740c8d07b740c0f88. This pull now carries two commits, e77527fb65c7bb21609c0f0740c8d07b740c0f88 and a39f46118f39264913b66bbf40c02a621a2325e2, the second being the head and the first its parent, so the commit this answer names is still on the branch and nothing in this reply points at an object the branch dropped - measured against the pull's own commit list rather than assumed. Read the figures above as figures at the earlier commit. At the head the branch now carries, the door prints the name this answer is about as knip completed with conclusion success, completed_at 2026-11-13T07:39:01Z, alongside check-translations, platform-unit-test (ubuntu-latest), platform-unit-test (windows-latest), compile and e2e-mock all completed / success, 19 of 20 rows success, 0 rows failure, and CodeRabbit the only row still in_progress.

One thing a reader following the citations above should know: the trunk tips named there, 5f42a918b9458b0383b7a3a0c86b901a5b311664 and d76dffa860939f79ce4657bee56364ed272d3523, are commits on main, not on this pull. Neither is an ancestor of the head this pull carries and neither appears in the two rows the pull carries, so searching for them in this pull's commit list will find nothing; they are named as the footing the measurements were taken against, and they are reachable on main.

The verdict word being asked for is not a checks word. The door's word for knip at this head is already success. The word still missing is a review word a person has to type: the ruleset Protect Main requires required_approving_review_count 1 and require_code_owner_review true, it sets current_user_can_bypass to never for this identity, and dismiss_stale_reviews_on_push is true, which means an approval has to come after the push that landed at 07:37:46Z to count at all.

Where the safeWriteText finding stands now, and the readers behind it

src/services/file-safety/safeWriteText.ts is the export production knip counts as unused public API. Outside test paths it has no reader: the only outside-test mention of the name anywhere in src, packages, apps or webview-ui is the declaration itself, and of the four lines that import the module only two name this export, both in its own specs, __tests__/safeWriteText.spec.ts:7 and __tests__/safeWriteText.integration.spec.ts:5. src/utils/safeWriteJson.ts:9 and __tests__/safeWriteJson.lockKey.spec.ts:9 import resolveLockKey and resolvePublishTarget, not this name.

It is now carried by the declaration the repository prescribes. Commit a39f46118f39264913b66bbf40c02a621a2325e2 on refs/heads/fws/u9d-safe-write-primitives adds six comment lines above the export, @internal with the reason beside it, and changes nothing else: the export line is byte-identical, no configuration file is touched, no suppression is added, and the reason points at docs/development-quality-checks.md line 36, which tells an author in this position to declare the seam here rather than in configuration. scripts/knip-policy.test.mjs carries that case as one of its own tests.

Exits in the order production knip, plain knip, the guardrail test, the two importing suites, the type check the src package declares: before the change 1 / 1 / 1 / 0 / 2, after it 1 / 1 / 1 / 0 / 2. The Unused exports tally goes 6 to 5 and the safeWriteText row is gone from it; the 5 left are the set the trunk tip prints; plain knip is byte-identical before and after; the two suites go 66 of 66 passed at both footings of the change.

Those figures are knip 5.60.2, which is what this box has installed. The head, its merge base and both trunk tips declare knip 5.88.1 and prettier 3.9.10 in package.json. Under 5.88.1 the tool stops before it reports anything here: it exits 2 loading webview-ui/eslint.config.mjs, because the @roo-code/config-eslint it resolves through is another checkout's copy and does not export ./i18n-language-switch, which this head's own copy does declare. So this box cannot run the declared version against this tree, and only a workflow run on the pushed commit can say what 5.88.1 makes of the tag.

The guardrail test shows the same split. At 5.60.2 it fails one case, visual entries cannot hide helpers unused by the production application, identically at this head, at 5f42a918b9458b0383b7a3a0c86b901a5b311664 and at d76dffa860939f79ce4657bee56364ed272d3523, which is a state that predates this pull. At 5.88.1 the same test file against the same tree passes 8 of 8 and exits 0. Neither version of that fact is caused by this pull.

A word about the two tips named above: they are footings, not commits this pull carries. Appended, not written over. 5f42a918b9458b0383b7a3a0c86b901a5b311664 and d76dffa860939f79ce4657bee56364ed272d3523 are the footings those figures were taken against. They are commits of main: neither is an ancestor of the head this pull carries and neither is one of the rows this pull carries, which the pull's own commit listing prints as exactly two, e77527fb65c7bb21609c0f0740c8d07b740c0f88 and a39f46118f39264913b66bbf40c02a621a2325e2. To re-produce a figure above, read comment 6846167639, which carries the command line, the footing install and the counts, and run it at the tip named as the footing rather than at this pull's head.

The knip guardrail step that fails here is version-bound, and it is not this pull

pnpm test:knip-policy fails one case at this head: visual entries cannot hide helpers unused by the production application in scripts/knip-policy.test.mjs, reported as AssertionError [ERR_ASSERTION]: {"files":["webview-ui/src/index.tsx"],"issues":[]}. The same case with the same assertion in the same file fails identically at this pull's merge base, at 5f42a918b9458b0383b7a3a0c86b901a5b311664 and at d76dffa860939f79ce4657bee56364ed272d3523. Nothing in this pull turns it red, and nothing in this pull's diff reaches webview-ui.

Which knip answers changes the answer, so it is worth pinning. This head, its merge base and both trunk tips named above declare knip 5.88.1 in package.json. Every failure above was produced by knip 5.60.2, the version this checkout's install carries. The same test file against the same tree, run with 5.88.1, passes 8 of 8 cases and exits 0. The 5.60.2 failure is therefore a property of the tool version, not of the tree, and I cannot report it as a repository-side red without naming the version next to it.

One thing this box cannot settle: 5.88.1 refuses to run against this tree at all, exiting 2 while loading webview-ui/eslint.config.mjs for the reason above, and the run-logs leaf answers 403 to this identity, so which of the three knip steps turns the knip context red on the workflow side is unmeasured here rather than settled.

The tips named above are footings, not commits this pull carries. Appended, not written over. 5f42a918b9458b0383b7a3a0c86b901a5b311664 and d76dffa860939f79ce4657bee56364ed272d3523 belong to main. Neither is an ancestor of this pull's head and neither appears in the two rows the pull's own commit listing prints, e77527fb65c7bb21609c0f0740c8d07b740c0f88 and a39f46118f39264913b66bbf40c02a621a2325e2. To re-produce what is claimed above, read comment 6846167639 for the command line, the declared-versus-installed versions and the counts, and run that command at the main-side tip named as the footing: the step is version-bound, so the answer at the footing install is not the answer at the head.

This head is green on every check the door prints, and it still needs a person

Head a39f46118f39264913b66bbf40c02a621a2325e2. The per-commit door, read once at 07:57:54Z, lists 20 runs of total_count 20 with no next page, so that listing is complete: 19 rows completed / success and 0 rows with a failure conclusion. The six names the ruleset requires all read completed / success, with the stamps the door gave them - check-translations 07:38:50Z, platform-unit-test (ubuntu-latest) 07:42:54Z, platform-unit-test (windows-latest) 07:46:50Z, compile 07:41:47Z, knip 07:39:01Z, e2e-mock 07:42:52Z. The three that were still running an hour ago are now finished the same way.

The other rows, named: mutation-diff (the advisory row) completed / success at 07:53:32Z, dependency-review success 07:38:19Z, invisible-chars success 07:38:20Z, Build test VSIX success 07:39:57Z, theme-fixtures success 07:40:01Z, extension-host-visual success 07:51:16Z, webview-visual success 07:42:22Z, Analyze (javascript-typescript) success 07:40:20Z, CodeQL success 07:40:12Z, codecov/patch success 07:43:12Z, codecov/patch/webview-patch success 07:43:13Z, Zoo Code / resolve PRs to reconcile success 07:37:54Z, Zoo Code / reconcile PR review state (2443) success 07:38:04Z, and CodeRabbit in_progress with no conclusion, started 07:47:56Z.

What this door does not print, and it is the part a verdict turns on: no step inside a job is visible from here (the run-logs leaf answers 403 to this identity), and the door carries no review decision, no review state, no code-owner verdict and no answer to the unattributed-changes rule. Those are not check runs, and on this repository the ruleset Protect Main (15494382, active) makes them the binding part: required_approving_review_count 1, require_code_owner_review true, require_extra_approval_for_unattributed_changes true, current_user_can_bypass reads never for this identity, dismiss_stale_reviews_on_push true - which means any approval recorded before the 07:37:46Z push no longer counts - while require_last_push_approval reads false and required_reviewers is empty. The commits here are unsigned and unreviewed, so the unattributed-changes rule is live rather than settled.

So: nothing on the checks side asks for a person any more at this head, and everything on the review side does. A green door is not a mergeable pull here; it is a pull that is waiting for an approving review, a code-owner review and possibly the extra approval, none of which this lane can grant or measure from the door.

u9-1917, leg 157. A docstring claim carried by this pull is contradicted by production code beginning at the next pull in the declared merge order, and no gate in the repository's gate of record can see the contradiction. Everything below was measured from transport and this repository's object store at 0 metered requests; the only purchase in this leg is this comment.

The sentence. At this pull's head a39f46118f39264913b66bbf40c02a621a2325e2 the file src/services/file-safety/safeWriteText.ts is 641 terminated lines at blob 7baf10c919fe, and lines 266 to 271 read:

/**
 * @internal Intentional direct-test seam: no production file calls this write path
 * yet, and this unit's own specs exercise it directly, which is the case
 * `docs/development-quality-checks.md` line 36 tells authors to declare here rather
 * than in configuration. Knip still follows the test imports in default mode.
 */
export async function safeWriteText(

The commit that adds the file is e77527fb65c7bb21609c0f0740c8d07b740c0f88, reachable from this head and from none of the other three published heads; the file is absent at the merge base f98fcf7d86534d730de936637c9cb35936461c00 and at the current trunk tip.

True at the head that adds it. Counting every naming of src/services/file-safety/safeWriteText in this head's tree: production files importing the module, 1 - src/utils/safeWriteJson.ts line 9, which imports resolveLockKey and resolvePublishTarget, not the write function; spec files importing it, 3 - src/services/file-safety/__tests__/safeWriteText.spec.ts, src/services/file-safety/__tests__/safeWriteText.integration.spec.ts, src/utils/__tests__/safeWriteJson.lockKey.spec.ts; production call sites of safeWriteText( itself, 0; spec files with such a call site, 2. That production import is this pull's own: the merge base's src/utils/safeWriteJson.ts is blob e54b8c51d3c3 and does not name the seam at all. The directory holds no index file, so nothing imports the module under a directory spelling.

False at 1917's head - the head where it stops being true. At 5dd5882cfa8af736a16de78f78f655203a5f4e29, the next pull in the declared order 2443 then 1917 then 2444 then 2445: production files importing the module, 2 - src/core/tools/guardedWrite.ts lines 27 and 30, and src/utils/jsonFileRecovery.ts line 8; production call sites of the write path, 2 - src/core/tools/guardedWrite.ts:230 and src/core/tools/guardedWrite.ts:326; spec files importing it, 1. The travel caveat belongs beside that count: this tagged file is absent from 1917's own tree, so the sentence is not present at that head either, and its two production imports are unresolved there - which is why that head's own type gate fails on the missing module (leg 147 measured 15 error rows at that head, 5 of them in its own files; carried from that measurement, not re-measured here). Read where the file and that contribution are together, which I built locally rather than argued - 2443's file with 1917's contribution on top at e5f54c11aaab493f7836f700fcd459b0bdd481fd - the sentence is false on its face: 3 production importers (src/core/tools/guardedWrite.ts, src/utils/jsonFileRecovery.ts, src/utils/safeWriteJson.ts) and 2 production call sites.

False only above 2444's head and 2445's head. At 3361738ef3bf204822fe52a90e46508758a70dec production files importing the module, 1 - src/integrations/editor/DiffViewProvider.ts line 23 (resolveLockKey); production call sites of the write path, 0; spec importers, 1; the tagged file is absent. At d41618a6108a436d84691e276f091c39f8e6c314 production importers, 1 - src/core/task-persistence/TaskHistoryStore.ts line 14 (resolveLockKey); production call sites of the write path, 0; spec importers, 0; the tagged file is absent, and that head cites src/services/file-safety/safeWriteText.ts:273-275 twice, coordinates that exist only on a footing carrying this file. Neither text calls the write path, so neither contradicts the sentence on its own; both are contradicted by 1917 landing beneath them in the declared order. On the four-rung landing this file is imported by production at 4 paths and the fifth importer, src/core/task-persistence/TaskHistoryStore.ts, is counted from 2445's own text because I did not build a four-deep footing - stated rather than implied.

No gate in the gate of record can see the claim at all, let alone test it. The compiler option that gives an @internal tag consequences is stripInternal, and it is named nowhere in this tree: git grep -n stripInternal at this head returns 0 rows across every file, including tsconfig.json (which extends @roo-code/config-typescript/base.json) and src/tsconfig.json. Both type legs of the gate of record invoke tsc with --noEmit - the root check-types and the src package's own check-types - so they emit no declarations for the tag to act on, and the src manifest names no declaration-producing build step (0 rows naming declaration in it). So the sentence is unchecked by any gate in the gate of record, not checked and passed: the pull that carries a false claim about production callers ships with nothing that would notice it.

What I did not measure, said before it is mistaken for a finding. Whether any behaviour depends on the tag. I did not run knip at any of these heads in this leg, so I report nothing about whether production mode really excludes the export from its public-surface findings, which is what line 37 of docs/development-quality-checks.md states (blob 5de20077bfd1, identical at this head and at the trunk tip) and what the tagged passage relies on; I tested no consumer of the tag; and I did not read any check run, review row, label or comment of any pull in this leg. Nothing here is pushed, landed, opened or resolved, no suppression or directive is added, no label is touched, and no changeset or changelog is edited.

Provenance: counts from git grep at each published head against this repository's object store; the four heads confirmed by git ls-remote against refs/pull/2443/head, refs/pull/1917/head, refs/pull/2444/head and refs/pull/2445/head, which returned the identifiers quoted above; local constructed footings in .wt-u917-stack3. All of that is unmetered git transport and object-store work. This comment is 1 core request, priced before it was sent.