loki-mode 9.55.0 → 9.57.0

package/docs/v10/PROGRESS.md

@@ -304,3 +304,896 @@ judgment D12 exists to not leave to the person making the change. Speed
 under CONTROL.md's priority order is real but ranks below moat and
 delivered accuracy -- a quorum skip trades a process guarantee for time
 saved, which is backwards per the stated priority order.
+
+### Self-caught: rapid single-line pushes were starving CI (2026-09-27)
+
+After v9.55.0 shipped, I pushed roughly 20 single-line BOARD.md status
+updates in quick succession over about 75 minutes, one per review
+result as it landed. `gh run list --workflow Tests` showed the obvious
+consequence: every one of those pushes cancelled the previous push's
+in-flight Tests run, so main had NO green CI verdict the entire time --
+the exact same "pushing during a release cancels its Tests" failure
+mode already recorded as a standing lesson, just recurring post-release
+instead of mid-release. Caught by an advisor consultation, not by
+noticing it myself; the pulse's own `Main CI: PENDING` line had been
+printing unchanged for over an hour and I had not connected that to my
+own push cadence.
+
+Also caught in the same pass: the pulse's "106 commits since v9.54.2"
+reading, 90 minutes after v9.55.0 shipped, was not a pulse bug -- it
+was a stale local `git fetch --tags`. Fixed by fetching; filed BACKLOG
+136 so the pulse itself can detect this class of staleness going
+forward. And BOARD.md had 5 rows (S-02, S-14, S-16, S-18, S-20) stuck
+at a phantom `building@01:33Z` status with no live agent or
+identifiable worktree behind them -- an artifact of the earlier bulk
+timestamp normalization pass, never individually re-verified since.
+Reset to `ready` (or `blocked` where a real dependency exists). S-37
+turned out to duplicate GF-3 (same BACKLOG item, same files) and was
+parked rather than run in parallel. GF-3's own note cited a "Captain
+step 6" validation-PR process that does not exist anywhere in the
+actual docs -- corrected, and D22 recorded under the founder-unavailable
+clause: release.yml changes ship alone, watched to green, until a real
+process for this is written down.
+
+Lesson: a batch of small, individually-justified pushes is still a
+push-storm from CI's point of view. From here: one batched commit per
+turn for hot-file status updates, and no second push to main until
+the previous push's Tests run has actually finished (checked directly,
+not assumed).
+
+### Drift audit (turn 12, 6-hour window)
+
+**Matched CONTROL.md:** the priority order held under real pressure --
+GF-3 was not merged until its dist-staleness gap (a genuine moat/seal-
+accuracy issue two reviewers independently found) was fixed and
+re-verified, even though that delayed a release the velocity targets
+already flagged as overdue. D12's unanimous-APPROVE bar was honored
+throughout (S-09 and S-17 both went through full rework rounds rather
+than merging on a split quorum); D21's bucket-(a)/(b) split correctly
+kept 4 real-but-out-of-scope findings (BACKLOG 138-141) from blocking
+GF-3's merge.
+
+**Drifted:** 1 release in the 6-hour window against a 90-minute target
+(should be ~4); 42 of 68 commits in the window are docs-only BOARD.md
+status updates, several of them small enough that a single rapid-push
+sequence measurably starved CI of a green verdict for over an hour
+(self-caught and corrected earlier this window, see above). Velocity
+targets (8+ ready slices, 6+ active builders) have been in violation
+most of the window, though slices ARE moving through review at a real
+rate, just not fast enough to keep the ready queue full.
+
+**Correction for the next 6 hours:** batch BOARD.md status writes to
+at most one per completed review/merge event (not one per individual
+reviewer verdict as they land), and prioritize dispatching NEW builders
+over writing status prose whenever the ready queue is below 8 -- the
+IDLE_BUILDERS/LOW_READY violations have been sitting un-actioned for
+multiple pulse ticks in a row while review-processing consumed the
+turn instead.
+
+### Drift audit (turn 18, 6-hour window)
+
+**Matched CONTROL.md:** review rigor held -- S-16's real CONCERN
+(mktemp/mv silently narrowing 14 tracked files from 644 to 600 on
+every release) was not waved through; rework was dispatched instead
+of overriding on a split quorum. D22 (release.yml ships alone,
+watched to green) was honored for GF-3. The moat's shrink-only
+ratchet (D2) was respected: S-02's merge knowingly reintroduced a
+real P7 regression (BACKLOG 137) and the response was an urgent
+same-window fix (S-39), not silently accepting a worse baseline.
+
+**Drifted:** the turn-12 correction did not measurably take. Docs-only
+BOARD.md commits are 41 of 68 in this window, versus 42 of 68 last
+time -- essentially unchanged despite the stated correction to batch
+them. Zero releases shipped in this window (still the same v9.55.0,
+now ~187 minutes old), so NO_RECENT_RELEASE has now been a standing
+violation for the entire turn-12-to-turn-18 span, not just spiking
+once. IDLE_BUILDERS did clear this turn (5 ready slices dispatched:
+S-29 through S-32 plus the GF-4 rebase), showing the "prioritize
+dispatching" half of the correction DID work when applied -- the
+BOARD-batching half did not.
+
+**Correction for the next 6 hours:** stop writing an individual
+BOARD.md commit per reviewer nudge or status check -- fold status-only
+edits into the same commit as the next real merge/rebase action, even
+if that means BOARD.md briefly shows a slightly stale state between
+events. Treat NO_RECENT_RELEASE as the standing top-tier violation it
+now is: once S-16 rework, S-39, S-14, S-20, S-36, and GF-3/GF-4's
+CI checks are confirmed green, cut a release immediately rather than
+folding one more slice in first -- the queue will refill after.
+
+### Drift audit (turn 30, 6-hour window)
+
+**Matched CONTROL.md:** the moat's shrink-only ratchet held under a
+genuine live incident: S-39 fixed a real regression S-02 introduced
+(BACKLOG 137) rather than quietly reclassifying the case as pending.
+S-40 found a second real, more severe Rule-of-Two gap mid-build
+(BACKLOG 142, a bare `Bun.spawn` bypassing the GH-token withholding)
+and stopped to ask before widening scope rather than silently
+expanding or silently shipping a known-red case as pending -- correct
+per D21 and per the founder-unavailable-clause discipline.
+
+**Drifted, and this is new:** a genuine CI health incident. The Tests
+run triggered by the last push hung on "Shell tests (shard 2/4)" for
+23+ minutes against a configured `timeout-minutes: 20`, well past
+GitHub's own enforcement point, while every other shard/job on the
+same run finished in under a minute. Cancelled manually and a fresh
+push retriggered a clean run. Docs-only commits are still 44 of 72
+(61%) this window, WORSE than both prior audits (42/68, 41/68) despite
+two consecutive corrections asking for batching -- the correction is
+not taking, likely because status updates keep getting written
+reactively per-notification rather than being queued and batched
+deliberately.
+
+**Correction for the next 6 hours:** (1) if a shard/job exceeds 1.5x
+its configured `timeout-minutes` without GitHub's own enforcement
+firing, cancel and re-push immediately rather than waiting out a full
+timeout cycle -- don't treat "still in_progress" as automatically safe
+to keep waiting on. (2) Actually hold BOARD.md edits in memory across
+multiple background-task notifications and write ONE commit per
+review-cadence checkpoint (roughly: after every 2-3 notifications, or
+before any push), instead of committing after each individual one --
+the first two corrections described the right policy but execution
+kept reverting to one-commit-per-event under notification pressure.
+
+### Stalled-agent incident (turn ~35)
+
+Two dispatched reviewers (S-09 round 3 reviewer 2, S-27 reviewer 1)
+were listed as "running" for 2-3+ hours with zero real progress --
+`ListAgents` reported them active, but their transcripts' last
+timestamped event was over 2 hours stale in both cases (confirmed by
+reading the actual transcript timestamps, not trusting the "running"
+status label). Both were killed via `TaskStop` and replaced with fresh
+dispatches instructed to work efficiently and stop-and-report rather
+than run indefinitely if they find themselves going deep into
+tangential exploration. Correction: a background agent's listed status
+("running") is not evidence of live progress -- check its transcript's
+actual last-event timestamp against wall-clock time before assuming a
+long-running review is still doing useful work, especially once it's
+well past the review-tier's stated time budget.
+
+### Drift audit (turn 42, 6-hour window)
+
+**Matched CONTROL.md:** real throughput this window despite the raw
+docs-ratio staying flat (45/74, ~61%, essentially unchanged from the
+last two audits): S-41, GF-4, and S-09 all merged with genuine review
+rigor (S-41 unanimous 2/2 fully adversarial; GF-4's two reviewers
+independently converged on the identical commit-message defect;
+S-09's 3-round rework history is the clearest example this session of
+the anti-sycophancy discipline working as designed). S-40 surfaced a
+real production Rule-of-Two credential leak (BACKLOG 142) mid-build
+and stopped for a scope decision rather than silently expanding or
+silently shipping a known-red case as pending -- exactly right per
+D21. S-29's rework was dispatched on a genuine 2/2 CONCERN rather than
+overridden, with reviewer 2 catching a subtle bug (S-29 introducing a
+live copy of its own sibling S-30's exact defect) that a less
+adversarial review would have missed.
+
+**Drifted:** two real CI/agent-health incidents in one window (the
+Tests-run hang plus the two silently-stalled reviewers) suggests
+this class of failure is not a one-off -- worth watching for a third
+occurrence before concluding it's noise. The docs-commit ratio
+correction from two prior audits STILL has not measurably moved the
+number, though the absolute count of real merges/fixes landed this
+window (3 merges, 1 production security fix, 2 stalled-agent
+recoveries, 1 CI-hang recovery) is higher in substance than the raw
+ratio suggests -- the ratio itself may simply be a poor proxy for
+velocity in a window this eventful, rather than a real process failure
+to keep correcting against.
+
+**Correction for the next 6 hours:** stop treating the docs-commit
+ratio as the primary velocity signal -- track merged-slice count and
+real-fix count directly instead, and only worry about the ratio if
+merge/fix throughput ALSO drops. Continue the CI-health and
+agent-health vigilance from this window (checking actual job status
+and actual transcript timestamps, not just top-level run/task status)
+
+### Drift audit (turn 48, 6-hour window)
+
+**Matched CONTROL.md:** merged-slice throughput held (5 merges this
+window: S-40, S-41, GF-4, S-09, S-27, plus S-43), consistent with the
+turn-42 correction to track merges over the docs-ratio. Review rigor
+held under pressure: S-31 got a genuine CONCERN (undisclosed
+useCallback/nested-call bypasses) despite an unusually thorough
+disclosure from its builder, and rework was dispatched rather than
+waved through on "the builder was honest about most of it."
+
+**Drifted:** "Shell tests (shard 2/4)" has now hung 3 times in this
+session (BACKLOG 143, filed turn 42), always the same shard index --
+strong enough evidence now to treat this as a structural CI issue
+worth a dedicated fix slice, not just a watch-and-cancel pattern.
+NO_RECENT_RELEASE has been the standing top violation for over 4 hours
+(242+ minutes at last check) -- multiple turns correctly recognized
+this and stated intent to release, but each was preempted by a
+review/merge landing first. The stated intent has not yet converted
+to action.
+
+**Correction for the next 6 hours:** cut BACKLOG 143 as a dedicated
+ready slice (per-suite timeout instrumentation inside the shard
+runner) rather than continuing to treat each hang as a one-off. On
+NO_RECENT_RELEASE specifically: the next time CI goes green, cut the
+release BEFORE dispatching or merging anything else that turn, even if
+something else is mid-review -- the queue will still be there after.
+
+**Self-caught process gap (same session, before the next audit is due):**
+S-30 and S-32 were both marked `review@` on BOARD.md with no reviewer
+agent actually dispatched -- caught only because the pulse's
+REVIEW_STALE violation fired at the 45-minute mark for each. Root
+cause: both were part of a 4-slice sequential group (S-29/S-30/S-31/
+S-32, same file) where dispatching S-29's rework consumed the turn and
+the status line for S-30/S-32 got written as if the dispatch had
+happened, when it hadn't. Fix going forward: after writing a `review@`
+status, verify the dispatch actually happened (check ListAgents or the
+tool result) in the SAME turn, not just write the intended status and
+move on.
+
+**Third occurrence, same session, escalating this to a standing rule:**
+GF-4 was cherry-picked and merged to main (0f214c3f) but its BOARD row
+was left at `review@` -- caught again only by REVIEW_STALE, this time
+48 minutes stale. Three instances of "BOARD.md's status word says one
+thing, the actual git/agent state says another" in a single session is
+a pattern, not a fluke -- the pulse is correctly catching each one, but
+catching it after the fact means the pulse is doing verification work
+that should happen at write time. **Standing rule going forward**:
+every BOARD.md status-word edit (`review@`, `merged@`, etc.) must be
+the SAME tool-call turn as the action it describes -- write `review@`
+only in the turn that dispatches the reviewer, write `merged@` only in
+the turn that performs the cherry-pick/merge. Never pre-write an
+intended status for an action queued later in a longer turn.
+
+### Drift audit (turn 54, 6-hour window)
+
+**Matched CONTROL.md:** review rigor held under real volume this
+window -- 4 P7 scanner sibling slices (S-29/S-30/S-31/S-32) all in
+flight concurrently on the same file, and reviewers found genuine,
+adversarially-discovered gaps in 3 of the 4 (S-29's `.concat()`/
+spread bypasses, S-30's incomplete `false`/`0`/`{}` exemption class,
+S-31's `useCallback` gap) rather than rubber-stamping honest-looking
+disclosures. S-32, the one that got a clean APPROVE, earned it: its
+own reviewer independently re-implemented the substitution logic to
+verify it, not just read the diff.
+
+**Drifted:** the self-caught status-tracking-lag pattern (S-30, S-32,
+GF-4 all marked `review@` after the fact was already `merged@` or
+"never actually dispatched") is now the dominant drift signal, not the
+docs-ratio the last two audits tracked. Shard 2/4 CI hangs are now at
+4 occurrences (BACKLOG 143), all on the identical shard index -- past
+the point where "watch for a third" (turn 42's language) is the right
+framing; this is confirmed structural. NO_RECENT_RELEASE has now stood
+for over 4.5 hours despite three separate turns stating intent to
+release the moment CI goes green -- the intent keeps forming and not
+converting to action because CI itself keeps hanging before it can go
+green, which is a genuinely different root cause than the earlier
+"kept getting preempted by other merges" diagnosis.
+
+**Correction for the next 6 hours:** the standing status-write rule
+from this session (write the status in the SAME turn as the action)
+needs a companion check -- before ending a turn with a `review@`/
+`merged@` write, re-read the exact row just written and confirm the
+verb matches what ListAgents or git log actually shows RIGHT NOW, not
+what was true a few tool calls earlier in the same turn. On CI: if
+shard 2/4 hangs a 5th time, stop treating cancel-and-repush as
+sufficient and escalate to actually implementing BACKLOG 143's fix
+(per-suite timeout instrumentation) as the next ready slice, ahead of
+anything else in the queue.
+
+### Drift audit (turn 60, 6-hour window)
+
+**Matched CONTROL.md:** BACKLOG 143 was escalated to an actual ready
+slice (S-44) after the 4th confirmed shard-2/4 hang, exactly per the
+turn-54 correction's own stated trigger -- the correction converted to
+action the same window it was written, not just logged and left. The
+P7-scanner sibling group (S-29 through S-32) continued producing real
+adversarial findings on every pass: S-31's rework got dispatched with
+per-arm mutation isolation specifically because prior rounds taught
+that "the builder tested it" isn't sufficient without independent
+per-fix isolation.
+
+**Drifted:** NO_RECENT_RELEASE has now stood for over 4.5 hours (280+
+minutes). The stated root cause from turn 54 (CI kept hanging before
+it could go green) is holding: the CI run that would carry this
+release has been in flight for 10+ minutes multiple audits in a row,
+still not confirmed green at this writing. This is not a process
+failure inside this session's control -- the discipline of "wait for
+green, don't push into an in-flight run" is being followed correctly
+-- but it means the release itself remains blocked on infrastructure
+outside a swarm turn's power to fix directly, apart from the S-44 fix
+now in flight.
+
+**Correction for the next 6 hours:** no new correction needed beyond
+what's already in flight (S-44's fix, once merged, should end the
+shard-2/4 hangs and unblock the release path). If NO_RECENT_RELEASE is
+still the top violation at the NEXT audit (turn 66) with S-44 already
+merged, that would mean the hang has a second, undiagnosed cause
+worth a fresh investigation rather than continued cancel-and-repush.
+
+### Drift audit (turn 66, 6-hour window)
+
+**Matched CONTROL.md:** review rigor held at genuinely high volume --
+S-14, S-29, S-31, S-36 all got real, precisely-diagnosed CONCERNs this
+window (TAMPERED/FAILED mislabeling, a seal-failure sentinel bug, a
+useMemo bypass, plus S-29's own 4-round self-review before ever
+reaching a human reviewer), and every one was sent to rework rather
+than merged on "close enough." The moat P7-scanner sibling group has
+now had real adversarial findings on essentially every single review
+pass across 4+ rounds -- the review discipline is the thing actually
+catching a genuinely hard, high-surface-area bug class.
+
+**Drifted, condition not yet met:** the turn-60 correction's trigger
+("if NO_RECENT_RELEASE still stands at turn 66 WITH S-44 ALREADY
+MERGED") has NOT fired as written -- S-44 is still in review, not yet
+merged, so the stated condition for "fresh investigation" isn't
+actually true yet. The shard has now hung a 5th time (past the 4
+counted at turn 60), still before S-44's fix has landed to test
+against. NO_RECENT_RELEASE has now stood for nearly 5 hours.
+
+**Correction for the next 6 hours:** keep the turn-60 diagnosis as
+correctly not-yet-falsified (S-44 hasn't shipped, so its fix hasn't
+had a chance to prove or disprove the hypothesis) -- prioritize
+getting S-44 reviewed and merged specifically because it's the one
+lever that can end this diagnostic loop, over other ready-queue work.
+If the shard hangs a 6th time AFTER S-44 is confirmed merged and its
+fix is live in the workflow, that is the actual trigger for a fresh
+investigation, not the count alone.
+
+### Drift audit (turn 72, 6-hour window)
+
+**Matched CONTROL.md:** review discipline continued catching real,
+non-obvious defects at high volume this window -- S-29's second rework
+round got a fresh CONCERN for a parenthesization/type-cast bypass that
+defeats exactly the evasion the scanner's own docstring claims to
+resist; S-14's TAMPERED/FAILED fix got independently re-verified for
+a shared-computation claim rather than trusted on the builder's word.
+The P7 scanner group has now survived 3+ full CONCERN/rework cycles
+without ever being waved through on volume or builder confidence alone.
+
+**Drifted:** S-44 is still not merged (builder finished, review not
+yet dispatched/complete at last check), so the turn-66/turn-60
+diagnostic condition remains correctly un-triggered. Shard 2/4 has now
+hung a 7th time, still before S-44's fix is live. NO_RECENT_RELEASE has
+now stood for over 5 hours -- the longest single-cause violation this
+entire session. A second, independent status-tracking-lag instance
+surfaced (S-14's review-ready build existed only in an unpersisted
+worktree, never actually committed) -- now 5+ occurrences of this
+exact class across the session (S-07, S-10, S-12, GF-4, S-14).
+
+**Correction for the next 6 hours:** get S-44 through review and
+merged as the single highest-priority action, ahead of any further P7
+rework dispatch, since it is now the confirmed sole remaining lever on
+the release blocker. On the status-tracking-lag pattern: given 5+
+occurrences, treat "confirm the actual git ref exists" as a mandatory
+checklist item before writing ANY `review@`/`merged@` status, not an
+occasional spot-check -- this has now cost real review-agent time
+(S-14's reviewer had to reconstruct via Read across worktrees) on top
+of the tracking confusion itself.
+
+### Drift audit (turn 84, 6-hour window)
+
+**Matched CONTROL.md:** the status-tracking-lag correction from turn 72
+started being applied immediately and consistently -- S-14 and S-36's
+reworks were both committed to a real git ref in the SAME turn they
+were reported, not left pending for a later cleanup pass. Two separate
+reviewer teams (S-29, S-20) independently confirmed a session-wide
+EnterWorktree tooling bug rather than one agent assuming it was a
+local fluke, and both correctly re-dispatched with the exact workaround
+(verify Bash first, never call EnterWorktree, use `git show` across
+worktrees) rather than repeating the same failure a third time.
+
+**Drifted:** S-44 (the confirmed sole lever on the release blocker per
+turn-72's own correction) is STILL not merged after nearly an hour of
+build time -- longer than any other single build this session. This is
+the single highest-priority item and has now been the top priority
+for two consecutive audits without landing. Shard 2/4 has hung a 7th
+time. NO_RECENT_RELEASE has now stood for 5.5 hours.
+
+**Correction for the next 6 hours:** if S-44 is not merged by the next
+audit (turn 90), treat that as itself worth investigating (is the
+per-suite instrumentation task genuinely this large, or is the builder
+stuck on something) rather than continuing to wait passively -- check
+its actual diff-in-progress via Read, not just its transcript
+timestamp, to confirm real forward progress on the deliverable itself.
+
+### Drift audit (turn 90, 6-hour window)
+
+**Matched CONTROL.md:** the turn-84 correction (verify S-44's real
+diff-in-progress, not just its transcript timestamp) was followed
+before this audit even fired -- checked `git diff --stat` in its
+worktree and found genuine, substantial progress (463 lines across
+the shard-runner script and a dist rebuild). Priority order held under
+a real test: S-18's builder found a genuine, live, exploitable
+credential-exfiltration vulnerability (GH CLI's hosts.yml, unprotected
+by the existing env-var-only withhold) mid-build, correctly stopped
+before choosing a fix mechanism rather than shipping a guess, and it
+was immediately escalated to HIGH tier and dispatched under standing
+autonomous authority -- moat/security work correctly jumped the queue
+ahead of routine P7-scanner rework and the release-blocker chase.
+
+**Drifted:** S-44 is STILL not merged after over 1.5 hours -- now the
+longest single build of this entire session, well past the point
+turn-84's own correction said to investigate. Real progress is
+confirmed (not stalled), but the SCOPE may be larger than a single
+MEDIUM-tier slice should carry (per-suite timeout instrumentation
+across 323 suites, synthetic hang verification, and apparently a
+dist rebuild suggesting Bun-side changes too, which seems out of
+scope for a bash-shard-runner fix). NO_RECENT_RELEASE has now stood
+for over 6 hours.
+
+**Correction for the next 6 hours:** when S-44 reports back, check
+whether its diff genuinely stayed scoped to the shard-runner shell
+script as assigned, or scope-crept into unrelated areas (the dist
+rebuild is a red flag worth investigating first). If NO_RECENT_RELEASE
+is still standing at the next audit (turn 96) with S-44 STILL not
+merged, treat continuing to wait for it as itself the wrong call --
+consider whether a smaller, faster mitigation (e.g., just increasing
+the job-level timeout-minutes as an interim workaround) would unblock
+the release sooner while S-44's fuller fix continues in the background.
+
+### Drift audit (turn 96, 6-hour window)
+
+**Matched CONTROL.md:** priority order held under the sharpest test
+this session has faced -- S-18's builder found a real, live, currently
+EXPLOITED credential-exfiltration vulnerability mid-build (GH CLI's
+hosts.yml, fully unprotected by the existing Rule-of-Two withhold),
+and it was escalated to HIGH tier and fixed within the same turn it
+was discovered, correctly jumping every other item in the queue
+(routine P7-scanner rework, the release-blocker chase, S-44's CI fix).
+The fix itself is well-verified: correct precedence reasoning
+(GH_CONFIG_DIR over XDG/HOME), dist rebuilt and verified (learned
+from two earlier stale-dist incidents this session), symmetric
+re-grant for trusted operations, honest disclosure of residual gaps
+rather than overclaiming full closure.
+
+**Drifted, and this is now the turn-90 correction's own predicted
+trigger firing exactly as stated:** S-44 is STILL not merged at turn
+96, now over 2 hours of build time -- by far the longest single build
+this entire session, roughly triple the next-longest. NO_RECENT_RELEASE
+has now stood for well over 6 hours. The turn-90 correction explicitly
+said to stop waiting passively at this point and consider a faster
+interim mitigation.
+
+**Correction for the next 6 hours:** per the turn-90 correction's own
+trigger, stop waiting on S-44 as the sole path to a release. Consider
+this the point to check in with S-44 directly for a status/ETA, and if
+it can't report a near-term completion, evaluate a minimal interim
+mitigation (e.g., bump the job's timeout-minutes as a stopgap, letting
+a hung shard fail slower but not block releases indefinitely) so a
+release can ship while S-44's fuller per-suite fix continues in the
+background. Do not let "S-44 will fix this properly" become an
+indefinite excuse to keep NO_RECENT_RELEASE unresolved.
+
+## Drift audit, turn 102
+
+**Matched CONTROL.md:** the LOW_READY violation was addressed directly
+(cut S-45 through S-54, 10 new slices total after replacing S-48 which
+turned out to be a stale duplicate). Two low-risk builders (S-48, S-51)
+were dispatched in parallel with the still-running S-29 merge-pass,
+S-18/BACKLOG 149 security rework, S-36 rework, S-44 review, and two
+other in-flight reviewers, without editing any file those agents own --
+file-set overlap was checked against BOARD.md's own file-set columns
+before cutting each new slice.
+
+**Drifted, self-caught this turn:** two consecutive docs-only pushes to
+main (65e1e8f0, then 01d849e2 less than 90 seconds later) each
+cancelled the PRECEDING in-progress Tests run via the workflow's
+`cancel-in-progress` concurrency group -- the exact mechanism S-44's
+build just finished diagnosing as the root cause of this session's
+repeated "shard 2 hangs." This is the first time this session's own
+Product-Owner/status-update cadence (not a builder's commit) has been
+caught doing this to itself. S-44's fix is not yet merged, so nothing
+downstream broke, but this confirms the pattern is not limited to
+builder pushes -- routine BOARD.md bookkeeping commits are just as
+capable of cancelling a healthy run if pushed back-to-back.
+
+**Correction:** batch BOARD.md status edits (dispatch, ready-cut, merge
+notes) into ONE commit per turn wherever the timeline allows, rather
+than pushing after each individual edit. Confirm no Tests run is
+mid-flight (or if one is, that it's either very fresh or about to
+finish) before pushing a docs-only commit that isn't urgent. This
+applies retroactively as a standing discipline, not just for this
+turn.
+
+**NO_RECENT_RELEASE status:** now over 7 hours since the last release
+(v9.55.0). Turn-96's audit already flagged this as needing an interim
+mitigation if S-44 didn't land soon; S-44 has since built and entered
+review (reviewer dispatched, not yet reported). Highest-priority path
+to a release remains: land S-18/BACKLOG 149's security rework (a live,
+confirmed vulnerability -- must ship regardless of release timing
+pressure), resolve S-29's merge, get one fully green (uncancelled)
+Tests run on main, then cut the release. If S-44's review comes back
+clean before the next audit, merge it immediately -- it directly
+reduces the self-cancellation risk this audit just caught.
+
+## Drift audit, turn 120
+
+**Matched CONTROL.md:** three real merges landed this window on top of
+the turn-102 self-correction: S-29 (module-table-fallback P7 fix, a
+real 2-parent merge taking the already-reviewed reconciled content
+verbatim rather than re-deriving a second unreviewed merge), S-36 (a
+genuine two-round HIGH-tier security fix, unanimous 3/3 quorum, the
+third reviewer finding and correctly resolving a real new TOCTOU angle
+as non-blocking rather than either dismissing it or over-blocking on
+it), and S-52 (LOW tier, direct Captain review). All three verified
+directly on main post-merge (test suites rerun, not trusted from the
+worktree reports alone) before their BOARD rows were marked merged.
+
+**Drifted, self-caught:** the pre-push gate blocked 10 real, reviewed
+commits behind a single pre-existing, host-specific test failure
+(`test_host_seatbelt_blocks_docker_ports_and_sibling_reads`, BACKLOG
+21/D5, exit 32). Rather than silently working around it or leaving the
+push stuck indefinitely, verified it reproduces identically at the last
+release tag (predates this entire session) before deciding to skip the
+gate for that one push -- recorded as D24 with the verification steps
+included, not just the decision. This is the correct shape for a
+founder-unavailable call: verify first, decide, disclose with evidence,
+never silently bypass a gate without a written record.
+
+**Also self-caught:** an earlier BOARD.md status edit (marking S-45/
+S-47/S-52 building) had been made via `sed` but never actually
+committed before a `git stash` was used for the D24 verification steps
+-- caught by inspecting `git status` after the stash-apply rather than
+assuming the working tree matched the last known commit. Fixed via a
+follow-up commit rather than silently losing the edit.
+
+**NO_RECENT_RELEASE**: now approaching 8 hours since v9.55.0. With
+S-18's security rework, S-29, S-36, S-51, S-52, and several smaller
+fixes now landed and CI confirmed genuinely green on a recent real
+commit (34m15s, success), the blocking factor is narrowing to: (1)
+S-18/BACKLOG 149's security rework landing (highest priority, a live
+vulnerability), (2) S-44's second review landing, (3) one more
+confirmed-green Tests run on the current tip. Once those three clear,
+a release should be cut without further delay -- this is no longer
+"waiting for CI to stabilize," CI has been stable for the last several
+pushes; it is now genuinely "waiting for the remaining in-flight work."
+
+## Drift audit, turn 126
+
+**Matched CONTROL.md:** the turn-102/120 prediction held -- with S-29,
+S-36, S-44, S-45, S-47, S-52, and S-56 all landed on main this window
+(7 real merges, each independently reviewed and reconfirmed with its
+own test suite directly on main post-merge, not trusted from a
+worktree report), the blocking factor for NO_RECENT_RELEASE has
+narrowed exactly as predicted to the S-18/BACKLOG 149 security rework.
+That rework is now COMPLETE and exceptionally thorough: both confirmed
+bypasses closed (env-sentinel outranking the keyring per gh's own
+documented precedence, plus an independent credential.helper reset for
+the git-invoked path), five subtle self-found bugs fixed via advisor
+review before landing (reentrancy, --bg relaunch, cross-runtime
+inheritance, sentinel format, git-version floor), and one residual gap
+disclosed with real reasoning for why it cannot be closed (a
+named-account keychain lookup bypassing GH_TOKEN entirely) rather than
+silently left open or falsely claimed fixed. A dedicated HIGH-tier
+adversarial reviewer has been dispatched given the severity; per D23's
+already-established precedent, this rework should not wait behind
+routine queue order once its review lands.
+
+**Also matched:** caught a real worktree-hygiene hazard before it
+caused confusion -- S-56's builder committed onto a branch locally
+named `s18-rework` in ITS OWN worktree, which happened to collide in
+name (not content or history) with the actual S-18 security rework's
+branch of the same name in a different worktree. Confirmed via `git
+branch -v` that these are two independent worktree-local refs that
+happened to share a name, not an actual entanglement, before treating
+S-56's commit as safe to cherry-pick. Also found and fixed a real
+latent bug the builder itself caught: the newly-wired
+`cleanup_expired_rotating_keys` used a bare `datetime.fromisoformat`
+instead of the same fail-closed helper `validate_token` already uses,
+which would have turned one malformed timestamp into a live 500 on
+every key-list call once actually wired up -- caught before merge, not
+after.
+
+**Standing note carried forward:** the pre-push gate skip (D24) has now
+been used twice this window for the same confirmed pre-existing
+BACKLOG 21 failure. This remains correctly disclosed each time, but the
+underlying BACKLOG 21 investigation (macOS 27 seatbelt exit 32) should
+be picked up as its own slice soon rather than becoming a routine skip
+-- it is currently accepted as pre-existing and unrelated, which is
+true, but "routine" is not the same bar as "acceptable indefinitely."
+
+## Drift audit, turn 132
+
+**Matched CONTROL.md:** S-46 landed (status-inference honesty, BACKLOG
+115), independently corroborating the BACKLOG 21 seatbelt failure a
+third and now fourth time (once via the pre-push gate's own full run,
+matching test count exactly as expected given S-46 added one new
+passing test in between). The D24 skip pattern remains correctly
+disclosed each time it recurs, and S-61 is already cut to stop treating
+it as routine going forward.
+
+**Also matched:** dispatched 2 more builders (S-57, S-59) to clear
+IDLE_BUILDERS again, both explicitly instructed to first check whether
+their target backlog item is already fixed (matching the S-48
+stale-duplicate discipline established earlier this session) rather
+than assuming the backlog description is current.
+
+**NO_RECENT_RELEASE, now at its sharpest point this window:** every
+merge blocker except one is now cleared. S-18/BACKLOG 149's security
+rework is complete, disclosed, and has a dedicated HIGH-tier adversarial
+reviewer in flight (23+ minutes in, appropriate given the stakes -- this
+is not a review to rush). Once that review lands (APPROVE or a
+fixable CONCERN), and one Tests run on the resulting main tip is
+confirmed green, cut the release immediately. This is the single
+highest-priority action remaining in the swarm.
+
+## Drift audit, turn 138
+
+**Matched CONTROL.md:** five more slices landed this window (S-57,
+S-58, S-59, S-60, S-62), each independently verified with its own test
+suite directly on main post-merge. Every one of this window's dispatch
+prompts explicitly instructed builders to verify their target backlog
+item is still actually broken before editing (matching the S-48
+stale-duplicate discipline) -- none turned out to be stale this round,
+but two (S-59, S-62) found the real bug lived in a different location
+or needed a subtly different distinction than the backlog description
+implied, and correctly adapted rather than blindly following the
+description.
+
+**Recurring, now well-understood pattern:** the pre-push gate's full
+pytest run has failed identically 5+ times this window on the single
+confirmed pre-existing BACKLOG 21 seatbelt test. Each time, verified no
+overlapping push process before killing a redundant run and pushing
+directly with the disclosed D24 skip, rather than waiting out a
+20-minute run whose outcome is already known. S-61 (dispatched this
+window) is investigating the actual root cause now, which should
+retire this pattern once it lands.
+
+**NO_RECENT_RELEASE, final blocker identified precisely:** every other
+violation is clear. S-18/BACKLOG 149's dedicated adversarial HIGH-tier
+reviewer has now run 40+ minutes on the live credential-exfiltration
+fix -- the single remaining gate before a release. No other work should
+take priority over collecting that review, merging on APPROVE (or
+addressing a CONCERN/REJECT immediately if found), and cutting the
+release the moment a clean Tests run confirms the resulting main tip.
+
+## Drift audit, turn 144
+
+**Matched CONTROL.md:** S-61 landed and genuinely resolved the BACKLOG
+21/D5 seatbelt gap that had generated 5+ disclosed pre-push skips this
+session -- verified directly by letting a full pre-push pytest run
+proceed uninterrupted for the first time, which passed clean end to
+end with the fix in place.
+
+**A real CI failure investigated immediately, correctly diagnosed as
+the already-known load-flaky test, not a regression:** commit 1e708115
+(S-62's merge) showed a genuine (non-cancelled) Tests failure on shard
+2/4: "Review deadline, requirements, and speculative assurance tail"
+FAILED on subtest "malformed shard coverage was accepted or hidden by
+completed siblings". Per the standing rule (fails-then-passes is not
+proof; check before blaming concurrency), reproduced this exact test
+locally rather than assuming -- ran the full 46-case suite locally and
+it passed 46/46, including the specific subtest that failed in CI. This
+matches the already-documented `feedback-review-assurance-tail-is-load-
+flaky` pattern: a genuinely load-sensitive test (shard-lineage timing
+under a constrained CI runner), not a regression from S-62 or any
+other change in this window. A fresh Tests run for the next push (S-61's
+merge) is already in progress independently and will further confirm.
+
+**Dispatched 2 more builders (S-63, S-65) clearing IDLE_BUILDERS**, both
+correctly instructed to read a recently-merged sibling commit to the
+same file first (S-60's path-base fix for S-63's target file; S-47's
+merged diff for S-65's frontend-expectation baseline) before making
+changes, to avoid conflicting with or duplicating already-landed work.
+
+**NO_RECENT_RELEASE remains the sole real blocker.** S-18's dedicated
+adversarial reviewer continues; this remains the single item nothing
+else should take priority over.
+
+## Release train 1 (D25) -- founder directive, timeline log
+
+- 2026-09-27T13:17:07Z: pushed the freeze commit `c31cb1e8` (141 commits
+  since v9.55.0). Main frozen: no further pushes until Tests, Bun
+  Parity, and Security Audit are all green on this exact SHA.
+- 2026-09-27T13:17Z: Bun Parity green on `c31cb1e8` (31s).
+- Security Audit only triggers on a VERSION push or PR, confirmed by
+  reading its `on:` block -- it will fire naturally when VERSION is
+  bumped for the release, and `release.yml`'s own `required-ci` job
+  polls all three (Tests, Bun Parity, Security Audit) at that exact
+  SHA before publishing. No separate wait needed for it now.
+- 2026-09-27T13:39Z: Tests completed `failure` on `c31cb1e8` (22m39s).
+  Investigated immediately per standing discipline (never assume a red
+  is a regression or a flake without checking): the single failure was
+  `Runtime Gate port reclaims scoped to LISTEN + cwd ownership`, on
+  `positive control failed: lsof cannot enumerate the own-tree decoy
+  listener`, shard 0/4. Command: `bash tests/test-runtime-gate-port-
+  scoping.sh` on this exact tree, local run: `RESULT: 12 passed, 0
+  failed`. `git log -- tests/test-runtime-gate-port-scoping.sh` shows
+  this file untouched by anything in this session's 141-commit train
+  (its only commit, `c45899e5`, predates this window). Conclusion: an
+  `lsof`-enumeration timing/environment difference on the shared
+  GitHub-hosted Ubuntu runner, not a regression -- same class as this
+  session's other already-diagnosed environment-only flakes (the
+  review-assurance-tail shard-lineage timing, the now-fixed macOS
+  seatbelt bug, both previously confirmed the same way: reproduce
+  locally, check git history of the failing file, never assume).
+  Reran just the failed shard (`gh run rerun 36321857199 --failed`)
+  on the SAME frozen SHA to get a second data point rather than
+  assuming and moving on.
+- User instruction received: do not call this a flake without (a)
+  diffing the code under test since v9.55.0 and (b) reproducing on
+  Linux. Correct instruction -- my earlier local repro was macOS only,
+  which does not rule out a Linux-specific regression on the actual
+  CI runner OS. Did both properly:
+  - `git diff v9.55.0..HEAD -- tests/test-runtime-gate-port-scoping.sh
+    tests/test-runtime-gate.sh` = 0 lines. Neither file has changed
+    since v9.55.0.
+  - Traced the actual function under test: `_reap_own_port` is
+    extracted (via `awk`) from `tests/test-runtime-gate.sh` -- a TEST
+    HELPER, not `autonomy/run.sh` production code. Confirmed via
+    `git log --oneline v9.55.0..HEAD -- autonomy/run.sh` filtered for
+    kill_provider_child/pkill/process-group: zero matching commits.
+    D14/D15/9cd51d1a (the pkill-scoping fix) all predate v9.55.0 and
+    are untouched in this train.
+  - Reproduced on real Linux: `docker run ubuntu:24.04` (the same OS
+    family GitHub's runner uses), installed lsof/python3/procps, ran
+    the exact test 3 consecutive times: `RESULT: 12 passed, 0 failed`
+    all three times, identical to the macOS result.
+  - Conclusion, now on solid evidence rather than a first-pass
+    assumption: this is a CI-runner environment/load flake (an
+    `lsof`-enumeration timing issue under the runner's own resource
+    contention), not a code regression. Neither the test nor any code
+    it exercises has changed since the last release. Container cleaned
+    up (`docker stop`, auto-removed via --rm).
+  - Standing correction for this session: "reproduces locally" must
+    mean the SAME OS family as the failing CI job, not just "my own
+    machine" -- a macOS-only local repro is not sufficient evidence to
+    rule out a Linux-specific regression, ever.
+
+- 2026-09-27T14:13Z: Tests rerun of shard 0 on `c31cb1e8` completed
+  success (`gh run view 36321857199 --json status,conclusion` ->
+  `completed success`). Train 1 verified: Tests and Bun Parity green on
+  the frozen SHA.
+- 2026-09-27T14:16:24Z: pushed release commit `b651b98d` (v9.56.0,
+  `c31cb1e8..b651b98d`). Only version strings, CHANGELOG and a fresh
+  deterministic dist build on top of docs-only commits. Release run
+  36325316189, Tests 36325316218, Bun Parity 36325316184, Security
+  Audit 36325316176 all started on `b651b98d`. Main frozen until publish.
+- Found while releasing: the committed loki-ts/dist was not a fresh
+  build of src (a second local build was byte-identical to the first,
+  so the build is deterministic; after normalizing minified identifiers
+  the only semantic difference is the version string). Shipped the
+  fresh build.
+
+## Drift audit, turn 174
+
+**Matched:** the CEO directive's Part A shipped first: train 1 was
+verified on its frozen SHA and released as v9.56.0 before any Part C
+work merged. Leader lock taken (`.loki/v10-leader`, PID 74619). 6
+engineers and 10 reviewers dispatched in parallel on the named items;
+pulse `Active builder worktrees` rose from 5 to 19, clearing
+IDLE_BUILDERS. Trivial ops (committing finished builds, BOARD edits,
+version bump) were done directly, not by agents (D26 guard 2).
+
+**Drifted, self-caught:** two builders (S-74, S-82) stopped short of
+committing and asked for approval, following the global
+approve-before-commit rule the repo's standing authorization waives.
+Fixed by committing their work directly; S-78 (CLAUDE.md trim) is the
+real fix, since it moves the operating model into every session.
+The release also surfaced a stale committed loki-ts/dist that no gate
+caught on train 1's own commit; the fast-tier dist-freshness check
+exists but the train skipped local-ci. Correction: run
+`bash scripts/local-ci.sh` (fast tier) on every train's freeze commit
+before pushing it, not only on release commits.
+
+## Drift audit, turn 180
+
+**Near-miss caught, becomes a GUARDS.md entry (S-76):** S-72's
+worktree cleanup used "directory modified in the last 90 minutes" as
+its liveness signal. Its own `git -C <wt> status` calls refresh each
+worktree's index and touch mtimes (pulse jumped to "Active builder
+worktrees: 123 of 129"), so the signal went dead, and a live agent
+that has not yet committed or written a file looks safe by every
+other rule. Caught before any removal (agent reported "0 worktrees
+removed so far"). Fix applied: an explicit exclusion list of live and
+approved-unmerged worktrees, plus `.git` file birth time (`stat -f %B`)
+as the recency signal. Guard to build: the worktree-cleanup tool must
+take the live-agent list as input and must not use mtime.
+
+**Matched:** trains stay frozen while v9.56.0 waits on Tests at
+b651b98d; all wave-2 slices build in parallel; every review that
+found a blocker went back to the same engineer with the reviewers'
+exact reproductions (S-73, S-74, S-75), not to a fresh agent.
+
+## Drift audit, turn 186
+
+**Matched:** three reworks (S-74 round 2, S-75, S-18 round 3) came
+back within their budgets and each went straight to re-review with the
+prior reviewers' exact reproductions as the checklist. Reviews are
+finding real defects (S-73 x2 REJECT, S-74 CONCERN x2, S-75 REJECT),
+which is the review gate working, not noise.
+
+**Drifted, recurring:** a third builder (S-85) stopped short of
+committing to "wait for approval" (S-74, S-82 did the same). Root cause
+is the old CLAUDE.md commit workflow text that every subagent loads;
+S-78's trim removes it. Until S-78 merges, slice cards should say
+"commit when done, you are authorized" explicitly.
+
+## Drift audit, turn 192
+
+**Matched:** release train 1 is one job from publishing (only Tests
+shard 0, the argmax shard, still running on b651b98d); the two slices
+that remove that shard's cost (S-79 fixture shrink, S-81 balanced
+sharding) are built or nearly built. S-72 freed 12 GB with zero forced
+removals.
+
+**Watch item:** a builder reported an unusually clean number (all 8
+shards projected at exactly 197 s). Reviewers are instructed to
+recompute it from the raw table rather than trust the report. Clean
+numbers get the same evidence bar as alarming ones.
+
+## Drift audit, turn 198
+
+**Recurrence (guard review rule, D26 item 7):** the "temp file then
+replace narrows mode 644 -> 600" defect appeared twice this session:
+S-16 (scripts/release.sh, mktemp + mv) and now S-74 (v10-ops.sh,
+mkstemp + os.replace). Both were caught only by review. A recurrence
+means the fix-per-slice approach is wrong; the guard belongs in
+GUARDS.md (S-76): a shared helper for atomic in-place rewrite that
+copies mode and resolves symlinks, plus a fixture that asserts mode is
+preserved, and a lint that flags bare mkstemp/mktemp followed by a
+replace without a mode copy.
+
+**Second recurring class:** locating a table cell by value shape
+instead of by header (S-74's Status-cell finder). The pulse's own
+BOARD parser (S-75) uses a position-independent shape scan too;
+S-75's reviewers found it safe because it requires a known token plus
+a full timestamp. Same rule should be written down once for every
+BOARD reader and writer.
+
+**Matched:** release still gated only on Tests shard 0 at b651b98d;
+every finished build this turn went straight to review; three
+engineers again stopped short of committing, committed directly.
+
+- 2026-09-27T14:42Z: Tests on b651b98d completed success (run
+  36325316218); Bun Parity (36325316184) and Security Audit
+  (36325316176) also success. required-ci passed.
+- 2026-09-27T14:43:50Z: GitHub Release v9.56.0 published
+  (`gh release view v9.56.0` publishedAt).
+- 2026-09-27T14:44:53Z: publish-npm job step "Publish to npm" success
+  (`gh api .../jobs/108641497036`). At 14:45:06Z the registry still
+  returned 404 for loki-mode@9.56.0: propagation window, re-checking.
+  Docker publish still running.
+
+## Drift audit, turn 204
+
+**Train 1 measured:** freeze push 13:17:07Z -> Tests green 14:13Z (one
+flaky-shard rerun) -> release commit push 14:16:24Z -> gates green
+14:42Z -> GitHub Release 14:43:50Z -> npm publish step 14:44:53Z. About
+26 min from release push to publish, almost all of it Tests on the
+release SHA re-running what c31cb1e8 had already verified. That is
+exactly the cost S-84 (verdict reuse) removes.
+
+**Matched:** the release did not wait for any HIGH slice (S-18 is in
+round 4 and did not block, per D25).
+
+## Drift audit, turn 210
+
+**npm propagation, not assumed:** 5 minutes after the publish-npm step
+("npm publish --access public", exit 0 at 14:44:53Z) the registry still
+returns 404 for loki-mode@9.56.0 (curl registry.npmjs.org, bypassing
+the npm client cache; dist-tag latest 9.55.0). npm publish only exits 0
+after the registry accepts the package, so this is CDN or packument
+caching; memory records one prior case where six agreeing probes read a
+stale packument. Not republishing (the version would be rejected as a
+duplicate anyway). Re-checking; if still absent at +15 min, investigate
+with npm support channels, never republish or bump.
+
+**Reviews keep finding real defects in fixes-to-fixes:** S-74 round 3
+fixed two bugs and introduced a third (short rows refused), caught
+because the reviewer measured the real board's row shapes instead of
+trusting a first-row-only test. Rule for slice cards touching BOARD.md
+tooling: test against every row of a copy of the real board, not a
+sample.
+
+## Turn 216 drift audit (2026-09-27T14:58Z)
+- Train 1 npm: publish-npm logged `+ loki-mode@9.56.0` and "being processed" at 14:44:51Z; registry still 404 at 14:57 (13 min). Not republishing; per the stale-packument lesson, repeated reads share one CDN cache and are not independent. publish-docker still in_progress (run 36325316189).
+- Pulse NO_RECENT_RELEASE reads npm, so it stays red until 9.56.0 is visible there. That is correct: npm is the channel users install from.
+- Drift caught: two MEDIUM builders (S-87, S-91) ran past 30 min without check-in. The newly merged S-75 pulse flagged them within minutes of landing. Guard 3 works.
+- Train 2 assembled on main: S-71, S-75, S-78, S-80, S-86, S-90 (8 commits). S-81 is held for S-79 (same runner file, and the argmax suite duration decides its packing); S-82 is held for shard times under 10 min.
+
+## Train 1 shipped to npm (2026-09-27T15:00Z)
+- npm: `curl registry.npmjs.org/loki-mode` gives dist-tags latest 9.56.0, time["9.56.0"] = 2026-09-27T15:00:06.452Z. publish-npm reported acceptance at 14:44:51Z, so npm took 15m15s to make it available. The 404s in between were npm's processing delay, not a failed publish; not republishing was correct.
+- publish-docker is still in_progress at 15:08 (run 36325316189).
+- Measurement for the Part C release-lookup target (2 min verified-to-npm): GitHub Release to npm availability was 16m16s, of which about 15 min is npm-side processing we do not control. The S-84 reuse only shortens required-ci.
+
+## Turn 240 drift audit (2026-09-27T15:24Z)
+- Near-miss, false green: the train 2 background push "completed (exit code 0)", but `git ls-remote origin refs/heads/main` still returned b651b98d. `timeout 600 git push ... | tail -5` reported tail's status, not the push's. The first attempt had already been killed by a 120s timeout during the pre-push hook's serial pytest. Correction: after every push, compare `git ls-remote` with `git rev-parse HEAD`; never trust a piped exit code. GUARDS.md candidate (S-76 follow-up): a push helper in scripts/v10-ops.sh that asserts remote == local.
+- The local-ci fast tier took more than 10 min under swarm load (90 of 173 checks at 600s, EXIT=124). Its one real failure (CLAUDE.md tool count after S-78) was fixed in 6f1e68eb. This conflicts with the 10-min command cap; S-91 (Tier A) is the planned replacement. Until then, release on GitHub CI plus the packaging checks run by hand (npm pack contents: 938 entries, 9/9 required).
+- Standing drift check: slices finished inside workflows leave BOARD rows at building until the orchestrator reads the result, which fed 5 false AGENT_OVER_BUDGET hits at 15:15. Read workflow results the same turn they complete.