# Fermenty — El mentor en el Panel

> Briefing para Claude Code. Integra la formulación en el escritorio reutilizando lo
> que ya existe en la PWA. **Empieza por un análisis, no por código:** el alcance real
> depende de cómo esté hoy el formulador, y eso no se puede decidir desde fuera.
>
> Referencias: `docs/Lexico.md` (§4 El motor, §6 Congelar/snapshot, Un solo dueño),
> `docs/Matematica_Motor.md`, `docs/Planes.md` (§6 decisiones abiertas),
> `docs/Encaminamiento.md` (§1, §2), `docs/Afinador_Web.md` (§5 Por dónde pasa el cálculo).
>
> Destino sugerido: `docs/Mentor_en_Panel.md` · Documento vivo · v1 · 2026-08-03
>
> **Informe de la fase 0: `docs/Mentor_en_Panel_Fase0.md` (2026-08-03).** Nota: de
> los documentos citados arriba solo existen `01_LEXICO.md` y `Matematica_Motor.md`;
> el detalle está en la nota previa del informe.

---

## 0. Las tres superficies, y cómo se llaman

Queda fijado el vocabulario, porque hasta ahora «panel» y «ERP» se usaban indistintamente:

| Nombre | Dónde | Quién | Qué es |
|---|---|---|---|
| **PWA** | `app.fermenty.es/` | Usuario | Una tanda, ahora, en la cocina |
| **Panel** | `app.fermenty.es/panel/` | Usuario | Escritorio. Muchas tandas, planificando |
| **ERP** | `erp.` | Interno | Administración del catálogo. Reservado además para el escalón 3 (Obrador) |

PWA y Panel son **la misma aplicación y el mismo usuario**, con dos disposiciones.
La canónica de una tanda es `/tandas/{id}`, sin prefijo, la haya creado quien la haya
creado (`Encaminamiento.md` §2). El ERP no entra en este briefing.

---

## 1. El encargo

**Que se pueda formular y arrancar una tanda desde el Panel, exactamente igual que
desde la PWA.**

El Panel ya tiene sus pantallas y su estructura. Lo que falta es el punto donde se
inicia un fermento.

***No es*** un rediseño del Panel. No se tocan navegación, layout general ni pantallas
existentes salvo el enganche del punto de entrada.

***No es*** el Afinador. El instrumento de cuatro ejes es del obrador y no se expone:
«los cuatro ejes» es vocabulario del motor y está prohibido en la interfaz
(`Planes.md` §5).

***No es*** el escalón 3. Lotes propios, trazabilidad y recetas del productor **no
entran**, aunque el Panel parezca su sitio natural. Si entran ahora, entran gratis y
ya no salen (`Planes.md` §8).

***No es*** una segunda implementación de nada.

---

## 2. Fase 0 — Análisis antes de tocar nada

**Entregable de esta fase: un informe en markdown. Cero código, cero migraciones,
cero refactor.** El alcance de las fases siguientes se decide leyéndolo.

### Lo que hay que averiguar

**a) Dónde vive hoy la formulación en la PWA**
- ¿Hay una clase de servicio (`App\Mentor` o equivalente) o la lógica está en el
  controlador / en la vista / repartida?
- ¿Cuál es su firma real: qué recibe y qué devuelve?
- ¿Hay algún cálculo del motor en JavaScript de cliente?

**b) Qué ocurre exactamente al «empezar tanda»**
- Qué tablas se escriben y en qué orden.
- Qué se congela: pasos, ingredientes, cantidades, ventanas previstas, ficha,
  versión del motor. ¿Está todo, o hay campos que se resuelven leyendo la guía viva?
- ¿El snapshot es autónomo? (§6 del Léxico: hubo 40 filas que no lo eran).

**c) Si el Panel ya tiene algún camino para crear tandas**
- ¿Existe un controlador propio? ¿Un `store` paralelo? ¿Un formulario reducido?
- Si existe, hay que saberlo antes de añadir otro: sería el tercer dueño.

**d) Dónde se comprueban los candados**
- El límite de tandas: dónde se lee, y si sigue cableado a `3` (`Planes.md` §6b).
- ¿Se comprueba en un sitio o en cada controlador?

**e) Qué viaja al cliente hoy**
- ¿Sale algún coeficiente de la ficha en JSON, en `<script>`, o en respuestas AJAX?
- La regla es dura: **nada del motor viaja al cliente.** El cliente manda
  identificadores y recibe salida presentable (`Afinador_Web.md` §5).

**f) Autenticación y sesión compartidas**
- ¿PWA y Panel comparten guard y sesión, o hay dos caminos?

### Formato del informe

Un archivo por pregunta no; un solo documento con seis apartados, cada uno con:
**qué se encontró · dónde (ruta:línea) · qué falta.**

> **No debe inventarse.** Si algo no existe, se escribe «no existe» — no se supone,
> no se describe cómo *debería* estar. Un informe con huecos honestos vale; uno
> completo a base de suposiciones hace que la fase 1 se planifique sobre humo.

---

## 3. La bifurcación que abre el informe

El resultado de (a) y (b) decide el trabajo, y es un dato, no una opinión:

**Camino A — el formulador ya es un servicio con entrada y salida limpias.**
El Panel es una vista más que llama a lo mismo. Es pequeño: una pantalla y un
enganche.

**Camino B — la lógica vive en el controlador de la PWA, acoplada a su vista.**
Hay que extraerla antes. Y conviene saber que **esa extracción hay que hacerla de
todos modos**: el afinador público la necesita igual (`Afinador_Web.md` §5), así que
no es coste hundido de este encargo, es trabajo adelantado. El Panel sería entonces
su segundo consumidor y la prueba de que el contrato aguanta.

En el informe hay que decir cuál de los dos es, y por qué.

---

## 4. La regla que no se negocia

**Un solo camino para crear la tanda.**

Formular desde el Panel tiene que producir una fila **indistinguible** de la que
produce la PWA: mismo snapshot, misma ficha congelada, misma versión del motor,
mismos campos rellenos. La única diferencia admisible es un registro de procedencia
si se quiere medir —y sería un puntero de origen, sin que nada dependa de él.

Si el Panel tiene su propio `store`, el día que cambie el snapshot se arregla en un
sitio y no en el otro, y la divergencia será silenciosa hasta que alguien compare dos
tandas. Es exactamente el fallo que el proyecto lleva nombrado desde el principio:
dos sitios reclamando ser dueños de lo mismo.

---

## 5. Lo que cambia entre superficies, y lo que no

| | PWA | Panel |
|---|---|---|
| Preguntas que se hacen | — | **idénticas** |
| Motor y coeficientes | — | **idénticos** |
| Lo que se congela | — | **idéntico** |
| Candados del plan | — | **idénticos** |
| Avisos y barandillas | — | **idénticos** |
| Disposición en pantalla | Por pasos, una cosa a la vez | Puede caber entero |

**Solo cambia la disposición.** El escritorio tiene sitio para enseñar la propuesta y
sus controles a la vez, en vez de en secuencia — y eso es una mejora real, porque
ver la ventana moverse al arrastrar la temperatura es lo que convence.

> **El riesgo concreto de esta pantalla:** hay hueco, y el hueco invita a añadir
> campos «ya que estamos». Cualquier entrada nueva que no exista en la PWA **no es un
> cambio de maquetación: es un cambio del modelo**, y se decide en
> `Matematica_Motor.md`, no aquí.

---

## 6. Los candados

Se leen del plan, en **una capa**, no por superficie. Si el Panel comprueba por su
cuenta, algún día el plan gratis tendrá tandas ilimitadas en escritorio y nadie se
enterará.

Dos avisos:

- **El límite de tandas** sigue pendiente de leerse del plan. Si el informe confirma
  que está cableado, se arregla **en la capa común**, no en el Panel.
- **«Recetas especiales» no existe como dato** (`Planes.md` §6a): no hay campo ni
  criterio. El Panel **no inventa uno**. Hasta que exista, esa distinción no se
  representa en ninguna pantalla.

---

## 7. 🔴 Decisiones abiertas que tocan esto

**a) Qué cuenta como «tanda activa»** (`Planes.md` §6d). ¿Ocupa hueco una en 2F? ¿Una
cerrada sin valorar? En la PWA el usuario ve una tanda y el número es abstracto; en el
Panel las ve todas a la vez y **el número tiene que ser defendible en pantalla**.
Aquí muerde más que en ningún otro sitio.

**b) Si el Panel expone la capa de override o solo los presets.** «Igual que la PWA»
resuelve esto por definición: lo que tenga la PWA. Queda anotado por si la PWA aún no
la tiene, en cuyo caso tampoco la tiene el Panel.

**c) El punto de entrada dentro del Panel.** Dónde se engancha exactamente depende de
la estructura que ya existe, y sale del informe de la fase 0.

---

## 8. Fases y entregables

| Fase | Qué se entrega | Bloquea a |
|---|---|---|
| **0** | El informe de §2. Sin código | Todo lo demás |
| **1** | Solo si camino B: extracción del formulador a servicio, con la PWA migrada a él y funcionando igual | Fase 2 |
| **2** | La pantalla del Panel, consumiendo lo mismo | Fase 3 |
| **3** | Verificación (§9) | — |

**Entre fase 0 y fase 1 hay una parada.** El informe se lee y se decide antes de
seguir. No encadenar.

---

## 9. Cómo se verifica

La prueba real no es que la pantalla se vea bien:

**Formular lo mismo desde las dos superficies y comparar las filas producidas.**
Deben ser idénticas salvo `id` y marcas de tiempo — snapshot de pasos, ingredientes,
cantidades, ventanas previstas, ficha congelada y versión del motor.

Si algo difiere, no es un detalle: es la divergencia empezando.

Además:
- El límite de tandas se comporta igual en las dos.
- Ninguna respuesta del servidor lleva coeficientes de la ficha.
- La tanda creada desde el Panel se abre y se sigue con normalidad desde la PWA, y al
  revés. Es la misma tanda; no hay tandas «de escritorio».

---

## 10. Fuera de alcance

- El bucle 1 y las vistas de agregado (el panorama de ventanas abiertas, comparar
  formulaciones). Dependen de que la ventana se mueva, y eso no está construido.
- El Afinador de cuatro ejes.
- Lotes, trazabilidad y recetas propias — escalón 3.
- Rediseño de pantallas existentes del Panel.
- Cualquier campo de entrada que no exista ya en la PWA.

---

## 11. No debe inventarse

- Ni coeficientes, ni valores por defecto del motor: salen de la ficha.
- Ni el criterio de «receta especial»: no existe todavía.
- Ni el número del límite de tandas: se lee del plan.
- Ni textos de aviso nuevos: los avisos son los del motor, con su clasificación
  `duro`/`blando` ya existente.
- Ni hallazgos en el informe de la fase 0: lo que no se encuentre, se declara ausente.

---

*Documento vivo. Cuando el informe de la fase 0 esté, esto se revisa antes de la fase 1.*