Repository navigation
Tracking fws U6: apply_patch publishes through the guard #2021
Description
What this unit delivers: the apply_patch tool publishes through the guard; a move carries the source's completeness to its destination instead of claiming completeness for lines the model never read; a partial-source move onto an already-observed destination is rejected before any state changes. It also rolls back the parent directories saveDirectly created when the guard refuses the publish.
Why it matters: patch hunks are the easiest way to "write" a file the model never fully read; routing them through the guard closes that hole.
Implemented by: PR #1915 (branch fws/u6-apply-patch-wiring).
Acceptance:
apply_patchpublishes viaguardedWrite; an unobserved overwrite and a stale version token are refused with the standard remediation.- A move inherits the source's
completeflag; a partial-source move onto an observed destination is refused pre-state-change. saveDirectlyremoves the directories it created (innermost-first,rmdirrefuses a populated directory) and rethrows the original error.
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
Queue gate line for this tracker entry (#1915, a71761a).
What the gate was: this entry waited on the same two answers - #1912 and #1914 - for the same reason: #1915's asking rows are dispositions by deferral, and the unit they defer to had to be triaged before the deferral meant anything.
The gate is cleared on my side, by the same reads as the #2023 line: #1912 answered at head 9d420ad in comment 6744486462 (2026-11-09T15:52:00Z, GitHub), #1914 answered by this account with its latest pre-existing review-comment entry id 4512376064 created 2026-11-09T11:48:16Z. #1915's four rows were answered today in comment 6744493793 (4,680 B, 15:52:18Z), with a correction to one sentence of mine in comment 6744527446 (623 B, 15:53:46Z).
What still gates this queue position: three of the four rows (guardedWrite.spec.ts:696, :801, :965) want the same FIFO-serialisation and pending-reset scenarios that #1916's two rows want, in the same three-copy file named in the #2023 line, and they are one change owed once in #1914's copy 32ab04c7c054 at 7209a5f, not three changes in three copies; the fourth row (ApplyDiffTool.ts:256) is routed to #1916's copy 0de4b3a30290 at da2b913 because routing the diff-view save through the guard is #1916's subject, and a version binding written into #1915's copy 6e59d8c7ee2e would give one guard two designs. Counted lines for #1915 are CI's printed 1,821 against the 500-line cap - CI's number, not a measurement of mine - and the standing stack rule still applies to whatever comes next: no second main-side pull request against the same four CODEOWNERS named in .github/CODEOWNERS while the first is open. Nothing was pushed and nothing is being asked of anyone by this comment.