Saltar al contenido principal

Estado del proyecto

Esta página resume dónde está Moveat hoy desde producto y operaciones. Sirve para entender qué existe, qué está siendo validado y qué falta antes de considerar estable el loop principal.
Moveat está en fase de fundación MVP. La arquitectura, infraestructura y varios módulos de negocio ya existen, pero el flujo end-to-end todavía se está endureciendo.

Etapa actual

Moveat ya pasó la etapa de prototipo puro. Existen repos separados, infraestructura productiva, persistencia en base de datos, autenticación, documentación, Swagger, observabilidad y una base sólida para Agent. El objetivo principal ahora es conectar los loops de producto de punta a punta:

Loop de nutrición

El usuario registra comida desde web o Agent, Platform persiste meal entries y actualiza el resumen diario una sola vez.

Loop de progreso

El usuario registra peso, Platform guarda valores métricos canónicos y el frontend muestra la unidad correcta.

Loop de entrenamiento

El usuario registra entrenamientos, ejercicios y series, y Platform mantiene historial durable.

Loop de coaching

Agent usa contexto de Platform e interpretación con LLM para reducir fricción y personalizar respuestas.

Qué existe hoy

ÁreaEstado actualSignificado operativo
DocumentaciónMintlify conectado a docs.mov-eat.app.El conocimiento de producto, técnica y operaciones está centralizado.
FrontendWeb client desplegado por separado en Vercel.El usuario interactúa fuera del droplet backend.
PlatformNestJS + Prisma con monolito modular.Platform es dueño del estado de negocio y expone APIs públicas e internas.
AgentServicio Go con WhatsApp, LLM, orquestación y Redis.Agent puede evolucionar sin mezclar lógica de canal en Platform.
Base de datosPostgreSQL en el stack productivo.Datos durables locales al droplet para reducir latencia.
RedisRedis en el stack productivo.Estado de sesión, cache y conversación de corta duración.
Reverse proxyCaddy maneja HTTPS y routing.Los dominios públicos apuntan a servicios internos.
ObservabilidadGrafana, Loki y Alloy desplegados.Logs y dashboards disponibles para debugging.
Gestión de contenedoresKomodo desplegado.Inspección y gestión visual de contenedores.
API inspectionPlatform expone Swagger público e interno.Ingeniería puede inspeccionar contratos vivos.

Estado de Platform

CapacidadEstadoNotas
Email/password authDisponibleUsa sesiones opacas HTTP-only.
Google auth backendDisponibleRequiere flujo frontend y client ID configurado.
SesionesDisponibleFrontend usa cookie; no lee JWT.
OnboardingDisponibleCrea profile, goals y nutrition settings juntos.
Conversión de unidadesDisponibleStorage métrico canónico, display convertido.
User channelsDisponibleCanales separados de users para escalabilidad.
Coaching contextDisponibleSeparado de /me para no inflar sesión.
Meal loggingDisponible en PlatformFalta validar end-to-end con frontend y Agent.
Daily nutrition summaryDisponible en PlatformSe actualiza desde meal entries.
Weight trackingDisponible en PlatformContrato con unitSystem a nivel response.
Workout trackingBase disponibleRequiere validación end-to-end y más tests.
SwaggerDisponibleDocs públicas e internas separadas.

Estado de Agent

CapacidadEstadoNotas
WhatsApp webhookDisponibleVerificación, firma y mapping.
WhatsApp senderDisponibleEnvía respuestas por Meta Cloud API.
Modelo channel-neutralDisponibleEvita lógica de negocio atada a WhatsApp.
Abstracción LLMDisponibleAdapter de Gemini; futuros providers pueden implementar el contrato.
Parser/interpreter LLMDisponibleOutput estructurado para intención y decisiones.
Redis session storeDisponibleEstado conversacional de corta duración.
Integración PlatformEn progresoAgent debe llamar APIs internas para writes durables.
Media handlingPlaneado/parcialImágenes/audio requieren descarga y multimodal.

Prioridades cercanas

  1. Validar meal logging end-to-end desde web y Agent.
  2. Endurecer contratos de weight y workout antes de que frontend dependa fuerte de ellos.
  3. Completar Platform client en Agent con auth interna e idempotencia.
  4. Subir coverage de Platform en paths críticos.
  5. Subir coverage de Agent en Platform client, providers y fallos.
  6. Exportar OpenAPI de Platform al repo docs.
  7. Mantener sincronizadas las versiones en español e inglés.