Static Publishing, `sgit vault serve`, and the Publishing Matrix
A vault publishes to a folder: encrypted objects plus a small, declared plaintext surface (loader, cover, manifest, and — only when the vault is deliberately public — the read key). That folder is readable by a browser through the loader and by sgit clone over ordinary GETs, from any HTTP host or a local folder, with no server and no auth. sgit vault serve exists because browsers give local files an opaque origin — the one case everybody tries first, double-clicking index.html, cannot work without it.
2cedd9a: the raw sources under src/ are byte-identical to that commit's tree — verify with a diff against it. Each document below has a reader page with the same apparatus as the site's documents.The documents
| Document | Role |
|---|---|
| 00 — The executable dev brief | The brief a developer agent runs from: grounding reads, the six rules, per-phase tasks, definition of done |
| 01 — Architecture | The transport seam, publish-as-projection, the published layout, the manifest contract |
| 02 — Commands & UX | The command surface and every CLI / loader mockup — intended user-facing output, word for word |
| 03 — Flows | Sequence diagrams: publish → serve → read, the static clone, and the fork round trip |
| 04 — Invariants & tests | Six invariants asserted everywhere + fourteen test cells, collapsed from 240 combinations |
| 05 — Implementation phases | P1–P7 (plus P4b, published API docs) with file lists, acceptance criteria and risk; start with P1 + P3 |
| 06 — Decisions & evidence | Ten open decisions for the maintainer, and the measured evidence that re-scoped the spec |
| 07 — The publish output | Revised 19 Aug: publish takes no target — one fixed folder, target-agnostic, and the override question resolved at deployment |
| 08 — Published API docs | Added 18 Aug from the maintainer's proposal: openapi.json generated from the manifest, and Swagger UI as CDN-pinned or bundled |
| 09 — A first-party asset origin | Added 19 Aug from the maintainer's static.sgit.ai proposal: yes to the asset site, no to Pages, and never on the reader's critical path |
| 10 — Tabletop: one repo carrying the key, the files, and the vault | An executed end-to-end tabletop exercise: the maintainer's scenario run for real with the shipped CLI, producing four live findings |
Why it is on this site
Two of this pack's measured findings connect straight to claims this site publishes: custody without access requires a manifest (every filename derives from the read key, so a keyless client cannot name a single file — sharpening the PKI section's custody row), and object ids hash ciphertext with random IVs, so a fork is unlinkable — relevant to the attribution question. The published-folder model is also the substrate the serialised pull request workflow rides on.