[HARDENING] Place PENDING-164 (jurist) and PENDING-165 — the record gap, and the hook laundering

PENDING-164 drafted by the jurist, placed verbatim: a steward decision that
rewrote seventeen commits is absent from the entire authorization record, and
the jurist repo_activity window stops five weeks short of it. Confirmed from
this side by grep over the raw files: zero LFS mentions before today.

Executor addendum to it, found while measuring PENDING-165 and not while looking
for corroboration: 95760ff (2026-04-17) removed this same LFS hook pollution,
named it correctly in the commit subject, and filed nothing. It recurred twice
today. A second instance of PENDING-164 class, arrived at for free.

PENDING-165: the jurist severity question answered NO as posed — no governed
hook exists under the four names git-lfs writes — but the real failure is worse
in kind. 066a47a committed the shims into dotfiles on 2026-03-20 and they were
tracked for four weeks. Not overwriting a governed hook: laundering an external
tool output INTO the governed directory. REVIEWED-105 converse — an ungoverned
hook that looks governed — and the only instance in this thread with no party
present at installation.

Measured cost of the jurist proposed remedy: removing git-lfs strands exactly
one repo, the pre-LFS-export backup, 399 tracked files and 975 MB of local LFS
objects. That is the safety copy for the seventeen-commit rewrite.

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

PENDING.md

@@ -5966,3 +5966,77 @@ central finding is that care is not a mechanism.
 **Recorded against the steward's earlier question under PENDING-147:** this also settles that putting the transcript archive behind LFS would make its backup *worse*, not merely conditional. That option is closed on measurement.
 
 **Awaiting:** nothing from the executor. The reworded message is implemented (`2408032`) and is reversible in one edit.
+
+---
+
+## PENDING-164 — A steward decision that rewrote seventeen commits is absent from the authorization record, and no jurist instrument can reach it
+**Date:** 2026-08-26
+**Tag:** [HARDENING]
+**Drafted by:** the jurist. Placed verbatim by the executor.
+**Summary:** On 2026-06-05 the steward adopted Git LFS in chamber-library, found it a misfit, retired it, and rewrote seventeen commits of history to undo it (0677e8a); a per-repo hook exemption was built in its place (400c054). Neither decision appears anywhere in PENDING.md, PENDING-archive.md or REVIEWED.md. Twelve weeks later, on 2026-08-26, the executor filed PENDING-163 recommending a route toward LFS and the jurist recommended option (ii) — adopt LFS — outright. Three exchanges were spent before the refutation surfaced, and it surfaced by accident: the string 'pre-lfs-export' appeared in an unrelated directory listing.
+
+**Measured, two instruments sharing no code:**
+| | |
+|---|---|
+| `governance_search('LFS')`, 313 items across the three files | 1 hit — PENDING-163 itself |
+| grep over the raw files, prior to 2026-08-26 | 0 mentions |
+| all present mentions | 22, all filed this afternoon |
+| jurist's deepest reachable window, `repo_activity(chamber-library, 100)` | back to 2026-07-16 |
+| distance from that floor to 0677e8a | ~5 weeks |
+
+**The symptom is not the disease.** Two AI parties reasoning toward a retired mechanism looks like a discipline failure — nobody checked prior art. It is not, or not only. The jurist has no filesystem, `repo_activity` caps at 100 commits, and at chamber-library's rate that floor sits five weeks short of the decision. 'Search prior art before proposing' is not a rule the jurist can follow. The party that could look did not, but the record that was supposed to make looking unnecessary did not contain the decision either — and it did not look incomplete, because nothing marks the absence.
+
+**The class, stated narrowly:** decisions taken inside a repo — adopting a mechanism, retiring one, migrating away — are recorded in commit messages and nowhere else. Nothing routes them into the authorization record. There is no failing state and no falsifier; the record simply lacks them and reads as complete. This is adjacent to PENDING-108 (a ruling is filed only when someone remembers) but is not the same item: PENDING-108 concerns rulings that exist and go unfiled, this concerns decisions that never entered the queue at all. It is a datum for PENDING-89's question about whether jurist and executor misses cluster — here they did, on the same object, in the same hour.
+
+**Options:**
+- **(a) Nothing.** Accept that in-repo decisions live in commit messages and that the jurist rules without them. Costs nothing; today's cost is the measurement of what it costs.
+- **(b) An adoption/retirement register** — a single governance file, one line per mechanism adopted or retired in any repo. Cheap. Fails exactly as PENDING-108's evidence says hand-held records fail: filed when someone remembers.
+- **(c) Make the substrate reachable rather than copying it** — extend the read-only server with a commit-message search across the enumerated repos, unbounded by the 100-commit window. Nothing to keep in sync, because the substrate is already authoritative. Costs a tool change.
+- **(d) A pre-proposal check** — before any `[PROPOSAL]` naming a mechanism by name, the executor searches repo history for that name and reports the result with a positive control. Mechanizes the discipline on the side that has the filesystem.
+
+**Recommendation: (c) and (d), not (b).** (c) removes the asymmetry rather than papering over it, and is the next increment of the move REVIEWED-82 already made once — a tool returns the substrate, where a second party would return testimony about it. (d) covers the interval before (c) exists, and covers repos no tool enumerates. (b) is refuted by evidence already logged rather than argued against.
+
+**Tag note.** Filed `[HARDENING]` rather than `[ESCALATE]`, and the judgement is contestable: what the jurist can know bears on the jurist role, which is close to relational. It is filed at the lower tag because the defect is in a record-keeping path, not in the model itself. Re-tag if that reads wrong.
+
+**Numbering.** Every reference in this item is written in prefixed form and none as a bare number, per PENDING-110, which is open and unruled. This is not a proposed scheme.
+
+**Files affected:** none modified.
+**Awaiting:** Steward authorization.
+
+**⚠ EXECUTOR ADDENDUM — a second instance of this item's own class, found while measuring the third item below.** `95760ff` (2026-04-17), *"Remove global git-lfs hooks from dotfiles"*: someone noticed the pollution described in PENDING-165, diagnosed it correctly enough to name it in a commit subject, and removed it. **Nothing was filed and no mechanism was added, so it recurred twice on 2026-08-26.** The finding lived in a commit message for four months and reached no register — which is this item's thesis, arrived at independently and without looking for it. **The corroboration was free; that is the point. Nobody had to search, because the record's gap is the default state rather than an unlucky one.**
+
+---
+
+## PENDING-165 — An external tool writes into the governed hook directory on nobody's schedule, and its output was once committed as though governed
+**Date:** 2026-08-26
+**Tag:** [HARDENING]
+**Raised by:** the jurist, on observing the recurrence; severity question posed by the jurist and measured by the executor.
+**Summary:** `git-lfs` installs four hook shims — `pre-push`, `post-checkout`, `post-commit`, `post-merge` — into whatever `core.hooksPath` names. On this machine that is `~/dotfiles/git/hooks/`, the **global** hook directory for all 37 repos. Any LFS operation in any repo writes there, with no human in the invocation path.
+
+**The severity question, posed precisely and answered NO — but the true answer is worse than the question allowed for.**
+
+The jurist asked: does the directory carry a *governed* hook under any of those four names, such that an external tool is overwriting it? **It does not.** `git ls-files git/hooks/` returns exactly `README.md` and `pre-commit`. `pre-commit` is never touched by `git lfs install`.
+
+⚠ **But the four names are not absent from history, and what happened is a different failure than overwriting:**
+
+| commit | date | what happened |
+|---|---|---|
+| `066a47a` | 2026-03-20 | the four shims were **COMMITTED into dotfiles**, swept in by a commit titled *"Audit and optimize for CapableMind development"* |
+| `95760ff` | 2026-04-17 | *"Remove global git-lfs hooks from dotfiles"* — removed after **four weeks tracked** |
+| — | 2026-08-26 ~17:00 | recurred (`git lfs install --local`, whose `--local` was overridden by the global `core.hooksPath`) |
+| — | 2026-08-26 ~19:00 | recurred again, triggered by an LFS *filter* running during the measurement of LFS storage |
+
+**So the mechanism is not overwriting — it is laundering.** An external tool deposits files into the governed directory; a routine `git add` in dotfiles captures them; and they then sit in the tracked hook path, indistinguishable from hooks the steward wrote, executing on every push/checkout/commit/merge in every repo. **That already happened once and lasted four weeks.** REVIEWED-105's doctrine is that a disarmed hook must not look like an armed one; this is its converse — *an ungoverned hook that looks governed* — and it is the only instance in this thread where **no party is present at the moment of installation.**
+
+**Options:**
+- **(a) Nothing.** It is visible: the shims appear as untracked files in `git status` on dotfiles. That is how all four occurrences were caught. ⚠ But occurrence one was caught **after being committed**, so visibility did not prevent capture.
+- **(b) `.gitignore` the four names in `git/hooks/`.** Stops the laundering (they can never be committed) at the cost of stopping the *visibility* that has caught every occurrence so far. **Trades the detectable failure for a silent one — refused on REVIEWED-105 grounds unless paired with (d).**
+- **(c) Remove `git-lfs` from the machine** (`Brewfile:40`). Removes the vector entirely. ⚠ **Measured cost, and it is not zero:** exactly one repo depends on it — `~/_Dev/chamber-library.pre-lfs-export-20260605`, holding **399 LFS-tracked files and 552 local LFS objects totalling 975 MB**. Removing git-lfs turns that backup into unreadable pointer files. **Whether that 2026-06-05 pre-migration snapshot is still needed is the steward's call and nobody else's** — it is the safety copy for a seventeen-commit history rewrite.
+- **(d) A drift-check assertion** — `governance-drift-check.py` reports any file in `git/hooks/` that is neither tracked nor `pre-commit`. Turns a visibility that depends on someone reading `git status` into a check that runs. Composes with (b) and makes it safe.
+
+**Recommendation: (d), then (b) once (d) is live. Not (c) unless the pre-LFS backup is independently retired.** (d) is the only option that converts this from *caught four times by luck* into *reported*. (c) is attractive and clean but its cost is a 975 MB backup of a history rewrite, and trading a hook nuisance for a stranded safety copy is the wrong exchange to make without the steward.
+
+⚠ **This item is a datum for PENDING-164, not merely adjacent to it.** `95760ff`'s author diagnosed this correctly in April, named it in a commit subject, and filed nothing. Four months later it recurred twice in two hours. **The pollution is the lesser finding; that the April diagnosis reached no register is the greater one.**
+
+**Files affected:** `~/dotfiles/git/hooks/` (shims removed, twice, not otherwise modified); `Brewfile:40` (not modified).
+**Awaiting:** Steward authorization.