jeffryandClaude Opus 5
c6354c95fa
Not built. It mirrors a published surface once and then drifts silently — check watches documents you hold, not surfaces you mirror — which is this tool's own failure mode one level up. And it would make add mean both I depend on this and render all of that, which are different units of justification: loom/docs adopts ten documents and keeps five usages files, one per repository, hung off an arbitrary representative, because the convention offers per-document facets and a mirror's dependency is not per-document. Recorded with the falsifier that makes it useful later: if somebody genuinely needs a mirror that stays current, the feature is surface-watching — list compared against the lock set — and --all falls out of that almost free. 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.