Durante los últimos días PuzzleHub ha acumulado una cantidad de cambios que sería difícil recordar de memoria: motores nuevos, rediseños, internacionalización, onboarding, CI, artículos, categorías y mejoras de producto. El problema no es que Git no conserve esa información. La conserva demasiado bien y en una forma pensada para ingeniería, no para lectores.
Un historial de commits responde «qué archivos cambiaron y con qué intención inmediata». Un buen devlog debería responder «qué cambió en el producto, por qué importa y qué aprendimos». Entre ambas cosas hay trabajo editorial.
Por qué no publicar los commits directamente
Los buenos mensajes de commit ayudan muchísimo, pero siguen teniendo otra función. «fix(i18n): validate journal dates independently of locale formatting» es útil dentro del repositorio. Para alguien que sigue el proyecto, lo interesante es que el pipeline multidioma encontró una dependencia accidental entre validar una fecha y presentarla según el idioma, y que ahora ambas responsabilidades están separadas.
Una entrada pública necesita contexto suficiente para que la decisión sea comprensible sin conocer el árbol de archivos. Copiar el mensaje del commit solo trasladaría el ruido de una interfaz a otra.
Git es una fuente excelente de hechos y una fuente mediocre de narrativa.
La primera automatización solo prepara un borrador
El flujo nuevo puede leer actividad reciente y convertirla en material de trabajo para una entrada de devlog. La palabra importante es «borrador». Queremos reducir el trabajo de recordar y recopilar, no delegar el criterio sobre lo que merece contarse.
El sistema ayuda a detectar grupos: varios commits sobre un mismo motor pueden formar una sola entrada; una secuencia de correcciones de i18n puede explicar una mejora de plataforma; una PR grande puede merecer un artículo completo.
Devlog y Journal no tienen la misma frecuencia
Una de las decisiones más útiles ha sido separar superficies. La bitácora acepta cambios breves y concretos: un motor que pasa a generación verificada, una nueva cobertura de onboarding, una mejora de CI. El Journal necesita una tesis más amplia.
Eso evita dos extremos: guardar durante semanas todo lo ocurrido hasta que ya no recordamos el contexto o publicar un artículo largo por cada pequeña implementación.
Building in public también necesita una fuente de datos
La página pública de building, el devlog y el Now/Roadmap ya se generan desde una fuente estructurada común. Hitos, prioridades actuales, siguiente horizonte y entradas breves viven como datos y el build los convierte en páginas coherentes.
Esto hace que actualizar el estado del proyecto sea una operación editorial pequeña y revisable. También permite que el Journal enlace hacia esa capa más dinámica sin convertir cada artículo histórico en un documento que necesita reescribirse constantemente.
Los commits ayudan a no inventar retrospectivas
Construir en público pierde valor si el relato se escribe semanas después y termina suavizando el proceso. Git proporciona una cronología bastante incómoda y por eso útil: cuándo intentamos algo, cuándo lo corregimos, qué vino antes y qué vino después.
Podemos contar que el onboarding pasó de fallback compartido a recetas específicas y después a un gate de CI porque la secuencia existe. Podemos ver que un juego necesitó una corrección de taxonomía después de implementar el motor. Ese tipo de detalle hace el proceso más creíble y también más útil para nosotros mismos.
No todo commit merece una entrada
Hay commits de cableado, ajustes de estilos o correcciones internas que solo importan como parte de un tema mayor. La automatización debe ser capaz de traerlos a la mesa sin obligarnos a publicar cada uno.
La unidad editorial suele ser una decisión o una mejora percibible, no un SHA. Varios commits pueden formar una historia; un solo commit grande puede contener varias. Por eso el paso de agrupación es esencial.
También estamos documentando la forma de documentar
Puede parecer meta construir herramientas para contar cómo construimos herramientas, pero tiene un efecto práctico: el conocimiento del proyecto deja menos huecos. Los artículos largos capturan decisiones arquitectónicas; el devlog conserva evolución reciente; Git mantiene la prueba detallada.
Juntos forman una memoria más útil para personas y para los agentes de IA con los que desarrollamos. Un agente puede leer el estado actual del código, pero entender por qué una decisión se tomó requiere contexto histórico de calidad.
La meta es que publicar no compita con construir
Building in public funciona mientras no se convierta en una segunda jornada de trabajo. Si cada avance exige reconstruir manualmente una cronología, el hábito desaparecerá justo en las semanas más interesantes.
El flujo Git→devlog intenta resolver esa fricción sin caer en el extremo contrario de publicar texto automático sin criterio. Queremos que la máquina recuerde y agrupe. La historia, la selección y el tono siguen siendo parte del producto.