History

dev 7adf93ca57 Prefs as schema-based core + lowercase App.* surface Two structural changes that were overdue and got bundled because they touched the same set of files. ## Prefs is now a schema, not a fixed shape Previously every preference had to be declared in a closed `PrefsCapabilities` interface (`languages`, `locales`, `currencies`, `themes`, `densities`, `motions`, `timezones`, `unitSystems`). Adding a new pref required forking `$libs/prefs` — bad framework design. The redesign replaces the fixed shape with a schema: PrefsSchema = Record<string, PrefsDimension<TIntent, TEffective>> Each dimension owns its own validator (`validate`), environment-fed resolver (`resolve`) and optional sibling-derived value (`derive`). The engine is generic over the schema and iterates it; it knows nothing about "locale" or "theme" specifically. Built-in dimensions live in `arts/prefs/dimensions/` (locale, language, theme, density, motion, timezone, currency, unit-system, direction, plus boolean / enum / string / number primitives). The `standardPrefsDimensions(catalog)` preset composes the canonical set; apps spread it and add their own: const schema = { ...standardPrefsDimensions({ languages, locales, currencies }), sidebarCollapsed: booleanDimension({ default: false }), notificationLevel: enumDimension( ['all', 'mentions', 'none'] as const, { default: 'mentions' } ) }; Active surface exposes one slot per schema key with uniform verbs: App.prefs.locale.get() App.prefs.locale.set('es-ES') App.prefs.locale.clear() App.prefs.locale.onChange((v) => …) App.prefs.sidebarCollapsed.set(true) `setIntent('locale', value)` stays available as a low-level pass- through (storage bridge consumes it generically) but UI code uses the dimension surface. ## Lowercase core surface `App.Logger`, `App.Bus`, `App.Timers`, `App.Orca`, `App.Prefs` are gone. The "PascalCase for core, lowercase for services" rule was visual signalling against JS convention, no technical benefit, and created an asymmetry on the same object. All core members are now lowercase, matching services: App.logger App.bus App.timers App.orca App.prefs `createPrefsStorageBridge` keeps its old responsibilities; sources helpers (`prefsLocaleSource`, …) are gone — the dimension API replaces them. ## What changed - `$libs/prefs`: fully generic schema-based types + resolver. Old fixed `PrefsCapabilities` / `PrefsIntent` / `PrefsEffective` removed; replaced by `PrefsDimension`, `PrefsSchema`, `PrefsEffectiveOf<S>`, `PrefsIntentOf<S>`. - `arts/prefs`: engine + active wrapper rewritten to schema. Per- dimension active surface auto-built from schema keys. Sources file deleted (replaced by dimension surface). New `arts/prefs/dimensions/` and `arts/prefs/standard.ts`. Storage bridge made schema-generic. - `arts/active-app`: lowercase `CoreServices` / `ActiveAppCore`, `prefs?: ActiveAppPrefsOptions<S>` root option carrying the schema. `defineActivePrefs` deleted (prefs is core, not service). `lang` / `format` / `frontend` factories migrated to read `core.prefs.<dim>` directly via defensive `readSlot()` helpers (each dimension is optional from the factory's POV; if the app's schema omits one, the integration degrades gracefully). - Presets, demos, web routes, README docstrings, `check-aliases.mjs` guards, marketing snippets all migrated. - Tests: `engine-prefs`, `active-prefs`, `storage-bridge`, `resolve-prefs`, `validate-intent`, `prefs-consumer-wiring`, `service-factories` rewritten for the schema-based API. `sources.test.ts` deleted (sources file is gone). ## Verification - `npm run check`: 0 errors, 0 warnings (1527 files). - `npm test`: 1645 tests across 139 files, all green. - `node scripts/check-aliases.mjs`: clean (lowercase enforced for every member of `App.*`, including `Logger`/`Bus`/`Timers`/`Orca`/ `Prefs` which now flag as forbidden capitals). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>		5 months ago
..
docs	Nexo desktop-first redesign + demo restructure	5 months ago
server	Nexo desktop-first redesign + demo restructure	5 months ago
web	Prefs as schema-based core + lowercase App.* surface	5 months ago
README.md	Nexo desktop-first redesign + demo restructure	5 months ago

README.md

Nexo - demo dating del ecosistema

Nexo es una app demo de dating/social matching para probar el ecosistema completo en un producto coherente. La demo no existe para ensenar pantallas bonitas aisladas: existe para forzar integracion real entre modulos, estados, permisos, cache, realtime, formularios, servidor y devtools.

Objetivo corto

Construir una app de matching segura y privacy-first, con perfiles, onboarding, filtros, matches, chat, bloqueo, reportes, moderacion y panel de diagnostico.

Debe servir para:

probar que active-app compone todos los servicios;
validar que uix puede ser la capa real de componentes;
usar sium para formularios y validacion;
ejercitar auth, session y perm en flujos reales;
conectar http, cache, storage y connection;
observar todo con logger, bus, timer y orca;
generar pruebas de producto, integracion y regresion.

Documentos

objetivos.md: objetivos de producto, ecosistema y validacion.
requisitos.md: requisitos funcionales, no funcionales, roles, permisos y datos.
diseno-producto.md: experiencia, pantallas, flujos y componentes esperados.
arquitectura-ecosistema.md: como participa cada modulo del ecosistema.
auth-y-fotos.md: paginas de login/registro y subida/gestion de fotos.
plan-implementacion.md: fases de construccion y entregables.
matriz-tests.md: pruebas necesarias para cerrar la demo con confianza.

Principios de la demo

Datos ficticios y seed controlado.
Usuarios siempre adultos dentro de la demo.
No usar rutas test o demo como libreria publica.
No meter logica de negocio dentro de componentes visuales.
Todo flujo importante debe dejar traza observable.
Toda pantalla debe poder probarse sin depender de servicios externos reales.
El servidor de datos vive aislado en servers/dating; SvelteKit consume su API.

Superficie inicial de rutas

/dating: shell principal de la demo.
/dating/login: inicio de sesion.
/dating/register: registro.
/dating/reset: recuperacion de acceso.
/dating/mfa: verificacion MFA simulada.
/dating/onboarding: creacion guiada de perfil.
/dating/discover: descubrimiento y filtros.
/dating/matches: matches y conversaciones.
/dating/chat/[matchId]: chat realtime.
/dating/profile: perfil, fotos, privacidad y preferencias.
/dating/profile/photos: subida, ordenacion y eliminacion de fotos.
/dating/safety: bloqueo, reporte, exportacion y borrado.
/dating/admin: moderacion y decisiones auditadas.
/dating/devtools: inspector de ecosistema para la demo.

Criterio de exito

La demo esta completa cuando un test puede recorrer este flujo:

registrar un usuario;
completar onboarding;
cambiar idioma, tema y preferencias;
descubrir perfiles;
hacer like y crear match;
enviar mensajes online y offline;
bloquear o reportar un perfil;
resolver reporte como moderador;
comprobar permisos;
ver trazas, cache, storage y eventos en devtools.