02 — Capability audit
Summary
The specification says the first deliverable is an inventory, not architecture; this file does the CLI half — which nobody had done, and which produced the pack's two findings. Present and merely surfaced by a forge: read-key-only open, tree navigation, single-object fetch, history, diff, branch/merge, sparse fetch, and the per-path index shipped as the cache layer. Present but unused: the structure key, a third access tier that decrypts metadata — paths, tree shape, history, sizes — but no blob content, with one consumer and full tests. Absent: the sub-vault/link-file primitive every brief builds granularity on, blame, bisect, and cross-vault search without a key (impossible by construction). The web-side template follows, with two rows added so absences are recorded on both sides rather than assumed present on the other.
Key concepts
- Finding 1: the missing primitive — no sub-vault or link file exists anywhere in the CLI — the permissions-as-topology model in every brief currently has nothing to stand on
- Finding 2: the structure key — browse the shape without reading the files — shipped, tested, one consumer; a permissions tier and a commercial tier at the same time, looking for a product
- Surfacing vs adding vs absent — the classification every forge feature must carry, so the plan never silently assumes a capability into existence
Key ideas
- A partial capability is more dangerous to a plan than an absent one, because it gets assumed complete.
- Four usable key positions exist, all shipped, none requiring server policy — the briefing pack works with only two of them.
- Report gaps as plainly as presences: the audit's value is the absences it puts on the record.