# Plan de infraestructura y riesgos

Nació del diagnóstico en caliente del 2026-07-30, cuando Gilberto preguntó si
el stack aguanta escala y dónde están las debilidades. La respuesta corta: el
stack aguanta de sobra, **el riesgo es la concentración**, no el rendimiento.

## Lo medido ese día (para no discutir de memoria)

| Dato | Valor | Lectura |
|---|---|---|
| Tamaño de la base | 20 MB | 4% del límite del plan free |
| Conexiones | 19 de 60 | 32% |
| Consultas por índice | 527.000 vs 10.000 secuenciales | 98% indexadas |
| Plan Supabase | **free** | sin PITR |
| Respaldos listados | **ninguno** | 🔴 |
| Operadores de la imprenta | **1** | 🔴 bus factor |
| Proyectos en la cuenta Cloudflare | 6 (incluía Yalo) | punto único |

**Conclusión:** a esta escala se puede crecer 20 veces sin tocar una línea. Lo
que puede matar el negocio es un martes cualquiera con la base corrupta y sin
respaldo, o una laptop quemada con el único libro fiscal adentro.

---

## ✅ HECHO el 2026-07-30

- [x] **El respaldo de la Estación conectado.** Era el hueco más grave y más
      irónico: construimos el respaldo cifrado y la Estación de Gilberto no lo
      tenía activo; su libro existía en un solo disco. Se dio de alta el
      negocio como cliente de la imprenta (serial **EF-00006-0**), se le creó
      su llave y se conectó. Verificado: líneas cifradas subiendo, y la
      Estación aprendió su serial sola por el latido.
- [x] **Yalo fuera de la cuenta de Gustito** (`yalo` y `yalo-propuesta`
      eliminados de Cloudflare Pages, con OK explícito de Gilberto). El código
      sigue en `C:\Users\10\yalo` para redesplegarlo en su cuenta propia.

---

## 🔧 LO QUE PUEDO HACER YO (en orden de daño evitado)

### 1. Separar la base fiscal de la de Gustito
**Por qué:** hoy los restaurantes y la facturación de los clientes de imprenta
comparten el mismo Postgres. Un domingo pico compite con la emisión de
documentos, y son dos negocios con riesgo legal distinto. Después de tener
clientes de imprenta, separarlos es una migración con dolor; ahora es limpio.
**Qué implica:** proyecto Supabase nuevo solo para el esquema `fiscal`, mover
las tablas, apuntar las Pages Functions del sello, y probar el circuito
completo (emisión, respaldo, latido, verificación de serial).
⚠ Requiere que Gilberto cree el proyecto nuevo (es su cuenta).

### 2. Respaldo propio, que no dependa de Supabase
✅ **HECHO 2026-07-31.** Worker `gustito-respaldo-imprenta` (cron cada 6 horas):
pide el volcado del esquema `fiscal` (RPC `fn_respaldo_imprenta`, solo
service_role, migration `20260731100000`), lo cifra AES-256-GCM en el propio
Worker y lo guarda en el cubo R2 **privado** `gustito-respaldo-imprenta`
(`fiscal/AAAA-MM-DDTHH-mm.json.enc`, autocontenido: iv adelante). Nada se
borra: kilobytes por vuelta, historial completo. Comprobación sin abrir cajas:
`GET /ultimo` con `x-respaldo-secreto`. **Viaje redondo probado el mismo día**:
caja bajada y abierta con la clave, contenido verificado. La clave está en el
Worker y APUNTADA en `Desktop\EstacionFiscal\clave-respaldo-imprenta.txt`
(pendiente de Gilberto: pasarla a papel).

### 3. Bajar la ventana de pérdida de la Estación
✅ **HECHO 2026-07-31.** El sellado mismo programa la subida del respaldo a la
imprenta (3 segundos, agrupando ráfagas); la vuelta de los 10 minutos queda de
red de seguridad. Probado en `prueba_respaldo_afuera` sección 7.

### 4. Aviso automático si una Estación deja de respaldar
🟡 **MEDIO HECHO 2026-07-31**: `estaciones_vivas()` ahora trae
respaldo_lineas/respaldo_ultimo/respaldo_atrasado (migration `20260731090000`)
y la tabla de Estaciones del panel muestra SIN RESPALDO / ATRASADO / al día en
rojo y verde. Falta el aviso que llega solo (correo) sin abrir el panel.

### 5. Prueba de restauración de la base completa
**Por qué:** un respaldo que nunca se restauró no es un respaldo, es una
esperanza. La restauración del libro de la Estación SÍ está probada; la de la
base, no.
**Qué implica:** montar la base en un proyecto de prueba desde un volcado y
verificar que todo levanta.

### 6. Prueba de carga a escala real
**Por qué:** la única prueba que hay se corrió a propósito en chico (20
dispositivos, 30 pedidos) para no competir con Arepa Power. Falta la de
verdad.
**Qué implica:** correr `test_carga_broadcast.mjs` con números altos, pero
DESPUÉS de pasar a Pro (si no, se compite por el cupo con un cliente real).

---

## 👤 LO QUE LE TOCA A GILBERTO

1. **Plan Pro de Supabase** (US$25/mes) y activar PITR. Antes del primer
   cliente de imprenta: ahí van libros fiscales de terceros.
2. **Segunda persona con acceso**: que sepa operar la imprenta y dónde están
   las claves. Es el riesgo número uno y no se arregla con código.
3. **Rotar las 4 llaves** que quedaron en pausa (ver Bloque 1 del PENDIENTE).
4. **Cuenta de Cloudflare propia para Yalo**, cuando lo retome.
5. **Acuerdo de servicio escrito** con los clientes de imprenta: qué se promete
   de disponibilidad y qué pasa si falla. Protege a las dos partes.

---

## Umbrales de crecimiento (referencia)

| Escala | Qué hay que hacer |
|---|---|
| Hasta 10 locales | Nada |
| 10 a 50 | Pro (cupo de conexiones realtime) |
| 50 a 150 | Subir cómputo, offline en el POS del mesero, PITR, runbook |
| 150 a 500 | Réplica de lectura para reportes, particionar `pedidos` y
`fiscal.documentos` por mes |

**Regla de bolsillo:** infraestructura por debajo del 10% del ingreso mensual.
Lo que mata a un SaaS de restaurantes no es el servidor, es un mal domingo.