English · Español

00 — Cerrar bien un proyecto

Cerrar un proyecto es una habilidad distinta de empezarlo. La tentación es seguir construyendo; el trabajo es parar, documentar, y dejar el sistema en un estado que un futuro tú o un futuro extraño pueda recoger.

Qué significa "cerrar"

Tras 40 fases, la tentación es añadir una cosa más. Una característica más. Una optimización más. Un pulido más al agente tutor.

No lo hagas. Cerrar es una habilidad separada de construir. Los entregables de cerrar son:

1. Un sistema en un estado conocido. Amenazas o cerradas o aceptadas explícitamente. Tests pasan. Documentación coincide con el código. CI en verde.
2. Un registro escrito de cómo llegaste aquí. El postmortem. No para nadie más (aunque otros puedan leerlo) — para el siguiente-tú, que dentro de seis meses mirará este código base y no recordará por qué X es como es.
3. Un plan para qué sigue. Porque el proyecto acaba; el aprendizaje no.

Si te saltas el trabajo de cierre y "simplemente empiezas lo siguiente", perderás las lecciones. El viaje de 40 fases son los datos. El postmortem es lo que convierte esos datos en conocimiento.

Los tres entregables, en orden de prioridad

Prioridad 1 — Endurecimiento (hardening)

Recorre security/THREATS.md línea por línea. Para cada hilo abierto:

• Ciérralo. Implementa la mitigación. Añade un test. Actualiza la amenaza a "mitigada por X (verificada en el test Y)".
• Acéptalo. Decide que el coste de arreglarlo es mayor que el riesgo. Escribe la justificación en el documento de amenazas. ("Aceptado: corremos en una CPU monoinquilino; el riesgo de cadena de suministro está acotado por pip-audit y la revisión semanal. Reevaluar si añadimos un endpoint hospedado").
• Apártalo. Decide que está fuera del alcance de este proyecto pero merece la pena anotarlo para el siguiente. Muévelo a READING_LIST.md como dirección futura.

El objetivo es dejar cero riesgos no enunciados. Un documento de amenazas con elementos "TODO" obsoletos es peor que no tener documento — miente sobre el estado del sistema.

Prioridad 2 — Postmortem

Escribe el viaje como si fuera un incidente prolongado. No porque el proyecto saliera mal — no salió mal — sino porque el formato postmortem fuerza honestidad sobre qué fue duro, qué fue suerte, y qué casi se rompió.

Un buen postmortem tiene cinco secciones (más en el archivo 01): resumen, línea de tiempo, factores contribuyentes, lecciones, acciones. Las acciones aquí son para proyectos futuros, no para este.

Prioridad 3 — Lista de lectura

La lista de lectura no es un vertedero de marcadores. Es una recomendación curricular para "qué hacer a continuación". Cada entrada tiene un "por qué" de una frase y un "qué hacer con ello" de una frase. Veinte entradas buenas baten a doscientas mediocres.

Por qué este orden

Endurecimiento primero porque la deshonestidad en el modelo de amenazas se arrastra hacia adelante — acéptala ahora o trabajarás alrededor de ella en el siguiente proyecto sin saber por qué.

Postmortem segundo porque la lista de lectura depende de saber qué te falta — lo cual requiere haber articulado qué tienes.

Lista de lectura al final porque es la parte que apunta lejos del proyecto. Hacerla primero filtra atención fuera del trabajo de cierre.

El encuadre sin culpas (blameless)

El postmortem menciona que la pérdida de entrenamiento de la Fase 18 estuvo rota dos días por un bug del eje en np.argmax. Versión con culpa: "Borja cometió un error descuidado". Versión sin culpa: "La señal de entrenamiento del Mini-GPT se degradó silenciosamente durante ~48 horas; la causa raíz (root cause) fue un off-by-one en un eje que los tests existentes no capturaron; el factor contribuyente fue que el conjunto de tests de la Fase 18 cubría corrección en una secuencia de 4 tokens pero no el caso multi-batch".

El encuadre sin culpas no va de ser amable con Borja-pasado. Va de producir lecciones accionables. "Ten más cuidado" no es una lección; "añade una aserción de forma multi-batch al paso de entrenamiento" sí lo es.

Para el postmortem de la Fase 40: cada incidente recibe una causa estructural, no personal.

Cuándo podrías romper este consejo

• Si descubres un problema crítico de seguridad durante el pase de endurecimiento, arréglalo. No lo aceptes.
• Si un entregable es objetivamente incorrecto (el postmortem es ilegible, la lista de lectura son enlaces rotos en su mayoría), rehazlo. Cerrar bien incluye rehacer tu trabajo de cierre.
• Si los stakeholders del proyecto cambiaron — Borja decidió a mitad de viaje apuntar el capstone solo a aprendices de español — actualiza la documentación para reflejar el estado final real.

Por lo demás: resiste el impulso de expandir el alcance.

Una meta-lección

Muchos proyectos nunca acaban. Se apagan, se abandonan, o acumulan "ya lo puliré más tarde" para siempre. El acto de cerrar formalmente — escribir el postmortem, marcar el ROADMAP en verde, hacer la lista de lectura — es lo que convierte el proyecto de una cosa a medias en una cosa terminada que te enseñó algo.

El siguiente proyecto será mejor porque este se terminó, no porque fuera perfecto.

Lo que este archivo NO cubre

• El formato de postmortem en sí. Siguiente archivo.
• Cómo se ve "buena supervivencia arquitectónica". Archivo 02.
• El método de curación de la lista de lectura. Lab 02.

Siguiente: 01-postmortem-structure.md