active-svelte/demos/dating/docs/objetivos.md

Objetivos de Nexo

Objetivo principal

Crear una demo de dating/social matching que use todos los modulos importantes del ecosistema y permita validar que la plataforma puede sostener una aplicacion real, no solo ejemplos aislados.

La app debe demostrar composicion, UI, formularios, seguridad, permisos, datos, realtime, cache, persistencia, preferencias, internacionalizacion, observabilidad y pruebas.

Objetivos de producto

• Permitir que un usuario cree una cuenta y complete un perfil.
• Permitir descubrir perfiles compatibles mediante filtros.
• Permitir likes, passes, matches y conversaciones.
• Permitir gestionar privacidad, bloqueo, reporte y borrado.
• Permitir moderar reportes desde un panel protegido.
• Permitir operar la app con estados degradados: offline, sesion expirada, permisos insuficientes, datos stale y errores de red.

Objetivos de ecosistema

• Validar active-app como compositor de servicios real.
• Convertir uix en una capa de componentes reusable, no acoplada a rutas demo.
• Usar sium como motor de schemas, validacion e introspeccion de formularios.
• Usar http como cliente tipado y observable.
• Integrar cache con http, storage, bus y estados de UI.
• Usar storage para drafts, preferencias locales, cola offline y cache persistente.
• Usar auth, session y perm para flujos de identidad y autorizacion.
• Usar connection para chat, presencia y reconexion.
• Usar logger, bus, timer y orca para trazar y coordinar flujos.
• Usar lang con MessageFormat 2.0 / MF2 como contrato moderno de mensajes.
• Usar format para fechas, distancia aproximada, listas, unidades y estados localizados.

Objetivos tecnicos

• Definir una DatingApp canonica con servicios tipados.
• Crear fixtures y seeds repetibles.
• Evitar dependencias externas obligatorias para el happy path local.
• Separar cliente, servidor, contratos y UI.
• Evitar que src/web/routes/dating se convierta en libreria interna: la logica reusable debe ir a src/uix, src/arts, src/libs o src/svrs.
• Cada flujo critico debe tener prueba automatizada.
• Cada error esperado debe tener estado visual y evento de diagnostico.

Objetivos de validacion

La demo debe permitir probar:

• composicion de servicios;
• renderizado de componentes;
• formularios generados;
• permisos y gates;
• sesion y expiracion;
• cache hit/miss/stale;
• storage persistente y drafts;
• offline queue;
• reconnect de chat;
• logs correlacionados;
• eventos de bus;
• tareas orquestadas por orca;
• timers de debounce, retry y expiracion.

No objetivos

• No construir una app de dating comercial completa.
• No usar datos reales de usuarios.
• No depender de pagos reales, mapas reales ni proveedores externos obligatorios.
• No crear features sociales no necesarias para probar el ecosistema.
• No meter reglas de negocio en componentes visuales.
• No duplicar motores ya existentes si el modulo del ecosistema puede cubrirlo.

Resultado esperado

Al terminar, Nexo debe funcionar como demo de referencia para la version 2.0: una app suficientemente compleja para romper las integraciones flojas, pero acotada para poder testearse y mantenerse.