# Views Interface Pattern Migration

This document records the bounded migration of Views-owned WebUI surfaces to
the GovOPlaN interface pattern language. Core owns shared controls, surface
projection, and the host shells. Views owns definitions, revisions,
assignments, effective selection, and the safeguards described here.

## Surface Inventory

| Surface | Archetype | Consequence class | Contract |
| --- | --- | --- | --- |
| `views.selector` | Compact global selector | Change active presentation projection | Localized accessible selector, required-state explanation, unsaved-change guard |
| `views.admin.system` | Administration list-detail editor | Create, publish, archive, assign | Shared admin layout, explicit disabled reasons, required-View lockout validation, contextual help |
| `views.admin.tenant` | Administration list-detail editor | Create, publish, archive, assign | Inheritance provenance, searchable group/user targets, explicit optional-module blocker |
| `views.settings.personal` | Settings list-detail editor | Create and publish owned Views | Shared owner selector, permission blocker, contextual field help |

## Consequence And Availability Rules

- Views filter presentation only. Authorization remains owned by Access and
  each protected backend route.
- Published revisions are immutable. Unpinned assignments follow later
  publications; pinned assignments retain one published revision.
- Required Views keep the selector and the applicable administration escape
  surface. The backend validates this before accepting the assignment.
- User and group assignments take precedence over tenant and system
  assignments. Inherited definitions and assignments are changed at their
  owning scope, not copied implicitly.
- The optional Access directory supplies searchable group and user targets.
  If it is absent, the UI explains the missing capability and its remedy while
  system and tenant targets remain usable.
- Definition, creation, and assignment drafts use Core's shared unsaved-change
  guard. Archive and assignment removal use shared consequential-action
  confirmation.

## State And Accessibility Evidence

The surfaces use Core loading, error, success, empty, disabled-action, blocker,
dialog, status, selector, and tree controls. Consequential actions stay visible
and explain missing permission, inherited ownership, lifecycle state, missing
catalogue data, or lockout validation. Labels and accessible properties are
provided through the module translation catalogue. Shared dialogs own focus
containment and restoration, while fixed-height panes retain responsive
scrolling.

Stable help references are contributed through the manifest for the selector,
administration sections, settings panel, fields, assignment precedence, and
consequential actions. Backend and WebUI contract tests prevent those
references and safeguards from silently regressing.