From fbf1426ac2403810cf722330895f69af38d369b4 Mon Sep 17 00:00:00 2001 From: zemion Date: Mon, 6 Jul 2026 23:46:27 +0200 Subject: [PATCH] Sync Repo-docs-MODULE-ARCHITECTURE from project files --- Repo-docs-MODULE-ARCHITECTURE.-.md | 37 +++++++++++++++++++++++++++++- 1 file changed, 36 insertions(+), 1 deletion(-) diff --git a/Repo-docs-MODULE-ARCHITECTURE.-.md b/Repo-docs-MODULE-ARCHITECTURE.-.md index 2043a11..7ad4e18 100644 --- a/Repo-docs-MODULE-ARCHITECTURE.-.md +++ b/Repo-docs-MODULE-ARCHITECTURE.-.md @@ -1,4 +1,4 @@ - + > 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