docs(theming): la auditoría de alcance de tema, componente a componente, con su propuesta
El censo medía el eje y no lo explicaba: 5.205 knobs en dos tablas del plan no
dicen QUÉ knob de QUÉ línea no alcanza un tema, ni qué token habría que crear.
Ahora `theming-census.ts --report` escribe la auditoría entera bajo
`docs/audit/theming/`: un README con la vista de conjunto y 170 fichas — 162
recetas con CSS + 8 componentes sin receta, el árbol completo de
`eidos/components/`.
Cada ficha de receta: knobs fuera de alcance con fichero:línea Y selector
(agrupados por clase), sistema transversal aparte, los privados con la columna
que decide («¿deriva de un público?»), y una PROPUESTA de corrección — el token
a declarar en `base.ts` con su valor VERBATIM y su scope TSC. La propuesta
deriva los nombres de recipe-contract §1 y theming §6.7; donde la doctrina no
decide, marca `⚠ decisión` en vez de inventar. Y no propone acuñar lo que la
doctrina prohíbe: lo que posee una capa compartida, el foco, la capa de estado,
un token prestado de otra receta, un shorthand o un eje físico.
Las 8 fichas sin receta dicen —medido, no supuesto— dónde vive su visual: el
componente que componen (icon-button → button), la capa que consumen (affix →
viewport-placement) o la receta ajena que pinta sus attrs (svg → badge/button).
Defectos del instrumento corregidos en el mismo pase, todos encontrados
mirando la salida: un `@import` pegado al primer selector se comía 2 knobs de
color-picker (el suelo del censo no puede moverse); `:not(:disabled)` se leía
como estado y producía `hover-disabled-*`; un knob que lee un privado se
proponía a sí mismo en vez de resolverse por talla; `--icon-size-sm` se
reportaba como préstamo del componente `icon` (ahora el préstamo se verifica
contra las claves del dueño en `base.ts`); y el default de talla salía sin
nombrar en vez de `-md`.
Verificación: censo global idéntico al suelo publicado (5205 · 1621/33% · 856 ·
1880 · 614 · 234) y COMPONENTE A COMPONENTE contra la tabla §9 del plan — 0
diferencias en 162 · regenerar dos veces da el árbol idéntico · el bloque de
veredicto escrito a mano sobrevive · docs:check 0 errores sobre 813 docs ·
prettier limpio (el árbol generado entra en .prettierignore junto a
eidos/generated).
Las 10 primeras fichas llevan ya su veredicto de revisión: análisis correcto en
las 10, propuesta apta en 2 (gradient-builder como piloto, combobox con cinco
correcciones — dos de ellas evitaban romper el default), y 5 que no se
tokenizan en solitario porque son alias de --calendar-*/--field-* y esperan la
decisión de familia. Cuatro destaparon privados con prefijo ajeno o abreviado
declarados en su propio CSS.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2 months ago
# gradient-picker — alcance de tema: análisis y propuesta
> Generado por `node --import tsx/esm scripts/theming-census.ts --report`.
> Lo **medido** y la **propuesta** se regeneran; el **Veredicto** (§5) se conserva.
> Vista de conjunto: [README](./README.md) · método y protocolo:
> [`PLAN-theming.md`](../../process/PLAN-theming.md) §1, §2, §7.
uix(callout): temable — 27 % → 79 %, y la base óptica deja de copiar el sistema
7 claves nuevas (28 → 35) y un literal anotado. El 21 % que falta es el PUENTE
DE PALETA (THM-2), que no es deuda: es la vía por la que `data-color` resuelve
los 8 roles y las 33 escalas donantes sin una línea de CSS extra. Global 64 %.
Cosido lo que la receta consumía a pelo: el hueco de fila, la tipografía del
cuerpo (`font-size` + `line-height` — así se lee una admonición), la tinta, el
tamaño del icono y el peso del título. Los tres pasos leen el BUNDLE
(`--size-md-font-size`, `--size-md-font-line-height`, `--size-md-icon-size`).
LA LÍNEA BASE ÓPTICA DEL ICONO DEJA DE REPETIR LAS MÉTRICAS DEL SISTEMA: era
`calc(var(--size-md-font-size) * var(--font-line-height-md, 1.5))` y ahora es
`calc(var(--callout-font-size) * var(--callout-line-height))` — la misma
derivación, sobre los tokens del propio callout, así que un tema que agrande la
copia mueve la caja del glifo con ella.
Cinco respaldos muertos retirados: `var(--callout-gap, var(--space-3))`,
`padding`, `accent-width`, `radius` —las cuatro claves están en el contrato— y
el `, 1.5` de `--font-line-height-md`, que además MENTÍA: el token existe y vale
1.45.
Los 24 rojos del guard son los TONOS, y no son de este componente: es la
supersesión de la cascada de paleta que `button` destapó hoy (el bloque genérico
va el último y gana por orden). Adjudicados con el patrón compartido, que ahora
nombra su razón una sola vez para los dos componentes.
Gates: sonda 0 diffs en 896 valores × 7 estados · centinela 10/34 con los tonos
adjudicados · censo 79 % · `component:audit` PASS · suite eidos con el rojo
conocido ajeno · `rtl:check` 0 · `docs:check` 0 · `check` sin errores propios ·
captura de cuatro tonos.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2 months ago
- **Medido**: 2026-08-23 · **Alcance** : **88%** — 23 de 26 knobs por token público
tooling(theming): el censo aprende a leer la válvula del canon — clase `exception`
Global 58 % → **59 %** sin tocar una línea de CSS: 54 knobs que eran deuda
resultan ser desviaciones que el canon ya había firmado.
`recipe-contract` §3 dice que una desviación anotada `/* literal: <razón> */`
EN SU PROPIA DECLARACIÓN es válida, y `component-audit` la honra desde siempre
(`declarationWindow` + `/literal:/i` en R-2.1, R-2.6 y R-2.7). El censo era el
único instrumento que no: su `strip()` blanquea los comentarios ANTES de
clasificar, así que las **81 anotaciones del catálogo** contaban como literales
sin excusa. Dos instrumentos, un canon, dos respuestas — y la que mandaba era la
del que no sabía leerlo.
Ahora un literal anotado cae en la clase **`exception`, fuera del ratio** como
`system`, y por la misma razón: no es que un tema no lo alcance, es que el canon
ya aceptó por escrito que ahí no va un token.
**54 knobs en 12 componentes**: `prose` 21 (su escala editorial em-relativa, que
su README documenta como decisión — «No 5× duplicated scale»), `proof-of-human`
16 (la escena de tono fijo), `palabras` 3, `timeline` 2 (73 % → **77 %**),
`result` 1 (86 % → **90 %**), y siete más con una cada uno.
Detalles que costaron medición:
- **La anotación vale para la DECLARACIÓN entera**, no sólo para su primera
línea: un valor partido en varias líneas lleva la nota al final. Se comprueban
todas las líneas que abarca la declaración.
- **`strip()` blanquea en el sitio** (sustituye por espacios, conserva los
saltos), así que el cuerpo despojado y el crudo quedan alineados línea a línea
y basta con guardar el crudo al lado.
- Muta-prueba: retirar una anotación de `prose` mueve el knob de `exception` a
`literal` (21 → 20) y el conteo vuelve al restaurarla.
Efecto colateral bueno: cada ficha gana una **§1.4 «Excepciones firmadas»** que
las LISTA con su razón. Estaban escritas en el CSS y no se leían desde ninguna
parte; ahora la ficha del componente las enseña, que es donde se decide si una
sigue siendo cierta.
Las 163 fichas cambian porque la plantilla cambia (sección nueva + la línea de
reparto); el README de la auditoría gana la fila de la clase y la nota de que
`system` y `exception` quedan fuera del denominador.
Guards: `--names` 4.105 claves, DESVIADAS 0 · component-audit PASS · docs:check
0 · `check` con 72 errores globales y 0 en los ficheros tocados.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2 months ago
- **Knobs de apariencia**: 27 — público 23 · privado 0 · global 2 · literal 1 · sistema 1 · excepción 0 _(los dos últimos, fuera del ratio)_
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
- **Contrato hoy** (`lib/recipes/base.ts`): 25 pública(s) — `chip-size-sm` , `chip-size-md` , `chip-size-lg` , `chip-size` , `gap` , `trigger-gap` , `border-width` , `chip-radius` , `chip-border` , `content-width-sm` , `content-width-md` , `content-width-lg` , `stoplist-max-block` , `stoplist-scrollbar-size` , `stoplist-scrollbar-inset` , `presets-panel-width` , `presets-gap` , `presets-min-column` , `preset-height` , `preset-radius` , `preset-border` , `hover-preset-border` , `selected-preset-border` , `selected-preset-outline-offset` , `actions-gap`
- **Eje `size` **: no · **ficheros** : `gradient-picker.css`
docs(theming): la auditoría de alcance de tema, componente a componente, con su propuesta
El censo medía el eje y no lo explicaba: 5.205 knobs en dos tablas del plan no
dicen QUÉ knob de QUÉ línea no alcanza un tema, ni qué token habría que crear.
Ahora `theming-census.ts --report` escribe la auditoría entera bajo
`docs/audit/theming/`: un README con la vista de conjunto y 170 fichas — 162
recetas con CSS + 8 componentes sin receta, el árbol completo de
`eidos/components/`.
Cada ficha de receta: knobs fuera de alcance con fichero:línea Y selector
(agrupados por clase), sistema transversal aparte, los privados con la columna
que decide («¿deriva de un público?»), y una PROPUESTA de corrección — el token
a declarar en `base.ts` con su valor VERBATIM y su scope TSC. La propuesta
deriva los nombres de recipe-contract §1 y theming §6.7; donde la doctrina no
decide, marca `⚠ decisión` en vez de inventar. Y no propone acuñar lo que la
doctrina prohíbe: lo que posee una capa compartida, el foco, la capa de estado,
un token prestado de otra receta, un shorthand o un eje físico.
Las 8 fichas sin receta dicen —medido, no supuesto— dónde vive su visual: el
componente que componen (icon-button → button), la capa que consumen (affix →
viewport-placement) o la receta ajena que pinta sus attrs (svg → badge/button).
Defectos del instrumento corregidos en el mismo pase, todos encontrados
mirando la salida: un `@import` pegado al primer selector se comía 2 knobs de
color-picker (el suelo del censo no puede moverse); `:not(:disabled)` se leía
como estado y producía `hover-disabled-*`; un knob que lee un privado se
proponía a sí mismo en vez de resolverse por talla; `--icon-size-sm` se
reportaba como préstamo del componente `icon` (ahora el préstamo se verifica
contra las claves del dueño en `base.ts`); y el default de talla salía sin
nombrar en vez de `-md`.
Verificación: censo global idéntico al suelo publicado (5205 · 1621/33% · 856 ·
1880 · 614 · 234) y COMPONENTE A COMPONENTE contra la tabla §9 del plan — 0
diferencias en 162 · regenerar dos veces da el árbol idéntico · el bloque de
veredicto escrito a mano sobrevive · docs:check 0 errores sobre 813 docs ·
prettier limpio (el árbol generado entra en .prettierignore junto a
eidos/generated).
Las 10 primeras fichas llevan ya su veredicto de revisión: análisis correcto en
las 10, propuesta apta en 2 (gradient-builder como piloto, combobox con cinco
correcciones — dos de ellas evitaban romper el default), y 5 que no se
tokenizan en solitario porque son alias de --calendar-*/--field-* y esperan la
decisión de familia. Cuatro destaparon privados con prefijo ajeno o abreviado
declarados en su propio CSS.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2 months ago
## 1. Knobs fuera de alcance
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
### 1.1 Directo a primitivo global (2)
docs(theming): la auditoría de alcance de tema, componente a componente, con su propuesta
El censo medía el eje y no lo explicaba: 5.205 knobs en dos tablas del plan no
dicen QUÉ knob de QUÉ línea no alcanza un tema, ni qué token habría que crear.
Ahora `theming-census.ts --report` escribe la auditoría entera bajo
`docs/audit/theming/`: un README con la vista de conjunto y 170 fichas — 162
recetas con CSS + 8 componentes sin receta, el árbol completo de
`eidos/components/`.
Cada ficha de receta: knobs fuera de alcance con fichero:línea Y selector
(agrupados por clase), sistema transversal aparte, los privados con la columna
que decide («¿deriva de un público?»), y una PROPUESTA de corrección — el token
a declarar en `base.ts` con su valor VERBATIM y su scope TSC. La propuesta
deriva los nombres de recipe-contract §1 y theming §6.7; donde la doctrina no
decide, marca `⚠ decisión` en vez de inventar. Y no propone acuñar lo que la
doctrina prohíbe: lo que posee una capa compartida, el foco, la capa de estado,
un token prestado de otra receta, un shorthand o un eje físico.
Las 8 fichas sin receta dicen —medido, no supuesto— dónde vive su visual: el
componente que componen (icon-button → button), la capa que consumen (affix →
viewport-placement) o la receta ajena que pinta sus attrs (svg → badge/button).
Defectos del instrumento corregidos en el mismo pase, todos encontrados
mirando la salida: un `@import` pegado al primer selector se comía 2 knobs de
color-picker (el suelo del censo no puede moverse); `:not(:disabled)` se leía
como estado y producía `hover-disabled-*`; un knob que lee un privado se
proponía a sí mismo en vez de resolverse por talla; `--icon-size-sm` se
reportaba como préstamo del componente `icon` (ahora el préstamo se verifica
contra las claves del dueño en `base.ts`); y el default de talla salía sin
nombrar en vez de `-md`.
Verificación: censo global idéntico al suelo publicado (5205 · 1621/33% · 856 ·
1880 · 614 · 234) y COMPONENTE A COMPONENTE contra la tabla §9 del plan — 0
diferencias en 162 · regenerar dos veces da el árbol idéntico · el bloque de
veredicto escrito a mano sobrevive · docs:check 0 errores sobre 813 docs ·
prettier limpio (el árbol generado entra en .prettierignore junto a
eidos/generated).
Las 10 primeras fichas llevan ya su veredicto de revisión: análisis correcto en
las 10, propuesta apta en 2 (gradient-builder como piloto, combobox con cinco
correcciones — dos de ellas evitaban romper el default), y 5 que no se
tokenizan en solitario porque son alias de --calendar-*/--field-* y esperan la
decisión de familia. Cuatro destaparon privados con prefijo ajeno o abreviado
declarados en su propio CSS.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2 months ago
| # | fichero:línea | selector | propiedad | valor |
| ---: | --- | --- | --- | --- |
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
| 1 | `gradient-picker.css:52` | `.gradient-picker-trigger-swatch` | `background` | `var(--gp-current-gradient, transparent)` |
| 2 | `gradient-picker.css:64` | `[data-gradient-picker-value-swatch]` | `background` | `var(--gp-current-gradient, transparent)` |
docs(theming): la auditoría de alcance de tema, componente a componente, con su propuesta
El censo medía el eje y no lo explicaba: 5.205 knobs en dos tablas del plan no
dicen QUÉ knob de QUÉ línea no alcanza un tema, ni qué token habría que crear.
Ahora `theming-census.ts --report` escribe la auditoría entera bajo
`docs/audit/theming/`: un README con la vista de conjunto y 170 fichas — 162
recetas con CSS + 8 componentes sin receta, el árbol completo de
`eidos/components/`.
Cada ficha de receta: knobs fuera de alcance con fichero:línea Y selector
(agrupados por clase), sistema transversal aparte, los privados con la columna
que decide («¿deriva de un público?»), y una PROPUESTA de corrección — el token
a declarar en `base.ts` con su valor VERBATIM y su scope TSC. La propuesta
deriva los nombres de recipe-contract §1 y theming §6.7; donde la doctrina no
decide, marca `⚠ decisión` en vez de inventar. Y no propone acuñar lo que la
doctrina prohíbe: lo que posee una capa compartida, el foco, la capa de estado,
un token prestado de otra receta, un shorthand o un eje físico.
Las 8 fichas sin receta dicen —medido, no supuesto— dónde vive su visual: el
componente que componen (icon-button → button), la capa que consumen (affix →
viewport-placement) o la receta ajena que pinta sus attrs (svg → badge/button).
Defectos del instrumento corregidos en el mismo pase, todos encontrados
mirando la salida: un `@import` pegado al primer selector se comía 2 knobs de
color-picker (el suelo del censo no puede moverse); `:not(:disabled)` se leía
como estado y producía `hover-disabled-*`; un knob que lee un privado se
proponía a sí mismo en vez de resolverse por talla; `--icon-size-sm` se
reportaba como préstamo del componente `icon` (ahora el préstamo se verifica
contra las claves del dueño en `base.ts`); y el default de talla salía sin
nombrar en vez de `-md`.
Verificación: censo global idéntico al suelo publicado (5205 · 1621/33% · 856 ·
1880 · 614 · 234) y COMPONENTE A COMPONENTE contra la tabla §9 del plan — 0
diferencias en 162 · regenerar dos veces da el árbol idéntico · el bloque de
veredicto escrito a mano sobrevive · docs:check 0 errores sobre 813 docs ·
prettier limpio (el árbol generado entra en .prettierignore junto a
eidos/generated).
Las 10 primeras fichas llevan ya su veredicto de revisión: análisis correcto en
las 10, propuesta apta en 2 (gradient-builder como piloto, combobox con cinco
correcciones — dos de ellas evitaban romper el default), y 5 que no se
tokenizan en solitario porque son alias de --calendar-*/--field-* y esperan la
decisión de familia. Cuatro destaparon privados con prefijo ajeno o abreviado
declarados en su propio CSS.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2 months ago
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
### 1.2 A través de un privado (0)
_Ninguno._
docs(theming): la auditoría de alcance de tema, componente a componente, con su propuesta
El censo medía el eje y no lo explicaba: 5.205 knobs en dos tablas del plan no
dicen QUÉ knob de QUÉ línea no alcanza un tema, ni qué token habría que crear.
Ahora `theming-census.ts --report` escribe la auditoría entera bajo
`docs/audit/theming/`: un README con la vista de conjunto y 170 fichas — 162
recetas con CSS + 8 componentes sin receta, el árbol completo de
`eidos/components/`.
Cada ficha de receta: knobs fuera de alcance con fichero:línea Y selector
(agrupados por clase), sistema transversal aparte, los privados con la columna
que decide («¿deriva de un público?»), y una PROPUESTA de corrección — el token
a declarar en `base.ts` con su valor VERBATIM y su scope TSC. La propuesta
deriva los nombres de recipe-contract §1 y theming §6.7; donde la doctrina no
decide, marca `⚠ decisión` en vez de inventar. Y no propone acuñar lo que la
doctrina prohíbe: lo que posee una capa compartida, el foco, la capa de estado,
un token prestado de otra receta, un shorthand o un eje físico.
Las 8 fichas sin receta dicen —medido, no supuesto— dónde vive su visual: el
componente que componen (icon-button → button), la capa que consumen (affix →
viewport-placement) o la receta ajena que pinta sus attrs (svg → badge/button).
Defectos del instrumento corregidos en el mismo pase, todos encontrados
mirando la salida: un `@import` pegado al primer selector se comía 2 knobs de
color-picker (el suelo del censo no puede moverse); `:not(:disabled)` se leía
como estado y producía `hover-disabled-*`; un knob que lee un privado se
proponía a sí mismo en vez de resolverse por talla; `--icon-size-sm` se
reportaba como préstamo del componente `icon` (ahora el préstamo se verifica
contra las claves del dueño en `base.ts`); y el default de talla salía sin
nombrar en vez de `-md`.
Verificación: censo global idéntico al suelo publicado (5205 · 1621/33% · 856 ·
1880 · 614 · 234) y COMPONENTE A COMPONENTE contra la tabla §9 del plan — 0
diferencias en 162 · regenerar dos veces da el árbol idéntico · el bloque de
veredicto escrito a mano sobrevive · docs:check 0 errores sobre 813 docs ·
prettier limpio (el árbol generado entra en .prettierignore junto a
eidos/generated).
Las 10 primeras fichas llevan ya su veredicto de revisión: análisis correcto en
las 10, propuesta apta en 2 (gradient-builder como piloto, combobox con cinco
correcciones — dos de ellas evitaban romper el default), y 5 que no se
tokenizan en solitario porque son alias de --calendar-*/--field-* y esperan la
decisión de familia. Cuatro destaparon privados con prefijo ajeno o abreviado
declarados en su propio CSS.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2 months ago
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
### 1.3 Literales (1)
docs(theming): la auditoría de alcance de tema, componente a componente, con su propuesta
El censo medía el eje y no lo explicaba: 5.205 knobs en dos tablas del plan no
dicen QUÉ knob de QUÉ línea no alcanza un tema, ni qué token habría que crear.
Ahora `theming-census.ts --report` escribe la auditoría entera bajo
`docs/audit/theming/`: un README con la vista de conjunto y 170 fichas — 162
recetas con CSS + 8 componentes sin receta, el árbol completo de
`eidos/components/`.
Cada ficha de receta: knobs fuera de alcance con fichero:línea Y selector
(agrupados por clase), sistema transversal aparte, los privados con la columna
que decide («¿deriva de un público?»), y una PROPUESTA de corrección — el token
a declarar en `base.ts` con su valor VERBATIM y su scope TSC. La propuesta
deriva los nombres de recipe-contract §1 y theming §6.7; donde la doctrina no
decide, marca `⚠ decisión` en vez de inventar. Y no propone acuñar lo que la
doctrina prohíbe: lo que posee una capa compartida, el foco, la capa de estado,
un token prestado de otra receta, un shorthand o un eje físico.
Las 8 fichas sin receta dicen —medido, no supuesto— dónde vive su visual: el
componente que componen (icon-button → button), la capa que consumen (affix →
viewport-placement) o la receta ajena que pinta sus attrs (svg → badge/button).
Defectos del instrumento corregidos en el mismo pase, todos encontrados
mirando la salida: un `@import` pegado al primer selector se comía 2 knobs de
color-picker (el suelo del censo no puede moverse); `:not(:disabled)` se leía
como estado y producía `hover-disabled-*`; un knob que lee un privado se
proponía a sí mismo en vez de resolverse por talla; `--icon-size-sm` se
reportaba como préstamo del componente `icon` (ahora el préstamo se verifica
contra las claves del dueño en `base.ts`); y el default de talla salía sin
nombrar en vez de `-md`.
Verificación: censo global idéntico al suelo publicado (5205 · 1621/33% · 856 ·
1880 · 614 · 234) y COMPONENTE A COMPONENTE contra la tabla §9 del plan — 0
diferencias en 162 · regenerar dos veces da el árbol idéntico · el bloque de
veredicto escrito a mano sobrevive · docs:check 0 errores sobre 813 docs ·
prettier limpio (el árbol generado entra en .prettierignore junto a
eidos/generated).
Las 10 primeras fichas llevan ya su veredicto de revisión: análisis correcto en
las 10, propuesta apta en 2 (gradient-builder como piloto, combobox con cinco
correcciones — dos de ellas evitaban romper el default), y 5 que no se
tokenizan en solitario porque son alias de --calendar-*/--field-* y esperan la
decisión de familia. Cuatro destaparon privados con prefijo ajeno o abreviado
declarados en su propio CSS.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2 months ago
| # | fichero:línea | selector | propiedad | valor |
| ---: | --- | --- | --- | --- |
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
| 1 | `gradient-picker.css:117` | `[data-gradient-picker-preset]` | `inline-size` | `100%` |
docs(theming): la auditoría de alcance de tema, componente a componente, con su propuesta
El censo medía el eje y no lo explicaba: 5.205 knobs en dos tablas del plan no
dicen QUÉ knob de QUÉ línea no alcanza un tema, ni qué token habría que crear.
Ahora `theming-census.ts --report` escribe la auditoría entera bajo
`docs/audit/theming/`: un README con la vista de conjunto y 170 fichas — 162
recetas con CSS + 8 componentes sin receta, el árbol completo de
`eidos/components/`.
Cada ficha de receta: knobs fuera de alcance con fichero:línea Y selector
(agrupados por clase), sistema transversal aparte, los privados con la columna
que decide («¿deriva de un público?»), y una PROPUESTA de corrección — el token
a declarar en `base.ts` con su valor VERBATIM y su scope TSC. La propuesta
deriva los nombres de recipe-contract §1 y theming §6.7; donde la doctrina no
decide, marca `⚠ decisión` en vez de inventar. Y no propone acuñar lo que la
doctrina prohíbe: lo que posee una capa compartida, el foco, la capa de estado,
un token prestado de otra receta, un shorthand o un eje físico.
Las 8 fichas sin receta dicen —medido, no supuesto— dónde vive su visual: el
componente que componen (icon-button → button), la capa que consumen (affix →
viewport-placement) o la receta ajena que pinta sus attrs (svg → badge/button).
Defectos del instrumento corregidos en el mismo pase, todos encontrados
mirando la salida: un `@import` pegado al primer selector se comía 2 knobs de
color-picker (el suelo del censo no puede moverse); `:not(:disabled)` se leía
como estado y producía `hover-disabled-*`; un knob que lee un privado se
proponía a sí mismo en vez de resolverse por talla; `--icon-size-sm` se
reportaba como préstamo del componente `icon` (ahora el préstamo se verifica
contra las claves del dueño en `base.ts`); y el default de talla salía sin
nombrar en vez de `-md`.
Verificación: censo global idéntico al suelo publicado (5205 · 1621/33% · 856 ·
1880 · 614 · 234) y COMPONENTE A COMPONENTE contra la tabla §9 del plan — 0
diferencias en 162 · regenerar dos veces da el árbol idéntico · el bloque de
veredicto escrito a mano sobrevive · docs:check 0 errores sobre 813 docs ·
prettier limpio (el árbol generado entra en .prettierignore junto a
eidos/generated).
Las 10 primeras fichas llevan ya su veredicto de revisión: análisis correcto en
las 10, propuesta apta en 2 (gradient-builder como piloto, combobox con cinco
correcciones — dos de ellas evitaban romper el default), y 5 que no se
tokenizan en solitario porque son alias de --calendar-*/--field-* y esperan la
decisión de familia. Cuatro destaparon privados con prefijo ajeno o abreviado
declarados en su propio CSS.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2 months ago
tooling(theming): el censo aprende a leer la válvula del canon — clase `exception`
Global 58 % → **59 %** sin tocar una línea de CSS: 54 knobs que eran deuda
resultan ser desviaciones que el canon ya había firmado.
`recipe-contract` §3 dice que una desviación anotada `/* literal: <razón> */`
EN SU PROPIA DECLARACIÓN es válida, y `component-audit` la honra desde siempre
(`declarationWindow` + `/literal:/i` en R-2.1, R-2.6 y R-2.7). El censo era el
único instrumento que no: su `strip()` blanquea los comentarios ANTES de
clasificar, así que las **81 anotaciones del catálogo** contaban como literales
sin excusa. Dos instrumentos, un canon, dos respuestas — y la que mandaba era la
del que no sabía leerlo.
Ahora un literal anotado cae en la clase **`exception`, fuera del ratio** como
`system`, y por la misma razón: no es que un tema no lo alcance, es que el canon
ya aceptó por escrito que ahí no va un token.
**54 knobs en 12 componentes**: `prose` 21 (su escala editorial em-relativa, que
su README documenta como decisión — «No 5× duplicated scale»), `proof-of-human`
16 (la escena de tono fijo), `palabras` 3, `timeline` 2 (73 % → **77 %**),
`result` 1 (86 % → **90 %**), y siete más con una cada uno.
Detalles que costaron medición:
- **La anotación vale para la DECLARACIÓN entera**, no sólo para su primera
línea: un valor partido en varias líneas lleva la nota al final. Se comprueban
todas las líneas que abarca la declaración.
- **`strip()` blanquea en el sitio** (sustituye por espacios, conserva los
saltos), así que el cuerpo despojado y el crudo quedan alineados línea a línea
y basta con guardar el crudo al lado.
- Muta-prueba: retirar una anotación de `prose` mueve el knob de `exception` a
`literal` (21 → 20) y el conteo vuelve al restaurarla.
Efecto colateral bueno: cada ficha gana una **§1.4 «Excepciones firmadas»** que
las LISTA con su razón. Estaban escritas en el CSS y no se leían desde ninguna
parte; ahora la ficha del componente las enseña, que es donde se decide si una
sigue siendo cierta.
Las 163 fichas cambian porque la plantilla cambia (sección nueva + la línea de
reparto); el README de la auditoría gana la fila de la clase y la nota de que
`system` y `exception` quedan fuera del denominador.
Guards: `--names` 4.105 claves, DESVIADAS 0 · component-audit PASS · docs:check
0 · `check` con 72 errores globales y 0 en los ficheros tocados.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2 months ago
### 1.4 Excepciones firmadas (0) — fuera del ratio
Literales que llevan su anotación `/* literal: <razón> */` en la propia
declaración: la válvula de recipe-contract §3, la misma que honra
`component-audit` . **Una desviación firmada no es deuda** — se listan para que la
razón se lea, no para acuñarlas.
_Ninguno._
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
## 2. Sistema transversal (1) — informativo, fuera del ratio
docs(theming): la auditoría de alcance de tema, componente a componente, con su propuesta
El censo medía el eje y no lo explicaba: 5.205 knobs en dos tablas del plan no
dicen QUÉ knob de QUÉ línea no alcanza un tema, ni qué token habría que crear.
Ahora `theming-census.ts --report` escribe la auditoría entera bajo
`docs/audit/theming/`: un README con la vista de conjunto y 170 fichas — 162
recetas con CSS + 8 componentes sin receta, el árbol completo de
`eidos/components/`.
Cada ficha de receta: knobs fuera de alcance con fichero:línea Y selector
(agrupados por clase), sistema transversal aparte, los privados con la columna
que decide («¿deriva de un público?»), y una PROPUESTA de corrección — el token
a declarar en `base.ts` con su valor VERBATIM y su scope TSC. La propuesta
deriva los nombres de recipe-contract §1 y theming §6.7; donde la doctrina no
decide, marca `⚠ decisión` en vez de inventar. Y no propone acuñar lo que la
doctrina prohíbe: lo que posee una capa compartida, el foco, la capa de estado,
un token prestado de otra receta, un shorthand o un eje físico.
Las 8 fichas sin receta dicen —medido, no supuesto— dónde vive su visual: el
componente que componen (icon-button → button), la capa que consumen (affix →
viewport-placement) o la receta ajena que pinta sus attrs (svg → badge/button).
Defectos del instrumento corregidos en el mismo pase, todos encontrados
mirando la salida: un `@import` pegado al primer selector se comía 2 knobs de
color-picker (el suelo del censo no puede moverse); `:not(:disabled)` se leía
como estado y producía `hover-disabled-*`; un knob que lee un privado se
proponía a sí mismo en vez de resolverse por talla; `--icon-size-sm` se
reportaba como préstamo del componente `icon` (ahora el préstamo se verifica
contra las claves del dueño en `base.ts`); y el default de talla salía sin
nombrar en vez de `-md`.
Verificación: censo global idéntico al suelo publicado (5205 · 1621/33% · 856 ·
1880 · 614 · 234) y COMPONENTE A COMPONENTE contra la tabla §9 del plan — 0
diferencias en 162 · regenerar dos veces da el árbol idéntico · el bloque de
veredicto escrito a mano sobrevive · docs:check 0 errores sobre 813 docs ·
prettier limpio (el árbol generado entra en .prettierignore junto a
eidos/generated).
Las 10 primeras fichas llevan ya su veredicto de revisión: análisis correcto en
las 10, propuesta apta en 2 (gradient-builder como piloto, combobox con cinco
correcciones — dos de ellas evitaban romper el default), y 5 que no se
tokenizan en solitario porque son alias de --calendar-*/--field-* y esperan la
decisión de familia. Cuatro destaparon privados con prefijo ajeno o abreviado
declarados en su propio CSS.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2 months ago
Un tema los alcanza **a nivel de sistema** , por diseño (recipe-contract §2).
| # | fichero:línea | selector | propiedad | valor |
| ---: | --- | --- | --- | --- |
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
| 1 | `gradient-picker.css:128` | `[data-gradient-picker-preset]:focus-visible` | `outline` | `var(--focus-ring-width) solid var(--focus-ring-color)` |
docs(theming): la auditoría de alcance de tema, componente a componente, con su propuesta
El censo medía el eje y no lo explicaba: 5.205 knobs en dos tablas del plan no
dicen QUÉ knob de QUÉ línea no alcanza un tema, ni qué token habría que crear.
Ahora `theming-census.ts --report` escribe la auditoría entera bajo
`docs/audit/theming/`: un README con la vista de conjunto y 170 fichas — 162
recetas con CSS + 8 componentes sin receta, el árbol completo de
`eidos/components/`.
Cada ficha de receta: knobs fuera de alcance con fichero:línea Y selector
(agrupados por clase), sistema transversal aparte, los privados con la columna
que decide («¿deriva de un público?»), y una PROPUESTA de corrección — el token
a declarar en `base.ts` con su valor VERBATIM y su scope TSC. La propuesta
deriva los nombres de recipe-contract §1 y theming §6.7; donde la doctrina no
decide, marca `⚠ decisión` en vez de inventar. Y no propone acuñar lo que la
doctrina prohíbe: lo que posee una capa compartida, el foco, la capa de estado,
un token prestado de otra receta, un shorthand o un eje físico.
Las 8 fichas sin receta dicen —medido, no supuesto— dónde vive su visual: el
componente que componen (icon-button → button), la capa que consumen (affix →
viewport-placement) o la receta ajena que pinta sus attrs (svg → badge/button).
Defectos del instrumento corregidos en el mismo pase, todos encontrados
mirando la salida: un `@import` pegado al primer selector se comía 2 knobs de
color-picker (el suelo del censo no puede moverse); `:not(:disabled)` se leía
como estado y producía `hover-disabled-*`; un knob que lee un privado se
proponía a sí mismo en vez de resolverse por talla; `--icon-size-sm` se
reportaba como préstamo del componente `icon` (ahora el préstamo se verifica
contra las claves del dueño en `base.ts`); y el default de talla salía sin
nombrar en vez de `-md`.
Verificación: censo global idéntico al suelo publicado (5205 · 1621/33% · 856 ·
1880 · 614 · 234) y COMPONENTE A COMPONENTE contra la tabla §9 del plan — 0
diferencias en 162 · regenerar dos veces da el árbol idéntico · el bloque de
veredicto escrito a mano sobrevive · docs:check 0 errores sobre 813 docs ·
prettier limpio (el árbol generado entra en .prettierignore junto a
eidos/generated).
Las 10 primeras fichas llevan ya su veredicto de revisión: análisis correcto en
las 10, propuesta apta en 2 (gradient-builder como piloto, combobox con cinco
correcciones — dos de ellas evitaban romper el default), y 5 que no se
tokenizan en solitario porque son alias de --calendar-*/--field-* y esperan la
decisión de familia. Cuatro destaparon privados con prefijo ajeno o abreviado
declarados en su propio CSS.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2 months ago
## 3. Privados de la receta — ¿de dónde sale su valor?
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
_La receta no declara privados propios en su CSS._
docs(theming): la auditoría de alcance de tema, componente a componente, con su propuesta
El censo medía el eje y no lo explicaba: 5.205 knobs en dos tablas del plan no
dicen QUÉ knob de QUÉ línea no alcanza un tema, ni qué token habría que crear.
Ahora `theming-census.ts --report` escribe la auditoría entera bajo
`docs/audit/theming/`: un README con la vista de conjunto y 170 fichas — 162
recetas con CSS + 8 componentes sin receta, el árbol completo de
`eidos/components/`.
Cada ficha de receta: knobs fuera de alcance con fichero:línea Y selector
(agrupados por clase), sistema transversal aparte, los privados con la columna
que decide («¿deriva de un público?»), y una PROPUESTA de corrección — el token
a declarar en `base.ts` con su valor VERBATIM y su scope TSC. La propuesta
deriva los nombres de recipe-contract §1 y theming §6.7; donde la doctrina no
decide, marca `⚠ decisión` en vez de inventar. Y no propone acuñar lo que la
doctrina prohíbe: lo que posee una capa compartida, el foco, la capa de estado,
un token prestado de otra receta, un shorthand o un eje físico.
Las 8 fichas sin receta dicen —medido, no supuesto— dónde vive su visual: el
componente que componen (icon-button → button), la capa que consumen (affix →
viewport-placement) o la receta ajena que pinta sus attrs (svg → badge/button).
Defectos del instrumento corregidos en el mismo pase, todos encontrados
mirando la salida: un `@import` pegado al primer selector se comía 2 knobs de
color-picker (el suelo del censo no puede moverse); `:not(:disabled)` se leía
como estado y producía `hover-disabled-*`; un knob que lee un privado se
proponía a sí mismo en vez de resolverse por talla; `--icon-size-sm` se
reportaba como préstamo del componente `icon` (ahora el préstamo se verifica
contra las claves del dueño en `base.ts`); y el default de talla salía sin
nombrar en vez de `-md`.
Verificación: censo global idéntico al suelo publicado (5205 · 1621/33% · 856 ·
1880 · 614 · 234) y COMPONENTE A COMPONENTE contra la tabla §9 del plan — 0
diferencias en 162 · regenerar dos veces da el árbol idéntico · el bloque de
veredicto escrito a mano sobrevive · docs:check 0 errores sobre 813 docs ·
prettier limpio (el árbol generado entra en .prettierignore junto a
eidos/generated).
Las 10 primeras fichas llevan ya su veredicto de revisión: análisis correcto en
las 10, propuesta apta en 2 (gradient-builder como piloto, combobox con cinco
correcciones — dos de ellas evitaban romper el default), y 5 que no se
tokenizan en solitario porque son alias de --calendar-*/--field-* y esperan la
decisión de familia. Cuatro destaparon privados con prefijo ajeno o abreviado
declarados en su propio CSS.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2 months ago
## 4. Propuesta de corrección
- **Consume la capa compartida `picker-shell` .** Un eje que la capa posee se consume como `var(--_x, var(--x))` ; el consumidor **no acuña** `--gradient-picker-{eje}` para él — sería un vocabulario paralelo (README de `eidos/components` , «Capas compartidas» regla 2).
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
### 4.1 Tokens a declarar en `lib/recipes/base.ts` (2)
docs(theming): la auditoría de alcance de tema, componente a componente, con su propuesta
El censo medía el eje y no lo explicaba: 5.205 knobs en dos tablas del plan no
dicen QUÉ knob de QUÉ línea no alcanza un tema, ni qué token habría que crear.
Ahora `theming-census.ts --report` escribe la auditoría entera bajo
`docs/audit/theming/`: un README con la vista de conjunto y 170 fichas — 162
recetas con CSS + 8 componentes sin receta, el árbol completo de
`eidos/components/`.
Cada ficha de receta: knobs fuera de alcance con fichero:línea Y selector
(agrupados por clase), sistema transversal aparte, los privados con la columna
que decide («¿deriva de un público?»), y una PROPUESTA de corrección — el token
a declarar en `base.ts` con su valor VERBATIM y su scope TSC. La propuesta
deriva los nombres de recipe-contract §1 y theming §6.7; donde la doctrina no
decide, marca `⚠ decisión` en vez de inventar. Y no propone acuñar lo que la
doctrina prohíbe: lo que posee una capa compartida, el foco, la capa de estado,
un token prestado de otra receta, un shorthand o un eje físico.
Las 8 fichas sin receta dicen —medido, no supuesto— dónde vive su visual: el
componente que componen (icon-button → button), la capa que consumen (affix →
viewport-placement) o la receta ajena que pinta sus attrs (svg → badge/button).
Defectos del instrumento corregidos en el mismo pase, todos encontrados
mirando la salida: un `@import` pegado al primer selector se comía 2 knobs de
color-picker (el suelo del censo no puede moverse); `:not(:disabled)` se leía
como estado y producía `hover-disabled-*`; un knob que lee un privado se
proponía a sí mismo en vez de resolverse por talla; `--icon-size-sm` se
reportaba como préstamo del componente `icon` (ahora el préstamo se verifica
contra las claves del dueño en `base.ts`); y el default de talla salía sin
nombrar en vez de `-md`.
Verificación: censo global idéntico al suelo publicado (5205 · 1621/33% · 856 ·
1880 · 614 · 234) y COMPONENTE A COMPONENTE contra la tabla §9 del plan — 0
diferencias en 162 · regenerar dos veces da el árbol idéntico · el bloque de
veredicto escrito a mano sobrevive · docs:check 0 errores sobre 813 docs ·
prettier limpio (el árbol generado entra en .prettierignore junto a
eidos/generated).
Las 10 primeras fichas llevan ya su veredicto de revisión: análisis correcto en
las 10, propuesta apta en 2 (gradient-builder como piloto, combobox con cinco
correcciones — dos de ellas evitaban romper el default), y 5 que no se
tokenizan en solitario porque son alias de --calendar-*/--field-* y esperan la
decisión de familia. Cuatro destaparon privados con prefijo ajeno o abreviado
declarados en su propio CSS.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2 months ago
Valor **verbatim** del CSS de hoy: el default no se mueve, sólo cambia quién
puede moverlo. Nombres derivados de recipe-contract §1 (ejes lógicos, talla
al final) y theming §6.7 (slots de color, modificador delante). Un token con
DOS valores distintos es una colisión de nombre: son dos knobs, o el nombre
no distingue lo que debería — se marca `⚠` .
| token (`--gradient-picker-…`) | scope TSC | valor propuesto | usos |
| --- | --- | --- | ---: |
| `bg` | `root` | `var(--gp-current-gradient, transparent)` | 1 |
| `value-swatch-bg` | `root` | `var(--gp-current-gradient, transparent)` | 1 |
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
### 4.2 Sin nombre mecánico (1)
docs(theming): la auditoría de alcance de tema, componente a componente, con su propuesta
El censo medía el eje y no lo explicaba: 5.205 knobs en dos tablas del plan no
dicen QUÉ knob de QUÉ línea no alcanza un tema, ni qué token habría que crear.
Ahora `theming-census.ts --report` escribe la auditoría entera bajo
`docs/audit/theming/`: un README con la vista de conjunto y 170 fichas — 162
recetas con CSS + 8 componentes sin receta, el árbol completo de
`eidos/components/`.
Cada ficha de receta: knobs fuera de alcance con fichero:línea Y selector
(agrupados por clase), sistema transversal aparte, los privados con la columna
que decide («¿deriva de un público?»), y una PROPUESTA de corrección — el token
a declarar en `base.ts` con su valor VERBATIM y su scope TSC. La propuesta
deriva los nombres de recipe-contract §1 y theming §6.7; donde la doctrina no
decide, marca `⚠ decisión` en vez de inventar. Y no propone acuñar lo que la
doctrina prohíbe: lo que posee una capa compartida, el foco, la capa de estado,
un token prestado de otra receta, un shorthand o un eje físico.
Las 8 fichas sin receta dicen —medido, no supuesto— dónde vive su visual: el
componente que componen (icon-button → button), la capa que consumen (affix →
viewport-placement) o la receta ajena que pinta sus attrs (svg → badge/button).
Defectos del instrumento corregidos en el mismo pase, todos encontrados
mirando la salida: un `@import` pegado al primer selector se comía 2 knobs de
color-picker (el suelo del censo no puede moverse); `:not(:disabled)` se leía
como estado y producía `hover-disabled-*`; un knob que lee un privado se
proponía a sí mismo en vez de resolverse por talla; `--icon-size-sm` se
reportaba como préstamo del componente `icon` (ahora el préstamo se verifica
contra las claves del dueño en `base.ts`); y el default de talla salía sin
nombrar en vez de `-md`.
Verificación: censo global idéntico al suelo publicado (5205 · 1621/33% · 856 ·
1880 · 614 · 234) y COMPONENTE A COMPONENTE contra la tabla §9 del plan — 0
diferencias en 162 · regenerar dos veces da el árbol idéntico · el bloque de
veredicto escrito a mano sobrevive · docs:check 0 errores sobre 813 docs ·
prettier limpio (el árbol generado entra en .prettierignore junto a
eidos/generated).
Las 10 primeras fichas llevan ya su veredicto de revisión: análisis correcto en
las 10, propuesta apta en 2 (gradient-builder como piloto, combobox con cinco
correcciones — dos de ellas evitaban romper el default), y 5 que no se
tokenizan en solitario porque son alias de --calendar-*/--field-* y esperan la
decisión de familia. Cuatro destaparon privados con prefijo ajeno o abreviado
declarados en su propio CSS.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2 months ago
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
- **⚠ decisión: `100%` es un valor identidad o geometría de layout, no un knob de tema — el perímetro de «knob» es D-TH.2, sin firmar** — 1: `inline-size` .
docs(theming): la auditoría de alcance de tema, componente a componente, con su propuesta
El censo medía el eje y no lo explicaba: 5.205 knobs en dos tablas del plan no
dicen QUÉ knob de QUÉ línea no alcanza un tema, ni qué token habría que crear.
Ahora `theming-census.ts --report` escribe la auditoría entera bajo
`docs/audit/theming/`: un README con la vista de conjunto y 170 fichas — 162
recetas con CSS + 8 componentes sin receta, el árbol completo de
`eidos/components/`.
Cada ficha de receta: knobs fuera de alcance con fichero:línea Y selector
(agrupados por clase), sistema transversal aparte, los privados con la columna
que decide («¿deriva de un público?»), y una PROPUESTA de corrección — el token
a declarar en `base.ts` con su valor VERBATIM y su scope TSC. La propuesta
deriva los nombres de recipe-contract §1 y theming §6.7; donde la doctrina no
decide, marca `⚠ decisión` en vez de inventar. Y no propone acuñar lo que la
doctrina prohíbe: lo que posee una capa compartida, el foco, la capa de estado,
un token prestado de otra receta, un shorthand o un eje físico.
Las 8 fichas sin receta dicen —medido, no supuesto— dónde vive su visual: el
componente que componen (icon-button → button), la capa que consumen (affix →
viewport-placement) o la receta ajena que pinta sus attrs (svg → badge/button).
Defectos del instrumento corregidos en el mismo pase, todos encontrados
mirando la salida: un `@import` pegado al primer selector se comía 2 knobs de
color-picker (el suelo del censo no puede moverse); `:not(:disabled)` se leía
como estado y producía `hover-disabled-*`; un knob que lee un privado se
proponía a sí mismo en vez de resolverse por talla; `--icon-size-sm` se
reportaba como préstamo del componente `icon` (ahora el préstamo se verifica
contra las claves del dueño en `base.ts`); y el default de talla salía sin
nombrar en vez de `-md`.
Verificación: censo global idéntico al suelo publicado (5205 · 1621/33% · 856 ·
1880 · 614 · 234) y COMPONENTE A COMPONENTE contra la tabla §9 del plan — 0
diferencias en 162 · regenerar dos veces da el árbol idéntico · el bloque de
veredicto escrito a mano sobrevive · docs:check 0 errores sobre 813 docs ·
prettier limpio (el árbol generado entra en .prettierignore junto a
eidos/generated).
Las 10 primeras fichas llevan ya su veredicto de revisión: análisis correcto en
las 10, propuesta apta en 2 (gradient-builder como piloto, combobox con cinco
correcciones — dos de ellas evitaban romper el default), y 5 que no se
tokenizan en solitario porque son alias de --calendar-*/--field-* y esperan la
decisión de familia. Cuatro destaparon privados con prefijo ajeno o abreviado
declarados en su propio CSS.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2 months ago
### 4.4 Lo que hay que comprobar a mano (PLAN-theming §1.3 · §7.4)
- [ ] **Privado que no deriva de un público** — §3 lo marca; el privado debe leer el público o desaparecer.
- [ ] **Velo o acento en el nodo equivocado** (`archetype: 'item'` en un envoltorio, un `background` en shorthand que mata la capa de estado) — se mide desde el píxel hacia arriba.
- [ ] **Doble animación** al mover un sello a una superficie con animación propia — registro de `animationstart` /`animationend`.
- [ ] **Diff de computed = 0** en reposo · hover · abierto · disabled · foco, por talla, antes y después.
- [ ] **Centinela por token nuevo** : valor imposible en el root → el nodo lo sigue. Si no, el token miente.
## 5. Veredicto
<!-- veredicto:start -->
docs(theming): revisadas las fichas 11-20 — veredicto verificado y corregido en cada una
Segunda tanda de revisión del eje theme-reach: command, table, media-player,
tree-grid, field-langs, gradient-picker, listbox, carousel, heading y feed.
Cifras reproducidas en las diez; la corrección va escrita en el bloque de
veredicto de cada ficha, que sobrevive a la regeneración.
Lo que la verificación cambió del plan mecánico:
- Tres «colisiones» no eran colisiones: el radio de command es ADAPTACIÓN al
Dialog que lo hospeda (lee un público de dialog, legítimo); el ancho del
panel de gradient-picker es POR TALLA (20/18/22rem); y el título de feed son
las redeclaraciones por talla de su propio privado.
- Dos nombres mecánicos estaban mal: el `root-height` de table es la FILA
(row-height, al bundle), y el `root-bg-image` de tree-grid son las GUÍAS de
indentación — el knob es un color (`guide-color`), los cinco gradientes son
de la receta.
- Dos prefijos más de la misma plaga: media-player declara `--_mp-*` (el censo
lo cuenta global) y field-langs `--_fls-*` — que además lee un privado DE
FIELD con la fórmula del label un paso por debajo, sólo resoluble anidado:
eso va al mandato field-composition, no se copia congelado. Y gradient-picker
estampa `--gp-current-gradient` inline: mismo renombrado que gb.
- Una regla de capa a punto de romperse: la propuesta de listbox acuñaba
`font-size = var(--list-font-size)`, que es un público DE LA CAPA
list-surface — duplicarlo es el vocabulario paralelo que la propia nota
prohíbe. Retirada.
- Y una lectura equivocada del 0 %: heading NO tiene deuda — es el primitivo
tipográfico consumiendo la capa de named styles, que ES su superficie de
tema (applyTypeScale la retunea en vivo). Acuñar --heading-* sería el alias
por eje×nivel que la purga del §39 mató. Disposición propuesta: medir
--style-* como sistema transversal para los primitivos tipográficos —
decisión D-TH.2, y aplica a toda la familia B5.
media-player trae además contexto que la propuesta ignoraba: su acento ya está
firmado en el propio bloque de recetas como theme-stable (una escala cruda a
propósito, para leerse sobre cualquier vídeo) — no se «corrige» a un rol.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2 months ago
**Revisión 2026-08-20 — verificación previa a implementación (Opus).**
**Análisis: CORRECTO** (38 · 0 · 7 · 23 · 5 · 3). Consume `picker-shell` ✓ (no
acuñar lo que la capa posee). Hallazgo de prefijo, cuarto de la familia: el
trigger estampa ** `--gp-current-gradient` inline** desde el wrapper
(`gradient-picker-trigger.svelte:4`) — abreviatura contra la regla 5.
**Renombrar a `--_gradient-picker-current-gradient` ** (wrapper + receta), el
mismo tratamiento que `--gb-stop-fill` en gradient-builder.
**Propuesta: APTA CON DOS CORRECCIONES.**
1. **El ⚠ de `content-width` NO es colisión — es POR TALLA** (20/18/22rem son
md/sm/lg): coordenadas `content-width-{sm,md,lg}` verbatim + resuelto
`content-width` (si el content viaja por portal, con `parts` — verificar
dónde estampa la talla el panel; el root sí la lleva).
2. **Forma por talla en el trigger** : `trigger-height-{k}` a la coordenada del
bundle (`--size-{k}-control-height`, computed idéntico);
`trigger-padding-inline-{k}` VERBATIM (sm=space-2 casa con el bundle pero
md=2-5 y lg=3 DESVÍAN — mantener el valor de hoy, desviación visible);
`trigger-font-size-{k}` al bundle. Todo con su resuelto `host` +`size:{k}`.
Gemelo funcional de `gradient-builder` (el piloto): puede seguir su commit
paso a paso, incluido el guard de claves duplicadas en `base.ts` y el
centinela con el popup abierto.
**Bloqueos de firma**: ninguno duro.
docs(theming): la auditoría de alcance de tema, componente a componente, con su propuesta
El censo medía el eje y no lo explicaba: 5.205 knobs en dos tablas del plan no
dicen QUÉ knob de QUÉ línea no alcanza un tema, ni qué token habría que crear.
Ahora `theming-census.ts --report` escribe la auditoría entera bajo
`docs/audit/theming/`: un README con la vista de conjunto y 170 fichas — 162
recetas con CSS + 8 componentes sin receta, el árbol completo de
`eidos/components/`.
Cada ficha de receta: knobs fuera de alcance con fichero:línea Y selector
(agrupados por clase), sistema transversal aparte, los privados con la columna
que decide («¿deriva de un público?»), y una PROPUESTA de corrección — el token
a declarar en `base.ts` con su valor VERBATIM y su scope TSC. La propuesta
deriva los nombres de recipe-contract §1 y theming §6.7; donde la doctrina no
decide, marca `⚠ decisión` en vez de inventar. Y no propone acuñar lo que la
doctrina prohíbe: lo que posee una capa compartida, el foco, la capa de estado,
un token prestado de otra receta, un shorthand o un eje físico.
Las 8 fichas sin receta dicen —medido, no supuesto— dónde vive su visual: el
componente que componen (icon-button → button), la capa que consumen (affix →
viewport-placement) o la receta ajena que pinta sus attrs (svg → badge/button).
Defectos del instrumento corregidos en el mismo pase, todos encontrados
mirando la salida: un `@import` pegado al primer selector se comía 2 knobs de
color-picker (el suelo del censo no puede moverse); `:not(:disabled)` se leía
como estado y producía `hover-disabled-*`; un knob que lee un privado se
proponía a sí mismo en vez de resolverse por talla; `--icon-size-sm` se
reportaba como préstamo del componente `icon` (ahora el préstamo se verifica
contra las claves del dueño en `base.ts`); y el default de talla salía sin
nombrar en vez de `-md`.
Verificación: censo global idéntico al suelo publicado (5205 · 1621/33% · 856 ·
1880 · 614 · 234) y COMPONENTE A COMPONENTE contra la tabla §9 del plan — 0
diferencias en 162 · regenerar dos veces da el árbol idéntico · el bloque de
veredicto escrito a mano sobrevive · docs:check 0 errores sobre 813 docs ·
prettier limpio (el árbol generado entra en .prettierignore junto a
eidos/generated).
Las 10 primeras fichas llevan ya su veredicto de revisión: análisis correcto en
las 10, propuesta apta en 2 (gradient-builder como piloto, combobox con cinco
correcciones — dos de ellas evitaban romper el default), y 5 que no se
tokenizan en solitario porque son alias de --calendar-*/--field-* y esperan la
decisión de familia. Cuatro destaparon privados con prefijo ajeno o abreviado
declarados en su propio CSS.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2 months ago
<!-- veredicto:end -->
