From 809c17b9bfafaa66f8c7c68aa7f96708ea8dcdb5 Mon Sep 17 00:00:00 2001 From: dev Date: Thu, 14 May 2026 23:36:13 +0200 Subject: [PATCH] Close general Eidos architecture --- continue.md | 22 ++++++++++++++-------- src/uix/contracts.test.ts | 11 +++++++++++ src/uix/eidos/README.md | 11 +++++++++-- 3 files changed, 34 insertions(+), 10 deletions(-) diff --git a/continue.md b/continue.md index d76325c3a..15bee6704 100644 --- a/continue.md +++ b/continue.md @@ -45,6 +45,14 @@ Actualizacion 2026-05-14: registro via `registerMorfo` y `soma.runtime(...)` como contrato vigente. - Referencias legacy de `frontend` afinadas: su densidad se documenta como vocabulario compatible para migracion, no como flujo desde `prefs.density`. +- Validacion global ejecutada: `npm run check`, tests focales UIX/arts, + tests legacy `ActiveApp/frontend` y `npm run build` pasan. Solo queda el + warning de chunks grandes del build. +- Eidos general queda cerrado sin tocar componentes: no hay `EngineEidos`, + wrapper `Eidos`, `eidos/engine` ni `eidos/core/headless`; se anade guardia + de regresion en `contracts.test.ts`. +- `recipes` queda como `RecipeTokenSet` plano por decision: subir a tipo + estructurado solo cuando exista builder/consumer real que lo necesite. - Commits nuevos empujados: - `694eb5c5` — `Clarify prefs projection contract` - `223cdf9e` — `Align sema docs with channel ownership` @@ -161,7 +169,7 @@ a su `portalTo`. No usar nombres como `somaPortalTo` en `ActiveUix`. `frontend` son servicios opt-in, y que `frontend` no debe usarse para codigo UIX nuevo. -## Pendiente Eidos +## Eidos cerrado para modulo general 1. Primitivas visuales sin tocar componentes: `layout` ya queda incorporado al `EidosConfig` con `containerWidth`, `containerPaddingInline`, @@ -186,9 +194,8 @@ a su `portalTo`. No usar nombres como `somaPortalTo` en `ActiveUix`. consumen los mismos custom properties, pero los valores salen de `generated/base.css`. 8. `ActiveEidos.listRecipes()` y `getRecipeTokens(component)` exponen los - aliases para editores de theme sin leer CSS. Pendiente: afinar tipado - estructurado de `recipes` solo si una recipe lo necesita; por ahora el - contrato plano evita una jerarquia grande prematura. + aliases para editores de theme sin leer CSS. El tipado plano de `recipes` + es intencional mientras no haya builder/consumer estructurado. 9. No reintroducir engine visual separado, carpeta `engine`, ni wrapper `Eidos` sin contrato propio. @@ -197,10 +204,9 @@ a su `portalTo`. No usar nombres como `somaPortalTo` en `ActiveUix`. - Validacion navegador `/uix` cerrada despues de mover recipe tokens y retirar fuentes remotas: carga sin `requestfailed`, sin errores de consola y el toggle dark sigue aplicando `data-theme`, `data-mode` y estilos visuales. -- Siguiente foco recomendado: si se mantiene el modulo general de Eidos sin - tocar componentes, solo queda afinar el tipado de `recipes` cuando una - recipe necesite estructura real. Si se abre trabajo de componentes, reauditar - primero la migracion option C y no mezclarla con cambios de runtime. +- Siguiente foco recomendado: reauditar componentes Eidos option C solo cuando + se autorice explicitamente. No mezclar esa fase con runtime ni arquitectura + general. - Warnings de toast resueltos; `npm run check` queda en 0 errores / 0 warnings. - No commitear logs temporales: `.codex-vite-dialog*.log`, `debug.log`, `md`. - Antes de seguir con componentes, releer `src/uix/active_architecture.md`, diff --git a/src/uix/contracts.test.ts b/src/uix/contracts.test.ts index 9217f7fe4..b6b5f9a5a 100644 --- a/src/uix/contracts.test.ts +++ b/src/uix/contracts.test.ts @@ -222,6 +222,7 @@ describe('UIX layer contracts', () => { it('ActiveEidos is the visual runtime and does not recreate an engine layer', () => { expect(UIX_LAYER_CONTRACTS.activeEidos.publicRuntime).toBe('ActiveEidos'); expect(existsSync(new URL('./eidos/engine', import.meta.url))).toBe(false); + expect(existsSync(new URL('./eidos/core/headless', import.meta.url))).toBe(false); expect(UIX_LAYER_CONTRACTS.activeEidos.constructionOptionalServices).toEqual([ 'langs', 'format', @@ -243,6 +244,16 @@ describe('UIX layer contracts', () => { eidos.dispose(); }); + it('guards Eidos public surface from wrapper/engine reintroduction', () => { + const eidosRoot = join(HERE, 'eidos'); + const violations = grepSources( + eidosRoot, + /\bEngineEidos\b|\bclass\s+Eidos\b|\bEidos\.create\(|from ['"].*\/engine/ + ); + + expect(violations).toEqual([]); + }); + it('guards UIX docs shell from writing visual prefs through ActivePrefs', () => { const violations = grepSources( join(REPO_ROOT, 'web', 'routes', 'uix'), diff --git a/src/uix/eidos/README.md b/src/uix/eidos/README.md index 50738a3ae..8195182aa 100644 --- a/src/uix/eidos/README.md +++ b/src/uix/eidos/README.md @@ -165,6 +165,12 @@ Para editores de theme, `ActiveEidos.listRecipes()` enumera los componentes con recipe tokens y `ActiveEidos.getRecipeTokens(component)` devuelve una copia defensiva del mapa de aliases. No muta el config interno. +La decision vigente es mantener `recipes` como mapa plano de aliases +(`RecipeTokenSet`). Subir una recipe a tipo estructurado propio solo se +justifica cuando exista un builder o consumer real que necesite semantica +interna; mientras las recipes sigan siendo CSS plano, el contrato publico es +el custom property generado. + ActiveEidos genera tambien la escala alpha de cada paleta fisica: ```text @@ -698,7 +704,8 @@ podrá retirarse. base desde `generated/base.css`. Los antiguos `tokens/components/*` tambien salen del entrypoint: `EidosConfig.recipes` genera los aliases de recipe estables. -- **Primitivas pendientes de cerrar**: afinar el modelo tipado de recipes si - alguna recipe necesita campos estructurados en vez de aliases planos. +- **Recipes**: quedan deliberadamente como `RecipeTokenSet` plano. No se crea + jerarquia estructurada hasta que una recipe tenga un builder/consumer real + que necesite mas semantica que aliases CSS. - **Check del repo**: `npm run check` no reporta errores ni warnings en este punto.