# 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):

| fingerprint | stale (`b9e7c1a`) | correct (`9e28a45`) |
|---|---|---|
| `data/options_iv_term` files | 47 | **48** |
| `data/shortability` files | 51 | **52** |
| `data/options_skew.jsonl` dates | 84 | **85** |
| `_SEPT_2026_OUTAGE` in `captures.py` | **absent** | present |
| `ACKNOWLEDGED_GAPS` keys | 4 | **7** |

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.