Release 1 · 2026.11
Todo lo especificado hasta hoy. No es un mínimo viable ni un subconjunto: es la primera entrega
grande, la que el design partner opera de punta a punta contra el hito G1-Engage del 2026-11-01.
Que sea mucho trabajo no lo cambia. Un release parcial obliga a explicarle al cliente qué parte del
producto todavía no existe, y esa conversación cuesta más que construirlo.
Las cinco entregas
Se construyen en este orden porque las dependencias no dejan otro. Identity no depende de nadie; todo depende de Core; las tres últimas son independientes entre sí y van en paralelo.Cuándo una entrega está lista
Los cinco criterios son los mismos para todas, y todos son verificables. Ninguno admite “está casi”.- Todos sus feature specs en
approved. La regla R-S1 dice que no se mergea código de una feature cuyo spec no esté aprobado, así que esto no es una formalidad: es la precondición. - Todas sus tablas con página de schema, con atributos, restricciones y registro de cambios. Una tabla sin página no se puede implementar.
- Todos sus endpoints publicados en la página de API del módulo, con su permiso y su clase de SLO.
- Los presupuestos de latencia verificados con prueba de carga en certificación (R18). Son criterio de Definition of Done, no aspiraciones.
- Prueba de negación de RLS por tabla: una consulta bajo el contexto del tenant A devuelve cero filas del tenant B. Sin excepciones y sin tabla que se salte la prueba.
Qué pasa si algo no llega
Se decide y se escribe. Un spec marcadoF2 sigue siendo parte de Release 1; si al acercarse la
fecha no llega, eso es un recorte de alcance explícito que se registra en la página de su
entrega, no un default silencioso.
Preferimos esa conversación incómoda a la alternativa: descubrir en noviembre que media suite
“nunca estuvo en el alcance” porque nadie lo escribió.