9. Protocolos de sesión — inicio, medio y fin para que cada día arranque en el mismo lugar

Este es el artículo final — parte 9 — de la serie Alice Way. Las partes 1 a 8 respondieron cómo diseñar, distribuir y proteger la mente. Este artículo registra cómo todo eso arranca, funciona y se apaga realmente cada día.

0. Los protocolos de sesión hacen que cada día arranque en el mismo lugar y se apague en el mismo lugar

Si no empiezas cada día de la misma manera, cada inicio gasta tiempo reconstruyendo el contexto. Dónde lo dejaste ayer, qué era lo siguiente, qué decisiones estaban en espera: todo desde cero.

Si no terminas cada día de la misma manera, cada cierre es incierto sobre qué se guardó y qué no. La siguiente sesión arranca sobre esa incertidumbre.

Los protocolos de sesión fijan ambos extremos. Lo que ocurre al inicio y lo que ocurre al final se solidifican en procedimientos. Entonces cada día arranca en el mismo lugar y se apaga en el mismo lugar. La mente del operador empieza desde la misma línea cada mañana.

Este artículo registra la composición del protocolo: tres de inicio, dos de medio, cuatro de cierre; y es también el cierre de la serie.

1. Protocolos de inicio — arrancar en el mismo lugar cada día

Lo que ocurre automáticamente en el momento en que empieza una sesión.

1.1 Hook SessionStart — imprimir estado de sincronización de memoria

En el instante en que se enciende la sesión, se imprime un estado de sincronización de memoria en una línea. "Memory sync: current" o "5 min old — refresh needed." El operador lee la línea y juzga al instante.

Por qué esto tiene que dispararse automáticamente como hook se cubrió en la parte 5 — Hooks y automatización §1: la mente del operador está más distraída exactamente en el momento en que se abre una sesión.

1.2 Carga automática de persona + índice de memoria

El resultado de la parte 2 — Persona y la parte 3 — Memoria: la persona (L1) y las primeras 200 líneas del índice de memoria (L2) se cargan automáticamente. El colaborador se une ya sabiendo quién es, qué decisiones se tomaron ayer y dónde vive cada cuerpo de memoria.

1.3 /start <proyecto> — entrar en un proyecto

Si se entra en un proyecto específico — invocar el slash command. Los documentos necesarios como README · CLAUDE.md · HANDOFF.md · PLAN.md se cargan automáticamente; el estado actual de git y el handoff de la sesión anterior se reportan en una pantalla; luego se detiene y espera la siguiente instrucción.

En el momento en que ese único comando se dispara, la mente del operador pasa directamente al modo de decisión sin el "¿por dónde empiezo?"

2. Protocolos de medio — mientras el trabajo avanza

Procedimientos que se aplican de forma consistente durante la sesión.

2.1 Reporte intermedio cada 3–5 pasos

No dejar que el trabajo avance cinco pasos o más sin un reporte. Reportes cortos de progreso en cada paso. El trabajo que supera los cinco pasos se pausa automáticamente para un reporte. El operador puede mantenerse al día sin perder el hilo.

Sin esto, el colaborador trabaja 30 minutos de forma autónoma y llega "todo listo", pero el operador tiene demasiado que absorber de una vez. Los reportes de cinco pasos distribuyen esa absorción.

2.2 Auto-escalación en decisiones ambiguas

Cuando el colaborador llega a "no estoy seguro" / "no sé cuál es mejor" / "todas las opciones parecen razonables", se auto-invoca /council antes de preguntar al operador. Ejecuta el análisis paralelo de cuatro perspectivas, sintetiza el resultado y reporta la síntesis. El operador decide a partir de la síntesis.

Este patrón está adaptado de la crítica multiperspectiva del razonamiento LLM de Andrej Karpathy. Ya citado en la parte 4 — Skills §3.4.

3. Protocolos de cierre — apagarse en el mismo lugar cada día

Lo que ocurre automáticamente al cerrar una sesión. Omitir cualquiera de estos y la siguiente sesión no arranca limpia.

3.1 /verify se dispara automáticamente

Si hubo cambios de código — justo antes del reporte de "listo," el bucle de 7 pasos de la parte 7 — Verificación se dispara automáticamente. Debe pasar para que salga el reporte.

Por qué este es el primer paso de cierre: los cambios no verificados que se hacen push rompen el entorno de la siguiente sesión. Arrancar desde un entorno roto arruina toda la sesión siguiente.

3.2 Actualización del log de trabajo

Añadir un párrafo a un log de trabajo como docs/history.md que cubra el día de hoy: qué se decidió, qué se escribió, qué se aplazó. Un operador futuro (o un colaborador diferente) debe poder restaurar el contexto desde este log.

3.3 Actualización de HANDOFF.md — la carta de handoff para la siguiente sesión

El paso más importante. El HANDOFF que se carga automáticamente en la siguiente sesión lleva:

• Progreso clave de la sesión anterior (1 línea)
• Próximas acciones recomendadas (1–3)
• Ítems incompletos / pendientes
• Decisiones esperando entrada
• Un marcador Next: (una directiva inmediatamente accionable para la siguiente sesión)

Si esto está vacío, la siguiente sesión arranca sin contexto. HANDOFF no es solo documentación; es el puente que entrega la mente del operador a la siguiente sesión.

3.4 Actualización de memoria + commit + push

Si en esta sesión apareció nuevo feedback, decisiones o contexto: añadirlos a los archivos de memoria. Actualizar el índice MEMORY.md junto con ello. Agrupar todo en un commit y hacer push.

No está cerrado hasta que el push se complete. Los cambios solo-locales pueden desaparecer antes de la siguiente sesión.

4. Hook Stop — verificación de omisiones

El sistema verifica si se omitió alguno de los cuatro pasos de cierre.

[stop] Checking session-end completeness...
[stop] OK: /verify passed
[stop] OK: history.md updated (1 paragraph added)
[stop] WARN: HANDOFF.md "Next:" marker missing — please add
[stop] OK: 3 files committed and pushed

Un WARN significa que el operador lo completa y luego cierra de nuevo. Las omisiones no pueden pasar en silencio.

5. /session-end — una palabra para cerrar

Los cuatro pasos de cierre se ejecutan juntos desde un único slash command.

• /verify se dispara automáticamente (verificación)
• Actualización automática del log de trabajo (el operador confirma antes de añadir)
• Actualización automática de HANDOFF.md (el operador confirma antes del push)
• Actualización de memoria (si apareció nuevo feedback) + commit + push
• Verificación de omisiones del hook Stop

El operador escribe una palabra: cuatro pasos se ejecutan de forma consistente, sin omisiones, hasta el push. Cada día se apaga en el mismo lugar.

6. El efecto del ciclo — cómo se ve un día

Cuando estos protocolos de inicio, medio y cierre se acumulan, el día del operador fluye así.

Inicio de sesión (09:00)
  Hook SessionStart → "Memory sync: current" (una línea)
  /start <proyecto> → docs necesarios cargados automáticamente, estado git + HANDOFF en una pantalla
  [Pausa. Esperando dirección del operador.]
 
Dirección del operador (09:01)
  → comienza el trabajo
  → reporte cada 3–5 pasos
  → en decisiones ambiguas, /council se auto-invoca
  → /verify en trabajo que necesita verificación
 
Cierre de sesión (18:00)
  /session-end →
    /verify se dispara automáticamente (pasa)
    history.md actualizado
    marcador "Next:" de HANDOFF.md actualizado
    memoria actualizada (nuevo feedback hoy)
    commit + push
    verificación del hook Stop → OK
  Sesión cerrada
 
Día siguiente (09:00)
  → retomar exactamente donde se dejó ayer

Cada día arranca exactamente en el mismo lugar y se apaga exactamente en el mismo lugar. La mente del operador entra en modo de decisión sin el coste de restauración del "¿dónde estaba?"

7. Trampas — patrones que colapsan los protocolos de sesión

7.1 Saltarse el protocolo de inicio

"Solo un vistazo rápido" — entrar sin /start. Las decisiones tomadas desde un contexto impuro colisionan con las de ayer. → Cada entrada pasa por /start.

7.2 Saltarse el protocolo de cierre

"No hay grandes cambios hoy, simplemente cierro" — terminar sin /session-end. HANDOFF queda obsoleto: la siguiente sesión no conoce el estado de ayer. → Siempre /session-end, independientemente del tamaño del cambio.

7.3 Reportes intermedios faltantes

El trabajo va demasiado bien: 10 pasos autónomos. Al final el operador tiene demasiado que absorber y el resumen posterior se convierte en su propia carga. → Mantener el límite de cinco pasos.

7.4 HANDOFF como copia del log de hoy

Escribir HANDOFF como simple copia retrospectiva de history.md. La siguiente sesión lo lee y pregunta "¿y qué?" → HANDOFF es información sobre la que la siguiente sesión puede actuar de inmediato. El marcador Next: es el núcleo.

8. Un principio — y el cierre de la serie

El núcleo del diseño de protocolos de sesión se resume en una oración.

"Cada día arranca en el mismo lugar y se apaga en el mismo lugar. El sistema mantiene los procedimientos al inicio, en el medio y al final; la mente del operador solo decide en el intermedio."

Y ese es también el cierre del arco de identidad — lo que Alice es.

La Parte 1 — Por qué Alice preguntó "¿cómo acumulo mi mente para que la IA no la pierda?" La persona traza el límite de la mente (parte 2), la memoria lo mantiene (parte 3), los skills solidifican los movimientos recurrentes (parte 4), los hooks externalizan las partes olvidadizas al sistema (parte 5), el Multi-Agent evita que un contexto lo lleve todo (parte 6), la verificación fija lo que significa "listo" (parte 7), la economía de tokens protege los espacios de señal (parte 8), y finalmente: los protocolos de sesión hacen que todo ello arranque y se apague en el mismo lugar cada día.

Estos nueve artículos son las respuestas que encontré mientras desarrollaba a un colaborador al que llamo Alice. La herramienta puede ser Claude, puede ser Codex, puede ser cualquier agente que llegue después. Pero las nueve decisiones anteriores no dependen de la herramienta. Las mismas decisiones aguardan a cualquiera que construya su propio colaborador.

La serie no termina en nueve. Tres artículos más la extienden hacia el arco de flujo de trabajo — cómo el operador y Alice realmente hacen el trabajo a través de este sistema: Parte 10 — PRD (qué construir), Parte 11 — Release gates (qué significa "listo") y Parte 12 — Ralph loop (cómo el sistema recorre el camino por sí solo). Los nueve artículos anteriores son el recipiente. Los tres siguientes son sobre lo que el recipiente lleva.

Si esta serie acortó aunque sea un poco el tiempo que se tarda en llegar a esas decisiones, la intención del operador aterrizó donde se pretendía.