backlog: file #1264 -- the clock fires on cadence but its fanout skips seats - #397
Merged
Conversation
…is not Filed on the owner's instruction. Number allocated atomically via alloc.ps1 (#1264, claimed by this worktree); no number was grepped for. THE NUMBERS ARE IN THE ITEM BODY, NOT BEHIND A POINTER, and that is deliberate. The working for this lived under mefor-coord/handoffs/, which is NEVER COMMITTED, so an item citing it would resolve to nothing for every later reader. That exact failure was measured live today: a claim note aimed at a handoff file that had been renamed away, with nothing validating the pointer, so nothing reported it. WHAT THE ITEM CARRIES: the clock fired 112 times at a ~10.0 minute cadence and was never late, while recipients per firing ranged 1 to 11 with a MEDIAN OF 2 and 53 of 112 firings reached exactly ONE seat. Both innocent explanations are refuted with their measurements -- roster growth fails because the count collapses AND recovers, and seat death fails because one seat sent 28 messages inside its own 60.1-minute gap, one of them 28 seconds before a firing that skipped it. THE DISCRIMINATOR IS ONE DIVISION AND IT TOOK THREE SEATS A DAY TO FIND: a gap that is an exact multiple of the cadence means the clock fired and you were skipped; a ragged gap is a real gap. From inside a single seat those two are the same observation, which is why nobody could see it alone. TWO FIXES WITH DIFFERENT OWNERS, stated separately so one does not absorb the other. The second is the one that matters: THE TICK'S OWN RUBRIC says a gap over ~15 minutes means the chain is broken, so every seat looked at the CLOCK and nobody looked at the ROSTER. An instruction naming the wrong subject turned a fleet-wide defect into eleven private ones. BASED ON THE LEDGER BRANCH, NOT MAIN, ON PURPOSE. #1260-#1263 are unmerged there, and both this item and those append to the same end of the same file -- basing on main would have manufactured a conflict in the tail of BACKLOG.md. Verified: status check OK at 529 items each declaring exactly one status; 27 insertions, 0 deletions; U+26A0 count UNCHANGED at 121, so no new glyph vocabulary enters the one file with a machine-parsed alphabet.
wshallwshall
enabled auto-merge (squash)
August 14, 2026 20:33
…D, add two more skipped seats THREE AMENDMENTS, none of them cosmetic: 1. THE COUNTS ARE A FLOOR, NOT A CENSUS, and the bias runs the wrong way. They come from DELIVERED MAIL FILES, so a firing written but never enqueued is invisible to the instrument. The defect is UNDER-DELIVERY and the instrument can only UNDER-COUNT -- biased in the SAME DIRECTION as the defect, so these numbers cannot bound the problem from above. Written flat they read as how bad it is; they are how bad it is AT LEAST. 2. THE DOC HALF IS ALREADY FIXED and the item now says so rather than asking for work that exists. seat-tick.ps1 now tells a seat to divide a long gap by the cadence before naming a cause. Recorded with its positive control. 3. TWO MORE SKIPPED SEATS, one of them the seat that OWNS the clock, measured from a RECEIVER's transcript rather than from delivery files -- an independent instrument, not a second look at the same one. Plus the smallest skip yet: ONE firing, bracketed by activity 60 seconds later, which a reader cannot dismiss as an outage. AND THE QUALIFICATION'S OWN TRANSIT FAILURE IS NOW IN THE ITEM. The bound was destroyed by the mail length cap, truncated MID-WORD on the caveat, so two seats relayed the figures flat. A cap bites at the END of a message, which is exactly where a caveat sits.
THE PREDICTED TAIL CONFLICT, resolved. #395 landed #1260-#1263 while this branch carried #1264; both append to the same end of docs/BACKLOG.md, so git saw two independent versions of the tail. Resolution is genuinely KEEP BOTH -- distinct items, no shared lines -- ordered ascending: #1260-#1263 then #1264. MY FIRST RESOLUTION SILENTLY DROPPED #1260 AND THE STATUS GATE PASSED ANYWAY. I split the conflict with a regex on the '=======' separator. A bare '=======' also occurs in ordinary content, so the regex matched the WRONG separator, clipped the region, and lost an item -- and backlog_status_check reported OK at 528 items each declaring exactly one status, because a file missing one item is still internally consistent. A CONSISTENCY GATE CANNOT SEE A DELETION. Re-done POSITIONALLY: locate the three marker LINES by prefix, slice by index, and concatenate. Verified after: 293 items, #1260-#1264 all present, zero duplicate numbers, zero line-anchored markers. AND THE VERIFICATION REPEATED THE SAME BUG ONCE MORE -- my marker count used raw.count('=======') and reported 3 remaining when the true line-anchored count was 0. Same substring-versus-line-structure error, inside the check written to catch it.
… item's scope Every gap in the item was quantised. Two seats then recorded RAGGED gaps in the same window -- 46.8 min (residual 0.32) and 36.8 min (residual 0.68) -- so by the item's own discriminator those are real chain gaps, NOT fanout skips. THE DIAGNOSTIC IS THAT THE TWO DIFFER IN LENGTH AND AGREE ON THEIR END. Both terminate at ~20:58 and the tick PHASE moved with them: every firing that day landed 9-16 seconds past the minute, that one landed at 02. Different durations converging on one resume instant is a SCHEDULE RESTART, not a selection skipping people -- a skip leaves each seat's gap an exact multiple of the cadence. RECORDED AS OUT OF SCOPE ON PURPOSE. Without it, a later reader holding one ragged gap attaches it to this item and concludes the fanout defect is broader than measured; worse, a fanout fix gets credited with curing a restart it never touched. Nobody has confirmed what restarted, and the coincidence with a ~20:15 hook edit is named rather than claimed. MY OWN CENSUS NEARLY DID NOT HAPPEN: my first pass counted ZERO tick messages in a box holding 39, because I read a 'sent' field where the schema says 'createdUtc'. Pattern fine, field absent -- re-reading the code finds nothing, and only dumping the record's keys shows it.
…minator has a limit TWO AMENDMENTS, both from seats reporting against their own work. 1. THE RAGGED GAP WAS NOT A RESTART. Its author confirmed it: they edited the tick body to 3395 chars against mail.ps1's hard 2000-char cap, so every send returned FAILED(queued=0) and NO seat received anything for ~29 minutes. Firings were attempted and nothing was enqueued -- a real break in the chain, which is what RAGGED means. THE DISCRIMINATOR CLASSIFIED IT CORRECTLY WITHOUT KNOWING THE CAUSE, which is the strongest thing that can be said for it. Their verification could not have caught it: they checked the file PARSED and carried NO GLYPHS, and both passed. Neither check can see a runtime length limit enforced by a different script. Their first fix also failed -- 2314, still over -- and they only knew because they FIRED THE CLOCK AND READ THE HEARTBEAT rather than trusting the edit. 2. THE DISCRIMINATOR NEEDS THE CADENCE AS AN INDEPENDENT INPUT, and a skipped seat cannot derive it from its own ticks -- its samples are exactly the firings that survived selection. A heavily-skipped seat computing a cadence from its surviving gaps classifies real skips as ragged and concludes the chain is broken. Take the cadence from the fleet-wide census. Surfaced by a seat whose 36.80 min fits no grid anchored at either of its own prior ticks. My own previous amendment called this a schedule restart and named a hook edit as a coincidence rather than a claim. The hedge held; the mechanism was different.
…tead of discarding gaps CORRECTS MY OWN PREVIOUS AMENDMENT, which said to treat ragged gaps as a separate mechanism and exclude them. That is right about the CLASS and wrong as a FILTER. A seat's 56.75 min gap is a MIXTURE: the ~20:11 and ~20:21 firings happened while the clock was HEALTHY and it received neither -- two genuine fanout skips -- concatenated with the outage. Neither class alone produces 56.75. SO RAGGED IS WEAKER THAN IT READS. Once two causes can concatenate, a ragged result means NOT PURELY QUANTISED, not A PURE CHAIN BREAK. AND THE FILTERING RULE MATTERS MORE THAN THE LABEL: clip each gap to the outage window and classify the remainder. Discarding any gap that merely STRADDLES the window absorbs real skips into it and drives this item's count DOWN -- and the count is already a floor, so every absorption makes an under-measurement worse. TWO MORE, both from seats correcting themselves: - MEASURE CADENCE ON SEND TIME. The same clock read broken on delivery time and 10.0 min on send time. A capped, queued channel turns a regular sender into a ragged-looking one at the receiver. - THE DISCRIMINATOR WAS VALIDATED BLIND: three seats classified their own gaps before the outage was disclosed, and each sorted correctly. A rule that works for a reader who does not know what they are looking at beats one confirmed by its own author.
…ame their own falsifier THREE ADDITIONS, all of which make the item harder to dismiss rather than easier. 1. ROBUST TO THE COUNTING RULE. A fan-out stamps recipients seconds apart, so grouping by MINUTE could split one broadcast across a boundary and MANUFACTURE this defect's signature. Re-measured by 30-second clustering: 113 firings vs 112, 53 single-recipient firings either way, median 2 either way. Two independent rules, one answer. That closes 'your census split a broadcast' before it is raised. 2. THE CENSUS IS ON SEND TIME, not delivery time -- sender-stamped createdUtc. This is the other obvious attack, and it matters because the SAME clock read broken on delivery time and 10.0 min on send time. A capped queued channel makes a regular sender look ragged at the receiver. 3. THE MIXED-MODE READING NOW NAMES ITS OWN FALSIFIER: it assumes firings occurred at ~20:11 and ~20:21, taken from the clock-owner's 'last good tick' and NOT verified against the heartbeat by anyone who read the source. If those never fired, two skips come off the count. The third is the one I would keep. An item that states what would refute it is worth more than one that only accumulates agreement -- and five seats agreeing is exactly the condition under which nobody looks for the refutation.
… directions The divide-by-ten rule assumes every firing sits on the cadence grid. A manual live-fire or recovery test does not, so the gap BEFORE it reads ragged and the gap AFTER it -- to the next scheduled firing -- can fall under the ~6 minute floor and read as OVER-FIRING, which the rubric calls the expensive fault. Neither is true. Second-order form of the defect this item is about: a rule answering exactly the question it was given, on data violating an assumption nobody wrote down. The recovery fire went to nine seats, so up to nine could each hold a short gap the rubric tells them to escalate. Raised by the seat that supplied the divide-by-ten rule, against their own rule. RECORDED AS UNCORROBORATED ON PURPOSE. This seat's next tick had not arrived when the amendment was written, so the claim rests on arithmetic rather than on a second observation -- and the item says so rather than borrowing confidence it has not earned. Five seats already agree on the main finding, which is exactly when an unverified addition slides in unchallenged.
…a fanout skip CORRECTS THIS ITEM'S OWN CENTRAL CLAIM, and the correction came from the tick text rather than from any seat defending the item. I wrote that a quantised gap means the firing happened and YOU WERE NOT ON THE LIST. That is one of TWO causes. A fanout skip and a FAILED SEND are indistinguishable from the receiver -- in both cases the firing happened and nothing reached you. THE 36-MINUTE OUTAGE IS THE PROOF THAT THE SECOND CASE IS REAL HERE: the scheduler ran perfectly and every send returned failure. It presented as RAGGED only because it ended on a manual recovery fire. HAD IT ENDED ON-GRID IT WOULD HAVE BEEN QUANTISED AND COUNTED AS FANOUT EVIDENCE. So the counts bound a DELIVERY fault, not specifically a ROSTER fault. The fanout hypothesis is still the best lead -- it explains the collapse-and-recover shape and the stable core of always-reached seats, which a send failure does not -- but the measurement does not exclude send-side failure and this item must not be read as having done so. Separating them needs the SENDER's per-firing result, which nobody has read. Five seats corroborated the observation and none of us questioned the label on it. The tick's own rubric did.
wshallwshall
disabled auto-merge
August 15, 2026 06:02
wshallwshall
added a commit
that referenced
this pull request
Aug 15, 2026
Resolves the docs/BACKLOG.md append-collision between this branch's filings (#1269-#1272) and #1273, which reached main via #404. The conflict was a pure append collision: both sides only ADD items at the tail, zero deletions on either side, so no resolution could lose content and the only decision was ordering. 1269-1272 precede 1273, so keeping HEAD then main is already ascending -- the resolution is the removal of the three conflict markers and nothing else. Verified after resolving: conflict markers remaining 0 items present 1268, 1269, 1270, 1271, 1272, 1273 -- all six, one each order strictly ascending at the tail backlog_status_check OK, 537 items, each declaring exactly one status link_check OK, 5418 relative links resolve dangling_citation_check exit 0 backlog_citation_check exit 0 The four allocations (#1269-#1272) belong to this worktree, which is why this branch has a legal commit path at all -- unlike #397, whose allocation is held by a dead worktree with no transfer path in alloc.ps1. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
wshallwshall
added a commit
that referenced
this pull request
Aug 19, 2026
owns() (ledger_check.py:219-231) compares the current worktree path to the one recorded at allocation, with no fallback when that directory is gone. Ownership is non-transferable, so an orphaned number can never be satisfied again. PR #397 is stranded by this now: #1264 was allocated by a worktree that no longer exists, is not on main, and #397's only conflict is docs/BACKLOG.md. Resolving re-introduces a heading absent from main, which counts as an addition, so ownership is consulted and refuses -- for everyone, permanently. The gate is failing closed and is correct. The defect is that there is no route back, and that the refusal only arrives after the resolution work is done. Records three candidate routes without picking one, and notes the fix must not be "widen the gate" -- the --ci leg already skips ownership by design. Also records the operational sweep that falls out: before removing a worktree, check whether it owns an allocation not yet on main. Run against the 16 worktrees proposed for removal today; returned zero, with #1264 as the positive control proving the sweep can detect the class. The first draft named a worktree slug and the forbidden-content gate refused it. Rewritten generically rather than allowlisted, per the rule that a refused slug is the gate working.
wshallwshall
added a commit
that referenced
this pull request
Aug 19, 2026
…nd a latent NULL unroll (#449) * backlog: file #1290 -- the connscale CPU-probe walk times out on hosted Windows runners A required status check is intermittently red on main. CI run 32255231838 at de896e0 failed `test (windows-2022, py3.14)` on test_subtree_re_resolution_picks_up_a_late_spawned_child: the process-table walk returned None on all 6 attempts in 30s. The identical leg passed on PR #448 in the same hour on the same runner image, and neither branch touches the probe, so the nondeterminism is measured rather than assumed. The assertion that fires is the one the test's author separated out as an environment problem, so the re-resolution assertion below it never runs -- the test is silent on the defect it exists to catch exactly when this fires. Filed distinct from #1014 (a fixed port-block collision in the smoke test) and #1210 arm 2 (FD/RSS provenance in the same probe). parse_items before/after: 306/226 open -> 307/227 open, the expected +1/+1/0 for filing one item. * backlog: file #1291 -- Get-HandledTools unrolls to NULL on two paths Measured in pwsh 7 via AST extraction: missing-file and zero-tool both return NULL; one tool returns a bare String, so .Contains() answers True on a substring of it. Filed as a LATENT trap, not a live defect. The single caller wraps in @(...), so shipped behaviour is correct today and a present-tense bug claim would be false. Recorded that way deliberately. Two details that decide how it gets fixed and tested: the missing-file early return unrolls the same as the tail, and that path is the normal one on a box where the gate was never installed; and a test through -Status cannot discriminate fixed from unfixed because the caller re-wraps, so the test must reach the function by AST extraction -- install-gate.ps1 cannot be dot-sourced without performing a machine-global install. parse_items 307/227 open -> 308/228 open, the expected +1/+1/0. * backlog: record #1290's same-head rerun confirmation Re-running the failed job alone on PR #447 head 4ccbf81, with no code change, returned completed/success. Identical commit, identical leg, opposite outcome, which settles nondeterminism more directly than the cross-branch pair the item was filed on. Bounded deliberately: it establishes that the failure is not a property of the tree under test, and establishes nothing about frequency or the runner load that triggers it, which is what sizing a fix actually needs. parse_items unchanged at 308/228 open, the expected 0/0/0 for amending a body. * backlog: file #1292 -- connscale smoke reports an acked message unobserved at intake The assertion names a CONFIRMED send that engine_read did not see. The harness already excludes the benign case in the same message (a send with no ACK before close is explicitly not counted as loss), so the remaining branch is either a harness reconciliation race or a count-and-log invariant failure. Filed because nobody has separated those two, and they have very different severities. Calling it a flake picks the comfortable branch without evidence. Red on main (run 32255231838, windows-2022) and on PR 448's rebased head (run 32259244062, ubuntu-latest), with different record shapes -- two platforms, two branches, which is evidence against a single fixed off-by-one. It already carries flaky(reruns=2) and failed anyway, so it exhausted its retries. Kept distinct from #1014 (port-block collision, same file) and #1290 (CPU-probe walk timeout, same suite). Two of the three sit inside required contexts, which is why the queue keeps stalling. Severity written in the conditional per CLAUDE.md section 0: zero instances, so nothing is affected today. P1 rests on the branch not yet ruled out. parse_items 308/228 -> 309/229, the expected +1/+1/0. * backlog: file #1293 -- worktree removal orphans unlanded ledger numbers owns() (ledger_check.py:219-231) compares the current worktree path to the one recorded at allocation, with no fallback when that directory is gone. Ownership is non-transferable, so an orphaned number can never be satisfied again. PR #397 is stranded by this now: #1264 was allocated by a worktree that no longer exists, is not on main, and #397's only conflict is docs/BACKLOG.md. Resolving re-introduces a heading absent from main, which counts as an addition, so ownership is consulted and refuses -- for everyone, permanently. The gate is failing closed and is correct. The defect is that there is no route back, and that the refusal only arrives after the resolution work is done. Records three candidate routes without picking one, and notes the fix must not be "widen the gate" -- the --ci leg already skips ownership by design. Also records the operational sweep that falls out: before removing a worktree, check whether it owns an allocation not yet on main. Run against the 16 worktrees proposed for removal today; returned zero, with #1264 as the positive control proving the sweep can detect the class. The first draft named a worktree slug and the forbidden-content gate refused it. Rewritten generically rather than allowlisted, per the rule that a refused slug is the gate working.
Resolves the docs/BACKLOG.md conflict. One hunk, both sides pure appends: #1264 on this branch, #1265-#1293 on main. The file is in ascending numeric order, so keeping both sides in the order they already appeared is both the correct resolution and the ordered one -- only the three marker lines were removed. Verified against arithmetic rather than by eye. merge-base was 292 items / 212 open; this branch 293/213 (it adds exactly #1264); origin/main 310/230 (it added 18). So a correct resolution is exactly 311/231, and parse_items reports 311/231. This is the commit BACKLOG #1293 says nobody could make. The worktree that allocated #1264 had been removed, and ledger_check's owns() is a bare path comparison against the recorded worktree with no fallback, so ownership could never be satisfied again and the conflict was unresolvable by anyone. The worktree was recreated at the recorded path, which restores the referent the comparison is against rather than weakening the check.
wshallwshall
enabled auto-merge (squash)
August 19, 2026 14:28
wshallwshall
added a commit
that referenced
this pull request
Aug 19, 2026
…was tested and works (#450) * backlog: file #1294 -- no cleanup path for the worktrees the prune tool must not touch Measured on this clone: 36 registered worktrees, 11 reachable by prune-merged.ps1, 12 under .claude/worktrees and 13 others excluded. 30 percent reachable. The owner removed 12 of the excluded ones by hand the same day, from a list assembled manually, because nothing produces that list. Filed explicitly as NOT a coverage bug. The exclusions are deliberate: that directory is where EnterWorktree relocates live sessions, the tool once removed an occupied worktree and left a directory git no longer recognised, and its header records the resulting bias as fixed and not negotiable. The defect is the missing middle. Today a worktree is either removed by the tool or invisible; nothing says "these look finished, here are the commands, you decide". Proposes a REPORT-ONLY extension rather than a wider fence, because the occupancy fence's own receipt records a 29 percent blind spot in one of its two signals. Automating deletion of the directory live sessions occupy, behind that fence, would trade the property the incident bought. Also records that worktree_gate.ps1's refusal should NOT be relaxed to close this -- the reporter makes the refusal cheap to live with, which is the correct order. parse_items 310/230 -> 311/231, the expected +1/+1/0. * backlog: record that #1293's route 1 was tested on the live instance and works Owner-directed. Recreated the worktree at the exact path recorded in #1264's alloc claim, resolved PR #397's conflict there, and committed from it. The ledger gate reported Passed on a commit that could not have been made from anywhere else, and #397 went DIRTY to MERGEABLE. Bounded deliberately: this confirms the mechanism (owns() compares a path string, so restoring the path restores the referent) and settles nothing about whether it should be the documented remedy -- it stays adjacent to the rename-workaround CLAUDE.md section 5 forbids. The distinction kept in the item is that it restores the condition the gate tests rather than bypassing the test. Also records two things a repeat must not skip: worktree add -B resets the local branch (here from 91a2406, verified to be an old main commit reachable from many refs before the reset was accepted), and the ledger conflict was resolved against a computed target -- 292/212 base, 293/213 branch, 310/230 main, so only 311/231 is correct, which is what parse_items returned.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Files #1264 on the owner's instruction: the seat clock's cadence is healthy and its fanout is
not, and the tick's own rubric is why nobody found it for a day.
Number allocated atomically via
alloc.ps1(#1264, claimed by this worktree). No number wasgrepped for.
The numbers are in the item body, not behind a pointer
The working for this lived under
mefor-coord/handoffs/, which is never committed -- so an itemciting it would resolve to nothing for every later reader. That exact failure was measured live
today: a claim note aimed at a handoff file that had been renamed away, with nothing validating the
pointer, so nothing reported it.
What the item carries
Both innocent explanations are refuted with their measurements. Not roster growth -- the count
collapses and recovers (
10,10,10,10,9,11,11then2,5,3,3,6,2,2,2then back to10..11). Notseat death -- one seat sent 28 messages inside its own 60.1-minute gap, one of them 28 seconds
before a firing that skipped it.
The discriminator is one division, and it took three seats a full day to find it: a gap that is an
exact multiple of the cadence means the clock fired and you were skipped; a ragged gap is a
real gap. From inside a single seat those two are the same observation, which is why nobody could see
it alone.
Two fixes, different owners, stated separately
seat looked at the clock and nobody looked at the roster. An instruction naming the wrong
subject turned one fleet-wide defect into eleven private ones.
Sequencing -- read before merging
This is based on
main, deliberately, and it CONFLICTS with#395's branch. Measured,rcreadbefore content:
Both append to the same end of the same file. Basing on
#395's branch instead was tried firstand the ledger gate rejected it: the gate attributes every item not on
mainto the committingworktree, so
#1260-#1263read as unallocated-to-me. A second seat cannot base ledger work onanother seat's unmerged ledger branch.
⇒ Land
#395first. This branch then needs an update-branch whose conflict resolution isgenuinely keep both -- two independent appends of distinct items, no shared lines.
Verified