Se aprueba una especificación de producto y necesita convertirse en software funcional — normalmente eso significa que un ingeniero la retoma entre otras tareas, escribe el código, escribe o actualiza las pruebas, abre un pull request y espera a un revisor que también está atendiendo su propia cola. Pasan días entre "aprobado" y "publicado", la mayor parte esperando, no trabajando.
Así es como se ve eso al pasar por el flujo gobernado de ContextTogether.
Ingesta. La especificación entra como documento. El flujo la extrae como conocimiento canónico — los requisitos, las restricciones, cómo se relaciona con el comportamiento ya documentado del resto del código base — para que nada se construya sobre un entendimiento desactualizado o contradictorio del sistema.
Ejecución con puntos de control. El código se escribe en pasos revisables y reanudables, no en un solo salto opaco de la especificación al pull request terminado. Cada punto de control queda registrado: qué se construyó, en qué orden, y por qué.
Verificación determinista. Antes de que una persona lo vea, el código pasa por pruebas y verificaciones automáticas — nada llega a revisión solo por la confianza de un modelo.
Punto de aprobación humana. Un revisor da el visto bueno antes de que algo se integre — el único paso que todavía necesita a una persona, y el único que lo necesita.
Recuperación. La especificación, los puntos de control, los resultados de las pruebas, la aprobación — todo queda recuperable con comprobantes, para que dentro de seis meses "por qué lo construimos así" tenga una respuesta.
La atención del ingeniero va a las decisiones de criterio, no a la espera.