English · Español

01 — Estructura del postmortem: las cinco secciones canónicas

Un postmortem no es un diario ni un resumen. Es un documento estructurado que convierte una historia en lecciones. Cinco secciones, cada una con un objetivo. Saltarse una pierde valor.

Las cinco secciones

Adaptado de la plantilla de postmortem de Google SRE y de los escritos de John Allspaw sobre "blameless postmortem":

1. Resumen — el titular. Un párrafo. Qué ocurrió, cuál fue el impacto, cuál fue la resolución.
2. Línea de tiempo — cuándo ocurrió cada evento. Horas en UTC, ancladas a señales objetivas (SHA de commit, línea de log, captura del panel).
3. Factores contribuyentes — por qué ocurrió. Múltiples — normalmente 3-5 — incluyendo proceso, herramientas, diseño y factores humanos.
4. Lecciones aprendidas — qué principios generales se pueden extraer. Son independientes del proyecto y sobreviven al postmortem.
5. Acciones — concretas, con dueño, con fecha. "Arreglar el umbral de alerta para el 2026-06-15 (dueño: Borja)".

Para el postmortem del viaje (lab 01 de la Fase 40), adaptamos esto:

1. Resumen — qué fue el proyecto, qué se entregó, qué no.
2. Línea de tiempo — hitos a lo largo de las 40 fases, con los baches mayores anotados.
3. Factores contribuyentes — qué hizo el viaje duro, qué hizo que funcionara.
4. Lecciones — principios generalizables para proyectos futuros.
5. Acciones — qué aplicar la próxima vez. Dueños: Borja-futuro.

Sección 1 — Resumen

Longitud: 100-200 palabras. Prueba de leerlo en voz alta: si lees solo esta sección a un extraño, debería saber qué pasó.

Para un postmortem de viaje:

• Qué. "Lynx Cortex: un currículo de sistemas de IA (AI) desde primeros principios de 40 fases, terminando en un servicio tutor de gramática para conjugación de verbos en inglés, con traducciones al español emparejadas".
• Entregado. "Las 40 fases completadas. Servicio tutor funcionando en CPU. Transformer Pre-LN entrenado sobre el corpus de 600 formas verbales. Planificador de continuous batching. Panel de observabilidad. Postmortem y lista de lectura".
• No entregado. "Entrenamiento en GPU (aplazado por CLAUDE.md §6). Beam search. Decodificación especulativa. Persistencia de memoria multi-aprendiz (se quedó en memoria)".
• Lección titular. Una frase. La conclusión más importante. Ejemplo: "Construir NumPy-first antes de tirar de PyTorch fue la decisión de mayor apalancamiento del currículo".

Sección 2 — Línea de tiempo

Para un postmortem de viaje, una línea de tiempo con resolución mensual es suficiente. Para cada hito mayor, da la fecha y la señal:

2026-01-15 — Arranque de Fase 00. uv + just + pre-commit funcionando.
2026-01-28 — Fase 05 completada. log-sum-exp asimilado vía comparación Bernoulli vs Gaussiana.
2026-02-10 — Diseño del corpus de Fase 12 completado. Corpus §A13 de 600 formas en `data/`.
2026-02-22 — Mini-GPT ensamblado en Fase 17. 103.680 parámetros; primer forward end-to-end en verde.
2026-03-04 — Bucle de entrenamiento de Fase 18. Bug de eje descubierto el día 2 (commit abc1234); arreglado el día 4.
2026-03-15 — KV cache en Fase 22. Prerrequisito de continuous batching aterrizado.
...
2026-05-22 — Capstone de Fase 39 integrado. Servicio tutor de gramática entregando correcciones de verbos.
2026-05-23 — Cierre de Fase 40.

Para cada línea, enlaza al commit relevante, entrada de diario o PHASE_NN_REPORT.md.

Sección 3 — Factores contribuyentes

Esta es la sección honesta. Qué lo hizo duro, qué te salvó. Mezcla factores estructurales con eventos puntuales:

Factores estructurales a considerar: - La elección NumPy-first. - El ritual estricto por fase (planear → aprobar → construir → enseñar → ejecutar → informar → reflexionar). - La política bilingüe (claridad forzada en dos idiomas). - Restricción de solo-CPU forzando diseño de corpus pequeño. - Subagentes (math-reviewer, numerical-stability-checker) capturando problemas que de otro modo se habrían propagado.

Eventos puntuales honestos: - "La Fase 13 se reescribió a mitad de camino cuando el giro a gramática verbal de A13 reemplazó el alcance de C-strings". - "El entrenamiento de la Fase 18 estuvo roto 2 días por un bug del eje". (Causa estructural: cobertura insuficiente de aserciones de forma en los tests de la Fase 17. No "Borja fue descuidado"). - "La cuantización de la Fase 26 requirió rehacer los labs de representación numérica de la Fase 02 para interiorizar bien fp16 vs bf16".

Para cada factor, nómbralo y explícalo en 1-3 frases. Evita la tentación de afirmar que todo fue sobre ruedas.

Sección 4 — Lecciones aprendidas

Estas son las líneas que sobreviven al proyecto. Van al MEMORY.md, a futuros CLAUDE.md, a la forma en que empiezas lo siguiente.

Formatea cada una como: regla + por qué + cómo aplicarla.

Ejemplo:

Construye el corpus antes que el modelo. El corpus de verbos §A13 se diseñó en la Fase 12 antes de fijar la arquitectura del Mini-GPT. Esto permitió que las fases posteriores (17-21) validaran contra una verdad inequívoca. Por qué: Sin un corpus diseñado, ajustas el modelo contra ruido. Cómo aplicarlo al próximo proyecto: Dedica el primer 10% del tiempo del proyecto al conjunto de evaluación, por pequeño que sea. La evaluación va primero.

De tres a siete es el número correcto. Menos significa que extrajiste poco. Más significa que rellenaste.

Sección 5 — Acciones

Concretas. Con dueño. Con fecha. Cada una encaja en el formato:

[Acción] para [fecha]. Dueño: [persona]. Criterio de éxito: [señal observable].

Para un postmortem de viaje, las acciones son para proyectos futuros:

Adoptar la regla "BLUEPRINT antes que código" de la Fase 00 en el próximo proyecto, antes de escribir cualquier módulo de producción. Dueño: Borja-futuro. Criterio de éxito: existe un BLUEPRINT.md en cada módulo src en menos de una semana desde que se empezó.

Releer el postmortem al mes 6 del siguiente proyecto. Dueño: Borja-futuro. Criterio de éxito: existe un evento en el calendario.

Tres a cinco acciones. Cada una realista — si escribes 20, harás cero.

Qué separa un buen postmortem de uno malo

Mal postmortem: "Aprendimos mucho, fue un gran viaje, aquí van algunas cosas que fueron bien y algunas que no. Lo haremos mejor la próxima vez".

Buen postmortem: Un lector que no hizo este proyecto puede extraer lecciones específicas y accionables. Nombres de incidentes (no culpa; especificidad). Tiempos. Commits. Causas estructurales. Acciones concretas que podrían aplicar a su propio trabajo.

La prueba: si un futuro colega de Borja lo lee dentro de un año, ¿aprende algo que no habría podido deducir solo del código?

Una nota sobre tono

Los postmortems no son vueltas de honor. Tampoco son autoflagelación. Son documentos técnicos con un arco narrativo. Apunta al tono de un artículo de conferencia bien escrito: asertivo sobre los hechos, cuidadoso con las afirmaciones, honesto sobre las limitaciones.

Lo que este archivo NO cubre

• Cómo medir qué decisiones arquitectónicas sobrevivieron. Siguiente archivo.
• El método de la lista de lectura. Lab 02.
• Los incidentes específicos a incluir. Eso es el contenido del lab; tú lo rellenas.

Siguiente: 02-decision-survival.md