5 Commits (c482fc7a28b8e23c5493cc774b524483f9e091d5)

Author	SHA1	Message	Date
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