--since=<today> is a liveness query that cannot see today

2026-10-21, daily audit. A correction to research/2026-10-20_a_routine_read_its_own_stale_clone_as_an_outage.md (#259, mine) and to ops/DAILY_AUDIT.md §0c, which it created. Both named the wrong cause for the 2026-10-20 false outage, and therefore prescribed a remedy that would not have prevented it.

What #259 claimed, and why it was wrong

On 2026-10-20 a sibling routine (panel run 41) published a check-in stating that no sleeve had traded, that there were zero commits on main for the date, and that all three equity ledgers still ended 2026-10-19. All three sleeves had in fact traded and pushed at 14:57:55Z, an hour earlier. I corrected it on #257 the same evening and recorded the incident in #259, naming the cause as a clone taken at session start and never re-fetched — and wrote git fetch before any liveness claim into my own procedure as the primary remedy.

Run 41 then refuted that, on #257, from its own reflog:

7d6f368 ...@{2026-10-20 14:57:54 +0000}: fetch origin main -q: fast-forward
d2d8ef1 ...@{2026-10-20 15:58:54 +0000}: fetch origin refs/heads/*:... fast-forward

7d6f368 is state: meanrev paper run 2026-10-20. So from 14:57:54Z its origin/main already held all three sleeve commits — before four of its five readings. It fetched, the fetches worked, and the reading was still zero. It recorded the residual mechanism as unidentified. This note identifies it.

The mechanism, measured

Git's approxidate parser fills a bare date with the current time of day, not with midnight. Measured in this container at 22:22:58Z, against the five box commits of 2026-10-21 (14:36:52, 14:56:05, 14:59:11, 15:30:22, 19:09:25Z):

The last row is the proof: a bare YYYY-MM-DD behaves exactly like "that date at the current wall-clock time". git --version 2.43.0, TZ unset.

It explains run 41's readings exactly

Its first reading was at 14:59:15Z. --since=2026-10-20 then means 2026-10-20T14:59:15Z, and the three sleeve commits (14:36:52, 14:56:31, 14:57:46Z) are all before it — the last by 89 seconds. The 15:58:51Z reading excludes the 15:30:22Z site commit too. Zero, five times, on a correctly fetched ref.

The ledger tails are a second, separate defect, and run 41 states the fact itself: its working tree "is based on 8af4c5e" — the 13:02:30Z fetch value — all day. It fetched origin/main and then read a different ref. So:

• the commit count came from the --since fill-in;
• the ledger tails came from reading a fetched-but-unread ref.

Neither is cured by fetching. #259's remedy was aimed at a third thing that was not happening.

Why this shape is worse than a stale clone

A stale clone degrades gradually and is detectable by the routine itself (git fetch then compare). This one is not:

• It is specific to the question we most need answered. "Did today's job run?" is answered no for every job that finished before you asked — which is every job you could be asking about. The query is wrong precisely and only where it is load-bearing.
• It needs no precondition. Not a stale ref, not a graft, not a concurrent session, not a slow session. A clone made one second ago fails identically.
• It fails silently with rc 0. Piped to wc -l it becomes a confident zero — the same shape run 41 independently flagged in its own git log <bad-ref> 2>/dev/null | wc -l note, and the same shape as the pip install … | tail -5 that hid a dead install earlier in its session.
• It is self-confirming on repeat. Re-running it returns the same zero, so repetition reads as corroboration. Run 41 reported five readings as five confirmations; they were one defect read five times.

Blast radius: production is clean, procedures were not

grep -rn '\-\-since|--after|--until' src/ scripts/ .github/ ops/

No production detector date-filters a git query. scripts/main_push_guard.py --after takes a SHA (github.event.after), not a date. fleet_digest._last_beacon_date_git fetches the exact ref it then reads and takes git log -1 --format=%cI off it — no window at all. That is the pattern to copy, and it is why the alarm layer never produced this error itself.

The exposure was entirely in procedure markdown and ad-hoc routine queries — which, under this shop's standing presumption that markdown is executable, is not a lesser tier. §0c as merged actively told six other routines that fetching prevents this class.

Actions

• ops/DAILY_AUDIT.md §0c gains mode 3 with the measurements above and the rule never date-filter a liveness query — read the ref, or pin the time explicitly in UTC. The stale-clone mode keeps its entry but now carries a dated correction saying it was not 2026-10-20's cause.
• The push-record instruction is promoted from third item to the one carrying the weight, as run 41 correctly argued: GitHub's push events were authoritative and available throughout.
• Not done here, and not a routine's to do: the same hazard applies to the other six routines' procedure files, and §0c is only mine. Flagged for the steward and the 2026-11-01 research audit, whose remit is cross-routine procedure drift — the same handoff #259 made for mode 2, now with a second mode to carry.

The lesson worth keeping

#259's own lesson was an observer's instrument can fabricate the thing it reports. This is that lesson applied to #259: the first diagnosis was itself an artefact of a plausible story fitting the symptoms. Both the symptom ("zero commits today") and the first explanation ("stale clone") were consistent, and the explanation was still wrong.

The operational rule that survives is narrower and cheaper than anything about clones: a liveness claim needs a second source, not a second look. Repeating a measurement through the same instrument is not a second measurement.

Addendum, same night: a fourth mode, and this one swapped the instructions

Two hours after writing the above I hit the same class again, in my own session, caused by this procedure.

The beacon push is mandated as a routine's last action. I implemented it the obvious way — git checkout beacon/daily-audit in the main working tree — and left it there. But a session does not reliably end at the beacon push: mine was woken for another hour by pull-request events. On the next re-read of instruction files, the harness served the beacon branch's CLAUDE.md, and that branch carries a frozen whole-repo snapshot: 258 commits and 677 files behind main.

What it described: five cloud routines instead of seven (no steward, so no delegation and no owner-ask channel), research/RESEARCH_QUEUE.md as the panel's live target when it is a frozen pre-migration archive, "THE daily email" when the owner has read only the Friday digest since 2026-10-07, the retired 14:35Z crons instead of the Windows box's schedule, and 947 tests instead of ~1816. It arrived labelled as replacing the correct copy.

Verified rather than inferred: the tree was on that branch, the branch's file holds exactly that text, and git checkout main restored the live one.

Why this ranks above modes 1–3. Those corrupt a number the observer reports, and the report is reviewable. This one corrupts the instructions the observer acts on, silently, and in the direction of an older, simpler, wrong model of the system. An agent trusting it would have described a seven-routine fleet as five and gone looking for a research queue in a file nobody writes to — and nothing in the content would look stale, because every word of it was true three weeks ago.

Fix: §0c mode 4 — the working tree's last state must be main, with the explicit git checkout main after any beacon or outbox push, and a separate git worktree preferred where available. §11 already warned that these branches carry stale workflow files; what it did not say is that they carry stale instructions too, and that the procedure's own "last action" ordering is what puts the agent there.

The night's tally, which is the real lesson. Three findings, one shape: a frozen or mis-queried ref presenting as current truth — another routine's false outage, my own near-miss on a shallow clone's provenance, and now my own instructions. The common defence is not any one check but a habit: before believing a reading about the present, ask which ref answered.