Etapa 2 — Kickoff

Etapa 2 — Kickoff y definición a alto nivel

• Input: requerimiento funcional MVP de Etapa 1.
• Quién participa: PO (convoca), UX, Arquitecto.
• Proceso:
  1. Kickoff: PO traslada la necesidad a alto nivel.
  2. Detección temprana de inconsistencias con desarrollos pasados o estrategia futura (técnicas y de usabilidad). No aplica si el producto es totalmente nuevo.
     • Inconsistencia grave → retroceso a Etapa 1 (re-discusión stakeholder ↔ PO).
     • Inconsistencia moderada/leve → se resuelve aquí.
  3. Requerimientos funcionales cerrados definitivamente.
  4. Tres líneas de trabajo paralelas:
     • PO redacta historias de usuario.
     • UX produce prototipo de alto nivel.
     • Arquitecto produce propuesta técnica / stack a alto nivel (teórica, no ejecución).
• Mecánica del kickoff (decisión 2026-05-21, opción C): turnos con cruces. Cada agente abre turno, produce su output, recibe objeciones de los otros dos al cierre del turno, responde, queda cerrado. Tres mini-rondas (PO → Arquitecto → UX por defecto, orden ajustable según proyecto).
• Output canónico (6 piezas):
  1. funcional.md v2 (propietario PO) — análisis funcional de alto nivel actualizado con los acuerdos del kickoff. No incluye HU formales (esas son output de etapa 3).
  2. tecnica.md (propietario Arquitecto) — propuesta técnica + stack del proyecto + decisiones de catálogo/persistencia/contratos.
  3. ux.md (propietario UX) — prototipo de alto nivel con wireframes.
  4. arbol-contenidos.md (propietario UX) — jerarquía de pantallas en Mermaid.
  5. diagrama-flujos.md (propietario UX) — user flow en Mermaid.
  6. acta-kickoff.md (propietario Director) — recopilación de dudas, decisiones, cruces, gaps detectados + clasificación + veredicto del kickoff.
• Criterio de cierre del kickoff (firme, decisión 2026-05-21):
  • Un gap bloqueante cumple ≥1: (a) requiere información que solo tiene el stakeholder, (b) los tres agentes no convergen tras los cruces, (c) introduce contradicción funcional o técnica que reabre alcance.
  • ≥1 gap bloqueante → kickoff incompleto → flujo vuelve al PO para resolución autónoma o consulta directa al stakeholder → regenera funcional.md → repite kickoff.
  • Ningún gap bloqueante → kickoff exitoso → se notifica al Director humano para validación en gate.
• Gate: validación humana antes de pasar a Etapa 3.
• Retroceso: a Etapa 1 si hay inconsistencias graves o gaps bloqueantes que exijan reabrir alcance con el stakeholder.

Flujos alternativos

Cruces entre agentes sin cierre al llegar al acta del Director

Cada uno de los tres turnos del kickoff (PO, Arquitecto, UX) puede dejar cruces dirigidos a los otros agentes (por ejemplo, el UX cuestiona una decisión del PO, o el Arquitecto necesita una precisión del UX). El procedimiento canónico es que cada agente escriba sus cruces como sección final de su propio output, el Director los recoja al abrir el acta-kickoff.md y los cierre uno a uno con decisión razonada. Si algún cruce no admite cierre en el acta (porque exige una decisión que va más allá del kickoff), el Director lo escala al humano del arnés, deja la decisión documentada, y firma D-1 sobre la base resultante. Ningún cruce queda abierto al pasar a Etapa 3.

Retroceso a Etapa 1 desde el kickoff

Si durante la redacción del funcional v2 el PO detecta que el requerimiento-funcional-mvp.md firmado en S-1 contiene una ambigüedad que no puede resolver sin volver a hablar con el Stakeholder, abre conversación complementaria con el Stakeholder por el canal síncrono que éste prefiera, actualiza el 00-necesidad-stakeholder.md con la aclaración, ajusta el funcional v2 sin invalidar el S-1 firmado, y deja constancia en memory.md. Si la ambigüedad es lo bastante grave como para invalidar el S-1 firmado, el Director declara retroceso formal a Etapa 1 con un nuevo ciclo Q&A.

Sin pieza técnica al firmar D-1

Si por orquestación del Director el turno del Arquitecto se posterga (caso real observado en proyectos del arnés cuando el UX se invoca antes que el Arquitecto), el Director puede firmar D-1 con cruces UX↔Arquitecto pendientes siempre que las cinco piezas restantes estén firmes y los cruces queden explícitamente abiertos en el acta para resolverse al inicio de Etapa 4. Es decisión del Director y se documenta en el propio acta.

Documentación generada en esta etapa

Artefacto	Propietario	Tipo
etapa-2/funcional.md	PO	Markdown
etapa-2/tecnica.md	Arquitecto	Markdown
etapa-2/ux.md	UX	Markdown
etapa-2/arbol-contenidos.md	UX	Markdown
etapa-2/diagrama-flujos.md	UX	Markdown + diagramas Mermaid
etapa-2/acta-kickoff.md	Director	Markdown
adr/NNNN-<slug>.md (uno por cada decisión arquitectónica firme)	Arquitecto	Markdown
proyectos/<slug>/memory.md (entradas fechadas por turno)	Cada agente al cerrar su turno	Markdown