Dependency Resolution
BrightWeb resolves module order from the registry, not from ad hoc assumptions. The current chain is linear: Core first, then Admin, then CRM, then Projects.
Current dependency rules
- CRM requires Admin. CRM policies and shared workflows assume the RBAC and governance layer already exists.
- Projects requires CRM. Projects attach to organizations and reuse CRM-owned organizational structure.
- Admin depends on Core. RBAC extends the shared profile and auth foundations in Core.
Resolved install-order examples
| Install shape | Resolved order | Note |
|---|---|---|
| Base only | Core → Admin | In workspace mode the generator keeps Admin governance enabled for platform auth and RBAC even if the admin UI surface is not selected. |
| Base + CRM | Core → Admin → CRM | CRM depends on Admin, so RBAC and governance land before CRM schema and logic. |
| Base + CRM + Projects | Core → Admin → CRM → Projects | Projects depends on CRM, so the install order is fully resolved before client-only migrations. |
Where the order comes from
supabase/module-registry.jsondefines the module graph.scripts/_db-modules.mjsresolves enabled modules into a concrete apply order.- The scaffold generator mirrors that logic when it creates
supabase/clients/<slug>/stack.jsonin workspace mode.
Base-only nuance: even if the admin UI module is not selected as a starter surface, the current workspace generator still keeps Admin governance enabled when resolving the database stack for a platform app.
Related docs
Repo sources
supabase/module-registry.jsonscripts/_db-modules.mjspackages/create-bw-app/src/generator.mjssupabase/README.md
Repo source
docs/architecture/dependency-resolution.mdThis page is rendered directly from the root docs folder. Edit the markdown there, not inside the app.
PreviousArchitecture ReferenceThis section holds durable architecture notes, migration policy, and database ownership decisions.NextDatabase FlowBrightWeb uses a modular database ownership model. Shared migrations live under module folders, client stacks declare enabled modules, and the repo can plan or materialize an installable Supabase workdir from that resolved stack.