for agents/llms.txtv0.6.75 · 6 Oct 2026

Home / Catalogue

The vault catalogue

An index of published vaults, rendered live from a vault that indexes vaults, including itself. Every entry carries a deliberately published read key, an honest evidence status, and its write-key status, because a vault whose write key is lost can never be corrected and a reader deserves to know.

The design constraint, stated openly: the bottleneck is one person with a backlog of vaults, so an entry costs a read key and one line: everything else (listing, sizes, commit count, whether an app is present) is derived by an agent opening the vault with the key it was just given. The two to-do queues are published in the catalogue itself: a named gap gets filled, an unnamed one does not. This page renders vault kc67yhgw directly, a push to it updates this page with no site deploy. The human companion is the published-vaults gallery: one page per vault, with the vault running live in it.
Where it stands, checked 19 September 2026. The catalogue vault holds nine entries and was last pushed when the site had nine published vaults; the gallery now has thirty. The twenty-one missing rows are not a queue problem (those vaults are published, audited and live on their own pages) they are a write-key problem: the catalogue can only be updated by whoever holds its key, and that is not the site's build. Until it catches up, the gallery and its machine-readable twin are the complete list, generated from one file on every release. What this page adds is the shape taxonomy, the evidence and write-key status per entry, and the proof that an index of vaults can itself be a vault.

Fetching the encrypted index…

Vault debug how this works →

not open yet
what you are looking at
Every row above is an encrypted object pulled from the SG/Send API and decrypted locally: click one: click one to see what it actually contains. Objects whose id contains -imm- are content-addressed and therefore immutable, so they are cached permanently; the mutable ref is the one mutable object, so it is checked at most once per freshness window (120s) rather than once per page, inside the window, reading the docs makes no requests at all, and check for new commit forces one whenever you want it.

The tree objects are the reason a first visit reads more than one file: filenames are encrypted inside them, so building the navigation means reading every directory. That index is a pure function of the commit id, so it is memoised, after the first visit, an unchanged commit reads no tree objects at all. Nothing here is stored on sgit.ai.
How this page works → Architecture diagrams, the object model, the cache tiers, and how a page like this one reads a vault it holds only the read key to.