# Cerrar la sesión

> Cómo cerrar un tramo de trabajo con protocolo-cierre y version-bump, para que la sesión siguiente arranque con el contexto al día.

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](https://ai-first.falcux.com/docs/guias/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:

   ```text
   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`:

   ```text
   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:

   ```bash
   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](https://ai-first.falcux.com/docs/referencia/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](https://ai-first.falcux.com/docs/parte-3/protocolo-cierre/).

## Próximos pasos

[Auditar en local y en CI](https://ai-first.falcux.com/docs/guias/auditar-en-local-y-en-ci/)Lo que corre en el push, después del commit de cierre.

[Las 11 skills](https://ai-first.falcux.com/docs/referencia/skills/)protocolo-cierre y version-bump, con las demás.

[Protocolo de cierre de sesión](https://ai-first.falcux.com/docs/parte-3/protocolo-cierre/)El capítulo del manual.
