jeffryandClaude Opus 5
e0ef0d02f8
Reported from use in another repository, reproduced before diagnosing, and the report was right and understated: two staging sites built a lock record without visibility, not one, and one of them was in add where the value was already computed three lines above. Fixed twice over, because the two fixes answer different questions. A staged copy is new bytes, so its visibility is evaluated afresh rather than inherited — a source that has gone private since adoption is a new exposure created at the moment of applying, and inheriting the old value would record a fact about bytes nobody holds any more. And apply now never lets an absent value overwrite a known one, which covers polads staged by an older build, the state the reporter is in. Pinned by a regression test. No test we had would have caught it: both sites round-trip correctly in isolation, and the field only vanishes across the handoff between them. The lock header says visibility is recorded because access is checked once and the copy is durable. A field that documents its own reason for existing, and is then dropped by the one operation that updates it, reads as verified and is blank. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018UTxuSizozEA8yDitPuris
loom-cli
loomctl fetches the documents this repository depends on, and tells you when
they change. It reports; it never repairs.
go build -o loomctl .
./loomctl --help
check only reads. Nothing here writes over the network, so a credential it is
given never needs write scope.
Why it is the way it is: .loom/event-log.md. Every
entry says what was decided and the belief that could turn out to be false.
What it depends on, and what we could not tell from those documents:
.loom/externals/ — the .gaps.md files beside each one.