svelte-kit-vice/src/uix/eidos

Eidos

Eidos es la capa visual de UIX. No existe todavía como código — este README documenta su rol y qué consume de las otras capas para que cuando se construya, el contrato cross-layer ya esté preparado.

Qué es

La capa que decide cómo se ve un componente. Tokens, themes, recipes, animaciones, transiciones. Lee del DOM lo que las capas anteriores han escrito y aplica CSS.

Morfo declara la genética
  ↓
Soma transcribe el comportamiento → DOM
  ↓
Sema emite señales perceptivas → DOM (data-event*)
  ↓
Eidos lee el DOM y aplica estilos

Eidos nunca importa internals de soma, ni pregunta a sema directamente. Su única fuente de verdad es lo que está escrito en el DOM: parts, data-attrs, ARIA, archetypes, event signals.

Qué consume de Morfo

Morfo es el contrato cross-layer. Eidos lee de la declaración (no del runtime) las cosas que necesita para generar selectores y reglas:

Pieza de morfo	Eidos la usa para
parts[].kebab	selectores [data-{component}-{kebab}]
parts[].archetype	selectores transversales [data-archetype=trigger]
parts[].states + data[].values	selectores variant [data-state=open]
parts[].data con data-starting-style / data-ending-style	hooks de animación enter/exit
events[].name (alineado con SEMA_VERBS)	selectores de señal [data-event=dismiss], [data-event^=commit]
events[].semantic.family + .intent	tinta semántica de transiciones
events[].prewrite[] (e.g. data-last-action)	tintar exit anim por causa (saved/cancelled/dismissed)
focus.trap	hint para layout de overlay
supportsNesting	scope :not([data-nested])

Qué NO consume

• Computed state lógico del provider (Provider.isDisabled OR'd con Field). Eidos solo ve el resultado: [data-disabled] está o no está. La lógica de cómo se computa vive en TS, no llega a CSS.
• Internals de runtime. Eidos no sabe si un attr lo escribió dom.apply, Svelte render, o el provider manualmente. Solo le importa que esté.
• Layers (Presence, Dismissal, ScrollLock). Son comportamiento; eidos reacciona a sus efectos visibles (data-state, data-starting-style), no a su existencia.

Cómo Sema le sirve

Cuando el provider llama semantic.emit(...), el SemanticEngine despacha la señal al VisualChannel, que escribe data-event* al DOM. La señal vive el hold configurado (240ms emerge/commit/handle, 600ms alert/sustain, 120ms contact por defecto), luego se limpia. Esa ventana es perceptualmente significativa — CSS tiene tiempo real para coreografiar feedback visible.

Durante esa ventana, eidos puede:

• Disparar animaciones que reaccionen a la señal: [data-event^=dismiss] { animation: eidos-dismiss-fade 320ms forwards }. Usar animation: @keyframes (no transition) para que el efecto corra full duration aunque el attr se retire después.
• Tintar el commit con la causa (via data-last-action): [data-last-action=cancelled].
• Diferenciar por intent: [data-intent=risk] { ... }.

Sema no le habla a eidos directamente. El DOM es el canal.

La regla "2-de-3"

Una extensión a morfo se justifica si al menos dos de las tres capas (soma, sema, eidos) la consumen. Si solo soma se beneficia, vive en provider via virtual prop, no en morfo.

Bajo esa regla, las extensiones que SÍ entraron en morfo:

• archetype — eidos + sema (+ soma como emisor)
• events[].semantic.family/intent — sema + eidos (+ soma como autor)
• events[].prewrite[] — soma (ejecuta) + eidos (anima)
• data-starting-style / data-ending-style — soma (Presence aplica) + eidos (anima)

Lo que NO entró:

• firstOf value source — soma-only convenience.
• prop-not-nullish condition — soma-only.
• Composition language para values — morfo se volvería mini-DSL.

Archetypes

Vocabulario actual (ver src/uix/morfo/types.ts:ARCHETYPE_VOCABULARY):

provider · trigger · content · overlay · viewport
item · option · indicator · thumb · track
label · title · description · close · action
header · image · fallback · arrow · separator
group · input · segment · preview

Cuando un componente declara archetype: 'trigger' en una parte, eidos recibe data-archetype="trigger" en ese nodo. Sirve para reglas transversales:

/* Estilo común a TODOS los triggers, sin enumerarlos */
[data-archetype="trigger"] {
  cursor: pointer;
  user-select: none;
  transition: background-color var(--motion-fast);
}

/* Hover dim común */
[data-archetype="trigger"]:hover {
  background-color: var(--surface-hover);
}

Verbs

Vocabulario en src/uix/sema/verbs.ts:SEMA_VERBS:

emerge:   present · dismiss · open · close · expand · collapse
commit:   commit · cancel · confirm · submit · reset · fail
alert:    announce · alert
contact:  activate · select · toggle
handle:   acknowledge · edit · drag · resize
sustain:  tick · progress

Cuando sema emite, escribe data-event="{verb-or-name}" al DOM. Eidos puede:

/* Transición común a cualquier "dismiss" sin importar el componente */
[data-event^="dismiss"] {
  animation: fade-out var(--motion-quick);
}

/* Tinta por intent */
[data-event][data-intent="risk"] { color: var(--risk-fg); }
[data-event][data-intent="threat"] { color: var(--threat-fg); }

Estado actual

• Capa: existe como concepto y como contrato cross-layer en morfo + sema.
• Código: nada todavía. Este README es el placeholder.
• Cuando se empiece: probablemente por tokens base + archetype-rules comunes + recipes simples.

Relación con air

src/uix/air/ es la implementación visual previa, marcada como dead branch (ver project_terra_air_dead.md en memoria). Eidos es su sucesor con disciplina cross-layer. No se reciclará código directamente; air sirve como referencia histórica de patrones (cómo se factorizaron tokens, qué recipes funcionaron) pero no como base.

Frase de arquitectura

Eidos lee el DOM. Si no está en el DOM, eidos no lo ve. Si lo necesita ver, debe estar en el morfo (declarado) o en una señal de sema (emitida).