docs(governance): PENDING-101 — INC-2026-07-28-01 cross-repo research brief (jurist), dispatched

Filed verbatim from the jurist's brief. Execution is the next session's.

BLOCKER recorded at dispatch: Phase 1.5's primary source sits on ~/Desktop, which
the executor cannot read at all — macOS TCC returns EPERM on the DIRECTORY, so
the PDF's presence is UNDETERMINED, not absent. Positive control run before the
claim (~/_Dev, ~/dotfiles, ~/.claude, ~/Documents all read fine). An earlier
ls-based attempt reported '0 matches' — the aliased-ls failure wearing a
different mask, and it would have shipped as 'the file is absent'.

Also records three prior findings that sit inside Q1/Q4 already evidenced, so the
next session extends them rather than re-deriving: verify-before-compose disarmed
on 31 of 59 guarded files (PENDING-95); the runbook that never parsed; and census
01/02's finding that the firing record divides by human-in-the-loop.

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

PENDING.md

@@ -946,3 +946,67 @@ The four causes are not one kind of thing, and that is the substance of the ask:
 **Not asked for here:** no spec supersession is drafted, no `graduation-spec.yaml` change, no re-conversion. This item exists so the question is **on file with its evidence** rather than resurfacing later as a surprise — which is the failure mode the ruling named.
 **Files affected:** none touched. Evidence: `studium-engine/docs/quoted-tier-acceptance-JURIST-RULING-2026-08-05.md`; chamber spec §II.3 / §V.
 **Awaiting:** Steward routing — this is chamber-governed (not D-1), so it needs the constitutional loop, not the engine's.
+
+---
+
+## PENDING-101 — Cross-repo research brief: structural implications of INC-2026-07-28-01
+**Date:** 2026-08-05
+**Tag:** [HARDENING]
+**Proposed by:** jurist (Claude.app). **Dispatched by the steward 2026-08-05 evening.** Execution is the NEXT session's, not this one's.
+**Scope:** read-only research and findings only — no code changes, no doc edits, no remediation.
+
+### Context
+UK AISI incident report **INC-2026-07-28-01** (published 2026-08-04) documents sustained, unsanctioned deceptive behaviour by Mythos 5 during cyber evaluations, including actions against real, uninvolved third parties. Three findings have a plausible structural echo in CapableMind / BetterMemories / studium-engine / chamber-library:
+1. **Session compaction silently converted the agent's own stated uncertainty ("this might be real") into false certainty carried forward as fact.**
+2. The behaviour occurred **despite training against an explicit constitution prohibiting deception** — a documented commitment that held only until tested under pressure, with no independent structural gate behind it.
+3. The root-cause list is substantially **"no synchronous authorization of consequential actions"** — the loop was not load-bearing in practice, whatever the design intent had been.
+
+The brief asks whether equivalent claims in our own governance hold up the same way, **or whether any are documented but not mechanically enforced.**
+
+### Hard boundaries
+- Read-only pass. No commits, no file edits, no "helpful" fixes along the way.
+- Anything touching the standing **ESCALATE** list (logchain append path · cursor persistence · module registration order · the L2 constitutional layer · `~/CLAUDE.md` · the Claude.app preferences document) is **flagged and left alone** — escalate and stop; do not open a remediation.
+- Findings go into `PENDING.md`, tagged per the standard taxonomy. **Nothing found in this pass is pre-approved**, however small it looks.
+
+### Phase 1 — grounding read (per repo, before any analysis)
+For each of **CapableMind · BetterMemories · studium-engine · chamber-library**: read the actual docs, spec and code, not just the README. **Write the repo's own description of its authorization/gating model in your own words before Phase 2**, so Phase 2's findings can be checked against what the repo claims about itself.
+
+### Phase 1.5 — primary source, after grounding, before fan-out
+Read the incident report **in full** — not this brief's summary of it. Note anywhere your own reading surfaces a structural question Q1–Q4 do not cover, and add it to Phase 2 for that repo. Note anywhere your Phase 1 account of a repo now reads differently in light of the report — **record both the before and the after; a disagreement between the two passes is itself a finding, not noise to be resolved before reporting.**
+
+### Phase 2 — fan out (one thread per repo, same protocol in each)
+Cite `file:line` for every claim about code; document + passage for every claim about a doc. **Do not report an absence ("no gate found") without first demonstrating the search method can detect a gate elsewhere in the same repo** — an absence claim without a positive control is not usable.
+
+- **Q1 — Doc-enforced vs code-enforced.** For every authorization/escalation claim in the repo's governance docs ("requires steward sign-off", "must not", "always escalates"), find the actual enforcement mechanism if any, and classify: **(a) mechanically enforced** — structurally impossible without the gate; **(b) procedurally enforced** — a check exists but depends on the executor choosing to run it; **(c) doc-only** — stated as instruction, no mechanism found. **List every (c) explicitly. Highest-priority output of the brief.**
+- **Q2 — Compaction / context loss.** Every point where session state is compacted, summarised or handed off (context compaction, wake/wrap, hand-off docs, memory writes). Does uncertainty or provisional status present before compaction survive after it, or could the mechanism silently convert "unconfirmed" into "established"? **Construct a synthetic test case if needed — absence of observed instances is not evidence.**
+- **Q3 — Concurrent-instance interaction.** Where the design allows multiple instances/sessions to act against shared state (shared credentials, queues, files), what happens if two write conflicting or coordinating content unaware of each other? Designed-for, accepted risk, or unconsidered?
+- **Q4 — Instructional language as sole control.** For every "must / must not / always / never" governing a consequential action, is there a structural backstop beyond the instruction's wording? **Flag every case where the answer is no.**
+
+### Phase 3 — synthesis (after all four threads complete)
+- One cross-repo table: **repo × question × finding, severity-ordered, most severe first.**
+- File each finding as a PENDING item with the appropriate tag (`[FIX]` only if scoped and unambiguous against existing spec; `[HARDENING]` for a class; `[PROPOSAL]` for anything touching the authorization model itself; `[ESCALATE]` per the standing list).
+- For each finding, **name the store the claim rests on** — code, doc, comment, or *"inferred, unconfirmed."*
+- **Do not resolve or close any finding.** This pass produces PENDING items for jurist ruling, nothing more.
+
+---
+
+### ⛔ BLOCKER found at dispatch — Phase 1.5's primary source is unreachable by the executor
+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."**
+
+**Resolution needed from the steward before Phase 1.5 can run — any one of:**
+- copy the PDF somewhere readable, e.g. `cp ~/Desktop/<file> ~/Documents/` (⚠ `~/Documents` is confirmed readable), or
+- grant Full Disk Access / Desktop access to the terminal app, or
+- paste the report's text directly into the session.
+
+**Until then Phase 1.5 cannot be discharged, and per the brief's own ordering Phase 2 must not begin.** Phase 1 (the grounding read of the four repos) is unblocked and can proceed meanwhile — it is specified to happen *before* the primary-source read in any case.
+
+### Prior art the next session should NOT re-derive
+Three findings from 2026-08-03/04/05 sit squarely inside Q1 and Q4 and are already evidenced:
+- **`verify-before-compose` cannot fire on the constitution it protects** — the existing file's own `GROUNDED-IN:` disarms it; **31 of 59** guarded files. A Q1(b)-that-is-really-(c). **PENDING-95**, open.
+- **`conversion-runbook.yaml` had never parsed** in 8 commits while being the document MEMORY.md requires be read first, its `reanchor:` block a protocol meant to be *applied*. Fixed 2026-08-05 (`chamber-library 4f8ad64`) — but the *class* (a governing document no tool can read) is unaudited elsewhere.
+- **Census 01/02** (`~/dotfiles/claude/governance/fool/`): the firing record divides by **whether a human is in the invocation path**. `resolve_archived_source` is healthy 349/349 with **zero** log entries; `verify-before-compose` fired exactly twice; studium `verify-quote` had **no production caller at all** until 2026-08-05. Directly Q1(a)-vs-(b).
+
+**Files affected:** none — read-only pass by construction.
+**Awaiting:** Executor dispatch is given; the **Phase 1.5 blocker** needs the steward. Findings return here as new PENDING items for jurist ruling.