sh0 v1.6.0 salió con todas las funcionalidades previstas. 230+ endpoints API, 103 herramientas MCP, 170 plantillas de despliegue, servidores de correo, auth, realtime, functions -- la plataforma completa. Luego el CEO se sentó a usarla de verdad. Lo que siguió fue la sesión de QA más productiva en la historia de sh0.
La preparación
El CEO probó sh0 como lo haría un desarrollador: desplegar stacks, crear dominios de correo, configurar tareas cron, aprovisionar servidores de autenticación. Cada bug se reportó en tiempo real vía captura de pantalla + registro de errores, y se corrigió de inmediato en la misma conversación.
Sin entorno de staging. Sin tickets de Jira. Sin planificación de sprint. Solo: "esto está roto" -> investigar -> corregir -> "siguiente problema."
Los bugs (y lo que revelan)
La comparación de cadenas (bug de 0,05 $, impacto de 500 $)
El badge SSL en la página de configuración mostraba "SSL pending" aunque HTTPS funcionaba perfectamente. Causa raíz: la API de Caddy devolvía "managed" pero el dashboard verificaba "active". Una comparación de cadenas. Una sola palabra de diferencia en el comportamiento.
Este tipo de bug hace que los usuarios desconfíen del producto. Si el indicador SSL está mal, ¿qué más está mal? Una corrección de una línea que preserva la credibilidad.
El bucle infinito (trampa de reactividad de Svelte 5)
La pestaña Queue del correo causaba un refresco infinito del navegador. El culpable: una variable $state que contenía un handle de setInterval, leída y escrita dentro de un $effect. La reactividad granular de Svelte 5 significa que cada lectura crea una dependencia, cada escritura dispara una reevaluación. El handle del timer no necesita reactividad -- es un detalle de implementación, no estado de interfaz.
Lección: En Svelte 5, no todo debe ser $state. Los handles de timer, las referencias WebSocket y la gestión interna deben ser let simple.
La imagen fantasma (arqueología del registro Docker)
El servidor Auth (Logto) no se creaba porque la imagen Docker logto/logto:1.22.0 no existe. Nunca existió. La imagen correcta es svhd/logto -- publicada por Silverhand, la empresa detrás de Logto, usando su antigua abreviatura como namespace en Docker Hub.
Pero incluso tras corregir el nombre de la imagen, el contenedor entraba en un ciclo de crash con npm error Missing script: "node". La imagen svhd/logto usa ENTRYPOINT ["npm", "run"] con CMD ["start"]. Nuestra sobreescritura CMD ["node", ".", "--env", "production"] se añadió al entrypoint, resultando en npm run node . --env production -- y no existe un script npm llamado "node."
La corrección: sobreescribir el entrypoint completamente con el patrón oficial de docker-compose: sh -c "npm run cli db seed -- --swe && npm start".
Lección: Al integrar imágenes Docker de terceros, siempre verifique el Dockerfile real, no la documentación que podría referenciar una versión diferente.
La memoria muscular de cPanel
Un desarrollador intentó crear una tarea cron con: curl -s "https://api.example.com/cron" > /dev/null 2>&1
Esta es la sintaxis crontab estándar que todo administrador Linux ha escrito cientos de veces. Pero sh0 ejecuta los comandos curl de forma nativa (sin shell), por lo que los caracteres > y & eran rechazados por el validador de comandos.
En lugar de pedir a los usuarios que cambien sus hábitos, añadimos sanitize_command() que elimina las redirecciones shell antes de la validación. Pegue su línea de crontab tal cual; sh0 se encarga del resto.
La contraseña admin silenciosa
El servidor de correo Stalwart genera automáticamente una contraseña de admin en el primer arranque y la imprime en los logs del contenedor. Nadie lee los logs del contenedor. Los usuarios creaban buzones de correo y luego no podían iniciar sesión en el webmail porque nunca supieron que existía la contraseña de admin.
La corrección: descifrar la contraseña de admin almacenada y mostrarla en la pestaña Overview del correo con un botón de mostrar/ocultar. La contraseña siempre estuvo ahí en la base de datos -- simplemente no se mostraba.
El método
Cada corrección siguió el mismo patrón:
- El CEO reporta -- captura de pantalla + registro de errores, sin interpretación
- La IA investiga -- lee el código fuente, rastrea la causa raíz
- La IA corrige -- cambio mínimo, sin desvío de alcance
- El CEO continúa probando -- reporta el siguiente problema
Sin cambios de contexto. Sin gestión de tickets. Sin "lo atendemos en el próximo sprint." El ciclo de retroalimentación se medía en minutos, no en días.
Tras todas las correcciones, un agente de auditoría revisó cada cambio para verificar la corrección, la coherencia y las regresiones. Encontró 3 problemas adicionales (un campo de struct faltante que habría roto la compilación, una fuga de timer y un bug de ordenamiento de patrones). Todos corregidos antes de la publicación.
Los números
| Métrica | Valor |
|---|---|
| Bugs encontrados | 20+ |
| Servicios afectados | Mail, Auth, Cron, Realtime, Functions, Settings |
| Archivos modificados | 72 |
| Líneas modificadas | +4.856 / -3.508 |
| Tests pasando | 155/155 |
| Tiempo total de corrección | ~4 horas |
| Versión | v1.6.0 -> v1.6.1 |
Lo que esto significa
El QA tradicional para una plataforma de este tamaño requeriría un equipo de testers una semana para encontrar estos bugs, y un equipo de desarrolladores otra semana para corregirlos. Nosotros lo hicimos en una sola sesión porque la IA tiene toda la base de código en contexto -- cada handler Rust, cada componente Svelte, cada clave i18n en 5 idiomas.
La IA no se cansa de leer registros de errores. No olvida lo que hace el handler de correo cuando pasa a corregir el planificador cron. No necesita reaprender la estructura del proyecto para cada bug.
Esto es lo que significa "IA como CTO" en la práctica: no reemplazar el juicio humano sobre qué probar, sino amplificar la velocidad a la que los problemas se encuentran, diagnostican y corrigen. El tiempo del CEO es el cuello de botella. Cada minuto esperando un build o buscando un bug es un minuto que no se dedica a decidir qué debe ser el producto.
v1.6.1 es más limpia que v1.6.0. No porque lo planeáramos así, sino porque la probamos como lo harían los usuarios.