Sync Repo-docs-MODULE-ARCHITECTURE from project files

Repo-docs-MODULE-ARCHITECTURE.-.md

@@ -1,4 +1,4 @@
-<!-- codex-wiki-sync:ae32ddb4aae0c28290f2031d -->
+<!-- codex-wiki-sync:145a1efa1dc4580d1870eef3 -->
 
 > Mirrored from `/mnt/DATA/git/govoplan-core/docs/MODULE_ARCHITECTURE.md`.
 > Origin: `repository`.
@@ -116,6 +116,14 @@ administration; tenancy contributes tenant registry/settings routes; admin
 contributes system settings, overview, and governance-template routes; audit
 contributes audit-log routes.
 
+Current admin WebUI ownership mirrors that route split. `govoplan-access`
+contributes the `/admin` route shell and admin nav item. Other platform modules
+contribute individual admin sections through the `admin.sections` UI capability.
+`govoplan-admin` contributes the overview, system settings, and governance
+template sections through that capability. Access-owned tenant/user/group/role
+sections remain in the access package until their owning platform modules take
+them over.
+
 Cross-module feature contracts live under focused kernel contract modules. For
 example, `govoplan_core.core.campaigns` defines
 `campaigns.access`, `campaigns.mailPolicyContext`,
@@ -217,6 +225,30 @@ WebUI modules receive only the core route context:
 
 A module should call its own API client and module-owned backend routes. Shared API helpers should live in core only when they are truly platform-level concerns.
 
+Modules can also contribute named UI capabilities for explicit extension
+points. Capability values must be narrow, typed contracts, not imports from a
+sibling feature package. For admin pages, modules contribute:
+
+```ts
+const adminSections: AdminSectionsUiCapability = {
+  sections: [
+    {
+      id: "system-settings",
+      label: "General",
+      group: "SYSTEM",
+      order: 10,
+      allOf: ["system:settings:read"],
+      render: ({ settings, auth }) => createElement(SystemSettingsPanel, { settings, auth })
+    }
+  ]
+};
+```
+
+The access admin route shell collects all installed `admin.sections`
+capabilities with `usePlatformUiCapabilities("admin.sections")`, filters them
+by `anyOf`/`allOf`, and renders them without importing the contributing module's
+components directly.
+
 ## Icon Rules
 
 Icons are resolved centrally by core.
@@ -255,6 +287,9 @@ Examples:
 
 - `ExplorerTree` is core because files, mailboxes, and future modules can all render hierarchical navigation.
 - `MessageDisplayPanel` is core because mail, campaign sending, and later audit/review surfaces can display message-like content.
+- `AdminPageLayout`, `AdminIconButton`, and `AdminSelectionList` are core
+  because access, admin, tenancy, policy, and audit panels share the same admin
+  shell language.
 - `MailProfileManagement` remains in the mail module because it is specific to mail transport policies and profiles.
 
 ## Cross-Module Integration