[davidpp09]

El problema

Caddy servía /home/david/RestFoodF/dist — la misma carpeta que escribe npm run build. Compilar y publicar eran el mismo acto:

• probar un build tiraba a producción lo que hubiera en el árbol de trabajo;
• no había versión anterior a la que volver: el build acababa de sobrescribirla;
• un build a medias dejaba el dist a medias, en vivo, con las tablets pegadas a él.

Costó dos incidentes el 2026-07-27. Uno publicó un frontend apuntando a staging, porque Vite carga .env.local también en los builds de producción.

El arreglo

Caddy ahora sirve ~/deploys/restfood-frontend/current, un symlink a una release con fecha y sha. Publicar es mover el symlink: es atómico, ninguna petición ve un estado intermedio y no hay que recargar Caddy — la ruta se resuelve en cada petición.

El dist/ del repo vuelve a ser lo que siempre debió ser: una carpeta de trabajo que no le importa a nadie.

~/deploys/restfood-frontend/
├── current  -> releases/20260728-104140-18ae50a
├── previous -> releases/<la anterior>
└── releases/

Es el mismo molde que deploy/deploy.sh del backend, para que no haya dos formas de desplegar que aprender.

deploy-frontend.sh

1. Exige estar en main, limpio y actualizado.
2. Exige el check tests en verde para ese commit.
3. Aborta si existe .env.local — es exactamente como el frontend acabó apuntando a staging, y Vite no avisa.
4. Compila desde cero (rm -rf dist + npm ci).
5. Verifica que el bundle que pide index.html exista en el build. Si no, la tablet carga un HTML que pide un JS inexistente: pantalla en blanco sin un solo error en el servidor.
6. Copia a la release, mueve previous y luego current.
7. Verifica contra el sitio real (https://192.168.10.100/) que responda 200 y que esté sirviendo ese bundle. Si no, rollback automático.
8. Conserva 5 releases, nunca la actual ni la anterior.

rollback-frontend.sh

Intercambia current y previous, así un segundo rollback deshace el primero. Aquí el rollback siempre funciona: son archivos estáticos, sin migraciones de por medio como en el backend.

Estado en el servidor

El cambio de root en el Caddyfile ya está aplicado (respaldo en /etc/caddy/Caddyfile.respaldo-20260728-1041). La primera release es una copia byte por byte del dist que ya se estaba sirviendo, verificada con diff -r, así que para las tablets no cambió nada. Verificado después de recargar: raíz 200, mismo bundle index-DQjJfaAV.js, /inventario/existencias 401 (la API sigue ruteando) y /admin/insumos 200 (el try_files sigue en pie).

Y la comprobación que importa: se corrió npm run build después del cambio y producción no se movió.

Pendiente que esto NO resuelve

El dist/ del repo y la release en vivo pueden divergir sin que nada avise. No es grave — nadie sirve el dist — pero conviene saberlo al depurar.