3.0 KiB
Admin interface pattern migration
This document records the interface-pattern coverage for the surfaces
contributed by govoplan-admin. The Access module hosts the administration
tree; Admin supplies only its declared sections through admin.sections.
Surface inventory
| Surface | Archetype | Authority and state model |
|---|---|---|
| Administration overview | Navigation dashboard | Counts are server projections. Links exist only for sections already admitted by capabilities, permissions, and the active View. |
| System settings | Adaptive configuration | A local draft is compared with the saved server state. Reload preserves an unsaved draft, Save requires system write authority, and maintenance controls also require maintenance authority. |
| Configuration changes | Governed work queue and evidence list | Open approval requests and immutable applied history are separate server-authoritative grids. Approval requires an explicit confirmation. |
| Configuration packages | Guided preflight/apply/export workspace | JSON input is validated locally, dry-run evidence is shown separately, approval is optional where policy allows it, and application is explicitly confirmed. Reference selectors replace raw IDs unless historical manual mode is selected deliberately. |
| Role and group templates | Governed definition directory | Definitions, tenant availability, and role permissions are edited in one draft. Deletion is confirmed and remains blocked by materialized dependencies in the backend. |
| Module management | Guided lifecycle workflow and operations evidence | Desired runtime state, package plan, preflight, maintenance gate, daemon request, and durable run evidence are distinct stages. Disabled controls name the earliest blocker. |
Consequence classes
- Overview navigation, reload, filtering, inspecting evidence, dry runs, and exports are reversible.
- Settings, templates, desired module state, package plans, and approval requests are governed mutations with permission and validation reasons.
- Approving a change, applying a configuration package, enabling maintenance, clearing a saved module plan, cancelling an installer request, and deleting a governance template require shared confirmation surfaces.
- Actual package mutation remains outside the API process and is performed by the supervised installer. Run and rollback evidence remains durable.
Shared controls and verification
Admin uses Core AdminPageLayout, DataGrid, ReferenceSelect, StageRail,
Dialog, ConfirmDialog, TableActionGroup, ActionBlockerHint,
DocumentationHelpLink, ToggleSwitch, and status/alert primitives. This
inherits Core focus restoration, keyboard order, responsive overflow,
disabled-action tooltips, and accessible dialog semantics.
The focused WebUI check rejects browser-native confirmation calls, private sibling-module imports, untranslated Admin-owned structural headings, missing contextual help, and missing disabled reasons on consequential controls. The manifest regression test fixes the help-context and surface declaration.