Estado, arquitectura y documentación funcional de los paquetes del monorepo.
Cada sección refleja el estado real del código — no aspiraciones.
6paquetes
3secciones documentadas
✓client design system completo
✓enterprise design system completo
🧹 En curso: limpieza de documentación + purga de Firebase/Cloud Run
Stack retirado (Firebase / GCS / Cloud Run) → actual: PostgreSQL + backend Node + VPS/Komodo
(deploy en docs/deploy/komodo.md). Estamos centralizando los docs aquí y eliminando todo rastro del stack viejo. Se hace en pasadas.
✅ Hecho: raíz reducida a 4 .md canónicos · docs/deployment/ (guías Firebase) eliminado ·
~50 reportes/docs Firebase borrados · 0 enlaces rotos. ⏳ Pendiente: reescritura de docs de contexto grandes (architecture/context.md, agents.md,
*_CONTEXT, core/WIKI, arquitectura.md) · purga de menciones Firebase incidentales en ~40 docs (por lotes).
Paquetes
6 en total
🏨
@happnest/enterprise
Back-office para staff de hotel y cadenas
Operativo
Panel de administración para el personal del hotel. Gestiona usuarios, roles, tareas, experiencias, reservas, check-ins, notificaciones y configuración de la empresa. Access control rewrite completo — AccessGuard, super admin pages, role builder. Migración del design system a tokens standalone completa (6/6 steps, 954 tests en verde).
App facing del huésped. Reservas, experiencias, check-in flow. Off-white, deep teal, Fraunces + Manrope. Design system completo — tokens, primitivas propias, temas por hotel via [data-theme].
Check-in online del huésped antes de llegar al hotel: asistente de 2 pasos, multi-tenant por hotel. Design system migrado a tokens; flujo de usuario y personas documentados.
Página de marketing de Happnest. Presentación de producto, captación de clientes y onboarding.
Next.js
Documentación pendientepróximamente
Completado / documentado
En progreso
Planificado
Design Systems
sección existente
Documentación visual de tokens, tipografía, colores y componentes para los cuatro paquetes front-end.
Generada durante la fase de design system (Feb–May 2026).
Lluvia de ideas sin compromiso de roadmap. Conceptos en fase de exploración — aquí se anotan
antes de decidir si pasan a tareas reales.
🤖IA autoalojada en Docker (chat + OCR + tool use)explorando
Correr un modelo de IA self-hosted en Docker (encaja con el stack VPS + Komodo + Caddy, multi-tenant
por cliente) para asistir tareas del producto: responder chats, hacer OCR y operar sobre la API existente
(reservas, tareas) vía tool calling. Argumento clave de privacidad: los datos nunca salen del servidor del cliente.
🟢 OCR check-in (DNI/pasaporte)
Más fácil y mayor ROI. VLM mediano (qwen2.5-vl 7B) o PaddleOCR/Tesseract → documento a JSON
que prellena el form de huésped. RGPD: procesado 100% local.
🟡 Chat asistente staff
Lenguaje natural sobre reservas/tareas. Lo difícil es el tool calling contra el backend,
reutilizando el control de acceso level+scope. Empezar read-only → luego acciones con confirmación.
🔴 Chat huésped (cara al cliente)
Mayor riesgo (alucinaciones, idiomas, tono). Necesita RAG (info del hotel) + guardarraíles fuertes.
Fase posterior, tras probar el motor con el staff.
Stack candidato:
Ollama (LLM, API tipo OpenAI) · LiteLLM/vLLM (gateway/throughput) · PaddleOCR / Tesseract / VLM para OCR. Arquitectura:caddy → ai-gateway → ollama + ocr-service + backend existente (tools).
Gateway propio que aplica auth/permisos, decide local vs API y aísla el scope por tenant. Ruta sugerida:
Fase 0 PoC (Ollama + OCR de un DNI de prueba) → Fase 1 OCR check-in en prod → Fase 2 chat staff read-only →
Fase 3 chat staff con acciones → Fase 4 chat huésped + RAG. Decisiones abiertas:
hardware (CPU vs GPU — cuello de botella real) · 100% local vs híbrido (OCR local + Claude API para razonamiento
complejo/tool use fiable) · aislamiento de modelo por tenant.
Tareas del proyecto
cargando…
Estado real del trabajo pendiente. Los checks se guardan en el navegador (localStorage).
0 / 0 hechas
0%
🏖️ Experiencias
Sistema de Reseñas de Experiencias
frontendbackendaltaLos clientes pueden valorar experiencias completadas. Backend incluye cron job diario para completarlas, y los administradores pueden moderar las reseñas en el panel Enterprise.
🧩 Infra · transversal (afecta a todos los módulos)
Servicio de envío de email en el backend — no existe todavía
backendaltaSin dependencia de mail (nodemailer/SES/Resend) ni config SMTP. Transversal: lo necesitan reset de contraseña, confirmaciones de reserva, invitaciones de usuario, notificaciones, etc. Plan: capa con nodemailer configurable por env (SMTP_*/FROM) — credenciales por cliente (modelo multi-tenant) + dominio verificado (SPF/DKIM/DMARC).
🧹 Cleanup · deuda técnica
Cleanup 7.7 — drop columna users.role VARCHAR legacy
backendbajaRequiere que todo el JWT migre a isSuperAdmin. Follow-up PR.
Migrar impersonation.controller.ts de auth.ts → auth.middleware.ts
backendmediaÚltimo controlador que lee req.user.role del JWT legacy.
🧪 Tests · regressions
Fix storage.controller.test.ts — 7 tests fallando
testsbackendaltaMock de fileExists/getSignedReadUrl no coincide con firma actual (extra argumento bucket).