Skip to content

English · Español

Break 00 — Saltarse el postmortem; el mismo incident vuelve tres meses después

🇪🇸 Este /break no es un bug de código — es un bug de proceso. Después del incidente INC-2026-08-14 (gloss español ausente), nadie escribió post-mortem; tres meses después, una regresión equivalente vuelve a romper el tutor en clase. Coste: dos incidentes que podrían haber sido cero.

Qué vas a hacer

Recorre una línea temporal simulada de tres meses donde el incident INC-2026-08-14 del tutor de gramática §A13 (descrito en theory/05-postmortem-template-and-fictional-incident.md) se arregla operativamente (el rollback tiene éxito) pero no se le da seguimiento con un postmortem. Tres meses después, un incident estructuralmente idéntico recurre. Documenta el meta-coste.

Este /break es diagnóstico y pedagógico: no hay código que editar. El "bug" es la ausencia de un artefacto de proceso. El "fix" es escribir el postmortem.

Paso 1 — El primer incident (14 ago)

INC-2026-08-14-tutor-spanish-gloss-missing ocurre como se describe en theory 05:

  • Causa: max_decode_tokens recortado de 32 a 16 en v2.4.0; los glosses largos en español se truncan a cadenas vacías.
  • Detección: ticket de usuario a los +16 min.
  • Mitigación: rollback a v2.3.4 a los +41 min.
  • Disrupción de clase: ~6 minutos tras el rollback (reintento de ítems).

Operacionalmente bien: el rollback funcionó, sin pérdida de datos, los estudiantes continuaron. La cohort es pequeña e indulgente. Borja sigue con feature work para v2.5.0. No se escribe ningún postmortem.

La entrada de journal del 2026-08-14 menciona: "incident del tutor — arreglado vía rollback, ~30 min." Eso es todo.

Paso 2 — Pasan tres meses; el sistema deriva

Entre el 14 de agosto y noviembre, ocurre lo siguiente:

  • 2026-08-22: se publica v2.4.1. max_decode_tokens restaurado a 32 (como parte de un PR distinto que tocaba la config). No se establece conexión con el incident anterior.
  • 2026-09-10: v2.5.0 entrega respuestas en streaming. El bucle de decode se refactoriza; el parámetro max_decode_tokens ahora se canaliza por un nuevo objeto StreamingDecoderConfig.
  • 2026-10-04: v2.6.0 añade un nuevo modo "verbose explanation" que el portal activa para ítems difíciles. Se prompea al modelo para dar explicaciones de varias frases.
  • 2026-11-12: v2.7.0 — pasada de rendimiento. Borja, perfilando latencia de cola, ve que el modo verbose explanation empuja p95 a 800 ms. Reduce StreamingDecoderConfig.max_tokens de 64 a 32 para bajar el p95. CI verde, eval gate en 0.93, bake limpio. Sale a producción.

Paso 3 — La recurrencia (13 nov)

2026-11-13 14:01  v2.7.0 deployed. Bake clean.
2026-11-13 14:05  Class of 25 students starts a quiz session.
2026-11-13 14:09  Portal log spikes "explanation field truncated".
2026-11-13 14:14  Borja sees student tickets. Spends 8 minutes diagnosing.
                  "Wait — this looks like the August thing."
2026-11-13 14:22  Realization: max_tokens=32 truncates the new verbose
                  explanation mode (longest cases are 50+ tokens). Same
                  failure pattern as Aug, different field, same root cause.
2026-11-13 14:28  Rollback to v2.6.1. Class continues.

Misma clase de incident. Campo distinto esta vez (explanation no spanish), misma clase de causa raíz (presupuesto de decode vs. desajuste de distribución), mismo modo de detección (tickets de usuario), misma mitigación (rollback).

Paso 4 — Lo que el postmortem habría atrapado

Si se hubiera escrito un postmortem el 14 de agosto con las acciones de theory 05:

  1. max_decode_tokens anclado al manifest con guard de CI → habría marcado la disminución de v2.7.0. ✗ no hecho.
  2. Prompts de cola larga en el regression test → los prompts de verbose explanation habrían estado ahí. ✗ no hecho.
  3. Contador de campo vacío + alerta → habría disparado a las 14:06 en lugar de las 14:14 (8 min antes). ✗ no hecho.
  4. Comprobación de campo vacío como eval gate bloqueante → habría hecho fallar v2.7.0 en CI. ✗ no hecho.
  5. El bake incluye prompts de portal muestreados → el bake lo habría atrapado antes del impacto en usuarios. ✗ no hecho.

Cada una de estas es unas pocas horas de trabajo, el día 14 de agosto, cuando el incident estaba fresco. Hechas como lote el 14 de agosto, la recurrencia de noviembre no ocurre.

Paso 5 — El meta-coste

Coste 14 ago 13 nov Total
Disrupción de clase (minutos) ~6 ~6 ~12
Tiempo de ingeniería para diagnosticar ~25 min ~13 min ~38 min
Tiempo de ingeniería para rollback + smoke ~10 min ~6 min ~16 min
Pérdida de confianza del estudiante (cualitativo) baja media media
Acciones aún pendientes tras 13 nov 0 5 5

El coste operativo aproximadamente se duplica (dos incidents en lugar de uno). El coste latente es más difícil de cuantificar: hay 5 acciones aún pendientes tras el 13 de noviembre, la misma clase de causa raíz puede recurrir una tercera vez, y el equipo aprende a tratar las regresiones de presupuesto de decode como "solo rollback cuando ocurran" en lugar de arreglar el proceso.

El coste de no escribir un postmortem es el número esperado de recurrencias futuras × el coste de cada recurrencia. Para una clase de incident que recurrió una vez en tres meses, el coste por trimestre es al menos un incident repetido. Para contextos de baja confianza (clientes de pago, industrias reguladas), el multiplicador de coste es mucho mayor.

Paso 6 — El "fix": escribir el postmortem (retroactivamente)

La acción que este /break motiva: abrir learners/borja/postmortems/INC-2026-08-14-tutor-spanish-gloss-missing.md y rellenar las cuatro secciones de theory/05-postmortem-template-and-fictional-incident.md. El artefacto ficticio se proporciona como ejemplo trabajado; el ejercicio es comprometerse con la disciplina.

El fix de la regresión de código en v2.7.0 es mecánico (anclar al manifest + contador + bake-smoke + extensión del regression set). El fix de la brecha de proceso es el postmortem mismo.

Por qué este es el /break correcto para la Fase 40

La Fase 40 es "Hardening y postmortem". El modo de fallo más común de la práctica de postmortem es no hacerla. Hacerla mal es raro; saltarla porque "el fix operativo funcionó" es universal. Este ejercicio hace concreto el coste de saltarla.

Reglas duras respetadas

  • Sin código editado.
  • Los incidents ficticios están claramente etiquetados; nada en producción se ve afectado.
  • El ejercicio produce un artefacto real (el postmortem retroactivo) que vive en learners/borja/postmortems/.
  • Sin implicación de seguridad.
  • Sin test modificado.

Siguiente: cuando el postmortem retroactivo esté escrito, relee ../theory/05-postmortem-template-and-fictional-incident.md y el canónico 01-postmortem-structure.md.