cerrar-sesion

name	cerrar-sesion
description	Cierra una sesión de trabajo dejando registro en la bitácora del proyecto y distribuyendo lo aprendido a los archivos que corresponde (MEMORY.md, ADR, registro de bugs, registro de implementaciones). Úsala al terminar una jornada de trabajo, antes de un /clear, o cuando el usuario diga que va a parar, retomar mañana o cambiar de tarea.

Cerrar una sesión de trabajo

La conversación se pierde; la bitácora no. El objetivo es que la próxima sesión —de esta persona o de otro compañero del equipo— arranque en tres líneas en vez de reconstruir horas de contexto.

Procedimiento

Paso 1 — Decide si hay algo que registrar

Se registra si la sesión cambió el repositorio, descubrió algo, o dejó trabajo a medias.

No se registra una sesión que solo consultó documentación o respondió preguntas sin producir cambios. Una bitácora llena de entradas vacías es peor que no tener bitácora.

Paso 2 — Reparte lo aprendido antes de escribir la entrada

Esto es lo que evita que la bitácora se convierta en el basurero donde va todo. Cada cosa a su sitio:

Lo que pasó en la sesión	Dónde va	Cómo
Se eligió entre alternativas técnicas	docs/design-decisions.md	skill registrar-decision
Se descubrió un hecho verificado que costó descubrir	MEMORY.md	Edición directa, 3 líneas
Se encontró un defecto	docs/gestion/registro-de-bugs.md	skill registrar-bug
Se fusionó un PR a develop	docs/gestion/registro-de-implementaciones.md	skill registrar-implementacion
Se verificó una fuente de datos	docs/ingenieria/auditoria-fuentes-de-datos.md	skill verificar-fuente
Nada de lo anterior — solo avance de trabajo	Solo la bitácora	Paso 3

Si una información ya quedó en un ADR o en MEMORY.md, en la bitácora va solo la referencia (ADR-008, BUG-003), nunca el contenido repetido.

Paso 3 — Escribe la entrada

Va en docs/gestion/bitacora-sesiones.md, arriba de la entrada más reciente del sprint en curso.

### AAAA-MM-DD · D<N> · `rama`
**Qué:** <resultado en pasado, máximo 2 líneas>
**Sigue:** <siguiente paso concreto, una línea>

Paso 4 — Verifica los presupuestos

Si en esta sesión se agregó algo a CLAUDE.md, MEMORY.md o DESIGN.md, comprueba que sigan dentro de su presupuesto de líneas (docs/gestion/protocolo-de-contexto.md §1). Si se pasó, mueve el detalle a docs/ y deja un puntero.

Si la bitácora superó las 30 entradas, rota las más viejas a docs/gestion/historico/bitacora-sprint-<N>.md.

Reglas de escritura

• En pasado y con resultado, no con intención. Implementado POST /api/reportes con rate limiting en Redis, no trabajando en el endpoint de reportes.
• Referencias, no contenido. Corrige BUG-004, no la explicación del bug otra vez.
• Nunca código en la bitácora. Solo archivo:línea.
• "Sigue" es obligatorio y concreto. Falta conectar el SSE del mapa al store de TanStack Query sirve; continuar con el frontend no dice nada.
• Si la sesión dejó algo roto o a medias, dilo explícitamente en "Sigue". Una bitácora que solo cuenta éxitos obliga al siguiente a descubrir el desastre por su cuenta.

Al terminar

Confirma al usuario, en una línea, qué se registró y dónde. Si algo quedó sin registrar por decisión suya, dilo también.