feat(F-054): completed feature

work/artifacts/F-054/architect.md

@@ -0,0 +1,31 @@
+# Architect — F-054
+
+## Diagnóstico
+- El backend (`dist/infrastructure/http/server.js`) muere sin dejar trazas de error en el log: el último `msg` es un `request completed` 200, y luego silencio.
+- Cuando el backend está caído, los proxies devuelven:
+  - `GET/POST /api/auth/login` en admin (3004) → **502** (catch del proxy en `[...path]/route.ts`)
+  - `POST /api/auth/login` en frontend (3003) → **500** (catch en `src/app/api/auth/login/route.ts`)
+- El frontend hardcodea `http://127.0.0.1:3000` mientras el admin usa `process.env.NEXT_PUBLIC_API_URL ?? 'http://127.0.0.1:3000'`. Inconsistencia menor pero no causa de este ticket.
+
+## Causa raíz probable
+El proceso fue terminado por SIGTERM/SIGKILL — posiblemente cuando el shell que lo lanzó (`nohup ... &`) fue reaped por el harness de Pi. `nohup` evita SIGHUP pero no SIGTERM/SIGKILL que pueda llegar desde el agente.
+
+## Diseño
+1. **Watchdog en `monolith.sh`**: nueva función `ensure_alive()` que verifica si el PID en `<service>.pid` sigue vivo (vía `kill -0`) y, si no, lo relanza con `spawn_service`. Se invoca al inicio de `status` y se ofrece como comando explícito `monolith.sh prod watch`.
+2. **Frontend `/api/auth/login`**: usar `process.env.NEXT_PUBLIC_API_URL ?? 'http://127.0.0.1:3000'` igual que el admin. Cambio defensivo (no causa el bug pero evita uno futuro si se despliega el frontend en otro host).
+3. **Diagnóstico de la muerte del backend**: añadir un handler de `uncaughtException` y `unhandledRejection` en `server.ts` que loguee el error antes de morir. No previene la muerte pero ayuda a diagnosticarla la próxima vez.
+4. **`monolith.sh prod status`** mejorado: ahora también dispara `ensure_alive` antes de imprimir la tabla, así el operador ve servicios vivos sin tener que reiniciar manualmente.
+
+## Alternativas descartadas
+- **systemd / launchd**: fuera del scope del proyecto (no se asume init del sistema).
+- **PM2 / forever**: añadiría una dependencia runtime al proyecto.
+
+## Acceptance
+1. Si el backend muere, `./project/scripts/monolith.sh prod status` lo detecta y lo relanza automáticamente.
+2. `frontend/src/app/api/auth/login/route.ts` lee `NEXT_PUBLIC_API_URL` con fallback a `127.0.0.1:3000`.
+3. `server.ts` loguea `uncaughtException` y `unhandledRejection` antes de morir.
+4. Smoke: matar backend manualmente (`kill <pid>`), esperar 5s, correr `monolith.sh status`, ver backend `running` de nuevo.
+
+## Riesgos
+- El watchdog añade latencia al `status` (1 ciclo de `kill -0` por servicio, <1ms).
+- Ningún cambio en runtime de los handlers API; solo el catch ya existente sigue devolviendo 500/502 cuando el backend está realmente caído.