#>design
component anatomy html constraints

Component Options / Dom Structure

Universal Slots

Most pieces of UI in Spwashi are a variation of the .frame-card or .frame-panel structure. Instead of authoring arbitrary wrappers, we use a predictable slot anatomy.

For producers and directors tuning visual style: The same slot contract used in rendered character/profile cards (header → meta → body → figure → actions → footer) is the grammar you tune in palettes, components, and materials. When a card from the character builder is used as a style packet in the Midjourney bench, its rendered slots become the testable surface for material, light, and rhythm decisions. This is the ergonomic loop: edit card → see rendered output → tune slots/palettes → send packet → iterate images with coherence.

[data-spw-slot="header"]

Used for the component's identifying marker, sigil, title, or top-level pill row. It anchors the component and provides identity before interaction.

[data-spw-slot="meta"]

For secondary information directly beneath the header—timestamps, provenance hints, and contextual breadcrumbs.

[data-spw-slot="figure"]

The primary visual container, whether for a raster image study or a runtime SVG rendering surface.

[data-spw-slot="body"]

The container for prose, lists, and structurally dense readable content. Handled by a max-inline-size measure.

[data-spw-slot="actions"]

Holds operator chips, buttons, and outbound links, usually sitting at the bottom boundary before references.

[data-spw-slot="footer"]

For terminal metadata, reference traces, or system-level output.