El 27 de marzo de 2026, sh0 pasó de ser una plataforma de despliegue con un CLI básico a una plataforma de despliegue con una experiencia de desarrollador completa. Dieciséis nuevos comandos. Dos nuevos endpoints de servidor. Un sistema de streaming WebSocket. Documentación en tres superficies en cinco idiomas. Seis sesiones de auditoría independientes. Cero bugs conocidos al final.
Este artículo cuenta la historia completa -- no los detalles de implementación (esos están en los artículos anteriores) sino la metodología, la línea temporal, las decisiones y las lecciones aprendidas.
La línea temporal
Trece sesiones. Cada sesión opera con contexto fresco -- sin arrastre de sesiones anteriores, sin sesgo del constructor.
El marcador de auditoría
| Métrica | Fase 1 | Fase 2 | Fase 3 | Global | Total |
|---|---|---|---|---|---|
| Críticos | 3 | 0 | 1 | 2 | 6 |
| Importantes | 8 | 1 | 0 | 5 | 14 |
| Menores | 9 | 2 | 4 | 7 | 22 |
| Corregidos | 11 | 1 | 1 | 7 | 20 |
| Regresiones | 0 | 0 | 0 | 0 | 0 |
Seis hallazgos Críticos en 3.200 líneas de código. Eso es un bug Crítico por cada 533 líneas.
Decisiones clave
Decisión 1: Auditar después de cada fase, no después de todas las fases Los bugs encontrados en la auditoría de la Fase 1 informaron los patrones usados en la implementación de la Fase 2. El patrón de escritura atómica, descubierto como corrección de bug en la Fase 1, se aplicó proactivamente en las Fases 2 y 3.
Decisión 2: Auditoría global después de auditorías por fase Las auditorías por fase examinan código dentro de un límite. No pueden detectar inconsistencias a través de límites. La auditoría global encontró problemas transversales.
Decisión 3: Reutilizar infraestructura existente Los 16 comandos se construyeron sobre código sh0 existente. No se introdujeron nuevas dependencias para código del lado del servidor.
Decisión 4: WebSocket con fallback HTTP El costo del fallback es ~50 líneas de código. El beneficio es compatibilidad retroactiva con cero rupturas.
Lo que aprendimos
- La brecha constructor-auditor es real. El contexto fresco produce mejores revisiones.
- Las auditorías entre fases son innegociables. Cinco de las veinte correcciones vinieron de la auditoría global.
- La deuda de documentación se acumula más rápido que la deuda técnica.
- Los wrappers delgados están subestimados. A veces el trabajo de mayor valor es el código más simple.
El punto más amplio
La metodología tiene tres propiedades:
- Separación de preocupaciones: El constructor optimiza para funcionalidades. El auditor optimiza para corrección. El documentador optimiza para claridad.
- Contexto fresco como funcionalidad: Cada sesión de auditoría comienza sin los supuestos del constructor.
- Convergencia a través de diversidad: Construir, auditar, auditar, aprobar. Cada pasada ve el código desde un ángulo diferente.
Dieciséis comandos. Seis sesiones de auditoría. Veinte correcciones de bugs. Cero regresiones. Un día.
Este artículo es parte de la serie "Cómo agregamos un CLI a sh0". Comienza desde el principio: Un comando para desplegar: cómo construimos sh0 push.