Saltar al contenido principal

Los artefactos de esta fase

La Fase 4 produce seis artefactos. Cada uno cumple una función específica en la trazabilidad entre lo construido y el problema que motivó el proyecto. En proyectos con construcción paralela, cada artefacto tiene una dimensión adicional que refleja la coordinación entre tracks.

ArtefactoFormatoConstruye
Decision Log distribuidoLog cronológico por track (Google Sheets). Se consolidan al cierreDev Leads por track. Context Engineer consolida al cierre
Grafo de dependencias actualizadoGrafo dirigido (Miro, draw.io)SM Agent (origen Fase 3). Actualizaciones autorizadas por Context Engineer
Actas de sincronización de integraciónActa de reunión (Google Docs)Tech Lead convoca. Context Engineer documenta
Build Validation ReportDocumento estructurado en 4 bloques, firmadoEquipo. Firman: Tech Lead, stakeholders Fases 1-2, Context Engineer
Context Document actualizadoArchivos Markdown (misma estructura que Fase 3)Context Engineer
Iteration Brief (borrador)Documento estructurado (Google Docs)Context Engineer / Product Lead con aprendizajes de todos los tracks

Secuencia de creación​

Setup (Paso 1)
    │
    ├── Decision Log distribuido ─── [continuo, desde el día 1]
    │
    ▼
Construcción (Paso 2)
    │
    ├── Grafo de dependencias ────── [se actualiza cuando surgen dependencias nuevas]
    │
    ├── Actas de sincronización ──── [en cada punto de sincronización del grafo]
    │
    ▼
Revisión de Fidelidad (Paso 4)
    │
    ├── Build Validation Report ──── [al completar los 4 bloques de revisión]
    │
    ▼
Cierre (Paso 5)
    │
    ├── Context Document actualizado
    │
    └── Iteration Brief (borrador)

1. Decision Log distribuido​

El registro continuo de cada decisión no prevista durante la construcción.

  • Formato: Log cronológico con campos: decisión, Story File, track, impacto estimado (local/cruzado/global), urgencia, estado.
  • Construye: Dev Leads por track. Context Engineer consolida al cierre.
  • Cuándo se crea: Desde el primer día. Un log por track, accesible para todo el equipo.
  • Propósito: Coordinación en tiempo real entre tracks y trazabilidad de cambios.
  • Consolidación final: Al cierre de la fase, los logs de todos los tracks se fusionan en un registro único donde las decisiones cruzadas y globales se consolidan en entradas que reflejan la resolución sistémica.
  • Estados finales válidos: Resuelto (Regla global), Resuelto (local), Resuelto (coherencia de integración), Abierto (pendiente Fase 5).

2. Grafo de dependencias actualizado​

El mapa de relaciones entre Story Files que determina qué puede construirse en paralelo.

  • Formato: Grafo dirigido con nodos (Story Files) y aristas (dependencias).
  • Construye: SM Agent (origen Fase 3). Actualizaciones autorizadas por Context Engineer.
  • Cuándo se crea: Heredado de la Fase 3. Verificado por todos los Dev Leads en el setup. Se actualiza cuando la construcción revela dependencias no documentadas.
  • En construcción paralela: Documento de referencia para activar y desactivar tracks. Cualquier modificación notifica a todos los Dev Leads.

3. Actas de sincronización de integración​

Registro formal de cada sesión de sincronización entre tracks.

  • Formato: Acta con: fecha, tracks involucrados, contratos de interfaz acordados, decisiones sobre incompatibilidades, track(s) que deben ajustar su output.
  • Construye: Tech Lead convoca. Context Engineer documenta.
  • Cuándo se crea: Cada vez que se activa una sincronización de integración.
  • Propósito: Evidencia del estado del sistema en cada punto del grafo de dependencias.

4. Build Validation Report​

El documento que certifica que lo construido es fiel al problema y la solución definidos.

  • Formato: Documento con resultados de los 4 bloques de la Revisión de Fidelidad.
  • Construye: Equipo. Firmantes: Tech Lead (Bloque 0), stakeholders de Fase 1 (Bloque 1), stakeholders de Fase 2 (Bloque 2), Context Engineer (Bloque 3).
  • Cuándo se crea: Al finalizar la Revisión de Fidelidad.
  • Condición de paso: Los cuatro bloques deben estar aprobados. El Bloque 0 es prerrequisito de los bloques 1 y 2.

5. Context Document actualizado​

El project-context.md que viaja a la Fase 5.

  • Formato: Archivos Markdown (misma estructura que Fase 3).
  • Construye: Context Engineer.
  • Cuándo se crea: Al finalizar el Paso 5 (Cierre).
  • Contenido: Todas las Reglas originales + todas las Reglas que emergieron de la construcción. Grafo de dependencias actualizado. Decisiones de integración documentadas.
  • Diferencia con la versión de Fase 3: Refleja lo que realmente se construyó, no lo que se planificó construir.

6. Iteration Brief (borrador)​

Los aprendizajes abiertos que la Fase 5 pondrá a prueba con el mercado.

  • Formato: Documento estructurado (Google Docs). Lista priorizada de hipótesis por validar, decisiones pendientes de datos del mercado, y asunciones activas del Problem Statement que la construcción no pudo confirmar ni refutar.
  • Construye: Context Engineer / Product Lead con aprendizajes de todos los tracks.
  • Cuándo se crea: Al finalizar el Paso 5 (Cierre).
  • En paralelo: Consolida aprendizajes de todos los tracks, no solo del más activo.
La cadena de trazabilidad completa

Problem Statement → Solution Brief → PRD → Story Files → Código construido → Build Validation Report. Si una línea de código no puede trazarse hasta el Problem Statement, es Context Debt. El Decision Log es el registro que hace verificable esta trazabilidad a través de todos los tracks.