10 Commits (468a9d1134d697546f1b36231d6773d6324a5faa)

Author	SHA1	Message	Date
dev	468a9d1134	style: prettier de una sola vez sobre el repositorio (F5 del cierre, parte 3) ... Formato puro: `npm run format` (dos pases; siete ficheros no convergían en el primero) sobre todo lo que .prettierignore no excluye (web/ congelado, .claude/, artefactos generados). Este commit va en .git-blame-ignore-revs. Neutralidad medida fichero a fichero, compilando y minificando con esbuild (y con el compilador de Svelte, cliente y servidor, para .svelte) la versión de HEAD y la formateada: 1 031 ficheros de código idénticos; 9 CSS que solo difieren en espacios pegados a un paréntesis (`var( --x )` frente a `var(--x)`), que CSS no tokeniza como significativos; 510 Markdown sin compilación posible (docs:check los valida). Los dos generados y el guard que dependía del formato se resolvieron en el commit anterior. Verificación sobre este árbol: npm run lint exit 0 · gate entero verde salvo focus-census, arreglado en el commit anterior y re-ejecutado (9/9): check:gate OK (src/ y scripts/ a cero) · docs:check 0/0 · arts/blocks/packs/rtl/ translations/agent · eidos:lint 0 inválidos · apps:check (boot 27/27, 0 errores) · suite 465/466 → 466/466 con el guard corregido · build de la raíz exit 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	3 weeks ago
dev	4f3425783b	docs: el contrato de consumo — una app del workspace consume UIX como fuente (docs/consuming.md) ... El framework no tenía ni una línea sobre cómo se consume desde fuera de su propio árbol de demos: todo el corpus asumía acceso al repositorio. El autor decidió que la app que viene después lo consume COMO FUENTE, en un workspace de este repositorio, sin paquete npm ni exports ni bin. docs/consuming.md es ese contrato, sección a sección, enlazando lo que ya tiene página propia en vez de copiarlo: dónde vive la app (apps/<name>, un solo node_modules y una sola copia de Svelte), los alias (resolveUixAliases en kit.alias), el modo runas por config, la raíz de composición standalone (attach existe y no lo consume nadie), el CSS y los assets servidos por URL (fuentes y sonidos se copian al static/ de la app), y el boot pre-hidratación (la receta de la guía de theming con <uix> = ../..). docs/README.md lo enlaza en E4 y en «I want to…». La guía de theming deja de llamar «fila abierta» al empaquetado: el consumo es un contrato de workspace. La app base de F3 es el primer consumidor real y la verificación del contrato: lo que no se sostenga al construirla se corrige aquí. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	3 weeks ago
dev	29e581c721	feat(active-uix)!: el boot lo compila el build del SITIO con su propio esquema, y lo que UIX escribe en <html dir> lleva marca de propiedad (fila 2 del boot, F1 del cierre) ... F1 del plan de cierre del framework. Cierra el último trabajo del eje boot. EL DEFECTO. El boot por defecto compilaba un catálogo de preferencias de UN solo idioma (createDefaultUixPrefsSchema), y la raíz sembraba su entorno leyendo el <html dir> que el boot acababa de escribir: un usuario árabe de una app multiidioma no veía un parpadeo, se quedaba en LTR TODA la sesión, porque el runtime tomaba la salida del boot como si la hubiera declarado la página. EL COMPILADOR POR SITIO. Una sola fusión, composeUixPrefsSchema, la consumen createActiveUix y el boot: no puede derivar. El generador acepta --schema y --out (el especificador boot/boot-schema.ts apunta al esquema del sitio o a boot/default-schema.ts); los guards (sin runas, techo de tamaño, ASCII, sin </script, valores string por atributo) son errores del COMPILADOR con mensajes para el consumidor, porque ahora el artefacto lo produce el sitio. Un esquema que importa el barrel $prefs se rechaza nombrándolo. scripts/uix-boot-check.ts es el guard de rancidez: plugin de Vite que tumba el build con un artefacto viejo (probado con vite build real) y función para CI. Delta cero por esquema: por defecto, multiidioma con árabe, ejes redefinidos y esquema parcial. LA MARCA DE PROPIEDAD, diseño firmado por el autor. El canon de dirección dice que <html dir> es una proyección y nunca una fuente, con una sola excepción: el dir del AUTOR en la plantilla o el servidor. El boot rompió la premisa de esa excepción. Todo lo que UIX escribe en <html dir> lleva ahora PREFS_DIR_PROJECTED_ATTR (el boot con valor «boot», cada proyección del runtime con un token de instancia); la semilla solo adopta un dir SIN marca. Un dir escrito por script no es una fuente: en ejecución la dirección se afirma con prefs.setIntent('direction') o options.prefs.environment, que ganan a la semilla. Se descartaron, midiendo, la marca con valor (cierra el script y congela la dirección al navegar entre layouts) y la inferencia por valor. dispose solo retira lo que todavía es SUYO: SvelteKit crea la raíz del layout nuevo ANTES de destruir la vieja (medido), y un retiro a ciegas dejaba el <html> de la raíz nueva sin dir, lang ni data-motion/sound/haptic (medido hoy: los nueve atributos a null). Mismo principio que el unstamp de sema, que comprueba data-event-id. esbuild se declara como devDependency EXACTA 0.27.4: los bytes del boot y su hash dependen del minificador, y una subida dentro de un rango rompería la sincronía. Boot 15 198 B, sha256-hsqdGYcrRu3oEc0Q3G/A67ApQT3q9c/vT9zMDgxROg8= (el hash se mueve: firmado por el autor). VERIFICACIÓN. Constructor Opus en cuatro rondas y adversarial Opus en dos pasadas independientes, con sus reproducciones repetidas tras cada cierre: en Chromium, entrar en árabe y pasar a inglés y a español sigue al idioma, y al revés también; el dir de plantilla gana antes y después de hidratar y en una raíz recreada; una raíz recreada sobre una viva sigue al idioma con y sin boot; tras create b → destroy a, <html> conserva lo que proyectó b. Diez defectos declarados por el adversarial, cerrados (D1–D10): marca de propiedad, esquema parcial que estampaba "undefined", vigilante de dev mudo, plugin sin test, receta de CI que no cargaba en jsdom, cifras y prosa, y un vite build real que se cae cuando el boot no compila. Mutaciones en rojo, restauradas byte a byte: la proyección no marca · dispose sin guard de dueño (también repetida por el coordinador: 3 rojos) · la semilla compara valor en vez de presencia · marcar el dir del autor. Suite entera 463 ficheros / 5 437 tests, exit 0 · check 0 errores en src/ y en scripts/ (89 en web/, ledger intacto) · docs:check 0/0 · generate:boot dos veces byte-idéntico. LO QUE NO CIERRA (al ledger de cierre): (1) PREEXISTENTE — en la misma navegación entre layouts, el ActiveEidos.dispose de la raíz vieja sigue retirando data-theme/mode/density/scaling de la raíz nueva; exige cambiar el dispose de eidos, otra capa. (2) La propiedad de los atributos proyectados cuelga de la marca de dir: si la plantilla declara la dirección, dispose deja lang y data-motion puestos cuando la raíz se desmonta sin sustituta (benigno). (3) Sin boot, un script que escribe dir antes de la primera raíz es indistinguible de la plantilla y se adopta. (4) El vigilante de dev no reacciona a ficheros nuevos ni a inputs fuera del root. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	3 weeks ago
dev	9ae58c2365	feat(active-uix)!: el boot viaja como CUERPO CONSTANTE con los parámetros en un atributo — un hash de CSP fijo, sin node:fs, y la delta deja de confirmarse a sí misma (fila 1) ... La receta documentada del boot pre-hidratación no funcionaba en ningún despliegue real, y el panel de diseño de nueve agentes que el autor pidió lo confirmó midiendo: con el `render.ts` anterior, un build REAL de SvelteKit con adapter-static revienta el prerender con `ENOENT …/output/server/generated/boot.js` y devuelve un 500. La causa: `renderUixBootScript` leía el bundle DEL DISCO junto a su propio módulo, y una vez empaquetado ese fichero no está ahí. FORMA NUEVA. El generador compila una entrada propia (`boot/entry.ts`), sin `globalName`, y emite el MISMO fichero de siempre (`generated/boot.js`, sin borrar nada) como módulo con dos constantes: el texto exacto del script y su `sha256-…`. `renderUixBootScript` pierde `node:fs`, `node:path`, `node:url`, la caché y el envoltorio que estaba ESCRITO A MANO: al no haber `globalName`, la llamada la hace la propia entrada compilada. «Compilado, no escrito» sale reforzado, no rebajado. LOS PARÁMETROS VIAJAN EN UN ATRIBUTO del mismo `<script>`, no dentro del cuerpo. Consecuencia, que es el punto entero de la fila: el cuerpo es CONSTANTE, así que su hash es constante por versión del framework, igual para todos los sitios y todos los `themeIds`. La guía pasa a tener UNA sola receta, por hash, que cubre prerender, SSR y hasta `mode: 'nonce'`; el nonce baja a salida de emergencia. Un bloque `application/json` hermano se descartó con razón medida: rompería la invariante de que el tag parsea a exactamente un `<script>` y un minificador de HTML podría borrarlo sin que nadie se entere. TRES MENTIRAS DE LA GUÍA, CORREGIDAS. `event.locals.nonce` no existe en Kit 2.55.0 (cero ocurrencias en su código; `respond.js:168` es `locals: {}`), así que la receta anterior pasaba `undefined`, el navegador bloqueaba el script y volvía el flash sin un solo error. El placeholder estaba ENCIMA de `%sveltekit.head%`, donde la política de prerender de Kit no lo alcanza: eso es evadir la CSP, no cumplirla, y no vale cuando la política llega por cabecera. Y el `html.replace` con cadena interpreta `$'`, así que ahora la receta usa reemplazo FUNCIÓN. Se añade el aviso que puede tumbarle la página al consumidor: añadir un hash a un `script-src` que lleva `'unsafe-inline'` hace que el navegador IGNORE `unsafe-inline` y bloquee los demás scripts inline del sitio, incluido el arranque de Kit. EL CRITERIO SE CORRIGE. `boot-delta.test.ts` gana un tercer snapshot contra un documento LIMPIO. El anterior arrancaba el runtime sobre el documento ya sellado, y como `directionDimension.derive` devuelve `env.direction` antes de derivar del idioma y el entorno se siembra leyendo el `<html dir>` que el boot acaba de escribir, la columna `dir` se confirmaba a sí misma. Medido con el boot clavado a `rtl`: los cinco rojos caen todos en la lectura nueva y ninguno en la anterior. AUDIT DEV. La raíz compara en desarrollo su primera proyección con lo que ya hay en `<html>` y NOMBRA los ejes que discrepan. Convierte en ruidosos cinco fallos que hoy son idénticos y mudos: pin olvidado, `themeIds` incompleto, `storageKey` distinto, artefacto rancio y script bloqueado por la CSP. Artefacto 14 666 B, `sha256-5fulJ/2Q6DttR258KqIhWSwfm5g7973BEzzzq14fapY=`, generación determinista. Verificación: suite entera 461 ficheros / 5404 tests, exit 0 · check con 0 errores bajo `src/` y bajo `scripts/` (89 en `web/`, ledger intacto) · docs:check 0/0/819 · `npx vitest run src/uix/active-uix` 9 ficheros / 97 tests. El test nuevo `boot/pack.test.ts` empaqueta `render.ts` y lo ejecuta: sale ROJO contra el código anterior con el ENOENT literal, y es lo único que impide que esta clase vuelva. Adversarial Opus independiente (árbol byte-idéntico al terminar, 14 mutaciones revertidas): midió el hash bajo CSP real contra un servidor HTTP en Chromium 145, Firefox 146 y WebKit 26, con control negativo bloqueado; montó una app SvelteKit real siguiendo la guía al pie de la letra y la vio construir, prerenderizar y arrancar sin violaciones; y probó el ENOENT con un build real. Declaró 5 defectos del lote, ninguno bloqueante, cerrados en una segunda ronda y re-verificados uno a uno con su reproducción original: un universal falso en un comentario, la puerta del artefacto sin validar el cuerpo (ahora con guard propio importable), la constante del hash sin comillas para quien escriba su propia cabecera, el audit que SÍ viaja al bundle de producción (1 428 B medidos, no un supuesto; no CORRE, gracias a un ternario que el bundler no pliega) y el eje que se nombraba a profundidad 2 y ahora va en el mensaje. La redacción del guard del artefacto, último defecto de la segunda pasada, la corregí yo: corre en cada render, 76 us con artefacto frente a 1,49 us sin él, medido. Filas que deja para el autor: los 1 428 B del audit en producción, si se gatean con una bandera que el bundler pliegue · el audit queda mudo si el runtime se desecha en el mismo turno · la fila 2 debe decidir si la puerta verifica que el hash describa al cuerpo. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	3 weeks ago
dev	418297a82a	test(active-uix): el boot se prueba por el tag REAL que inyecta el sitio, y el nonce se valida contra la gramática de CSP ... `renderUixBootScript` es el único camino de producción al boot pre-hidratación (guía de theming, §59) y ningún test lo importaba. La suite de delta cero no lo llamaba: ejecutaba una COPIA de su envoltorio con `new Function`, la segunda implementación que la doctrina del boot prohíbe («compilado, no escrito»). Nadie vigilaba que `pins` llegase al boot, que el escape de `<` impidiera cerrar el tag antes de tiempo, ni el atributo `nonce`. Tres decisiones firmadas por el autor: 1. `boot/render.test.ts` (nuevo, jsdom): forma del tag (un `<script>`, un solo cierre, ningún `<!--`); nonce ausente, válido (base64 y base64url) e inválido; reenvío de TODOS los parámetros medido por comportamiento en `<html>` (`defaultLocale`, `pins`, `themeIds`, `storageKey`); ida y vuelta byte a byte de una clave y un themeId hostiles con `</script>` y `<!--` sin inyectar markup; ningún global tras ejecutar; higiene del bundle generado. 2. La suite de delta ejecuta el tag real: muere `runGeneratedBoot` con su `new Function` y `BOOT_SOURCE`. El único ejecutor vive en `test/boot-script-tag.ts` (DOMParser inerte + `vm.runInThisContext`, script clásico en ámbito global). No eval indirecto: el bundle abre con `"use strict"` y el eval estricto guarda sus `var` en un entorno propio, así que una fuga de `__uixBoot` habría sido invisible (medido en Node y Chromium; un control positivo lo pone en rojo si vuelve). 3. El nonce se valida contra CSP Level 3 `base64-value` y fuera de ella lanza `ActiveUixInvalidBootNonceError` (`uix::boot.invalid_nonce`, con la longitud, nunca el valor). `JSON.stringify` escapaba para JavaScript y no para un atributo HTML: `a"b` salía como `nonce="a\"` más un atributo basura, y `&lt;` llegaba decodificado. La validación ES el escape. Razón precisa (corregida por el adversarial antes de anclar): fuera de la gramática el valor no es un `nonce-source` válido; Chromium 145 y Firefox 146 no lo casan, WebKit 26 tolera `=` de más, así que ninguna política portable puede apoyarse en él. El nonce de SvelteKit 2.55.0 (`btoa` sobre bytes aleatorios) siempre la cumple. `render.ts` localiza el bundle con una ruta de disco resuelta desde el módulo en vez del idioma `new URL(…, import.meta.url)`, que el entorno jsdom de Vitest reescribe a `self.location`. Medido por el adversarial con un build REAL de Vite 7.3.1: neutro en producción (build SSR suelto y con disposición tipo Kit: las dos formas se comportan igual), funciona en dev SSR, y solo la nueva funciona bajo Vitest jsdom. El barrel exporta la clase de error junto a las otras seis. Verificación: suite de `boot` + `test` 5 ficheros / 29 tests → 6 / 52 · check con 0 errores bajo src/ (89 en web/, ledger intacto) · docs:check 0/0 · suite entera 459 ficheros / 5389 tests, exit 0. Mutaciones del constructor, cada una restaurada byte a byte: `pins` fuera del reenvío 4 rojos (2 de ellos en la suite de delta: prueba de que ya pasa por el camino real) · sin escape de `<` 2 · sin envoltorio 1 · sin validación 10 · ejecutor vuelto a eval 1 · gramática sin `^` 6 · `storageKey` sin reenviar 2. Adversarial Opus independiente (árbol intacto al terminar): gramática = el ABNF exacto, 0 discrepancias en ~600 000 entradas contra un oráculo propio; suite sin dependencia de orden en 7 semillas; 3 defectos del lote cerrados en una segunda ronda — la frase absoluta sobre CSP en cuatro sitios, y dos mutaciones que sobrevivían (clave en minúsculas; regex con flag `g` según el orden), re-ejecutadas después por el coordinador: rojo en orden por defecto y con las semillas 42 y 777. Filas PREEXISTENTES que destapó el adversarial, no tocadas aquí (van al handoff para el autor): en cualquier build de servidor empaquetado `renderUixBootScript` lanza ENOENT al leer el bundle; la receta de la guía pasa `event.locals.nonce`, que Kit nunca rellena (el navegador bloquea y vuelve el flash, sin error); y el `html.replace` con cadena interpreta `$'` y puede cerrar el script. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	3 weeks ago
dev	f875f60b97	feat(eidos)!: un escalar es una instancia CLAVADA — mueren el throw de la puerta 2 y las fuentes por eje (c') ... Cierra el estado INTERINO de e3c0899dd. `resolvePreferences` lanzaba con `uix` + escalar y `ActiveEidos.create()` inyecta `uix` SIEMPRE, así que la regla no decía «no mezcles dos motores»: decía «ningún escalar, nunca», y toda demo que clava un panel en oscuro arrancaba con excepción. Forma firmada por el autor (c'): - Pines SÍ: `theme` / `mode` / `density` / `scaling` en `ActiveEidosOptions` son PINES — el eje queda clavado en la instancia y gana sobre la fuente, prefs incluido (precedente en el mismo constructor: `options.dom ?? options.uix?.dom`). Un eje clavado sigue suscrito: `apply()` corre y lo encuentra quieto. - Sources por eje FUERA sin shim: `modeSource` / `densitySource` / `scalingSource` eran la API del segundo motor. La puerta de sustitución ENTERA sigue siendo `preferences`. Mueren `createComposedPreferenceSource`, `createStaticValueSource` y `PREFERENCE_OPTION_KEYS`; nace `createStandalonePreferenceSource(dom)`: sin primer motor no hay segundo — standalone sigue al SO EN VIVO para `mode`. - Sin throw. UNA precedencia por UN envoltorio (`createPinnedPreferenceSource`) sobre la puerta que responda (`preferences` · `uix.prefs` · standalone): `pin ?? fuente ?? fallback` en las tres. - Una función pura, dos lectores: `src/uix/eidos/lib/visual-preference.ts` (`VisualPreferencePins` + `resolveVisualPreference(pin, value)`), importable por el boot compilado como `lib/theme-id.ts`. `ActiveEidosOptions extends VisualPreferencePins`; `UixBootParams.pins` lo toma entero; `renderUixBootScript({ pins })` los embarca. DOS parámetros y no tres: el fallback no es compartido (el boot resuelve siempre los cuatro ejes; en runtime lo aporta cada fuente) — acta en changelog §60. - Delta cero a CINCO casos: instancia clavada a dark con sobre en light (ni un attr se mueve al hidratar) + familia clavada `acme` con modo de prefs (`acme-dark` a los dos lados: el pin atraviesa `resolveThemeId`). Mutaciones probadas: sin pin en el boot → 2 rojos; sin pin en el envoltorio → 2 rojos; restauración por sha256. - `contracts.test.ts`: retirado el guard «guards UIX docs shell from writing visual prefs through ActivePrefs» — codificaba la doctrina REVOCADA el 2026-09-14 (escribir `theme` en prefs es el camino canónico); no se invierte: un guard sobre un árbol congelado que se reconstruye no mide nada. Acta en §60. - Coste en el árbol congelado: diez demos pasan `*Source` y pierden el tipo → ledger `check-debt.ts` +22 (8 entradas nuevas, 2 subidas), cada una con causa fechada (excepción firmada 2026-09-13). `src/` a CERO. - Docs: eidos.md §preferencias · prefs README §Eidos Boundary · guide.md (`pins`, tercer parámetro del boot) · changelog §60 · active-uix / overview / active-architecture / blocks (snippets con `modeSource` al flujo canónico). Verificación: vitest eidos+active-uix+prefs+contracts+value-channels 59/640 · check 95 = 73 + 22 exacto, src/ 0 · check:gate OK · docs:check 819 OK · generate:boot 15104 bytes con sync verde · adversarial Opus independiente (informe en el handoff). Constructor + adversarial Opus 5; la sesión coordina. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>	4 weeks ago
dev	e3c0899dd8	feat(prefs)!: un motor, un sobre, un codigo — mode/theme/density/scaling son prefs, sobre canonico y boot compilado ... Auditoria P2 #2: los attrs de preferencias se estampaban solo en cliente tras hidratar (app.html sin script, build estatico sin servidor) — flash claro para todo usuario dark — y no podia existir un script de arranque porque no habia contrato de persistencia (PrefsIntentStorage lo aporta cada app) y eidos llevaba un SEGUNDO motor de preferencias (theme / modeSource / densitySource / scalingSource por opciones, sin persistir), por doctrina escrita en arts/prefs/README.md («UIX does not turn it into prefs.theme»). El autor REVOCA esa doctrina. UN MOTOR. `mode` es una dimension de prefs junto a `motion` (mismo patron, `resolveTheme` de $libs/theme, que ya existia como gemelo de `resolveMotion`); `theme` (id de familia), `density` y `scaling` las declara la RAIZ en un modulo PURO (src/uix/active-uix/prefs-schema.ts) — arts/prefs no importa src/uix. Eidos lee `uix.prefs` por su puerto `ActiveEidosPreferenceSource` (src/uix/eidos/prefs-source.ts), como ya consume uix.langs / uix.dom / uix.motion. El resolver de tema baja a una funcion pura `resolveThemeId(theme, mode, isRegistered)` (src/uix/eidos/lib/theme-id.ts); los cuatro nombres de attr de eidos a src/uix/eidos/lib/attrs.ts y los de la proyeccion a src/arts/prefs/dom-attrs.ts: modulos sin Svelte, porque el boot los comparte. UN SOBRE. src/libs/prefs/document.ts: `uix.prefs-intent` v1 bajo la clave `uix.prefs`, espejo del documento de eidos (kind + version estrictos, version desconocida se RECHAZA). Solo intencion — nunca efectivo ni entorno. Adaptador localStorage canonico creado en la raiz standalone (`prefs.storage`: propio gana, `false` desactiva). HIDRATACION SINCRONA: el bridge awaitea `load()` aunque sea sincrono y produciria una primera resolucion con defaults y un salto un tick despues — el flash movido de sitio; la raiz lee el sobre ANTES de crear el motor y lo pasa como `intent`; el bridge queda solo para persistir (skipHydrate). UN CODIGO. El boot no se escribe: se COMPILA con esbuild desde los mismos modulos puros (src/uix/active-uix/boot/boot.ts → generated/boot.js, 15.009 bytes / 5.625 gzip, IIFE sin globales, cero Svelte; test de sincronia, precedente generated/base.css). `renderUixBootScript(params)` (boot/render.ts) es Kit-agnostico: el framework entrega el string; el hook de Kit son tres lineas de la app (receta en docs/theming/guide.md, NO cableada: el layout congelado lleva persistencia propia). Estampa los NUEVE attrs (dir lang data-motion data-sound data-haptic data-theme data-mode data-density data-scaling) → DELTA CERO al hidratar, probado por integracion con la raiz REAL (boot/boot-delta.test.ts, tres casos) y por tres mutaciones (sin hidratacion sincrona → rojo; constante de attr cambiada en un solo lado → rojo; boot compilado con `data-modo` → los tres casos rojos). Hallazgo del test de delta cero: la raiz no aplicaba el entorno del navegador (esperaba que el app llamara detectBrowserEnvironment en onMount) — ahora lo siembra ella (guardado por `document`) y observa sus cambios (watchBrowserEnvironment → patchEnvironment), sustituyendo el listener que eidos tenia en createSystemColorSchemeSource. Cifras: vitest prefs+libs/prefs+active-uix+eidos+value-channels 57/593 · suite completa 453/5306 · check 73 (src/ a cero; ledger intacto) · check:gate OK · eidos:lint 0 · docs:check 0/0 · morfo:vocabulary, arts/blocks/packs/rtl/translations/agent:check OK. ESTADO INTERINO, firmado para manana (acta en CONTINUE-audit-p0.md): `resolvePreferences` LANZA con `uix` + escalar/source (forma firmada originalmente); medido despues, `ActiveEidos.create()` inyecta `uix` SIEMPRE y todas las demos pasan escalares o sources (>=12 sitios, incluido web/routes/uix/+layout@.svelte:511) → el sitio de demos lanza al arrancar hasta la forma (c'): pines si (escalar explicito gana, precedente `options.dom ?? options.uix?.dom`), sources reactivas por eje FUERA, sin throw, pines en el boot. Pendientes anotados: contracts.test.ts:1270-1276 codifica la doctrina revocada; esbuild no es dependencia declarada (transitiva de vite) — decision del autor con servidores parados. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>	4 weeks ago
dev	e2c37f8920	feat(eidos)!: un tema DICE lo que es — appearance obligatorio en ThemeDefinition, una sola fuente de verdad ... 39edbc8db dejaba la apariencia como OPCION del que renderiza (RenderThemeCssOptions.appearance, pasada a mano por generated-css.ts): apply() y renderCss() salian mudos, y habia DOS fuentes de verdad porque la apariencia ya vivia implicita en el sufijo del id (/-(light|dark)$/). Forma firmada por el autor: - ThemeDefinition.appearance: ThemeEffective (el tipo de $libs/theme, sin union nueva), OBLIGATORIO. Tres palabras: mode = la preferencia (data-mode) · theme = lo pintado (data-theme) · appearance = que ES el tema. No `colorScheme`: ese nombre es de la paleta derivada de seed. - renderThemeCss lo lee del TEMA y lo emite SIEMPRE como primera declaracion; la opcion desaparece sin shim. apply(), renderCss() y el generador lo emiten gratis. - El sufijo del id baja a convencion de BUSQUEDA del resolver: el validador exige el campo (gate de forma, el que protege documentos) y cierra la contradiccion sufijo<->apariencia (gate semantico). Un tema nuevo por EidosConfigPatch sin el campo cae en el primero. - Todo bloque que pinta una apariencia la declara: el bloque del seed (applyColorScheme, que admite forzar el donante) emite color-scheme desde la apariencia del tema DONANTE resuelto, no del mode crudo; helper #resolveSchemeDonorThemeId compartido para resolverlo una vez. - Documento persistido v1 -> v2, sin migracion: nadie puede adivinar la apariencia de un tema viejo. generated/ no cambia ni un byte (las dos lineas ya estaban; ahora vienen del tema): renderGeneratedBaseEidosCss() sigue en 5751 nombres unicos / 8034 ocurrencias, contrato y censo quietos. Suite eidos + value-channels 460/460 (8 tests nuevos, 4 mutaciones probadas). check 71 -> 73: los dos son web/routes/alpha/lib/docs-theme.ts sin appearance — el arbol congelado pierde el tipo por diseño y entra en el ledger con la unica excepcion escrita (crece SOLO cuando el framework se mueve bajo el arbol provisional); grafito.ts y theme-variants.ts ya fallaban por literal y no suben. src/ a cero. check:gate OK, eidos:lint 0. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>	4 weeks ago
dev	6307ec86f0	docs(book): F7.3 (9/9) — THEMING reference translated; theming/ + canon/ batch COMPLETE ... src/uix/eidos/THEMING.md (1499 L, Spanish) translated to English as docs/theming/reference.md, same s1-s38 numbering: the mental model, s1.bis (theming lives in eidos — the 2-of-3 derivation and the canonical split), the CSS layers, the 7 token layers, the 9 roles, the size canon (universal 1:1 + label step-down + container cap + the icon scale), the naming conventions, the s7/s8/s9/s13/s15/s17/s18 stubs repointed into the book (canon/tsc, theming/guide, theming/notes, theming/changelog, theming/motion), runtime overrides + builders, bundle/purge, validation tooling, s14 motion (the pickup lift), s16 anti-patterns, s19 variants canon, and the s20-s38 standing-decision stubs. One internal reconciliation applied: the s35 stub cited the control/compact/dense size archetypes that s5 declares superseded by the universal 1:1 — aligned. One stale v1 DEMO_AUTHORING s12.8 citation in s5 replaced by the v2 s6 parity rule. Stub at the old path carries the full s1-s38 map (the most sN-cited doc in the repo: code comments, CLAUDE.md, RFCs). Corpus links swept (CANON, docs map, comparison, glossary, eidos chapter, canon/tsc, theming/guide + notes). docs:check 0 errors (260 docs). F7.3 complete: docs/canon/ (tsc, recipe-contract) + docs/theming/ (reference, guide, notes, channels, motion, motion-guide, changelog). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	3 months ago
dev	060f7f1572	docs(book): F7.3 (2/3) — theming/ satellites: guide + notes + channels + motion-guide + changelog ... Five theming docs into the book tree: - docs/theming/guide.md — THEMING_GUIDE (241 L, Spanish -> English): add a component's recipe step-by-step + the three theme-definition modes. - docs/theming/notes.md — THEMING_NOTES (168 L, Spanish -> English): the bundle/feature comparison + the controversial-decisions FAQ (in-page anchor to s1.bis fixed to a real THEMING link). - docs/theming/channels.md — CHANNELS_SYNTHESIS (115 L, Spanish -> English): the per-channel-RFC capstone (two moments, 8 expression vs 3 runtime channels, the builder sextet + applyTheme). - docs/theming/motion-guide.md — MOTION_GUIDE (213 L, already English): moved with frontmatter + links repointed. - docs/theming/changelog.md — THEMING_CHANGELOG (1310 L): chronicle, moved VERBATIM (recorded history is not translated), links repointed. Thin stubs at all five old paths; corpus links swept (docs map E3/E4 rows, building-a-component phase 5, decisions umbrella, getting-started, eidos chapter). docs:check 0 errors (258 docs). Remaining in F7.3: THEMING.md itself (1499 L) + eidos-motion.md (698 L). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	3 months ago