feat: establish the module product contract

Ekklesia's module model has been backend-only since ADR 0001: a module
owns domain behavior and data, and every presentation concern belongs to
a surface. That prevents a module author — the person who knows the
domain — from shipping the screen that makes their module useful, and it
guarantees a module and its own UI drift apart. It also pushes toward two
codebases for one domain the moment a module needs to run standalone.

ADR 0021 replaces that rule. A module is an independently versioned
product that owns its domain behavior, data, permissions, routes,
migrations, and its own UI, hostable inside Ekklesia and — from the same
implementation — by a later standalone host. Core keeps the containing
application shell and every platform policy: authentication,
authorization enforcement, platform context, top-level routing,
navigation, global theme, error boundaries, and trusted-origin/CORS. The
module graph stays flat: modules are peers, genuine module and capability
dependencies remain the only relationships, and Dashboard folders are
presentation configuration an administrator can reorganize, never module
architecture.

This pass implements the static contract only. `manifestVersion` moves to
4 and `entrypoints` gains one optional field, `ui`. Version 3's
`entrypoints` is strict and rejects `ui`, so this is an incompatible
shape change and version 3 is now rejected outright rather than
reinterpreted, exactly as version 1 was by version 2 and version 2 by
version 3. Every field version 4 adds is optional, so upgrading a
backend-only manifest is a one-character edit.

Discovery resolves and validates `ui` under the same rules as `server`
and `schema` — package-relative, inside the package before and after
symlink resolution, a real file, compiled ESM `.js`/`.mjs`, so source
TypeScript is rejected rather than assumed to be compiled later.
Discovery stays inert: nothing imports, evaluates, mounts, or renders a
UI entrypoint, and a test proves a throwing artifact still discovers
successfully. This follows `entrypoints.jobs`, declared and resolved
since ADR 0006 with no runtime consumer.

The name is `ui`, not `dashboard`, because a module's UI must be hostable
by Ekklesia's shell and by a standalone host, so the contract cannot be
named after one of them; and not `surface`, because `surfaces/*` is a
separate ownership layer. No widget, route, icon, folder, menu, layout,
or standalone-metadata field is added, and tests assert the manifest
still rejects every unknown entrypoint key and offers no hierarchy field.

Deliberately unchanged: `scripts/check-boundaries.ts` still enforces
`modules-do-not-own-ui`. Relaxing that guard depends entirely on the UI
authoring model a later pass chooses, and weakening a working protection
before that decision exists would trade real coverage for nothing. A
module may therefore declare `ui` today only for a framework-neutral
compiled artifact, and the docs say so rather than implying otherwise.
Restart-based discovery, explicit operator-invoked migrations, and the
trusted compiled-module model are untouched — a module that ships UI is
exactly as trusted as one that does not.

No Dashboard shell, UI runtime, renderer, framework choice, navigation
registry, grouping system, standalone host, installer, hot-loading, or
feature module is added by this pass.

Co-Authored-By: Claude Opus 5 <[email protected]>

README.md

@@ -1,8 +1,8 @@
 # Ekklesia
 
-Ekklesia is an open, modular church technology platform for composing backend capabilities
-into independently developed dashboards, websites, mobile apps, kiosks, displays, and other
-surfaces.
+Ekklesia is an open, modular church technology platform. Each module is an independently versioned
+product that owns its domain behavior, data, and its own UI, composed into dashboards, websites,
+mobile apps, kiosks, displays, and other surfaces.
 
 ## Current status
 
@@ -11,7 +11,7 @@ Phase 4C (Core authorization), Phase 5A (module authorization integration), Phas
 transport), and Phase 5C (module database access) have landed. **Phase 5D (security hardening
 against an independent security audit) is complete: all five passes have landed and the final
 independent whole-repository re-audit has closed, under the current trusted-contributor,
-not-yet-deployed threat model — and Phase 6 (Surface work) is unblocked.** The operational
+not-yet-deployed threat model — and Phase 6 is unblocked and underway.** The operational
 requirements that remain are prerequisites for two specific *future* activities — executing
 untrusted CI contributions, and a public production launch — and neither gates Phase 6; see the
 pass 5 closure below and
@@ -60,9 +60,9 @@ on every mutation. Roles/groups/teams/tenants, an owner-management HTTP endpoint
 accounts/API tokens remain later work. See [Authorization](docs/development/authorization.md) and
 [ADR 0013](docs/architecture/decisions/0013-core-authorization-and-owner-bootstrap.md).
 
-Phase 5A wires module-declared permissions into that same authorization system: a version-3 module
-manifest declares permissions as complete `{id, baseline, description}` declarations (never a bare
-string), and `apps/api` discovers every installed module and composes one immutable platform
+Phase 5A wires module-declared permissions into that same authorization system: the module manifest
+(version 3 at the time, version 4 today) declares permissions as complete
+`{id, baseline, description}` declarations (never a bare string), and `apps/api` discovers every installed module and composes one immutable platform
 permission registry — Core's own declarations plus every module's — before constructing its
 database pool, Better Auth instance, or HTTP server. A module's declared permission is then
 enforceable and grantable through the exact same `requirePermission` middleware and
@@ -218,6 +218,31 @@ development proceeds under the current trusted-contributor, not-yet-deployed mod
 and job-token authority remain unverified and are not described as isolated. See
 [Security model and deployment trust boundaries](docs/development/security.md).
 
+Phase 6A establishes the **module product contract** and nothing else yet. Ekklesia's modules are no
+longer backend-only capability packages: a module is an independently versioned *product* that owns
+its domain behavior, data, permissions, routes, migrations, and — new in this pass — **its own UI**.
+Core keeps the containing application shell and every platform policy (authentication, authorization
+enforcement, platform context, top-level routing, navigation, global theme, error boundaries,
+trusted-origin/CORS). Modules stay **flat peers**: `video`, `livestream`, and `announcements` are
+independent first-class modules with no parent/child relationship, and a Dashboard folder such as
+`Media` is presentation configuration an administrator can reorganize, never module architecture and
+never a dependency. The long-term goal is one module implementation hosted by Ekklesia *and*, later,
+by a standalone application — never two codebases for one domain. See
+[ADR 0021](docs/architecture/decisions/0021-modules-as-hostable-products.md).
+
+**What this pass actually ships is the static contract only.** `manifestVersion: 4` adds one
+optional field, `entrypoints.ui`, a package-relative path to a compiled ESM artifact validated
+during discovery exactly like `server` and `schema` — inside the package, real file, no source
+TypeScript. Discovery stays inert: **nothing imports, mounts, or renders that entrypoint**, exactly
+like the long-declared `entrypoints.jobs`. Upgrading a backend-only version 3 manifest is a
+one-character edit; version 3 is rejected outright rather than reinterpreted, as version 2 was
+before it. **The Dashboard shell, a UI runtime or renderer, any UI framework choice, navigation
+registration, Dashboard grouping, a standalone host, a module installer or marketplace, hot-loading,
+and every feature module do not exist.** `pnpm boundaries` also still enforces
+`modules-do-not-own-ui`, so module UI cannot yet be authored with a UI framework — choosing that
+authoring model is the next pass's first question. Restart-based discovery, explicit
+operator-invoked migrations, and the trusted compiled-module model are unchanged.
+
 **Security model.** Installed modules are trusted compiled backend code that runs arbitrary
 JavaScript in the API process and shares its PostgreSQL role — table prefixes, manifests, permission
 declarations, typed facades, and frozen contexts are correctness boundaries, not a sandbox. Ekklesia