svelte-kit-vice/src/uix/eidos/CHANNELS_SYNTHESIS.md

Los canales como un solo sistema — síntesis ("Diseñando lo que ocurre")

Capstone de los RFCs por canal. La tesis del libro Diseñando lo que ocurre: una interacción no es color, ni movimiento, ni sonido — es un solo suceso perceptual repartido en N canales, bajo el modelo de dos momentos. Esto ata COLOR_ENGINE_RFC · TYPOGRAPHY_ENGINE_RFC · DEPTH_ENGINE_RFC · SHAPE_ENGINE_RFC · STRUCTURE_ENGINE_RFC. Demo vivo: /temas/orquesta (el mezclador).

1. Dos momentos, unidos por un token: sema emite, eidos lee

Un suceso fluye por dos momentos, conectados por el token:

• Momento de sema (emisión) — sema evalúa el suceso y lo emite. Sonido + háptica los ejecuta ahí mismo (canales runtime); para lo visual, lo estampa como tokens data-event-* (family · intent · phase). Sema no conoce DOM/CSS.
• Momento de eidos (materialización) — eidos lee esos tokens (+ data-state) y los materializa en CSS (el canal visual). Es el único dueño visual.

El token es el contrato: sema escribe, eidos lee — y por eso las capas se desacoplan (sema agnóstico del DOM, eidos sin lógica semántica).

Sobre ese eje productor → consumidor corre el eje temporal (motion F1) — qué token:

Token	Naturaleza	Quién lo escribe	Eidos lo lee como
data-state	persistente — lo que el elemento es	soma / morfo	presets
data-event-*	transitorio — lo que ocurre (durante el hold)	sema (emite)	signatures

sequence (pre / coincident / post) ordena los dos.

2. Canales de expresión (libro) vs canales de sema (runtime)

El libro tiene 8 canales de expresión (dimensiones perceptuales). El framework los implementa con los canales de sema (runtime), que son 3 — y aquí está la clave que evita la confusión clásica:

Canal de sema (runtime)	Cubre (expresión del libro)	Quién lo materializa
visual (sema proyecta data-event-*)	movimiento · presencia · profundidad · forma · color	eidos — CSS sobre data-event-* + data-state
sound	sonido	sema (chans/sound)
haptic	háptica	sema (chans/haptic)

No te confundas: motion · depth · shape · color NO son "canales de eidos" — son el canal visual de sema, que sema proyecta y eidos materializa. Eidos es el materializador del canal visual, no el dueño de unos canales propios. Los RFCs de eidos (COLOR/DEPTH/SHAPE_ENGINE) describen cómo eidos materializa cada faceta visual — no canales independientes.

Más el espacio (STRUCTURE_ENGINE_RFC) — estructural, no de expresión: no "ocurre", es el escenario (solo-estado).

3. La cadena de capas (cada una con su papel)

Un suceso atraviesa las capas — no es "todo sema", y eidos no es un shim:

1. morfo — declara el evento y su semántica (familia · intención · verbo). El contrato / DNA; TypeScript puro, sin runtime.
2. soma — lo dispara (runtime.trigger): secuencia prewrite → sema.emit → handler → atributos de estado. Escribe data-state (el momento-estado).
3. sema — lo emite: despacha la señal a sus canales — ejecuta sound + haptic; proyecta el canal visual estampando data-event-*. No conoce DOM/CSS.
4. eidos — lo materializa: lee data-state (presets) + data-event-* (signatures) y los rinde con sus motores de tokens (color · motion · depth · shape · space — los RFCs). Es el sistema visual completo y el único dueño de lo visual.

Eidos no "hace visible a sema": sema aporta el qué (familia / intención semántica), eidos aporta el cómo (el vocabulario visual y su materialización). Co-capas, no una subordinada.

(Narrativa canónica completa en CLAUDE.md → "Sema: open channel registry".)

4. La composición — un evento, N canales

La firma (BUILTIN_SIGNATURES + BUILTIN_KEYFRAMES) es cross-modal: un solo keyframe lleva varias modalidades. Ejemplo real (press-squeeze, familia contact):

contact · press  →  scale 0.96 (motion)
                 +  box-shadow → plano (depth recede)
                 +  --shape-smoothing 2→3 (shape: la esquina se afirma)
                 +  tick (sema sound)
                 +  vibración (sema haptic)

Un engine.emit(...) estampa data-event-* (el canal visual reacciona — eidos lo materializa en color/motion/depth/forma) y dispara sound + haptic — desde el mismo evento. No hay sistemas coordinándose a mano; hay un suceso que se expresa por los canales de sema.

5. Builders runtime — el sexteto (jaula abierta)

Cada eje retunable en runtime, mismo patrón (semilla → bloque gestionado), opt-in sobre la escala authored:

applyColorScheme · applyTypeScale · applyDepth · applyShape · applySpacing

Y el capstone que los compone: applyTheme(seed) — una sola semilla ({ color?, type?, depth?, shape?, space? }) compone los cinco ejes en una única escritura gestionada (vs cinco apply* sueltos), de forma atómica: los ejes que das se aplican, los que omites revierten a la foundation authored. clearTheme() revierte todo. Para retoques quirúrgicos por eje, los apply* individuales siguen ahí. Ningún referente reúne los cinco ejes perceptuales bajo un único builder de tema en runtime.

6. Posición frente a referentes

Ningún referente reúne los canales bajo un modelo semántico único. Material tiene morph de forma + motion (ad-hoc, sin sonido/háptica integrados); Apple, continuidad + materiales (atado a plataforma); todos, color. La UIX los reúne —el canal visual (sema → eidos) + sound + haptic (sema)— sobre el modelo de dos momentos, disparados desde un evento, con builders runtime y registro abierto. Eso es el framework, no la suma de sus partes.

7. Demo

/temas/orquesta — el mezclador: pulsa un control y silencia cada faceta para oír su parte. Las 4 facetas del canal visual se materializan con tokens de eidos (toggleables para poder silenciarlas una a una); sound + haptic los dispara el motor sema real (EngineSemantic.emit, canales filtrados). Un evento, los canales de sema.