Enforce the shared WebUI pattern language

docs/architecture/INTERFACE_PATTERN_LANGUAGE.md

@@ -82,9 +82,18 @@ retaining the standard inset, and `embedded` owns neither scroll nor inset.
 owns module/resource subnavigation plus content; its `split` variant owns
 collection/detail panes. It centralizes pane sizing, internal scroll,
 responsive collapse/stacking, accessible pane labels and workspace help
-identity. `PageHeader` remains available when an exceptional canvas needs only
-the shared heading. Specialized layouts such as `AdminPageLayout` compose
-these lower-level Core contracts; they do not repeat markup or responsive CSS.
+identity. `WorkspaceFrame` is the outer full-height module frame and owns
+container or application-viewport height, overflow, surface, landmark, help,
+and accessible-name behavior. `PageHeader` remains available when an
+exceptional canvas needs only the shared heading. Specialized layouts such as
+`AdminPageLayout` compose these lower-level Core contracts; they do not repeat
+markup or responsive CSS.
+
+Composite workspaces whose selected contribution supplies its own semantic
+heading may use `PageLayout` with its visible header delegated. This preserves
+the central inset, loading boundary, help identity, and content frame without
+adding a duplicate heading. It is not permission to recreate the page header
+locally on ordinary headed pages.
 
 Module CSS may arrange domain content inside a shared layout. It must not
 override Core layout internals or copy the outer page, dialog, toolbar, form or
@@ -102,16 +111,34 @@ Migration is incremental and enforceable:
 5. promote the next repeated structure only after its variants and extension
    points are understood.
 
+The current page-frame and workspace migration has no legacy exceptions. New
+raw frames fail the focused layout contract instead of entering a new baseline.
+
 The current structural vocabulary is:
 
 - `ActionToolbar`, `ToolbarGroup`, and `ToolbarSpacer` own action alignment,
-  density, grouping, accessible toolbar naming, help identity, and responsive
-  wrapping. Modules may add surface padding or domain-specific presentation;
-  they do not recreate the flex/wrap skeleton.
+  distribution, density, grouping, panel/section surfaces, accessible toolbar
+  naming, help identity, and responsive wrapping. Modules may add
+  domain-specific presentation; they do not recreate the flex/wrap skeleton.
+- `WorkspaceFrame` and `WorkspaceLayout` own application-viewport framing,
+  surfaces, overflow, list/detail and navigation/content pane geometry,
+  accessible region identity, and responsive pane behavior. Modules own only
+  the domain regions placed inside those contracts.
+- `FilterBar` owns submitted or live filter/search arrangement, wrapping,
+  width and surface. `SelectionList`, `SelectionListItem`, and
+  `SelectionListItemContent` own selectable resource navigation and its
+  title/description/leading-icon geometry. `CountBadge` owns compact numeric
+  emphasis. Modules retain filter behavior, selection state, and count meaning.
+- `StatePanel` owns whole-surface, compact, inline and fill state presentation
+  for empty, unavailable, blocked, warning and recoverable-error compositions.
+  Modules provide the cause, consequence, permitted action and authority.
 - `ContentGrid`, `FormGrid`, `FormLayout`, and `GridItem` own equal-column
   geometry, standard gaps, alignment, spans, native form semantics, and named
   responsive collapse points. A module-local grid remains appropriate only
   when unequal tracks or domain visualization semantics are material.
+- `ContentSection` owns repeated bordered or subtle content-section surfaces,
+  density, stacked flow and surrounding rhythm without prescribing a domain
+  heading or body schema.
 - `FormSection` owns form-section heading, description, actions, content flow,
   separation, and panel presentation. It does not own field values,
   validation, permissions, or domain wording.
@@ -129,15 +156,22 @@ The current structural vocabulary is:
   `DialogSection` own the footer action flow, native form flow, and body
   grouping used inside it. Modules compose fields and consequences rather than
   recreating dialog anatomy.
+- `DefinitionPalette`, `DefinitionPaletteGroup`, `DefinitionPaletteItem`, and
+  `DefinitionNodeIcon`, together with the shared definition-canvas classes,
+  own reusable graph-editor palette, canvas-control, node-icon, port and empty
+  overlay visuals. Workflow/Dataflow retain node types, shapes, edges,
+  validation and execution semantics. `FloatingStatus` owns the common
+  non-shifting activity overlay.
 
-Raw toolbar tags, the former generic grid and property-list classes, raw
-dialog-form wrappers, and module-local definitions of these contracts are
-rejected by the focused workspace checks. Dialog widths matching the Core size
-scale must use `Dialog size`; other local widths require a reviewed exception
-and may only decrease. The next promotion candidates are assignment/picker
-composition, filter/search composition, and unified empty/error state
-composition. Their APIs must remain composable; a central component is not a
-single oversized page template.
+Raw toolbar tags, the former generic grid and property-list classes, retired
+module-local shells/states/metrics/badges, raw dialog-form wrappers, and
+module-local definitions of these contracts are rejected by the focused
+workspace checks. Dialog widths matching the Core size scale must use `Dialog
+size`; other local widths require a reviewed exception and may only decrease.
+Remaining local layout is acceptable only for unequal-track domain editors,
+visualizations, trees, timelines, data tables, or domain-specific multi-pane
+interaction. Generic resemblance alone is not a reason to create one oversized
+page template, while exact repeated structural anatomy must be promoted.
 
 ## Surface Archetypes