# Fermenty ERP — Tareas priorizadas (Web primero)

Fecha: 24-03-2026

## Estado actual
- [x] (1) Terminar acceso/registro con Google
- [x] (2) Envío de mails desde la plataforma
- [x] (3) Rutinas de notificación (12-06-2026: reglas por paso al activarse, rutina diaria de vencimientos, dispatch email cada 15 min)
- [x] (4) Añadir mediciones a lotes activos (tipo logs)
- [x] (5) Hints por paso (algunos Premium)
- [ ] (6) Preferencias de notificaciones en perfil
- [ ] (7) Guardar recetas propias (Premium)
- [ ] (8) Visibilidad pública de usuario y sus lotes (feature premium)
- [ ] (9) Compartir recetas en Comunidad (con fotos)
- [x] (10) Redactar comparativa Free vs Premium + copy para landing "¿Por qué Premium?" (ver PREMIUM_LANDING_COPY.md + landing publicada)

## Objetivo
Definir un orden lógico para implementar funcionalidades sin romper el flujo actual de la app web y dejando base lista para futura API móvil.

## Orden recomendado

### 1) Terminar acceso/registro con Google [DONE]
**Por qué primero:** es parte del acceso principal y reduce fricción de entrada; conviene estabilizar autenticación antes de ampliar features.

**Incluye:**
- Revisar flujo completo: redirección, callback, alta de usuario, login y manejo de errores
- Vinculación segura de proveedor social (`user_social_providers`)
- Caso de cuenta existente por email (evitar duplicados)
- Configurar credenciales reales en Google Cloud Console por entorno (local/producción)
- UX clara en login/registro y mensajes de fallo

**Salida esperada:** registro/login con Google robusto en producción, sin cuentas duplicadas ni bloqueos de acceso.

**Estado:** completado el 15-04-2026 (flujo validado local y online).

---

### 2) Envío de mails desde la plataforma [DONE]
**Por qué ahora:** muchas funcionalidades dependen de correo (verificación, newsletter, alertas); es infraestructura base.

**Incluye:**
- Configuración estable de mailer por entorno
- Plantilla base de correo (branding + idioma)
- Prueba de entrega real y manejo de rebotes mínimos
- Logging de errores de envío

**Salida esperada:** la plataforma puede enviar correos transaccionales de forma confiable.

**Estado:** completado el 15-04-2026.
- Local: Mailpit en puerto 1025 (SMTP) + UI en http://localhost:8025
- Producción: pendiente de configurar Resend + DNS (ver docs/MAIL_SERVER_SETUP.md)
- Acción interna de test disponible en `/acp/newsletter`

---

### 3) Rutinas de notificación
**Por qué aquí:** una vez funcionando el canal de correo, conviene consolidar el motor de eventos/reglas antes de abrir más controles al usuario.

**Incluye:**
- Definir eventos clave (pasos, vencimientos, recordatorios)
- Ejecutores/rutinas con Queue + Scheduler para disparar notificaciones
- Reglas base globales reutilizando `notification_rules`
- Registro/auditoría mínima en `fermenty_notifications`

**Salida esperada:** notificaciones consistentes y trazables, listas para personalización por usuario.

---

### 4) Añadir mediciones a lotes activos (tipo logs)
**Por qué ahora:** mejora el core del producto (seguimiento del fermento) y usa modelos ya existentes (`measurements`, `daily_logs`).

**Incluye:**
- Alta de mediciones desde vista de lote activo
- Tipos iniciales sugeridos: `ph`, `temperature`, `weight`, `brix` (si aplica)
- Relación clara con `batch_id` + timestamp
- Visualización básica de historial por lote

**Salida esperada:** cada lote activo permite registrar y consultar mediciones ordenadas por fecha.

---

### 5) Hints por paso (algunos Premium)
**Por qué aquí:** enriquece la experiencia sobre pasos existentes sin cambiar el flujo principal.

**Incluye:**
- Campo de ayuda/consejo por `guide_step` o `batch_step`
- Flag de acceso (`free`/`premium`)
- Render condicional en la vista del paso

**Salida esperada:** cada paso puede mostrar consejos útiles y restringir algunos por plan.

---

### 6) Preferencias de notificaciones en perfil
**Por qué después:** depende de tener las rutinas de notificación estables para que el usuario pueda gestionar algo ya operativo.

**Incluye:**
- Centro de preferencias por usuario
- Opt-in/opt-out por tipo de notificación
- Canales por tipo: email / push (push puede quedar como “preparado” si aún no está activo)
- Frecuencia o nivel (todas / importantes)

**Salida esperada:** usuario controla qué recibe y por qué canal, sin tocar reglas globales del sistema.

---

### 7) Guardar recetas propias (Premium)
**Por qué en esta fase:** se implementa cuando autenticación/notificaciones/core de lotes ya están estables; sirve como base para comunidad.

**Incluye:**
- CRUD de recetas del usuario autenticado
- Regla de acceso por plan (`premium`)
- Estado inicial de receta: `draft`
- Fotos de receta (mínimo 1 opcional)

**Salida esperada:** usuario premium puede crear/editar/borrar sus recetas y ver su listado privado.

---

### 8) Visibilidad pública de usuario y sus lotes (feature premium)
**Por qué en esta fase:** depende de controles de privacidad y de una experiencia de perfil más madura.

**Incluye:**
- Switch de privacidad en perfil: “perfil público”
- Opción adicional: “mostrar mis lotes”
- Reglas para ocultar datos sensibles
- Guard/policy para acceso público seguro

**Salida esperada:** usuario decide si su actividad es visible públicamente; por defecto privado.

---

### 9) Compartir recetas en Comunidad (con fotos)
**Por qué al final:** depende de 7) recetas propias ya estables y 8) decisiones de visibilidad.

**Incluye:**
- Modelo de publicación comunitaria (recomendado: `community_posts` reutilizable + vínculo a `recipe_id`)
- Flujo “Publicar receta” desde receta propia
- Estados: `draft`, `published`, `archived`
- Soporte de galería/fotos y metadatos mínimos

**Salida esperada:** recetas propias se pueden publicar en comunidad de forma controlada y moderable.

---

### 10) Redactar comparativa Free vs Premium + copy para landing "¿Por qué Premium?"
**Por qué ahora:** con el feature de pistas Premium ya definido, conviene alinear el mensaje comercial con beneficios concretos y no genéricos.

**Incluye:**
- Matriz clara de funcionalidades Free vs Premium
- Argumentario centrado en resultados para el usuario
- Borrador de secciones para landing: problema, valor, comparación, FAQs, CTA
- Copys cortos para tarjetas y CTA secundarios

**Salida esperada:** documento de copy aprobado para construir la landing "¿Por qué Premium?" sin rehacer textos.

---

## Dependencias clave
- (3) depende parcialmente de (2) para canal email
- (6) depende de (3)
- (9) depende de (7)
- (8) condiciona parte de (9) si se desea autor visible

## TODO futuro
- Integrar notificaciones push para móviles una vez esté diseñado el API móvil y definida la gestión de tokens de dispositivo.

- **(PRO / B2B) Etiquetas de lote con QR / código de barras.** Cada lote puede **imprimir una etiqueta**
  con un código (QR o código de barras) que identifica el lote. Al **escanearlo con la app** se abre
  directamente su ficha y se pueden **añadir mediciones rápidamente** desde el panel — pensado para
  uso profesional/obrador (muchos lotes simultáneos, trazabilidad e inventario).
  - **Identificador estable:** codificar un UUID/slug firmado del lote, no el `id` secuencial (no exponer
    ni permitir colisiones/enumeración).
  - **Plantilla imprimible:** vista de etiqueta (etiqueta térmica individual y/o A4 con varias por hoja)
    con nombre del lote, fermento, fecha de inicio y el código.
  - **Ruta de escaneo / deep link:** p. ej. `/l/{code}` (web) o esquema en `app.fermenty.*` que resuelve
    el código → ficha del lote + acceso directo a "añadir medición".
  - **Captura:** escaneo por cámara desde la app; en B2B, soporte de lector de código de barras físico.
  - **API:** endpoint para resolver `code → batch` y para registrar medición desde el flujo de escaneo
    (reutiliza la lógica de mediciones existente, alineado con la futura API móvil).

## Recomendación de ejecución por sprints
- **Sprint A:** (1) + (2)
- **Sprint B:** (3) + (4)
- **Sprint C:** (5) + (6)
- **Sprint D:** (7)
- **Sprint E:** (8) + (9)

## Criterio de calidad mínimo por tarea
- Validaciones con `FormRequest`
- Policies para ownership/acceso premium
- Tests feature básicos de happy path + autorización
- En tareas de notificación: tests de jobs/cola + comandos programados
- UI consistente con vistas actuales Blade