SHR-1 — an UNLISTED mode of the clone hazard, which git fetch cannot detect: a shared working tree moved under CONCURRENT READERS. It happened in this run, to this run's own chair, inside the run reviewing #259

status: dismissed as a queue row · raised panel run 42 (2026-10-21; change-reviewer lens candidate CR42-2 part B, and independently the chair's own error) · killed at the chair's adversarial pass as too small for a slot while the cap binds — the fix is ~0.1 pd of instruction text and this record carries it · class: G2 loudness / measurement provenance

What happened, and it was the chair's doing

#259 (merged 2026-10-20) added ops/DAILY_AUDIT.md §0c, "Your clone is not the repository", after panel run 41 reported a trading outage that had not happened.

CORRECTED 2026-10-21, after this file was first written. The first draft of this row said run 41's false reading came from "a working copy taken at its 13:00Z session start" — i.e. §0c's stale mode. That cause was wrong, and #265 (537e5f3, merged this evening) falsified it from run 41's own reflog: origin/main fast-forwarded to the meanrev commit at 14:57:54Z, before four of its five readings. It fetched, the fetches worked, and the reading was still zero. The real causes were git's approxidate filling a bare date with the current time of day (so --since=2026-10-20 asked at 14:59Z means 2026-10-20T14:59Z, excluding every commit made earlier that day) plus a fetched-but-unread ref for the ledger tails. §0c now carries that as its own mode 3, and the panel inherited the stale-clone attribution from #259 and the steward without independently verifying the mechanism — the facts it did verify (that all three sleeves traded) were never in doubt and are unaffected.

So this row is not "the third mode" — §0c's mode 3 is the date filter.

And do not replace that with another ordinal. A second correction, hours later the same evening: #266 (59c2320) added a mode 4 — parking the working tree on beacon/* or outbox/*, which swaps out the agent's own instruction files because the harness re-reads CLAUDE.md from the parked branch. So the "fourth" this row claimed for itself was wrong within the hour. §0c is being extended faster than a row can cite a position in it, and an ordinal written into a file someone else is appending to is a claim that rots by default. Cite these by name, never by number.

This row is the concurrent-readers mode, and it is still unlisted. It is adjacent to mode 4 and not covered by it: mode 4's harm is to the mover's own instructions and its remedy is "check out main again afterwards" — which this run did do. SHR-1's harm is to other readers of the same tree, who never moved anything and have no way to notice, and its remedy is different (hand each reader the SHA, or export the commit). Mode 3's text comes closest to naming it, in passing, when it notes that the date-filter failure "needs no stale ref, no graft and no concurrent session".

The hazard below stands on its own measured evidence, which never depended on run 41's cause.

And it bit this run. Having dispatched three lenses against the shared checkout at /home/user/thales, the chair then checked out branch research-queue/panel-run-41 in that same tree to push a correction to #257. That branch is diverged from origin/main, not merely behind — it forks before the 2026-10-20 commits — so for several minutes the tree the lenses were reading lacked bef5203 (#258), 8253ff4 (#259) and 9e28a45 (#256), and every option/borrow capture stream was exactly one session light.

git status was clean throughout. git fetch would not have helped: nothing was unfetched. git rev-parse --is-shallow-repository tests the wrong property. The tree was simply pointed somewhere else by another writer.

Measured, CONFIRMED-BY-EXECUTION (the chair's own fingerprints, used to verify each lens afterwards):

The near-miss is the point. The change-reviewer lens watched grep -c "_SEPT_2026_OUTAGE" src/thales/data/captures.py return 12 and then 0, with no edit of its own, and was one step from reporting that #258's acknowledgements were absent from merged code — a false finding about merged code, in the run reviewing the false-finding incident. The queue-and-clocks lens was tipped off only because two runs of the same gather function minutes apart returned different windows. Its own note is the sharpest statement of the risk: "a routine with no reason to re-run the same command twice would have shipped the stale figure, exactly as run 41 did."

Both lenses then re-derived everything from an immutable snapshot (git archive <sha> / git ls-tree) and proved byte-identity against origin/main by md5/sha256, so no finding in run 42 rests on the moved tree — verified, not asserted. One figure was corrected on the way (a DISCHARGED-precedent count), and one measurement was discarded mid-run rather than reported.

Why it is dismissed as a ROW

1. The fix is instruction text, and this file states it — see below. A row would restate it and wait for a builder that has not run since 2026-10-07.
2. Part A of the original candidate is already owned and dated. The lens observed that §0c landed only in ops/DAILY_AUDIT.md though the panel made the error, and that ops/RESEARCH_PANEL.md, ops/ROUTINES.md, ops/STEWARD.md and ops/WEEKLY_AUDIT.md carry zero matches for fetch/stale/shallow/clone. True — but #260 names that gap explicitly and assigns the cross-routine edit to the monthly research audit (2026-11-01). A row for an assigned, dated residual is duplication.
3. open/ was at 12 of 12, and this run spends its one defensible slot on DLV-1, which bites this Friday.
4. The panel may not fix it itself. The remedy is an edit to the panel's own procedure, i.e. recursion on purpose, which NORTHSTAR.md §5 reserves to the owner's countersign. Propose-only is the correct posture, and a dismissal with the text written out is the cheapest form of the proposal.

The remedy, written out so whoever owns §0c can paste it

A further mode for §0c — add it by name, not by number (~0.1 pd): a shared working tree can be moved by a concurrent session. git status stays clean and git fetch detects nothing. Before any claim about merged content, re-read git rev-parse HEAD immediately before the read — or, better, do not read the shared tree at all: export the commit under review (git archive <sha> | tar -x -C <your own dir>) and measure there.

And the generalisation, which is the valuable half (~0.2 pd): a lens should be handed the SHA it is reviewing and assert it, rather than being told which branch to trust. The panel's own dispatch brief told three lenses the tree was at origin/main; that was true when written and false minutes later. A chair cannot promise the state of a tree it shares with itself.

Noted and deliberately not proposed: the mechanical version of part A — a clone-vintage banner on thales fleet status / fleet digest, in the shape of the existing market_session_date() banner (~0.5 pd). The shop already has a clone-independent liveness detector (thales fleet digest --fail-on-no-run, cli.py:3777, which correctly did not fire on 2026-10-20). Run 41's error was hand-reasoning past a mechanical detector that was already right, which argues the detector is not what is missing.

Reopen conditions (any one)

1. A routine publishes a second claim traceable to a moved or mis-vintaged tree — the first was run 41's false outage, this was the near-miss. A second published instance makes it a row, cap or no cap.
2. The 2026-11-01 research audit does not make the cross-routine §0c edit (§0c had gained a third mode, a fourth mode and two corrections within the single evening of 2026-10-21, and is still only the daily audit's file — six other routines clone the same way and none of their procedures say any of this), leaving ops/RESEARCH_PANEL.md and ops/STEWARD.md with no clone-vintage discipline. Part A then has no owner and reopens as one row with this leg.
3. A panel run is observed dispatching lenses against a tree it then moves. This run did exactly that; the reopen is for the recurrence, which would show the record did not bind.
4. The owner rules that a dismissal is a sufficient record site for a procedure defect found in the procedure's own run. Then this closes permanently — but the corollary is SCR-1's: ops/RESEARCH_PANEL.md must name the site, so the next such finding has a pinned reader rather than a passive verb.