Enforce shared WebUI primitive adoption
This commit is contained in:
@@ -102,10 +102,31 @@ Migration is incremental and enforceable:
|
||||
5. promote the next repeated structure only after its variants and extension
|
||||
points are understood.
|
||||
|
||||
The intended next structural contracts are responsive page toolbar, content
|
||||
grid, form-section layout, dialog body/footer layout and shared empty/error
|
||||
state composition. Their APIs must remain composable; a central component is
|
||||
not a single oversized page template.
|
||||
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.
|
||||
- `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.
|
||||
- `FormSection` owns form-section heading, description, actions, content flow,
|
||||
separation, and panel presentation. It does not own field values,
|
||||
validation, permissions, or domain wording.
|
||||
- `Dialog` owns size and administration variants, body padding, description,
|
||||
notices, and fixed footer placement. `DialogActions`, `DialogForm`, and
|
||||
`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.
|
||||
|
||||
Raw toolbar tags, the former generic grid classes, raw dialog-form wrappers,
|
||||
and module-local definitions of these contracts are rejected by the focused
|
||||
workspace checks. The next promotion candidates are metric groups,
|
||||
description/property lists, filter/search composition, responsive data
|
||||
summaries, and unified empty/error state composition. Their APIs must remain
|
||||
composable; a central component is not a single oversized page template.
|
||||
|
||||
## Surface Archetypes
|
||||
|
||||
|
||||
Reference in New Issue
Block a user