# 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.