Quién participa y cómo se organiza el equipo
En las fases anteriores, la composición del equipo se organizaba en torno a una actividad central: descubrir el problema, alinear la solución, diseñar el contexto. En la Fase 4, la composición se organiza en torno a una tensión: cómo distribuir la construcción entre múltiples personas y agentes de IA sin perder la coherencia del contexto.
El cambio fundamental
En la Fase 3, el Context Engineer era el protagonista absoluto: diseñaba Agentes, Reglas y Skills. En la Fase 4, el Context Engineer pasa a un rol de supervisión. Ya no crea, protege. Su trabajo es asegurar que lo que se construye sigue siendo fiel a lo que se diseñó.
El protagonismo se distribuye entre desarrolladores que ejecutan Story Files con agentes de IA. Pero esa distribución no es plana. Hay una jerarquía funcional donde cada nivel tiene exactamente la visibilidad y capacidad de decisión que su posición justifica.
Los cinco niveles
| Nivel | Rol | Qué hace en esta fase | Qué puede decidir |
|---|---|---|---|
| 1 | Context Engineer | Propietario del project-context.md. Tiene visibilidad de todos los tracks en tiempo real. Resuelve gaps que afectan a más de un track. | Total sobre Reglas. Puede detener cualquier track de construcción. |
| 2 | Tech Lead | Supervisa la coherencia técnica entre tracks. Detecta colisiones de decisiones entre equipos. Primera línea de escalación para problemas de integración. | Puede pausar un track. No puede modificar Reglas sin el Context Engineer. |
| 3 | Dev Leads de track | Lideran la ejecución de su grupo de Story Files. Mantienen el Decision Log del track. Escalan al Tech Lead cuando una decisión local puede afectar a otro track. | Decisiones locales al track. No pueden tomar decisiones de integración. |
| 4 | Desarrolladores | Ejecutan Story Files con agentes de IA bajo supervisión del Dev Lead. Documentan gaps en tiempo real. | Solo dentro del Story File activo. No toman decisiones técnicas no previstas sin documentarlas. |
| 5 | QA Agent | Valida cada output de Story File antes de que pase a "completado". Detecta violaciones de Reglas. Señala outputs que podrían colisionar con otros tracks. | Puede bloquear un Story File. No puede aprobar cambios de Reglas. |
Un desarrollador que no ve el track vecino no debería tomar decisiones que lo afecten. Un Context Engineer que ve todos los tracks es el único que puede tomar decisiones transversales. Cada nivel tiene acceso a exactamente la información que necesita y exactamente la capacidad de decisión que su visibilidad justifica.
Roles que regresan de fases anteriores
Los stakeholders de las Fases 1 y 2 no participan en la construcción diaria. Pero regresan en dos momentos críticos:
En las Revisiones de Fidelidad Parciales: cada 3-4 Stories completados, el Context Engineer presenta el estado integrado del proyecto. Los stakeholders evalúan si lo que se está construyendo sigue siendo reconocible como respuesta al problema que definieron.
En la Revisión de Fidelidad Final: al completar la construcción, los stakeholders firman el Build Validation Report. Su pregunta no es "¿el código es bueno?" sino "¿esto resuelve el problema que describimos?"
En proyectos pequeños
No todos los proyectos necesitan cinco niveles. En un equipo de 1-2 personas con construcción secuencial:
- El Context Engineer y el Tech Lead son la misma persona
- No hay Dev Leads de track porque no hay tracks paralelos
- El desarrollador ejecuta Story Files en secuencia y mantiene un Decision Log simple
- El QA Agent sigue siendo obligatorio, es la validación que protege la fidelidad
La jerarquía se simplifica, pero los roles de supervisión (Context Engineer) y validación (QA Agent) nunca desaparecen. Sin ellos, la construcción pierde su anclaje al contexto.