📸 Epic P — Meal Photo AI: la comida entra por la cámara

1 · Por qué es EL epic (y por qué ahora)

• El registro manual de comidas es la fricción nº 1 de cualquier app de nutrición. La foto la elimina.
• La competencia ya lo hace (28 desde julio, Aluna) — reconocer el plato es commodity. Nuestro hueco: convertir cada comida en dato estructurado y consciente del ciclo, y aprender del bucle recomendar → hacer → responder (informe v1.1, pestaña 🥊).
• El dato de CORRECCIÓN de la usuaria («era pollo, no atún») es el activo que nadie puede comprar.

2 · Reparto (quién trae qué)

3 · Arquitectura — el stack que ya tenemos, sin piezas nuevas

Cero servidores nuevos (principio rector). Todo Supabase + React Native + un proveedor de visión:

App RN (Expo)
  ├─ foto → redimensionar 1024px JPEG (compress .75, SIN EXIF)
  ├─ subir a Storage PRIVADO  meal-images/{user_id}/{meal_id}.jpg
  └─ crear meal_log (status: uploading → queued)
        ▼
Edge Function analyse-meal
  ├─ verificar sesión de la usuaria (y que el meal es SUYO)
  ├─ descargar imagen privada → base64
  ├─ visión IA → JSON ESTRICTO (json_schema, strict:true)
  ├─ casar alimentos contra canonical_foods (USDA/EuroFIR)
  ├─ macros DETERMINISTAS: per100g × gramos ÷ 100  ← jamás el LLM
  └─ guardar borrador (status: needs_review)
        ▼
Pantalla de confirmación (borrador, no hecho)
  ├─ «La IA detectó esto» + confianza
  ├─ corrige porciones/ingredientes → meal_edits (ORO)
  └─ confirmar (status: confirmed)
        ▼
Motor de patrones (SQL primero, LLM solo EXPLICA después)
  └─ grupos + macros + fase + síntomas + energía + sueño + ejercicio

Modelos y enrutado

4 · Las reglas que no se negocian

• El formulario manual NUNCA desaparece (requisito Juanjo, 9-ago). «Log Today's Meal» ofrece SIEMPRE dos caminos: 📸 foto con IA (el nuevo) y ✍️ apuntarlo a mano (el sencillo de hoy) — como fallback permanente: sin cámara, sin cobertura, IA caída, o simplemente porque ella prefiera teclear. Ambos acaban en el MISMO databed (meal_captures.origen = 'foto' | 'manual'); mientras el flujo IA madura, el manual sigue escribiendo donde siempre (meal_logs) sin tocarse. La IA profesionaliza el NutriLog; no le quita la puerta simple.
• El LLM identifica, la base de datos calcula. La IA dice «yogur griego, ~180 g, confianza 0.89»; los macros salen de canonical_foods (USDA per-100g × gramos). Nada de calorías inventadas con tres decimales.
• Nutrientes ≠ grupos de alimentos — dos capas separadas (proteína/hidratos/grasa/fibra vs legumbres/cereales/verduras/lácteos…). Una comida pertenece a varios grupos.
• Borrador, no veredicto: todo se presenta como estimación con confianza visible y corrección en un toque. Rangos, no falsa precisión. Cero decisiones clínicas.
• La corrección se guarda separada de la estimación original (meal_edits: before/after) — es el dataset de entrenamiento futuro. No se afina ningún modelo hasta acumular corrección limpia.
• Imágenes: análisis a 1024px JPEG temporal → miniatura 256-384px WebP/JPEG con consentimiento → el grande se borra salvo que ella elija conservar su diario visual. EXIF y localización fuera. Bucket privado, URLs firmadas cortas, borrado explícito en sus manos.
• Claves solo en el backend (Edge secrets): OpenAI, USDA, EuroFIR. Jamás en la app.
• Patrones por SQL primero; el LLM recibe la evidencia calculada y solo la explica («asociación en tus propios datos, no causa»). Comparación contra SU historia, no contra una dieta ideal.

5 · Modelo de datos (resumen — SQL completo en el anexo del chat de ingeniería)

RLS en todo (cada usuaria solo lo suyo), bucket meal-images privado con carpeta por usuaria — el mismo patrón que feedback-shots.

6 · Fuentes nutricionales

6b · El databed ya existe (9-ago tarde)

7 · Los 5 incrementos y dónde caen

8 · Qué mide el éxito (piloto)

• % de fotos que producen borrador útil (is_food + ≥1 item correcto) — objetivo >80%
• % de comidas confirmadas sin corrección — el 72% de referencia del informe
• Tiempo foto→confirmación < 20 segundos
• Correcciones/semana (el dataset creciendo) y comidas/usuaria/día (adopción real)

9 · Encaje en los planes

• 🗂 Sprint Planning: el epic entra como P·Increments con release asignada (SQL 2026-08-09).
• 🥊 Competencia: es la respuesta al «commodity» — la sección 5 del informe es la especificación funcional de este epic.
• Epic N (Propuesta 32): comparte router, golden-set y regla cero-PII. Este epic APORTA el mejor golden-set posible: fotos reales + correcciones reales del piloto.
• Wearables (Epic O): el ejercicio NO va por foto — jerarquía: Health/wearables → un toque → voz → foto de pantalla como último recurso.
• Compliance: imágenes = dato personal; el flujo de retención/borrado entra en el RAT y la EIPD con Audidat (J5).