Etapa 3 — Refinamiento

Etapa 3 — Refinamiento

• Input: los seis outputs canónicos de Etapa 2 (funcional.md v2, tecnica.md, ux.md, arbol-contenidos.md, diagrama-flujos.md, acta-kickoff.md).
• Quién participa:
  • Exponen: PO, UX, Arquitecto.
  • Reciben y retan: Backend, Frontend, SRE, QA.
• Proceso: 0. Primera acción del PO al arrancar etapa 3: redactar las HU formales en formato Connextra (Como <rol> quiero <capacidad> para <beneficio>) con criterios de aceptación Gherkin-lite, derivadas del funcional.md v2 + casos de uso de etapa 1 + prototipo UX. Las HU son input adicional para el resto del proceso.
  1. Ceremonia de refinamiento: las propuestas + HU se exponen al equipo ejecutor.
  2. El equipo reta con dudas.
  3. Bifurcación:
     • Inconsistencias graves → reabrir outputs de Etapa 2 y reconvocar refinamiento cuando estén adaptados.
     • Todo entendido y correcto → refinamiento OK.
  4. El equipo ejecutor realiza un análisis y produce informe de conclusiones.
• Output (4 piezas):
  1. HU formales (output inicial del PO al arrancar la etapa).
  2. Informe de análisis del equipo ejecutor.
  3. Tareas vinculadas a las HU.
  4. Calendario de entrega.
• Gate: validación humana antes de pasar a Etapa 4.
• Retroceso: a Etapa 2 si las inconsistencias son graves.

Flujos alternativos

El Director rechaza el refinamiento al firmar D-2

Si al revisar el hu.md el Director detecta cobertura incompleta de los bloques funcionales firmados en D-1, criterios de aceptación ambiguos (no verificables — viola CAL-037), criterios cuantitativos sin test asociado (viola CAL-046), o reordenamiento de IDs de HU sin ADR (viola ARQ-024), rechaza D-2 con veredicto explícito en el acta-refinamiento.md. El PO recibe la lista de observaciones, revisa el hu.md, ajusta lo que corresponde y entrega una versión v2 para nueva firma D-2. El gate no se firma sobre la versión rechazada.

Aparece una HU nueva sorpresiva durante el refinamiento

Si al refinar las HU el PO descubre una nueva HU que no estaba prevista en el funcional v2 firmado en D-1, la añade aditivamente con ID HU-N+1 respetando la regla de cambios aditivos (ARQ-024 — no se reordenan ni se renumeran los IDs ya asignados). Si la HU nueva contradice o invalida una HU ya firmada, el Director declara retroceso parcial al kickoff de Etapa 2 para rehacer el funcional sobre la base nueva.

Cruces materiales entre la HU y la pieza técnica firmada D-1

Si al aterrizar los criterios de aceptación el PO se encuentra con que un criterio cuantitativo declarado contradice una decisión técnica del tecnica.md v1 (por ejemplo, un umbral de rendimiento que el stack elegido no puede sostener), abre cruce mid-Etapa-3 al Arquitecto anotado en memory.md. El Arquitecto responde por escrito, el cruce se cierra en el acta-refinamiento.md con decisión razonada del Director, y el hu.md o el tecnica.md se ajustan en consecuencia antes de firmar D-2.

Documentación generada en esta etapa

Artefacto	Propietario	Tipo
etapa-3/hu.md	PO	Markdown
etapa-3/acta-refinamiento.md	Director	Markdown
adr/NNNN-<slug>.md (si el refinamiento abre alguna decisión arquitectónica)	Arquitecto (por encargo del Director)	Markdown
proyectos/<slug>/memory.md (entrada de cierre del turno)	PO	Markdown