# Fermenty — Plan de documentación

> Punto de partida para retomar en otra sesión. Recoge lo acordado, lo que falta,
> y los documentos ya escritos que necesitan sitio.
>
> 2026-07-22

---

## 1. La estructura propuesta

**Base (de Manu):**

0. Descripción general
1. Léxico
2. Diagrama de flujos
3. Modelo BBDD
4. Style Guide
5. Marketing Guide (SEO, textos)

**Añadidos propuestos:**

6. **El modelo del dominio** — el documento del mentor (v0.8): los dos cortes, intensidad × equilibrio, el presupuesto de carbohidrato repartido en el tiempo, las barandillas. La fermentación hecha modelo. Es el documento más valioso del proyecto y no tenía sitio en la lista.
7. **El porqué de las decisiones** — por qué la receta no posee pasos, por qué las guías no se versionan, por qué la sal es regulador. Antídoto directo contra que alguien «arregle» una decisión deliberada creyendo que es una carencia. Ya está escrito disperso en cinco briefings; falta reunirlo **por decisión**, no por paso.
8. **Runbook de operaciones** — backup, deploy, restaurar, la regla del `USE` al importar dumps, migración inmutable, cómo montar `fermenty_test`. El menos glamuroso y el que más dolor evita: la base de desarrollo se perdió dos veces por algo que cabe en tres líneas.
9. **Contrato de la API** — antes de que lleguen el TWA y Flutter. Hoy la PWA es la única consumidora y cabe en la cabeza; con dos clientes deja de caber.

**Dos apuntes de estructura:**

- **«Diagrama de flujos» son dos documentos**, no uno: flujos de *usuario* (qué ve alguien desde que aterriza hasta que cierra un lote) y flujos de *datos* (cómo una formulación se convierte en tanda congelada). Preguntas distintas, momentos de consulta distintos.
- **Separar vigente de histórico.** Dos carpetas: lo que describe el estado actual del sistema, y lo que cuenta cómo se llegó aquí (briefings incluidos). La distinción no es temática, es de tiempo verbal.

---

## 2. Documentos ya escritos que necesitan casa

Si no se les da sitio ahora, se convierten en lo que queríamos evitar.

| Documento | Naturaleza |
|---|---|
| Léxico (v2) | Vigente — va directo a `docs/Lexico.md` |
| El mentor incorporado v0.8 | Vigente — es el modelo del dominio (#6) |
| Simulación de UI (20 huecos) | Vigente — alimenta flujos de usuario (#2a) |
| ERM clasificación→tanda (SVG) | Vigente — alimenta modelo BBDD (#3) |
| Esquema actual vs v0.8 (v3) | Histórico — mapa de migración |
| Briefings pasos 1–5 | Histórico — pero contienen el «porqué» que hay que extraer a #7 |
| `Paso*_Deuda.md` | Vigente mientras la deuda no venza |
| `Plan_Pasos.md` | Vigente |

---

## 3. `CLAUDE.md` en la raíz

Sin él la documentación existe pero no la lee nadie automáticamente. Con él, cada sesión de Claude Code arranca sabiendo el léxico y los principios sin que se los peguen.

Debe contener, o apuntar a: los cinco principios, la lista de defunción con su paso, el léxico, y las reglas de operación (migración inmutable, el `USE` de los dumps).

---

## 4. Estado del proyecto al guardar esto

- Pasos 1–4 cerrados y desplegados. Dev = prod.
- Paso 5 (ingredientes) en su segundo punto de parada: mapeo presentado, pendiente de confirmar **el azúcar** (clase padre «Azúcar» propuesta) y **el té de la receta clásica**.
- Correcciones pendientes de aplicar al perfil: claves neutras de unidad (`*_per_unit`) más unidad canónica como columna en `ingredients`; anotar que el SCOBY con perfil `{0,0}` es correcto y no un error; «Otras verduras» es un hueco de guía, no deuda de contenido.
- Sin hacer y sin depender de nada: **el backtest** — las tandas recordadas de LIRONA, escritas antes de ver ninguna salida del modelo.