COMMIT PIN 5d2b701e7329b8e501b88bc6c5cebbca0701d712 on main
  5d2b701e docs(infra): IR-122 — rig's isolated-daemon stop is unrunnable from a hosted session
  One file: docs/INFRA-REGISTER.md. 13 insertions, 0 deletions. Nothing else staged.
  Co-authored by: hertz — verified by raw body read at line 21, never %(trailers:).
TRACEABLE-REQS: traceable-reqs 0.4.1, check REAL_EXIT=0, 902 OK rows, no missing stages.
  I report the exit I actually read: my first run's "CHECK_EXIT=0" was tail's exit through a
  pipe and measured nothing. Re-run unpiped for the real status.

A DEFECT I CAUSED AND CAUGHT BEFORE IT REACHED YOU — worth your attention because it is IR-121
instance 4 recurring, in the very file that documents it, committed by the agent reading it.
My earlier edits used a Python TEXT-mode write. On Windows that translated every LF to CRLF:
HEAD is LF-only with exactly 2 lone CR bytes; my working copy came out 6679 CR / 6679 LF — the
WHOLE FILE flipped, plus IR-121's own two lone CRs converted to newlines, silently rewriting
two lines belonging to another entry. git diff --stat showed a harmless-looking "17 insertions,
2 deletions" because the CRLF flip is invisible through the repo's text normalization, so the
diff summary would NOT have told you.
Caught by reading the diff hunks rather than the insertion count — the same tell IR-121 records
("a one-bullet append that reports 5 insertions, 2 deletions is telling you it touched something
else"). Repaired by rebuilding the file from HEAD BYTES plus my block alone, in binary. Post-
state asserted: 13 insertions, 0 deletions, 2 lone CRs preserved, 0 deletion lines in the diff.
The committed content is my append and nothing else.
I am not filing this as a new IR — it IS IR-121, and its rule ("read bytes with a byte reader;
a text-mode read is a WRITE hazard") is already correct and already written down. It failed to
protect its own author, which by our own standard makes it a mechanism worth restating rather
than a new finding.

EVIDENCE LIMITS RECORDED, your wording kept rather than softened:
  1. The absence of secret-LIKE FILENAMES does not prove absence of secret CONTENTS. I ran a
     name-based search across the 125 archived files; I did NOT audit file contents and I am
     not claiming a content audit.
  2. The missing .secret directory does not establish WHO removed it or by what mechanism. I
     observed it present at 23:14Z and absent at archive time. That is a before/after
     observation, not a proven deletion path, and my earlier "the driver scrubbed it" named a
     mechanism I had not demonstrated — withdrawn.
  No seed material was read, copied, quoted or investigated; I did not open .secret's contents
  at any point, and I did not go looking for them to settle this.

ARCHIVE unchanged and still verified: 125 files, sha256sum -c exit 0, 125 OK / 0 FAILED,
MANIFEST.sha256 = dfe32a593bf40cd37d1c182b32e3d71f9de1cfd2e11edc42528b3362e7849237, which you
independently verified. I did not regenerate the manifest after your verification, so the hash
you checked is the hash that stands.

No implementation change, no product-guard change, no process action. Nothing of mine running.