Close general Eidos architecture

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`,

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'),

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.