feat: define the module UI authoring model and host contract

ADR 0021 established that a module may own UI and added a statically
validated, never-executed `entrypoints.ui` path, but deliberately left
five questions open: what the artifact exports, what a host provides,
how one artifact runs under both Ekklesia and a standalone host, what
the browser-side trust model is, and how module UI avoids being welded
to a Dashboard that does not exist. This answers them.

React and TypeScript are the supported module UI authoring model. The
repository already leaned this way: `packages/typescript-config` ships a
`browser.json` preset and a `react-native.json` preset with
`"jsx": "react-jsx"`, and ADR 0002 names browser and React Native
configurations. One framework is supported; every other stays rejected.

React is deliberately not part of the contract. A module's compiled
artifact default-exports `defineModuleUi({ id, version, mount })`, and
`mount(container, context)` takes a DOM element and returns an unmount
function. `id` and `version` are build-artifact identity markers a host
verifies against the manifest, mirroring `defineModuleRuntime` exactly.
A host needs an element and a context, never a matching rendering
library, so a module's framework, a host's framework, and the platform
boundary between them stay independent.

The contract lives in a new `@ekklesia/module-ui-sdk` rather than in
`@ekklesia/module-sdk`, for a concrete reason: that package re-exports
all of `@ekklesia/contracts`, so routing module UI through it would drag
Zod, Drizzle, and semver into every browser bundle. The new package has
no runtime dependencies, and its one dependency on contracts is
type-only — the emitted `host-context.js` is `export {};`, and a test
pins that so it cannot regress.

The host context is four members: `moduleId`, `api`, `principal`, and
`permissions`. Navigation, theme, module configuration, organization
context, and diagnostics are deliberately absent; each needs a design
that does not exist. Module UI reaches its backend through
`api.request(path)` with a path relative to its own API root and never
constructs `/api/v1/modules/<id>/...`, which is Ekklesia's private
deployment detail — a module that builds that URL is silently unhostable
anywhere else. One fixture artifact is mounted under two hosts with
different origins and URL shapes to prove it.

Client-side permission hints are presentation only, and both the docs
and a test say so plainly: a denied hint does not stop the module from
calling its API, because server-side `requirePermission` is the only
authority. Module UI is trusted code in the host's own browser realm —
no iframe, no sandbox — which matches the backend model rather than
overstating it, since a module's server half already holds the API's
database authority.

The boundary guard is narrowed precisely, not removed: `.tsx`, `react`,
and `react-dom` are un-denied and modules may depend on the new
`module-ui-sdk` role. `.jsx`, `.css`, every other framework,
`react-router-dom`, `react-native`, and `@vitejs/plugin-react` stay
denied, layer rules are untouched, and an unsupported framework aliased
behind an allowed name (`"react": "npm:vue@3"`) is resolved and rejected
by its real target. Fixtures prove each case, including that module UI
source still cannot import Core.

Core, apps/api, and the manifest contract are untouched. Discovery still
validates the `entrypoints.ui` path and never evaluates it; hosts
perform their own dynamic import and validate the result with
`parseModuleUiExport`. No Dashboard shell, UI runtime, navigation,
grouping, standalone host, build or styling pipeline, installer,
hot-loading, or feature module is added.

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

docs/architecture/platform-architecture.md

@@ -30,7 +30,9 @@ The four ownership layers are:
 1. **Core** orchestrates generic platform infrastructure: startup, identity, permissions,
    configuration, database connectivity, storage, events, jobs, module discovery, and lifecycle.
 2. **Modules** own domain behavior, data schemas, resources, actions, routes, events, permissions,
-   jobs — and, per [ADR 0021](decisions/0021-modules-as-hostable-products.md), their own UI. A module
+   jobs — and, per [ADR 0021](decisions/0021-modules-as-hostable-products.md), their own UI, authored
+   in React against `@ekklesia/module-ui-sdk`
+   ([ADR 0022](decisions/0022-module-ui-authoring-and-host-contract.md)). A module
    is an independently versioned product, not only a backend capability. It does not own the
    containing application shell or any platform policy.
 3. **Surfaces** own the presentation concerns a module does not: the containing application shell,
@@ -163,20 +165,40 @@ blocks Phase 6. Read
 does and does not protect against, and the repository root
 [README](../../README.md#current-status) for the current status of every phase.
 
-**Phase 6A establishes the module product contract.**
+**Phase 6A established the module product contract.**
 [ADR 0021](decisions/0021-modules-as-hostable-products.md) replaces the backend-only module model:
 a module is an independently versioned product that may own its own UI, hostable inside Ekklesia and
 — later, from the same implementation — as a standalone application. Core keeps the host shell and
 every platform policy, the module graph stays flat, and Dashboard grouping stays presentation
 configuration.
 
-What this pass actually implements is the **static contract only**: `manifestVersion: 4` adds one
-optional `entrypoints.ui` field, validated during discovery exactly like the server and schema
-entrypoints — package-relative, inside the package, compiled ESM. Discovery remains inert; nothing
-imports, mounts, or renders that entrypoint. The Dashboard shell, the UI runtime, the standalone
-host, module UI authoring (including the still-enforced `modules-do-not-own-ui` boundary rule), and
-every feature module remain future work. Restart-based discovery, explicit operator-invoked
-migrations, and the trusted compiled-module model are all unchanged.
+What that pass implemented is the **static contract only**: `manifestVersion: 4` adds one optional
+`entrypoints.ui` field, validated during discovery exactly like the server and schema entrypoints —
+package-relative, inside the package, compiled ESM. Discovery remains inert; nothing imports, mounts,
+or renders that entrypoint.
+
+**Phase 6B pass 1 defines the module UI authoring model and host contract.**
+[ADR 0022](decisions/0022-module-ui-authoring-and-host-contract.md) selects React and TypeScript as
+the supported way to author module UI, and defines what a compiled `entrypoints.ui` artifact exports
+and what a host provides it. React is the authoring model but deliberately not the contract: an
+artifact default-exports `defineModuleUi({ id, version, mount })`, and `mount(container, context)`
+takes a DOM element and returns an unmount function, so a module's framework and a host's stay
+independent.
+
+The contract lives in `@ekklesia/module-ui-sdk`, a browser-safe shared package with no runtime
+dependencies, consumed by module authors and hosts alike. Its host context is four members —
+`moduleId`, `api`, `principal`, `permissions`. Module UI reaches its own backend through
+`api.request(path)` with a path relative to the module's own API root, never by constructing
+Ekklesia's `/api/v1/modules/<module-id>` prefix, which is what keeps a standalone host possible.
+Client-side permission hints are presentation only; server-side enforcement remains the sole
+authority. Module UI is trusted code in the host's browser realm — there is no sandbox, matching the
+backend trust model rather than overstating it.
+
+Core is untouched by this: discovery still validates the `entrypoints.ui` path and never evaluates
+it, and hosts perform their own dynamic import. The Dashboard shell, a UI runtime, the module UI
+build and styling pipeline, the standalone host, and every feature module remain future work.
+Restart-based discovery, explicit operator-invoked migrations, and the trusted compiled-module model
+are all unchanged.
 
 Target architecture not yet implemented includes production approval-provider
 composition, physical storage-bucket provisioning, jobs/workflow automation, richer public resource