Architecture decisions
Every load-bearing choice the platform makes is recorded here as a numbered ADR (Architecture Decision Record). The intent is transparency: if the platform behaves a certain way, the reasoning is in this list.
- 0001pnpm monorepo with apps/* and packages/*accepted
- 0002Multi-tenancy via single Supabase + organization_id partitioningaccepted
- 0003Stack: React + Vite + Express, TypeScript everywhere, port from internalizeaccepted
- 0004Tenant config: repo bootstraps, DB authoritative at runtimeaccepted
- 0005Public sites deploy to Cloudflare Pages, one project per tenantaccepted
- 0006API + admin portal deploy to Railwayaccepted
- 0007TypeScript strict mode everywhere, no exceptionsaccepted
- 0008Transparency-as-product: ADRs and decision-making are user-facing featuresaccepted
- 0009TDD and stability as primary; the RLS isolation test is the keystone gateaccepted
- 0010Google Workspace integration: view, never ownaccepted
- 0011Internalize is a reference, not an architectural exemplaraccepted
- 0012Use Supabase CLI for migrationsaccepted
- 0013Design system in `packages/ui`, mobile-first member-first shell, modal-for-edit, plain-text firstaccepted
- 0014RLS is the security gate; the UI gates affordances by role as a UX hint, not a security controlaccepted
- 0015Image storage = Supabase Storageaccepted
- 0017Storage uploads route through the API, not direct from the browseraccepted
- 0018Cloudflare Pages auto-provisioning is the default; manual override stays availableaccepted
- 0019Security posture and threat modelaccepted