12 Commits (f5f2b5d225dbb25e73f2d17a45d278e31bead4a6)

Author	SHA1	Message	Date
dev	f5f2b5d225	docs(theming): el handoff, reescrito para que otra sesión arranque sin arqueología ... La sesión llega llena. El handoff había crecido por acumulación —cada bloque añadía su sección— y para saber qué hacer había que leerlo entero y deducirlo. Ahora la AGENDA va arriba y el registro histórico abajo, separado por su propio encabezado. Arriba: qué comprobar en los primeros cinco minutos (las dos cifras que deben cuadrar, el dev server antes de medir, leer el veredicto §5); tres opciones con recomendación —revisión adversarial de F2-A, el diseño de `calendar-surface`, o seguir la cola por alcance, con la cola ya recalculada—; el protocolo en diez pasos; y **lo que este bloque enseñó**, que es lo que evita repetir el día: el veredicto orienta pero la medición decide (tres de ocho tenían un error de lectura) · un token que no mueve nada miente, y lo que procede es retirar la declaración muerta · un alias puro se borra, no se renombra · lo que la capa posee el consumidor no lo acuña · y la sonda miente de tres maneras distintas, así que ante un diff inesperado se corre DOS VECES sobre el mismo código antes de sospechar del cambio. El plan §8 gana la entrada de la sesión con las cifras y los commits, y su cabecera de estado pasa a 43 %. Estado que hereda la sesión siguiente: alcance global 43 % (era 33 % al abrir el eje), 15 componentes con contrato, 49 sin él, 7 al 100 %, gramática con 0 desviadas y guard en `error`. 29 commits, sin pushear. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
dev	5596fc8707	docs(next-features): el registro de incidencias del eje theme-reach ... Encargo del autor: anotar todas las incidencias de esta clase para resolverlas después. Van al registro canónico (`next-features.md`), no a un sitio nuevo, y con su MEDICIÓN — no como impresión. **§12 — El contrato de cascada del velo de estado.** Seis incidencias que resultaron ser la misma: nadie fijó nunca cómo compone el velo de `archetypes.css` con las reglas de una receta. Y la raíz explica por qué se manifiestan de formas tan distintas: el velo se pinta con DOS pesos según el arquetipo — `:where()` (0,0,0) para `trigger`, especificidad plena (0,5,0) para `item`/`option`. 131 declaraciones-atajo en 45 componentes cancelan el velo (66 BASE · 32 ACENTO · 23 HOVER · 10 OTRA; cero valores con gradiente, así que el paso a longhand no tiene riesgo técnico; 32 nodos velados que hoy no reaccionan al ratón pasarían a hacerlo) · la prop `hoverable` de table no suprime nada · en tree-grid el empate (0,5,0) lo decide el ORDEN DE CARGA y varía entre recargas · la banda de tree-grid mata el hover en las filas pares · un token de tinta no puede ganar al arquetipo (`selected-row-fg` se retiró por eso) · el thumb de scroll-area no tiene velo al que migrar. Esto explica de paso la adopción 21/135 que midió la auditoría del 2026-07-01: el velo estaba escrito y estructuralmente derrotado. **§13 — Huecos de instrumento y de demo.** Lo que hizo que una medición mintiera o no existiera, que importa porque el eje entero se apoya en ellas: falsos negativos del centinela sobre propiedades transicionadas, pseudo-elementos y componentes compuestos que no ve, la sonda que no pasa el ratón por un `<tr>`, y la lección general —**una sonda sobre una parte que la demo no monta compara CERO valores y pasa**—, con la lista de partes condicionales afectadas. El handoff gana la regla para las sesiones del eje: si una incidencia mueve píxel o toca morfo, se mide, se anota ahí y se sigue; no se arregla dentro del commit del componente. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
dev	8324e2cedb	docs(theming): partir recipes/base.ts, al terminar el eje entero ... Pregunta del autor: por qué los tokens de 128 componentes viven en un fichero de 6.223 líneas y no junto a su componente. La respuesta medida: NO es un fichero de tokens, es el valor del campo `recipes` de `EidosConfig` —serializable, que un tema hidrata—, y por eso los valores no pueden mudarse a `components/{x}/`: ya se intentó y se retiró («The old `tokens/components/*` were retired»). Lo que sí puede repartirse es la AUTORÍA, con un fichero por componente que `base.ts` compone. Verificado antes de proponerlo: el muro de tipos de `defineRecipes` sigue disparando cuando las claves llegan por spread desde un fichero suelto — probado con `trigger-color` y `padding-x`, ambas siguen sin compilar. Y el único consumidor sensible a la forma (`eidos-purge`, que hace `Object.keys()`) es indiferente. Va al final de TODO el themeable, no al cerrar el bloque: mientras quede un componente por tokenizar, ese fichero se toca en cada commit, y mover 6.000 líneas en medio garantiza conflicto con cualquier sesión que esté trabajando. Los tres costes que justifican hacerlo se midieron hoy: casi entra un SEGUNDO bloque `table` que el catálogo habría descartado en silencio, una coma perdida rompió el catálogo entero dos veces, y es el punto de conflicto de todas las sesiones concurrentes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
dev	b43e7e2ec0	docs(theming): el tab Tokens entra en el protocolo del bloque ... Cada componente que se tokenice engancha su tab en el mismo commit — una línea, porque el panel lee el contrato vivo y no hay tabla que mantener. `command` queda marcado como cerrado en la tabla del bloque. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
dev	5ee796fa98	docs(theming): el bloque F2-A preparado — ocho componentes, sus defectos y sus gates ... La cola revisada se eleva a plan de bloque: pieza 0 de instrumento (D-TH.2-b: la familia tipográfica mide por --style-* — va primero porque cambia el suelo del censo), los ocho componentes con sus defectos MEDIDOS (censo) y la corrección que su veredicto §5 ya verificó contra el CSS, los gates de §7 por componente, y la revisión adversarial al cierre. 330 knobs hoy a 0 %; el bloque debe llevar el global de 37 % a ~42 %. Y al cerrarlo, el orden de lo que las firmas desbloquearon: el diseño de calendar-surface (220 knobs más), el mandato Field, y el resto de B1-B8. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
dev	d27e2ac9fc	docs(theming): la firma 3 al día — y el atajo que llevaba dos meses ganando ... Cuatro componentes migrados con su medición, y el diagnóstico que cambió al ejecutar: el velo del sistema no llegaba a ninguno, y la culpa no era del hover propio sino de la regla base — el atajo `background:` pesa (0,1,0) contra el `:where()` (0,0,0) de archetypes.css y fija `background-image: none` para siempre. Queda escrito lo que NO he hecho y por qué: scroll-area pide decisión de morfo (su thumb no lleva arquetipo con velo), el barrido de las otras 141 declaraciones no entra en una firma que se dio sobre knobs concretos, y la demo del date-range-picker no monta `kind`, así que su overview no se puede medir. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
dev	e154b23fb9	docs(theming): el handoff al día — el bloque del vocabulario, cerrado ... Los cuatro pasos hechos, con sus commits, y lo único que queda del bloque: el tercer muro (el tipo de `defineRecipes`) espera a que la migración a la capa de estado vacíe las 17 claves de hover neutro que todavía dicen `color`. Y las cuatro cosas que el bloque enseñó a base de costar vueltas: el plan se escribe antes de tocar nada o el verificador mide el vacío; un valor puede cambiar de texto sin cambiar de significado; prettier en masa reformatea deriva ajena (88 de 101 ficheros ya salían sucios por el CRLF del checkout); y un hover se clasifica por su VALOR, nunca por su nombre — cosa que este mismo handoff tenía mal. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
dev	f09e04fab1	docs(theming): el acta — las catorce decisiones que faltaban, firmadas ... El eje llevaba desde el 19 ejecutando sólo lo que no dependía de una firma. Hoy se presentaron las catorce con recomendación fundada y el autor las firmó en bloque. Quedan escritas donde se ejecutan: §4 del plan fila a fila, y una sección de acta en el handoff con el QUÉ ejecutable de cada una. La que cambió de sentido al presentarla fue D-TH.6. La pregunta no era «normalizar hacia lo documentado» sino una CONTRADICCIÓN entre dos doctrinas firmadas: theming §6.7 r7 dice que el slot de tinta es `fg`; el principio de plataforma del codemod px/py («el token se llama como la propiedad») dice `color`. Se adjudicó `fg`, y con una razón que acota el principio en vez de romperlo: gobierna los ejes DIMENSIONALES, no la pareja `bg`/`fg` — si la gobernara, `bg` tendría que llamarse `background-color`, y nadie lo propone. De la misma lectura salió que el inventario heredado estaba inflado: de las 370 claves «desviadas», 47 son `{rol}-{slot-de-rol}` (`primary-solid-hover`, `palette-hover`) donde COLOR_ROLE_SLOTS pone el modificador detrás POR CONSTRUCCIÓN. Un codemod sobre las 370 las habría roto — `button` entero. El inventario real es 301, y la gramática es POR FAMILIA, no única. Los 22 «falsos amigos» resultaron ser tres cosas distintas: los que se quedan (la familia del sistema `--focus-ring-*`, el color como sustantivo de `aura`, y `stop-color` que ES una parte de gradient-builder), los que el morfo ya resuelve (`partial`, `read`, `failed` son valores declarados de `data-state` y `data-delivery`), y los dos `scrim-color-on-*`, que chocaban con el prefijo canónico `on-` del acento y pasan a `scrim-fg-over-*`. Y una que no era limpieza sino decisión: los hovers neutros NO se renombran, MIGRAN a la capa de estado (§38 + R-4.3). Renombrarlos habría presumido que sobreviven. Con las firmas, la revisión de los 7 componentes ya corregidos contra la gramática nueva: 6 limpios y una corrección (`gradient-builder.checker-color` → `checker-fg`), que entra en el codemod. Que salgan limpios no es suerte — el backfill de este eje ya venía escribiendo `fg`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
dev	51122efa32	docs(theming): mañana lo primero — el vocabulario de tokens: D-TH.6 (codemod) y R-5.3 (guard de gramática) ... La conversación de hoy destapó que el backfill está escribiendo canon sobre un catálogo que habla al revés: el vocabulario de nombres existe (theming §6.7 + recipe-contract §1) pero no tiene guard, y la medición fundacional del 2026-07-01 ya dijo lo que le pasa a un canon defendido por prosa. Medido ahora con `scripts/__names-inventory.ts` (semilla del `--names` del censo): sobre 3.333 claves públicas hay 370 desviadas en 68 componentes — 125 con el modificador detrás, 215 con `color` como slot o segmento, 30 con ambas. Y dos falsos amigos que NO se renombran de oficio: `*-focus-ring-color` espeja la familia del sistema, y los `orb-color-*` de aura usan color como sustantivo. El handoff pone el bloque como primera tarea, con el orden que evita el error clásico: primero la FIRMA (D-TH.6, una decisión con el inventario delante), luego el codemod value-preserving con el triple muro del precedente px/py (renombres 1:1 en generated, censo idéntico, computed intacto en tres sondas), y sólo entonces el guard — R-5.3 como gramática y no como lista, porque el vocabulario de tokens es compositivo donde el de eventos era cerrado: la talla contra las siete canónicas, el modificador cerrado y delante, el slot contra sus tres fuentes, y la parte contra el morfo compilado como ya hace eidos-lint. En `error` directo: tras el codemod no hay deuda que tolerar, y la rampa warn es como estos guards mueren. Con muta-prueba antes de darlo por bueno. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
dev	35216b591c	fix(natural-time-picker): la anotación del literal volvió a su línea — prettier la había separado del valor ... Regresión mía de ayer, cazada por el guard al preguntar si los nombres pasan por el canon. Al renombrar los privados abreviados a su nombre completo, tres declaraciones cruzaron el ancho de línea y prettier las partió en varias; la anotación que las justifica quedó en otra línea, y R-2.1 la exige en LA MISMA. Resultado: un componente que estaba en PASS pasó a NEEDS-WORK con tres colores crudos donde en realidad hay tres excepciones anotadas de tono fijo. Se arregla con `prettier-ignore` sobre cada declaración, que es lo único que no toca lo que importa: ni se acorta el comentario que documenta por qué el color es fijo, ni se cambia el valor. El diff de computed sigue vacío (6.438 valores, ocho estados) y el componente vuelve a PASS. La lección va al handoff, porque el error no fue el rename sino el ORDEN de la verificación: correr `component:audit` antes del formateo final deja pasar exactamente esta clase de regresión. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
dev	a9b9711657	docs(theming): handoff del eje al día — cola revisada, firmas pendientes y el instrumental que las verifica ... El eje deja de ser «plan entregado» y pasa a «en ejecución»: siete componentes corregidos, veinte fichas revisadas y el informe vivo. El handoff y el registro del plan lo dicen con cifras y commits, para que mañana se entre por la ficha y no por la memoria de nadie. `CONTINUE-theming.md` se reescribe con lo que hace falta para continuar: la cola inmediata de ocho componentes EJECUTABLES sin firma —cada uno con la trampa concreta que su veredicto ya destapó—, la lista de lo que ESPERA firma (familia calendar, mandato de Field, el perímetro del knob para la familia tipográfica, el hover a la capa de estado) y la tabla de lo ejecutado con su censo antes → después. El plan gana su §8 con el registro completo y corrige su cabecera, que seguía diciendo que no había nada construido. Y se commitea el instrumental, porque sin él el protocolo §7 es una intención: la sonda de computed antes/después, el diff que es el gate (vacío o se para), el centinela que pregunta si cada token alcanza de verdad, y la captura del stage. Se ejecutan con `node` a secas —el loader de tsx inyecta helpers que no existen dentro de `page.evaluate` y toda sonda revienta—, desde la raíz y contra el dev server. Lo que el instrumento aprendió a fuerza de mentir queda escrito donde se consulta: congelar `transition` pero NUNCA `animation` (Presence necesita el `animationend` para montar el panel, y si lo congelas mides un popup que no existe); un token resuelto no se mueve desde `:root` por diseño; un panel portalado no ve el ámbito del componente; la demo puede tapar el componente que mides; y un valor centinela igual al real se lee como «no efecto». Igual las cuatro trampas que costaron un commit cada una, con su guard al lado: la clave duplicada en `recipes/base.ts` que descarta el bloque en silencio, los bloques `[data-size]` del CSS que sobreviven a la cascada del TSC y hacen que el diff dé cero por la ruta vieja, los backticks en `node -e` desde bash, y el encabezado que un Edit se come al insertar una sección. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago
dev	07a99679d7	docs(theming): el plan del eje theme-reach — medir qué alcanza un tema, y corregir componente a componente ... El autor, al ver que el radio del trigger del nav vivía en un privado clavado a --radius-default: «¿los componentes son themables? si no lo son, es un error como framework». Lo es. La doctrina ya exige que cada receta declare sus knobs en recipes/base.ts (recipe-contract §1, theming §6), pero R-1…R-4 sólo comprueban «sin literales», no «alcanzable por un tema»: una receta con todo en var(--radius-md) y privados pasa component:audit en PASS y sólo se puede temar moviendo el sistema entero. Medido, no opinado — scripts/theming-census.ts (instrumento, NO guard): de 5.205 knobs de apariencia en 162 recetas, 1.621 (33 %) pasan por un token público del componente; 1.880 atan directo a un primitivo global, 856 a privados, 614 son literales; 62 componentes no tienen una sola entrada en el contrato; 59 tienen alcance < 20 %; 6 al 100 %. navigation-menu, tras todo el día de hoy, 44 %. El plan (PLAN-theming.md): §1 el censo por familia y por componente (tabla regenerable, no editable) · §2 los cuatro ejes de «personalizable» (tokens · talla · color/variante · estados) · §3 la regla R-5 «alcance de tema» para component-audit, con su válvula de excepción · §4 ocho decisiones D-TH para el autor (R-5 dura · perímetro de knob · WIP · orden · DEFAULT IDÉNTICO · normalizar nombres de slot, que hoy incumplen tabs y el propio nav · cuándo gradúa a error · panel de temas) · §5 fases F0–F4 con gates · §6 deuda transversal · §7 el PROTOCOLO DE VERIFICACIÓN por componente, porque «lo ejecutará Opus, y Opus falla mucho»: cinco preguntas, medir ANTES (computed por parte/estado/talla, sonda headless desde la raíz, fuera de callbacks de MutationObserver), editar sólo la forma firmada, medir DESPUÉS (diff de computed = 0, prueba de CENTINELA por cada token nuevo, desde el píxel hacia arriba, registro de animationstart/end), guards por fichero, un componente = un commit con sus artefactos, y revisión adversarial por bloque. Cada paso tiene un artefacto; sin artefacto no está hecho. El instrumento se probó por mutación antes de creerle, y falló la primera vez: no contaba una regla de una sola línea (`[x] { padding-inline: 8px; }`), así que meter un literal no movía la cifra. Regex endurecido; ahora 6→7→8 con una y dos mutaciones. Las cifras del plan son las del instrumento final, y el handoff (CONTINUE-theming.md) obliga a reproducirlas antes de seguir. Nada firmado, nada construido. Gates del commit: docs:check 0/642 · prettier del script limpio · tsc del script sin errores · el plan cita ficheros que existen (los once, comprobados). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2 months ago