20260912 #5 — Llevar registro: trabajar en muchas sesiones

El día uno cerró de madrugada y el día dos empezó media hora después, con una sesión corta que no tocó el producto: definió cómo se iban a llamar las sesiones, dónde se iban a anotar y qué script las cerraría solo. El problema que resolvía no era de orden sino de continuidad. Cada conversación con Claude Code termina, y yo quería poder trabajar en muchas —abrir una, cerrarla, volver al día siguiente o desde otro proyecto— sin perder lo que se había decidido en la anterior. Con distancia, es una de las sesiones que más pesan de todas las que tengo: sin ella esta nota no existiría, porque el material del que salen todas las notas de esta bitácora es, justamente, el archivo de cada sesión.

Una sesión corta y una convención

Lo que quedó escrito esa noche cabe en cuatro líneas. Un formato de nombre, YYYYMMDD-VNN_nombre: la fecha, un correlativo que arranca en V01 cada día y un objetivo en dos o tres palabras. Un índice, docs/sessions.md, una tabla en Markdown. Un hook de cierre —un script que Claude Code ejecuta solo cada vez que el modelo termina de responder— que actualiza la hora de fin y el estado. Y una decisión sobre cómo averiguar el identificador real de la sesión, el UUID que hace falta para retomarla: tomar el archivo más reciente del directorio interno de sesiones de Claude Code.

Y una línea más, casi al pie: "retroactivamente registrada la sesión V01 del 08/15". El día uno, del que hablé en la nota anterior, existe como sesión porque el día dos lo anotó. El registro empezó registrando hacia atrás.

Lo que el mismo día ya no alcanzó

Esa misma tarde, la tercera sesión del día rehízo la mitad del diseño (la segunda se abrió y se cerró vacía, sin objetivo: el primer registro de una sesión que no fue). La tabla única no alcanzaba. Cada sesión pasó a tener su propio archivo, con un encabezado de metadatos y secciones fijas —objetivo, decisiones, trabajo realizado, próximos pasos— y el índice quedó como lista liviana. Apareció list_sessions.py, que lee esos encabezados y muestra las sesiones ordenadas por actividad, y la instrucción de que cada conversación empiece mostrando esa lista y preguntando: ¿retomamos una o abrimos otra? Ahí quedó dicho el objetivo real: que el trabajo pudiera repartirse en muchas sesiones sin que cada una arrancara de cero.

El detalle que más me gusta está en los metadatos. La cuarta sesión del día tiene el mismo identificador que la tercera: la heurística de "el archivo más reciente" falló el mismo día en que se la escribió, con dos sesiones abiertas casi juntas. Y las horas: la primera sesión del día tiene hora de inicio; las tres siguientes, solo la fecha; las del día después dicen literalmente "(hora no disponible)". El sistema nació sin saber leer el reloj.

Lo que quedó y lo que se movió

El formato de nombre es hoy idéntico, letra por letra, en el molde que replico en cada proyecto. Hay 426 archivos de sesión repartidos en diez proyectos; 165 de ellos los abrió el sistema solo, con el texto del primer mensaje como nombre, uno por cada ticket que un agente ejecutó desde la terminal sin que yo estuviera en la conversación —eso el día dos no lo previó. Las secciones fijas de la tercera sesión son las mismas que tiene el archivo de la sesión en la que estoy escribiendo esto.

Lo que se movió es la responsabilidad. El hook de cierre dejó de vivir en mi carpeta de usuario y pasó a viajar con cada proyecto, y ahora responde a dos eventos: uno refresca la hora de fin en cada turno, otro marca la sesión como cerrada una sola vez, cuando la conversación termina. El arranque —listar y preguntar— dejó de ser un párrafo en el archivo de instrucciones: un hook de inicio inyecta datos reales (tickets, sesiones abiertas hace más de 48 horas, alertas), una regla propagada desde el molde define el protocolo, y las instrucciones globales garantizan el mínimo si las otras dos capas faltan. Tres capas para lo que el día dos resolvió con un párrafo, porque el párrafo divergió en tres de ocho proyectos apenas se copió.

Y hay algo que el día dos no podía saber: que la fecha del nombre iba a terminar siendo la fecha de esta nota. Las notas de esta bitácora llevan como fecha la de su sesión fuente, no la del día en que se escriben. Esta lleva 16 de agosto. La convención de esa noche decidió, sin querer, el orden en que se lee todo lo demás.

Lo que no decidió es si esta es la forma correcta. Cuatrocientos archivos, tres capas de hooks y reglas, un correlativo que arranca de nuevo cada día: funciona, y es lo que me permitió escribir esto. Pero lo armé en una noche y lo vengo parchando desde entonces, sin compararlo nunca con otra cosa. Si trabajás con agentes en muchas sesiones, ¿cómo llevás el registro? ¿Es esta la mejor forma de manejar las sesiones, o solo la que me tocó?

Tags: sesiones · registro de trabajo · hooks · convenciones · memoria entre conversaciones