La Fase 4 agregó dos funcionalidades que cambian cómo los desarrolladores interactúan con sh0 durante el desarrollo activo. La primera, sh0 watch, elimina la necesidad de escribir sh0 push después de cada cambio. La segunda, streaming de logs de build por WebSocket, reemplaza el bucle de polling HTTP de 1,5 segundos con entrega de logs en tiempo real.
Ninguna funcionalidad es requerida para desplegar. Ambas hacen que el despliegue sea invisible -- que es exactamente el punto.
sh0 watch -- El observador de archivos
El concepto es simple: observar el directorio del proyecto por cambios, esperar dos segundos de debounce, re-ejecutar sh0 push. El desarrollador guarda un archivo, y en segundos, la versión actualizada está en línea.
La arquitectura usa notify versión 7, que proporciona APIs nativas de eventos del sistema de archivos: kqueue en macOS, inotify en Linux. La arquitectura es un bucle de eventos basado en canales con tokio::select! para shutdown elegante.
Debouncing
Los editores de archivos no guardan atómicamente. Una sola acción de "Guardar" en VS Code puede producir tres a cinco eventos del sistema de archivos. Sin debouncing, cada uno de esos eventos dispararía un push separado. La lógica de debounce recolecta eventos por una ventana configurable (predeterminada 2000ms) antes de disparar.
La decisión de diseño clave está en la ruta de error: las fallas de push imprimen un error y continúan observando. Un error de sintaxis en el código del desarrollador no debería matar al observador.
Lógica de ignorado compartida
La auditoría global encontró que watch.rs tenía su propia lógica de ignorado que divergía de push.rs. La corrección fue extraer funciones compartidas de push.rs.
Streaming de logs de build por WebSocket
El sh0 push de la Fase 1 hacía polling del estado de despliegue cada 1,5 segundos vía HTTP. El streaming WebSocket resuelve la latencia (líneas de log aparecen con latencia sub-100ms) y la carga (sin sobrecarga de polling).
El nuevo endpoint GET /api/v1/deployments/:id/stream actualiza la conexión HTTP a WebSocket y transmite contenido de logs de build. La autenticación sigue el mismo patrón que los endpoints WebSocket existentes de sh0: el token se pasa como parámetro de consulta.
WebSocket primero, fallback HTTP
El comando push ahora intenta streaming WebSocket primero y recurre a polling HTTP si la conexión falla. El fallback es importante por dos razones: algunos proxies inversos eliminan encabezados de actualización WebSocket, y el CLI debe funcionar contra servidores sh0 que no tienen el endpoint de stream.
La diferencia en experiencia del desarrollador
Con la Fase 4, el desarrollador escribe un comando al inicio de su sesión y nunca piensa en despliegue de nuevo. Cada guardado dispara un push. Cada línea de log se transmite en tiempo real. Esto no se trata de ahorrar pulsaciones de teclas. Se trata de mantener al desarrollador en estado de flujo.
Siguiente en la serie: El auditor encontró lo que el constructor pasó por alto -- Una inmersión profunda en la metodología de auditoría multi-sesión: 5 Críticos, 12 Importantes y 19 Menores en 3.200 líneas de código.