ekklesiaandClaude Opus 5
616c1d4834
Phase 6C pass 2. Every link in the module UI chain existed except the one that closes it: a module could be authored, built, validated, published at a browser URL, and loaded by a generic loader — and nothing in Ekklesia did any of it. There was no browser application at all. Two pieces were missing. A browser could not discover what to mount, and it must not work that out for itself. GET /api/v1/module-ui is the inventory: per publishable module, its id and version, the server-produced artifact URL, the server-produced root of the module's own API, and the subset of that module's declared permissions the caller holds. Five fields, each because building a ModuleUiHostContext needs it — no filesystem paths, and no name/icon/folder/order, because navigation metadata is a design that does not exist yet. Its module set is the ADR 0025 publication registry rather than a rescan, so the inventory and the artifact route cannot disagree. It requires a new Core permission, core.modules.ui.read (baseline authenticated), because it is precisely the enumeration the anonymous artifact route deliberately withholds. Both URLs are server-produced. moduleUiArtifactUrl already existed; moduleApiBaseUrl is now exported and moduleRoutePath builds on it, so each URL shape has exactly one author. Without it the shell would hardcode /api/v1/modules/<id> — the prefix ADR 0022 forbids a module UI from spelling, reappearing in the host instead. surfaces/shell (@ekklesia/shell) is the repository's first surface: a small React application built to static files by its own esbuild script. It resolves the principal, fetches the inventory, builds the host context entirely from server-derived data, and hands the artifact URL to @ekklesia/module-ui-host. One frame per selection — keyed by module identity — defeats the stale-load race; the host owns the container, the loading state, and every failure, so a broken module costs its own panel rather than the shell. The shell statically imports no module, and both levels are checked: no source import may name a module, and the emitted bundle must contain exactly one dynamic import (the loader's) with no module id, no /api/v1/modules, no eval, and no blob URL. Permission hints come from Core's own evaluator and stay presentation-only — the end-to-end test has a UI holding no grant call its API anyway and still receive 403. Surfaces may now depend only on browser-safe shared roles; @ekklesia/contracts is deliberately excluded, since its barrel pulls Drizzle's types and Node's globals into the browser — the hole ADR 0024 closed one layer down. Not the Dashboard: no navigation, grouping, icons, ordering, design system, or routing. The selector is a list of module ids. Co-Authored-By: Claude Opus 5 <[email protected]>
7.5 KiB
7.5 KiB
Repository boundaries
These rules map platform ownership to filesystem and package boundaries. The executable check is
pnpm boundaries; CI must reject violations.
| Area | Owns | May depend on |
|---|---|---|
apps/* |
Thin deployable composition roots | Public Core APIs, generated bootstrap, or a surface as required by the app |
core |
Feature-agnostic platform implementations | Public contracts and external infrastructure libraries |
modules/* |
Domain capability, data, and the module's own UI | Module SDK, module UI SDK, public contracts, React, and external backend libraries |
surfaces/* |
The application shell, UI, renderers, navigation, and interaction | Surface SDK, API/auth clients, the module UI SDK and host loader, design packages, and a browser framework |
builders/* |
Declarative surface composition tooling | Builder/surface SDKs and public contracts |
packages/* |
Explicitly scoped SDKs, contracts, clients, design, testing, or tooling | Only dependencies appropriate to the package's declared level |
templates/module |
A small example backend module | The same dependencies allowed for any module |
Mandatory rules
- Core never imports a feature module, surface, Builder implementation, or app.
- A module never imports Core implementations, another module, a surface, Builder code, or an app.
- A module may own UI (ADR 0021) and authors it in
React and TypeScript (ADR 0022). A
module may therefore contain
.tsxsource and depend onreact,react-dom, and@ekklesia/module-ui-sdk. It still cannot contain.jsx, stylesheets, single-file components, Astro/Marko/MDX/HTML views, or SVG presentation assets, and cannot depend on any other UI framework (includingreact-router-dom,react-native, and@vitejs/plugin-react) or on shared UI-role packages. A module needs no bundler plugin:@ekklesia/module-ui-build— atoolingpackage, a role modules could already depend on — owns the entire module UI build (ADR 0023). An unsupported framework aliased behind an allowed name is resolved and rejected by its real target. - Module UI source is subject to the identical layer rules as module backend source: it may not
import Core, an app, a surface, a builder, or another module. It also may not import
@ekklesia/module-ui-host: that package is host infrastructure, and a module bundling the loader would blur the author/host split (ADR 0024). @ekklesia/module-ui-sdkhas no dependencies at all, and@ekklesia/module-ui-hostdepends only on it. Both are browser-safe by construction: neither can pull a backend type graph — and with it Node's global declarations — into browser code. Core still owns the containing application shell and all platform policy, and module UI reaches the host only through@ekklesia/module-ui-sdk.- Module UI asset publication runs Core →
apps/api, never the other way (ADR 0025). Core owns the policy (createModuleUiPublicationRegistry, built only from already-validatedDiscoveredModulerecords);apps/apiowns the HTTP route and the one canonical URL construction. Neither@ekklesia/module-ui-hostnor@ekklesia/module-ui-sdklearns anything about how Ekklesia publishes artifacts — the loader takes a URL and stays host-neutral — and no module may reach publication internals. This introduced no new package and no boundary relaxation:apps/*could already depend on Core and on shared packages. - A publication helper accepts module identity only. Neither Core's registry nor the API's URL builder takes a filename, relative path, or any other artifact selector, so no caller can use one to reach a second file inside a module package.
- A surface never imports Core or a feature module. It uses public API/client contracts, and reaches the server over HTTP.
- A surface may depend only on browser-safe shared roles (
api-client,auth-client,design-tokens,module-ui-host,module-ui-sdk,surface-sdk,ui) plus dev-timetestingandtooling.@ekklesia/contractsis deliberately excluded, despite being a "public contract" package: its barrel pulls Drizzle's types, and with them Node's global declarations, into any program that imports it — measured in ADR 0024, which removed exactly that import from@ekklesia/module-ui-sdkto close the browser boundary.module-sdkre-exports the same barrel and is excluded for the same reason. A surface declares its own types for the wire and validates what arrives (ADR 0026). - The browser host (
surfaces/shell) statically imports no module. Every installed module UI it can mount arrives at run time as a URL from the module UI inventory, is fetched by the generic loader, and is never bundled into the shell. Its own build (esbuild, owned by that package) is a separate concern from@ekklesia/module-ui-build, which compiles a module's declared artifact. - Separate surfaces do not import each other's internals.
- Builder code composes contracts and surface renderer identifiers; it does not import module or surface internals.
- Contract and SDK packages cannot depend upward on implementations.
- Workspace package consumers use declared
exports, not private subpaths. - Every internal dependency uses a
workspace:range and every imported workspace package is declared by the consumer. - Workspace aliases are forbidden because they obscure package ownership in the dependency graph.
- Workspace package names are unique and shared packages declare a recognized architectural role.
- Circular source and workspace-package dependencies are rejected.
- Cross-module data access uses services, events, capabilities, or opaque identifiers rather than direct table imports and foreign keys. Modules may not import another module's Drizzle tables, columns, relations, schema entrypoint, or migration internals.
The boundary test suite includes intentionally invalid fixture graphs. This proves that the guard rejects every currently machine-checkable repository rule even before production packages fill every directory. The UI guard rejects component, view, template, stylesheet, shared UI-role, and common UI-framework dependencies inside modules. This deny list is defense in depth; package review remains required when adopting a new frontend technology. ADR 0022 narrowed the guard precisely rather than removing it: React was un-denied, every other framework stayed denied, and the layer rules were untouched.
The Phase 3 schema validator complements source boundaries by checking table ownership, foreign-key targets, and physical table namespaces in compiled Drizzle metadata. Offline migration validation checks each module's packaged Drizzle inventory and policy contract, while deliberately making no claim that opaque SQL ownership can be proven without PostgreSQL-aware analysis.
Generated code
Generated artifacts are reproducible outputs with a named generator and validation step. A
generated module bootstrap under the root generated/ boundary may import discovered module entry
points, and apps may import that generated bootstrap. Handwritten app and Core code still cannot
import feature modules directly. Generated files are never an excuse for a hand-maintained central
module registry.