|
|
|
|
# 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.
|