502 Commits (d3089e880c9df14d258d4560f6a1660cf0b106c7)

Author	SHA1	Message	Date
dev	d3089e880c	uix(link): temable — 0 % → 36 %, y ese techo bajo es la respuesta correcta ... 5 claves fusionadas en el bloque `link` de `recipes/base.ts` (donde ya vivían los dos forwards de paleta). Censo 0 % → 36 %. **Un enlace en línea hereda casi todo del texto que lo rodea**, así que su superficie de tema es pequeña por diseño. Sus dos escotillas por instancia (`--_link-font-size`, `--_link-line-height`) tienen como fallback `inherit`, y ese `inherit` es SEMÁNTICO: el enlace toma la tipografía del párrafo en el que vive. Convertirlo en token exigiría un público con valor `inherit`, que en `:root` no significa lo mismo — se quedan privadas. Con los dos forwards de paleta, ésos son los cuatro privados que forman el grueso del 64 % restante. Lo tokenizable es la GEOMETRÍA: radio del anillo, hueco del glifo externo, tamaño del glifo (`0.85em` en las dos dimensiones → UN knob) y el grosor y desplazamiento del subrayado, cada uno declarado en las DOS reglas que lo dibujan (`always` y `hover`) con el mismo valor. Las tres opacidades son sistema; el `fill: currentColor` del glifo es identidad, sigue a la tinta del enlace a propósito. **La cascada no se toca.** El CSS lleva dos correcciones de especificidad ya medidas y explicadas en su sitio (el `inherit` condicional, para que un `color` pedido por el consumidor no se descarte en silencio; y el `:active` al final, porque una pulsación es siempre también un hover). El diff de computed confirma que tokenizar no las altera. Artefactos y gates: - Sonda antes/después = 0 diffs en 203 valores × 7 estados. Determinismo verificado. - R-5.4: 2/5, los tres mudos adjudicados con su medición. Ninguno es deuda: el glifo externo no se monta en la demo (0 nodos, contados) y el enlace arranca en `data-underline='hover'` sin puntero encima, así que NO HAY subrayado que mover (`text-decoration-line: none`, `thickness: auto`). Forzando el estado, los tres alcanzan. - En el mismo pase, `text-decoration-thickness` y `text-underline-offset` entran en la lista de propiedades del guard, que no las miraba — verificado que los otros DIECISÉIS componentes con ledger no cambian. - censo --only 36 % · component:audit PASS · eidos-lint invalid 0, class-hooks 0 · suite eidos sin rojos nuevos · rtl:check 0 · docs:check 0 · check por fichero limpio · README con «Talla y tema» y tab `Tokens` (5 claves). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2 months ago
dev	adb77863cd	uix(kbd): temable — 0 % → 86 %, y 13/13 en el guard sin una sola excepción ... 13 claves en una entrada NUEVA de `recipes/base.ts`. Censo 0 % → 86 %. 1. **`font-family` NO se acuña**: lee `var(--style-code-font-family)`, la capa tipográfica, y un consumidor no re-declara el vocabulario de su capa — precedente inmediato, `code-block`. El `font-size` SÍ entra, y la diferencia está medida: su fallback era un PRIMITIVO, no la capa. `--_kbd-font-size` es la escotilla por instancia que el wrapper escribe desde la prop `size` (`kbd.svelte:37`), y el fallback pasa a ser el público. 2. **El padding y el min-width son em-relativos a propósito** — una tecla crece con su letra —, así que son knobs con valor `em`, no literales pendientes de corregir. El `line-height: 1` sí es identidad: una tecla no tiene interlineado. 3. **El relieve de tecla física es de la variante `surface`**: borde inferior más grueso + luz interior. Dos knobs propios, no adorno del borde general; outline y ghost son planas por identidad. Artefactos y gates: - Sonda antes/después = 0 diffs en 522 valores × 7 estados. Determinismo verificado. - R-5.4: **13/13**, sin una sola entrada en el ledger — el primero de la tanda que no necesita adjudicar nada. - censo --only 86 % · component:audit PASS · eidos-lint invalid 0, class-hooks 0 · suite eidos sin rojos nuevos · rtl:check 0 · docs:check 0 · check por fichero limpio. - README con su «Talla y tema» y tab `Tokens` en la demo (13 claves, en vivo). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2 months ago
dev	650d76aa0e	uix(drag-drop): temable — 0 % → 89 %, casi todo en el fantasma del arrastre ... 10 claves en el bloque `drag-drop` de `recipes/base.ts` (fusionadas con `preview-z`, que ya estaba, y los dos forwards de paleta). Censo 0 % → 89 %, cero globales. **Siete de sus dieciséis knobs YA eran sistema** y no entran al ratio (las opacidades de fantasma y deshabilitado, los dos anillos de foco y el anillo `inset` de los droppables), así que los puntuables eran nueve — seis de ellos en el PREVIEW, el fantasma que sigue al puntero. 1. Los dos forwards de paleta siguen privados (THM-2): el fondo del `[data-dragover]` los lee a pelo y no admite un público sin duplicar la regla — es el 11 % que falta. En cambio el `border` y el `box-shadow` del preview los COMBINAN con una anchura y una sombra que sí son knobs propios, así que esas dos declaraciones entran al alcance. 2. El `--ring-inset-*` de los droppables no se toca: es vocabulario del anillo del SISTEMA y la receta se limita a alimentarlo con su acento. Acuñar un `droppable-ring-*` sería vocabulario paralelo sobre un transversal. 3. El `padding` del preview es un shorthand de dos valores → dos knobs lógicos. Artefactos y gates: - Sonda antes/después = 0 diffs en 1.827 valores × 7 estados. Determinismo verificado. - R-5.4: 0/10 en vivo, y los DIEZ adjudicados con su medición. No es un instrumento roto ni tokens muertos: el preview se crea sólo mientras hay un arrastre en curso (0 nodos en reposo, contados), y forzando el nodo los diez mueven su propiedad — padding 8→1234px, radio 6→1236px, borde 1→9px, fondo, tinta, familia, tamaño 14→99px, sombra y z 100→4321. - censo --only 89 % · component:audit PASS · eidos-lint invalid 0, class-hooks 0 · suite eidos sin rojos nuevos (el conocido skin-media-player) · rtl:check 0 · docs:check 0 · check por fichero limpio. - README con su «Talla y tema» y tab `Tokens` en la demo (10 claves, en vivo). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2 months ago
dev	7a0fc2eadb	uix(link-preview): temable — 0 % → 100 %, y el plano overlay que traía tipografía ... 33 claves en una entrada NUEVA de `recipes/base.ts`. Censo 0 % → **100 %**: no queda un knob de apariencia fuera del contrato (los tres restantes son sistema — anillo de foco y los dos del plano de profundidad que pintan la flecha). Global 48 %, sin contrato 42 → 41, al 100 % 7 → 8. 1. **Los per-talla llevan `parts: ['content']`**, no el host: el panel está PORTALADO y su `data-size` vive en el content, así que una cascada colgada del host no lo alcanza nunca. La talla mueve sólo dimensiones físicas (padding, min-width, tipo); familia, peso e interlineado son constantes a propósito, como ya decía la receta. 2. **La flecha no se tokeniza**: su fill y su stroke consumen el plano `overlay` para casar siempre con el panel; acuñar `arrow-fg` rompería justo esa garantía. El subrayado del trigger es un `color-mix` sobre `currentColor` — la mezcla ES el aspecto, así que el knob es la declaración entera, no el 35 %. Y el fallback encadenado del color del trigger viaja verbatim: la coma es parte del valor, no un segundo knob. EL HALLAZGO — el plano `overlay` impone TIPOGRAFÍA (→ next-features §12.9): `[data-depth='overlay']` (`generated/base.css:7088`) no declara sólo fondo, borde y sombra: también `font-family` y `line-height`. El panel estampa ese plano para su elevación, así que la declaración del plano empata a (0,1,0) con la de la receta y **gana por orden de carga** (la hoja generada va después del chunk de la receta). Medido con CDP `getMatchedStylesForNode`: el par `font-family` / `line-height` de esta receta **no había pintado nunca**. Retirado con **0 diffs**, que es la prueba. Afecta a los **veinte** componentes que estampan el plano. Lo que hay que decidir —aparte, mueve píxel— es si un plano de profundidad tiene competencia sobre la tipografía o sólo sobre la superficie. Cuarta ocurrencia de la clase «empate resuelto por orden de carga». CÓMO SE MIDIÓ, porque el instrumento estándar tampoco servía aquí: El panel abre en HOVER con retardo y está portalado → la sonda genérica ve **1 nodo**, y una sonda que compara un nodo pasa en falso. Sonda dirigida (abre por hover, captura los cinco nodos reales en las cinco tallas): determinismo verificado y **gate antes/después = 0 diffs sobre 550 valores**, repetido tras la retirada. El guard R-5.4 pasó de **3/35 a 31/33** con dos extensiones: `openBy: 'hover'` para este componente (un hover card no se abre con clic — clicar su `<a>` navega) y `text-decoration-color` en la lista de propiedades, que faltaba pese a estar en `KNOB_PROPS` del censo. Verificado que los otros QUINCE componentes con ledger no se mueven ni una cifra. Los dos tokens que siguen mudos son un conflicto ESTRUCTURAL, no un hueco de demo: para abrir el panel hay que tener el puntero en el trigger, y el hover es justo el estado cuya regla pisa la tinta y el subrayado de reposo — el token de hover lee vivo en la misma corrida. Adjudicados con esa razón. Gates: censo --only 100 % · component:audit PASS · eidos-lint invalid 0, class-hooks 0 · suite eidos sin rojos nuevos (el conocido skin-media-player) · rtl:check 0 · docs:check 0 · check por fichero limpio · README con «Talla y tema» y tab `Tokens` en la demo (33 claves, en vivo). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2 months ago
dev	42a3e74136	uix(spinner): temable — 0 % → 70 %, y 71 tokens propuestos que eran 18 ... 18 claves en el bloque `spinner` de `recipes/base.ts` (fusionadas con los dos forwards de paleta). Censo 0 % → 70 %, cero globales. Global 48 %, sin contrato 44 → 43. **La §4 proponía 71 tokens para 23 knobs — la peor inflación que ha dado el generador en todo el eje.** El spinner tiene UNA coordenada de talla (`--spinner-size`) que gobierna el anillo, la pista de puntos y las barras, más el trazo (`--spinner-thickness`). La propuesta multiplicaba esa única coordenada por variante × parte × dimensión × talla y producía `ring-track-width-xs`, `dots-track-gap-xs`, `dots-dot-width-xs`, `bars-track-gap-xs`… todos con el mismo `0.75rem`, porque todos SON el tamaño en xs. Un tema habría necesitado veinte claves para cambiar un número. 1. Las proporciones son CONSTRUCCIÓN, no knobs: `calc(size * 0.3)` es el punto, `* 0.18` la barra, `* 0.2` y `* 0.12` los huecos. Definen la FORMA de cada variante y se quedan en la receta — mismo reparto que los gradientes de las guías de tree-grid o el damero de gradient-builder. 2. `fg` / `dots-dot-bg` / `bars-bar-bg` ⚠ no eran tres knobs con dos valores en pugna: son UNA variable (`--_spinner-color`) leída en tres sitios, con el conmutador `data-color='inherit'` que la cambia de forward de paleta a `currentColor`. Se queda privada, igual que `--_spinner-track`, que además envuelve su fuente en un color-mix distinto por rama (60 % / 25 %). Aplanarlas exigiría duplicar cada regla por color. 3. La escala es PROPIA, no la del bundle de iconos: medido, 12/16/20/28/40 px contra los 14/16/18/20/32 de `--icon-size-*`, y sólo coinciden en sm. Verbatim con la desviación anotada — forzar el bundle habría movido el default en cuatro tallas de cinco. 4. `duration` entra al contrato en vez de seguir en `0.9s` a pelo: el registro ya tenía abierta la incoherencia de que el spinner de feed ganó tokens de duración y el de media-player no (§13). Aquí se hace bien de entrada. El 30 % que falta son los dos privados conmutadores, los dos `border-radius: 50%` (identidad de forma) y los fotogramas de los @keyframes. Artefactos y gates: - Sonda antes/después = 0 diffs en 377 valores × 7 estados. Determinismo verificado. - R-5.4: 14/18. Los cuatro mudos, medidos uno a uno y adjudicados: la demo monta SÓLO la variante ring y sin etiqueta (0 barras, 0 puntos, 0 labels, contados), y `track-opacity` sólo se declara dentro de `prefers-reduced-motion` — forzando variante, etiqueta y contexto reduce, los cuatro alcanzan. - censo --only 70 % · component:audit PASS · eidos-lint invalid 0, class-hooks 0 · suite eidos sin rojos nuevos (el conocido skin-media-player) · rtl:check 0 · docs:check 0 · check por fichero limpio. - README con su «Talla y tema» y tab `Tokens` en la demo (18 claves, en vivo). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2 months ago
dev	c56d6544e6	uix(card-group): temable — 0 % → 90 %, y dos privados abreviados que mueren ... 20 claves en una entrada NUEVA de `recipes/base.ts`. Censo 0 % → 90 %, cero globales y cero privados. Global 47 %, sin contrato 45 → 44. Es un CASCO de composición y su propia cabecera ya lo decía: compone ToggleGroup, Collapsible, Card y Button, y la receta posee «ONLY the genuinely CardGroup-level visual». Eso acota el contrato antes de nombrar nada — el cromo de las tarjetas es de Card, el del título de disclosure es de Button. 1. **`--_cg-pad` y `--_cg-card-radius` eran privados ABREVIADOS** (§6 r5 los prohíbe: `cg` por `card-group`), el mismo defecto que los `--_mp-*` de media-player. Pasar a públicos con el nombre completo es a la vez el renombrado que la regla pedía y la tokenización. La §3 de la ficha decía «la receta no declara privados propios»: los declaraba en su bloque raíz (`card-group.css:15-16`), y el escáner no los veía por buscarlos con el prefijo completo del componente. 2. **`--shape-outer-radius` NO se acuña: se CALCULA.** La receta lo compone como `card-radius + padding` para que las tarjetas aniden concéntricamente (§30). Un tema mueve las dos coordenadas y el radio exterior se recompone solo; el censo ya lo clasifica como sistema. 3. **El eje `size` es sm|md|lg, no las cinco tallas** (`Extract<Size, 'sm' | 'md' | 'lg'>`): seis coordenadas por talla, no diez. Escribir xs/xl habría sido vocabulario muerto. 4. Los tres `padding` son shorthand con una parte fija y otra variable; lo que varía y no es el inset del grupo es el hueco inferior → `title-padding-block-end` y `description-padding-block-end`. 5. El chevron es geometría propia (dos bordes girados 45°): `chevron-size` cubre las dos dimensiones y `chevron-width` el trazo. Su `currentColor` hereda del título a propósito y no es knob. 6. Los `font-size` van al BUNDLE (`--size-{k}-font-size`, alias 1:1) y no al primitivo crudo — misma trampa que cayó en code-block: la propuesta copia el CSS verbatim y hereda el incumplimiento cuando el valor de partida ya violaba `recipe-css-contract`. Aquí se aplicó de entrada. Artefactos y gates: - Sonda antes/después = 0 diffs en 2.581 valores × 7 estados. Determinismo verificado: dos corridas, 0 diffs. - R-5.4: 15/20. Los cinco mudos son los del encabezado ESTÁTICO, que la demo no monta (0 nodos `[data-static]` contra 1 `[data-button]`, CONTADOS); forzado `data-static` alcanzan los cinco, y cada uno lleva su medición en el ledger. El hueco de demo queda registrado en next-features §13, misma clase que el `kind='month'|'year'` de date-range-picker. - censo --only 90 % · component:audit PASS · eidos-lint invalid 0, class-hooks 0 · suite eidos sin rojos nuevos (el conocido skin-media-player) · rtl:check 0 · docs:check 0 · check por fichero limpio. - README con su «Talla y tema» y tab `Tokens` en la demo (20 claves, en vivo). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2 months ago
dev	354d166df1	uix(code-block): temable — 0 % → 81 %, y la demo que no enseña el componente ... 20 claves en una entrada NUEVA de `recipes/base.ts` (no tenía). Censo 0 % → 81 %. Global 46 % → 47 %, sin contrato 46 → 45. El handoff lo llamaba «el más mecánico de los que quedan». No lo es: sus 26 knobs se parten en dos grupos con doctrinas distintas. 1. **El nodo del código NO acuña nada, y la §4 pedía que lo hiciera.** `[data-code-block-code]` consume la capa tipográfica `--style-code-*` en sus cinco declaraciones, y las dos que pasan por privado usan la forma canónica de la escotilla por instancia (`var(--_code-block-font-size, var(--style-code-font-size))`, escrita por el wrapper desde la prop `size` y sólo si llega). Es el patrón que D-TH.2-b fijó para heading/text/code. Acuñar `code-font-family` y compañía sería el vocabulario paralelo que la regla 2 de capas prohíbe. Todo lo que entra al contrato es el CASCO alrededor. 2. **Los tres `font-size` iban al primitivo crudo, y lo cazó un guard.** La propuesta copia el valor del CSS verbatim, y ese valor ya violaba `recipe-css-contract` («recipes consume the size bundle, not the raw size-coordinate primitives»): `title/lang/copy-font-size` corregidos a `var(--size-{k}-font-size)`. Los alias son 1:1 → 0 diffs tras aplicarlo. Aviso general: cuando el CSS de partida ya incumple el contrato, la propuesta generada hereda el incumplimiento. 3. Shorthand partidos: los dos `border` y el `border-bottom` de la cabecera comparten anchura y color → `border-width` + `border`; el `padding` del `<pre>` → `pre-padding`. Los `transparent` de outline/ghost y el `border: 0` de ghost son identidad de variante. El 19 % que falta son esas cinco de la capa, que el censo cuenta como `global` porque `code-block` no está en `TYPOGRAPHIC_PRIMITIVES` — es un compuesto que CONTIENE un primitivo tipográfico, no uno de ellos. Extender la clase `system` del censo a las capas sigue pendiente de tu firma; la métrica penaliza hacer lo correcto y no se fuerza de oficio. DOS HALLAZGOS QUE NO SE ARREGLAN AQUÍ (→ next-features §13): - **La demo de `code-block` no enseña el `code-block`.** `[data-uix-docs] pre` (`web/routes/uix/uix.css:801`) pesa (0,1,1) contra los (0,1,0) de `[data-code-block-pre]`, y `[data-uix-docs]` es el shell de TODAS las páginas. Siete propiedades del `<pre>` las pinta el harness y no la receta: padding (16px 20px contra 12px), border (1px contra ninguno), radius (8px contra 0), background (gris contra transparente), font-family, font-size (13 contra 14) y line-height (18.2 contra 20.3). El fondo, el borde y el radio que se ven ahí son del sitio. Por eso `pre-padding` lee muerto en el guard, adjudicado con esa medición. Acotar la regla toca el CSS del SITIO, que sirve a ~162 páginas: decisión aparte. - **El guard de claves duplicadas del handoff inspeccionaba el VACÍO.** El comando documentado usa `grep -oE "^\t…"`, y `grep -E` lee `\t` como una `t` literal: 0 coincidencias sobre 130 bloques reales, así que salía «vacío = OK» sin mirar nada — el antipatrón que el proyecto tiene registrado, dentro del propio handoff. Comprobado con un contador fiable: cero duplicados en el árbol, así que no hay daño en los commits que confiaron en él. CONTINUE queda corregido con una versión que CUENTA los bloques y avisa de que «0 bloques» significa guard roto, no fichero limpio. Artefactos y gates: - Sonda antes/después = 0 diffs en 1.305 valores × 7 estados (dos veces: tras la tokenización y tras la corrección del bundle). Determinismo verificado. - R-5.4: 19/20; `pre-padding` adjudicado con las siete propiedades medidas. - censo --only 81 % · component:audit PASS · eidos-lint invalid 0, class-hooks 0 · suite eidos de vuelta al único rojo conocido (skin-media-player) tras corregir el bundle · rtl:check 0 · docs:check 0 · check por fichero limpio. - README con su «Talla y tema» y tab `Tokens` en la demo (20 claves, en vivo). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2 months ago
dev	dd188f1255	uix(tree-view): temable — 0 % → 92 %, y el velo que tiñe la carpeta entera ... 46 claves en el bloque `tree-view` de `recipes/base.ts` (fusionadas con el forward de paleta). Censo 0 % → 92 %, cero globales. Global 46 %, sin contrato 47 → 46. Molde del hermano `tree-grid` allí donde el problema es el mismo. LA PROPUESTA GENERADA FALLABA EN EL NOMBRE DE CASI TODO LO QUE IMPORTA: el clasificador toma el PRIMER selector de cada regla como si fuera la parte pintada, y aquí ese primero es el root o el branch-control cuando el nodo real es otro. 1. `root-width: 1px` / `root-bg` NO son del root: son la GUÍA de indentación (el `::before` del branch, una línea vertical). → `guide-width` + `guide-fg`, literalmente los nombres de tree-grid. Un `root-bg` que tiñe una línea es la clase de nombre que miente. 2. `branch-control-padding-inline-{k}` ⚠ fundía DOS ejes que se SUMAN en el mismo calc: el ritmo de la fila y el PASO DE PROFUNDIDAD (`--tree-depth × indent + padding`). Fundidos, tematizar la sangría habría movido el padding. → `row-padding-inline-{k}` + `indent-{k}`. 3. El prefijo `branch-control-` es erróneo: la regla reza `[data-tree-view-branch-control], [data-tree-view-item]` — las DOS filas. El CSS ya llamaba `row` a sus privados. → `row-*`, como tree-grid y como la lección de table. Y fuera el prefijo `root-` del chasis: el wrapper ES el componente. 4. `row-padding-block` ⚠ no eran dos valores en pugna sino cinco por talla: xs colapsa a `0`, las otras cuatro `--space-1`. 5. `branch-indicator-width` + `-height` son UN knob (`1em`) → `branch-indicator-size`. Bundle: la altura de fila casa 1:1; padding e indent llevan ritmo propio; la tipografía un paso por debajo desde lg — verbatim, como table y tree-grid. Los resueltos con `parts: ['root']` (el `data-size` va en `[data-tree-view-root]`, wrapper de eidos, no parte del morfo). Los `transparent` de outline/ghost y el `padding: 0` de ghost son identidad de variante y siguen literales. `hover-row-bg` SÍ se acuña, al revés que en grid-list, y por medición: la misma regla pinta dos nodos con arquetipo distinto, y `branch-control` NO lleva archetype — ahí el plano de la receta es la única pintura (velo medido ausente) y el token es toda la superficie de tema del hover. Tener un consumidor legítimo es lo que lo distingue del caso grid-list. EL DEFECTO QUE LA MEDICIÓN DESTAPÓ (preexistente, NO se toca aquí → next-features §12.8): al pasar el ratón por la fila de una carpeta abierta se tiñe LA CARPETA ENTERA, hijos incluidos. `archetype: 'item'` está declarado en el `<li>` branch (`morfo/components/tree-view.ts:103`), que contiene el control Y todo el `branch-content`, mientras la fila que el usuario señala es el `branch-control` de dentro: el nodo velado mide 336 px frente a los 36 px de la fila — medido y capturado. Un branch anidado acumula además el velo de sus ancestros, así que sus filas se ven más oscuras que las hermanas. Mover el arquetipo es morfo y mueve píxel en toda la demo. Es la TERCERA variante de la misma familia: table lo tiene en fila Y celda, grid-list en fila Y celda sobre el mismo nodo, y tree-view en un ANCESTRO del nodo señalado. Artefactos y gates: - Sonda antes/después = 0 diffs en 8.062 valores × 7 estados. - R-5.4: 45/46; `disabled-row-fg` adjudicado en el ledger (la demo monta CERO filas deshabilitadas, contadas; forzada alcanza oklch(0.61 0 0) → rgb(1,2,3)). - censo --only 92 % · component:audit PASS · eidos-lint invalid 0, class-hooks 0 · suite eidos sin rojos nuevos (el conocido skin-media-player) · rtl:check 0 · docs:check 0 · check por fichero limpio (72 globales, ninguno mío). - README con su «Talla y tema» y tab `Tokens` en la demo (46 claves, en vivo). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2 months ago
dev	893aeaf817	uix(textarea): temable — 0 % → 80 %, y el contador que casi pierde su 0.85 ... 37 claves en el bloque `textarea` de `recipes/base.ts` (fusionadas con el forward de paleta que ya estaba). Censo 0 % → 80 %, con **cero globales y cero literales de valor**: los 16 privados leen ya su público. Global 46 %, sin contrato 48 → 47. LO QUE LA MEDICIÓN CAMBIÓ. La §4 generada proponía 35 tokens; cuatro eran colisiones y uno habría movido el default: 1. `count-font-size-{k}` × 5 BORRABA el factor 0.85. El CSS calcula `calc(var(--_textarea-font-size) * 0.85)` y la propuesta ponía el tipo del input crudo en las cinco tallas: el contador habría crecido un 18 %. D-TH.5 lo prohíbe. Queda en UN token con el `calc` sobre el público del input — la escala se escribe una vez y la talla la resuelve el input. Pide `scope: 'host'`: emitido en `:root` su dependencia no existe, y el contrato de scope de la receta lo caza (lo cazó). 2. `input-fg` ⚠ eran DOS knobs (texto y placeholder) → `input-fg` + `input-placeholder-fg`. Igual `count-fg` → `count-fg` + `overflow-count-fg`. 3. `input-border` ⚠ NO eran dos knobs sino UNA variable con su swap de paleta, y el nombre estaba mal: es el borde de FOCO → `focus-input-border`. El de reposo es otro token, que la propuesta ni listó por viajar en el atajo. 4. `ghost-input-border` se RETIRA: la regla ghost lee ese mismo conmutador — sería un valor con dos nombres. Bundle, medido: la tipografía casa 1:1 en las cinco (lee `--size-{k}-font-size`); el spacing NO — `padding-inline` casa salvo en xs (8px vs 6px) y `padding-block` sólo en xs. Verbatim y documentado: un campo multi-línea respira más, y el spacing queda fuera del guard del bundle. Resueltos sin `parts` (el `data-size` va en `[data-textarea]` y el input hereda); fuera los cuatro `[data-size]`. DOS ARREGLOS DEL INSTRUMENTO, los dos por medición y no por sospecha: - **El guard medía con el PUNTERO encima.** `reopen()` corre antes de CADA token y hace clic en `[data-{c}-input]` cuando el componente no tiene parte `content`; el `blur()` de la revisión adversarial quitaba el foco pero no el puntero, así que `:hover` casaba toda la corrida y toda regla de hover pisaba a sus vecinas. Costaba TRES falsos negativos aquí. Con `mouse.move(0,0)` tras cada blur, `input-border` revive solo (31 → 32). - **`::placeholder` SÍ se lee con `getComputedStyle`.** La nota de §13 que decía lo contrario nunca se comprobó; medido, el color centinela vuelve tal cual. Entra en el snapshot (32 → 33) y deja STALE la entrada `command.input-placeholder-fg`, que el guard señaló y se ha borrado. Corridos los DIEZ componentes con ledger tras los dos arreglos: ningún otro cambia, un único STALE, el previsto. Y un hallazgo de píxel que NO se toca aquí (→ next-features §13): el borde de foco sólo se ve con Tab. Las tres reglas de `border-color` del input están ordenadas al revés de lo que significan — hover (0,4,0) > foco (0,3,0) > invalid (0,2,0) — y hacer clic deja el puntero encima por definición, así que gana el hover; un campo inválido pierde su borde rojo al enfocarlo o al pasar el ratón. El anillo de foco del sistema sí se ve siempre, así que no es fallo de accesibilidad. Arreglarlo mueve píxel. El 20 % que falta son las dos declaraciones que consumen `--_textarea-border-focus`, privado a propósito: es el conmutador de una variable con dos fuentes (el público y el forward THM-2), y aplanarlo exigiría duplicar la regla por color. Mismo techo que `listbox` paga por consumir bien su capa. Mi propio veredicto predecía ~100 % y la medición lo corrigió a 80 %. Artefactos y gates: - Sonda antes/después = 0 diffs en 1.247 valores × 8 estados (el 0.85 intacto, que era el riesgo). Determinismo verificado: dos corridas, 0 diffs. - R-5.4: 33/37; los 4 mudos adjudicados en el ledger con su medición (foco, invalid y las dos del contador rebasado — estados que la demo no monta). - censo --only 80 % · component:audit PASS · eidos-lint invalid 0, class-hooks 0 · suite eidos sin rojos nuevos (el conocido skin-media-player) · rtl:check 0 · docs:check 0 · check por fichero limpio (72 globales, ninguno mío). - README con su «Talla y tema» y tab `Tokens` en la demo (37 claves; el panel muestra el contador computando `calc(calc(1rem * 1) * 0.85)`). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2 months ago
dev	60b5b98969	uix(grid-list): temable — 0 % → 85 %, y una selección que nunca pintó ... 38 claves nuevas en el bloque `grid-list` de `recipes/base.ts` (que ya existía con los dos forwards de paleta: se FUSIONA, no se añade un segundo). Alcance del censo 0 % → 85 % (22 de 26 puntuables); global 45 % → 46 %, sin contrato 49 → 48. El eje `size` se estampa en el PROVIDER —el wrapper de eidos no tiene parte `root`—, así que los tres nombres resueltos van SIN `parts`: molde `command`, no `table`/`tree-grid`. Fuera los cuatro bloques `[data-size]` del CSS; los emite el TSC. Altura de fila 1:1 con el bundle, `row-padding-inline` con ritmo propio, y la tipografía un paso por debajo de md en adelante — verbatim, como table y tree-grid. LO QUE LA MEDICIÓN CAMBIÓ (la §4 generada tenía un error de doctrina y dos defectos que sólo aparecieron midiendo; el §5 Veredicto se escribió con la sonda delante, porque estaba vacío): 1. La selección de fila NUNCA HA PINTADO. La receta seleccionaba `[data-grid-list-row][data-selected]`, un atributo que ni el morfo declara ni soma estampa (estampa `data-state='selected'` + `aria-selected`): la regla no casaba jamás y su acento `--_grid-list-palette-element` no llegó nunca al píxel — una fila seleccionada muestra el velo NEUTRO del arquetipo, indistinguible del hover (capturado). Retirada la declaración muerta y su forward huérfano: 0 diffs, que es la prueba. Repararlo mueve píxel y choca con §12.5 (el arquetipo fija también `color`) → §13, espera firma. El acento del checkbox (`_palette-solid`) sí vive y se conserva. 2. NO se acuña `hover-row-bg` aunque la propuesta lo pedía. La fila es `archetype: 'item'`: el velo del sistema la pinta a especificidad plena y el plano de la receta pierde — medido, el hover pinta DOS VECES sobre el MISMO nodo (a diferencia de table/tree-grid, donde velo y plano caen en nodos distintos). Sería un token que no puede ganar; mismo criterio que listbox.highlighted → §12.7. Y fila Y celda llevan ambas `item`, así que bajo el puntero se apilan tres capas. 3. «Consume la capa compartida `menu-indicator`» es FALSO. Sale de `SHARED_LAYERS` (`theming-census.ts:432`), pero esa capa no tiene un solo selector de grid-list, la receta no la importa y soma no renderiza indicator: el checkbox ESPEJA el visual pintándolo por su cuenta. Entrada desviada del censo → §13 (listbox / menubar / navigation-menu están en la misma entrada y tampoco aparecen en el fichero). Nombres, sobre la propuesta: `selection-checkbox-{width,height}` son UN knob → `selection-checkbox-size`; `on-selection-checkbox-bg` → `checked-selection-checkbox-fg` (es la tinta del glifo, y `on-` es prefijo reservado); `border` partido en `border-width` + color (molde `command.input-border*`), que el checkbox comparte; `padding` uniforme se queda `padding` (precedente `command.viewport-padding`); `max-block` entra al contrato (molde `command.viewport-max-block`). Artefactos y gates: - Sonda antes/después = 0 diffs en 6.090 valores × 7 estados. Determinismo verificado: dos corridas del mismo código, 0 diffs. - R-5.4: 37/38 tokens mueven un computed. `invalid-border` adjudicado EN EL LEDGER con su razón medida (la demo arranca con su control en off; activado a mano alcanza: oklch(0.9555 0.0207 13.86) → rgb(1,2,3)). - censo --only 85 % · component:audit PASS (R-5.3 incluida) · eidos-lint invalid 0, class-hooks 0 · suite eidos sin rojos nuevos (el único es el conocido skin-media-player) · rtl:check 0 · docs:check 0 · check por fichero limpio (72 globales, ninguno mío). - README con su «Talla y tema» y tab `Tokens` en la demo (38 claves, leídas en vivo). El tab `Recipe` documentaba la regla retirada: corregido. Las fichas de calendar / carousel / command / month-grid / range-calendar / table / year-grid entran porque `--report` regenera el informe entero: sólo actualizan NÚMEROS DE LÍNEA de commits ya hechos que no lo regeneraron. Cero cambios de alcance. Las otras 161, que sólo cambiaban la fecha, se revirtieron. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2 months ago
dev	34a95a550c	feat(feed): temable — 0 % → 94 %, y cierra el bloque F2-A ... Octavo y último del bloque. censo 0 % → 94 % · global 43 % computed reposo y las CINCO tallas, idénticas al byte **El título no escala por talla: escala por NIVEL DE ENCABEZADO.** El informe leyó sus cuatro valores como una colisión de `size`, y son `aria-level` 3..6 — un encabezado más profundo es más pequeño porque es más profundo. Sus tokens son `article-title-font-size-{3,4,5,6}`, no coordenadas de talla. Tercera corrección de este tipo a un veredicto en el bloque. **El ⚠ del `sentinel` eran DOS medidas**, como sospechaba el veredicto: la fila-sonda mantiene un alto mínimo para que el observador tenga algo que intersecar, y el spinner que va dentro tiene su propio diámetro. El feed tipa por debajo del 1:1 de md en adelante, como `table` y `tree-grid`; la coordenada lo nombra en vez de esconderlo. **Sobre la medición, que aquí hubo que trabajarla.** La sonda dio 7 diffs y ninguno era un cambio: - el `box-shadow` del nodo `[data-busy]` está ANIMADO, y la sonda congela `transition` pero nunca `animation` —a propósito, porque congelarla impide que Presence monte nada—, así que lo muestrea en una fase distinta cada vez: dos corridas del MISMO código dan cinco diffs; - y el estado `hover` se mide después de haber forzado las tallas, así que su altura arrastra la última. Lo que decide es que las SEIS medidas estables —reposo y las cinco tallas— salieron idénticas al byte: 544,5 · 564,5 · 628,5 · 792,5 · 966,5 px. Queda escrito en el README para que el siguiente no persiga el mismo fantasma. audit PASS · eidos-lint 0 invalid · rtl 0 · docs 0 · check 0 en tocados · suite: sólo el rojo conocido Demo con tab Tokens: 50 filas, 0 sin computar. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
dev	4cab776677	feat(carousel): temable — 0 % → 77 % ... Séptimo del bloque F2-A. censo 0 % → 77 % · global 42 % computed 2.842 valores en 7 estados: 0 diffs **Los botones prev/next no se acuñan aquí** — componen `<IconButton>`, así que su cromo es el del Button y un tema los viste por ahí. Esta receta sólo decide DÓNDE se colocan (`trigger-offset`). El veredicto avisaba de comprobarlo antes de copiar filas de trigger, y estaba en lo cierto. **El ⚠ del informe eran DOS gaps distintos**, no un knob con dos valores: el `gap` en columna de la raíz y el `item-gap` ENTRE DIAPOSITIVAS. Y el segundo sólo se aparta del default en `xs`, así que su cascada declara UN override en vez de cinco coordenadas iguales — el TSC no necesita que se le repita lo que ya hereda. **Los puntos del paginador son geometría propia**: 0.375–0.75rem por talla, ni bundle ni desviación que marcar, porque el bundle no tiene coordenada que signifique «un punto». El punto activo se estira a pastilla con un factor que ahora es token (`active-indicator-scale`): es lo que lo hace leer como «estás aquí» y no como un punto más gordo. **El radio interior es concéntrico**, no un segundo radio: viewport y diapositivas redondean por dentro del marco, así que su esquina es la del marco menos el borde — el `2px` suelto pasa a `inner-radius-inset`. Las tres variantes (surface / outline / ghost) entran enteras: padding del marco, borde y superficie. Quedan 5 literales de layout (`block-size: 100%` ×3 para que el viewport vertical no colapse, `max-content` del raíl de puntos) y los 2 privados de paleta. audit PASS · eidos-lint 0 invalid · rtl 0 · docs 0 · check 0 en tocados · suite: sólo el rojo conocido Demo con tab Tokens: 30 filas, 0 sin computar. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
dev	3b325c4394	feat(listbox): temable hasta donde le toca — 0 % → 68 % ... Sexto del bloque F2-A, y el primero cuyo techo es DELIBERADO. censo 0 % → 68 % · global 42 % computed 2.813 valores en 7 estados: 0 diffs **Este componente no puede acuñar su ritmo de fila, y esa es la regla de oro de las capas compartidas.** Altura, padding inline y block, gap y tamaño de letra los posee `lib/list-surface.css`, por talla, para TODAS las superficies de lista —select, combobox, command y los menús—. Acuñar `--listbox-item-height` sería el vocabulario paralelo que las reglas de esa capa prohíben, y encima ganaría a la capa para todas las demás. Los cinco privados ADOPTAN la capa y se quedan privados; un tema mueve ese ritmo por `--list-*`, que es donde vive. Consecuencia honesta: el censo cuenta esos cinco como privados y el alcance se queda en 68 % en vez de ~86 %. **La métrica penaliza hacer lo correcto** — el mismo defecto de medición que D-TH.2-b arregló para los primitivos tipográficos (`--style-*` pasó a `system`). Registrado en `next-features.md` §13; extenderlo a las capas compartidas es decisión, no corrección al paso. **Dos cosas medidas que NO se tocaron:** - El `highlighted` pinta DOS veces: la receta pone un `--color-surface-overlay` plano y encima el arquetipo `item` añade su velo del 8 %. El plano es el duplicado que §38 deprecó, así que se dejó SIN token — bendecir con un nombre público algo condenado a morir es el error que este eje ya evitó en el codemod. Retirarlo mueve píxel. - La tinta de la fila seleccionada era código MUERTO y se retiró: el arquetipo la fija a (0,4,0) contra los (0,3,0) de la receta. Mismo hallazgo que en `table`, verificado igual, 0 diffs al quitarlo. Lo que sí es suyo y ahora es público: la superficie que sostiene las filas (fondo, borde, radio, padding, gap, tipografía, alto máximo), la esquina y la tinta de la fila, el glifo de selección y el grupo con su etiqueta. audit PASS · eidos-lint 0 invalid · rtl 0 · docs 0 · check 0 en tocados · suite: sólo el rojo conocido Demo con tab Tokens: 21 filas, 0 sin computar. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
dev	d177ee331c	feat(gradient-picker): temable — y su trigger resultó estar muerto entero ... Quinto del bloque F2-A. censo 0 % → 88 % · global 42 % computed 609 valores en 8 estados: 0 diffs **El hallazgo llegó por el centinela: 36 de 45 tokens no movían nada.** Con esa cifra no se sigue adelante. El trigger es un POPOVER TRIGGER, y `popover.css` le pinta el cromo entero —altura, padding inline, tipografía, color, fondo, borde, radio, hover y foco— desde `[data-popover-trigger]:not([data-archetype='field-trigger'])`, que gana a `[data-gradient-picker-trigger]` en base (0,2,0 contra 0,1,0) y en los estados (0,3,0 contra 0,2,0). Esta receta re-declaraba TODO eso y nada pintaba: la altura, el padding, el tamaño de letra y el radio venían de popover, y con valores distintos —12px contra el `space-2-5` de la receta, 14px contra su `font-size-md`—. Llevaba así desde que el trigger se volvió trigger de popover. Así que no se tokeniza: **se retira**. Un token sobre una declaración muerta es un token que miente, y este eje ya retiró uno por lo mismo en `table`. Retirarlo dio **0 diffs**, que es la prueba de que estaba muerto. Un tema viste este trigger por el contrato de POPOVER, que es composición funcionando. Lo que sí es del picker se queda y alcanza (verificado a mano, porque el chip usa un hook de CLASE que el centinela no ve): el `gap` de la fila, el chip del degradado (tamaño por talla, radio, borde), las tres anchuras del panel, la lista de paradas y la rejilla de presets. **Correcciones al veredicto**, ambas medidas: `--gp-current-gradient` NO lo estampa el wrapper sino SOMA (`gradient-picker-provider.svelte.ts:197`), así que renombrarlo toca otra capa y no es de este commit; y no es un knob de tema sino un canal de valor —el degradado que eligió el usuario—, sobre el que un tema no tiene nada que decir. Las tres anchuras del panel se quedan como tokens planos leídos por tres reglas, no como cascada del TSC: el content va por PORTAL y dimensiona con `data-picker-size` (el atributo de picker-shell), y el vocabulario de scopes no tiene palabra para el atributo de otro componente. Al registro (`next-features.md` §13) van cuatro incidencias nuevas: que un componente compuesto pueda tener el cromo entero muerto sin que nada avise —merece guard, y el instrumento ya existe—, el nombre abreviado en soma, los dos hooks por CLASE que `eidos-lint` cuenta, y el foco opaco del trigger contra la mezcla suave del sistema. audit PASS · eidos-lint 0 invalid · rtl 0 · docs 0 · check 0 en tocados · suite: sólo el rojo conocido Demo con tab Tokens: 25 filas, 0 sin computar. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
dev	9748733adc	feat(tree-grid): el árbol se vuelve temable — 0 % → 95 % ... Cuarto del bloque F2-A. 42 knobs con 29 privados que no derivaban de nada; ahora 47 claves públicas y tres privados, los tres legítimos. censo 0 % → 95 % · global 41 % → 42 % computed 9.744 valores en 7 estados: 0 diffs **Las guías de indentación eran UN color, no un fondo.** Lo que la propuesta llamaba `root-bg-image` son las líneas verticales por `aria-level`: cinco gradientes apilados que dibujan una línea por ancestro. El knob es `guide-fg` (+ `guide-width`); la construcción se queda en la receta — el mismo reparto que el damero de gradient-builder, donde el color es el token y el patrón es de la receta. **Tres privados sobreviven, y por razones distintas**: `--_tree-grid-columns` no es un knob de tema sino un CANAL de layout que el wrapper escribe inline desde la definición de columnas del consumidor; `--_tree-grid-palette-element` es el forward THM-2; `--_tree-grid-stable-rows` es dato del consumidor. **El hover de fila es no determinista, y viene de antes de este eje.** Dos hallazgos medidos: 1. En filas CON BANDA el hover está muerto: la regla de `striped` pesa (0,7,0) contra los (0,5,0) del hover y usa el atajo, así que en las pares no ocurre nada al pasar el ratón. 2. En las demás, quién gana depende del ORDEN DE CARGA: el velo del arquetipo `item` y el hover de la receta empatan EXACTAMENTE a (0,5,0). Seis corridas de la misma configuración dieron cuatro veces «sin velo» y dos «con velo». Eso segundo obligó a parar y caracterizarlo: al ver 3 diffs tras un cambio trivial (un `border-width` a token) lo primero que hice fue sospechar de mi cambio; comparar dos corridas del MISMO código dio los mismos 3 diffs, así que no era el código sino un empate de especificidad resuelto por orden — la misma clase de fragilidad que el canon documenta para las bandas de z-index. No se toca aquí: decidir quién manda mueve píxel y es la decisión pendiente del velo. El guard de huérfanos cazó tres tokens que acuñé suponiendo (`font-family`, `fg`, `surface-bg`): existían en la receta pero leyendo el valor crudo. Ahora los leen, que es justo lo que el eje persigue. audit PASS · eidos-lint 0 invalid · rtl 0 · docs 0 · check 0 en tocados · suite: sólo el rojo conocido `skin-media-player` Demo con tab Tokens: 47 filas, 0 sin computar. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
dev	b7a4cef08f	feat(media-player): el proyector se vuelve temable — 0 % → 88 % ... Tercero del bloque F2-A. 45 knobs sin contrato salvo el acento; ahora 61 claves públicas, **cero privados y cero globales**. censo 0 % → 88 % · global 40 % → 41 % computed 3.277 valores en 7 estados: **0 diffs** **El veredicto pedía renombrar `--_mp-*` → `--_media-player-*`; hacen falta menos pasos que eso.** El prefijo abreviado viola theming §6 r5, cierto, pero al leerlos uno a uno los dieciséis privados eran ALIAS PUROS de su fuente (`--_mp-fg: var(--color-content-primary)`, `--_mp-accent: var(--media-player-accent)`…). Un alias puro no se renombra: se borra. La capa privada entera desaparece y cada knob pasa a público. **El acento firmado NO se tocó**: `accent`/`accent-strong` siguen siendo `--scale-amber-9/10` — acento de proyector theme-stable, que debe leerse sobre cualquier vídeo en claro Y oscuro, con su doctrina escrita en el propio bloque. Verificado en vivo que sigue re-tintando el rango del Slider compuesto. **El scrim: UN color, dos gradientes.** La tira inferior de controles y el degradado del título salen del mismo `--media-player-scrim`; dos tokens dejarían que un tema rompiera la pareja sin querer. **`audio-player` viajaba en el mismo barco y no era obvio**: consume siete de esos tokens sin declarar ninguno. No es fuga entre componentes — es un SKIN sobre las mismas partes (`[data-media-player][data-variant]`), así que están en ámbito. Su receta se migró en el mismo pass. **Lo que no se pudo medir, y se dice**: `audio-player` no tiene página de demo (la ruta da 404), así que la sonda encontró 0 nodos — y una comparación de 0 valores pasa siempre, que es justo la clase de guard que no vale. Se verificó a mano estampando `data-variant` sobre el player vivo: el padding pasó a `6px 12px`, exactamente los tokens nuevos. Hueco de demo anotado en el README. Centinela 36/61. Los 25 restantes, adjudicados por clase: partes no montadas en la demo (captions, buffering, título de audio, paneles portalados), un pseudo-elemento (`::after` del scrim) y los que pintan DENTRO del Slider compuesto — verificado a mano que `--media-player-track` sí llega hasta `--slider-track-bg`. Los 6 knobs que quedan son literales de relleno (`100%`, `max-content`). audit PASS · eidos-lint 0 invalid · rtl 0 · docs 0 · check 0 en tocados · suite: sólo el rojo conocido `skin-media-player` Demo con tab Tokens: 61 filas, 0 sin computar. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
dev	564133b485	feat(table): la rejilla se vuelve temable — 0 % → 86 % ... Segundo del bloque F2-A. 46 knobs sin una sola entrada de contrato; ahora 45 claves públicas. censo 0 % → 86 % · global 39 % → 40 % computed 13.050 valores en 7 estados: **0 diffs** **Una trampa esquivada de milagro**: `table` YA tenía bloque en `base.ts` — los forwards de paleta THM-2. Insertar uno nuevo habría creado un segundo bloque `table:` y el catálogo lo habría descartado EN SILENCIO (gana el último). Las claves se fusionan en el existente; el guard de duplicadas lo confirma. **Dos nombres corregidos, como decía el veredicto**: lo que el privado llamaba `root-height-{k}` es la altura de la FILA (`row-height-{k}`), y el prefijo `root-` desaparece del resto — el envoltorio ES el componente y recipe-contract §1 no repite la parte en ese caso. **Qué casa con el bundle y qué no**, medido eje a eje: la altura de fila sí (1:1); el padding NO (la rejilla empaqueta más denso en xs y más suelto de md en adelante — forzar el bundle cambiaría el default); y la tipografía casa DESPLAZADA: de md en adelante la tabla tipa un paso por debajo (`font-size-md` = `var(--size-sm-font-size)`), que es deliberado y ahora se lee en el propio nombre de la coordenada en vez de esconderse en un primitivo. **Dos hallazgos del arquetipo `item`, y ninguno es mío** — la fila lo lleva, y ese velo de `archetypes.css` está a especificidad PLENA (0,5,0), a propósito: 1. **La prop `hoverable` no suprime nada.** Una fila se ilumina al pasar el ratón aunque el atributo no esté — medido con hover real, y ocurría ANTES de tocar esta receta. El arquetipo y la prop no se ponen de acuerdo sobre quién decide: es decisión de morfo, se presenta, no se toca de oficio. 2. **`selected-row-fg` era un token que mentía.** La misma regla fija el `color` de la fila seleccionada y gana a la receta (0,5,0 contra 0,3,0), así que el token no podía mover nada nunca. Lo cazó el centinela; retirado con su declaración muerta. La tinta de la fila seleccionada es del arquetipo. Y una corrección de rumbo a mitad de camino: al pasar todo a `background-color` el velo apareció en 3 sort-triggers (su velo sí va en `:where()`, 0,0,0). Eso es el barrido sistemático del velo, que NO está firmado — así que en los nodos velados se mantiene el atajo a propósito, con el porqué escrito en la línea. Primero lo diagnostiqué como regresión mía; la medición lo corrigió. Los 6 knobs que quedan: 3 privados de paleta (patrón THM-2, capa compartida) y 3 literales de layout/identidad (`inline-size: 100%` ×2, `opacity: 1`). El test `horizontal-escape` afirmaba el nombre del privado; ahora afirma el público, que es justo lo que este eje persigue. audit PASS · eidos-lint 0 invalid · rtl 0 · docs 0 · check 0 en tocados · suite: sólo el rojo conocido `skin-media-player` Demo con tab Tokens: 46 filas, 0 sin computar. README con «Talla y tema» y los dos hallazgos del arquetipo. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
dev	90aa6dc5f0	feat(demos): la demo enseña el contrato de tokens — `TokensPanel` ... Hallazgo del autor mirando `command`: la demo no enseñaba su superficie de tema. Al ir a comprobarlo salió que **ninguna** demo lo hacía — ni las que este eje ya llevó de 0 % a 98 %. El tab `recipe` lista SELECTORES; los tokens no aparecían en ningún sitio, y lo más cerca era el tab `system` de 23 demos, que en `sidebar` enseña 3 de sus 40 claves. Un componente temable cuya demo esconde sus tokens está a medio entregar: la demo es el producto. `TokensPanel` es un panel COMPARTIDO (junto a SemaPanel / MotionPanel / SystemAxes), no una tabla a mano por demo: pregunta `eidos.getRecipeTokens(component)` — la misma entrada de `recipes/base.ts` que alimenta al generador — así que un token añadido, renombrado o retirado aparece aquí sin que nadie se acuerde de tocar la demo. Una lista escrita a mano sería una segunda fuente de verdad, y en este repo ya está medido lo que cuestan. Tres columnas: el nombre, el valor DECLARADO, y lo que COMPUTA sobre el escenario vivo. Esa tercera es la que convierte «es temable» en algo que se ve en vez de algo que el doc afirma. Un knob por talla o por ámbito se muestra como tal en vez de fingir un valor único. Verificado en el navegador con `command`: **57 filas, 0 sin computar** (`--command-input-padding-inline-sm` → `var(--size-sm-padding-inline)` → `calc(8px * 1 * 1)`). Entra en el protocolo del bloque F2-A: cada componente que se tokenice engancha su tab en el mismo commit. Para los 160 que aún no tienen contrato el panel dice justo eso — que todavía no son alcanzables por un tema. check 0 errores en ficheros tocados Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
dev	bd916ef3fb	refactor(eidos): el catálogo habla un idioma — 269 claves al vocabulario firmado ... D-TH.6, ejecutada. El slot de tinta pasa a `fg` y el modificador interactivo se pone delante, que es lo que theming §6.7 r7 documentaba sin guard desde que se escribió. Value-preserving: renombra la clave en `recipes/base.ts` y sus 793 referencias en 101 ficheros; no toca un solo valor. claves renombradas 269 en 66 componentes referencias 793 en 101 ficheros censo antes/después 162 recetas · 5.203 knobs · 1.841 públicos (37 %) · 56 sin contrato — IDÉNTICO, como debe ser un rename --names antes/después 269 desviadas → 0 Qué NO entra, y por qué: 47 `{rol}-{slot-de-rol}` canónicas: COLOR_ROLE_SLOTS pone el modificador detrás POR CONSTRUCCIÓN (`primary-solid-hover`) 13 exentas firmadas `--focus-ring-*` es familia del sistema; el color de `aura` es un sustantivo; `stop-color` ES una parte de gradient-builder 47 hovers neutros por VALOR: migran a la capa de estado (§38 + R-4.3), no se renombran — firma 3 6 ocurrencias en historia changelog, errores-toxico, PLAN-affix/background: reescribir un registro fechado lo vuelve mentira El clasificador vive en el censo (`--names`), no en un script suelto, para que el guard R-5.3 consuma la MISMA gramática que el codemod. Su muta-prueba (`__names-mutatest.ts`, 27 casos) es lo que hizo el trabajo: cazó que yo promovía al frente CUALQUIER valor declarado por el morfo, y así `--sidebar-width-icon` (la anchura del raíl colapsado) se convertía en `--sidebar-icon-width` (la anchura de un icono), que es otra cosa. La firma dice «delante lo interactivo, detrás lo dimensional y contextual»: ahora sólo promociona el vocabulario interactivo cerrado, y lo contextual —`below`, `loaded`, `vertical`, `icon`— se queda donde estaba. Los cinco casos de regresión están en la muta-prueba. También cazó que `dropdown-menu.item-bg-hover` lee `var(--color-primary-element)`: es un hover CON VALENCIA (el palette swap de recipe-contract §2), no el hover bespoke que §38 deprecó. Clasificar por el nombre lo habría metido en una migración que no le toca; se clasifica por el VALOR. Verificación (§7.4, artefacto por paso): diff de generated/ 269 renombres 1:1 · 0 cambios de valor · 22 privados reapuntados a los nombres nuevos (`__names-verify-diff`) computed tag-group · field · tabs: 6.467 valores en 23 estados, 0 diffs — y comprobado en el navegador que sirve el CSS nuevo, para que ese 0 no sea el de una copia cacheada huérfanos 0 en código suite eidos 434 pasan · 1 rojo, el conocido (`skin-media-player`). `recipe-css-contract` verde: es el guard que caza el `var()` sin fallback a un nombre que ya no se emite, o sea el fallo exacto de un rename a medias component:audit 163 PASS · 3 NEEDS-WORK, los tres SIN TOCAR por esto check 0 errores en ficheros tocados (los 73 globales son de otras sesiones de la rama; se atribuye por fichero) rtl:check 0 · docs:check 0 formato el renombrado no alarga ninguna línea: ningún fichero tiene más líneas de 100 chars que antes, así que no se pasa prettier — hacerlo reformateaba 300 ficheros de deriva ajena Entra aquí la corrección del repaso de los 7 ya hechos: `gradient-builder.checker-color` → `checker-fg` (el damero de transparencia; ahí `color` era slot). Sus `stop-color-*` no se tocan. Queda para el paso siguiente: R-5.3 no puede graduar a `error` directo mientras los 47 hovers neutros sigan hablando el idioma viejo — o migran antes (firma 3, ya firmada), o el guard necesita una exención greppable. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
dev	4a27715170	uix(section): la sección de una página es un componente, no un esqueleto que cada block reescribe ... Los 19 blocks del tier repetían el mismo chasis: un <section {...rest}> escrito a mano, dentro Section (el aire), dentro Container (la medida) y a veces Background (la decoración). Medido antes de tocar: containerSize recableado en 16 blocks, sectionSize en 15, decor en 9, y OCHO copias del mismo Header — Box maxWidth 48rem + Motion viewport + Stack gap 3—, una de las cuales ya había derivado en silencio: la de article-grid perdió su Motion. La regla del propio tier dice que una parte se gana el compound cuando SE REPITE. Aquí lo que se repite son los blocks, así que la repetición se gana un componente. Y no uno nuevo: ese componente ya existía a medias y se llama Section. Crece en vez de nacer un hermano — un segundo componente obligaría a explicar en cada README en qué se diferencia de Section, y la explicación sería «Section con tres props más». Section gana, todo opcional: containerSize (compone Container DENTRO, y sin él los hijos se renderizan igual que siempre), decor (pinta Background.Pattern como HIJO, para que la banda sangre a todo el ancho por detrás de la medida sin ganar caja) y la parte Section.Header. Y renderiza un <section> real. Renderizaba un <div> a propósito, con la nota «si un consumidor necesita un <section> de verdad para el landmark, que lo envuelva» — y nueve blocks hacían exactamente eso, pagando un nodo extra para poder nombrarse. Un <section> sin nombre NO es landmark (se expone como region sólo al llevar nombre accesible, que es lo que A-109 dejó medido esta misma semana), así que el tag no ensucia el árbol de nadie y la raíz duplicada desaparece. Para eso Box gana `as`, que cierra F21 («los primitivos de layout no pueden cambiar de elemento»): lista CERRADA de elementos contenedores, nunca void — es una escotilla semántica, no un prop de tag libre—, default 'div', y el modelo de caja, las vars y la receta idénticos rinda lo que rinda. Los ≥2 casos reales que la decisión original pedía para reconsiderarlo llegaron hace tiempo: la columna de enlaces del pie que debía ser ul/li, y estos dieciséis blocks. Migrados DOS como prueba, uno por clase: feature-grid (medida) y stats-band (medida + decoración). Cada uno pierde dos niveles de anidamiento y su <section> duplicado — medido en navegador: [data-section] ES el <section>, el patrón 'grid' sigue siendo su hijo, 1280 de ancho, 64px de aire, 1024 de medida, y el documento pasa de 3 elementos <section> a 2. Los otros 17 van en tandas aparte. ⚠️ El paso de tipos que costó los únicos 5 errores de esta rama, y que lo explica una regla ya escrita en el propio types.ts de stats-band: «sub-parts extend the props of the canon component they wrap, never HTMLAttributes: the raw attribute surface clashes with the canon's refined style/class when spread through (the feature-grid lesson)». Ahora la RAÍZ también envuelve un componente del canon, así que sigue la misma regla: FeatureGridProps y StatsBandProps extienden SectionProps. Gates: svelte-check 72/62 antes y después · vitest eidos+blocks 470/471 (el rojo es skin-media-player, ajeno y documentado) · blocks:check 0/19 · docs:check 0/0. Prosa al día: README de Box y de Section, la demo de Section (que anunciaba la limitación en cuatro sitios) y F21 cerrado en PLAN-blocks-quality §6. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
dev	18165e74ed	uix(blocks-demos): la vista previa nace con el estado vivo de ActiveUix, no con los defaults ... El iframe de la vista previa es OTRO documento con OTRO runtime (BootUix corre su propio createActiveUix), así que el estado de la sección no cruza el marco: la rama de 375/768 se abría SIEMPRE en claro, y en 9 demos siempre en LTR, con la topbar en oscuro y RTL delante (A-29). Dentro del documento los blocks siempre atendieron a ActiveUix — el shell conduce el framework por uix.prefs.setIntent y el modeSource de eidos —; lo que faltaba era la única serialización que existe entre dos runtimes: la URL. El arreglo va en el ARNÉS, no demo a demo. BlockDemo lee el estado VIVO por la superficie sancionada del framework — readActiveUixPrefsSlot(uix.prefs, 'direction'|'language')?.get(), las lecturas por dimensión que son rune-backed (contador $state por dimensión), y eidos.getThemeContext().mode, que lee el modeSource del shell — y compone la URL final: los props del BLOCK los pone el demo, los EJES los pone el arnés. El {#key} y el enlace «abrir ↗» pasan a la URL resuelta, así que mover un toggle global re-monta el iframe con los params nuevos y el enlace abre lo que estás viendo. Retirados los 11 controles «dir (solo la vista previa)» de banner, contact, cta, feature-grid, feature-split, hero, newsletter, site-footer, site-header, stats-band y team: eran el eje de sección repetido por demo — la regla del arnés dice que tema, idioma y dirección los da el shell — y no tocaban prefs, sólo escribían la URL. El shell queda como único dueño de los ejes; una precedencia demo-gana habría dejado el toggle global inerte en esas páginas. Dos correcciones a la ficha: testimonials ya derivaba su URL (el literal desnudo quedó atrás en F2b), y el alcance real era el sistémico que la propia ficha apuntaba — mode= no viajaba en NINGUNO de los 19 demos y dir= faltaba en 9. La pata lang sigue siendo inerte salvo en contact (blocks.* registrado), pero viaja igual: es un eje del shell. Verificado con la topbar REAL de la sección, no con params a mano: en oscuro + RTL, el iframe de pricing a 375 arranca base-dark + dir=rtl (tinta oklch(0.9491 0 0)) y el de hero — que tenía control local — hereda igual; en el estado por defecto los dos vuelven a base-light + ltr. La URL sale con los props del block primero y mode/dir/lang detrás. Gates: svelte-check 72/62 antes y después · blocks:check 0/19 · docs:check 0/0. Huella: BlockDemo +31, cada demo −18 (−192/+39 en total). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2 months ago
dev	48bad6c726	uix(feature-split): una sección se nombra por su encabezado, y sus filas cuelgan de él ... feature-split era el único block de sección del tier sin parte .Header. Sus filas emitían h2 por defecto, así que una sección de tres filas aportaba tres h2 hermanos al outline y la sección misma no tenía nombre (A-110). La página compuesta lo rodeaba a mano: encabezado escrito como primer hijo y un level={3} repetido fila a fila. El h2 de las filas no era un descuido: era una decisión ESCRITA en el README del block —«.Title emits h2 by default (each row is a section-level statement of its own)… drop it to 3 when the page already put an h2 above the rows»—. Se deroga en sitio, y no por gusto sino porque el resto del tier declara lo contrario: FeatureGrid.ItemTitle, las preguntas de faq y Pricing.PlanName ponen en level 3 lo que se repite, y el h2 lo lleva el Header. Nace FeatureSplit.Header, calcado de Testimonials.Header (Box con medida + Motion + Stack) y sin contexto, porque este block no tiene eje align que heredar. Y .Title baja su default de 2 a 3. La forma queda coherente en los dos casos, que es lo que la hace preferible a las alternativas: con .Header el h2 es suyo y las filas cuelgan; sin .Header la app ya puso el h2 encima y las filas cuelgan igual. La tercera vía —un contexto donde el Header marcase su presencia y el Title derivara su nivel— daba el mismo resultado a cambio de un hijo escribiendo en el contexto del padre, que es el patrón que ya costó un bucle de $effect en este repo. Por un solo bit, no compensa. Verificado en navegador, outline leído del DOM: /blocks/feature-split/preview h2 «Del evento crudo a la decisión» h3 ×3 (las filas) ← antes: h2 ×3, sin nombre /blocks/landing h2 + h3 ×2, dentro de un outline de página que ya no salta de nivel La demo compone su encabezado y LandingSite deja de hacerlo a mano: fuera el Stack escrito a pelo y fuera los dos level={3}. Header medido en su sitio (x 144, 768 de ancho: la misma medida que la copia de las filas). Gates: svelte-check 72/62 antes y después · vitest src/uix/blocks 36/36 · blocks:check verde (19 blocks, 147 ficheros) · docs:check 0/0. Primera fila del ledger arreglada DENTRO del tier, por acotación del eje: las tres anteriores de la sesión (A-111, A-112, A-109) eran todas de canon. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
dev	1e3a67ad39	uix(banner): la tira de aviso no es la cabecera del sitio, así que deja de reclamar su landmark ... Toda página con cabecera exponía DOS landmarks banner: el <header> del site-header y la tira de aviso, que estampaba role="banner" a mano. ARIA reserva ese rol para la cabecera DEL SITIO —identidad, búsqueda del sitio— y dice que un documento debería marcar como mucho uno (A-109). Las dos salidas que la ficha proponía estaban mal planteadas, y lo destapó una revisión adversarial de tres refutadores independientes: - «Estampar el rol ANTES de los rest props, que es la clase naming donde gana el consumidor» contradice la doctrina que la propia ficha citaba: role es clase CONTRATO por nombre de atributo (morfo/types.ts:811-832; ARIA_NAMING_ATTRS contiene sólo aria-label). El runtime siempre gana ahí, y con razón: un data-state o un role pisables son un componente que miente. - Y el orden de estampado NUNCA fue el mecanismo. Medido: el segundo landmark es el <header> del site-header, que no lleva atributo role ninguno — recibe banner IMPLÍCITO por ser una <header> fuera de un elemento de sección. Un rol pisable habría dejado quitarlo caso por caso, empujando el arreglo a cada app, en vez de arreglarlo por defecto. - El morfo, además, nunca declaró el rol (aria: []): era un literal del wrapper de eidos que el README daba por contrato de la parte. Drift morfo↔eidos que se queda sin objeto. Lo firmado: la tira deja de reclamar el landmark. defaultElement header→section en el morfo, fuera el role literal. Un <section> es region SÓLO cuando tiene nombre, así que el aria-label del consumidor la hace encontrable y su ausencia la deja como contenido plano — que es exactamente lo que el censo de landmarks de A-111 ya sancionaba por escrito. ⚠️ SIN nombre por defecto, y esta es la corrección que la revisión me obligó a hacer sobre mi propia propuesta: yo había planteado un default traducido («Aviso»), copiando el patrón de skeleton/spinner. Habría convertido TODA tira en landmark sin salida — /temas/grafito apila cuatro y habrían salido cuatro region con el mismo nombre, que es la clase de defecto de A-111 con otro traje. El precedente de <nav> no transfiere: un <nav> es SIEMPRE landmark y por eso pide nombre; un <section> lo es PORQUE lo tiene. Quien quiera una tira encontrable, la nombra. Derogadas por escrito las dos afirmaciones que decían lo contrario, porque existían y estaban firmadas: el README del canon («Banner is a landmark for page-level announcements — site header, persistent notice, system status bar») y el «✓ ejemplar» que docs/audit/components/banner.md le puso a ese contrato el 2026-07-07. La otra mitad de aquella decisión —no role="alert", el feedback transitorio es de Toast— sigue en pie y se dice. Verificado con el árbol AX de Chrome por CDP, servidor limpio: /blocks/landing banner ['Aviso del producto','Acme'] → banner ['Acme'] + region ['Aviso del producto'] /blocks/banner/preview banner ['Principal'] · region ['Aviso del producto'] /temas/grafito banner [] · region [] — las cuatro tiras sin nombre dejan de ser landmarks, que es lo correcto Píxel idéntico: la receta selecciona [data-banner], no el elemento — tira a sangre 1280×54 con el mismo fondo, capturada y mirada. Ningún test, guard, CSS ni consulta del repo seleccionaba por role=banner ni por el tag. Gates: svelte-check 72/62 antes y después · vitest eidos+blocks+morfo 692/693 (el rojo es skin-media-player, ajeno y documentado) · blocks:check 0/19 · docs:check 0/0 (644) · morfo:check PASS en banner. Prosa re-sincronizada en 11 sitios: los README de canon, block y app-shell, la ficha de auditoría, las tres demos, landing y su README. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
dev	ae9e277fad	uix(navigation-menu): el botón «aparecía» en vez del panel, y la forma del trigger no la podía tocar ningún tema ... Dos defectos que el autor señaló en el megamenú, y los dos anteriores a T-1. 1 · EL TRANSLATE. `emerge-open` / `emerge-close` se estampaban en el TRIGGER, así que la firma genérica `[data-event^='emerge-open'] { animation: present-rise }` corría sobre el BOTÓN: opacidad 0→1 y 8px de translate en el control, mientras el panel —la superficie que entra en el campo— no hacía nada. Medido: a +8 ms el trigger con `present-rise` y `translateY(5.5px)`, a +120 todavía vivo. La premisa del target era real («el content se monta al abrir, un sello dirigido a él muere») y la receta A-36 ya la respondía, por eso dropdown-menu, popover, context-menu y dialog declaran `content` y ninguno declara `trigger`: `open` es `post` —el flip monta el panel y el runtime difiere el emit pasado `tick()`— y `close` es `pre` —el panel sigue ahí para anunciarlo—, con `targetFallback: [trigger]` para la carrera en que ya no está. Resolución por estado de montaje, DECLARADA, no un fallback a mano en el provider. navigation-menu era el último que la arrastraba. Ahora el trigger queda sin evento, sin animación y sin transform en todos los instantes; el panel se lleva la aparición. La suite lo fija en las dos ramas (content montado · fallback). Al mover el sello salió un doble que habría enviado: el panel tiene entrada propia (slide+scale+fade, 120 ms) y la firma se la pisaba durante el hold; al retirarse el sello, la de la receta arrancaba DE CERO. El panel entraba dos veces, 320 + 120 ms. Precedente exacto en tooltip («the preset entrance wins over the global present-rise signature», medido allí el 13-08): la entrada propia gana por especificidad. Registro de animaciones tras el arreglo: una sola entrada de 116 ms, nada en el botón. 2 · LA FORMA. El radio del trigger vivía en un PRIVADO (`--_navigation-menu- radius`) clavado a `--radius-default` —«decoupled from size (Radix model)», una línea que leyó a Radix como regla cuando Radix no pinta nada—, la altura salía de `padding-block: var(--space-2)` (un token de ESPACIO como altura de CONTROL: medido 33,5 / 36 / 41 px en sm/md/lg, sólo `md` en la escala por aritmética casual) y los rellenos de hover/abierto estaban escritos a mano. El contrato del componente publicaba tres knobs (content-z, indicator-w/x): ningún tema podía decir «píldora» sin mover el radio del sistema entero. Por el TSC y por lo que hacen Button (`--button-radius-*`), dropdown-menu (`item-*`) y el Sidebar de ayer (`--sidebar-row-*` por talla), eso es un error, y el autor lo firmó así: themable, default el actual. Ahora el trigger (y el Link, que comparte su cromo) toma el bundle canónico `--size-{k}-*` a través de tokens públicos por talla —`--navigation-menu- trigger-{height,font-size,line-height,padding-inline,radius}` con sus pasos `-{sm,md,lg}` y el nombre resuelto por `data-size`— más `-bg-active` / `-fg-active` para el acento de abierto / aria-current. A `md` el default es exactamente lo que traía: 36 px, 6 px de radio. Medido antes → después: altura 33,5/36/41 → 30/36/44; radio 6/6/6 → 6/6/10. Y un tema decide la forma en una línea: `--navigation-menu-trigger-radius: var(--radius-full)` en el root → 9999px en el trigger, medido. Y el hover: la receta pintaba `background: var(--color-surface-overlay)` con el SHORTHAND, que resetea `background-image` —donde vive la capa de estado canónica que `archetypes.css` ya da a todo `trigger` (R-4.3)—. Medido: `background-image: none` en hover, la capa muerta y una superficie a mano en su lugar; y el trigger ABIERTO sin ninguna respuesta al puntero (el mismo bug que la fila activa del Sidebar, ayer). La regla de hover desaparece (la capa ya está) y el acento usa `background-color`, así que compone encima: medido, hover cerrado = sólo la capa; hover abierto = acento + capa. Fuera del alcance y sin tocar: los enlaces DENTRO del panel (`[data-navigation-menu-content] :is(a, …)`) conservan su `background` shorthand — otra superficie, otro selector, otro día. Gates: check 72 con CERO en los ficheros tocados · soma nav 9/9 · sema+morfo 550/550 · eidos 434/435 (el rojo es `skin-media-player`, ajeno, el mismo que documenta el handoff del sidebar) · eidos-lint 31 morfo-backed / 0 invalid · component:audit PASS · rtl:check 0 · docs:check 0/640 · generated/base.css +41 líneas, sólo las del nav. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
dev	aa3f0e3511	uix(navigation-menu): navegar no fija nada, y el megamenú que se abre solo no debería sonar ... T-1 de PLAN-sidebar.md §6. El `Link` emitía `commit-select + affirm` al navegar. El libro lo nombra: TABLA 9.3, «Success de navegación — cambio de contexto con logro», corregido como «shift + commit.fulfill si procede»; cap. 27 §2 «shift no es commit… ir a otra pantalla no implica que la operación haya terminado»; y la apertura de cap. 10, «una navegación no es exitosa por cambiar de pantalla». Nada queda fijado al pulsar un enlace del nav: `aria-current="page"` es la huella que deja el router DESPUÉS, no un estado que la parte fije. Ahora habla el par de cap. 22 §9 —«Link → contact.press seguido de shift.navigate: la presión no es la navegación»—, el mismo que la fila del Sidebar declaró ayer: - `contact-activate` ANCLADO en el enlace pulsado (parte repetida → `partInstance`). - `shift-navigate` en el `provider`, sin anclar: `data-event-*` es UNA ranura por elemento, y el sujeto del cruce es el `<nav>` que cruza como unidad, no el control que lo inicia. Sólo si el `<a>` tiene `href` — aquí no es un opt, viaja en restProps, así que se lee del elemento que la parte ya tenía atado. Esto REABRE la decisión del 2026-08-05 (ledger A-54), no la pisa: mover el evento fuera del marco estaba bien; la familia era el defecto. El pack estuvo a punto de borrarse, y esa habría sido la equivocación de la sesión. Al quitarle la regla del commit se quedaba con dos selectores vacíos y propuse retirarlo como ruido. El autor paró y pidió releer: la pregunta no era qué escribe el fichero, sino qué debe decir la aparición del megamenú. Se abre por HOVER, y medido con el default de familia un barrido del puntero por dos triggers y salir de la barra emitía `open` · `open` · `close` — tres sonidos, 6 osciladores, sin un solo clic. Cap. 17 §3 («emerge — normalmente no necesita sonido»), cap. 26 §7, cap. 32 §10-§11, cap. 5 §11. Así que `emerge-open` y `emerge-close` son SILENT, la postura que `tooltip` y el flyout del `sidebar` (D-SB.3) ya tienen para el mismo gesto. El pack DIFIERE del default y vuelve a ser un pack. Enmienda D.6 de book-deviations.md (PROJECT_CANON): `navigation-menu` sale del alcance del `commit.subtle`, y quedan corregidas tres cláusulas suyas caducadas — el `emerge-open/close` declarado desde el 2026-08-05, el `commit.subtle` que murió en 86fa9a1b7 sin sustituto, y el `emerge.soft` (0.08) que el catálogo absorbió (la base `open` es 0.09). `menubar` tiene la misma clase de defecto en su trigger y NO se toca: otro componente, otra sesión. Medido en Chromium headless (la pantalla oculta congela rAF; sonda desde la raíz): - clic en enlace → `contact-activate` (familia contact, sin intent) sobre el `[data-navigation-menu-link]` con `press-squeeze` corriendo EN el enlace a +8 y +30 ms y retirado a +120 · `shift-navigate` sobre `[data-navigation-menu]` · 4 osciladores · cero estampados de familia `commit`. - Enter sobre el enlace enfocado: idéntico (`handleListKeydown` no intercepta Enter; el ancla nativa dispara el click). Sin `href`: sólo contacto, 2 osc. - RTL: mismo par, sin `data-event-direction` — un `href` no tiene sentido propio. - El SILENT demostrado por diferencial con la MISMA maquinaria: el barrido sigue estampando `emerge-open`/`emerge-close` y baja de 6 osciladores a 0. - Enlace pulsado con el panel abierto: cuatro ocurrencias en tres nodos distintos (open@trigger · contact@link · shift@nav · close@trigger), 4 osciladores — las dos silenciosas no compiten con el par del enlace. La demo clavaba las cuatro previsualizaciones en el `<li>`: con eventos en tres partes, el ▶ del contacto habría encogido el item entero. Ahora resuelve la parte del contrato compilado (mismo arreglo que la revisión adversarial del sidebar). Medido: contacto→link, shift→nav, emerge→trigger. El README de soma describía el estado ANTERIOR al 2026-08-05 (target `item`, emisión en `openNow`, cascada por `closest()`): reescrito entero. Gates: check 72 errores con CERO en los ficheros tocados (el de nav-menu que queda vive en eidos/navigation-menu-content.svelte, `sideOffset`, intacto) · suite nav 8/8, cuatro contratos nuevos · sema 327/327 · morfo:check exit 0 · morfo:vocabulary 0 (el WARN es de cropper) · component:audit --only navigation-menu PASS · eidos-lint 32 morfo-backed / 0 invalid · docs:check 0/640 · rtl:check 0 · blocks:check 0/19. Queda ABIERTO y no es de este eje: `emerge-open` estampa en el TRIGGER y le corre `present-rise` encima —el botón «aparece» como si fuera él la superficie—, y la receta pinta abierto/seleccionado con `background` plano sobre un radio fijo. Los dos son anteriores a este commit y piden su propio eje (la doctrina ya tiene la forma: `targetFallback`, resolución por estado de montaje). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
dev	aced677a15	uix(toolbar): la acción principal de un cluster ya puede decir su rango — y el gesto ya suena ... `Toolbar.Button` tipaba contra el ButtonProps de SOMA ({id, disabled}): sin variant, sin color, sin size. Un cluster de acciones donde UNA es la principal no tenía cómo decirlo desde dentro, y la demo del app-shell dejaba «Nueva» FUERA del toolbar como workaround documentado (A-112). La ficha ofrecía dos salidas y mi primera recomendación fue la equivocada — declarar el toolbar deliberadamente uniforme y consagrar el workaround. El autor la tumbó, con razón: el eidos toolbar-button.svelte era un PASSTHROUGH que dejaba el <button> nativo de soma, exactamente la clase de bug que dialog-trigger (2026-06-19) y card-group-title (2026-06-27) ya pagaron, y el precedente correcto no es menubar-trigger sino Form.Submit. Dos datos que el primer análisis no tenía: - El botón era MUDO. El morfo del toolbar sólo declara commit-toggle (el group-item), así que pulsar una acción no emitía nada. Medido tras el cambio: click → contact-activate estampado en el nodo + 8 nodos de audio, donde antes 0. - La uniformidad la dan los DEFAULTS, no la ausencia del eje: ghost/neutral y el size del toolbar por contexto de eidos (toolbar/context.ts, calcado del precedente ButtonGroup y con su misma razón: la receta del Button lee data-size EN el nodo, un descendant selector no llega). El tipo estrecha a SelectionVariant (solid | outline | ghost). La forma es el Button consumer pattern entero: composición vía child de soma (con el rename outerChild contra la recursión), y la receta CEDE el nodo — cero cromo de botón en toolbar.css (regla 5); Link y GroupItem siguen siendo superficie de la barra y los pinta ella. Antes de ceder, las dos recetas sobre un mismo nodo producían un híbrido medido en el que solid/primary NO pintaba. La doctrina que faltaba queda escrita en guides/component-guide.md §4: dos clases de parte con forma de botón en una barra. ACCIÓN en barra (Toolbar. Button, Form.Submit, Dialog.Trigger) compone el Button; control de SUPERFICIE de barra (Menubar.Trigger: File, Edit) lo pinta la barra. El test: ¿significa lo mismo fuera de la barra? Esa distinción vivía en un comentario de menubar-trigger; el comentario ahora apunta a la doctrina. Verificado en navegador (Playwright, servidor limpio): el nodo ES el Button del canon (data-button + data-variant), solid/primary pinta (fondo primary, tinta blanca), paridad exacta con el GroupItem por construcción — mismo bundle --size-*: 36px/36px en md, 30px/30px en sm, con la herencia del size del toolbar medida en vivo al cambiarlo. La demo del app-shell mueve «Nueva» AL INTERIOR del cluster (workaround retirado, gap del block cerrado en su README) y la demo del toolbar gana la acción «New» con controles vivos action variant / action color. Gates: svelte-check 72/62 (base 73/62, sin regresión) · vitest eidos+blocks 470/471 (el rojo es skin-media-player, ajeno y documentado en el handoff) · blocks:check 0 errores / 19 blocks · docs:check 0/0. Los avisos de prettier de los dos README ya fallaban en HEAD. ⚠️ El árbol compartido tiene ya encima trabajo NUEVO de otra sesión (navigation-menu, PLAN-sidebar, book-deviations): este commit lleva sólo los 14 ficheros del eje A-112, verificados por lista. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2 months ago
dev	bae03e55c5	uix(sidebar): cuatro cosas que sólo se ven cuando alguien intenta refutarte ... Revisión adversarial del eje (seis lentes, un escéptico por hallazgo): 21 hallazgos, 17 refutados, 4 reales. Los cuatro, arreglados. 1. El `MenuBadge` no llegaba nunca a `lg`. Indexaba la tabla de su excepción por `part`, que ya venía capado en `md`, así que la rama `lg→md` era código muerto y un sidebar `lg` sacaba el chip un paso pequeño. Ahora indexa por la talla del sidebar: 26 · 26 · 30 · 36. 2. `emerge-close-sub` se sellaba en un nodo que el mismo tick ocultaba. El `display:none` de `[data-state='closed']` mataba `dismiss-fade` antes de pintar un frame y, como el pack silencia ese evento a propósito, la retirada del flyout se quedaba sin NINGÚN canal: una ocurrencia declarada que no ocurre. La regla se guarda ahora con `:not([data-event^='emerge-close'])`, que es justo la ventana que el canal visual mantiene abierta. Medido: opacidad 0,85 → 0,35 → 0,03 con la animación viva, y el nodo oculto a los ~516 ms, cuando el sello se retira. ⚠️ Mi primera sonda dijo que `dismiss-fade` corría, y era mentira: leía `animationName` DENTRO del callback del MutationObserver, o sea antes del flush que ocultaba el elemento. El instrumento midió el instante equivocado. 3. La pestaña sema de la demo clavaba las SEIS previsualizaciones en el panel. Con cuatro eventos apuntando a otras partes, el ▶ de `contact-activate` estampaba la familia en el panel de 16rem y `press-squeeze` encogía el panel ENTERO —lo contrario de lo que el propio párrafo de al lado explica—, y los dos `emerge-*-sub` no podían encontrarse con la regla que los silencia, atada a `[data-sidebar-menu-sub]`. `SemaPanel` recibe ahora la acción (parámetro opcional: las otras 23 páginas siguen con su thunk sin argumentos) y la página resuelve la parte desde el contrato compilado. Medido: contacto → una fila, open-sub → el sub, shift → el provider. 4. La fila de Gaps del README de `app-shell` seguía afirmando que «sus morfos sólo declaran emerge-expand/collapse», que es exactamente lo que este eje dejó de ser cierto. Reescrita: queda viva sólo la mitad que lo sigue siendo —`NavigationMenu` emitiendo `commit-select` al navegar, el antipatrón «success de navegación» del cap. 10 §12—, y se registra por qué se refutó la lectura «la fila SELECCIONA la sección». Gates: eidos-lint 49/0 invalid · component:audit PASS · rtl:check 0 · docs:check 0/639 · vitest eidos 434/435 (el rojo es ajeno) · suite del sidebar 8/8 · `check` con delta CERO contra la base medida con stash (72/72). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2 months ago
dev	63b2de03c7	uix(sidebar): un token de ESPACIO no es la altura de un control, y el raíl de iconos no es una constante ... El componente vivía fuera del canon de talla: la fila clavaba `min-block-size: var(--space-8)` —un token de la escala de ESPACIO haciendo de altura de CONTROL, que es otra escala de densidad— y `font-size: var(--font-size-sm)` escrito en el recipe, donde el guard del bundle no lo ve. El rótulo clavaba `xs`, el trigger `sm`, el badge `xs`, y la acción no componía `Button`: se quedaba con los 13,33px del user-agent y sin acuse perceptivo propio. Ahora el sidebar tiene eje `size` (xs..lg, default `md`, `data-size` en el WRAPPER —nunca en el morfo, o la resolución de soma lo pisaría con undefined—) y cada coordenada de la fila sale del bundle `--size-{k}-*`. Medido: 26/12 · 30/14 · 36/16 · 44/20, con el glifo siguiendo (14/16/18/20) por `--icon-size`, que es la costura que ya usa `Button` porque un `<Icon>` pinta su tamaño INLINE y gana a cualquier regla de hoja. El raíl de iconos deja de ser `3rem`: se DERIVA (fila + 2×padding), así que da 42 · 46 · 52 · 60 y a `md` ya no recorta la fila que tiene que contener. Tres composiciones más, por la regla que ya existía (container→part capada en `md`, precedente `Dialog.Close`): el `Trigger` deriva su talla, la `MenuAction` pasa a ser `IconButton ghost` —y con ella llegan su cromo, su anillo, su capa de estado y su `contact-activate`—, y el `MenuBadge` deriva con UNA excepción firmada: baja un paso, porque con la regla al pie el chip sale a 36/16 junto a una fila de 36/16 e iguala al control en vez de anotarlo. El hover deja de ser un `--color-surface-raised` a mano y pasa a la capa canónica `--state-hover`. Al medirlo salió un defecto que no buscaba: la fila activa no daba NINGUNA respuesta al hover, porque su acento usaba el shorthand `background`, que resetea el longhand `background-image` donde vive la capa. Con `background-color` la capa compone encima, que es justo para lo que existe. Verificado con Playwright headless (la pantalla del navegador estaba oculta y ahí rAF se congela: las medidas de layout salían falsas). Gates: eidos-lint 49 morfo-backed / 0 invalid · component:audit PASS 0E/0W · vitest src/uix/eidos 434/435 (el rojo es `skin-media-player`, ajeno, idéntico en base) · rtl:check 0 · docs:check 0/639 · `check` con delta CERO contra la base medida con stash (72/72). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2 months ago
dev	edf0639eea	blocks(app-shell): la barra y el raíl no son la misma navegación en dos tamaños, son dos ÁMBITOS ... Corrección del autor, y era una equivocación de fondo, no de forma. Yo había escrito que un menú en la barra sería «una segunda navegación dentro de un shell cuya navegación es el raíl». Es al revés: - la BARRA lleva la APLICACIÓN — su menú general, las áreas que tiene, y lo que es de la persona y no de la página (buscar, avisos, la cuenta). No cambia cuando el lector se mueve dentro de un contexto; - el RAÍL lleva el CONTEXTO en el que está — este proyecto, esta tabla: sus secciones y sus acciones. Cambias de contexto y el raíl entero cambia; la barra no se mueve. Es el `TopNav` + `SideNav` de Atlassian y el `TopBar` + `Navigation` de Polaris, que estaban en mi propio dossier. Y es también por qué una app publica DOS landmarks `navigation` legítimamente: la APG pide nombre único en los repetidos, y cada uno nombra un ámbito distinto. La demo modelaba mal: el raíl era el menú general. Ahora la barra lleva marca + `NavigationMenu` de la aplicación (Bandeja · Proyectos · Informes) y el raíl es el proyecto Apollo (Tablero · Conversaciones · Archivos + sus Acciones). El rastro se va con ella: su sitio es la cabecera de la PÁGINA, no la barra — cambia con cada vista mientras la barra no, y una barra que lo lleva crece una segunda fila en cuanto la ruta tiene tres niveles, que es lo que se midió antes de moverlo. De `site-header` se queda sólo la razón que era cierta: no es que sobre una navegación, es que la pieza es de un SITIO — `Sticky` por defecto (una barra de app bajo `scroll="main"` no debe pegarse) y `Container` MEDIDA (una barra de app va de borde a borde). Su forma marca · nav · acciones es la correcta. **Y un defecto de canon que sólo aparece con dos navegaciones**: `NavigationMenu` deja su landmark ANÓNIMO — el `aria-label` se reenvía al `<ul>` y el `<nav>` se queda sin nombre (el morfo lo declara así: «the root delegates its name to the list it wraps»). Un `<ul>` no es un landmark. Medido: `navigation: ['Navegación principal', null, 'Migas de pan']`. No se arregla desde fuera —nombrar la lista no nombra la región, y envolver en otro `<nav>` anidaría landmarks—, así que queda VISIBLE y registrado en los Gaps. Guards: `blocks:check` verde · `docs:check` 0/0 · `svelte-check` sin errores propios (de paso, `NavigationMenu.Item` exige `value` y no se lo pasaba). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
dev	db7bcc3a55	blocks(hero): la mitad de escritorio no se oculta en el móvil, no existe — y el clip no se pide ... F4 del eje de visibilidad por breakpoint: el primer caso real, y la receta escrita donde un agente la va a buscar — el README del block que la usa. Medido sobre build de PRODUCCIÓN (`build` + `vite preview`, Chrome), que es el único sitio donde la afirmación es comprobable: a 375, cero `<video>` en el DOM y NINGUNA petición de `video.mp4`; a 1280, uno y una (`206 Partial Content`). En dev es falsa por construcción — el servidor renderiza a ancho 0 y sirve la variante `base` antes de que la hidratación la pode. Dos criterios que la receta fija para el tier. La puerta va DENTRO del snippet, nunca alrededor del `<Hero>`: envolver el block duplicaría título, copy, formulario y acciones por breakpoint, que es lo que hacen las secciones por-breakpoint de Framer y la razón de que deriven; la media es lo único que difiere, así que es lo único escrito dos veces. Y `display="contents"`: una puerta decide presencia, no añade geometría. La mitad móvil no es un vídeo más ligero: es NINGÚN vídeo. El Surface con aurora cuesta cero bytes y sigue la paleta del tema. ⚠️ Hallazgo del canon, medido de paso y NO arreglado aquí: la media dentro de un `Background.Layer` desborda la capa — el mínimo automático del ítem de rejilla gana a `block-size: 100%`. Hero a 1280: capa 567px, vídeo 714px. En la demo del propio canon con `Background.Video`: capa 288px, vídeo 435px. `min-block-size: 0` lo colapsa exacto en ambos. `overflow: clip` lo escondía, así que `cover` lleva recortando descentrado sin que se viera. Es del eje `background`, cerrado el 2026-08-18: queda escrito en §Found while composing. `launch.json` gana `preview-prod`: la entrada llamada `preview` arranca `npm run dev`, así que no servía el build y la medida no se podía hacer. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
dev	1d91c11e89	blocks(app-shell): la demo no usaba los componentes que SIGNIFICAN lo que enseñaba ... Rehecha entera. Cada pieza es ahora el componente del canon que corresponde al acto, no una caja con el aspecto adecuado: - las tres cifras son `Metrics` (label · value · delta), con la dirección desacoplada de la valencia: en «sin asignar», BAJAR es bueno (`goodTrend`), que es justo lo que las referencias hacen mal; - la bandeja y la actividad son `Feed` — `role="feed"`, cada conversación un `role="article"` con `aria-posinset/setsize` y su título con `aria-level`, teclado de feed incluido. Medido: 2 feeds, 11 artículos, 11 encabezados; - la barra superior es `Toolbar` (`role="toolbar"`, roving tabindex: cinco controles cuestan UNA parada de tabulación) más `Breadcrumb` con `current`; - la tipografía sale de los estilos SEMÁNTICOS del tema — `Text style="label|caption|body"`, `Heading level` + `style` — en vez de tamaños elegidos a ojo, que es lo que había. **Y la avería que esto destapó, que era del arnés y afectaba a los 19 previews**: la foundation declara los `@font-face` y emite los estilos (`--style-body-*`…) pero no los aplica a ningún elemento — un `Text` ancla su familia en su recipe y todo lo demás HEREDA del documento. El arnés de blocks no anclaba nada, así que `html`, `body`, `[data-sidebar]` y cada fila del raíl computaban **Times New Roman** al lado de los `Text` en Instrument Sans. El shell de docs sí lo ancla (`uix.css`); éste no. Anclado en `_lib/reset.css` con los tokens del tema, no con una familia escrita. De paso, el sangrado de 40px que el navegador pone a `dd`. Tres huecos del canon que salieron al componer, registrados en los Gaps: 1. **`Sidebar.MenuButton` es mudo y `NavigationMenu.Link` no** — el mismo acto con dos respuestas. El README del `Sidebar` firma que «navegar una fila es nativo y no suena», pero entonces el `NavigationMenu` contradice la firma; y en un shell la fila casi nunca navega: SELECCIONA la sección. Es de sema, no del tier. 2. **`Toolbar.Button` no acepta `variant`/`color`** — tipa contra el `ButtonProps` de soma (`{id, disabled}`), así que un cluster no puede decir cuál es su acción principal. Aquí va al lado, como en las referencias. 3. **No existe `description-list`** y el panel de detalle es exactamente el «primer detail-view real» que su ficha F5 pone como disparador. Guards: `blocks:check` verde · `docs:check` 0/0 · `svelte-check` sin errores propios (dos props inexistentes corregidas de paso: `Icon.Filter` y el `variant` del `Toolbar.Button`). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
dev	026e07beaa	blocks(app-shell): la demo estaba escrita a mano, no con la capa visual ... La escribí sin haber leído la doctrina de eidos y salió lo que sale así: `<div style>` donde hay primitivos, `inline-size: 16rem` clavado, `font-size` en un `<strong>`, bordes y fondos a pelo, y contenido de relleno («Bloque de contenido 1»). Rehecha contra la tabla «Build contract» de `guides/component-guide.md`. Ahora **cero literales y cero `style=`** en el fichero: color por token de rol, espaciado por `--space-*` a través de los props de layout, tipografía por la escala de `Text`/`Heading`, paneles por `Card`, separaciones por `Separator`, anchura del aside por `--sidebar-width` (la medida del propio sistema, que respeta densidad y `--scaling`). Dos props que no hacían NADA, encontradas al reescribir: - `Badge intent="affirm"` — `Badge` no tiene `intent`, tiene `color`. - `AutoGrid minChildWidth="var(--container-width-sm)"` — le pasé un breakpoint como suelo de pista, así que las tres tarjetas caían en una columna. Ahora `Grid columns={{ base: 1, sm: 3 }}`, sin literal ninguno. Y una tercera cosa medida que NO se arregla desde aquí: el aside llevaba `Surface variant="soft"` y es **inerte** — `oklch(0.9911 0 0)` contra un fondo de página de la misma claridad, o sea invisible en claro. Es **F15** de `PLAN-blocks-quality.md` §6, gap de canon ya registrado («soft no acota un panel, y Surface no tiene borde»). La frontera la pone un `Separator`, que es lo que sí acota, y el porqué queda escrito en el fichero para que nadie lo «arregle» con un fondo a mano. Verificado mirando las capturas, claro y oscuro, 1280 y 375. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
dev	fd02780002	uix(box): ocultar por CSS descarga el vídeo igual, y evitarlo pedía no tener SSR ... `visibleFrom` / `hiddenFrom` no ocultan: no renderizan. El subárbol no está en el DOM, sus efectos no corren y su media no se pide — la mitad que `display={{ base: 'none' }}` no puede dar. Los once contenedores que componen Box (Section, Container, Flex, Grid, Stack, Group, Wrap, AutoGrid, Surface, AspectRatio, Float) la heredan sin tocar sus ficheros. La puerta es un `$derived` sobre `eidos.dom.isAtLeast(bp)` y un `{#if}`: sin atributos nuevos, sin generador, sobre los breakpoints que configura el app. Ninguna referencia lo hace así. Mantine (`hiddenFrom`/`visibleFrom`), Chakra y Panda (`hideFrom`/`hideBelow`), Framer y Webflow ocultan por CSS y dejan el DOM montado — Webflow lo documenta como coste de ancho de banda y Framer llega a duplicar secciones enteras por breakpoint. Eligieron CSS porque con SSR una puerta JS pinta la variante equivocada en el HTML (MUI devuelve un `matches` por defecto en el primer montaje; Vuetify #17252 reporta los saltos de layout), y el precio de evitarlo es adivinar el ancho por User-Agent o Client Hints. Aquí ese precio no existe: el proyecto se despliega como SPA (`adapter-static` + `fallback`, ninguna ruta con `prerender = true`), así que el primer render ocurre en el navegador con el `innerWidth` real — el build es un `200.html` de 1,8 KB, shell puro. El que SÍ se paga está escrito en el tipo: cruzar un breakpoint destruye el subárbol y su estado. Cuando el estado deba sobrevivir, `display`. Sólo el dev server renderiza en servidor (ancho 0) y empieza a descargar la media de la variante `base` antes de que la hidratación la pode: queda como caveat de desarrollo en el README. `base` sale del tipo en ambas props: `visibleFrom="base"` sería «siempre» y `hiddenFrom="base"` «nunca renderiza», y ninguna de las dos es una cosa que una prop deba poder decir. Card, Banner, ScrollArea y Sticky rinden su propia raíz y NO heredan la puerta: queda como gap diferido con la regla del `as` (≥2 casos reales). El puente de SSR queda escrito con su disparador, no construido — hoy sería un atributo que nadie lee. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
dev	6a53c3dc99	blocks(app-shell): la pieza que posee las alturas de la página, y por eso el aviso deja de tapar la cabecera ... F3.1 del tier, con su fase 0 firmada delante. El block que faltaba: el que POSEE las regiones de una página de aplicación — sus landmarks, sus enlaces de salto y sus alturas. **A-95 se cierra por construcción, no compensando.** Bajo `scroll="main"` no hay nada fijo: el aviso es una fila, el cromo es una fila y la página es la fila que se desplaza. Medido con la tira puesta: aviso [0,54], cabecera [54,85], **solape 0**, y el hit-test en el centro de la cabecera cae en la cabecera (antes: 49px de solape y el clic en la tira). El eje `scroll` es el que Mantine expone como `mode` y Atlassian como `isFixed` por slot; `body` existe porque `docs-shell` lo necesitará para anclas y TOC. Compone `Sidebar` (sus tres colapsos, su drawer móvil, sus dos landmarks), `SkipLink`, `Sticky`, `Grid`/`Flex`/`Box`. Sin `.css`. Coordina tres booleanos (`navOpen · asideOpen · mobile`) por contexto, sin máquina y sin palabras: nada en un shell puede bloquearse, así que no hay frase que decir. Medido en navegador (Playwright; 1280 y 375, claro y oscuro, LTR y RTL): - landmarks por construcción — 1 banner · 1 main · 2 navigation NOMBRADOS · 2 complementary NOMBRADOS · 1 contentinfo; encabezados 1-2-2-2-2 sin saltos. - `scroll="main"`: documento 720 = viewport, el main scrollea dentro y la cabecera se queda en 0 tras desplazar 900px. `scroll="body"`: el documento scrollea y la cabecera SE PEGA (top 0 a 900px de scroll). - teclado: los tres enlaces de salto son las tres primeras paradas y Enter deja el foco en el `<main>`. - 375: el raíl es drawer, devuelve el foco al trigger con Escape, el aside se pliega y el documento no crece. RTL: sin desbordamiento horizontal, raíl a la derecha, aside a la izquierda. Cuatro averías que sólo aparecieron midiendo, y las cuatro son doctrina ahora: 1. `minHeight` es un SUELO, no un techo: con `100dvh` ahí el documento crecía con el contenido. Es `height`. 2. Un grid que sólo declara filas tiene UNA columna implícita `auto`, que se encoge a su contenido: la página salía en una tira de 32px al lado del raíl. 3. `Box` declara `flex-grow/shrink/basis`, así que pisa el `flex: 1 1 auto` de la receta del inset. Quien está más abajo en el árbol tiene que PEDIR crecer. 4. Un ancestro con `overflow` se lleva el `position: sticky` de dentro. El `overflow: auto` de `Sidebar.Inset` dejaba la barra sin pegar bajo `body` mientras `data-stuck` decía que sí — el atributo dando la razón a una página que no la tenía. Por eso el shell pone su propia caja: gap de canon anotado (el inset debería dejar elegir si es contenedor de scroll). **Y una avería del ARNÉS que este block destapó**: los 19 previews del tier llevaban los 8px de margen por defecto del navegador, así que ningún block se enseñaba a sangre — contra la regla dura del propio tier. Medido: `x: 8, y: 8, w: 1264` en 1280, la página compuesta incluida, cuyo README cita cifras a sangre. Invisible porque todos scrollean; deja de serlo con un shell que llena el viewport. Arreglado en el reset del arnés. De paso, en el canon `skip-link`: el enlace del panel complementario decía «Ir a la barra lateral», que es como todo el mundo llama al raíl de NAVEGACIÓN. En una página que tiene los dos, nombraba al que no era. Ahora «Ir al panel lateral». Guards: `blocks:check` verde con 19 blocks · `docs:check` 0/0 (638) · `svelte-check` 74, ninguno aquí. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
dev	9fd54c80fa	uix(skip-link): el tier decidió en F2.1 que los shells lo poseen, y no había nada que poseer ... Canon nuevo, eidos-native (1 parte, 0 eventos): la pieza de WCAG 2.4.1 que `site-header` difirió a los shells hace tres semanas y que `app-shell` (F3.1) necesita para existir. Nace de su fase 0, decisión Q4 firmada. Lo que decide, y por qué: - **Las palabras son suyas.** «Ir al contenido principal» no es copy: es el nombre de un contrato. La regla del tier (B-7 / D-BLK.5) apunta a esta puerta — si un string parece inevitable, lo posee el componente canónico vía `texts:` + langs. Por eso el prop es `region`, no `label`, y el vocabulario es la lista de landmarks de la APG. Cada clave es una FRASE ENTERA: en castellano el artículo se contrae con la región, así que un «Ir a» + sustantivo saldría mal en media catálogo. - **`region` no se estampa**: elige un texto y ninguna capa lo lee. Declararlo repetiría el error que `Affix` corrigió el 2026-08-15. - **No compone `Link`**: `Link` es tinta en línea y todo su API describe texto dentro de un párrafo. Esto es cromo que aparece de la nada, con su geometría y su suelo; envolverlo sería pisar todos sus props y aun así dejarlos en la API pública. Los componentes del canon renderizan sus nativos; son los blocks los que no pueden. - **El handler mueve el FOCO**, que es lo que el fragmento no hace: un `href` desplaza la vista y deja el foco en el enlace, y el siguiente Tab vuelve al cromo que el lector pidió saltar. El destino se hace enfocable sólo mientras dura el salto. El `href` se queda: es el camino sin JS. - **Peldaño propio de z (950), el más alto de la escalera estática.** No puede compartir el de `affix`: un empate lo rompe el orden del DOM y este enlace es por definición el primer elemento del documento, así que perdería contra cualquier aviso fijado debajo — el fallo medido en A-95. Medido con Playwright (el pane del navegador no tiene el foco del SO, así que `:focus` nunca casa ahí): en reposo 1x1 con clip-path; enfocado `position: fixed`, z 950, píldora de 181x36 sobre `primary-solid` con tinta blanca y anillo de foco, igual en claro y en oscuro; el salto deja el foco en `#demo-main` y el `tabindex` temporal se limpia en el blur; en RTL la píldora espeja al otro borde (x 338 -> 761) sin una segunda regla. Y la demo se corrigió a sí misma: decía «Tab desde el botón de abajo» y la medición enseñó que desde ahí el foco va hacia delante. El botón sube encima del marco, y de paso salió la otra mitad de la lección — por tabulación NUNCA se aterriza en el `main`, porque no tiene nada enfocable. Justo por eso el destino necesita el `tabindex` prestado. Guards: `component:audit --only skip-link` PASS · `morfo:check` PASS · `eidos-lint` 2 selectores morfo-backed, 0 inválidos · `docs:check` 0/0 · `svelte-check` 72, ninguno aquí. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
dev	73f06a7882	uix(background): el velo tenía una escala que no ordenaba, y una tinta que le pone techo ... Cierra el eje salvo dos firmas. La escala `strength` dejaba de crecer a mitad de camino: tomaba prestada `--opacity-*`, que nombra cuán opaco es un ELEMENTO, y leída como pesos de velo salía `ghost` 0,30 · `scrim` 0,45 · `overlay` 0,65 · `muted` 0,65 · `subtle` 0,80 — es decir, un consumidor que pedía `subtle` recibía el velo MÁS pesado del conjunto, y `overlay` y `muted` eran el mismo número con dos nombres. Ahora el velo tiene su propia escala de cinco pasos (`--background-scrim-strength-xs`…`-xl`) y la unión pasa a `xs|sm|md|lg|xl`, ordenada por construcción: medido en Chrome, α 0,084 · 0,126 · 0,189 · 0,273 · 0,420, estrictamente creciente. `md` sostiene el 0,45 que shipeó el hero, así que el default pinta exactamente lo que pintaba. Era cambio de API y se hizo mientras el único consumidor era la demo: ningún block nombra `strength`. Y midiendo eso apareció que la tabla de contraste del README era falsa por la mitad, en la dirección incómoda. Estaba calculada sobre una tinta de α 0,66; `--color-overlay` resuelve a `rgba(28, 25, 23, 0.42)`. Los valores reales, ahora compuestos en un canvas y leídos por píxel en vez de calculados: el default da 1,48:1 sobre foto blanca —no 2,10— y el paso más fuerte 2,14 —no 4,42—. Lo que eso destapa no es un número peor sino un TECHO: `xl` gasta la tinta entera y llega a 2,66:1, de modo que ningún paso nuevo puede alcanzar AA, porque el límite es el alpha del token y no la escala. Con tinta opaca los mismos pesos dan 5,45:1 a 0,65 y 9,22:1 a 0,80. Queda como decisión del autor, reescrita con estas cifras, porque es sobre qué ES un scrim y no sobre subir un valor. La rama `@supports not (animation-timeline: view())` queda ejercitada, que era el último hueco de verificación. Chromium ya no puede desactivar scroll-driven —estable, flag de runtime retirado: seis candidatos probados, los seis siguen reportando soporte—, pero el Firefox de Playwright NO lo soporta por sí mismo, así que la rama está viva ahí sin emulación ninguna. Con el fichero de receta real: `--background-progress` 0 → −64px, 0,5 → 0, 1 → +64px, con `animation-name: none` y cero animaciones. Son los mismos extremos que el camino CSS medido en Chrome, o sea que los dos caminos concuerdan; y en Chromium la rama no aplica y escribir la var no mueve nada, que es la exclusión mutua que el README afirmaba sin haberla medido. Sin ejercitar queda un eslabón —que `ScrollProgress` escriba la var extremo a extremo—: desde el shell de este entorno no hay ruta a localhost, y Firefox no alcanza el dev server. El paseo de la checklist A–H, que estaba listado como lectura de F4 y nunca registrado, encontró tres cosas. Faltaba la excepción `A2.3` con su ID (las tres partes llevan `data: []` porque sus attrs son de wrapper y su único estado vive en el Button que compone) y faltaba `## Subset` (color: el conjunto completo, porque en decoración restringir la paleta sería arbitrario; intent: no se acepta). Y una deriva documental: el README decía en TRES sitios que el control de pausa «IS the canonical Toggle» y que dispara `commit-toggle`, cuando D-BG.18 lo cambió a `IconButton` con etiqueta que cambia y sin `aria-pressed` — el evento es `contact-activate` de `button.ts`. Vestigios de la era D-BG.4 que la enmienda no barrió; corregidos, incluido el comentario del propio morfo. La banda de `feature-split` queda firmada POR SECCIÓN, enmendando el plan en sus tres menciones y `PLAN-blocks-quality` §3 columna B, que la pedía por fila: por fila obliga a cada `Row` a poseer el estado de alternancia —su índice y el de sus hermanas— y un block que coordina deja de ser un block que no posee nada. Gates: audit PASS 0/0 · morfo:check (6 de 160 fallan, background no) · eidos-lint invalid 0 y class-hooks 0 · rtl:check 0/180 · smoke del componente PASS · vitest eidos 434/435 (el rojo es `skin-media-player`, el de siempre) · `check` con los mismos 72 errores preexistentes y ninguno en ficheros propios. Tres fantasmas costaron tiempo y son el mismo patrón: leer las vars tras un screenshot devuelve el `write(0,0)` de un `pointerleave`; dar por muerto el `strength` leyendo `backgroundColor` de un scrim GRADUADO, que pinta por `background-image`; y juzgar `fade` y `pause` sin la precondición que necesitan. El instrumento miente antes que el código, y aquí mintió tres veces. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
dev	d2574e8a7c	uix(background): la línea de tiempo la capturaba un overflow, y el puntero se iba con el scroll ... El travel llevaba dos días escrito y sin medir, porque el panel oculto nunca activa una animación scroll-driven declarada en CSS. Con el Chrome del autor delante se pudo medir, y lo que apareció no fue una confirmación: fueron dos defectos que ninguna sonda había estado en posición de ver. La puerta es `document.visibilityState` — con la pestaña oculta la `ViewTimeline` existe, con `source` y `subject` correctos y `playState: 'running'`, y `currentTime` es `null` para siempre; ahí ni un `await requestAnimationFrame` resuelve. El primero estaba en la demo y el límite es del componente. `[data-uix-stage]` declaraba `overflow: hidden`, y eso es un scroll container aunque no pueda scrollear nunca: `view()` se ancló al stage y el progreso quedó clavado en 52,63% en toda posición de scroll, sin error, sin aviso y con un `translate` de aspecto perfectamente razonable. Con `overflow: clip` —recorta igual, respeta el radio, y no es scroll container— el travel aparece: progreso 43,5% → 95,5%, `translate` `0px -8,34px` → `0px 58,19px`, monótono, y los `4rem` completos de `--background-parallax-travel` en el extremo. Entra en el README como quinto límite porque el caso real no es un harness de demos: es el `overflow-x: hidden` con el que cualquier landing contiene su decoración, que convierte al elemento en scroll container en los DOS ejes. El segundo era del componente. El rect del anfitrión se cacheaba en coordenadas de viewport y sólo lo invalidaban `pointerenter` y un resize; el scroll mueve el anfitrión sin disparar ninguno de los dos. Medido con ratón real: un tick de rueda sobre un anfitrión de 288px dejaba `--background-pointer-y` 0,77 fuera de sitio —los 111px de scroll sobre media altura, a la centésima—, o sea fuera del rango −1…1 que la variable promete, con el spotlight despegado del cursor unos 115px y sin recuperarse hasta salir y volver a entrar. Cacheada la caja en coordenadas de DOCUMENTO y normalizando contra `pageX`/`pageY`, que en un evento real ya traen el scroll incorporado: error 0 en los dos movimientos, halo a 1px del píxel pedido, sin lectura de layout en el camino caliente y sin el listener de scroll que este componente existe para no tener. Queda dicho el residuo: un scroller anidado vuelve a desviar, porque `pageY` no lo ve, y se autocura al reentrar. Y lo que era el encargo, medido: 60 fps con mediana de 16,7ms, p95 17,0, máximo 17,1 y 0 de 200 frames por encima de 20ms con el travel vivo —la base con `speed: 0` salió peor, que es ruido de entorno—; y 0ms de reflow forzado en esos mismos 200 frames moviendo los DOS ejes, con el observador de Long Animation Frames que usa `arts/perf`. El cero está validado por mutación: un thrash deliberado de 65ms en la misma página se reporta con 43ms forzados y el script atribuido, porque un instrumento que no ve nada y un cero real se leen igual. Sigue pendiente la rama `@supports not`, que sólo se ejercita en Firefox. Las 174 demos comparten ese stage, así que el cambio se auditó: `affix` idéntico y `sticky` idéntico —cuatro pasadas alternando `clip` y `hidden`, porque la primera miente—, y `anchor-nav` cambia a mejor: su rail `position: sticky` es hermano del scroller interno, con `hidden` no se pegaba nunca y se escapaba por arriba perdiendo media lista, y ahora se mantiene a la vista. Ninguna demo tocada. Dos avisos para quien vuelva. Un `PointerEvent` construido reporta `pageY === clientY`, sin sumar el scroll, así que los eventos sintéticos sirven para DESCUBRIR este defecto pero no para verificarlo: con ellos el arreglo bueno mide −1,389 donde el ratón real da −0,008. Y leer las variables después de un screenshot puede devolver el `write(0, 0)` de un `pointerleave` en vez de la medición; el valor que vale es el del último `pointermove`, trazado. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
dev	c786d0f804	blocks(landing): las piezas se prueban juntas, y ahí sale lo que ninguna enseñaba sola ... Cierra el tramo D y con él F2b entera. Una landing verosímil con 14 de los 18 blocks, a sangre y sin marco de demo, porque el claim del tier —que sus blocks ensamblan sin fricción— es indemostrable block a block: el outline de encabezados sólo existe cruzando secciones, dos landmarks sólo chocan cuando hay dos, y una costura vertical sólo aparece cuando algo se pone debajo. Lo que dice la medida: un h1 y 22 encabezados sin un solo salto de nivel; ningún landmark repetido sin nombre; 0px de hueco entre secciones vecinas —el aire es siempre el padding de cada Section, costuras de 112 a 192px—; cuatro de las cinco cascadas esperando a que su sección entre en viewport; un solo commit-submit en el formulario; setenta tabulaciones sin una trampa de foco y un drawer que a 375px devuelve el foco a su disparador. A-95 vuelve confirmado, ahora con cifras: con affix="top" la tira y la cabecera solapan 49px —la altura entera de la cabecera— y el hit-test en su centro cae en la tira, así que la navegación es inalcanzable. La pieza que falta sigue siendo app-shell. La página compone la tira en flujo, que es lo correcto, y deja el escenario del defecto detrás de ?banner=affix para poder medirlo en vez de citarlo. Un defecto arreglado, y era de los que importan: Newsletter.Reason medía 2,33:1 sobre el panel mientras la nota a su lado medía 8,5:1. Es la frase que explica por qué la acción está bloqueada —la que la doctrina de coordinación obliga a tener— y no se podía leer: la doctrina cumplida en la estructura y derrotada en la percepción. El block ya tenía el mecanismo y ya lo había escrito para su nota («más callado por TAMAÑO, no por tinta»); su razón no lo seguía. Ahora 8,83:1 sobre el panel, y muted fuera de él. Dos gaps nuevos, ninguno tocado aquí: los DOS landmarks banner —el canon estampa role="banner" DESPUÉS de sus rest props, así que nombrar ambos es todo lo que puede hacer la app, y esta página lo hace— y feature-split sin parte .Header, el único block de sección que no la tiene: sin ella emite tres h2 hermanos y la sección se queda sin nombre. El catálogo aprendió a publicar páginas: kind: 'page' en BlockEntry y el guard lo salta en las dos direcciones, con self-test propio probado por mutación. Y una lección de instrumento que costó un susto: una captura fullPage no hace scroll, así que toda cascada bajo el pliegue se queda en opacidad 0 y la imagen sale EN BLANCO. La primera medida dijo «la landing está vacía». Saltar de una vez al final del documento tampoco vale: las secciones pasan de debajo a encima en un frame y el observador nunca las ve entrar. Se recorre en pasos. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2 months ago
dev	740274a847	uix(background): el fondo se mueve con el scroll, y con lo que el lector no pidió no ... F3 (parallax) + F4 (demo y registro documental) + las correcciones de sus dos auditorías, en un commit porque viven en los mismos ficheros: la demo enseña los ejes que F3 añade, y separarlas dejaría un estado que nunca se probó. Cinco maneras de que una capa deje de estarse quieta: `speed` (cuánto del token de travel cubre mientras el anfitrión cruza el viewport), `bleed` (crece más allá del anfitrión para que el viaje no arrastre su propio borde), `depth` (la deriva contra el puntero), `spotlight` y `attach='fixed'`. El travel es CSS: `animation-timeline: view()` lo gobierna desde la posición de scroll, sin listener ni rAF. Sólo donde el motor no lo trae, la pila arranca `ScrollProgress` y escribe `--background-progress`, que la rama `@supports not` mete en la MISMA declaración; los dos caminos no pueden estar vivos a la vez porque el JS comprueba la condición idéntica con `CSS.supports`, y ambos se paran bajo `prefers-reduced-motion` — el parallax es movimiento atado al scroll del propio lector, que es justo la clase que provoca síntomas vestibulares. **La decisión que no estaba prevista.** El scroll y el puntero quieren mover la MISMA capa, y una animación sobre `translate` gana a cualquier declaración estática: el puntero habría dejado de existir sin más. Así que el scroll anima una custom property REGISTRADA (`@property`, o interpolaría a saltos) y un único `translate` compone los dos términos. Medido: parallax solo → `0px 30px`; con el puntero arriba-derecha y `depth: 20px` → `20px 10px`. Es `translate` y nunca el shorthand `transform`, la misma ley que sigue el lift del draggable con `scale`. El precio, dicho porque en la primera redacción escribí lo contrario tres veces: una custom property NO se puede compositar, así que el navegador recalcula estilo cada frame. Para una decoración es el intercambio correcto —una property por capa que viaja, ninguna bajo reduced motion— pero «va en el compositor» era falso y ahora el código dice lo que ocurre. **Dos footguns cerrados por forma, no por disciplina:** - `attach='fixed'` se DECLARA desde la capa y la pila se recorta sola. Antes había que escribirlo también en la pila, y olvidarlo dejaba la capa `position: fixed` pintando a sangre por todo el viewport, detrás de todo y sin error (un hijo fijo se escapa de `overflow: clip`; sólo un `clip-path` lo trae de vuelta). La prop de la pila desaparece: no hay nada que olvidar. - Un `speed` negativo —una capa que se mueve contra el scroll— invertía el bleed: la capa ENCOGÍA y enseñaba justo los bordes que el bleed tapa. Ahora usa la magnitud. **Lo que costó medición**: el shorthand `animation` pone `duration: 0s` y una línea de tiempo de progreso necesita el `auto` inicial, así que con el shorthand la capa no se movía nunca (van longhands, con el porqué escrito) · mi listener de puntero pedía un frame y no lo liberaba si el rect salía degenerado, matando el puntero para el resto de la sesión (reescrito sin frame, con el rect cacheado e invalidado por `pointerenter` y `observeResize`) · las cuatro registraciones —`animated`, `pointer`, `scroll`, `fixed`— comparten un solo sitio, `declare.svelte.ts`, donde vive la regla A30 y su segunda mitad: registrar desde el init, y seguir el prop sin escribir en la primera pasada. **La demo** (`/uix/components/background`, v2, nueve pestañas) monta un ANFITRIÓN de verdad en el escenario, porque este componente es invisible por sí solo y sin padre no se puede enseñar lo único que importa: que el padre se adopta y el layout no se mueve. Los chips son uniones completas verificadas por el TIPO (`Record<Union, 0>`): un miembro que falte es error de compilación. Y fue la demo la que destapó que, con A30, encender `animate` en caliente no hacía aparecer el control de pausa — el registro era un hecho de montaje. Invisible en una sonda, obvio con un interruptor. Registro documental (D-BG.11): `next-features.md` §11 · la frase en `design-text-effects.md` (el mismo corte canon/pack leído desde el otro lado) · `PLAN-blocks-quality.md` Q0.3 → sucesor · `surface/README.md` §Gaps «scrim de autoría» CERRADO por `Background.Scrim` · glosario con entrada `Background` y `Aura` corregida (decía «Not built yet» y está construido) · y en `motion-guide.md` §8 + el RFC: el travel ligado al scroll no es un preset —un preset nombra una transición discreta CON duración, y esto es modulación continua sin ninguna— y sólo se replantea como dominio con un segundo consumidor. Verificado en Chrome real: el puntero mueve `depth` y `spotlight` con los valores exactos y vuelven al centro al salir · `attach='fixed'` estampa y retira el recorte de la pila · el bleed aguanta el speed negativo · RTL: el `translate` del puntero se mantiene FÍSICO y el bleed en el eje de bloque · cada control de la demo cambia algo (los de `spotlight` y `depth` no llegaban a tres de las cuatro clases de capa hasta la segunda auditoría). ⚠️ SIN VERIFICAR, y no lo doy por bueno: el travel real al hacer scroll, los 60 fps y el detector de reflow. El panel del navegador va oculto con viewport 0×0 y ahí las animaciones scroll-driven declaradas en CSS no se activan — comprobado que es del ENTORNO con un caso mínimo inyectado (un `div` pelado con `animation-timeline: view()` sale inactivo mientras una `ViewTimeline` creada por API sobre el mismo sujeto marca 68%). Necesita una pasada con Chrome visible. Gates: audit `--only background` PASS 0 errores · eidos-lint invalid 0 · `rtl:check` 0/180 · `docs:check` 0/0 en 634 docs · `blocks:check` 0/18 · `morfo:check` PASS · smoke PASS · 441/442 (el fallo es el `skin-media-player` de siempre) · `check` 0 errores propios. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
dev	dc7c4920d6	blocks(cookie-consent): la ley europea como tipo, y las dos salidas al mismo peso ... Cierra el tramo C de F2b. El único block cuya fase 0 fue jurídica antes que visual: las referencias shippean el aviso como markup, y el markup no puede impedir las tres cosas que lo vuelven ilegal — un rechazo debilitado, categorías premarcadas, y cerrar tratado como consentir. Aquí son el tipo y el constructor. `essential: true` hace inescribible una UI que ofrezca apagarlo; `initialConsent()` no admite semilla, así que una primera pregunta no puede llegar marcada; `onDecision` es obligatoria, así que un aviso que no informa de vuelta no se puede montar. Las cinco reglas están numeradas en consent.ts y afirmadas por 8 tests, porque son justo lo que un refactor rompe en silencio mientras todo sigue pintando bien. Desviación de la ficha, y a favor: UNA llamada requerida `onDecision(consent, via)` en vez de `onAcceptAll` + `onRejectAll`. Con dos callbacks el consumidor podía pasar un no-op a «rechazar»; aquí el camino de rechazo lo renderiza el block y el API no expone knob para degradarlo. Medido: las dos acciones tienen idéntico relleno, tinta, borde, tamaño, peso y alto — 5.96:1 en claro, 8.79:1 en oscuro. Tres cosas se arreglaron por mirar, no por deducir. La barra era un `Card` outline y midió 1.00:1 contra la página: se disolvía en ella, así que va al plano `overlay` del sistema, el mismo que estampa cada superficie flotante del canon. A 375 las tres acciones envolvían con «rechazar» en una fila y «aceptar» en la siguiente, leyéndose como dos botones ajenos justo donde la pareja más importa: ahora son un `Group`, y el markup lo dice. Y el panel devolvía el foco a un nodo muerto — se devuelve aquí, un frame después de que la trampa se desarme, con un pestillo para que el asentamiento del montaje no le robe el foco a nadie al cargar. Tres gaps de canon salieron al componerlo, todos en el README: `Button` acepta `ref` y no lo reenvía (forma de A-94), `Switch` no tiene parte de etiqueta, y el `Dialog` restaura el foco a un nodo muerto cuando su disparador se desmontó. El instrumento mintió antes que el código, otra vez: el pane del navegador no compone frames, así que la animación de salida no termina y un diálogo cerrado sigue pintado — el foco medido allí era ficción. Y `fillStyle` no normaliza oklch, así que todo color leído del estilo computado se volvió negro y dio 1.11:1 sobre texto perfectamente legible. Las cifras de esta ficha se miden por píxel, en Chrome real. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2 months ago
dev	313e4d52fa	blocks(article-grid): la banda editorial, y el elemento que el canon no podía dar ... Lo que las referencias llaman blog. Sus dos preguntas de fase cero quedan resueltas, y ninguna necesitó tocar el canon. El nombre. Blog nombra una sección entera de un sitio, y esto es la fila de artículos recientes dentro de otra página; el tier nombra por función de página y el elemento que renderiza es un article, así que article-grid hace coincidir nombre, función y markup. La palabra blog sobrevive donde un consumidor la busca: la primera línea del readme y la etiqueta del catálogo. El artículo semántico. Un teaser tiene que ser un article o se lee como una caja de texto suelto, pero la tarjeta del canon es un div fijo y eso parecía obligar a elegir entre añadirle un eje de elemento o declarar un hueco. Construirlo enseñó la tercera vía, que no cuesta nada: el bloque renderiza el article y compone la tarjeta dentro. El tier lleva desde su primer bloque renderizando sus propios elementos de seccionado, así que el elemento es del bloque y la superficie sigue siendo del canon. La regla amuralla al primitivo, no a la composición. Y tres decisiones más que sí son de diseño. La tarjeta entera no es un enlace, porque el teaser lleva además un chip y una firma y anidar interactivos dentro de un enlace es marcado inválido: es justo donde acaban las referencias que hacen clicable toda la tarjeta, así que el enlace vive en el título y hay exactamente uno por teaser. El realce al puntero viene encendido, al revés que en precios, porque un teaser sí es algo a lo que se va. Y el bloque no formatea fechas: las compone la app con el componente del canon. Dos errores míos en la tanda, los dos cazados mirando la captura y no la sonda. El ancho mínimo por defecto sólo cabía dos veces en la medida, cuando las referencias lideran con tres columnas; medido y corregido, ahora da tres, dos y una según el ancho. Y el segundo intento de arreglarlo no llegó a aplicarse sin que me diera cuenta, porque lancé el reemplazo sin aserción y el formateador había juntado las props en una línea: culpé a la caché del servidor antes de mirar el fichero. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
dev	b7474e499d	blocks(logo-cloud): la banda de marcas vuelve, y su parte difícil no era la disposición ... Se difirió en F2 sobre una premisa que las referencias desmienten —que su versión honesta pedía un marquee o quedaba en un wrap trivial—: Tailwind Plus, Untitled y Flowbite lo shippean estático. Una decisión cuya premisa cae se corrige. Pero el argumento para construirlo no es la paridad. Lo difícil de un muro de logos es la tinta: veinte marcas en veinte paletas gritan sobre la página y entre ellas. Ese tratamiento acaba de entrar en la fundación como contexto, así que el bloque queda fino y es exactamente la forma correcta — cuando lo difícil es un tratamiento, el tratamiento va a la fundación y el bloque sólo lo estampa. Aquí no hay una línea de CSS, que es además lo que el contrato exige. Dos decisiones medidas, no elegidas. Las marcas van en un wrap y no en una rejilla, porque llegan con proporciones dispares y unas pistas iguales dejan huecos irregulares alrededor de las estrechas. Y la parte del ítem se gana su sitio defaulteando el eje de bloque, que es lo único que un logo nunca trae consigo: un vectorial carga su viewBox, un raster sus píxeles, y uno al lado del otro aterrizan a cinco alturas distintas. Verificado con ocho marcas de anchos y colores deliberadamente dispares: las ocho a una sola altura conservando sesenta y cuatro píxeles de diferencia de ancho, que es cada una guardando su proporción. El marquee se queda como hueco con disparador y con su forma decidida: si algún día entra será un preset de movimiento sobre la fila, no un bloque nuevo, y con la preferencia de movimiento reducido parándolo. Y el hueco de la utilidad para nombres sólo audibles sale aquí por tercera vez en la ola. Tres consumidores reales lo piden ya. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
dev	00489be263	blocks(tramo B): las cinco primeras matrices de equivalencia ... El entregable central de la ola, y el que responde a la pregunta que la abrió: no competir en número de dumps, sino demostrar variante a variante qué composición nuestra logra cada una de las suyas — y sacar a la luz, con nombre, lo que no alcanzamos. Cada block gana una sección de equivalencias con cinco columnas: la variante de la referencia, quién la shippea, la receta exacta, dónde se ha visto, y su estado. La regla que gobierna la tabla es que una receta que no se ha visto en el navegador no entra: la columna de demostración es la prueba, no la promesa. Y la primera tabla ya justificó el tramo. El hero declaraba desde julio, en sus gaps, que el mockup de móvil estaba HECHO — y la demo sólo había enseñado nunca el cromo de navegador. El primitivo ofrece tres, así que se añadió el control, se midió el cromo de teléfono a trescientos veinte y sólo entonces se escribió la fila. Una receta declarada no es una receta demostrada, que es exactamente lo que este tramo existe para separar. Van cinco de quince: hero, pricing, cta, testimonials y faq, que son los que esta sesión ha trabajado y cuyas recetas están medidas. Entre las filas quedan nueve gaps con nombre —desde la elevación estática que Card no tiene hasta el carrusel de citas— y dos «no se ofrece» con su motivo: un carrusel en la apertura es movimiento automático sin control de pausa, y filtrar preguntas es estado de datos del app. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
dev	e7677d6d87	blocks(pricing): la tabla de comparación, y las palabras que una marca no dice ... La brecha recurrente del dossier en pricing, y la última fila del primer tramo de la ola. Es una PARTE y no un hermano porque tiene que obedecer al periodo de la sección, y sólo una parte puede leer ese contexto: B-10 le prohíbe a un hermano importar el block que lo posee. Vivir dentro de la sección es además lo que permite que la app meta el precio en una celda y cambie con el conmutador, sin que esta página cablee nada. La app construye la tabla y el block la compone. B-5 admite datos justo donde el canon compuesto ya es data-driven, y la tabla del canon lo es: exige la instancia que devuelve createTable. Así que la parte no inventa un formato de matriz propio ni traduce nada de ida y vuelta, que es el acoplamiento que esa regla existe para evitar. Las tarjetas y la tabla conviven, como en las referencias, alimentadas por el mismo array de planes. Dos cosas que el plan había esbozado y que construirlas demostró equivocadas, y quedan escritas en vez de calladas. No hay un Record de ejes visuales por plan: acentuar una columna es componer canon, que es justo lo que ya permite el snippet de cabecera, y ese Record habría sido una segunda fuente de lo que la app declara en su plan. Y el block no fija la columna: el motor es del app, y meter mano ahí sería el block decidiendo cómo se comporta la tabla de otro. Lo que sí posee es lo que la app no puede: el nombre accesible de la tabla y las palabras que una marca de visto o de guion no dice en voz alta. Ese glifo lleva todo el significado de la celda y es silencio para un lector de pantalla, así que va oculto y la frase viaja en su etiqueta, desde un mapa exhaustivo con respaldo en inglés y su test en las dos direcciones. Y absorbe el cast del canon siendo genérico: la tabla tipa su ranura sin parámetro mientras el motor sí lo devuelve, así que todo consumidor castea, empezando por la demo del propio componente. Aquí se castea una vez a la entrada y se deshace a la salida, para que el snippet de celda devuelva la fila con la forma del app. Medido a 1280 y 375: ocho filas por cuatro columnas, tabla nombrada, marcas que se anuncian, y en móvil la tabla desplaza con la columna de características quieta y la última columna alcanzable. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
dev	f4ce006423	blocks(faq): la lista estática, y un tipo que deja de prometer lo que no da ... La brecha del dossier para este block, y la mayoría del formato: seis de siete en Tailwind Plus no son acordeón, sino una rejilla de preguntas y respuestas siempre abiertas. El eje vive en la LISTA, no en la raíz. Primero porque la lista es lo único que cambia —la cabecera se lee igual—, y segundo porque esa colocación es la que permite que el tipo diga la verdad: pasa a ser una unión discriminada. Bajo acordeón atraviesa toda la superficie del Accordion del canon; bajo lista no se ofrece ninguna de esas props, porque una rejilla estática no tiene estado abierto que enlazar, nada que colapsar ni modo simple o múltiple. Ofrecer una superficie y descartarla en silencio es justo lo que A-94 dejó dicho que no se hace, y aquí es donde iba a morder después. El ítem lee la disposición del contexto: no puede discriminar sobre la unión de la lista sin obligar a la app a repetir el arreglo en cada pregunta. Su value y su disabled quedan documentados como del acordeón, la misma convención que el fondo del hero y la media del cta. Y bajo lista la pregunta es un encabezado de verdad, porque ahí ES el encabezado de su respuesta; bajo acordeón el canon la mete dentro del disparador y esa semántica es suya, así que el block no inventa una segunda. Medido a 1280: en acordeón, cinco disparadores, ningún encabezado, medida de setecientos sesenta y ocho y respuestas ocultas hasta pulsar; en lista, ningún disparador, cinco encabezados, tres pistas de trescientos nueve, medida de mil veinticuatro y todas las respuestas visibles sin tocar nada. A 375 cae a una columna conservando ambas cosas. El acordeón queda idéntico. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
dev	f3bfcf2dd9	blocks(testimonials): una cita sola no va en una tarjeta ... La brecha que el dossier le apuntaba a este block: la cita única es la variante modal de todas las referencias y el grid la minoría, dos de ocho en Tailwind Plus. Entra como disposición, no como hermano. La anatomía no cambia —cita, autor, avatar—, sólo cómo se colocan, y el precedente es el fondo del hero, que también redefine lo que hacen sus partes. El hermano se reabre sólo si algún día pide rotación o carrusel, que es otro componente. Viaja por contexto de configuración, el patrón del align de feature-grid y team, no la coordinación de pricing. Y viaja porque el spotlight no es una piel sobre las mismas cajas: la rejilla deja de serlo y de estampar el ritmo estructural —que es para una FILA, no para una cita—, el ítem pierde la tarjeta, la cita sube de tamaño y se centra, y el autor pasa debajo, donde ya no hay una hilera de caras que alinear. Pedirle a la app que repita esa decisión en cinco partes es el agujero que A-84 cerró en feature-grid. Enmarcar una cita sola la hace parecer un ítem de una lista que no está ahí, así que ahí no hay tarjeta y el tipo lo dice, en vez de aceptar una superficie que luego descarta. La cita se centra con un párrafo de verdad: sobre una caja en línea el centrado no aplica, y sería mentira. Slot nuevo para la marca de quien firma, en las dos disposiciones: es lo que hace que una cita se lea como evidencia y no como una opinión, y es la pieza que ponen todas las referencias. Medido: en grid, cinco tarjetas, veinte píxeles, medida de mil veinticuatro y ritmo escalonado; en spotlight, cero tarjetas, una cita de veintiocho centrada en párrafo, medida de setecientos sesenta y ocho, autor centrado y sin escalonado; a 375 la cita cae a veinticuatro. El grid queda idéntico a antes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
dev	0646d5ebde	blocks(pricing): el plan dice dónde estás, y el que no puedes elegir dice por qué ... Firma del usuario: faltaba la decoración del elegido, y faltaba poder marcar un plan como no disponible — si estoy cambiando de plan, el que ya tengo no debería poder seleccionarse. Lo segundo cambia la posición doctrinal del block. Su README decía desde julio que nada en una tabla de precios puede bloquearse y que por tanto no hay nada que explicar. Eso vale mientras la sección es sólo una comparación; se cae en cuanto el visitante ya está en un plan. Y ahí manda lo que costó contact: una acción bloqueada debe su frase, o es un agujero — algo que no se puede hacer y nada en pantalla diciendo por qué. El plan gana un estado: disponible, actual o elegido. Un enum y no tres booleanos, porque tres booleanos admiten lo que no existe, como elegido y no disponible a la vez. Y ortogonal a featured, que es la recomendación de quien vende: el plan recomendado puede ser justamente el que ya tienes. Se deriva una sola vez en el plan y viaja por contexto. La acción se lo entrega al botón del app por parámetro de su snippet, así que nadie vuelve a deducir en el punto de uso si se puede pulsar, y las palabras del botón siguen siendo del app. La frase, en cambio, es del block: idlangref con respaldo en inglés dentro de un Record exhaustivo, el mismo mapa que bloquea la acción es el que escribe el motivo, así que un estado que bloquea en silencio no se puede ni expresar. Su test lo afirma en las dos direcciones. Y una parte nueva la dice y posee el id al que apunta el aria-describedby del botón deshabilitado, sin renderizar nada cuando no hay nada que decir. La decoración la pone el canon: el elegido reenvía el anillo de Card, el actual su tratamiento deshabilitado. Nada de un data-pricing-selected propio: sería un atributo que nadie lee, porque un block no pinta CSS. Medido de punta a punta en el escenario de cambio de plan: el actual sale con cursor de no permitido, botón deshabilitado y aria-describedby que casa con el id de la frase, traducida por el arnés; al elegir otro, su tarjeta gana el anillo de dos píxeles con el primary de su paleta y las demás no. Queda anotado un gap del canon que salió al medir esto y que no toco: Card disabled nunca atenúa. La regla existe y su cursor sí aplica, pero la animación de montaje fija la opacidad en uno con prioridad de animación y se come la del estado; aislado con no-emerge, atenúa. Es el patrón que la doctrina de motion llama frágil-conocido —dos dueños peleándose por una propiedad en un nodo— y alcanza a toda Card deshabilitada del ecosistema. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
dev	db026e48f5	blocks(pricing): la tarjeta responde al puntero, y el guard deja de leer prosa ... El plan reenvía el eje nuevo de Card. No es el `interactive` del canon: eso convertiría la tarjeta en un botón y `.PlanAction` ya tiene uno dentro. Apagado por defecto, porque una fila de planes es una comparación y una tarjeta que responde al puntero sugiere que la tarjeta misma es el control; se enciende donde la tarjeta entera ES la elección. Control vivo en la demo y en la URL de la vista previa. Y al escribir el comentario que explica por qué NO se usa un nativo aquí, el guard del tier se puso rojo sobre mi propia prosa: la regla B-2 leía comentarios como código. Su barrido quitaba sólo los de UNA línea, mientras el que entiende todas las formas y conserva los saltos ya existía tres líneas más abajo, usándose sólo para los imports. Es la lección de la fase cinco aplicada a una regla y no a la otra. Arreglado con dos fixtures nuevos —un nativo nombrado dentro de un comentario multilínea es prosa; un nativo de verdad debajo de ese mismo comentario sigue siendo error— y probado en rojo sobre el árbol real: un button inyectado en el hero sale señalado con su línea exacta, y el árbol queda restaurado después. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
dev	44e4c9328e	blocks(hero): un vídeo en un hero es paisaje, y que se repita lo decide quien lo pone ... Corrección del usuario, y tenía razón: la demo componía el reproductor completo con su barra de controles, y nadie enseña un botón de play en una sección de apertura. Un vídeo de hero es decorativo — mudo, en línea, arrancando solo y sin controles. Y si se repite o no es una decisión, no algo horneado: en bucle el movimiento no termina nunca, así que sale como control vivo propio. Medido: cero botones, sin nodo de controles, y el loop siguiendo al conmutador. De paso queda registrado lo que aquello escondía. La barra que había se pintaba directamente sobre el fotograma sin fondo propio, así que en un clip claro eran siete botones a opacidad uno que nadie podía ver; es del canon y media-player está en la lista de intocables de este plan, así que se documenta por si algún día vuelve. Y un hallazgo más gordo, medido al cablear lo anterior: la preferencia de movimiento no llega a prefs en este arranque. Un vídeo que se repite sin barra de controles no se puede pausar, así que su autoplay tiene que ceder ante la preferencia declarada del visitante, igual que ya hacen las entradas de Motion del propio block. La puerta está escrita en app-land y hoy es inerte: con prefers-reduced-motion emulado en reduce, el valor efectivo sigue resolviendo allow, la raíz sigue estampando data-motion allow y el clip sigue corriendo. Queda puesta —empezará a funcionar el día que el eje lo haga— y anotada como lo que es: un problema de WCAG 2.2.2 a nivel de framework, no un detalle. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
dev	fd9df269ef	blocks(hero): un slot apagado se pasa vacío, no se renderiza a cero ... El usuario dijo que en la demo hay propiedades que no hacen nada. Medí los diez controles uno a uno: nueve tienen efecto comprobable y uno funcionaba a medias. Apagar el eyebrow quitaba el contenido y dejaba el hueco: el stack de copia seguía con seis hijos y el primero medía cero de alto, comiéndose los veinte píxeles del gap. La causa era de la demo, no del block, y contra una regla que el propio handoff del tier tiene escrita: el snippet se declaraba con un {#if} DENTRO, así que siempre llegaba, el {#if eyebrow} del block seguía siendo cierto y sobrevivían el envoltorio de Motion y su parte del ritmo con nada dentro. Ahora el contenido se declara fuera y se pasa como undefined cuando no toca — lo mismo para la media, el formulario y el aviso de confirmación. Medido: cuatro hijos con el chip puesto, tres sin él, y ningún hijo de altura cero en ninguna combinación. Queda registrado además el defecto que el usuario vio en el vídeo del hero: los controles del MediaPlayer están —siete botones, todos con caja, opacidad uno— pero se pintan sin fondo propio sobre el fotograma, así que en un clip claro son ilegibles y se leen como ausentes. Es del canon, y media-player está en la lista de intocables de este plan, así que se documenta sin tocarlo. Con la nota de método: contar nodos y leer la opacidad no dice nada de la legibilidad sobre contenido en movimiento. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago