> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mov-eat.app/llms.txt
> Use this file to discover all available pages before exploring further.
# Estado del proyecto
> Estado actual de implementación de Moveat en producto, backend, agent, frontend, infraestructura y operaciones.
# 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:
El usuario registra comida desde web o Agent, Platform persiste meal entries y actualiza el resumen diario una sola vez.
El usuario registra peso, Platform guarda valores métricos canónicos y el frontend muestra la unidad correcta.
El usuario registra entrenamientos, ejercicios y series, y Platform mantiene historial durable.
Agent usa contexto de Platform e interpretación con LLM para reducir fricción y personalizar respuestas.
## Qué existe hoy
| Área | Estado actual | Significado operativo |
| ----------------------- | ---------------------------------------------------- | -------------------------------------------------------------------------- |
| Documentación | Mintlify conectado a `docs.mov-eat.app`. | El conocimiento de producto, técnica y operaciones está centralizado. |
| Frontend | Web client desplegado por separado en Vercel. | El usuario interactúa fuera del droplet backend. |
| Platform | NestJS + Prisma con monolito modular. | Platform es dueño del estado de negocio y expone APIs públicas e internas. |
| Agent | Servicio Go con WhatsApp, LLM, orquestación y Redis. | Agent puede evolucionar sin mezclar lógica de canal en Platform. |
| Base de datos | PostgreSQL en el stack productivo. | Datos durables locales al droplet para reducir latencia. |
| Redis | Redis en el stack productivo. | Estado de sesión, cache y conversación de corta duración. |
| Reverse proxy | Caddy maneja HTTPS y routing. | Los dominios públicos apuntan a servicios internos. |
| Observabilidad | Grafana, Loki y Alloy desplegados. | Logs y dashboards disponibles para debugging. |
| Gestión de contenedores | Komodo desplegado. | Inspección y gestión visual de contenedores. |
| API inspection | Platform expone Swagger público e interno. | Ingeniería puede inspeccionar contratos vivos. |
## Estado de Platform
| Capacidad | Estado | Notas |
| ----------------------- | ---------------------- | ------------------------------------------------ |
| Email/password auth | Disponible | Usa sesiones opacas HTTP-only. |
| Google auth backend | Disponible | Requiere flujo frontend y client ID configurado. |
| Sesiones | Disponible | Frontend usa cookie; no lee JWT. |
| Onboarding | Disponible | Crea profile, goals y nutrition settings juntos. |
| Conversión de unidades | Disponible | Storage métrico canónico, display convertido. |
| User channels | Disponible | Canales separados de users para escalabilidad. |
| Coaching context | Disponible | Separado de `/me` para no inflar sesión. |
| Meal logging | Disponible en Platform | Falta validar end-to-end con frontend y Agent. |
| Daily nutrition summary | Disponible en Platform | Se actualiza desde meal entries. |
| Weight tracking | Disponible en Platform | Contrato con `unitSystem` a nivel response. |
| Workout tracking | Base disponible | Requiere validación end-to-end y más tests. |
| Swagger | Disponible | Docs públicas e internas separadas. |
## Estado de Agent
| Capacidad | Estado | Notas |
| ---------------------- | ---------------- | -------------------------------------------------------------------- |
| WhatsApp webhook | Disponible | Verificación, firma y mapping. |
| WhatsApp sender | Disponible | Envía respuestas por Meta Cloud API. |
| Modelo channel-neutral | Disponible | Evita lógica de negocio atada a WhatsApp. |
| Abstracción LLM | Disponible | Adapter de Gemini; futuros providers pueden implementar el contrato. |
| Parser/interpreter LLM | Disponible | Output estructurado para intención y decisiones. |
| Redis session store | Disponible | Estado conversacional de corta duración. |
| Integración Platform | En progreso | Agent debe llamar APIs internas para writes durables. |
| Media handling | Planeado/parcial | Imá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.