Cerrar la sesión

Terminaste un tramo de trabajo con cambios en el código y quieres que la próxima sesión, tuya o de otro, lo retome sin reconstruir qué pasó. protocolo-cierre documenta la sesión; version-bump decide el número de versión que viaja en el mismo commit.

Cuándo usarla

• Al terminar una sesión de implementación de features.
• Al terminar una corrección de bugs que modificó comportamiento.
• Al terminar una sesión de gestión de cambios.
• Al terminar un refactor que afectó la arquitectura.

No hace falta en sesiones exploratorias sin cambios de código, en fixes de typos ni en sesiones de sólo lectura. Si todavía no verificaste los tests, eso va antes: test-fix, en Desarrollar una feature.

Antes de empezar

Las dos skills vienen en la instalación por defecto, y init deja el registro que el cierre escribe, docs/SESSION_LOG.md, vacío y con su cabecera. Para que version-bump clasifique bien, el proyecto necesita commits convencionales —feat:, fix:, docs:—; sin ellos, la clasificación cae en leer el diff, que es más lento y menos confiable.

El cierre tiene tres fases, y sólo la primera es del agente:

Fase	Quién
A — Documentar	El agente, con protocolo-cierre
B — Verificar	El humano, no delegable
C — Commit	El humano, no delegable

Paso a paso

1. Pide la Fase A. Antes del commit:

   Usa protocolo-cierre para cerrar esta sesión. No hagas commit.

   El agente reúne el contexto objetivo con git diff --name-only HEAD, git status --short y git log --oneline -10, y lee las últimas dos entradas del registro de sesión y el registro de cambios. Lo que no aparece en el diff no pasó.

2. Deja que revise las migraciones. Si el schema cambió y no hay migración nueva, lo avisa en el reporte como bloqueante suave. No la ejecuta por su cuenta.

3. Revisa la entrada del registro. Va al tope de docs/SESSION_LOG.md, con el número de sesión siguiente: resumen, cambios por área, validación y pendientes. Si un check no se corrió, dice «no ejecutado», nunca un PASS inventado.

4. Revisa los docs que tocó. Sólo los que la sesión afectó: AGENTS.md si cambió una regla activa, docs/ADR.md si hubo una decisión, el inventario de componentes si se tocó uno compartido, el registro de cambios si un cambio se completó. Los aprendizajes van a un destino según su tipo, no a todos.

5. Decide la versión. El cierre clasifica la sesión y, si amerita bump, pasa a version-bump:

   Usa version-bump. Analiza los commits desde el último tag y recomiéndame
   el bump. No apliques nada hasta que confirme.

   La regla del máximo manda: un solo commit MAJOR en el rango gana sobre cualquier cantidad de PATCH. Sin tu confirmación explícita, no aplica nada. Con ella, actualiza todos los manifiestos a la misma versión y fecha la entrada del CHANGELOG en ese mismo commit.

6. Haz la Fase B. El reporte termina con tu lista: si el resumen refleja lo que hiciste, si los docs son precisos, si los aprendizajes son reales, si pasa la suite completa, si quedó algo sin documentar y, si hubo bump, si las versiones quedaron sincronizadas.

7. Haz la Fase C. Un commit con el código y los docs juntos. Después, el tag lo creas tú, con el número que confirmaste:

   git tag v0.Y.Z && git push origin v0.Y.Z

Precaución

El tag va después del commit de cierre, nunca antes. Un tag creado antes apunta a un commit que no tiene los manifiestos actualizados. Por eso version-bump no lo crea.

Qué queda escrito

Archivo	Quién lo escribe
docs/SESSION_LOG.md	protocolo-cierre, una entrada nueva al tope
AGENTS.md, docs/ADR.md, guía de diseño, inventario de componentes, arquitectura	protocolo-cierre, sólo los que la sesión afectó
docs/TECH_NOTES.md	protocolo-cierre, si el aprendizaje es una cicatriz de stack
docs/changes/CHANGE_LOG.md	protocolo-cierre, si un cambio se completó; el CHG sale de pending/
Los manifiestos, como package.json	version-bump, tras tu confirmación
La entrada del CHANGELOG	version-bump, con la fecha del bump

Ninguna de las dos toca código ni hace commits.

Qué vigila el detector

• Decisión sin fila en ADR (P1). Si la sesión sumó o quitó una dependencia de producción, o tocó una superficie de decisión, el ADR tiene que ganar una fila en el mismo rango. El detector la reconoce por su encabezado, ## ADR-NNN o ### ADR-NNN. Si el cambio no era una decisión, se silencia con <!-- ai-first: sin-decision --> en el cuerpo del commit; esa anotación sólo se lee en modo rango, con --base.
• Artefacto huérfano (P2). Si el cierre nombra en AGENTS.md o en el ADR un archivo que ya no existe, se reporta. El registro de sesión no se declara como artefacto: es cronología, y nombra con razón cosas que ya se retiraron.
• Alcance excedido (P1). Si el CHG del cambio que cerraste sigue en pending/, el detector lo sigue leyendo como abierto.

El detalle de cada una está en Las cinco verificaciones.

Por qué funciona así

La AI puede describir lo que hizo, pero no puede juzgar si está bien, y un commit es una firma que tiene dueño: por eso sólo la Fase A se delega. El criterio completo está en el Protocolo de cierre de sesión.

Próximos pasos

Auditar en local y en CILo que corre en el push, después del commit de cierre.

Las 11 skillsprotocolo-cierre y version-bump, con las demás.

Protocolo de cierre de sesiónEl capítulo del manual.