Commit Graph
4 Commits
Author SHA1 Message Date
David F GliddenandClaude Opus 5 46aa3d15a2 [FIX] REVIEWED-131: build PENDING-165 (d) as an allowlist, then (b) narrowly
(d) — governance-drift-check.py now DECLARES the contents of ~/dotfiles/git/hooks
(README.md, pre-commit) and reports anything unexpected or declared-but-missing.
Tracked-ness is never consulted, and that is the correction: the filed form tested
"neither tracked nor pre-commit", and 066a47a was TRACKED for four weeks, so it
would have been silent throughout the only occurrence that did damage. Asserted
structurally, not in prose — a control checks that scan_hooks' code names contain
neither "git" nor "subprocess".

(b) — .gitignore for the four git-lfs shim names. DELIBERATELY NARROW: a blanket
git/hooks/* + allowlist would silently prevent committing a new legitimate hook,
which would work locally, never reach the repo, and be invisible to (d) because
(d) reads the filesystem and not the index. Verified the pair composes: a planted
shim yields 0 entries in git status AND is reported UNEXPECTED by the check.

⚠ And a fifth self-referential instrument event, in the fix for that very class.
The five new controls were appended after failed_controls is computed (702 vs
846): all ran, none counted, tally still read 48/48, and a failure among them
would have printed NOTHING. The check against blind checks was blind to itself.
Caught by comparing the printed tally to the number of controls added. Moved above
the report block (53/53) and verified by breaking one deliberately and confirming
it prints INSTRUMENT NOT VERIFIED and names itself.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NvZAKSf9aqratbqHbU9LK5
2026-08-26 18:58:06 +02:00
David F GliddenandClaude Opus 5 7ed9c206af chore(ledger): the LFS hook pollution recurred — hazard, not slip
Removed once this afternoon; back within two hours, triggered by an LFS filter
running during the git-vs-LFS storage measurement. git-lfs installs its hooks
into whatever core.hooksPath names, which here is the global hook directory.
Any LFS operation in any repo on this machine writes four shims there.

Deliberately not gitignored: they show as untracked files in dotfiles status,
and ignoring them would hide the pollution rather than surface it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NvZAKSf9aqratbqHbU9LK5
2026-08-26 18:19:58 +02:00
David F GliddenandClaude Opus 5 171be14ab7 chore(ledger): log the --local-that-was-not-local side effect
git lfs install --local wrote four LFS shims into the GLOBAL hook directory,
because core.hooksPath redirects there. Reverted. Caught by reading git status
at the end, not by expecting it — another instance of the class filed as
PENDING-160 this morning, made while writing it up.

Verified rather than assumed: pre-commit untouched, and filter.lfs.* in
.gitconfig is pre-existing (dotfiles-tracked, unmodified).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NvZAKSf9aqratbqHbU9LK5
2026-08-26 17:28:46 +02:00
David F GliddenandClaude Opus 5 57f83740a5 [FIX] Resolve the STATE-CLAIM; [HARDENING] file PENDING-163; add the preservation instrument
STATE-CLAIM: memory-index-claims-reviewed-127-unplaced -> resolved, pointing at
7a92460. Verified end to end by re-running governance-drift-check.py rather than
trusting the write: "1 of 3 open are NOW FALSE" -> "2 tracked, none falsified /
plus 1 RESOLVED", no dangling-pointer defect, so the resolution parses AND its
pointer resolves. The `resolved:` form was derived from the parser, not from
memory of the schema, which is also why the correction commit had to come first.

What that discharge is evidence for is written into the item so it cannot be
quoted as more: one marked claim, marked by its own author, corrected in the
immediately following session. Expressibility, not adoption. The 57 unmarked
claims are untouched.

PENDING-163 [HARDENING]: the global pre-commit hook refuses files over 5MB and
prints "Consider using Git LFS", but measures `wc -c < "$file"` — working-tree
size — so an LFS-tracked file stages as a ~130-byte pointer and is still refused.
Tried it; same refusal, same file. The hook is NOT modified: it is global and
governed by REVIEWED-100/105.

preserve-transcripts.py: PENDING-147 option (i). The archive itself is NOT in this
repo — 115MB of transcripts is not dotfiles material, which is what the hook was
right about even though its reasoning measures the wrong thing. It lives at
~/_Dev/claude-transcript-archive, outside the harness's pruned path, which is what
actually stops the clock. 43 transcripts, read-back PASS.

No guard was bypassed: no --no-verify, no per-repo core.hooksPath override, and no
empty .git left behind that would make the archive look tracked when it is not.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NvZAKSf9aqratbqHbU9LK5
2026-08-26 17:26:22 +02:00