00 — The executable dev brief
Summary
Written to be executed: the grounding reads in order, then the instruction the specification itself insists on — two things land before any hub architecture is written: the web-side capability audit, and the sub-vault decision. Six rules override convenience: the server reads nothing, ever (the catastrophic-failure principle as a design test); features follow the key, not the tier; classify keys by declaration and refuse a vault key in any read surface; never imply a capability that does not exist; sparse by default; and a hub is a vault — if hubs seem to need a server-side feature to talk to each other, stop. Eight steps from the audits to structure-key views, a definition of done per step, and an explicit list of what is not the builder's to decide.
Key concepts
- Step 0 before architecture — a design written without the inventory is wrong in one of two expensive directions: rebuilding what exists, or assuming what does not
- The catastrophic-failure design test — if a total compromise of the hub would disclose content that was not already public, the feature fails — out, not deferred
- Features follow the key, not the tier — anything a user holds a key to gets the full experience; only discovery across keyless vaults needs a reading index
Key ideas
- When a brief contradicts the code, the code wins — two of the briefing pack's open questions were already settled by measurement.
- The sub-vault decision is raised, never resolved in code: recommend, do not implement unilaterally.
- The moment a hub is necessary rather than convenient, the fractal stops being real.