docs(governance): PENDING-101 blocker resolved — Read reaches Desktop, bash does not

The steward supplied the path; the Read tool opens it (1023.8KB, ~36pp). The bash
sandbox still cannot, so the instrument matters and is now named in the item.

Records the generalisable lesson: 'I cannot read X' was true of one instrument
and false of another, and I twice reported the instrument's limit as a fact about
the world (aliased ls -> count 0; find -> silent empty) before controlling it.
The brief already demands a positive control before any absence claim about a
gate; the same rule was needed one layer down, on my own file search.

Also records a small real contamination: pages 1-3 were read tonight to test
reachability, so tomorrow's Phase 1 baseline is knowingly formed with the
executive summary already seen. Named rather than pretended away — the brief
orders Phase 1 before Phase 1.5 precisely to keep that baseline clean.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AB3Kryoy6b1pm2Nz1DYdLh

PENDING.md

@@ -990,7 +990,14 @@ Cite `file:line` for every claim about code; document + passage for every claim
 
 ---
 
-### ⛔ BLOCKER found at dispatch — Phase 1.5's primary source is unreachable by the executor
+### ✅ BLOCKER RESOLVED 2026-08-05, and the resolution is itself worth recording
+**The `Read` tool reaches `~/Desktop`; the bash sandbox does not.** Confirmed live: `Read('~/Desktop/6a724858f7db25c81487016d_Security Incident INC-2026-07-28-01.pdf', pages='1-3')` returned the title page, contents and executive summary (1023.8 KB, ~36 pp incl. appendices A–B). **Use `Read` for this file; do not route it through bash.**
+
+⚠ **The lesson generalises and should not be re-learned tomorrow:** "I cannot read X" was true of one instrument and false of another, and I reported the *instrument's* limit as a fact about the *world* twice before controlling it — first via aliased `ls` (`count: 0`), then via `find` (silent empty). Both would have shipped as "the file is absent." Before any absence claim in Phase 2, name the instrument and show it detecting a positive case, exactly as the brief already requires for gates.
+
+⚠ **Recorded contamination of the Phase 1 baseline, small but real:** pages **1–3** were read tonight to test reachability — title, table of contents, executive summary. That is enough to know the report's shape and its headline finding; it is *not* the Phase 1.5 read. The brief orders Phase 1 **before** Phase 1.5 precisely so the "before" account of each repo is uncontaminated, and asks that a disagreement between the two passes be reported rather than resolved. Tomorrow's session should note that its baseline was formed with the executive summary already seen, and treat that as a known, bounded exposure rather than a clean slate.
+
+### (superseded) BLOCKER as found at dispatch
 The brief names `~/Desktop/6a724858f7db25c81487016d_Security Incident INC-2026-07-28-01.pdf`. **The executor cannot read `~/Desktop` or `~/Downloads` at all** — macOS TCC returns `PermissionError errno=1, Operation not permitted` on the *directory*, not `No such file`. So **whether the PDF is present is undetermined**, not negative.
 
 *Positive control, run before the claim:* the same method reads `~/_Dev` (16), `~/dotfiles` (39), `~/.claude` (34) and `~/Documents` without error. The blocker is the two directories, not the method. ⚠ An earlier `ls`-based attempt returned "0 matches" — **that was the aliased-`ls` failure mode wearing a different mask, and it would have been reported as "the file is absent."**