Sesiones multi-repo

Hay cambios que no caben en un repositorio: la API y el cliente que la consume, una librería compartida y las dos apps que la usan. Una sesión multi-repo vincula hasta cinco workspaces registrados en una sola sesión (un agente, una conversación, una revisión) mientras cada repositorio conserva su rama, su pull request y su base.

Crear una

En el modal de nueva sesión, el control de vincular repositorios te deja añadir otros workspaces que ya tengas registrados en Chronos. La sesión sigue siendo una unidad (un id, un agente, un sandbox), pero tiene una copia de trabajo por repo, cada una cortada desde la rama base de su propio repositorio y con el mismo nombre de rama de sesión.

Las copias vinculadas son escribibles en modo ejecución y de solo lectura en modo plan; la salida a red sigue la política más estricta de todos los repos vinculados.

Cuándo usarla

Vincula repos cuando el cambio es uno y cruza repositorios (un contrato y sus consumidores). Para tareas independientes, sesiones separadas en paralelo siguen siendo la opción buena.

Pedirle el trabajo

El agente conoce el nombre y la ruta de cada repo, trabaja sobre todos en la misma conversación y sabe que cada repositorio sale en su propio pull request. Nombra los repos con naturalidad: «cambia el contrato en api y adapta el consumo en web».

Los prompts, el modo plan, las misiones y el resto de controles del composer funcionan igual que en una sesión normal: es una sesión, solo que con más de una copia de trabajo.

Revisar por repo

El panel derecho gana una barra de repos: una píldora para el principal y otra por cada vinculado. Files, Changes, Checks y el Diff se acotan al repo seleccionado, así revisas los cambios de cada repositorio en sus propios términos.

Enviar

• Un PR por repo. Cada repositorio con cambios recibe su propio pull request, contra su propia rama base. El menú de PR de la cabecera los lista todos.
• Aprobación y merge son de la sesión. Una sola acción de merge integra primero los repos vinculados y el principal al final, con idempotencia por repo: si un merge falla a mitad, arreglarlo y reintentar nunca vuelve a integrar lo que ya entró. Ver PRs y merge.
• Los consentimientos pendientes aparecen también en la cola de atención, como en cualquier otra sesión.
• Cerrar o eliminar la sesión limpia todas las copias de trabajo, incluso si uno de los workspaces vinculados ya no existe.

Límites (v1)

• Se inyectan las variables del workspace principal; los repos vinculados no traen su propio conjunto.
• Los run targets, los checks y el setup corren sobre el repo principal. Ver Ejecutar tu proyecto.
• Los repos solo se vinculan al crear la sesión, no después.