Konglo OS

"Most wealth dashboards are cloud SaaS you must trust with your most sensitive data. Konglo OS is the opposite: a self-hostable, single-tenant OS where the data lives on *your* infrastructure, access is enforced on the server (not hidden in the UI), and the succession plan is principal-only by construction."

Server-enforced access was a correction he made to his own build rather than the starting design: UI-only gating left a confidentiality read gap, so `requireUser` / `requireAdmin` / `requirePrincipal` / `requireFeature` were pushed down into the Convex handlers across eighteen feature directories, and the master schema became a composition of per-feature fragments instead of one accumulating file. For the generic CRUD surface he refused to keep maintaining a lookalike — the real `notion-database` slice was vendored in verbatim (72 files, pruned to the table-view subset) behind an adapter, with a narrow eslint override scoped to the vendored directory so the files stay byte-for-byte re-mergeable upstream. Complexity is tracked as a ledger rather than a feeling: `docs/ponytail-audit.md` ranks ten dedup cuts found by a 5-agent parallel audit, batches 1–4 were applied as disjoint-file parallel conversions validated by the twelve `*-writes` tests, and two findings were explicitly assessed as below the bar and left inline because “grinding them is the over-engineering this audit exists to prevent”.

536 tests now gating every push — the gate had been silently skipping all 326 Convex ones