Vercel construyó. Vercel desplegó. Y el artículo no apareció.
Eso fue lo primero que noté esta mañana: la última publicación de The Chronicles —sobre por qué construí Ledger Wealth— no estaba en olaveruiz.cl. El dashboard de Vercel mostraba verde. Sin errores. Sin warnings. Solo silencio.
Este tipo de bug es el más molesto que existe en desarrollo web: el que no grita.
El diagnóstico
El primer instinto fue revisar el frontmatter del archivo .md. Fecha correcta, draft: false, todo en orden. Luego el build local: npm run build en el directorio del proyecto. Y ahí apareció el error real, el que Vercel había decidido ignorar en silencio:
Cannot find package '@vercel/analytics'@vercel/analytics estaba importado en Layout.astro y en WealthLayout.astro. Pero no estaba en package.json. Funcionaba en local porque lo tenía instalado globalmente de alguna sesión anterior. En el servidor limpio de Vercel, no existía.
La dependencia faltante rompía el build. El build fallaba. El artículo no aparecía. Y Vercel no te dice nada.
La solución fue trivial: npm install @vercel/analytics --legacy-peer-deps, commit del package.json y package-lock.json actualizado, push. Tres minutos. El aprendizaje tomó más.
Lo que aprendí (y quedó documentado)
Desde hoy, LEARNINGS.md tiene una entrada nueva:
Vercel — Dependencias faltantes rompen el build silenciosamente. Si una dependencia está importada en el código pero no declarada en
package.json, el build de Vercel falla sin mensaje de error claro. El ambiente local puede enmascarar el problema si la dependencia está instalada globalmente. Reproducción:astro builddesde cero en una carpeta limpia.
Este es exactamente el tipo de aprendizaje que justifica el Build in Public. No es glamoroso. No es un nuevo feature. Es un error de 20 minutos que no debería repetirse.
La otra mitad del día: separar Ledger
Con el artículo publicado, el objetivo del resto de la sesión era más estructural: separar Ledger del monorepo corporativo.
Ledger empezó como un módulo dentro de jolaveruiz/olave-ruiz-corporation. Tiene backend FastAPI, base de datos Supabase, encriptación AES-256-GCM, y un frontend Astro completo. Demasiado para vivir mezclado con el sitio web y los chronicles. El precedente fue LabelLoop, que ya tiene su propio repo.
Preparé los 29 archivos del nuevo repo jolaveruiz/Ledger: backend completo (routers de auth, emails y wealth), schemas SQL, servicios de crypto y Gmail, y el frontend Astro con sus design tokens y páginas. The Architect auditó todo antes del push.
La auditoría encontró dos puntos críticos que se corrigieron:
- El endpoint
/emails/syncaceptabauser_idpor query param. En producción eso es un vector de ataque. Se agregó un guard que bloquea el endpoint fuera de entorno de desarrollo. - Lo mismo para
/auth/refresh/{user_id}. Solo funciona enAPP_ENV=development. - Los docs interactivos de FastAPI (
/docs,/redoc) se desactivan en producción.
Todo esto antes de que una sola línea llegue al repo público.
El proxy que no estaba
El push falló. No por el código, sino por infraestructura: el proxy git local que permite las operaciones con GitHub solo corre cuando el MCP está completamente conectado, y en esta sesión el puerto tardó en levantarse.
La solución temporal fue usar el MCP de GitHub directamente para pushear los cambios al repo corporativo. Para el repo de Ledger, los archivos están listos y commitados. El push queda pendiente para la próxima sesión.
Hay algo honesto en esto: no siempre el día termina con todo desplegado. A veces el ambiente falla. A veces el proxy no arranca. El trabajo igual avanzó.
El tercer hilo: gate_testing
La tercera decisión del día fue corporativa: agregar gate_testing como gate obligatorio antes de cualquier deploy.
Hasta hoy el pipeline tenía ocho gates: desde gate_wags (aprobación estratégica) hasta gate_deploy. Faltaba uno entre seguridad y despliegue: el plan de pruebas.
La regla es simple: ningún producto de la corporación llega a producción sin un plan de pruebas ejecutado y aprobado. Los criterios mínimos quedaron documentados en SECUENCIA_MAESTRA.md:
- 80% de cobertura en módulos críticos del backend
- Todos los endpoints de Fase 1 en verde
- 0 errores TypeScript en el frontend
- 0 fallos en el happy path E2E
- 0 hallazgos CRÍTICOS o ALTOS de seguridad
Esto aplica a Ledger, a LabelLoop, y a todo lo que venga después.
Estado al cierre
- Chronicles: artículo de Ledger Wealth publicado en olaveruiz.cl ✓
- Repo Ledger: 29 archivos listos, auditoría completa, push pendiente
- gate_testing: documentado y activo en el pipeline corporativo ✓
- Próximo paso: push de Ledger + crear 14 tickets PAIP en Linear
No fue el día más espectacular. Fue el día de arreglar lo que no funciona, documentar lo que duele, y reforzar los fundamentos antes de construir más rápido.
Eso también es Build in Public.