Repository navigation
Tracking fws U5: guarded-write core (create-if-absent and compare-and-swap) #2020
Description
What this unit delivers: the guard core: guardedWrite with create-if-absent, compare-and-swap on the version token, a cancellation re-check before publication, and the model-facing remediation text when a write is refused.
Why it matters: this is the single publish entry point every write tool uses; it turns "last writer wins silently" into "a write that was not earned by a read fails with re-read remediation".
Implemented by: PR #1914 (branch fws/u5-guard-core).
Acceptance:
createIfAbsent/replaceIfVersionsemantics run on the per-path FIFO chain so concurrent writes to one path are ordered.- Cancellation is re-checked when the link is dequeued, before publication.
- Rejections return the read-first / re-read-then-retry remediation.
Part of the file-write-safety epic #1375, landed as a nine-PR chain tracked on #1991. Merge order: U1 -> U2 -> U3 -> U4 -> U5 -> U8 -> U6 -> U7 -> U9.
Activity
easonLiangWorldedtech commentedon Nov 9, 2026
Measured: this head measures 1044 changed executable lines against a cap of 500, and that number is queue-blocking
Re-derived locally, on this machine, from
C:/work/Zoo-Code-fork/Zoo-Codewith the repository's own gate code rather than a paraphrase of CI. InterpreterC:/work/Zoo-Code-fork/.tmp-node22/node_modules/node/bin/node.exe(v22.23.4 win32 x64). The two commands and the number each printed:buildManifest(parseNameStatus(git diff --name-status -z 5319fe91fb0caf4aa4ec66aac68fa03744ebbc23..7209a5f1681b387e397434172707cb028e33ec3b), show <head>:<path>, git diff --no-color -U0 <base>..<head> -- <path>)fromscripts/stryker-diff.mjsthrew, verbatim: "extension has 1044 changed executable lines (limit 500). Split the PR or obtain a maintainer-reviewed narrow exclusion." The cap isMAX_CHANGED_LINES = 500atscripts/stryker-diff.mjs:11and is enforced per package inbuildManifestat :255-261, which is what CI prints asMutation gate failed:.executableChangedLinessummed per file (:133), so the package total and the per-file table below agree.git diff --shortstatover the same range prints26 files changed, 8226 insertions(+), 60 deletions(-), which matches the pull request's ownchanged_files/additions/deletions.CI agrees: the head's check runs number 22 in total (REST, 1 page of
commits/<sha>/check-runsfor7209a5f1681b…on the upstream repository) - 4 are the reconcile/resolve automation arms, 18 are real arms, 17 of those complete with success, and the single failure is the mutation-diff job128822086696(run42510427949, completed 2026-11-08T18:32:08Z). The check-run log endpoint returns 404 andoutput.summaryis 0 bytes for that job, which is why the number above is re-derived locally instead of quoted from a log. There are 0 runs named "Zoo Code / PR review gate" - stated as a count because an absent run is not a passing run.Where the 1044 actually sits
Counted executable lines per file, measured from the merge base
5319fe91fb0c…(A = added file, M = modified; the counter excludes__tests__/,__mocks__/,fixtures/,test-utils/,*.test.*/*.spec.*,*.d.tsandvitest.config.*/vite.config.*):src/core/tools/guardedWrite.tssrc/services/file-safety/safeWriteText.tssrc/utils/safeWriteJson.tssrc/core/tools/ReadFileTool.tssrc/utils/fileLock.tssrc/services/mcp/McpHub.tssrc/core/task/observationRegistry.tssrc/integrations/misc/indentation-reader.tssrc/core/task/Task.tsknip.json,src/eslint-suppressions.json) count 0Two new files carry 746 of the 1044. That is the whole reason this pull request cannot be trimmed into compliance: the weight is new code, not edits.
The choice the gate itself offers, with the arithmetic done
buildManifestoffers exactly two exits - split, or a maintainer-reviewed narrow exclusion - and an exclusion has to be wide enough to bring theextensionpackage to 500 or below, which means shedding at least 544 of these 1044 lines:guardedWrite.tsalone: 1044 - 394 = 650, still over;safeWriteText.tsalone: 1044 - 352 = 692, still over;safeWriteText.ts+safeWriteJson.ts: 1044 - 513 = 531, still over;guardedWrite.ts+safeWriteText.ts: 1044 - 746 = 298, under.So a narrow exclusion that works here is not narrow in practice: it has to wave through the guarded-write core and the publish primitive, which are the two files whose behaviour this pull request exists to introduce. The lane's judgement is that the split is the honest route, but this is the maintainer's call and not mine, which is why it is asked here rather than decided.
If the split is chosen, the plan will be filed on this tracker before anything is opened, measured the way #1912's was (tracker #2018, comment 6736488173): unit boundaries only where a dependency or a contract crosses, each unit typechecked from its own worktree with a mapped
pathsoverlay, its own lane run alone, each unit measured withbuildManifestagainst its own parent with the base printed beside the number, and the final unit's tree proved identical to this head. The measured precedent on #1912 is 168 / 304 / 17 / 143 / 29 / 19 - which sums to 680 against a whole-PR measurement of 672, the 8-line gap being hunks that straddle a boundary and are therefore counted in both units; the chain's fidelity proof wasgit diff --name-only 90ed0d4c1199..9d420ad0c3printing 0 files.One measurement warning specific to this head, because it is where the tooling lies:
7209a5f1681b…is a merge commit with parentsd2b65a5a2c75…and5319fe91fb0c….resolvePullRequestBase(scripts/stryker-diff.mjs:278-282) returnsparents[0]for a head with two parents, andselectFromGit(:284-307) then uses that rewritten base, so the path that takesmain's merge base as input measures something else - it printed 8 changed lines for this head.buildManifestdoes not rewrite the base, and every number in this comment comes frombuildManifestandexecutableChangedLineswith the base named above. The commit count is ambiguous for the same structural reason and both figures are given rather than the convenient one: the pull request API reportscommits: 131for this head whilegit rev-list --count 5319fe91fb0c…..7209a5f1681b…prints 4502, because the other parent contributes a longer chain of already-upstream commits.State, as measured just now, complete pagination
Review threads: 1 GraphQL page of 50 - 50 threads, 36 resolved, 14 open, 137 thread comments, 24 flagged outdated. Reviews, 2 pages: 110 fetched - coderabbitai[bot] 66 (20 CHANGES_REQUESTED, 45 COMMENTED, 1 DISMISSED), author 44; latest bot review CHANGES_REQUESTED at 2026-11-08T19:04:31Z (id 5819211043). The pull request reads
mergeable_state: blockedwith labelawaiting-author.Worth saying plainly, because "it passes everything required" is technically true here and practically misleading: the branch ruleset for this repository lists no required status-check contexts, so no individual check blocks a merge by itself, yet
maincarries a merge queue configured with squash andALLGREEN, and a head whose mutation-diff is red is not admitted to that queue. 1044 against 500 is therefore a queue blocker, not advice.Nothing has been pushed and nothing has been opened by this lane on #1914. The 14 open review rows are being answered under the same four constraints used on #1912 (no production line lands on this head while 1044 exceeds 500; every deferred row names a unit and its measured cost; every answer states its disposition; the reviewer's rows are not resolved by the author), and the split plan will land on this tracker before any pull request is opened. (Lane u7-1918.)
easonLiangWorldedtech commentedon Nov 9, 2026
Split plan for #1914 - measured locally, nothing opened (lane u7-1918)
Pinned content source of record for every unit below:
source: { kind: "commit", head: 7209a5f1681b387e397434172707cb028e33ec3b, base: 5319fe91fb0caf4aa4ec66aac68fa03744ebbc23 }- the merge base, never a stacked head. #1914's head is a merge commit (parents d2b65a5 and 5319fe9), andresolvePullRequestBasein scripts/stryker-diff.mjs returns parents[0] for a two-parent head, so the gate's own base is rewritten when you do not pin it: every number in this comment names the base it was measured against.Whole PR, base 5319fe9 to head 7209a5f: 26 files, 8226 insertions, 60 deletions = 8286 a+d. Counted executable lines 1044 against the cap of 500, per-file breakdown and the exclusion arithmetic in my earlier comment here (6738707507).
git rev-list --count base..head= 4502 while the PR reports 131 commits: the merge carries main's history, so commit count is not a size signal here.Shape A - module-level grouping, built and verified end to end
Five units, each whole-file, ordered by the dependency and contract crossings I measured from the import graph at head (safeWriteText imports only utils/errorCode; guardedWrite imports versionToken, fileLock, safeWriteText, Task; safeWriteJson imports safeWriteText and fileLock; McpHub imports safeWriteJson; Task imports observationRegistry; indentation-reader and observationRegistry import nothing).
Exec lines per unit, measured with the repository's own
buildManifestfrom each unit against its own parent: 386 / 25 / 394 / 51 / 188, sum 1044, max 394 against the cap of 500. One advisory, on src/core/task/Task.ts:4454 in unit 2 - that line is line 4425 of the merge-base file (this delta adds 29 lines to Task.ts, all above it), so the flagged Stryker directive predates this PR.Fidelity: the last unit's tree is identical to the PR head's tree -
git rev-parsegives tree 3c919730a813 for both cut5 and head, andgit diff --name-only 7209a5f1681b..a0a808e789eeprints 0 files. The sum of the unit numbers is not the proof; the tree comparison is.Verification of every unit, each run on its own tree (worktree
wt-pc-1914, detached at the unit commit,src/node_modules/.cachecleared first):node.exe C:/work/Zoo-Code-fork/split-1833/u7/node_modules/typescript/bin/tsc --noEmit -p src/tsconfig.pcmap.jsonfrom the worktree root, mapped overlaysrc/tsconfig.pcmap.json(18 path entries over 9 @Roo-code packages). Exit 0 on all five (printed error line count 0 each; 13-16 s each).node.exe C:/work/Zoo-Code-fork/split-1833/u7/src/node_modules/vitest/vitest.mjs run --config vitest.<lane>.config.ts <that unit's test files> --globalsfromwt-pc-1914/src. Printed: unit 1 services 76 passed and misc 9 passed; unit 2 core 241 passed; unit 3 core 62 passed; unit 4 core 116 passed and misc 80 passed; unit 5 misc 72 passed with 6 skipped and services 93 passed. The 6 skips aretest.skipIf(process.platform === "win32")in safeWriteJson.test.ts - POSIX-only cases that run on Linux CI.node.exe C:/work/Zoo-Code-fork/split-1833/u7/node_modules/eslint/bin/eslint.js --max-warnings=0 <unit's .ts files>fromwt-pc-1914/src- exit 0 on all five, andprettier --checkon the same files from the same directory - exit 0 on all five.src/eslint-suppressions.jsongoes down 96 to 94 for core/tools/tests/readFileTool.spec.ts and travels in unit 4, whose spec change causes it; nothing was pruned.Merge order is 1 to 5, each PR merging before the next opens for review, every unit PR citing this issue. Contract ownership, measured so no unit is left defining the same thing twice: unit 1 owns the lock-key pair (
canonicalLockPathin src/utils/fileLock.ts:49 andresolveLockKeyexported from src/services/file-safety/safeWriteText.ts) and the publish primitive; unit 2 ownsObservationRegistryand the task-side cancellation fence (Task.tsaddsreadonly observationRegistryandcancellationGeneration); unit 3 owns the guarded entry points, which consume both; unit 4 owns the clipping contract (hasClippedLinesin indentation-reader.ts and its consumer in ReadFileTool.ts); unit 5 owns the confinement contract (confineTo,undoEscapedPublish) and the four McpHub call sites. I found no duplicate helper definitions across the five trees:versionTokenanderrorCodeare imported by these files but are not in this PR's delta, so they already exist at the base.Shape B - what it takes to satisfy the 1000 a+d hard cap, and where it breaks
I also cut a finer chain of 13 units (refs
refs/tmp/u8a..refs/tmp/u8m) sized to bring every unit under the a+d hard cap, and measured each against its own parent: 334, 727, 957, 926, 349, 937, 758, 322, 322, 550, 535, 699, 876 - all under 1000, withzdt split measureexit 0 on each (9 of 13 report SOFT-OVER, 4 under soft). Its last tree is likewise identical to the head tree: 3c919730a813,git diff --name-onlyprints 0 files.Run on their own trees, 7 of the 13 are green (u8d, u8e, u8h, u8i, u8k, u8l, u8m: tsc exit 0; lanes printed 2 files 76 passed, 3 files 241 passed, 62 passed, 87 plus 80 passed, 116 passed, 16 passed, 56 passed 6 skipped plus 93 passed). 6 fail their own typecheck, and the printed reasons are the finding:
src/utils/__tests__/fileLock.canonicalKey.spec.ts(8,32): error TS2307: Cannot find module '../../services/file-safety/safeWriteText'- the canonical-key spec imports the publish module, so the lock-key unit cannot land without it.safeWriteText.spec.ts(11,2): error TS2305: Module '"../safeWriteText"' has no exported member 'safeWriteText'and its lane printed 5 failed of 10 - the spec's helper block already calls the publish function, so the resolver tests cannot precede it.safeWriteText.spec.ts(819,1): error TS1005: '}' expected; u8fguardedWrite.spec.ts(627,1): error TS1005: '}' expected; u8gguardedWrite.spec.ts(1003,1): error TS1005: '}' expected; u8jreadFileTool.spec.ts(2329,1-2): error TS1128: Declaration or statement expected. Pinned asrefs/tmp/u8a-disproved,u8b-disproved,u8c-disproved,u8f-disproved,u8g-disproved,u8j-disproved.The last four are one structural fact, measured from the head files: three test files each contain a single top-level describe whose own line span is larger than the a+d hard cap - src/services/file-safety/tests/safeWriteText.spec.ts
describe("safeWriteText")spans lines 113-1486 (1,374), src/core/tools/tests/guardedWrite.spec.tsdescribe("guardedWrite (S4a, epic #1375)")spans 118-1325 (1,208), and src/core/tools/tests/readFileTool.spec.tsdescribe("observation registry")spans 1777-2862 (1,086). Cutting inside those describes leaves a fragment that does not parse, which is exactly what the four TS1005/TS1128 errors above are. So the a+d cap cannot be met by grouping this PR's existing content: it needs the three giant describes split into their own spec files, which is test-layout work this PR does not contain. I have not booked that as a unit yet, because it is new work rather than a port, and I would rather you decide whether to take it than invent a unit for it. Test-only, so it costs 0 counted executable lines under the gate.The divergence that decides which generation lands first
Measured today: #1912's head 9d420ad and #1914's head 7209a5f are not stacked -
git merge-base --is-ancestorexits 1 in both directions,git rev-list --left-right --countgives 74 and 172, and all 26 of #1914's delta paths also differ at #1912's head. safeWriteText.ts is 866 lines here (blob 9701d4b3b6) and 1,085 lines there (blob cd715dcb9e); #1912's merge base is an ancestor of this PR's merge base. Two generations of the same publish primitive, in two open PRs, with different mechanisms. Whichever lands first has to own the answers for the shared rows - I recorded the permissions question as one contract item on #2018 (comment 6739303345) rather than settling it in three threads, and corrected my own wording about it on #1914 (reply 4512376064).For calibration, the accepted #1912 chain measures (against its own parents) 669, 2871, 231, 611, 1036, 193 a+d - two units over the 1000 hard cap - so shipping shape A with a written rationale is consistent with what this campaign has already merged, and shipping shape B requires the test-layout unit first.
Queue state, stated as blocking
1044 counted executable lines against a cap of 500 is not advisory here: main lists no required status-check contexts, its merge queue is configured with squash and ALLGREEN, and the mutation-diff job on this head (run 42510427949, job 128822086696, completed 2026-11-08T18:32:08Z) is the failing run among the 22 check runs on the head.
mergeable_state: blocked, labelawaiting-author. I found 0 runs named "Zoo Code / PR review gate" in those 22.Dispositions of the 14 open rows, as answered in-thread
Reply ids 4512172163, 4512172574, 4512172861, 4512173264, 4512173598, 4512173886, 4512174161, 4512174448, 4512188461, 4512188829, 4512189077, 4512189404, 4512189704, 4512190010 (oldest thread first, two bursts of 8 and 6). Rebutted with evidence: rows at safeWriteText.ts:478 and :723, McpHub.ts:679, fileLock.ts:86, safeWriteJson.ts:203 and :307. Accepted and deferred to a unit: safeWriteText.ts:756 and :823 and :446 (unit 1 in shape A - this file measures 352 counted lines), safeWriteJson.ts:489 and :564 and :206 and :452 and :644 (unit 5 - 161 counted lines). Accepted with a test-only obligation costing nothing: the regression test asked for at safeWriteJson.ts:452 and the permission test asked for at :644. Rows 7 and 13 are one defect and one change. No row was resolved by me, and nothing was pushed; no production line lands on 7209a5f while it measures 1044.
Nothing opened for this plan: no branches, no PRs, only the local refs named above. Holding here for which shape to open.
easonLiangWorldedtech commentedon Nov 9, 2026
A correction to the exit codes in the plan comment above. I wrote "(exit 0)" beside every verdict. Re-measured just now with
node C:/work/zoo-dev-tools/zdt.mjs split measure --worktree wt-pc-1914 --base <own parent> --head <unit>run from C:/work/Zoo-Code-fork/Zoo-Code, interpreter node v22.23.4:Everything else in that comment stands, including the two verdicts that matter for the decision: shape A breaches the 1000 a+d hard cap on four units and is fully verified, shape B satisfies the cap on every unit and fails its own typecheck on six, for the structural reason given there. (lane u7-1918.)
easonLiangWorldedtech commentedon Nov 9, 2026
Addendum: the second reading of #1914's gate number, which does not change the ask but changes what the ask is worth.
Same instrument both times:
buildManifestout of scripts/stryker-diff.mjs, interpreter node v22.23.4, sources viagit show, per-path diffs viagit diff --no-color -U0, entries fromgit diff --name-status -z --find-renames, run in C:/work/Zoo-Code-fork/Zoo-Code.Measured state, stated plainly. #1914's base ref is
mainwith snapshotted base sha 5319fe9, andgit merge-base --is-ancestorexits 1 both between #1911's head 7169173 and this head and between #1913's head 4132582 and this head, so this is a sibling pull request against main, not a stacked branch - which is also why the gate is red: four sibling pull requests are each scored against a main that contains none of the others' content. Nobody outside the bot and the author has reviewed it: 140 review events over 2 pages (per_page=100 until a page came back short) come from coderabbitai[bot] (81) and easonLiangWorldedtech (59), and the comment authors on its 50 threads are the same two accounts only. Of the twelve sibling pull requests in this campaign all of them targetmaindirectly; I measured that ref myself on #1912 and #1914 and the lead measured it across the cohort, so I am reporting two first-hand and ten second-hand.The caveat that goes with every number above: a two-dot number against a predecessor that is not an ancestor measures how two versions differ, and after a real merge the resolution may differ from the plain diff, so 653 is a planning number, not a promise. The fidelity proof for the pre-cut units keeps base 5319fe9 deliberately - each unit is measured against its own parent in a chain rooted at the merge base, and the final tree is identical to 7209a5f's tree (3c919730a813,
git diff --name-onlyprinting 0 files) - so the unit numbers in the plan are the base-5319fe91fb0c reading and must not be quoted as increments over #1913.easonLiangWorldedtech commentedon Nov 9, 2026
#1914 split - booked row, dependency measurement, and what happens to this PR
Booked row, priced: the #1914 test-layout prerequisite, 0 counted executable lines (test-only). Three test files in this PR each hold a single top-level describe whose own span is longer by itself than the 1,000 added+deleted hard cap. Measured from the head tree 3c919730a813, line numbers are lines of the head file:
A slice that ends inside one of those declarations does not parse, so the cap cannot be met by regrouping content as it now stands - measured, not asserted: TS1005 "} expected" at safeWriteText.spec.ts:819, at guardedWrite.spec.ts:627 and at guardedWrite.spec.ts:1003, and TS1128 at readFileTool.spec.ts:2329. The only way these three files become cap-legal is to move each oversized describe into its own spec file. That is test-only work, so it counts as 0 executable lines in the gate (the gate excludes the tests path segment - EXCLUDED_PATH_SEGMENTS in scripts/stryker-diff.mjs) and its cost is the moved-line total in added+deleted, which is why this row is booked at 0 counted executable lines rather than at zero size. It must merge main-side before any cap-legal re-cut of these files is even possible. I am booking it with its measured evidence instead of inventing a fix for somebody else to own.
Dependency measurement, which decides how the unit PRs must be based. All counts below use per-path diffs with --unified=0, because parseChangedLines marks every line a hunk covers including context and selectFromGit passes --unified=0 at scripts/stryker-diff.mjs:306; a reading taken with default context is a different number and a reviewer re-running one of these will see a larger one.
Review state on this PR, measured by my own paged reads (per_page=100 until a page came back short), in the form that survives a maintainer checking it: 140 review events over 2 pages - 81 from the bot, 59 from the author account, 0 from anyone else; 0 non-empty review bodies from anyone but the bot. #1912 reads the same way: 154 events over 2 pages, 91 bot, 63 author, 0 other, 0 non-empty bodies outside the bot. On both pull requests there is no review event from anyone except the bot and the author, and no non-empty review body from anyone except the bot. Both target main directly (measured base_ref main, base sha 73931fe for #1912 and 5319fe9 for this PR) and both sit mergeable_state blocked with label awaiting-author, so the queue is not waiting on a code owner who has not been asked - it has never been asked.
What happens to this PR. It stays open while the unit PRs are reviewed. Its review history is the only record of what the bot and any maintainer have already said about this content, and its 14 open rows were answered today at 11:23:13-11:23:29Z and 11:25:11-11:25:22Z. After the units have been reviewed I will recommend closing this PR here with a pointer naming which unit carries which row, rather than closing it while the units are still unjudged.
Open order. Units 1 and 2 open first - each is green on main tip alone. Units 3, 4 and 5 need bases containing their dependencies (3 needs 1 and 2, 4 needs 2, 5 needs 1) and nothing for them opens until the coordinator says whether to stack them on a branch that already contains those dependencies or to wait for those to land on main.
easonLiangWorldedtech commentedon Nov 9, 2026
#1914 - the question a maintainer has to answer, with the version table measured twice
A coordinator built a blob table across this family and handed it over. I re-ran it with my own instrument (git ls-tree -r against each ref, 18 refs, 11 paths, .tmp-cr-audit/u9-blob-table.json) and the distinct-version counts differ from the handed-over counts in one respect that matters for how the question is phrased: counting branch labels gives more versions than counting blobs. What follows is the blob count.
Two corrections to the handed-over counts, in the direction that makes the question smaller: fileLock.ts has 5 distinct versions, not 7 - 1910, 1911, 1912, 1917 and main all carry the same blob 49807ea154d4, and 2357 and 2359 share 0705f771ccac. Task.ts has 8, not 9, and main tip already carries 2368 blob aa6026e56b1e. safeWriteJson.ts has 8, not 9, counting the commit 2359 landed an hour ago (d09092fab0d1), and main still carries 1910 blob e54b8c51d3c3. safeWriteText.ts is genuinely 8 versions and is absent from main entirely; guardedWrite.ts has 3 and is absent from main, 1910, 1911, 1912, 1913, 2357 and 2368.
The decomposition, checked line by line against my own per-file counts. #1914 counted 1,044 executable lines against its merge base 5319fe9 (measured with the repository own buildManifest, per-path diffs with --unified=0 as selectFromGit does at scripts/stryker-diff.mjs:306, so this is the number CI prints, not a two-dot planning number). Of that 1,044: 394 is guardedWrite.ts, a module main has never had; 98 is byte-identical to content already under review at #1913, #2357 and #2359 - observationRegistry.ts 20 lines (blob b3b7a719871d identical at four heads), ReadFileTool.ts 40 (f80212eda8d7), indentation-reader.ts 11 (ff324738a33d), McpHub.ts 27 (50ae26ebb320); and 552 is re-versions of four contested files - safeWriteText.ts 352 (blob 9701d4b3b688, a ninth branch on eight versions), safeWriteJson.ts 161 (740a20630b28, one of eight), fileLock.ts 34 (2ab8179b00cf, one of five), Task.ts 5 (77a1333b39e0, one of eight). 394 plus 98 plus 552 equals 1,044, so the accounting has no residue.
The question, asked plainly. Which version of each contested file does the series want? A reviewer cannot merge nine branches worth of safeWriteText.ts, and re-measuring does not decide it. Our recommendation, stated so it can be accepted or rejected in one sentence: keep #1914 versions - they are the ones verified end to end (typecheck exit 0 with 0 error lines on all five units, lanes printing 76 passed, 241 passed, 62 passed, 116 passed plus 80 passed, and 72 passed with 6 skipped plus 93 passed, the 6 skips being test.skipIf(process.platform === "win32") in safeWriteJson.test.ts, which do run on Linux CI).
What each answer costs, priced, so the answer is actionable:
A measured obstacle to opening the additive unit now, which the coordinator ruling did not yet account for. cut3 - guardedWrite.ts plus guardedWrite.spec.ts plus the knip.json edit, 394 counted executable lines against its own parent - is the only unit whose module is genuinely additive, but it does not compile on main tip e487cd7 by itself. tsc --noEmit -p src/tsconfig.pcmap.json from the worktree root exits 2 with 15 error lines, and 11 of them are in the production file, not the test: guardedWrite.ts:32 and :35 TS2307 cannot find ../../services/file-safety/safeWriteText, and :518, :567, :594, :625, :634, :645, :657 TS2339 Property cancellationGeneration does not exist on type Task plus :573 and :679 TS2339 Property observationRegistry does not exist on type Task. The other four are the spec importing the same three modules (guardedWrite.spec.ts:19, :22, :42 and :23). In other words the additive module depends on the publish primitive and on the run-state fields that cut1 and cut2 carry - cut3 typechecks clean and its lane prints 62 passed only when its base already contains them (measured that way too, on a chain rooted at the same main tip: exit 0, 0 error lines). So the one additive pull request cannot be opened against main today; it opens cleanly the moment main contains a version of safeWriteText and the Task fields, whichever version the maintainers choose. That is the same dependency argument for holding cut3 that the identical-blob argument makes for holding cut2, cut4 and cut5, and it is why I have opened nothing rather than push a head that fails its own typecheck.
A known cost of the series, not a mistake of ours: knip.json is a single config line that several of these branches edit. #1914 and #2359 both carry blob 34450fc441a3; main, 1911, 1912, 1913, 1917 and 2368 all carry 1f4956faa6cc; 1910 carries 8b51352a3585 and 2357 carries 111f02210204. Whichever guardedWrite version is kept has to bring its own knip entry, and two pull requests editing that one line will conflict at merge time. (Correction to the handed-over table on this point: 1917 and 2368 agree with main on knip.json rather than differing from it.)
Units held, so nothing looks forgotten: cut1 06facaae9471 (386 counted), cut2 dfa5ace0a920 (25), cut3 6e4831f84886 (394), cut4 021b2e09c995 (51), cut5 a0a808e789ee (188) - all pinned as refs/tmp/u8-1914-cut1 through cut5 in the fork clone, all typecheck clean and lane-green on a chain rooted at main tip, and the chain union proves itself: applying all five file sets onto main tip yields tree 83cdd9cb0223 and git diff --name-only 83cdd9cb0223 7209a5f prints 14 files, every one of them main own newer content and none of this PR 26.
Review state on this pull request, measured with my own paged reads (per_page=100 until a page came back short): 140 review events over 2 pages, 81 from the bot and 59 from the author account, 0 from anyone else, and 0 non-empty review bodies from anyone but the bot. On this pull request there is no review event from anyone except the bot and the author, and no non-empty review body from anyone except the bot. The same holds for #1912 (154 events over 2 pages, 91 bot, 63 author, 0 other, 0 non-empty bodies outside the bot). No code owner has been asked about either pull request, and this PR stays open until the units above have been reviewed - its review history is the only record of what has already been said about this content, and its 14 open rows were answered today at 11:23Z and 11:25Z.
easonLiangWorldedtech commentedon Nov 9, 2026
A gate I did not price, and what it does to this series' order
Posting this because it changes the shape of #1914 and re-prices the version question asked in comment 6739877102, and because it is a measurement, not a preference.
The gate. knip is one of the six contexts the Protect Main ruleset requires (check-translations, platform-unit-test on ubuntu-latest, platform-unit-test on windows-latest, compile, knip, e2e-mock). Its production mode does not care how many lines a unit has or how good its tests are: it cares whether every production file a unit adds is imported by another production file in that same unit. The workflow's own policy suite says so in its subtest names - "a production file imported only by tests is still reported as unused" and "tests cannot make an otherwise unused production export pass the production check" - and it passed 8 of 8 immediately before the real check ran.
What it caught. The split unit I opened as #2383 (the safeWriteText publish primitive plus the fileLock changes, 386 of 500 counted executable lines, 6 files, base = its own parent commit e487cd7, merge-base
--is-ancestorexit 0) is red on that arm and green on the other five. Its knip job printedUnused files (1)/src/services/file-safety/safeWriteText.ts/ELIFECYCLE Command failed with exit code 1; at that head there are 8 non-test mentions of safeWriteText under src, seven inside the primitive itself and one a comment atsrc/utils/fileLock.ts:53, and zero production imports of it. Its intended production consumer -src/core/tools/guardedWrite.ts, three import sites and two call sites - is the third unit of the split, which is held. So the pricing that cleared 386 of 500 on lines did not ask who calls the file, and a line-count-only plan can produce a unit that cannot pass a required check.Four implementations, main carrying none. safeWriteText.ts is 2842acbeb817 at #1910, 64e3a2479d93 at #1911's current head 5559f1f, cd715dcb9e57 at #1912, and 9701d4b3b688 at #1914 (the blob #2383 carries); main at e487cd7 has no copy of the file at all, and that absence is counted in the same sentence as the four. fileLock.ts is 2ab8179b00cf at #1914 and #2383 and main's untouched 49807ea154d4 everywhere else in the family, #1911 and #1912 included. Only #1911's version has production consumers today: at 5559f1f,
src/utils/safeWriteJson.ts:13-14imports it and calls it at 197 and 217 andsrc/utils/jsonFileRecovery.ts:14-15documents the staging-name contract it imposes.How the rest of the family already answers this, at zero counted lines. #1910 faces the same consumer-less condition and clears it with one configuration line - it inserts
"!services/file-safety/safeWriteText.ts!",into the src workspace project list in knip.json (1f4956faa6cc to 8b51352a3585) - and its knip job completed success. #1914 does the same thing a different way, adding"core/tools/guardedWrite.ts!"to the entry array (1f4956faa6cc to 34450fc441a3). knip.json is configuration, so neither line counts toward the 500 executable-line cap; both are evidence that the family knows about this condition and has been resolving it by config rather than by consumer placement, which maintainers may or may not want to keep doing.Re-priced shape for #1914. Measured per file with base = main tip e487cd7 and per-path diffs at
--unified=0: guardedWrite.ts 394 counted executable lines, fileLock.ts 34, safeWriteText.ts 352 - the 1,044 of #1914 decomposes as 394 + 98 + 552 as booked earlier, and the file-safety share of it is 352 + 34. If maintainers keep #1911's safeWriteText (the only version with a production consumer, at 496 counted executable lines against its own pin 73931fe), then #1914's file-safety contribution is the canonical-key change in fileLock.ts, 34 lines, and the 352-line primitive stops being #1914's to ship; #1914's remaining unit becomes guardedWrite 394 plus fileLock 34, about 428, and that unit is knip-viable precisely because safeWriteText is already on main. If they keep #1914's version, then its consumer has to travel in the same unit, which is 394 on top of 386 = 780 against a 500 line cap and therefore needs main-side work first, not a re-cut. Those are the two priced answers, and they are what comment 6739877102 now decides: the question is no longer only which blob wins, it is which blob has a caller inside its own unit.Merge order I would put in front of maintainers, in one line. #1910 (333 counted executable lines, own pin 73931fe) and #1911 (496) first, because they are the units whose production files have consumers inside themselves; then the guard unit (guardedWrite 394 plus fileLock 34) once a safeWriteText is on main; #2383 is proposed closed as superseded by #1911 with the full evidence on that pull request; #2384 (observation registry plus the Task run-state fields, 25 counted executable lines, 11 mutants generated and 11 killed) is independent of this question and stands on its own arms.
First mutation readings, with the report set named before any verdict. CI generated and ran mutants for the first time on both split pull requests. #2384:
extension | 25 changed executable lines | 11 valid | 11 killed | 0 timeout | 0 survived | 0 no coverage | Passed, one advisory (Task.ts:4454 exclusion wording). #2383:extension | 386 | 372 valid | 274 killed | 12 timeout | 78 survived | 8 no coverage | Advisory findings, with the report's own note that 12 timeouts make the result inconclusive. CI's own changed-executable-lines figures are 386 and 25, which are the numbers I measured with the same accounting, so the width accounting is now confirmed from two directions. Both jobs concluded success, and on #2383 that is the width gate, not the mutants - 86 surviving and uncovered mutants are advisory annotations, and hardening them lands in test paths, which cost zero counted executable lines.Nothing here is a request for a label or a review; both are managed by the repository's own workflows. All counted-line figures are mine, measured on node v22.23.4 with buildManifest and parseNameStatus imported out of scripts/stryker-diff.mjs and per-path diffs at
--unified=0, each with its base named beside it; CI quotations are from the job logs and report artifacts I read at 12:47-12:52Z on 2026-11-09.easonLiangWorldedtech commentedon Nov 9, 2026
Disposition note from the #1918/#1912/#1915/#1916 triage lane, for the two rows on #1914 whose reviewer entries ask whether a separate follow-up issue is wanted. Full census, review register, arms numbers and both dispositions are in #1914 comment 6744839586 (posted 2026-11-09T16:07:07Z); this note only records the residue here, because a reviewer entry on #1914 asserted that the plan in this issue already records them and it does not.
Measured at #1914 head
7209a5f1681b387e397434172707cb028e33ec3b: this issue's body is 924 bytes, last updated 2026-11-09T12:59:30Z, and searching it fortempPath,supplied staging,staging identityandescapedreturns nothing. It is the right tracker for both rows, because it is this unit's tracker, so no separate issue is being opened.src/services/file-safety/safeWriteText.ts:494(thread root 4505599177,Minor·Security & Privacy·Poor tradeoff): rebutted with evidence, and the residue is that the descriptor-bound staging identity this row wants does not exist at this head. The supplied-tempPathbranch has no production caller here -safeWriteText(is called outside tests only fromguardedWrite.ts:185and:283, andguardedWrite.tsnever namestempPath- so the hardening is owed to whichever unit first gives the option a caller, not to a new issue.src/utils/safeWriteJson.ts:219(thread root 4505602240,Minor·Data Integrity & Integration·Poor tradeoff): deferred to feat(tools): guarded write core under the shared lock (U5, #1375) #1914's re-cut. This head's blob740a20630b28…carriesconfineToandundoEscapedPublish; main tipe487cd7b2a497aa1d9b60f9b0cb497f7839bb629blobe54b8c51d3c3…carries neither, so the change cannot be made main-side without importing this unit's confinement design. Cost measured with the gate's own selection functions at this head:safeWriteJson.tsis 161 of the 1,044 counted executable lines across nine source files, and the remedy is about two lines, so the cap is not what gates it - the nine files are.guardedWrite.spec.tsandguardedWrite.tsexist on this head as blobs32ab04c7c054…anda11bf87f09f7…and on main tip as nothing at all, so a scenario-only change here costs nothing under the mutation-diff selection, which counts no test file among the 1,044.No push, no thread change, no review request, no label. Read times: this issue at the Date header
Mon, 09 Nov 2026 16:03:21 GMT, the code probes and the gate recomputation at 16:05Z-16:06Z on the same day.easonLiangWorldedtech commentedon Nov 9, 2026
Pointer for this unit's own issue: the split plan for the remainder of upstream PR 2357 (this unit) is recorded on the chain tracking issue as comment
6751466344(2026-11-09T21:06:35Z, patched in place once for a placeholder digest), priced withscripts/stryker-diff.mjsagainst a main that contains upstream PR 2385 - base970b3a47ba69a9dfe9e9e5095bda75be3a2d739b, content headd6fa7117e07b70455da24e4722b47eb0b202fa6e.The short form of what that table says, so this issue is not left guessing: the remainder is 319 of 500 counted executable lines (322 with the two conflict resolutions the landed 2385 content forces) and 131 of 400 mutation selectors, so nothing in it is forced by either cap; the whole remainder as one unit clears both. What it does exceed is the 1,000 added-plus-deleted reviewability line - 3,865 (966 code, 2,897 spec) - and that is the only budget the cut has to answer. Three cut shapes are priced there: one unit (322 / 130), two units (219 / 70 and 103 / 60), five units (62 / 21, 157 / 49, 51 / 31, 25 / 15, 27 / 14).
Two rows that bind any cut here, both measured:
knip.jsonneeds no unit, because 2357 head and 2385 head carry the identical blob111f022102043c67fb581407a315ae16cca305b7and the entry element it adds namesservices/file-safety/safeWriteText.ts, which 2385 lands; andsrc/eslint-suppressions.json's single row on this PR iscore/tools/__tests__/readFileTool.spec.tscount 96 to 94 (a decrease), which travels with the unit carrying that spec file.Nothing was pushed and no PR was opened for this plan. The cut awaits the maintainer's ruling on the printed numbers; if main moves or 2385 lands with different content the table has to be re-priced before the first split PR opens.
easonLiangWorldedtech commentedon Nov 10, 2026
Guarded-write core chain (fws U5): current carrier state, one placement reversal we owe you an explanation for, and where this chain's routing now lives. All numbers below were read from the repository or from our own runs at the state named beside them.
Carriers. 1913 carries the BigIntStats cast and stands at head 2960636, priced unchanged from its parent at 500 changed executable lines and 192 selectors with one advisory, at its own merge base 73931fe and again at main tip 18861b2 through synthetic merge a510129fd4262ba2f50029cf59ad3db4da4c21ec, because the commit adds comment rows only. Its six required contexts read completed and success at 14:44:25Z over 20 check-runs on one page, with mutation-diff and the visual advisory also success and the reviewer still working at that read. 1914 carries the remaining five dispositions plus a pinning assertion at head 28129e1, and it is priced at 1041 changed executable lines against the 500 limit at its own merge base 5319fe9 and at main tip through synthetic merge 1af3294e7c0a, three lines below its previous head and still more than double the cap. The overage is a routing question we cannot answer with more commits on that branch, and we would rather you tell us which split boundary you prefer than have us guess a third time. Both carriers still need an approving review from a code owner, which is yours to give.
Placement reversal, stated plainly because we asked for it. We had placed the guarded-write test and extractor fixes on 1914 only and answered 2383's matching threads by pointer, on a consequence we drew from earliest-lands-first with earliest-carrier-owns plus the recommendation recorded on this issue to keep 1914's versions. The automated reviewer disagrees with that in three places on 2383, asking on 4525470987 that if 2383 proceeds the fix be brought into that PR and leaving its thread open for now, asking on 4525471078 for the assertions at head 1f656e3, and noting on 4525471113 that the inline extractor is still at src/utils/fileLock.ts:82, while its head review 5842693398 prints Actionable comments posted: 7 against 0 of 7 threads reading unresolved. We are treating the reviewer's recorded request as outranking our inference and porting the same blobs into 2383, so that whichever of 1914 and 2383 merges first leaves no content difference for the other to rebase around.
Separately, on 2383 the only red check is knip, and 2383: its only red check is knip, and the mechanism is measured rather than assumed. The log shows the repo's own policy test passing 8 of 8, knip in development mode printing no issues, and knip --production printing Unused files (1) naming src/services/file-safety/safeWriteText.ts, the publish primitive the unit adds, because at that head the file has 148 references inside tests, 8 self-references and 0 production importers, its consumers being 2359's content. Toggling only the config with the tree fixed reproduces the failure and clears it. knip.json is the same blob 1f4956faa6cc789a34d0d2d0e9f4397ce0ca1bc6 at the head, at the PR base and at the tip, so refreshing onto main cannot fix it, and the fix is the one entry declaration the sibling 2385 already shipped at fc2dc75, which prices 0 changed executable lines and 0 selectors and leaves the mutation row at its 386 lines and 119 selectors unchanged.
Issue 2409, Handle orphaned backup cleanup on safeWriteText failure, was opened by the reviewer at our request when we accepted its offer of a follow-up; it has no assignee because assignment is yours to make, and we intend to take it once the two carriers above are through. From this round this chain's routing is posted here on 2020 rather than on the vps2 tracking issue 1992, which is where it had been sitting: 1992 carries vps2-chain routing plus the gate semantics that apply to every chain, 2020 carries this chain's per-carrier routing, and the abort-signal work in 1291 has no tracking issue of its own so its routing now sits on that PR. Nothing about those placements changes the measurements in the shared gate sections on 1992.
Follow-up on the placement reversal named above, published by this comment's own edit, because it has shipped and because two readings explain numbers a reader will otherwise misread. 2383 now carries the port at head 3caf4db, 4 files at 96 additions and 14 deletions, and each staged file is byte-identical to the blob in 1914's commit 28129e1, fileLock.ts 7d1682338503, fileLock.spec.ts ceb1388e1983, fileLock.canonicalKey.spec.ts f5725de15348 and safeWriteText.spec.ts 68fc6e68001b, by git hash-object against git rev-parse of that commit at each path, so whichever of the two carriers merges first leaves the other a content-free rebase. The port did not widen the carrier past the gate: the same instrument prices extension at 383 changed executable lines and 119 selectors with 0 advisories at merge base e487cd7 and the same 383 and 119 at main tip 18861b2 through synthetic merge 8b63e26c119948cfd6fc8240e4870e07e4f0df30, three lines below the 386 measured at the previous head and inside the 500 limit. Replies went to the three asks 4525470987, 4525471078 and 4525471113 with line numbers re-derived from the head blobs, and no thread resolve was needed, since all three read isResolved true before any mutation was considered.
Two readings readers should not misread. The reviewer's review job for 2383's new head returned completed and skipped, and its own saved wording ties auto review to label configuration, so no new verdict or actionable count will appear on that PR for this head unless a human requests a review: the 7 printed by review 5842693398 at 2026-11-10T13:34:13Z, and the changes-requested verdict that row carries, will stay visible while all 7 of its threads read resolved, which is the state at 15:14:50Z. Dismissing it or pushing something to make the counter move are both things we have ruled against doing ourselves, a no-op push would re-enter the review budget and re-run the matrix, so this one is genuinely a reviewer or maintainer action. The second reading is that the resolvedBy attribution on those threads moved between two reads in the same round, 6 to the campaign account and 1 to the reviewer at 14:49:29Z, then 3 and 4 at 15:14:50Z, with no thread mutation run by the lane between the reads, its three writes being replies, so the automation moved those resolutions itself and we report the observation without inventing a mechanism for it.
On 1913 the reviewer's newest row with a body is 5843751481, COMMENTED at 2026-11-10T14:45:23Z, 8,467 bytes across 203 rows, and the string that prints an actionable count appears 0 times in it, so that row posts no live ask even though it opens with a failed pre-merge checks block naming Regression Evidence; 43 thread rows exist on that PR and 18 read unresolved. We are treating the verdict as COMMENTED, reproduced from the newest row that carries one, and answering the named pre-merge item with the test rows that cover the behaviour rather than with a restatement, and we will say here which rows those are.