feat: mount discovered module UI in a minimal Ekklesia browser host

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]>

core/src/authorization/permissions.ts

@@ -83,6 +83,21 @@ export const CORE_AUTHORIZATION_GRANTS_MANAGE: PermissionId = parsePermissionId(
   "core.authorization.grants.manage",
 );
 
+/**
+ * Authenticated: any signed-in user of this installation may learn which module UIs the platform is
+ * currently hosting, because that is exactly what a browser shell has to render before it can offer
+ * anything at all. It is deliberately not `public` — the anonymous artifact route (ADR 0025) is
+ * careful never to become an enumeration oracle, and an anonymous inventory would hand over the very
+ * listing that route withholds. It is deliberately not `restricted` either: a shell that rendered
+ * nothing until an operator granted every user this permission would make the platform unusable for
+ * its ordinary users, and the module UIs themselves already gate their own content on their own
+ * permissions.
+ *
+ * Listing a module UI is not permission to use that module. Every module route remains enforced
+ * against its own declared permission, unchanged.
+ */
+export const CORE_MODULES_UI_READ: PermissionId = parsePermissionId("core.modules.ui.read");
+
 /**
  * Core's own declarations, exported in deeply immutable form so a trusted composer (the module
  * integration layer, `core/src/modules/permissions.ts`) can build one combined registry from
@@ -96,6 +111,11 @@ export const CORE_PERMISSION_DECLARATIONS: readonly PermissionDeclaration[] = Ob
     description: "Create, list, and revoke another user's explicit authorization grants.",
     id: CORE_AUTHORIZATION_GRANTS_MANAGE,
   }),
+  Object.freeze({
+    baseline: "authenticated" as const,
+    description: "List the installed module UIs a browser host may mount.",
+    id: CORE_MODULES_UI_READ,
+  }),
 ]);
 
 /**

core/src/modules/ui-publication.ts

@@ -1,3 +1,4 @@
+import type { PermissionDeclaration } from "@ekklesia/contracts";
 import type { DiscoveredModule } from "./discovery.js";
 
 /**
@@ -14,6 +15,19 @@ export interface PublishableModuleUi {
   readonly moduleId: string;
   readonly version: string;
   readonly artifactPath: string;
+  /**
+   * The module's own manifest-declared permissions, carried here so a publisher can compute the
+   * presentation-only permission hints a host context needs (ADR 0022) **without** reaching back
+   * into the manifest and re-deriving which modules are publishable — which would put the
+   * publication policy in two places.
+   *
+   * Declarations only: this says what the module declares, never what any principal holds.
+   * Evaluating a principal against them is the caller's job, through Core's one authorization
+   * evaluator, and the answer is a hint rather than a grant. `artifactPath` and these declarations
+   * are the complete set of things a publisher may need; nothing else from the manifest belongs
+   * here.
+   */
+  readonly permissions: readonly PermissionDeclaration[];
 }
 
 /**
@@ -78,6 +92,9 @@ export function createModuleUiPublicationRegistry(
       Object.freeze({
         artifactPath,
         moduleId: module.manifest.id,
+        // Already deeply frozen by discovery; copied into a fresh frozen array so a caller holding
+        // this record can never reach the manifest object graph itself.
+        permissions: Object.freeze([...module.manifest.permissions]),
         version: module.manifest.version,
       }),
     );

core/tests/authorization-permissions.test.ts

@@ -2,6 +2,7 @@ import { parsePermissionId } from "@ekklesia/contracts";
 import { describe, expect, it } from "vitest";
 import {
   CORE_AUTHORIZATION_GRANTS_MANAGE,
+  CORE_MODULES_UI_READ,
   CORE_PERMISSION_DECLARATIONS,
   CORE_PERMISSION_REGISTRY,
   createPermissionRegistry,
@@ -89,8 +90,21 @@ describe("CORE_PERMISSION_REGISTRY", () => {
     expect(declaration?.id).toBe("core.authorization.grants.manage");
   });
 
-  it("contains no other permission in this slice", () => {
-    expect(CORE_PERMISSION_REGISTRY.declarations).toHaveLength(1);
+  it("registers core.modules.ui.read as authenticated, not restricted", () => {
+    const declaration = CORE_PERMISSION_REGISTRY.get(CORE_MODULES_UI_READ);
+    expect(declaration).toBeDefined();
+    // Any signed-in user may learn which module UIs the browser host can mount; a shell that
+    // rendered nothing until an operator granted each user a permission would be unusable, and the
+    // module UIs gate their own content on their own permissions regardless (ADR 0026).
+    expect(declaration?.baseline).toBe("authenticated");
+    expect(declaration?.id).toBe("core.modules.ui.read");
+  });
+
+  it("contains exactly these two permissions and no others", () => {
+    expect(CORE_PERMISSION_REGISTRY.declarations.map((declaration) => declaration.id)).toEqual([
+      CORE_AUTHORIZATION_GRANTS_MANAGE,
+      CORE_MODULES_UI_READ,
+    ]);
   });
 });
 
@@ -102,9 +116,15 @@ describe("CORE_PERMISSION_DECLARATIONS", () => {
         description: "Create, list, and revoke another user's explicit authorization grants.",
         id: CORE_AUTHORIZATION_GRANTS_MANAGE,
       },
+      {
+        baseline: "authenticated",
+        description: "List the installed module UIs a browser host may mount.",
+        id: CORE_MODULES_UI_READ,
+      },
     ]);
     expect(Object.isFrozen(CORE_PERMISSION_DECLARATIONS)).toBe(true);
     expect(Object.isFrozen(CORE_PERMISSION_DECLARATIONS[0])).toBe(true);
+    expect(Object.isFrozen(CORE_PERMISSION_DECLARATIONS[1])).toBe(true);
   });
 
   it("matches exactly what CORE_PERMISSION_REGISTRY exposes as its own declarations, so a composer building on top of it never diverges from what Core itself registers", () => {

core/tests/doctor-report.test.ts

@@ -78,7 +78,7 @@ Modules
   ✓ Dependency graph valid
     Dependency order is empty.
   ✓ Permission registry composed
-    1 permission registered
+    2 permissions registered
 
 Data definitions
   ✓ Schemas validated

core/tests/module-permissions.test.ts

@@ -2,6 +2,7 @@ import { type PermissionBaseline, parseModuleManifest } from "@ekklesia/contract
 import { describe, expect, it } from "vitest";
 import {
   CORE_AUTHORIZATION_GRANTS_MANAGE,
+  CORE_MODULES_UI_READ,
   CORE_PERMISSION_DECLARATIONS,
   PermissionRegistryError,
 } from "../src/authorization/index.js";
@@ -63,9 +64,11 @@ describe("composePlatformPermissionRegistry", () => {
     const registry = composePlatformPermissionRegistry([calendar, people]);
 
     expect(registry.has(CORE_AUTHORIZATION_GRANTS_MANAGE)).toBe(true);
+    expect(registry.has(CORE_MODULES_UI_READ)).toBe(true);
     expect(registry.has("calendar.events.read")).toBe(true);
     expect(registry.has("people.directory.read")).toBe(true);
-    expect(registry.declarations).toHaveLength(3);
+    // Core's own two declarations plus one from each module.
+    expect(registry.declarations).toHaveLength(4);
   });
 
   it("preserves deterministic order: Core first, then modules in the supplied order, then declarations in manifest order", () => {
@@ -81,6 +84,7 @@ describe("composePlatformPermissionRegistry", () => {
 
     expect(registry.declarations.map((declaration) => declaration.id)).toEqual([
       CORE_AUTHORIZATION_GRANTS_MANAGE,
+      CORE_MODULES_UI_READ,
       "calendar.events.read",
       "calendar.events.write",
       "people.directory.read",