You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
70 lines
3.1 KiB
70 lines
3.1 KiB
# 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.md): objetivos de producto, ecosistema y validacion.
|
|
- [requisitos.md](requisitos.md): requisitos funcionales, no funcionales, roles, permisos y datos.
|
|
- [diseno-producto.md](diseno-producto.md): experiencia, pantallas, flujos y componentes esperados.
|
|
- [arquitectura-ecosistema.md](arquitectura-ecosistema.md): como participa cada modulo del ecosistema.
|
|
- [auth-y-fotos.md](auth-y-fotos.md): paginas de login/registro y subida/gestion de fotos.
|
|
- [plan-implementacion.md](plan-implementacion.md): fases de construccion y entregables.
|
|
- [matriz-tests.md](matriz-tests.md): pruebas necesarias para cerrar la demo con confianza.
|
|
|
|
## Principios de la demo
|
|
|
|
1. Datos ficticios y seed controlado.
|
|
2. Usuarios siempre adultos dentro de la demo.
|
|
3. No usar rutas `test` o `demo` como libreria publica.
|
|
4. No meter logica de negocio dentro de componentes visuales.
|
|
5. Todo flujo importante debe dejar traza observable.
|
|
6. Toda pantalla debe poder probarse sin depender de servicios externos reales.
|
|
7. 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:
|
|
|
|
1. registrar un usuario;
|
|
2. completar onboarding;
|
|
3. cambiar idioma, tema y preferencias;
|
|
4. descubrir perfiles;
|
|
5. hacer like y crear match;
|
|
6. enviar mensajes online y offline;
|
|
7. bloquear o reportar un perfil;
|
|
8. resolver reporte como moderador;
|
|
9. comprobar permisos;
|
|
10. ver trazas, cache, storage y eventos en devtools.
|