Retomar sin reconstruir
Cualquiera que haya dejado un proyecto dos semanas y vuelto a él conoce la sensación: ¿en qué estaba?, ¿qué quedó a medias?, ¿por qué hice esto así? Ahora multiplícalo por varias personas, varios proyectos en paralelo y, cada vez más, asistentes de IA que trabajan por sesiones y no recuerdan la anterior.
La continuidad no puede depender de la memoria. Tiene que estar escrita, y en un formato que se pueda leer en un minuto.
Dos documentos, dos funciones
El estado es una ficha corta y estructurada que se sobrescribe cada vez que algo cambia:
- En qué fase está la aplicación y qué compuertas ha pasado.
- Qué hitos quedan y cuáles están cumplidos.
- Qué bloquea el avance y quién tiene que resolverlo.
- Cuál es el siguiente paso.
La bitácora es un registro cronológico que solo crece: cada sesión de trabajo añade una entrada con lo que se hizo, lo que se decidió y lo que queda. Nunca se corrige una entrada anterior; si algo estaba mal, una entrada nueva lo dice.
Por qué dos y no uno
Porque responden a preguntas distintas. El estado responde "¿dónde estamos?" en segundos. La bitácora responde "¿cómo llegamos aquí?" cuando hace falta entender una decisión o rastrear un error. Mezclarlos produce un documento demasiado largo para leerlo rápido y demasiado editado para fiarse de su historia.
Reglas prácticas
- Se actualizan en la misma sesión, no "luego".
- Viven en el repositorio de la aplicación, junto al código.
- Lo crudo va aparte: las salidas largas de comandos o los volcados no ensucian la bitácora; se guardan en su propio fichero y se citan.
- Son legibles por máquinas: el estado tiene estructura fija, para que la plataforma pueda mostrar en un panel en qué punto está cada aplicación.
Con la memoria del proyecto resuelta, toca construir. Y construir bien empieza por una idea muy concreta: lo que se despliega tiene que ser exactamente lo que se probó.
Cómo lo aplicamos: Ingeniería de Plataforma.