Registro de sesión
Escribe un registro duradero de una sesión de trabajo. Estos registros se tratan como verdad fundamental por quien los lea después — incluido tú, dentro de seis semanas, sin nada de este contexto. La precisión importa más que la pulcritud.
Cuándo ejecutar esto
- Acaba de terminar una fase de construcción, corrección, auditoría o investigación
- Una sesión está terminando y hay estado que la siguiente necesitaría
- Se diagnosticó la causa raíz de algo y vale la pena conservar el mecanismo
No lo ejecutes para trabajo trivial. Una corrección de una línea no necesita un registro.
Dónde va
Donde sea que el proyecto guarde sus registros de sesión — un directorio docs/sessions/, un vault de notas, una wiki. Pregunta una vez si no es obvio, luego mantén la consistencia.
Un nombre de archivo que incluya la fecha y una descripción breve se ordena y escanea bien: YYYY-MM-DD Descripción Breve.md.
Pasos
1. Reúne los hechos antes de escribir
No escribas solo de memoria de la conversación. Recopila:
- Números de PR, SHAs de commits, marcas de tiempo de migraciones, IDs de despliegue
- Qué se verificó realmente, y con qué comando
- Qué falló, y qué sigue abierto
- Cualquier cosa que solo un humano pueda hacer
Si un hecho no se puede confirmar, márcalo como no confirmado en lugar de omitirlo o afirmarlo.
2. Escribe el cuerpo
# YYYY-MM-DD — <lo que se diagnosticó o publicó>
<Una línea que nombre cómo se ejecutó el trabajo: quién planificó, quién construyó, quién revisó.>
## Qué sucedió
- Mecanismo primero. Por qué sucedió esto, no solo qué.
- Evidencia concreta: números de PR, SHAs, marcas de tiempo, recuentos de filas, líneas de log.
- Distingue lo probado de lo inferido, explícitamente.
## Corrección
1. Pasos numerados. Cada uno indica qué se verificó y cómo.
## Reglas de NO hacer vigentes
<Solo si la sesión produjo prohibiciones. Fundamenta cada una en el incidente que la causó.>
## Elementos restantes — necesita un humano
- [ ] Cosas que solo ellos pueden hacer
Enlaces: <documentos relacionados>
Si el sistema de notas usa frontmatter, incluye un campo outcome: una oración completa que indique qué es verdad ahora que no lo era antes. Es la línea más leída del archivo. Haz que sea una afirmación real, no una etiqueta.
3. Las dos secciones que todos omiten
## Elementos restantes y el pie de enlaces son obligatorios. Son las dos secciones que aportan valor hacia adelante y las dos más omitidas — en un vault, medido en 230 registros existentes, aparecieron solo en ~21% y ~28% de ellos.
Escríbelas ambas, cada vez. Si realmente no hay nada retenido para un humano, escribe Ninguno — no se retiene nada. en lugar de eliminar el encabezado.
4. Marca cada afirmación
Etiqueta cada una como VERIFICADO (cómo) o ASUMIDO (por qué no se comprobó) en línea. No las difumines.
"Verificado" debe significar que un humano o un comando realmente lo confirmó. Una afirmación sobre producción requiere una consulta contra producción — no una prueba exitosa, no un PR fusionado, no un despliegue verde.
5. Resuelve cada enlace antes de guardar
Verifica cada destino del enlace contra un archivo real antes de escribirlo. Un sistema de notas acumula referencias rotas rápido, y un registro lleno de enlaces muertos es un registro en el que nadie confía.
6. Actualiza el estado del proyecto
Si el trabajo cambió el estado de un proyecto, agrega una sección de estado fechada al documento principal de ese proyecto — el más nuevo primero, antepón, nunca sobrescribas el historial.
Si el trabajo avanzó un programa con un documento de traspaso, actualízalo en su lugar para que la próxima sesión lo recoja correctamente.
7. Realimenta las lecciones
Si el usuario corrigió algo durante la sesión, escribe la lección en algún lugar duradero — un archivo de reglas, un almacén de memoria, esta misma habilidad. Así es como las correcciones dejan de repetirse.
Estilo de la casa
- Específico y falseable. Los resúmenes vagos son peores que nada aquí.
- Nunca afirmes un estado sin decir cómo se comprobó.
- Empieza con las malas noticias. No las entierres.
- Escribe para un lector que no tiene nada de tu contexto.
No hacer
- No sobrescribas un registro existente. Lee primero, luego edita.
- No escribas en directorios generados por máquina.
- No crees archivos temporales ni salidas de compilación junto a las notas.