Etapa 6 — Retrospectiva y consolidación

Etapa 6 — Retrospectiva (decisión 2026-05-23)

Ceremonia de cierre del proyecto en el arnés. Obligatoria al firmar el gate final de etapa 5: sin retrospectiva, el proyecto no se considera cerrado del todo en el arnés (aunque el producto esté en producción y funcionando).

Propósito: extraer aprendizajes del proyecto entero (no de un incidente concreto — eso es un post-mortem, que es otra ceremonia) y convertirlos en cambios concretos al sistema. La retrospectiva mira lo que funcionó, lo que no, las sorpresas y los gaps, no solo los fallos.

Frontera con post-mortem: un post-mortem se dispara por un incidente puntual (bug grave, gap del sistema, fallo en producción) y produce reglas para que el incidente concreto no se repita. La retrospectiva se dispara por el cierre del proyecto y produce mejoras estructurales del sistema. Los post-mortems que hayan ocurrido durante el proyecto son insumo de la retrospectiva, no la sustituyen.

Quién participa:

En fase 1: el asistente conduce; el titular del arnés en rol Director + stakeholder firma los gates.
En fase 2: el agente Director del ciclo conduce; humano sigue firmando.

Sub-etapas:

6.0 Consolidación de artefactos de diseño (decisión 2026-05-26)

Propósito: antes de mirar el proyecto para extraer aprendizajes, sanear los artefactos de diseño para que reflejen el producto realmente construido, no el planificado. Sin este paso la retrospectiva lee evidencia obsoleta (diagramas con flujos retirados, decisiones técnicas drift-eadas) y produce conclusiones contaminadas.

Cascada de consolidación (3 habilidades en habilidades/consolidacion-*):

consolidacion-funcional (propietario PO) — primero. Sanea etapa-2/funcional.md y, si aplica, etapa-3/hu.md. Genera versión N+1 con frontmatter incrementado, historial y sección “Delta vN+1”. Al cerrar, declara el cierre en memory.md del proyecto con / sin deltas y dispara las otras dos en paralelo.
consolidacion-ux (propietario UX) — en paralelo a Técnica. Lee el funcional consolidado y sanea etapa-2/ux.md, etapa-2/arbol-contenidos.md, etapa-2/diagrama-flujos.md. Genera versión N+1 de cada uno (o firma “sin deltas” si no hubo drift).
consolidacion-tecnica (propietario Arquitecto) — en paralelo a UX. Lee el funcional consolidado y sanea etapa-2/tecnica.md. Genera versión N+1 (o firma “sin deltas”).

Las 3 habilidades describen su proceso interno en sus respectivos README.md. Esta sub-etapa es la declaración formal de obligatoriedad en el ciclo: sin las 3 consolidaciones firmadas en memory.md del proyecto, 6.1 no arranca.

Estado de implementación (act. 2026-05-30): las habilidades existen como contrato. Los 8 agentes del arnés están construidos (PO, Director, Arquitecto —dueño del rol Técnico—, QA, SRE, UX, Backend y Frontend; arnés 8/8 desde 2026-05-30). El disparo agéntico end-to-end (daemon despertando a los agentes por turnos en el kickoff/consolidaciones) aún no está cableado, así que mientras tanto el asistente conduce las habilidades asumiendo los roles, anotando en memory.md del proyecto las firmas con marcador “ejecutada por asistente en ausencia de flujo agéntico”. Cuando el disparo esté cableado, el flujo pasa a ser end-to-end agéntico sin más cambios al ciclo.

Output: artefactos vN+1 actualizados (los que tuvieron deltas) + entradas fechadas en memory.md del proyecto declarando las 3 firmas (PO, UX, Arquitecto).

Sin gate (las firmas en memory.md actúan como cierres mecánicos de cada habilidad; el Director valida en 6.6 que están las 3).

6.1 Recopilación de evidencia

El Director recoge automáticamente los insumos disponibles:
- Informe de cumplimiento de directrices (decisión 2026-05-26): proyectos/<proyecto>/informes/cumplimiento-directrices-YYYY-MM-DD.md + render PDF/HTML — generado por el agente Arquitecto tras las 3 firmas de 6.0. Auditoría descriptiva regla por regla de las directrices vigentes contra el proyecto, con veredicto ✅ cumple / ⚠️ parcial / ❌ no cumple / 🚫 no aplica y evidencia/justificación por regla, resumen ejecutivo + cifras agregadas por directriz + hallazgos relevantes + recomendaciones de cierre. El Arquitecto envía además correo al Stakeholder con el resumen ejecutivo. Procedimiento detallado en .claude/agents/arquitecto.md. Estado de implementación (2026-05-26): el Arquitecto existe como sesión SDK efímera disparada por el Director vía inbox/; la invocación hoy es manual (Stakeholder deposita encargo en churrerIA/director/inbox/<timestamp>-cumplimiento-<slug>.md con frontmatter agente: arquitecto, encargo: informe-cumplimiento, proyectos: [<slug>]). Cuando el Director pase a variante con autoridad orquestadora (D-D), invocará al Arquitecto automáticamente al detectar las 3 firmas de 6.0 en memory.md del proyecto. Cross-ref del Arquitecto en director/log.md al cerrar.
- Artefactos consolidados en 6.0: funcional.md vN+1, hu.md vN+1 (si aplica), ux.md vN+1, arbol-contenidos.md vN+1, diagrama-flujos.md vN+1, tecnica.md vN+1 — junto con sus secciones “Delta vN+1” como evidencia del drift planificado↔construido.
- memory.md del proyecto (decisiones, gaps, hitos).
- cumplimiento-plan.md de etapa 4 (documento canónico de Etapa 4.7): registro final de qué fases se completaron, cuáles quedaron parciales (⚠️ con su deuda documentada), cuáles se descartaron (🚫 con motivo). Fuente más rica de la trayectoria real de la implementación.
- Issues abiertos y cerrados del repo del proyecto (gh issue list --state all).
- Actas firmadas de los 8 gates anteriores (etapas 1-5).
- Post-mortems que hayan ocurrido durante el proyecto si los hubo (con sus reglas resultantes).
- PRs mergeados y commits significativos.
- Iteraciones de gates (p. ej. cuántas versiones del sub-gate 4.2 hicieron falta).
- Auditoría de deuda generada en caliente (propuesta #2 retrospectiva piloto vocab-1000, 2026-05-23): reglas firmes con sufijos provisionales (-bis, -tmp, -draft), TODOs sin cerrar en código y documentos, decisiones con marcador temporal (pendiente, por definir, a fijar antes del primer proyecto), excepciones documentadas a directrices con plazo vencido. Se lista en §0 de retrospectiva.md con su origen (commit/sesión donde se introdujo) para que el triaje 6.4 decida qué se limpia en 6.5.
- Informes individuales de aprendizaje por agente (propuesta #7 retrospectiva piloto vocab-1000, 2026-05-23): cada agente del ciclo (Backend, Frontend, SRE, QA, UX, PO, Arquitecto, Director) entrega al Director un mini-informe propio (qué le costó, qué directrices se sintieron forzadas o ausentes, qué herramienta le falló, qué patrón replicaría). Formato detallado a definir cuando los agentes existan en fase 1 — hasta entonces, el Director consolida la voz colectiva desde memory.md y se anota como pendiente en cada retrospectiva.
Output: proyectos/<proyecto>/etapa-6/retrospectiva.md §0 (evidencia en bruto, sin lectura).
Sin gate.

6.2 Lectura del proyecto

Sobre la evidencia de 6.1, el Director clasifica los hechos en cuatro lentes:
- §1 Patrones validados — lo que funcionó y conviene mantener o extender a próximos proyectos. Ejemplos: separación tokens vs marcado, sub-gate 4.2, persistencia IDB→LS→memory.
- §2 Anti-patrones confirmados — lo que falló y hay que evitar. Ejemplos: gate firmado sin inventario, criterio cuantitativo en prosa.
- §3 Sorpresas — decisiones cuyo coste/valor no era evidente al inicio y resultaron clave (en cualquier dirección). Ejemplos: iteraciones de paleta sin retrabajo de componentes; coste oculto de Next.js 16 vs versiones previas.
- §4 Gaps del sistema — lo que el arnés no cubría y ahora se ha hecho visible.
Output: retrospectiva.md §1-4.
Sin gate.

6.3 Propuestas de cambio al sistema

Para cada aprendizaje accionable de §1-4, una propuesta concreta con:
- Tipo: directriz (regla nueva, retirada o matizada) / ciclo (etapa, sub-gate, output canónico) / agente (capacidad nueva, prompt refinado) / habilidad (capacidad nueva en habilidades/) / plantilla (formato canónico nuevo o modificado).
- Justificación trazada a la evidencia de §0 (un patrón, un anti-patrón, una sorpresa, un gap).
- Coste estimado de aplicar (baja / media / alta), para ayudar al triaje del gate 6.4.
Output: retrospectiva.md §5 — lista numerada.
Sin gate.

6.4 Triaje humano (GATE)

el titular del arnés (rol Director + stakeholder) revisa cada propuesta y decide:
- Aceptar — se ejecuta en 6.5.
- Posponer — con condición de retoma explícita (“cuando aparezca un proyecto con X”, “tras N proyectos más”, “en la próxima retrospectiva sistémica”).
- Rechazar — con motivo registrado.
Output: proyectos/<proyecto>/etapa-6/acta-retro.md firmada, con cada propuesta marcada con su veredicto y motivo si aplica.
GATE.

6.5 Ejecución de cambios aceptados

Las propuestas aceptadas en 6.4 se aplican al sistema:
- Edits en directrices/, ciclo.md, habilidades/, plantillas, definiciones de agentes.
- Cada cambio = commit (o PR si el cambio toca un repo separado) con motivo trazado a la propuesta numerada de retrospectiva.md.
Limpieza explícita de la deuda detectada en 6.1 (propuesta #3 retrospectiva piloto vocab-1000, 2026-05-23): las propuestas de 6.4 que aprueben limpiar deuda concreta se ejecutan aquí, no en otro momento. Casos típicos: renumerar reglas con sufijos provisionales (-bis → ID limpio), cerrar TODOs marcados con plazo cumplido, retirar excepciones documentadas con plazo vencido, sustituir marcadores temporales (pendiente, por definir) por la decisión cerrada cuando corresponda. La sección “Cambios aplicados” registra cada limpieza con su trazabilidad.
Las propuestas pospuestas quedan en acta-retro.md como deuda visible, con la condición de retoma.
Las propuestas rechazadas no se ejecutan, pero quedan registradas para que un futuro Director vea que esa idea ya se evaluó y descartó (con motivo).
Output: commits / PRs aplicados + sección “Cambios aplicados” al final de retrospectiva.md con checklist (✅ cada propuesta aceptada → commit/PR concreto).
Sin gate (la firma de 6.4 autoriza la ejecución).

6.6 Cierre formal del proyecto (GATE FINAL)

El Director valida que:
- Las 3 consolidaciones de 6.0 están firmadas en memory.md del proyecto (PO, UX, Arquitecto) — sin esto, el cierre no procede.
- Todas las propuestas aceptadas en 6.4 están ejecutadas (checklist completa).
- retrospectiva.md está completa (§0-5 + cambios aplicados).
- acta-retro.md firmada.
el titular del arnés firma el gate final: el proyecto pasa a estado CERRADO en el arnés.
A partir de aquí, el proyecto queda como referencia consultable (artefactos persistentes en proyectos/<proyecto>/) pero inmutable: no se reabre salvo que un incidente futuro lo justifique (y entonces es un post-mortem, no una retrospectiva nueva).
GATE FINAL.

Output canónico de Etapa 6:

Artefactos de diseño consolidados (6.0): funcional.md, hu.md, ux.md, arbol-contenidos.md, diagrama-flujos.md, tecnica.md — en versión vN+1 los que tuvieron deltas, o firma “sin deltas” registrada en memory.md del proyecto.
proyectos/<proyecto>/etapa-6/retrospectiva.md (§0 evidencia + §1-4 lectura + §5 propuestas + sección final “Cambios aplicados”).
proyectos/<proyecto>/etapa-6/acta-retro.md (triaje firmado).
Commits / PRs trazables a las propuestas aceptadas.

Retroceso: la etapa 6 NO entra en el bucle del ciclo (ver sección siguiente). Si en 6.4 alguna propuesta exige reabrir un proyecto cerrado (caso límite: el aprendizaje invalida algo ya entregado), eso se trata como un proyecto nuevo, no como retroceso desde la retrospectiva.

Frontera con retrospectiva sistémica (no formalizada todavía): la etapa 6 mira un proyecto. Cuando haya varios proyectos cerrados, podría tener sentido una “retrospectiva sistémica” periódica que mira el arnés entero (cross-proyectos). Por ahora no se formaliza — se decide cuando exista al menos un segundo proyecto cerrado y haya material para mirar.

Flujos alternativos

Lecciones del proyecto que disparan apertura de nuevos proyectos

Durante la retrospectiva (gate D-6), el equipo puede detectar lecciones que no caben en el proyecto cerrado: un patrón reutilizable que merece habilidad propia del arnés, un gap operativo recurrente que exige nueva regla en una directriz, una herramienta nueva detectada como necesaria para futuros proyectos. El Director, al cerrar el acta-retrospectiva.md, abre encargo de proyecto nuevo al PO si la lección lo justifica, dejando la trazabilidad de origen entre el memory.md del proyecto cerrado y el 00-necesidad-stakeholder.md del nuevo proyecto.

Lecciones que modifican las directrices del arnés

Si la retrospectiva detecta una anti-patrón nuevo que ninguna regla firme cubría, o una regla existente que la práctica demostró que debe reforzarse o reescribirse, el Director (en el gate D-7 de consolidación) edita la directriz correspondiente (arquitectura.md, calidad.md, observabilidad.md, usabilidad.md) añadiendo una entrada en su sección de Revisiones con la versión nueva, la fecha, el cambio y el motivo. El cambio en la directriz se propaga al siguiente proyecto que la consuma.

El Director rechaza el cierre de retrospectiva al firmar D-6

Si el material de retrospectiva no contiene evidencia suficiente sobre los hitos del proyecto, omite los incidentes que requirieron tratamiento explícito durante el desarrollo, o no enumera las lecciones aprendidas con la granularidad que el arnés exige, el Director bloquea D-6 y devuelve al equipo la retrospectiva para completar. Cierra cuando la pieza tiene la información necesaria para que un proyecto futuro pueda aprovecharla.

Gap del propio arnés detectado durante la consolidación (D-7)

Si en el gate D-7 el Director detecta un gap operativo del propio arnés que la retrospectiva del proyecto no identificó (por ejemplo, una contradicción entre dos directrices, una pieza canónica que ningún agente sabe quién la mantiene), abre un gap numerado en la bitácora global del arnés y lo deja para sesión interactiva del titular. Esto permite que el ciclo cierre sin bloquear el proyecto, pero deja constancia explícita de la deuda sistémica.

Documentación generada en esta etapa

Artefacto	Propietario	Tipo
`etapa-6/acta-retrospectiva.md`	Director (coordinando aportes de todos los agentes)	Markdown
`etapa-6/acta-consolidacion-tecnica.md`	Arquitecto (consolidación técnica del proyecto)	Markdown
`etapa-6/acta-consolidacion-ux.md`	UX (consolidación visual y de patrones de uso)	Markdown
Ediciones sobre `directrices/*.md` del arnés (si proceden)	Director firma; Arquitecto, QA, UX co-autores según carril	Markdown
Encargos nuevos en `director/inbox/` para proyectos derivados (si proceden)	Director	Markdown
`proyectos/<slug>/memory.md` (entrada final de cierre del proyecto)	Director	Markdown