Anatomía de la construcción paralela
La construcción paralela no es simplemente "varias personas trabajando a la vez". Es un sistema con estructura interna: un grafo que determina qué puede ocurrir simultáneamente, un mecanismo de coordinación que hace visible lo que ocurre en cada track, puntos de sincronización que verifican la coherencia, y un agente de validación que protege la integridad del conjunto.
Capa 1: El grafo de dependencias
El grafo de dependencias es el documento que determina qué puede construirse en paralelo y qué debe esperar. Es producido por el SM Agent en la Fase 3 y verificado por todos los Dev Leads en el setup de la Fase 4.
Elementos del grafo
Story File A ──────────────────────────────── [independiente]
Story File B ──────────────────────────────── [independiente]
Story File C ──→ depende de A ─────────────── [secuencial tras A]
Story File D ──→ depende de B ─────────────── [secuencial tras B]
Story File E ──→ integración de C + D ─────── [espera C y D]
Cada nodo del grafo tiene:
- Story File(s) que lo componen
- Track al que está asignado
- Dependencias explícitas (qué debe estar completado antes)
- Punto de sincronización (si es un nodo de integración)
Tipos de relación
| Relación | ¿Paralelizable? | Condición |
|---|---|---|
| Independientes | Sí | Las Reglas del project-context.md bastan para que ambos se completen sin comunicación. |
| Dependencia directa | No | El output de uno es input del otro. Secuencia obligatoria. |
| Dependencia compartida de datos | Condicionalmente | Sí, si el schema de datos está definido como Regla global en el project-context.md. |
| Dependencia de integración | Paralelo hasta la integración | Cada uno se construye en su track. El Skill de integración espera a que ambos estén validados. |
Capa 2: El Decision Log distribuido
En construcción paralela, el Decision Log es el sistema nervioso del equipo. Cada entrada contiene campos adicionales respecto a la construcción secuencial:
| Campo | Descripción | Específico de paralelo |
|---|---|---|
| Decisión tomada | Qué se decidió que no estaba en el Story File. | — |
| Story File afectado | Referencia al Skill. | — |
| Track de construcción | Identificador del track. | Obligatorio. Sin él, el Context Engineer no puede hacer triage. |
| Impacto estimado | Local / Cruzado / Global | El campo más crítico. Activa protocolos distintos según el valor. |
| Urgencia de resolución | Inmediata / Diferida / Informativa | Determina si el Context Engineer necesita intervenir ahora. |
| Estado | Abierta / En revisión / Resuelta (local) / Resuelta (Regla global) / Pendiente Fase 5 | El Context Engineer revisa todas las "Cruzadas" antes de cada sincronización. |
Tres propiedades del Decision Log distribuido
- Visibilidad en tiempo real: Todas las entradas de todos los tracks son accesibles para el Context Engineer y el Tech Lead en el momento en que se registran.
- Clasificación por impacto de track: El desarrollador (quien está más cerca de la decisión) clasifica si es local, cruzada o global.
- Protocolo de alerta entre tracks: Una entrada clasificada como "cruzada" activa revisión entre Dev Leads de ambos tracks y el Tech Lead.
El indicador más útil de la salud del Decision Log no es el número total de entradas, sino la velocidad entre la ocurrencia del gap y su registro. Un gap registrado en el momento tiene coste cero de comunicación. Un gap registrado dos días después tiene el coste de todo lo que se construyó sobre él.
Capa 3: Las sincronizaciones de integración
Las sincronizaciones no se programan por calendario. Se programan por el grafo de dependencias.
| Tipo | Cuándo se activa | Quién participa | Qué se verifica |
|---|---|---|---|
| De schema | Antes de iniciar tracks con dependencia compartida de datos. | Context Engineer + Dev Leads de los tracks afectados. | El schema en el project-context.md es suficientemente preciso para ambos tracks. |
| De interfaz | Cuando dos Skills de tracks distintos definen la interfaz de comunicación. | Dev Leads + Tech Lead. | El contrato (API, schema de mensajes, protocolo) es compatible. |
| De integración mayor | Cuando todos los Skills de un grupo de dependencia están validados por QA. | Tech Lead + Dev Leads de todos los tracks del grupo. | Los outputs se integran sin colisión. El Skill de integración puede ejecutarse. |
| Revisión de fidelidad parcial | Cada 3-4 Stories completados en el conjunto. | Context Engineer + representante de cada track. | El estado global sigue siendo reconocible como expresión del Problem Statement. |
Cada sincronización produce un acta que documenta: contratos acordados, decisiones sobre incompatibilidades y tracks afectados.
Capa 4: El QA Agent en construcción paralela
En construcción secuencial, el QA Agent valida Story Files de forma independiente. En paralelo, tiene un rol adicional: es el primer mecanismo de detección de incoherencias entre tracks.
| Tipo de validación | En secuencial | Adicional en paralelo |
|---|---|---|
| Criterios de aceptación | Verifica todos los criterios del Story File. | Sin cambios. |
| Conformidad con Reglas | Verifica que el output respeta el project-context.md. | Verifica la versión más reciente. Si fue actualizado durante la ejecución, fuerza re-ejecución. |
| Trazabilidad al PRD | Señala funcionalidades sin referencia en el PRD. | Indica en qué track se originó la funcionalidad no trazada. |
| Compatibilidad con contratos | No aplica. | Verifica que el output es compatible con el contrato de interfaz definido en la sincronización de schema. |
| Ausencia de context drift | Detecta patrones inconsistentes en un track. | Detecta patrones inconsistentes entre tracks (ej.: convenciones de nomenclatura distintas entre tracks). |