# Access interface pattern migration

This document records the Access-owned surfaces covered by the platform
interface pattern language. Shared primitives remain owned by Core and
optional Mail, Files, Organizations, IDM, and Docs behavior is consumed only
through declared capabilities or metadata.

## Surface inventory

| Surface | Archetype | Authority and state model |
| --- | --- | --- |
| `/admin` tree and unavailable state | Tree-navigated administration workspace | The effective principal and active View determine which branches exist. A missing administration grant is an explained blocker, not an empty route. |
| System and tenant users | Server-authoritative directory plus list/detail editor | Delta reads refresh accounts and memberships. Create, update, assignment, suspension, and final-owner safeguards remain independent permissions. |
| System and tenant roles | Governed definition directory | Built-in and system-managed definitions remain visible but immutable. Assigned roles cannot be deleted. |
| Tenant groups | Governed definition and membership editor | Definition, membership, and role-assignment rights remain independent. Required system groups cannot be deactivated. |
| Tenant API keys | Immutable-secret lifecycle directory | A key is created once, its secret is shown once, and revocation is consequential and confirmed. |
| Function mappings | Governed cross-module mapping editor | Organizations supplies function choices, IDM supplies accepted facts, and Access maps facts to assignable roles. |
| Credential scopes | Adaptive configuration panel | Core owns the reusable credential manager. Access supplies system, tenant, group, and user ownership choices. |
| Mail and Files scope panels | Optional capability host | Access supplies owner selection; the owning module supplies configuration UI. A missing capability names the required module, actor, and destination. |

## Consequence classes

- Reload, inspect, filter, select, and open-help actions are reversible.
- User, group, role, mapping, and credential edits are governed mutations and
  expose permission or validation blockers before submission.
- Account or membership deactivation, group deactivation, role deletion,
  mapping deletion, API-key revocation, and credential deletion are
  consequential actions and use the shared confirmation contract.
- Secret values and temporary passwords are never placed in list rows or
  persistent notices. One-time values remain inside dedicated dialogs.

## Interaction evidence

- `WorkspaceLayout`, headerless `PageLayout`, `AdminPageLayout`, `TreeSubnav`,
  `DataGrid`, `Dialog`, `ConfirmDialog`,
  `TableActionGroup`, `PasswordField`, `ActionBlockerHint`, and
  `DocumentationHelpLink` come from Core.
- The administration tree and its contributed panels now share Core-owned pane
  sizing, scrolling, content inset, responsive collapse, region labels, and
  contextual-help identity; Access no longer carries a raw workspace or page
  frame exception.
- Dialog focus trapping and restoration, disabled-action tooltips, keyboard
  ordering, responsive grid overflow, and alert semantics therefore inherit
  the tested Core behavior.
- All Access-owned labels added by this migration are present in the English
  and German module catalogs.
- The WebUI structural test rejects browser-native confirmation calls, private
  sibling imports, missing contextual-help references, and unexplained
  optional-module blockers.

## Documentation contexts

- `access.workflow.grant-user-access` covers the user, group, and role path.
- `access.reference.admin-access-fields` covers accounts, roles, API keys, and
  their backing administration fields.
- `access.workflow.manage-api-keys` owns exact help for accountable ownership,
  bounded scopes and expiry, one-time secret custody, and immediate revocation.
- `access.workflow.manage-service-account-credentials` owns exact help for the
  account ceiling, activation state, credential rotation/revocation, one-time
  secret custody, concurrency, and retirement consequences.
- `access.reference.external-function-role-mappings` explains the
  Organizations, IDM, and Access responsibility split.
- Files and Mail blockers link to documentation supplied by the owning module.