La funcionalidad
El Mail MVP de sh0 convierte un solo comando CLI en una plataforma de hosting de correo completa. Stalwart Mail Server, generación de claves DKIM, verificación DNS, configuración automática de Cloudflare, gestión de buzones y alias -- todo envuelto en un dashboard de 4 pestañas con soporte i18n en 5 idiomas.
La implementación abarca ~5 000 líneas en 30 archivos: una migración SQL, 3 modelos Rust, crypto DKIM, un gestor de contenedores Docker, un cliente API REST de Stalwart, verificación DNS vía dig, extensiones DNS de Cloudflare, 15 handlers API con RBAC y un dashboard Svelte 5 con un asistente de configuración, página de detalles y modales CRUD completos.
El problema del código generado por IA
Cada sesión de IA optimiza localmente. La sesión 1 construye la capa de base de datos. La sesión 2 construye la API. La sesión 3 construye el dashboard. Cada sesión produce código funcional -- pero ¿la interfaz TypeScript del dashboard coincide con la struct de respuesta Rust? ¿La cadena de formato del registro DNS en mail_crypto.rs coincide con lo que muestra el asistente de configuración? ¿El enum DnsStatus se serializa como "pass" o "Pass"?
La consistencia entre capas es donde se esconden los bugs. Las piezas individuales funcionan bien de forma aislada; la integración es donde las cosas se rompen.
La metodología
Usamos un pipeline construir-auditar-auditar-aprobar:
- Sesiones de build (3 sesiones): cada una enfocada en una capa. Infraestructura, API, Dashboard.
- Auditorías focalizadas (2 rondas): cada sesión de auditoría revisa una sesión de build. La auditoría de la sesión 2 encontró 4 problemas importantes (timeouts de dig, limpieza de contenedores Docker huérfanos, registro de fallos parciales de Cloudflare, direcciones de alias opcionales). La auditoría de la sesión 3 encontró 3 problemas importantes (cadenas en inglés codificadas, claves i18n incorrectas para estados vacíos, texto de estado sin traducir).
- Auditoría global (esta sesión): un contexto fresco lee cada archivo y verifica el sistema en su conjunto.
Lo que encontró la auditoría global
Definimos 230 elementos de checklist en 19 secciones:
- Corrección del esquema: 11 verificaciones (tipos de columnas, restricciones, índices, claves foráneas)
- Capa de modelo: 13 verificaciones (mapeos from_row, métodos CRUD, anotaciones serde)
- Crypto: 10 verificaciones (generación de claves DKIM, cadenas de formato DNS, manejo de errores)
- Docker: 14 verificaciones (imagen, puertos, volúmenes, etiquetas, idempotencia, limpieza)
- Cliente Stalwart: 11 verificaciones (auth, endpoints, manejo de errores, timeouts)
- Verificación DNS: 12 verificaciones (6 tipos de registros, prevención de inyección, timeouts)
- Cloudflare: 9 verificaciones (creación MX/TXT, manejo de fallos parciales, TTL)
- Handlers API: 30 verificaciones (15 endpoints, RBAC, cifrado, validación, registro de auditoría)
- Router y OpenAPI: 6 verificaciones
- Tipos solicitud/respuesta: 8 verificaciones
- Tipos TypeScript y cliente API: 9 verificaciones (correspondencia campo por campo)
- Páginas dashboard: 51 verificaciones (lista, asistente, detalles con 4 pestañas)
- i18n y acentos franceses: 14 verificaciones (los acentos son críticos -- es una plataforma educativa)
- Seguridad: 12 verificaciones (cifrado, inyección, XSS, secretos en respuestas)
- Consistencia entre capas: 9 verificaciones (BD == Modelo == API == TypeScript == Dashboard)
- Verificación de correcciones previas: 7 verificaciones (las 7 correcciones de auditorías previas siguen en su lugar)
- Verificación de build: 4 verificaciones
Resultados: 227 aprobados, 3 fallidos. 0 críticos. 2 importantes (ambos corregidos en la sesión).
Los dos hallazgos importantes fueron problemas de i18n: cadenas en inglés codificadas que evitaban el sistema de traducción, y una columna created_at faltante en la tabla de buzones. Ambos se corrigieron añadiendo 20 nuevas claves i18n en los archivos de 5 idiomas y actualizando 3 componentes Svelte.
Por qué funciona
La idea clave es perspectivas diversas a la granularidad correcta:
- Las sesiones de build optimizan para la corrección dentro de su capa
- Las auditorías focalizadas detectan bugs dentro de esa capa desde una perspectiva fresca
- La auditoría global detecta inconsistencias entre capas que ninguna auditoría de una sola capa puede ver
La auditoría global encontró problemas que ambas auditorías focalizadas habían pasado por alto -- inglés codificado en fallbacks de error, la columna de tabla faltante. Estos son el tipo de bugs que se filtran cuando cada revisor solo ve su propia porción.
Los números
| Métrica | Valor |
|---|---|
| Líneas de código totales | ~5 000 |
| Archivos tocados | 30 |
| Sesiones de build | 3 |
| Rondas de auditoría | 3 (2 focalizadas + 1 global) |
| Hallazgos totales en todas las auditorías | 10 |
| Hallazgos críticos | 0 |
| Hallazgos importantes corregidos | 9 |
| Hallazgos menores | 4 |
| Elementos de checklist verificados | 230 |
| Idiomas con acentos correctos | 5 |
El costo del pipeline de auditoría es ~30 minutos de cómputo IA. El costo de publicar una funcionalidad de hosting de correo con una fuga de clave DKIM, una inyección de comando en dig, o "Boites aux lettres" sin el acento circunflejo en una plataforma educativa? Mucho mayor.