Contexto y resultado
Cadence es una plataforma de retrospectivas en tiempo real. El trabajo se enfocó en identificar qué impedía considerarla preparada para producción y en convertir esos riesgos en un programa de mejoras verificables. El resultado disponible es un hardening que cubrió configuración, autenticación, secretos, CORS, límites, readiness, migraciones y observabilidad.
Problema y restricciones
La plataforma combinaba frontend Next.js, API Go/chi, MySQL y comunicación en tiempo real con Centrifugo. Los riesgos iniciales abarcaron secretos, autenticación, CORS, límites de abuso, readiness y migraciones. El alcance exigía mejorar la confiabilidad sin mezclar responsabilidades entre frontend, backend e infraestructura.
Responsabilidad personal
Analicé la arquitectura y prioricé riesgos P0/P1. Diseñé un hardening incremental y llevé la calidad al flujo de entrega: CI backend con módulos de solo lectura, build, vet, race tests y pruebas de seguridad; CI frontend con instalación reproducible, typecheck, lint, pruebas, build y una política auditable de vulnerabilidades conocidas. La atribución de decisiones apoyadas por IA sigue pendiente de aclaración con validación humana.
Decisiones y alternativas
La decisión documentada fue abordar el hardening de forma incremental y llevar la calidad al flujo de entrega, respetando las fronteras entre frontend, backend e infraestructura. En el diseño de producto se fijaron decisiones estructurales verificables: el tablero de tarjetas usa DOM con dnd-kit en lugar de canvas para preservar accesibilidad por teclado y lectores de pantalla, y la API nunca retiene WebSockets — publica eventos hacia Centrifugo tras cada escritura exitosa. No hay evidencia publicada de otras alternativas descartadas, por lo que no se atribuyen comparaciones adicionales.
Arquitectura y datos
Next.js compone el frontend y Go/chi expone la API; MySQL forma parte de la plataforma de datos y Centrifugo habilita la comunicación en tiempo real. El backend accede a la base de datos únicamente a través de código generado con sqlc a partir de SQL escrito a mano, con migraciones versionadas mediante golang-migrate; la autenticación es JWT autogestionada con access y refresh tokens. En el dominio se preserva una invariante de anonimato: el autor de una tarjeta anónima nunca se serializa en las respuestas. El diagrama sanitizado del antes/después y del pipeline permanece pendiente porque no existe uno preparado para publicación.
Calidad, seguridad, CI y observabilidad
El programa de hardening cubrió configuración, autenticación, secretos, CORS, límites, readiness, migraciones y observabilidad. El CI backend incluyó módulos de solo lectura, build, vet, race tests, verificación de módulos con go mod verify y escaneo de secretos con gitleaks sobre todo el historial de Git; el CI frontend incluyó instalación reproducible, typecheck, lint, pruebas, build y una política auditable de vulnerabilidades conocidas con línea base congelada de hallazgos de producción. La configuración entre frontend y API se resolvió mediante issue, pull request, checks automáticos y merge trazables. La evidencia disponible no detalla señales operacionales ni resultados de observabilidad, por lo que no se infiere una madurez adicional.
Resultado verificable
La evidencia disponible respalda la cobertura del hardening, la entrega trazable de la configuración entre frontend y API mediante issue, pull request, checks y merge, y las decisiones estructurales verificables en el código: tablero accesible por DOM, acceso a datos type-safe con sqlc, publicación de eventos hacia Centrifugo en lugar de WebSockets en la API, e invariante de anonimato. El estado final verificable de cada riesgo no está consolidado: no se marca ninguno como resuelto o aceptado y todos permanecen pendientes de verificación individual. Las métricas de riesgos cerrados y de duración o confiabilidad del pipeline siguen pendientes por falta de una fuente consolidada y una serie histórica defendible.
Aprendizajes y mejoras
El hardening incremental permitió priorizar riesgos P0/P1 y llevar la calidad al flujo de entrega sin mezclar responsabilidades entre frontend, backend e infraestructura. Tratar la accesibilidad como restricción arquitectónica —DOM antes que canvas— demostró que la inclusividad puede ser una decisión de estructura y no un parche posterior. Las capturas actuales del tablero, el resumen de cierre y las métricas permiten revisar el flujo del producto. Quedan pendientes la consolidación individual de riesgos, un diagrama sanitizado, métricas verificables y la aclaración de decisiones personales frente al apoyo de IA con validación humana.
Enlaces
- Ver Cadence (abre en una nueva pestaña)
- Las capturas funcionales incorporadas arriba documentan el producto sin añadir métricas no verificadas.
