astra
alpha-0.1-background
alpha-0.1-dir-prefs
alpha-0.1-sec-dom
menubar-v4-safe
active-uix
morfo-runtime
morfo-driven-soma
semantuix
glm-5
main
sium-v1.0
${ noResults }
2058 Commits (ab64efee778cf66b0f977d0f8652e93150a9f8e3)
| Author | SHA1 | Message | Date |
|---|---|---|---|
 dev
|
3219a19c3c |
fix(switch): el velo para el off, el swap de paleta para el checked
Firma 3, tercer componente, y el primero donde la regla servía DOS hovers a la
vez: `--_switch-track-bg-hover` resolvía al color neutro cuando el switch está
off y al `palette-solid-hover` cuando está checked. recipe-contract §2 los
separa —el neutro es la capa del sistema, el con valencia es el swap de la
receta— así que la regla se parte en dos:
`[data-switch]:hover` sólo el borde; el fondo lo pone
el velo de archetypes.css
`[data-switch][data-state=checked]:hover` `background-color:
var(--_switch-palette-solid-hover)`
Y la regla base pasa a `background-color:` por lo mismo de siempre: el atajo
fijaba `background-image: none` y ganaba al `:where()` del sistema.
Medido (377 valores, 7 estados): 2 diffs, los dos en el hover del track off —
el velo aparece y el fondo vuelve a su base. Verificado además en el navegador
que las DOS reglas viven y que el swap del checked sigue en pie.
`track-bg-off-hover` sale del contrato, y con él el privado que lo reenviaba.
censo switch 57 % · audit PASS · suite 434 (1 rojo conocido)
Nota de método: borrar la clave por línea partió una declaración multilínea
(clave y valor en líneas distintas) y dejó el valor huérfano — esbuild lo cazó
al regenerar. Un rename en sitio es seguro; un borrado necesita mirar si el
valor va debajo.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2 months ago |
|
dev
|
c66b738101 |
fix(splitter): el asa recupera el velo del sistema
Firma 3, segundo componente, y la misma pareja de causas que el checkbox: el asa lleva `archetype: 'trigger'`, así que `archetypes.css` le pinta el velo, pero la regla base declaraba el ATAJO `background:` (0,1,0) y lo cancelaba contra el `:where()` (0,0,0) del sistema. Encima había un hover propio con su propio color. regla base `background:` → `background-color:` regla hover fuera entera; el velo la sustituye Medido (812 valores, 7 estados): 2 diffs, ambos en el hover del asa — `bg oklch(0.8853) → oklch(0.931)` y `img none → linear-gradient(rgb(0 0 0 / 0.08))`. Reposo, tallas, dragging, disabled y foco: idénticos. El estado `dragging` conserva su acento (`--splitter-active-handle-bg`), que es un hover CON VALENCIA y no le toca la capa neutra. `handle-bg-hover` sale del contrato: sin consumidores. censo splitter 100 % · audit PASS · suite 434 (1 rojo conocido) Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
2 months ago |
|
dev
|
b35855c20d |
fix(checkbox): el velo del sistema vuelve a pintar — y el atajo era el culpable
Firma 3, primer componente. El checkbox tenía un hover propio
(`bg-off-hover`, un `color-mix` del surface al 82 %) de los que §38 deprecó, y
al quitarlo apareció que el velo del sistema no volvía. La causa no era el
hover: era la regla BASE.
`[data-checkbox] { background: var(--checkbox-bg-off) }` usa el ATAJO, que fija
`background-image: none`, y esa regla pesa (0,1,0) contra el `:where()` de
`archetypes.css`, que pesa (0,0,0). El velo perdía la cascada SIEMPRE — no en
hover, nunca. El hover bespoke no era un capricho: era la cicatriz de que el
velo del sistema no llegaba, y con él delante nadie lo notó.
Dos cambios, uno por causa:
regla base `background:` → `background-color:` (longhand), que deja libre
`background-image` para el velo
regla hover fuera el `background` propio; queda el `border-color`, que es
otro eje y otra decisión
Medido en el navegador (sonda de computed, 2.436 valores en 7 estados):
antes hover bg `srgb 0.974` · img `none` ← el velo, ausente
después hover bg `oklch(0.9911)` · img `linear-gradient(rgb(0 0 0 / 0.08))`
reposo intacto · tallas intactas · disabled intacto · foco intacto
8 diffs, todos en el hover y sólo en esas dos propiedades. El hover queda algo
MÁS visible que antes (0.911 efectivo contra 0.974): es la calibración del
sistema, que es justamente lo que la firma perseguía.
`bg-off-hover` sale del contrato: sin consumidores, y un alias público que
nadie consume rompe `recipe-css-contract`.
censo checkbox 47 % · audit PASS · eidos-lint 0 invalid · suite 434 (1 rojo
conocido) · rtl 0 · docs 0
No adjunto captura: el panel del navegador no está visible en esta sesión y el
screenshot expira. La evidencia es la medición de computed sobre Chromium real.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2 months ago |
|
dev
|
476da2dd23 |
feat(eidos): el tercer muro — `color` como slot deja de compilar
Cierra el triple muro de D-TH.6, con el mismo molde que la normalización px/py del 2026-07-06: el codemod vacía la deuda, R-5.3 la vigila al correr el audit, y el tipo la impide mientras escribes. El muro de tipos es el único que no necesita que nadie ejecute nada. Ayer no podía entrar: disparaba sobre 17 claves de hover neutro que todavía decían `color`. El commit anterior las renombró al descubrir que no eran capa de estado, así que ahora el catálogo compila limpio y el muro sube. Las tres exenciones firmadas van DELETREADAS, no encajadas en un patrón laxo —una exención que no se puede leer es una que nadie puede auditar—: `*-focus-ring-color` (espeja la familia del sistema), `orb-color-*` (color como sustantivo) y `stop-color-*` (una parte de gradient-builder). Muta-prueba: `mutant-trigger-color` → NO COMPILA, con el mensaje que enseña la regla las tres exenciones → compilan catálogo actual → 0 errores en recipes Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
2 months ago |
|
dev
|
93017975ca |
fix(eidos): la capa de estado es un VELO — 38 hovers que no lo eran, al idioma
El codemod de ayer apartó 47 knobs «en cola de migración a la capa de estado».
Al empezar esa migración se ve que sólo SEIS lo estaban: el velo de §38 es
`background-image: linear-gradient(var(--state-hover), var(--state-hover))` y
no alcanza nada más. De los otros 41, veintidós mueven un BORDE y diecinueve
mueven la TINTA — ninguno es la capa de estado por muy neutro que sea su valor.
Eran deuda de nombre, y yo los había excluido del renombrado.
El clasificador tenía media prueba: miraba el VALOR (¿neutro o con valencia?) y
no la PROPIEDAD. Ahora exige las dos, siguiendo un salto por privado
(`--_switch-track-bg-hover`) y entre componentes (la familia calendar presta
`--calendar-control-*` a month-grid, range-calendar y year-grid, y por eso
esos cuatro no aparecían consumidos en su propia receta).
renombres 38 en 22 componentes · 113 referencias en 30 ficheros
cola real 6 (checkbox · date-range-picker ×2 · scroll-area · splitter ·
switch) — los únicos que pintan fondo
censo 162 · 5.203 · 1.841 (37 %) · 56 — IDÉNTICO
--names 38 → 0 desviadas
diff generated 38 renombres 1:1 · 0 cambios de valor
computed field · tabs contra la línea base ORIGINAL (anterior a las dos
pasadas): 4.031 valores, 16 estados, 0 diffs
huérfanos 0 · formato sin regresión · audit 163 PASS · rtl 0 · docs 0 ·
suite 434 pasan (1 rojo conocido) · check 0 errores en ficheros tocados
La muta-prueba se reescribió contra el catálogo vivo — asertaba nombres que el
codemod ya había renombrado — y gana los casos que faltaban: un knob de borde
neutro es `modifier`, uno de tinta neutro es `both`, y sólo los de fondo son
`state-layer`.
Queda una pregunta que §38 no contesta y que NO he decidido: si un hover de
borde o de tinta POR COMPONENTE debe existir siquiera. R-4.3 guarda
`background*` en `:hover`, nada más. Ahora al menos se llaman como deben
mientras se decide.
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
|
7781d6e4c8 |
feat(audit): R-5.3 — la gramática de los nombres deja de ser prosa
El canon de nombres llevaba meses documentado y sin guard, y la medición del
2026-07-01 ya decía qué le pasa a un canon así: deriva entre el 30 y el 85 %.
Había derivado. El codemod de ayer lo normalizó; esto es lo que impide que
vuelva.
R-5.3 valida una FORMA, no una lista — ahí se separa del guard de eventos, que
comprueba pertenencia a un vocabulario cerrado. La forma es: tinta = `fg`,
modificador interactivo DELANTE, y detrás lo dimensional y contextual.
No reimplementa la gramática: la consume de `theming-census --names`, que es
la misma fuente sobre la que corrió el codemod. Dos implementaciones de una
gramática son dos gramáticas que acaban discrepando — y este repo ya pagó esa
factura con `commit-resize`, un hook muerto tres meses en una receta con todos
los tests en verde.
Entra en `error` directo, sin rampa `warn`, porque su deuda murió en el mismo
pass (precedente R-4.4). Las claves en cola de migración a la capa de estado se
reportan APARTE: no son deuda de nombre, son knobs que van a desaparecer, y
renombrar lo condenado es churn.
Muta-prueba de tres caras, que es lo único que distingue un guard de un guard
que pasa sobre el vacío:
`-bg-hover` con valor de acento → ROJO
`trigger-color` → ROJO
`primary-solid-hover` → VERDE (canónica: COLOR_ROLE_SLOTS pone
el modificador detrás por construcción)
La tercera es la que importa: es el fallo que un codemod ingenuo habría
cometido sobre las 47 claves de rol, `button` entero incluido.
Doctrina en el mismo pass: recipe-contract §1 gana las dos filas que le
faltaban (tinta y estado) más la frase que las gobierna y las dos familias con
gramática propia; §4 gana la fila R-5.3; theming §6.7 una nota fechada que
acota el principio de plataforma del px/py a los ejes dimensionales. El
checklist de cierre declara la regla — lo cazó `docs:check` con su propio
guard I5, que exige que toda regla del audit esté declarada allí.
Lo que NO entra, y por qué: el tercer muro (el tipo en `defineRecipes`, molde
`PhysicalAxisKey`) está escrito y probado, y dispara sobre 17 claves — los
hovers neutros que la firma 3 manda migrar. Meterlo hoy rompería `npm run
check` a todo el mundo por una deuda que ya tiene dueño y fecha. Entra cuando
la migración a la capa de estado las vacíe; son dos líneas entonces.
component:audit 163 PASS · 3 NEEDS-WORK (badge, mockup, motion — los tres
sin tocar por esto, R-5.3 pasa en los 166)
docs:check 0
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2 months ago |
|
dev
|
bd916ef3fb |
refactor(eidos): el catálogo habla un idioma — 269 claves al vocabulario firmado
D-TH.6, ejecutada. El slot de tinta pasa a `fg` y el modificador interactivo
se pone delante, que es lo que theming §6.7 r7 documentaba sin guard desde
que se escribió. Value-preserving: renombra la clave en `recipes/base.ts` y
sus 793 referencias en 101 ficheros; no toca un solo valor.
claves renombradas 269 en 66 componentes
referencias 793 en 101 ficheros
censo antes/después 162 recetas · 5.203 knobs · 1.841 públicos (37 %) · 56
sin contrato — IDÉNTICO, como debe ser un rename
--names antes/después 269 desviadas → 0
Qué NO entra, y por qué:
47 `{rol}-{slot-de-rol}` canónicas: COLOR_ROLE_SLOTS pone el modificador
detrás POR CONSTRUCCIÓN (`primary-solid-hover`)
13 exentas firmadas `--focus-ring-*` es familia del sistema; el color
de `aura` es un sustantivo; `stop-color` ES una
parte de gradient-builder
47 hovers neutros por VALOR: migran a la capa de estado
(§38 + R-4.3), no se renombran — firma 3
6 ocurrencias en historia changelog, errores-toxico, PLAN-affix/background:
reescribir un registro fechado lo vuelve mentira
El clasificador vive en el censo (`--names`), no en un script suelto, para que
el guard R-5.3 consuma la MISMA gramática que el codemod. Su muta-prueba
(`__names-mutatest.ts`, 27 casos) es lo que hizo el trabajo: cazó que yo
promovía al frente CUALQUIER valor declarado por el morfo, y así
`--sidebar-width-icon` (la anchura del raíl colapsado) se convertía en
`--sidebar-icon-width` (la anchura de un icono), que es otra cosa. La firma
dice «delante lo interactivo, detrás lo dimensional y contextual»: ahora sólo
promociona el vocabulario interactivo cerrado, y lo contextual —`below`,
`loaded`, `vertical`, `icon`— se queda donde estaba. Los cinco casos de
regresión están en la muta-prueba.
También cazó que `dropdown-menu.item-bg-hover` lee `var(--color-primary-element)`:
es un hover CON VALENCIA (el palette swap de recipe-contract §2), no el hover
bespoke que §38 deprecó. Clasificar por el nombre lo habría metido en una
migración que no le toca; se clasifica por el VALOR.
Verificación (§7.4, artefacto por paso):
diff de generated/ 269 renombres 1:1 · 0 cambios de valor · 22 privados
reapuntados a los nombres nuevos (`__names-verify-diff`)
computed tag-group · field · tabs: 6.467 valores en 23 estados,
0 diffs — y comprobado en el navegador que sirve el CSS
nuevo, para que ese 0 no sea el de una copia cacheada
huérfanos 0 en código
suite eidos 434 pasan · 1 rojo, el conocido (`skin-media-player`).
`recipe-css-contract` verde: es el guard que caza el
`var()` sin fallback a un nombre que ya no se emite,
o sea el fallo exacto de un rename a medias
component:audit 163 PASS · 3 NEEDS-WORK, los tres SIN TOCAR por esto
check 0 errores en ficheros tocados (los 73 globales son de
otras sesiones de la rama; se atribuye por fichero)
rtl:check 0 · docs:check 0
formato el renombrado no alarga ninguna línea: ningún fichero
tiene más líneas de 100 chars que antes, así que no se
pasa prettier — hacerlo reformateaba 300 ficheros de
deriva ajena
Entra aquí la corrección del repaso de los 7 ya hechos:
`gradient-builder.checker-color` → `checker-fg` (el damero de transparencia;
ahí `color` era slot). Sus `stop-color-*` no se tocan.
Queda para el paso siguiente: R-5.3 no puede graduar a `error` directo
mientras los 47 hovers neutros sigan hablando el idioma viejo — o migran
antes (firma 3, ya firmada), o el guard necesita una exención greppable.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2 months ago |
|
dev
|
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
|
6e501f4fdf |
docs(blocks): handoff del día — cinco filas cerradas, y el eje que cambió el método
Deja escrito por dónde entrar mañana, en este orden: §0 EL EJE VIVO — el chasis de sección, que es lo que hay que retomar. Con la frase del autor que lo abrió («lo estás convirtiendo en una mierda a base de parches, ninguna es profesional ni de alcance») y su pregunta, que es la que tenía razón: si no debería haber un componente del que se basen todos los bloques. El censo que la confirmó (16 · 15 · 9 · 8 copias del Header), la firma (que CREZCA Section, no que nazca un hermano), por qué el nombre Block se descartó (ya significa «a todo el ancho» en el canon), los tres commits, las dos trampas que costaron —el Background que se capa dentro de la medida, y la raíz que extiende SectionProps y no HTMLAttributes— y las tres cosas que quedan: los 19 README describen el nido viejo, el contrato del tier no dice todavía que la raíz de un block ES un Section, y nada más. §1 LA COLA, REENCUADRADA — con el aviso de que más de la mitad de lo que sigue archivado bajo un block tiene la causa en el canon (A-48, A-53, A-60, A-62, A-65), así que bajarlas dentro de la frontera del tier fabrica parches. Y el trabajo honesto que sí queda dentro: A-74, A-96 y A-71. A-11 replanteada en su ficha por la misma razón: su arreglo profesional es que el canon publique el CATÁLOGO en runtime de sus escalas —como ya hace EIDOS_VARIANTS— y no siete líneas de exhaustividad repartidas por las demos. Queda medido lo que hoy está derivado: ContainerSize sin xxl, Breakpoint con 3 de 6, Decor con 5 de 8. docs:check 0/0 (813). Los avisos de prettier de los dos ficheros son preexistentes (CRLF), comprobado contra HEAD. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
2 months ago |
|
dev
|
cc98444343 |
uix(blocks): las diecisiete raíces que quedaban dejan de reescribir el chasis de sección
Cada block abría con el mismo nido escrito a mano: un <section {...rest}> sólo
para poder nombrarse, dentro Section para el aire, dentro Container para la
medida, y a veces un Background para la banda. Con Section ya crecido, la raíz
es una línea y el <section> duplicado desaparece: medido en las previews, el
documento pasa de 3 elementos <section> a 2 en cada block migrado.
Trece van al patrón entero (size + containerSize + decor):
article-grid, contact, faq, pricing, team, testimonials, feature-split,
logo-cloud, newsletter, más los dos de la primera tanda. Cuatro conservan algo
propio y sólo pierden el envoltorio:
- cta mantiene su Container, porque su medida lleva un paddingX condicional
(`full` significa EDGE TO EDGE y el gutter hay que quitarlo) que no es del
chasis.
- content-section no usa Container: su medida es una rejilla de cinco pistas.
- site-footer usa `as="footer"` — la sección de cierre de la página ES una
sección, con el mismo aire, la misma medida y la misma banda; lo que cambia
es el elemento, que es lo que la hace landmark `contentinfo`.
- hero conserva su Container en la variante `background`, y esto lo destapó la
MEDIDA, no la lectura: al pasarle `containerSize` su backdrop quedó atrapado
dentro de la medida y el hero salió con 128px de blanco a cada lado en vez de
a sangre. El `decor` del chasis se pinta FUERA del container justo por eso,
pero el de hero no es un patrón de tokens sino la media de la app bajo un
scrim, así que llega como hijo — y un hijo se capa con la copia. Queda escrito
en el sitio donde volvería a morder. Verificado después: fondo 1280 a sangre,
hijo directo de la sección, medida 1024 dentro, en hero y en stats-band.
Los tipos siguen la regla que ya estaba escrita en el types.ts de stats-band y
que la primera tanda confirmó: la raíz extiende los props del componente del
canon que envuelve —SectionProps— y nunca HTMLAttributes, cuya superficie
laxa choca con el style/class refinado del canon al esparcirse.
Gates: svelte-check 72/62 antes y después · vitest eidos+blocks 470/471 (el rojo
es skin-media-player, ajeno) · blocks:check 0/19 · docs:check 0/0. Medido en
navegador block a block: tag SECTION, aire, medida y patrón en su sitio, y el
hero en sus tres layouts.
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
|
3bfe0d4130 |
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 |
|
dev
|
07778b597a |
uix(date-range-picker): la vista de década es suya y pasa a tokens; el calendario y el campo esperan su firma
Séptimo del eje theme-reach. Este componente es un híbrido de tres familias y el contrato lo dice ahora explícitamente: la vista de década/mes es invención suya y pasa a contrato público — separación, ancho, cabecera, navegación, rejilla y celdas, con los estados del rango separados por nombre en vez de amontonados en uno solo. Más el acento. Lo que NO se toca tiene dueño y esperando firma: la mitad de calendario lee `--calendar-*` y su corrección es la decisión de familia calendar que la auditoría del sistema dejó registrada; la entrada segmentada lee `--field-*` y le toca el mandato de composición de Field. Duplicar cualquiera de las dos bajo prefijo propio habría sido justo el alias que la purga de 2026-07 mató. Y el mismo defecto de prefijo que sus hermanos, aquí por partida doble: 44 referencias `--_date-field-*` y 9 `--_calendar-font-size` declaradas en ESTE CSS con el nombre de otro componente. Con un DateField o un Calendar anidados se habrían pisado. Renombradas, con el diff de computed en cero. Verificación: diff de computed vacío sobre 493 valores en ocho estados · component:audit PASS · suite eidos sin rojos nuevos · rtl:check 0 · docs:check 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
2 months ago |
|
dev
|
ecb23d6a48 |
uix(blocks): los ocho encabezados de sección eran el mismo, y uno ya había derivado
feature-grid, feature-split, pricing, testimonials, faq, article-grid, team y contact declaraban cada uno su `.Header` con las mismas tres líneas: un Box con maxWidth 48rem, un Motion trigger="viewport" y un Stack gap 3. Ocho ficheros, una sola idea. Y la copia se pagó donde siempre: article-grid había perdido su Motion. Su encabezado aparecía sin el reveal que tenían los siete hermanos, y nadie lo notó porque no hay dos secciones iguales delante a la vez. Componer el canon lo restaura — medido: su primer hijo estampa ya `data-animation-trigger`, igual que el de pricing. Los ocho pasan a componer `Section.Header`, que gana `align` para la única variación real: feature-grid hace llegar el eje de la sección al contenido del encabezado por contexto (A-84) y article-grid alinea a start. faq conserva su `marginX="auto"` en el call site. Ninguna parte pública desaparece: `Pricing.Header` sigue siendo `Pricing.Header`, sólo que ahora hay una implementación en vez de ocho. Medido en las ocho previews: 768px de medida (48rem) donde tocaba, faq en sus 736 por su propio centrado, y el alignItems de cada Stack en lo que su block pide — center en feature-grid, start en article-grid, stretch en el resto. Gates: svelte-check 72/62 antes y después · vitest src/uix/blocks 36/36 · blocks:check 0/19. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
2 months ago |
|
dev
|
68eb8af260 |
uix(time-range-picker): el reloj de dos columnas y la franja AM/PM pasan a tokens
Sexto del eje theme-reach, y gemelo de time-picker: mismo reparto, mismas razones. A contrato lo que el componente inventa — el reloj de dos columnas (su separación, ancho, tinta y tipografía), los colores de las tres manecillas y la franja AM/PM entera — y sin tocar el lado con forma de campo, que lee `--field-*` porque compone Field. Y el mismo defecto de prefijo que su gemelo: 56 referencias declaraban `--_time-field-*` dentro de este CSS (más una mención en el wrapper). Renombradas a `--_time-range-picker-*`, con el diff de computed en cero. Dos cosas que la revisión había marcado como acuñables y NO lo son, confirmadas al ejecutar: el realce del reloj al puntero lee `--toggle-palette-solid`, que es la paleta de otro componente — si procede, es un bloque de composición cruzada, y eso es decisión, no corrección; y el `padding-inline` del raíl consume el tamaño del pulgar del Slider, un eje que publica su dueño o no se publica. Verificación: diff de computed vacío sobre 725 valores en ocho estados · component:audit PASS · suite eidos sin rojos nuevos · rtl:check 0 · docs:check 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
2 months ago |
|
dev
|
e4fcdd62ee |
uix(time-picker): el reloj es suyo y pasa a tokens; el campo sigue siendo del Field
Quinto del eje theme-reach, y el primero donde la mitad del componente NO debe tokenizarse: time-picker compone Field, así que su parte con forma de campo lee `--field-*` por diseño y duplicar esos ejes bajo prefijo propio sería el vocabulario paralelo que el contrato prohíbe. Lo que sí es invención suya —la cara del reloj— pasa a contrato: separación, ancho, tinta y tipografía del reloj, los colores de las tres manecillas, el refuerzo del pulgar sobre la superficie del popover y el radio del trigger en línea. Más el acento, que ahora es público en vez de esconderse tras un privado. Y un defecto que el censo no podía ver: la receta declaraba sus privados con el prefijo de OTRO componente (`--_time-field-*`) dentro de su propio CSS. No era sólo cosmético — un TimeField anidado y este picker se habrían pisado el nombre. Son 44 referencias renombradas, con el diff de computed en cero. El 82 % que el censo sigue contando fuera son esos préstamos de Field: no es deriva, es un préstamo con dueño, y su corrección es el mandato de composición de Field que la auditoría del sistema dejó apuntado (§5.3-3), no este eje. El guard de huérfanos me corrigió por el camino: había declarado doce tokens de más, copiados del range-picker (la franja AM/PM y los ticks), que este componente no tiene. Retirados; sólo `trigger-radius` tenía consumidor real y se cableó. Verificación: diff de computed vacío sobre 580 valores en ocho estados · component:audit PASS · suite eidos sin rojos nuevos · rtl:check 0 · docs:check 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
2 months ago |
|
dev
|
4a27715170 |
uix(section): la sección de una página es un componente, no un esqueleto que cada block reescribe
Los 19 blocks del tier repetían el mismo chasis: un <section {...rest}> escrito a
mano, dentro Section (el aire), dentro Container (la medida) y a veces
Background (la decoración). Medido antes de tocar: containerSize recableado en
16 blocks, sectionSize en 15, decor en 9, y OCHO copias del mismo Header —
Box maxWidth 48rem + Motion viewport + Stack gap 3—, una de las cuales ya había
derivado en silencio: la de article-grid perdió su Motion.
La regla del propio tier dice que una parte se gana el compound cuando SE
REPITE. Aquí lo que se repite son los blocks, así que la repetición se gana un
componente. Y no uno nuevo: ese componente ya existía a medias y se llama
Section. Crece en vez de nacer un hermano — un segundo componente obligaría a
explicar en cada README en qué se diferencia de Section, y la explicación sería
«Section con tres props más».
Section gana, todo opcional: containerSize (compone Container DENTRO, y sin él
los hijos se renderizan igual que siempre), decor (pinta Background.Pattern
como HIJO, para que la banda sangre a todo el ancho por detrás de la medida sin
ganar caja) y la parte Section.Header.
Y renderiza un <section> real. Renderizaba un <div> a propósito, con la nota
«si un consumidor necesita un <section> de verdad para el landmark, que lo
envuelva» — y nueve blocks hacían exactamente eso, pagando un nodo extra para
poder nombrarse. Un <section> sin nombre NO es landmark (se expone como region
sólo al llevar nombre accesible, que es lo que A-109 dejó medido esta misma
semana), así que el tag no ensucia el árbol de nadie y la raíz duplicada
desaparece.
Para eso Box gana `as`, que cierra F21 («los primitivos de layout no pueden
cambiar de elemento»): lista CERRADA de elementos contenedores, nunca void —
es una escotilla semántica, no un prop de tag libre—, default 'div', y el
modelo de caja, las vars y la receta idénticos rinda lo que rinda. Los ≥2 casos
reales que la decisión original pedía para reconsiderarlo llegaron hace tiempo:
la columna de enlaces del pie que debía ser ul/li, y estos dieciséis blocks.
Migrados DOS como prueba, uno por clase: feature-grid (medida) y stats-band
(medida + decoración). Cada uno pierde dos niveles de anidamiento y su
<section> duplicado — medido en navegador: [data-section] ES el <section>, el
patrón 'grid' sigue siendo su hijo, 1280 de ancho, 64px de aire, 1024 de
medida, y el documento pasa de 3 elementos <section> a 2. Los otros 17 van en
tandas aparte.
⚠️ El paso de tipos que costó los únicos 5 errores de esta rama, y que lo
explica una regla ya escrita en el propio types.ts de stats-band: «sub-parts
extend the props of the canon component they wrap, never HTMLAttributes: the
raw attribute surface clashes with the canon's refined style/class when spread
through (the feature-grid lesson)». Ahora la RAÍZ también envuelve un
componente del canon, así que sigue la misma regla: FeatureGridProps y
StatsBandProps extienden SectionProps.
Gates: svelte-check 72/62 antes y después · vitest eidos+blocks 470/471 (el
rojo es skin-media-player, ajeno y documentado) · blocks:check 0/19 ·
docs:check 0/0. Prosa al día: README de Box y de Section, la demo de Section
(que anunciaba la limitación en cuatro sitios) y F21 cerrado en
PLAN-blocks-quality §6.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2 months ago |
|
dev
|
ae91573c32 |
uix(proof-of-human): el cromo del reto se puede temar; la paloma y el cielo no, y eso ya estaba firmado
Cuarto del eje theme-reach. El reto ataba su escenario a primitivos globales: alto mínimo, radio, fondo, borde y los bordes de veredicto no los alcanzaba ningún tema. Ahora son 20 claves públicas, con el alto por talla en el canon de dos piezas y `parts: ['root']`, más la guía del trazo (corredor, línea, estela, marcador de meta) y el token arrastrable. Lo que NO entra es la escena — la paloma, la carta, los cielos del reloj — y no por falta de tiempo: el guard de recetas ya lista este componente en la excepción de tono fijo, y sus literales ya llevan anotación línea a línea. Un sello no se vuelve azul porque el tema lo haga. La revisión había anotado esto como decisión pendiente del autor; era una firma que ya existía y no había leído. Dos fallos míos que la verificación cazó y que quedan escritos porque son reutilizables. El primero: añadí un bloque `'proof-of-human'` a las recetas sin ver que ya había uno (el forward de paleta), y en un object literal la segunda clave gana — mi bloque se descartaba EN SILENCIO. Lo delató el diff de computed con 28 diferencias, empezando por un `border-radius` que caía a cero. El segundo: al fusionar los bloques perdí la última clave, y el guard de tokens fantasma lo cazó al instante. Verificación: diff de computed vacío sobre 406 valores en siete estados · component:audit PASS · suite eidos sin rojos nuevos · rtl:check 0 · docs:check 0. El centinela no vale aquí y así queda dicho: la demo declara su propio `min-block-size` y un degradado sobre el escenario, de modo que tapa dos de los tokens; los que no pisa responden. El 86 % que el censo sigue contando fuera son los dos ficheros de la escena, que enganchan por CLASE en vez de por data-attr — migrarlos es otro eje, anotado. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
2 months ago |
|
dev
|
e774ca7e84 |
uix(natural-time-picker): el cromo de la banda se puede temar, y el cielo sigue siendo el cielo
Tercero del eje theme-reach. La receta ataba todo a primitivos globales y guardaba su geometría en privados con un prefijo abreviado, `--_ntp-*`, que ni el censo veía ni el vocabulario permite: alcance 0 %. Ahora son 60 claves públicas y el 61 % medido. Dos de los tres bloqueos que la revisión había anotado no existían: la doctrina ya estaba escrita y no la había leído. El guard de recetas ya lista este componente en la excepción de TONO FIJO — un cielo no cambia con el tema, y sus literales ya llevaban su válvula línea a línea, así que los cielos, la tinta del sol/luna y la línea de posición se quedan privados y anotados, sin decisión que pedir. Y el panel sigue leyendo `--popover-*` porque su propia cabecera dice que esa superficie ES el flotante canónico: duplicarla con prefijo propio habría sido el vocabulario paralelo que el contrato prohíbe. De ahí que el 39 % restante no sea deuda sino préstamo deliberado. Lo que sí es suyo pasa a contrato: banda y knob por talla con `parts: ['panel']` —conservando su derivación de la altura de control, así que la expresión sigue siendo el knob y mover la talla arrastra ambos—, la línea indicadora, los ticks, el readout (hora, meridiem, periodo), los steppers, los chips y el trigger. Más el `panel-gap`, que sí es del panel y no del popover. Las 37 referencias `--_ntp-*` mueren: el prefijo de un privado es el nombre completo del componente (theming §6 regla 5). El rename alcanza receta, wrapper, README y el propio guard que las citaba. Verificación: diff de computed vacío sobre 6.438 valores en ocho estados. Centinela 40/62 automático, y cada uno de los marcados muertos verificado a mano: banda, knob, gap del panel, línea, radio de la línea e inset de los ticks alcanzan; los `trigger-*` NO, porque `[data-popover-trigger]` gana la cascada y viste el trigger — ya eran inertes antes de tokenizarlos, y ahora está dicho en el README en vez de fingir que el token pinta. Guards: component:audit PASS · eidos-lint 0 invalid · suite eidos sin rojos nuevos · rtl:check 0 · docs:check 0 · el guard del bundle obligó a apuntar `tick-font-size` a la coordenada `--size-xxs-font-size`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
2 months ago |
|
dev
|
cef2d32f16 |
uix(combobox): el campo y su panel pasan a tokens públicos, con la talla resuelta donde manda
Segundo del eje theme-reach. El combobox tenía UN token propio (`content-z`) y
todo lo demás atado a primitivos globales o enterrado en privados: alcance 0 %.
Ahora son 106 claves públicas y el 76 % medido — lo que queda fuera son tres
hovers que esperan firma, seis literales de layout y doce knobs que pasan por
privados que ya derivan de un público.
La talla sigue el canon de dos piezas (coordenada + nombre resuelto), pero con
una diferencia que el DOM impone: los resueltos del control se emiten sobre
`control` e `input`, no sobre el root, porque el `data-size` que manda vive en el
control — y el input suelto lo necesita fuera de él. Los del panel se emiten
sobre `content`, que viaja por portal y nunca vería un token del root. Es el
precedente de `select` aplicado donde toca.
Altura, tipografía y separación del control consumen la coordenada del bundle
`--size-{k}-*`; el relleno inline SE DESVÍA del bundle en cuatro tallas y
conserva su valor de hoy — la desviación queda visible en el contrato en vez de
redondearse a la coordenada, que habría sido un cambio visual disfrazado de
limpieza. El chip conserva sus expresiones (`control-height − inset`,
`control-font-size − offset`), así que mover el control sigue arrastrándolo.
El centinela cazó un fallo real a mitad del trabajo: la primera pasada dejó
vivos los ocho bloques `[data-…][data-size='…']` de la receta, que pisaban los
tokens nuevos con los valores viejos. El diff de computed daba cero JUSTAMENTE
porque la ruta vieja seguía mandando; sin centinela habría pasado por bueno.
Verificación: diff de computed vacío sobre 1.566 valores en ocho estados —
reposo, las cinco tallas, el panel ABIERTO y hover. Centinela 67/106 automático
y el resto verificado a mano: `content-z` alcanza (80 → 4321) aunque viva en el
wrapper flotante; placeholder, disabled e ink del trigger forzando su estado;
los del panel abriéndolo por teclado. Los siete nombres resueltos no se mueven
por diseño — el tema mueve la coordenada. Los catorce `selected-tag-*`, los tres
`separator-*` y `scrollbar-inset` no son verificables en esta demo (no monta
modo múltiple, ni separadores, ni scroll): queda dicho, con su consumidor
comprobado en la receta, en vez de darlos por buenos.
Un token nace inerte y se anota como tal: `content-font-family` y
`content-line-height` los pisa `[data-depth='overlay']` con la misma
especificidad — es la tipografía de portal del Build contract, y tocarla sería
otro eje.
Guards: component:audit PASS · eidos-lint 0 invalid · suite eidos sin rojos
nuevos · rtl:check 0 · docs:check 0 · el guard del bundle obligó a apuntar
`indicator-size` e `item-indicator-size` a `--size-sm-icon-size`.
El informe `docs/audit/theming/` se regenera entero, así que todas las fichas
actualizan su fecha de medida; las que cambian de contenido son combobox y
gradient-builder.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2 months ago |
|
dev
|
18165e74ed |
uix(blocks-demos): la vista previa nace con el estado vivo de ActiveUix, no con los defaults
El iframe de la vista previa es OTRO documento con OTRO runtime (BootUix corre
su propio createActiveUix), así que el estado de la sección no cruza el marco:
la rama de 375/768 se abría SIEMPRE en claro, y en 9 demos siempre en LTR, con
la topbar en oscuro y RTL delante (A-29). Dentro del documento los blocks
siempre atendieron a ActiveUix — el shell conduce el framework por
uix.prefs.setIntent y el modeSource de eidos —; lo que faltaba era la única
serialización que existe entre dos runtimes: la URL.
El arreglo va en el ARNÉS, no demo a demo. BlockDemo lee el estado VIVO por la
superficie sancionada del framework — readActiveUixPrefsSlot(uix.prefs,
'direction'|'language')?.get(), las lecturas por dimensión que son rune-backed
(contador $state por dimensión), y eidos.getThemeContext().mode, que lee el
modeSource del shell — y compone la URL final: los props del BLOCK los pone el
demo, los EJES los pone el arnés. El {#key} y el enlace «abrir ↗» pasan a la
URL resuelta, así que mover un toggle global re-monta el iframe con los params
nuevos y el enlace abre lo que estás viendo.
Retirados los 11 controles «dir (solo la vista previa)» de banner, contact,
cta, feature-grid, feature-split, hero, newsletter, site-footer, site-header,
stats-band y team: eran el eje de sección repetido por demo — la regla del
arnés dice que tema, idioma y dirección los da el shell — y no tocaban prefs,
sólo escribían la URL. El shell queda como único dueño de los ejes; una
precedencia demo-gana habría dejado el toggle global inerte en esas páginas.
Dos correcciones a la ficha: testimonials ya derivaba su URL (el literal
desnudo quedó atrás en F2b), y el alcance real era el sistémico que la propia
ficha apuntaba — mode= no viajaba en NINGUNO de los 19 demos y dir= faltaba en
9. La pata lang sigue siendo inerte salvo en contact (blocks.* registrado),
pero viaja igual: es un eje del shell.
Verificado con la topbar REAL de la sección, no con params a mano: en oscuro +
RTL, el iframe de pricing a 375 arranca base-dark + dir=rtl (tinta
oklch(0.9491 0 0)) y el de hero — que tenía control local — hereda igual; en el
estado por defecto los dos vuelven a base-light + ltr. La URL sale con los
props del block primero y mode/dir/lang detrás.
Gates: svelte-check 72/62 antes y después · blocks:check 0/19 · docs:check
0/0. Huella: BlockDemo +31, cada demo −18 (−192/+39 en total).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
2 months ago |
|
dev
|
3cdb5b5f03 |
uix(gradient-builder): el editor entero pasa a tokens públicos — un tema lo mueve sin tocar el sistema
Primer componente del eje theme-reach, y su piloto: la receta declaraba CERO
tokens propios («self-contained», decía la cabecera) y ataba cada knob a un
primitivo global o a un privado. Alcance medido: 0 %. Un tema no podía cambiar
ni el alto del preview ni el radio de la tarjeta sin mover el ecosistema.
Ahora los 72 knobs son contrato público del componente. Los ejes dimensionales
siguen el canon de dos piezas que firmó el Sidebar: coordenadas por talla
(`preview-height-{sm,md,lg}`…) más UN nombre resuelto (`host` = md, `size:sm`,
`size:lg`) que es lo único que consume el CSS — así los bloques `[data-size]`
de la receta desaparecen y la cascada la emite el TSC. La geometría se queda
PROPIA (px × `--scaling`): un raíl de edición no tiene coordenada de
control-height, así que forzarlo al bundle habría sido rediseño. La tipografía
sí lo consume, que es lo que el guard `recipe-css-contract` exige.
De paso mueren dos abreviaturas que escondían tokens al censo y podían cruzarse
por anidamiento: `--gb-checker*` y `--gb-stop-fill` pasan a
`--_gradient-builder-*` (también en el wrapper). El damero de transparencia se
parametriza por `checker-color` + `checker-cell`, y el patrón de cuatro
gradientes se queda privado — un tema cambia el color de la celda, no reescribe
la rampa. El `padding` shorthand se parte en ejes lógicos.
El default no se mueve: sonda antes/después con 6.612 valores computados
comparados en 7 estados (reposo · cinco tallas · hover) sobre 34 nodos, diff
VACÍO. El único diff que apareció era la transición de hover de un Button
compuesto capturada a mitad — demostrado reproduciendo el valor interpolado en
el árbol ya modificado, bajando la espera de asentamiento.
Centinela: 72/72 tokens alcanzan. 49 desde el ámbito del componente en reposo;
las 12 coordenadas de talla y las 2 de preset seleccionado forzando su estado;
`hover-preset-border` con hover real; y los 4 del editor de color sólo desde
`:root`, porque el panel viaja por portal — anotado en el README para que nadie
lo lea como un token muerto.
Dos hallazgos que quedan anotados, no corregidos (mueven píxel, así que son
decisión): el wrapper pinta el preview con el shorthand `background` inline, que
resetea `background-image` y tapa el damero, de modo que la transparencia no
llega a verse; y el foco de la parada usa el patrón de dos anillos con
box-shadow cuando §32 canonizó `outline`.
Guards: component:audit PASS · eidos-lint 0 invalid · suite eidos sin rojos
nuevos (queda el conocido skin-media-player) · rtl:check 0 · docs:check 0 ·
check sin errores en los ficheros tocados · censo 0 % → 80 % (el resto son
privados que YA derivan de públicos, el anillo de foco y tres literales de
layout) · captura 2× revisada.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2 months ago |
|
dev
|
2591ec2f03 |
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 |
|
dev
|
48bad6c726 |
uix(feature-split): una sección se nombra por su encabezado, y sus filas cuelgan de él
feature-split era el único block de sección del tier sin parte .Header. Sus
filas emitían h2 por defecto, así que una sección de tres filas aportaba tres
h2 hermanos al outline y la sección misma no tenía nombre (A-110). La página
compuesta lo rodeaba a mano: encabezado escrito como primer hijo y un level={3}
repetido fila a fila.
El h2 de las filas no era un descuido: era una decisión ESCRITA en el README
del block —«.Title emits h2 by default (each row is a section-level statement
of its own)… drop it to 3 when the page already put an h2 above the rows»—. Se
deroga en sitio, y no por gusto sino porque el resto del tier declara lo
contrario: FeatureGrid.ItemTitle, las preguntas de faq y Pricing.PlanName ponen
en level 3 lo que se repite, y el h2 lo lleva el Header.
Nace FeatureSplit.Header, calcado de Testimonials.Header (Box con medida +
Motion + Stack) y sin contexto, porque este block no tiene eje align que
heredar. Y .Title baja su default de 2 a 3. La forma queda coherente en los dos
casos, que es lo que la hace preferible a las alternativas: con .Header el h2 es
suyo y las filas cuelgan; sin .Header la app ya puso el h2 encima y las filas
cuelgan igual. La tercera vía —un contexto donde el Header marcase su presencia
y el Title derivara su nivel— daba el mismo resultado a cambio de un hijo
escribiendo en el contexto del padre, que es el patrón que ya costó un bucle de
$effect en este repo. Por un solo bit, no compensa.
Verificado en navegador, outline leído del DOM:
/blocks/feature-split/preview h2 «Del evento crudo a la decisión»
h3 ×3 (las filas) ← antes: h2 ×3, sin nombre
/blocks/landing h2 + h3 ×2, dentro de un outline de página
que ya no salta de nivel
La demo compone su encabezado y LandingSite deja de hacerlo a mano: fuera el
Stack escrito a pelo y fuera los dos level={3}. Header medido en su sitio (x
144, 768 de ancho: la misma medida que la copia de las filas).
Gates: svelte-check 72/62 antes y después · vitest src/uix/blocks 36/36 ·
blocks:check verde (19 blocks, 147 ficheros) · docs:check 0/0.
Primera fila del ledger arreglada DENTRO del tier, por acotación del eje: las
tres anteriores de la sesión (A-111, A-112, A-109) eran todas de canon.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2 months ago |
|
dev
|
1e3a67ad39 |
uix(banner): la tira de aviso no es la cabecera del sitio, así que deja de reclamar su landmark
Toda página con cabecera exponía DOS landmarks banner: el <header> del
site-header y la tira de aviso, que estampaba role="banner" a mano. ARIA
reserva ese rol para la cabecera DEL SITIO —identidad, búsqueda del sitio— y
dice que un documento debería marcar como mucho uno (A-109).
Las dos salidas que la ficha proponía estaban mal planteadas, y lo destapó una
revisión adversarial de tres refutadores independientes:
- «Estampar el rol ANTES de los rest props, que es la clase naming donde gana
el consumidor» contradice la doctrina que la propia ficha citaba: role es
clase CONTRATO por nombre de atributo (morfo/types.ts:811-832;
ARIA_NAMING_ATTRS contiene sólo aria-label). El runtime siempre gana ahí, y
con razón: un data-state o un role pisables son un componente que miente.
- Y el orden de estampado NUNCA fue el mecanismo. Medido: el segundo landmark
es el <header> del site-header, que no lleva atributo role ninguno — recibe
banner IMPLÍCITO por ser una <header> fuera de un elemento de sección. Un rol
pisable habría dejado quitarlo caso por caso, empujando el arreglo a cada
app, en vez de arreglarlo por defecto.
- El morfo, además, nunca declaró el rol (aria: []): era un literal del wrapper
de eidos que el README daba por contrato de la parte. Drift morfo↔eidos que
se queda sin objeto.
Lo firmado: la tira deja de reclamar el landmark. defaultElement header→section
en el morfo, fuera el role literal. Un <section> es region SÓLO cuando tiene
nombre, así que el aria-label del consumidor la hace encontrable y su ausencia
la deja como contenido plano — que es exactamente lo que el censo de landmarks
de A-111 ya sancionaba por escrito.
⚠️ SIN nombre por defecto, y esta es la corrección que la revisión me obligó a
hacer sobre mi propia propuesta: yo había planteado un default traducido
(«Aviso»), copiando el patrón de skeleton/spinner. Habría convertido TODA tira
en landmark sin salida — /temas/grafito apila cuatro y habrían salido cuatro
region con el mismo nombre, que es la clase de defecto de A-111 con otro traje.
El precedente de <nav> no transfiere: un <nav> es SIEMPRE landmark y por eso
pide nombre; un <section> lo es PORQUE lo tiene. Quien quiera una tira
encontrable, la nombra.
Derogadas por escrito las dos afirmaciones que decían lo contrario, porque
existían y estaban firmadas: el README del canon («Banner is a landmark for
page-level announcements — site header, persistent notice, system status bar»)
y el «✓ ejemplar» que docs/audit/components/banner.md le puso a ese contrato el
2026-07-07. La otra mitad de aquella decisión —no role="alert", el feedback
transitorio es de Toast— sigue en pie y se dice.
Verificado con el árbol AX de Chrome por CDP, servidor limpio:
/blocks/landing banner ['Aviso del producto','Acme'] → banner ['Acme']
+ region ['Aviso del producto']
/blocks/banner/preview banner ['Principal'] · region ['Aviso del producto']
/temas/grafito banner [] · region [] — las cuatro tiras sin nombre
dejan de ser landmarks, que es lo correcto
Píxel idéntico: la receta selecciona [data-banner], no el elemento — tira a
sangre 1280×54 con el mismo fondo, capturada y mirada. Ningún test, guard, CSS
ni consulta del repo seleccionaba por role=banner ni por el tag.
Gates: svelte-check 72/62 antes y después · vitest eidos+blocks+morfo 692/693
(el rojo es skin-media-player, ajeno y documentado) · blocks:check 0/19 ·
docs:check 0/0 (644) · morfo:check PASS en banner. Prosa re-sincronizada en 11
sitios: los README de canon, block y app-shell, la ficha de auditoría, las tres
demos, landing y su README.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2 months ago |
|
dev
|
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 |
|
dev
|
a827948459 |
uix(navigation-menu): el hover es el del sistema — la misma capa, sobre la forma de cada elemento
«El estilo tiene que ser el mismo para todos los elementos. ¿De dónde sacas esos estilos?» De ningún sitio que valiera: en |
2 months ago |
|
dev
|
12796ac428 |
uix(navigation-menu): los enlaces del panel hablan el mismo hover que la barra
«¿Por qué los otros ítems no tienen el mismo hover? ¿Qué sentido tiene?»
Ninguno. En
|
2 months ago |
|
dev
|
822b78cf2c |
uix(navigation-menu): el panel sube como lo que es, y la caja gris del hover era el <li>
Dos correcciones del autor sobre |
2 months ago |
|
dev
|
ae9e277fad |
uix(navigation-menu): el botón «aparecía» en vez del panel, y la forma del trigger no la podía tocar ningún tema
Dos defectos que el autor señaló en el megamenú, y los dos anteriores a T-1.
1 · EL TRANSLATE. `emerge-open` / `emerge-close` se estampaban en el TRIGGER,
así que la firma genérica `[data-event^='emerge-open'] { animation: present-rise }`
corría sobre el BOTÓN: opacidad 0→1 y 8px de translate en el control, mientras
el panel —la superficie que entra en el campo— no hacía nada. Medido: a +8 ms el
trigger con `present-rise` y `translateY(5.5px)`, a +120 todavía vivo.
La premisa del target era real («el content se monta al abrir, un sello dirigido
a él muere») y la receta A-36 ya la respondía, por eso dropdown-menu, popover,
context-menu y dialog declaran `content` y ninguno declara `trigger`:
`open` es `post` —el flip monta el panel y el runtime difiere el emit pasado
`tick()`— y `close` es `pre` —el panel sigue ahí para anunciarlo—, con
`targetFallback: [trigger]` para la carrera en que ya no está. Resolución por
estado de montaje, DECLARADA, no un fallback a mano en el provider.
navigation-menu era el último que la arrastraba. Ahora el trigger queda sin
evento, sin animación y sin transform en todos los instantes; el panel se lleva
la aparición. La suite lo fija en las dos ramas (content montado · fallback).
Al mover el sello salió un doble que habría enviado: el panel tiene entrada
propia (slide+scale+fade, 120 ms) y la firma se la pisaba durante el hold; al
retirarse el sello, la de la receta arrancaba DE CERO. El panel entraba dos
veces, 320 + 120 ms. Precedente exacto en tooltip («the preset entrance wins
over the global present-rise signature», medido allí el 13-08): la entrada
propia gana por especificidad. Registro de animaciones tras el arreglo: una sola
entrada de 116 ms, nada en el botón.
2 · LA FORMA. El radio del trigger vivía en un PRIVADO (`--_navigation-menu-
radius`) clavado a `--radius-default` —«decoupled from size (Radix model)», una
línea que leyó a Radix como regla cuando Radix no pinta nada—, la altura salía
de `padding-block: var(--space-2)` (un token de ESPACIO como altura de CONTROL:
medido 33,5 / 36 / 41 px en sm/md/lg, sólo `md` en la escala por aritmética
casual) y los rellenos de hover/abierto estaban escritos a mano. El contrato del
componente publicaba tres knobs (content-z, indicator-w/x): ningún tema podía
decir «píldora» sin mover el radio del sistema entero. Por el TSC y por lo que
hacen Button (`--button-radius-*`), dropdown-menu (`item-*`) y el Sidebar de
ayer (`--sidebar-row-*` por talla), eso es un error, y el autor lo firmó así:
themable, default el actual.
Ahora el trigger (y el Link, que comparte su cromo) toma el bundle canónico
`--size-{k}-*` a través de tokens públicos por talla —`--navigation-menu-
trigger-{height,font-size,line-height,padding-inline,radius}` con sus pasos
`-{sm,md,lg}` y el nombre resuelto por `data-size`— más `-bg-active` /
`-fg-active` para el acento de abierto / aria-current. A `md` el default es
exactamente lo que traía: 36 px, 6 px de radio. Medido antes → después: altura
33,5/36/41 → 30/36/44; radio 6/6/6 → 6/6/10. Y un tema decide la forma en una
línea: `--navigation-menu-trigger-radius: var(--radius-full)` en el root → 9999px
en el trigger, medido.
Y el hover: la receta pintaba `background: var(--color-surface-overlay)` con el
SHORTHAND, que resetea `background-image` —donde vive la capa de estado canónica
que `archetypes.css` ya da a todo `trigger` (R-4.3)—. Medido: `background-image:
none` en hover, la capa muerta y una superficie a mano en su lugar; y el trigger
ABIERTO sin ninguna respuesta al puntero (el mismo bug que la fila activa del
Sidebar, ayer). La regla de hover desaparece (la capa ya está) y el acento usa
`background-color`, así que compone encima: medido, hover cerrado = sólo la
capa; hover abierto = acento + capa.
Fuera del alcance y sin tocar: los enlaces DENTRO del panel
(`[data-navigation-menu-content] :is(a, …)`) conservan su `background`
shorthand — otra superficie, otro selector, otro día.
Gates: check 72 con CERO en los ficheros tocados · soma nav 9/9 · sema+morfo
550/550 · eidos 434/435 (el rojo es `skin-media-player`, ajeno, el mismo que
documenta el handoff del sidebar) · eidos-lint 31 morfo-backed / 0 invalid ·
component:audit PASS · rtl:check 0 · docs:check 0/640 · generated/base.css +41
líneas, sólo las del nav.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2 months ago |
|
dev
|
aa3f0e3511 |
uix(navigation-menu): navegar no fija nada, y el megamenú que se abre solo no debería sonar
T-1 de PLAN-sidebar.md §6. El `Link` emitía `commit-select + affirm` al navegar.
El libro lo nombra: TABLA 9.3, «Success de navegación — cambio de contexto con
logro», corregido como «shift + commit.fulfill si procede»; cap. 27 §2 «shift no
es commit… ir a otra pantalla no implica que la operación haya terminado»; y la
apertura de cap. 10, «una navegación no es exitosa por cambiar de pantalla».
Nada queda fijado al pulsar un enlace del nav: `aria-current="page"` es la huella
que deja el router DESPUÉS, no un estado que la parte fije.
Ahora habla el par de cap. 22 §9 —«Link → contact.press seguido de shift.navigate:
la presión no es la navegación»—, el mismo que la fila del Sidebar declaró ayer:
- `contact-activate` ANCLADO en el enlace pulsado (parte repetida → `partInstance`).
- `shift-navigate` en el `provider`, sin anclar: `data-event-*` es UNA ranura por
elemento, y el sujeto del cruce es el `<nav>` que cruza como unidad, no el
control que lo inicia. Sólo si el `<a>` tiene `href` — aquí no es un opt, viaja
en restProps, así que se lee del elemento que la parte ya tenía atado.
Esto REABRE la decisión del 2026-08-05 (ledger A-54), no la pisa: mover el evento
fuera del marco estaba bien; la familia era el defecto.
El pack estuvo a punto de borrarse, y esa habría sido la equivocación de la
sesión. Al quitarle la regla del commit se quedaba con dos selectores vacíos y
propuse retirarlo como ruido. El autor paró y pidió releer: la pregunta no era
qué escribe el fichero, sino qué debe decir la aparición del megamenú. Se abre
por HOVER, y medido con el default de familia un barrido del puntero por dos
triggers y salir de la barra emitía `open` · `open` · `close` — tres sonidos, 6
osciladores, sin un solo clic. Cap. 17 §3 («emerge — normalmente no necesita
sonido»), cap. 26 §7, cap. 32 §10-§11, cap. 5 §11. Así que `emerge-open` y
`emerge-close` son SILENT, la postura que `tooltip` y el flyout del `sidebar`
(D-SB.3) ya tienen para el mismo gesto. El pack DIFIERE del default y vuelve a
ser un pack.
Enmienda D.6 de book-deviations.md (PROJECT_CANON): `navigation-menu` sale del
alcance del `commit.subtle`, y quedan corregidas tres cláusulas suyas caducadas
— el `emerge-open/close` declarado desde el 2026-08-05, el `commit.subtle` que
murió en
|
2 months ago |
|
dev
|
aced677a15 |
uix(toolbar): la acción principal de un cluster ya puede decir su rango — y el gesto ya suena
`Toolbar.Button` tipaba contra el ButtonProps de SOMA ({id, disabled}): sin
variant, sin color, sin size. Un cluster de acciones donde UNA es la principal
no tenía cómo decirlo desde dentro, y la demo del app-shell dejaba «Nueva»
FUERA del toolbar como workaround documentado (A-112).
La ficha ofrecía dos salidas y mi primera recomendación fue la equivocada —
declarar el toolbar deliberadamente uniforme y consagrar el workaround. El
autor la tumbó, con razón: el eidos toolbar-button.svelte era un PASSTHROUGH
que dejaba el <button> nativo de soma, exactamente la clase de bug que
dialog-trigger (2026-06-19) y card-group-title (2026-06-27) ya pagaron, y el
precedente correcto no es menubar-trigger sino Form.Submit. Dos datos que el
primer análisis no tenía:
- El botón era MUDO. El morfo del toolbar sólo declara commit-toggle (el
group-item), así que pulsar una acción no emitía nada. Medido tras el
cambio: click → contact-activate estampado en el nodo + 8 nodos de audio,
donde antes 0.
- La uniformidad la dan los DEFAULTS, no la ausencia del eje: ghost/neutral y
el size del toolbar por contexto de eidos (toolbar/context.ts, calcado del
precedente ButtonGroup y con su misma razón: la receta del Button lee
data-size EN el nodo, un descendant selector no llega). El tipo estrecha a
SelectionVariant (solid | outline | ghost).
La forma es el Button consumer pattern entero: composición vía child de soma
(con el rename outerChild contra la recursión), y la receta CEDE el nodo —
cero cromo de botón en toolbar.css (regla 5); Link y GroupItem siguen siendo
superficie de la barra y los pinta ella. Antes de ceder, las dos recetas sobre
un mismo nodo producían un híbrido medido en el que solid/primary NO pintaba.
La doctrina que faltaba queda escrita en guides/component-guide.md §4: dos
clases de parte con forma de botón en una barra. ACCIÓN en barra (Toolbar.
Button, Form.Submit, Dialog.Trigger) compone el Button; control de SUPERFICIE
de barra (Menubar.Trigger: File, Edit) lo pinta la barra. El test: ¿significa
lo mismo fuera de la barra? Esa distinción vivía en un comentario de
menubar-trigger; el comentario ahora apunta a la doctrina.
Verificado en navegador (Playwright, servidor limpio): el nodo ES el Button
del canon (data-button + data-variant), solid/primary pinta (fondo primary,
tinta blanca), paridad exacta con el GroupItem por construcción — mismo bundle
--size-*: 36px/36px en md, 30px/30px en sm, con la herencia del size del
toolbar medida en vivo al cambiarlo. La demo del app-shell mueve «Nueva» AL
INTERIOR del cluster (workaround retirado, gap del block cerrado en su README)
y la demo del toolbar gana la acción «New» con controles vivos action variant
/ action color.
Gates: svelte-check 72/62 (base 73/62, sin regresión) · vitest eidos+blocks
470/471 (el rojo es skin-media-player, ajeno y documentado en el handoff) ·
blocks:check 0 errores / 19 blocks · docs:check 0/0. Los avisos de prettier de
los dos README ya fallaban en HEAD.
⚠️ El árbol compartido tiene ya encima trabajo NUEVO de otra sesión
(navigation-menu, PLAN-sidebar, book-deviations): este commit lleva sólo los
14 ficheros del eje A-112, verificados por lista.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
2 months ago |
|
dev
|
cae88ca15b |
uix(navigation-menu): un <ul> no es una región, y por eso el landmark salía sin nombre
El morfo declaraba el nombre por defecto de la navegación en la parte que pinta
el <ul>, con la razón escrita al lado: «the root <nav> delegates its name to the
list it wraps». La delegación no existe. El gesto que un lector de pantalla
ofrece para saltar entre las áreas de una página llega al <nav>, y llegaba a un
<nav> ANÓNIMO — con el nombre del consumidor puesto una capa más adentro, en un
elemento que ninguna navegación por landmarks visita.
Sobrevivió tres semanas de tier porque con UNA navegación en la página un
landmark anónimo es admisible, y todas las demos del componente y todos los
blocks de sitio montan una. Apareció en cuanto el app-shell montó dos ámbitos,
que es lo que un shell hace por definición (A-111). La APG es explícita: si una
página incluye más de un landmark de navegación, cada uno lleva su nombre.
El arreglo NO es el que la ficha proponía. Su paso 1 quería que la lista
heredase el nombre por aria-labelledby; el barrido de los morfos hermanos con
defaultElement 'nav' dijo otra cosa: breadcrumb (<ol>) y nav-tree (<ul>)
declaran aria: [] en su lista y nombran sólo el <nav>. navigation-menu era el
único fuera de esa forma, así que la pareja de nombre —el aria-label con su
suppression prop-falsy ariaLabelledby, y el aria-labelledby por propRef— sube
entera a la parte Provider y la lista se queda con su aria-orientation.
En soma, la fuente ariaLabelledby sube al nivel del runtime (la forma de
breadcrumb) y el wrapper DEJA de sacar aria-label de restProps: viaja con el
resto y gana el merge por política de naming, que es lo que A-85 dejó escrito y
lo que este componente no aplicaba. Se van con ello el opt ariaLabel y el
reenvío condicional que la List hacía a mano.
Y como la regla no estaba escrita en ninguna doctrina —grep de «landmark» en
morfo.md, canon/ y guides/ daba cero—, se escribe: architecture/morfo.md §Step 4
gana «A landmark is named on ITS OWN element», y nace el censo
morfo/landmark-census.test.ts, que falla si una parte con defaultElement 'nav'
no declara un attr de nombre EN SU PARTE. Probado en rojo por mutación tres
veces: deshaciendo el arreglo (navigation-menu.provider), retirando la excepción
(palabras.breadcrumb) y vaciando el catálogo, que es la mutación que impide que
un censo sobre nada pase en verde. El ámbito es 'nav' a propósito: main, header
y footer son únicos por página, y section y form sólo son landmark cuando ya
tienen nombre.
El guard destapó de paso un segundo caso de la misma clase: la parte Breadcrumb
de palabras declara un <nav> con aria: [] y nadie la nombra, ni en soma ni en
eidos. Queda como A-116 con EXCEPCIÓN FIRMADA por el autor: palabras es el eje
de otra sesión y su rama es compartida. La tercera fila del censo obliga a
retirar la excepción el día que esa parte declare un nombre.
Verificado con el nombre COMPUTADO desde el árbol AX de Chrome por CDP, nunca
leyendo el atributo (un aria-label en el DOM prueba el atributo, no el nombre),
con servidor recién arrancado y esperando la puerta de hidratación honesta:
/blocks/app-shell/preview navigation: ['Navegación principal',
'Menú de la aplicación',
'Migas de pan'] (antes: el 2.º null)
/uix/components/navigation-menu (sin label del consumidor)
el <nav> computa 'Principal' — el default del morfo,
traducido, sobre el landmark; el <ul>, sin nombre
Gates: 420/420 en morfo+sema+soma+eidos tocados · component:audit --only
navigation-menu PASS · morfo:check PASS · svelte-check 72/62 antes y después ·
docs:check 0/0. Los avisos de prettier de los ficheros tocados ya fallaban en
HEAD (comprobado con git show HEAD:… | prettier --check); el fichero nuevo va
formateado.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2 months ago |
|
dev
|
e2754a2b6f |
docs(sidebar): el handoff del eje, y las seis deudas que abrió en otros
En este eje no queda nada: nueve decisiones firmadas, cinco fases ejecutadas y verificadas, y la revisión adversarial pasada con sus cuatro hallazgos arreglados. Lo que queda es de OTROS ejes, y por eso el handoff los lista con nombre y sitio en vez de dejarlos en la cabeza de quien estuvo aquí: T-1 (`navigation-menu` emite `commit-select` al navegar — el antipatrón «success de navegación»), T-2 (nav-tree · anchor-nav · breadcrumb siguen mudos por el contrato que aquí se retiró), T-3 y T-4 (dos fichas del ledger de blocks que suponen lo contrario de lo que ahora hay), T-5 (el guard del bundle sólo ve tokens, no reglas) y T-6 (la densidad y el zoom no bajan a un subárbol, y eso no está escrito en ninguna doc). El handoff también deja por escrito las dos veces que hoy mintió el INSTRUMENTO y no el código: con la pantalla del navegador oculta rAF se congela y `getBoundingClientRect` daba 256px para un panel de 52; y leer `animationName` dentro del callback de un MutationObserver mide el instante anterior al flush, que es como di por viva una animación que moría 3,5 ms después. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
2 months ago |
|
dev
|
bae03e55c5 |
uix(sidebar): cuatro cosas que sólo se ven cuando alguien intenta refutarte
Revisión adversarial del eje (seis lentes, un escéptico por hallazgo): 21
hallazgos, 17 refutados, 4 reales. Los cuatro, arreglados.
1. El `MenuBadge` no llegaba nunca a `lg`. Indexaba la tabla de su excepción
por `part`, que ya venía capado en `md`, así que la rama `lg→md` era código
muerto y un sidebar `lg` sacaba el chip un paso pequeño. Ahora indexa por la
talla del sidebar: 26 · 26 · 30 · 36.
2. `emerge-close-sub` se sellaba en un nodo que el mismo tick ocultaba. El
`display:none` de `[data-state='closed']` mataba `dismiss-fade` antes de
pintar un frame y, como el pack silencia ese evento a propósito, la retirada
del flyout se quedaba sin NINGÚN canal: una ocurrencia declarada que no
ocurre. La regla se guarda ahora con `:not([data-event^='emerge-close'])`,
que es justo la ventana que el canal visual mantiene abierta. Medido:
opacidad 0,85 → 0,35 → 0,03 con la animación viva, y el nodo oculto a los
~516 ms, cuando el sello se retira.
⚠️ Mi primera sonda dijo que `dismiss-fade` corría, y era mentira: leía
`animationName` DENTRO del callback del MutationObserver, o sea antes del
flush que ocultaba el elemento. El instrumento midió el instante equivocado.
3. La pestaña sema de la demo clavaba las SEIS previsualizaciones en el panel.
Con cuatro eventos apuntando a otras partes, el ▶ de `contact-activate`
estampaba la familia en el panel de 16rem y `press-squeeze` encogía el panel
ENTERO —lo contrario de lo que el propio párrafo de al lado explica—, y los
dos `emerge-*-sub` no podían encontrarse con la regla que los silencia,
atada a `[data-sidebar-menu-sub]`. `SemaPanel` recibe ahora la acción
(parámetro opcional: las otras 23 páginas siguen con su thunk sin
argumentos) y la página resuelve la parte desde el contrato compilado.
Medido: contacto → una fila, open-sub → el sub, shift → el provider.
4. La fila de Gaps del README de `app-shell` seguía afirmando que «sus morfos
sólo declaran emerge-expand/collapse», que es exactamente lo que este eje
dejó de ser cierto. Reescrita: queda viva sólo la mitad que lo sigue siendo
—`NavigationMenu` emitiendo `commit-select` al navegar, el antipatrón
«success de navegación» del cap. 10 §12—, y se registra por qué se refutó la
lectura «la fila SELECCIONA la sección».
Gates: eidos-lint 49/0 invalid · component:audit PASS · rtl:check 0 ·
docs:check 0/639 · vitest eidos 434/435 (el rojo es ajeno) · suite del sidebar
8/8 · `check` con delta CERO contra la base medida con stash (72/72).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
2 months ago |
|
dev
|
63b2de03c7 |
uix(sidebar): un token de ESPACIO no es la altura de un control, y el raíl de iconos no es una constante
El componente vivía fuera del canon de talla: la fila clavaba
`min-block-size: var(--space-8)` —un token de la escala de ESPACIO haciendo de
altura de CONTROL, que es otra escala de densidad— y `font-size:
var(--font-size-sm)` escrito en el recipe, donde el guard del bundle no lo ve.
El rótulo clavaba `xs`, el trigger `sm`, el badge `xs`, y la acción no componía
`Button`: se quedaba con los 13,33px del user-agent y sin acuse perceptivo
propio.
Ahora el sidebar tiene eje `size` (xs..lg, default `md`, `data-size` en el
WRAPPER —nunca en el morfo, o la resolución de soma lo pisaría con undefined—)
y cada coordenada de la fila sale del bundle `--size-{k}-*`. Medido: 26/12 ·
30/14 · 36/16 · 44/20, con el glifo siguiendo (14/16/18/20) por `--icon-size`,
que es la costura que ya usa `Button` porque un `<Icon>` pinta su tamaño INLINE
y gana a cualquier regla de hoja.
El raíl de iconos deja de ser `3rem`: se DERIVA (fila + 2×padding), así que da
42 · 46 · 52 · 60 y a `md` ya no recorta la fila que tiene que contener.
Tres composiciones más, por la regla que ya existía (container→part capada en
`md`, precedente `Dialog.Close`): el `Trigger` deriva su talla, la `MenuAction`
pasa a ser `IconButton ghost` —y con ella llegan su cromo, su anillo, su capa
de estado y su `contact-activate`—, y el `MenuBadge` deriva con UNA excepción
firmada: baja un paso, porque con la regla al pie el chip sale a 36/16 junto a
una fila de 36/16 e iguala al control en vez de anotarlo.
El hover deja de ser un `--color-surface-raised` a mano y pasa a la capa
canónica `--state-hover`. Al medirlo salió un defecto que no buscaba: la fila
activa no daba NINGUNA respuesta al hover, porque su acento usaba el shorthand
`background`, que resetea el longhand `background-image` donde vive la capa.
Con `background-color` la capa compone encima, que es justo para lo que existe.
Verificado con Playwright headless (la pantalla del navegador estaba oculta y
ahí rAF se congela: las medidas de layout salían falsas). Gates: eidos-lint 49
morfo-backed / 0 invalid · component:audit PASS 0E/0W · vitest src/uix/eidos
434/435 (el rojo es `skin-media-player`, ajeno, idéntico en base) · rtl:check 0
· docs:check 0/639 · `check` con delta CERO contra la base medida con stash
(72/72).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
2 months ago |
|
dev
|
f6d5fa1595 |
uix(sidebar): la fila que navega decía «te sentí» a nadie, y el libro dice cómo se dice
«Navegar una fila es nativo y no suena» era una decisión de la fase 1 tomada en silencio (el plan la dejó como «decidir en fase 1») sobre una premisa falsa — «item = Link puro»—: la fila es `<button>` cuando no tiene `href`, la acción es un botón pelado y el `MenuItem` posee un flyout. Medido en navegador: pulsar fila, sub-fila o acción estampaba CERO; el Trigger sí acusaba recibo, porque compone `Button`. El libro no deja margen: cap. 22 §9 compone el enlace como «contact.press seguido de shift.navigate: la presión no es la navegación», cap. 27 §8 lo repite y cap. 22 §12 llama antipatrón al contacto mudo. Así que la fila declara las dos ocurrencias, y la aparición del flyout —cap. 26 §5-§6, un menú anclado— deja de ser un cambio de estado sin evento. Dónde se estampa cada una lo decidió la doctrina, no la comodidad: el gesto en la mano (la fila, anclado por instancia: es parte REPETIDA) y el cruce en la superficie que cruza como unidad (el provider). Eso evita la quinta pareja `queue` que yo iba a declarar: calendar ya movió su `shift-navigate` fuera del botón porque las dos ocurrencias se comían la única ranura y el press-squeeze no llegaba a pintarse. Voz: contact y shift toman la de su familia (`touch`, `slide`) sin escribir nada; los dos `emerge-*-sub` van SILENT como el tooltip — el flyout se abre al pasar el puntero, y un barrido por el raíl serían ocho apariciones sonando (cap. 26 §7, Criterio 12). El `trigger` NO declara contacto: lo trae por composición de `Button`. El `rail` sí, porque es una franja de cromo y nadie más lo estampa. Medido en el navegador tras el cambio: fila con href → `contact-activate` (press-squeeze corriendo) en ESA fila + `shift-navigate` en el shell; fila deshabilitada → nada; sub-fila → el mismo par; rail → contacto propio + `emerge-collapse` del panel; en modo icono, hover → `emerge-open-sub` (present-rise), hover repetido → nada, salir → `emerge-close-sub` (dismiss-fade). Suite nueva de 8 contratos, `check` con delta CERO contra la base medida con stash (72/72), morfo:check PASS, contracts sin fallos nuevos. Plan y decisiones firmadas: docs/process/PLAN-sidebar.md. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
2 months ago |
|
dev
|
23667277c1 |
docs(blocks): el shell dejó cinco filas, y una explica por qué nadie la había visto
Handoff reescrito para mañana y las cinco filas que abrió el `app-shell` fichadas en el ledger (A-111…A-115). La puerta de entrada de mañana es la primera. **A-111 — `NavigationMenu` deja su landmark ANÓNIMO.** El `aria-label` del consumidor se reenvía al `<ul>` de la parte `List` y el `<nav>` se queda sin nombre; el morfo lo declara así a propósito («the root delegates its name to the list it wraps»). Pero un `<ul>` no es una región: quien navega por landmarks ve el `<nav>`, y lo ve anónimo. Con UNA navegación en la página es admisible —y por eso lleva tres semanas de tier sin salir—; con dos ámbitos incumple la APG, y un shell de aplicación monta dos por definición. Medido en el preview: `navigation: ['Navegación principal', null, 'Migas de pan']`. La ficha lleva la forma propuesta en cuatro pasos: mover el default de naming de la `List` al `Provider` y que la lista apunte al root con `aria-labelledby`; precedencia de clase «naming» (el consumidor gana si dice algo); un guard que falle si un componente con `defaultElement: 'nav'` no puede recibir nombre en su root; y re-medir el censo. Toca morfo + soma, así que va con el aviso de mirar antes si la sesión del `sidebar` sigue viva ahí. Las otras cuatro: **A-112** `Toolbar.Button` tipa contra el `ButtonProps` de soma y no acepta `variant`/`color` · **A-113** la foundation emite los estilos semánticos y no los aplica a ningún elemento —Times New Roman en los 19 previews—, ARREGLADA en el reset del arnés pero con la pregunta de canon abierta · **A-114** `Sidebar.Inset` impone `overflow: auto` y se lleva el `sticky` de dentro · **A-115** no existe `description-list` y el panel de detalle del shell es el «primer detail-view real» que su propia ficha F5 pone como disparador. El handoff recoge además la corrección de fondo del día (la barra y el raíl son dos ÁMBITOS, no la misma navegación en dos tamaños), las dos averías del arnés que este block destapó, y lo que NO se ejecutó: la app de referencia en modo attach, que sigue siendo el único sitio donde el ecosistema entero se demostraría cableado. docs:check 0/0 (639). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
2 months ago |
|
dev
|
edf0639eea |
blocks(app-shell): la barra y el raíl no son la misma navegación en dos tamaños, son dos ÁMBITOS
Corrección del autor, y era una equivocación de fondo, no de forma. Yo había escrito que un menú en la barra sería «una segunda navegación dentro de un shell cuya navegación es el raíl». Es al revés: - la BARRA lleva la APLICACIÓN — su menú general, las áreas que tiene, y lo que es de la persona y no de la página (buscar, avisos, la cuenta). No cambia cuando el lector se mueve dentro de un contexto; - el RAÍL lleva el CONTEXTO en el que está — este proyecto, esta tabla: sus secciones y sus acciones. Cambias de contexto y el raíl entero cambia; la barra no se mueve. Es el `TopNav` + `SideNav` de Atlassian y el `TopBar` + `Navigation` de Polaris, que estaban en mi propio dossier. Y es también por qué una app publica DOS landmarks `navigation` legítimamente: la APG pide nombre único en los repetidos, y cada uno nombra un ámbito distinto. La demo modelaba mal: el raíl era el menú general. Ahora la barra lleva marca + `NavigationMenu` de la aplicación (Bandeja · Proyectos · Informes) y el raíl es el proyecto Apollo (Tablero · Conversaciones · Archivos + sus Acciones). El rastro se va con ella: su sitio es la cabecera de la PÁGINA, no la barra — cambia con cada vista mientras la barra no, y una barra que lo lleva crece una segunda fila en cuanto la ruta tiene tres niveles, que es lo que se midió antes de moverlo. De `site-header` se queda sólo la razón que era cierta: no es que sobre una navegación, es que la pieza es de un SITIO — `Sticky` por defecto (una barra de app bajo `scroll="main"` no debe pegarse) y `Container` MEDIDA (una barra de app va de borde a borde). Su forma marca · nav · acciones es la correcta. **Y un defecto de canon que sólo aparece con dos navegaciones**: `NavigationMenu` deja su landmark ANÓNIMO — el `aria-label` se reenvía al `<ul>` y el `<nav>` se queda sin nombre (el morfo lo declara así: «the root delegates its name to the list it wraps»). Un `<ul>` no es un landmark. Medido: `navigation: ['Navegación principal', null, 'Migas de pan']`. No se arregla desde fuera —nombrar la lista no nombra la región, y envolver en otro `<nav>` anidaría landmarks—, así que queda VISIBLE y registrado en los Gaps. Guards: `blocks:check` verde · `docs:check` 0/0 · `svelte-check` sin errores propios (de paso, `NavigationMenu.Item` exige `value` y no se lo pasaba). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
2 months ago |
|
dev
|
e5f30a501d |
blocks(app-shell): «no compone ningún block todavía» no era una razón, era una casilla vacía
El shell declara la excepción B-10 —los shells componen otros blocks por diseño— y no compone ninguno. Eso estaba escrito como si fuera una tarea pendiente. No lo es, y ahora dice por qué. El candidato obvio es `site-header`, y es la pieza equivocada aquí por tres cosas que están en su propio API: es `Sticky` por defecto (una barra de aplicación bajo `scroll="main"` NO debe pegarse — nada se desplaza por debajo de ella), envuelve su contenido en un `Container` MEDIDA (una barra de app va de borde a borde de su inset), y su forma es marca · nav · acciones + drawer móvil, o sea una SEGUNDA navegación dentro de un shell cuya navegación es el raíl. Es el cromo de un SITIO; esto es una aplicación. Lo que sí falta, y queda registrado como gap: lo que una barra de aplicación sostiene de verdad —disparador del raíl, rastro, buscador, avisos, menú de usuario— no tiene pieza en el tier. `user-menu` (F3.6) y `notifications` (F3.7) están planificados y sin construir, y el shell los compondrá POR esta misma excepción el día que aterricen. Hasta entonces la barra es el snippet del app, montada con canon (`Sidebar.Trigger` + `Breadcrumb` + `Toolbar` + `Button`), que es lo que enseña la demo. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
2 months ago |
|
dev
|
db7bcc3a55 |
blocks(hero): la mitad de escritorio no se oculta en el móvil, no existe — y el clip no se pide
F4 del eje de visibilidad por breakpoint: el primer caso real, y la receta
escrita donde un agente la va a buscar — el README del block que la usa.
Medido sobre build de PRODUCCIÓN (`build` + `vite preview`, Chrome), que es el
único sitio donde la afirmación es comprobable: a 375, cero `<video>` en el DOM
y NINGUNA petición de `video.mp4`; a 1280, uno y una (`206 Partial Content`).
En dev es falsa por construcción — el servidor renderiza a ancho 0 y sirve la
variante `base` antes de que la hidratación la pode.
Dos criterios que la receta fija para el tier. La puerta va DENTRO del snippet,
nunca alrededor del `<Hero>`: envolver el block duplicaría título, copy,
formulario y acciones por breakpoint, que es lo que hacen las secciones
por-breakpoint de Framer y la razón de que deriven; la media es lo único que
difiere, así que es lo único escrito dos veces. Y `display="contents"`: una
puerta decide presencia, no añade geometría.
La mitad móvil no es un vídeo más ligero: es NINGÚN vídeo. El Surface con
aurora cuesta cero bytes y sigue la paleta del tema.
⚠️ Hallazgo del canon, medido de paso y NO arreglado aquí: la media dentro de
un `Background.Layer` desborda la capa — el mínimo automático del ítem de
rejilla gana a `block-size: 100%`. Hero a 1280: capa 567px, vídeo 714px. En la
demo del propio canon con `Background.Video`: capa 288px, vídeo 435px.
`min-block-size: 0` lo colapsa exacto en ambos. `overflow: clip` lo escondía,
así que `cover` lleva recortando descentrado sin que se viera. Es del eje
`background`, cerrado el 2026-08-18: queda escrito en §Found while composing.
`launch.json` gana `preview-prod`: la entrada llamada `preview` arranca
`npm run dev`, así que no servía el build y la medida no se podía hacer.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2 months ago |
|
dev
|
1d91c11e89 |
blocks(app-shell): la demo no usaba los componentes que SIGNIFICAN lo que enseñaba
Rehecha entera. Cada pieza es ahora el componente del canon que corresponde al
acto, no una caja con el aspecto adecuado:
- las tres cifras son `Metrics` (label · value · delta), con la dirección
desacoplada de la valencia: en «sin asignar», BAJAR es bueno (`goodTrend`),
que es justo lo que las referencias hacen mal;
- la bandeja y la actividad son `Feed` — `role="feed"`, cada conversación un
`role="article"` con `aria-posinset/setsize` y su título con `aria-level`,
teclado de feed incluido. Medido: 2 feeds, 11 artículos, 11 encabezados;
- la barra superior es `Toolbar` (`role="toolbar"`, roving tabindex: cinco
controles cuestan UNA parada de tabulación) más `Breadcrumb` con `current`;
- la tipografía sale de los estilos SEMÁNTICOS del tema — `Text
style="label|caption|body"`, `Heading level` + `style` — en vez de tamaños
elegidos a ojo, que es lo que había.
**Y la avería que esto destapó, que era del arnés y afectaba a los 19
previews**: la foundation declara los `@font-face` y emite los estilos
(`--style-body-*`…) pero no los aplica a ningún elemento — un `Text` ancla su
familia en su recipe y todo lo demás HEREDA del documento. El arnés de blocks no
anclaba nada, así que `html`, `body`, `[data-sidebar]` y cada fila del raíl
computaban **Times New Roman** al lado de los `Text` en Instrument Sans. El
shell de docs sí lo ancla (`uix.css`); éste no. Anclado en `_lib/reset.css` con
los tokens del tema, no con una familia escrita. De paso, el sangrado de 40px
que el navegador pone a `dd`.
Tres huecos del canon que salieron al componer, registrados en los Gaps:
1. **`Sidebar.MenuButton` es mudo y `NavigationMenu.Link` no** — el mismo acto
con dos respuestas. El README del `Sidebar` firma que «navegar una fila es
nativo y no suena», pero entonces el `NavigationMenu` contradice la firma; y
en un shell la fila casi nunca navega: SELECCIONA la sección. Es de sema, no
del tier.
2. **`Toolbar.Button` no acepta `variant`/`color`** — tipa contra el
`ButtonProps` de soma (`{id, disabled}`), así que un cluster no puede decir
cuál es su acción principal. Aquí va al lado, como en las referencias.
3. **No existe `description-list`** y el panel de detalle es exactamente el
«primer detail-view real» que su ficha F5 pone como disparador.
Guards: `blocks:check` verde · `docs:check` 0/0 · `svelte-check` sin errores
propios (dos props inexistentes corregidas de paso: `Icon.Filter` y el
`variant` del `Toolbar.Button`).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2 months ago |
|
dev
|
026e07beaa |
blocks(app-shell): la demo estaba escrita a mano, no con la capa visual
La escribí sin haber leído la doctrina de eidos y salió lo que sale así: `<div
style>` donde hay primitivos, `inline-size: 16rem` clavado, `font-size` en un
`<strong>`, bordes y fondos a pelo, y contenido de relleno («Bloque de contenido
1»). Rehecha contra la tabla «Build contract» de `guides/component-guide.md`.
Ahora **cero literales y cero `style=`** en el fichero: color por token de rol,
espaciado por `--space-*` a través de los props de layout, tipografía por la
escala de `Text`/`Heading`, paneles por `Card`, separaciones por `Separator`,
anchura del aside por `--sidebar-width` (la medida del propio sistema, que
respeta densidad y `--scaling`).
Dos props que no hacían NADA, encontradas al reescribir:
- `Badge intent="affirm"` — `Badge` no tiene `intent`, tiene `color`.
- `AutoGrid minChildWidth="var(--container-width-sm)"` — le pasé un breakpoint
como suelo de pista, así que las tres tarjetas caían en una columna. Ahora
`Grid columns={{ base: 1, sm: 3 }}`, sin literal ninguno.
Y una tercera cosa medida que NO se arregla desde aquí: el aside llevaba
`Surface variant="soft"` y es **inerte** — `oklch(0.9911 0 0)` contra un fondo
de página de la misma claridad, o sea invisible en claro. Es **F15** de
`PLAN-blocks-quality.md` §6, gap de canon ya registrado («soft no acota un
panel, y Surface no tiene borde»). La frontera la pone un `Separator`, que es lo
que sí acota, y el porqué queda escrito en el fichero para que nadie lo
«arregle» con un fondo a mano.
Verificado mirando las capturas, claro y oscuro, 1280 y 375.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2 months ago |
|
dev
|
fd02780002 |
uix(box): ocultar por CSS descarga el vídeo igual, y evitarlo pedía no tener SSR
`visibleFrom` / `hiddenFrom` no ocultan: no renderizan. El subárbol no está en
el DOM, sus efectos no corren y su media no se pide — la mitad que
`display={{ base: 'none' }}` no puede dar. Los once contenedores que componen
Box (Section, Container, Flex, Grid, Stack, Group, Wrap, AutoGrid, Surface,
AspectRatio, Float) la heredan sin tocar sus ficheros. La puerta es un
`$derived` sobre `eidos.dom.isAtLeast(bp)` y un `{#if}`: sin atributos nuevos,
sin generador, sobre los breakpoints que configura el app.
Ninguna referencia lo hace así. Mantine (`hiddenFrom`/`visibleFrom`), Chakra y
Panda (`hideFrom`/`hideBelow`), Framer y Webflow ocultan por CSS y dejan el DOM
montado — Webflow lo documenta como coste de ancho de banda y Framer llega a
duplicar secciones enteras por breakpoint. Eligieron CSS porque con SSR una
puerta JS pinta la variante equivocada en el HTML (MUI devuelve un `matches` por
defecto en el primer montaje; Vuetify #17252 reporta los saltos de layout), y el
precio de evitarlo es adivinar el ancho por User-Agent o Client Hints.
Aquí ese precio no existe: el proyecto se despliega como SPA (`adapter-static` +
`fallback`, ninguna ruta con `prerender = true`), así que el primer render
ocurre en el navegador con el `innerWidth` real — el build es un `200.html` de
1,8 KB, shell puro. El que SÍ se paga está escrito en el tipo: cruzar un
breakpoint destruye el subárbol y su estado. Cuando el estado deba sobrevivir,
`display`. Sólo el dev server renderiza en servidor (ancho 0) y empieza a
descargar la media de la variante `base` antes de que la hidratación la pode:
queda como caveat de desarrollo en el README.
`base` sale del tipo en ambas props: `visibleFrom="base"` sería «siempre» y
`hiddenFrom="base"` «nunca renderiza», y ninguna de las dos es una cosa que una
prop deba poder decir.
Card, Banner, ScrollArea y Sticky rinden su propia raíz y NO heredan la puerta:
queda como gap diferido con la regla del `as` (≥2 casos reales). El puente de
SSR queda escrito con su disparador, no construido — hoy sería un atributo que
nadie lee.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2 months ago |
|
dev
|
9333acd661 |
docs(blocks): A-95 deja de ser «bloqueada por una pieza que no existe»
La pieza existe desde ayer. La fila pasa a ARREGLADO con sus cifras: solape 0px
entre el aviso y la cabecera, hit-test dentro de la cabecera, documento = 720 =
el viewport. Lo que la cierra no es un número mejor sino haber quitado la
pregunta que tumbó todas las propuestas anteriores («¿y si tenemos banners a
diferentes alturas?»): el aviso entra en flujo como una fila, así que su altura
es la que sea.
⚠️ Sigue siendo cierto lo que la ficha decía del `Affix`: fuera de un shell, un
aviso con `affix="top"` sigue tapando una cabecera pegada. Es el apilamiento
firmado, no un defecto.
A-109 gana disposición escrita (es del canon: el `role="banner"` va después de
los rest props; dos salidas, y se decide en una sesión del canon).
El handoff cambia de puerta: F3 está abierta y `app-shell` hecho. Queda escrito
lo que la sesión NO llegó a ejecutar — la app de referencia en modo attach, que
sigue siendo el único sitio donde el ecosistema entero se demuestra cableado, y
hoy no lo hace ninguno de los siete shells del repo.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2 months ago |
|
dev
|
6a53c3dc99 |
blocks(app-shell): la pieza que posee las alturas de la página, y por eso el aviso deja de tapar la cabecera
F3.1 del tier, con su fase 0 firmada delante. El block que faltaba: el que POSEE las regiones de una página de aplicación — sus landmarks, sus enlaces de salto y sus alturas. **A-95 se cierra por construcción, no compensando.** Bajo `scroll="main"` no hay nada fijo: el aviso es una fila, el cromo es una fila y la página es la fila que se desplaza. Medido con la tira puesta: aviso [0,54], cabecera [54,85], **solape 0**, y el hit-test en el centro de la cabecera cae en la cabecera (antes: 49px de solape y el clic en la tira). El eje `scroll` es el que Mantine expone como `mode` y Atlassian como `isFixed` por slot; `body` existe porque `docs-shell` lo necesitará para anclas y TOC. Compone `Sidebar` (sus tres colapsos, su drawer móvil, sus dos landmarks), `SkipLink`, `Sticky`, `Grid`/`Flex`/`Box`. Sin `.css`. Coordina tres booleanos (`navOpen · asideOpen · mobile`) por contexto, sin máquina y sin palabras: nada en un shell puede bloquearse, así que no hay frase que decir. Medido en navegador (Playwright; 1280 y 375, claro y oscuro, LTR y RTL): - landmarks por construcción — 1 banner · 1 main · 2 navigation NOMBRADOS · 2 complementary NOMBRADOS · 1 contentinfo; encabezados 1-2-2-2-2 sin saltos. - `scroll="main"`: documento 720 = viewport, el main scrollea dentro y la cabecera se queda en 0 tras desplazar 900px. `scroll="body"`: el documento scrollea y la cabecera SE PEGA (top 0 a 900px de scroll). - teclado: los tres enlaces de salto son las tres primeras paradas y Enter deja el foco en el `<main>`. - 375: el raíl es drawer, devuelve el foco al trigger con Escape, el aside se pliega y el documento no crece. RTL: sin desbordamiento horizontal, raíl a la derecha, aside a la izquierda. Cuatro averías que sólo aparecieron midiendo, y las cuatro son doctrina ahora: 1. `minHeight` es un SUELO, no un techo: con `100dvh` ahí el documento crecía con el contenido. Es `height`. 2. Un grid que sólo declara filas tiene UNA columna implícita `auto`, que se encoge a su contenido: la página salía en una tira de 32px al lado del raíl. 3. `Box` declara `flex-grow/shrink/basis`, así que pisa el `flex: 1 1 auto` de la receta del inset. Quien está más abajo en el árbol tiene que PEDIR crecer. 4. Un ancestro con `overflow` se lleva el `position: sticky` de dentro. El `overflow: auto` de `Sidebar.Inset` dejaba la barra sin pegar bajo `body` mientras `data-stuck` decía que sí — el atributo dando la razón a una página que no la tenía. Por eso el shell pone su propia caja: gap de canon anotado (el inset debería dejar elegir si es contenedor de scroll). **Y una avería del ARNÉS que este block destapó**: los 19 previews del tier llevaban los 8px de margen por defecto del navegador, así que ningún block se enseñaba a sangre — contra la regla dura del propio tier. Medido: `x: 8, y: 8, w: 1264` en 1280, la página compuesta incluida, cuyo README cita cifras a sangre. Invisible porque todos scrollean; deja de serlo con un shell que llena el viewport. Arreglado en el reset del arnés. De paso, en el canon `skip-link`: el enlace del panel complementario decía «Ir a la barra lateral», que es como todo el mundo llama al raíl de NAVEGACIÓN. En una página que tiene los dos, nombraba al que no era. Ahora «Ir al panel lateral». Guards: `blocks:check` verde con 19 blocks · `docs:check` 0/0 (638) · `svelte-check` 74, ninguno aquí. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
2 months ago |
|
dev
|
f3bf6a0299 |
docs(blocks): la ficha del shell cabía en cinco líneas porque no miraba el ecosistema
Fase 0 de F3.1 `app-shell`, firmada. La ficha original se escribió antes de que existieran el canon `Sidebar` y la capa `affix`, y el autor preguntó lo que había que preguntar: si su alcance tenía delante `active-app` y `active-uix` enteros. No los tenía. Las cuatro decisiones que se firman, y lo que las obligó: - **Q1 — el block NO cablea servicios.** La integración del ecosistema se demuestra en una app de referencia en app-land, no dentro del block. Un shell que leyera `App.session` para dibujar el menú de usuario sería una raíz de composición disfrazada: funcionaría, y metería el arranque del ecosistema dentro de una pieza que ha de poder caer en cualquier app. - **Q2 — dos modelos de scroll por prop.** `main` (rejilla 100dvh, sin fixed, sin números) es lo que cierra A-95 por construcción; `body` es lo que `docs-shell` necesitará para anclas y TOC pegada. - **Q3 — cabecera dentro del inset.** El provider del `Sidebar` ES la fila flex, así que su `Trigger` sólo vive dentro. Una cabecera a todo lo ancho exigiría partir ese provider: queda como gap de canon para v2. - **Q4 — canon `skip-link` + uno por región montada** (técnica G124). De paso, tres cosas que estaban mal escritas y ahora lo dicen: - El dossier afirmaba que **ninguna referencia trae skip-link** y que era superación nuestra. Es falso: Polaris lo trae en `Frame` y Atlassian genera un menú entero. La superación real es generarlos del mismo contrato que estampa el landmark. Y el icon-rail no es de Mantine (su `collapsed` es booleano); es de shadcn, AntD, Toolpad y Atlassian. El dossier tampoco miró nunca el `navigation-system` actual de Atlassian, y el `page-layout` que sí miró está deprecado. - **D-BLK.6 ha derivado**: la celda dice «ni prefs ni langs ni eidos» y la doctrina vigente (`blocks.md` §Services) sancionó dos servicios en julio y agosto. Queda enmendada con lo que sigue siendo cierto: ningún block CREA ni cablea servicios. - **E-5 está desfasada**: `Command.Dialog` ya trae el atajo (`shortcut`, `mod+k` por defecto). El listener a mano de F4.1 no hay que escribirlo. - **F3.2 `auth`**: la ficha dice cuatro vistas y el dominio tiene seis. Falta `update-password`, que no es un lujo — es donde aterriza el enlace de recuperación, y sin ella el camino de `recover` no termina. `blocks.md` gana un párrafo «Shells» bajo §Conventions: qué poseen (geometría, landmarks, alturas) y dónde está la línea (la raíz de composición es de la app). Verificado en código antes de escribirlo: `Sidebar.Inset` acepta `child`, `Box` expone minHeight/position/overflow y `Grid` templateRows —la rejilla del shell no necesita CSS propio—, y `Sticky` expone `root`. docs:check 0 errores, 0 avisos (635 docs). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
2 months ago |