Tareas en paralelo

Desde 3.198.0, las tareas de un plan con 04 corren en paralelo de fábrica: «aprobado solución» aprueba el plan y autoriza el lote con un tope calculado, y kb lote correr --todo las corre a la vez —cada una en su propia carpeta, con su rama, su agente y su ventana de contexto—; kbspec verifica e integra, y la persona revisa al final. De a una, cada una validada antes de la siguiente, cuando se pide: «aprobado solución una a una», kb ejecucion secuencial, o modo: secuencial en CICLO.md para todo el equipo. Un XS o un S va siempre de a una, y si la máquina no tiene con qué correr el lote (la CLI o el SDK de Copilot), el agente sigue de a una sin pedir nada.

	Qué es	Dónde corre
De a una	`/kb-implementar`: tarea, validación, siguiente	La carpeta de siempre
Modo lote de `/kb-implementar`	Todas seguidas en el mismo chat, con una sola validación al final	La carpeta de siempre
`kb lote`	Las tareas de una ola a la vez, un agente por tarea	Un árbol por tarea
`kb paralelo`	Otro requerimiento, no otra tarea: ver Dos requerimientos a la vez	Otra carpeta, otra ventana

Qué tareas pueden ir juntas

kb lote                  # el plan en olas, y lo que impide el lote
kb listo --paralelo      # el veredicto de siempre, más lo que el lote exige del plan

Cada tarea va en la primera ola posterior a sus dependencias donde haya lugar y no comparta archivos con otra. Eso sale del propio plan (el 04): Depende de y Archivos previstos. Una tarea sin archivos declarados va sola en su ola, y en cada ola entran hasta max_por_ola tareas —3 si el equipo no lo cambió en CICLO.md, de 1 a 10—. Lo que impide el lote se dice con la tarea: una tarea sin **Se verifica con:**, sin aplicación, o con una dependencia que no existe o que cierra un círculo. Se corrige el plan en la fase 4, no en el lote. **Modelo:** es opcional: cada tarea puede pedir el suyo.

El recorrido de una ola

kb lote preparar                              # un árbol y una rama por tarea de la ola
kb lote autorizar --hasta 40 --motivo "…"     # la persona: «aprobado lote 40» en el chat
kb lote correr                                # un agente por tarea, a la vez
kb lote verificar                             # la verificación de cada tarea, en su árbol
kb ramas                                      # la copia principal, en la rama de trabajo
kb lote integrar                              # merge a la rama de trabajo, en orden
kb lote final                                 # todo junto, cuando no quedan olas
kb lote revisar                               # la revisión del conjunto: paquete y choques
kb lote revisar --cerrar                      # lo abierto, a una tarea de corrección

Preparar. Un git worktree por tarea desde la punta más nueva de la rama de trabajo, con su rama (<rama de trabajo>-T-NN), la sesión de kbspec y un brief autocontenido en .kb/lote-brief.md. Las tareas quedan 🔄 y la bitácora (05) queda abierta. La ola siguiente se prepara recién con la anterior integrada, así que arranca con sus dependencias adentro.
Lanzar. Tres caminos. kb lote correr lanza un agente por tarea con la CLI de Copilot (--agent kb-implementar y el modelo de la tarea; la línea se cambia con corredor en CICLO.md, y la de fábrica le niega el git push), espera —--tope en minutos, 60 si no se dice— y verifica. Sin la CLI, el agente kb-lote coordina desde la ventana de agentes, con una sesión por tarea: no escribe código, la compuerta se lo impide. O se abre cada carpeta a mano.
Cerrar cada tarea. Cada agente termina con kb tarea T-NN --hecho "…", que en el árbol corre la verificación de esa tarea, escribe la bitácora y commitea en su rama. La tarea sigue 🔄.
Verificar. kb lote verificar corre de nuevo la verificación de cada tarea en su árbol —la que dice el 04, no una marca que el agente pudiera reescribir— y deja evidencias/LOTE-T-NN.txt. Una tarea sin commit, con cambios sueltos o en rojo queda fallida, y avisa si tocó archivos que no estaban previstos. La fallida se corrige en su árbol. Si la tarea se cerró con su verificación en verde y el árbol sigue en ese commit, no la repite: reusa la del cierre y lo deja en el rastro (--repetir la corre igual).
Integrar. Merge de cada tarea verificada a la rama de trabajo, en el orden del plan, en la copia principal (que tiene que estar limpia y en esa rama). Un conflicto aborta ese merge sin dejar nada a medias y dice qué archivo chocó. Después quita los árboles.
Todo junto. kb lote final corre la verificación de cada tarea con todo integrado (evidencias/LOTE-FINAL.txt) y kb validar: cada comando distinto una vez por repositorio, y los repositorios a la vez. Verde quiere decir que todo junto compila y pasa; no, que todo junto esté bien hecho. La verificación completa —sin acotar— va una sola vez, con las E2E.
Las dependencias de cada árbol. Un árbol nace sin node_modules. kbspec lo deja puesto antes de que arranque el agente:
- macOS y Linux: un enlace al de la copia principal, si el archivo de bloqueo es igual.
- Windows: instalado con el archivo de bloqueo (npm ci), nunca con una unión de directorio. git worktree remove --force las recorre y borra lo de la copia principal.
El enlace queda fuera de git y se suelta antes de quitar el árbol. dependencias en CICLO.md lo cambia: auto, instalar o nada.
La revisión del conjunto. Cada agente vio su tarea y nadie el conjunto. kb lote revisar arma el paquete —el diff de todo lo integrado y lo aprobado— y busca, sin gastar tokens, los choques entre tareas: dos que agregaron lo mismo por su lado (FechaHelper en una, FechasUtil en otra) y los nombres nuevos con una palabra que el glosario dice evitar. Los anota en el 05 y las lentes de estándares y de cumplimiento leen el paquete. kb lote revisar --cerrar junta lo abierto en una tarea de corrección por aplicación —no una por agente: la corrige una sesión que ve todo— y la agrega al plan; la persona la autoriza y el lote la corre. kb lote correr --todo la prepara solo al terminar.
La validación humana. Con la revisión del conjunto cerrada falta lo único que no se delega: una validación humana de todo el paquete. Con el OK, la persona cierra escribiendo «aprobado cierre» en el chat —kb tarea --todas—, que antes de esto se niega. Verde no es validado.

La autorización y el tope

kb lote correr es el único camino sin nadie mirando cada turno, y no lanza nada sin kb lote autorizar --hasta <créditos>. Lo decide la persona escribiendo «aprobado lote <créditos>» en el chat —o lo corre en su terminal; al agente la compuerta se lo niega—, aprueba también el plan y se niega si kb listo dice NO LISTO. La autorización vale para este plan: queda sellada la huella de lo que hace cada tarea (sección, dependencias, archivos, verificación y modelo). Marcar estados o tildar casillas no la cambia; cambiar un alcance sí, y hay que autorizar de nuevo. Al llegar al tope de créditos, corta a todos los agentes. El resto de los controles de gasto está en La IA bajo política.

Lo que lo hace seguro

Candados donde se escribe a la vez. La bitácora (05) y el plan (04) se escriben bajo candado: medido sin él, tres cierres simultáneos perdían entradas de la bitácora en 4 de 4 corridas. Y cuando varias sesiones de la ventana de agentes cierran a la vez, las integraciones van de a una: un cierre espera al que está integrando, y si la rama de trabajo del remoto va adelante, primero se la trae.
La rama correcta es la de la tarea. La compuerta que frena escribir en la rama equivocada reconoce el árbol de una tarea del lote, y ahí kb ramas y kb tarea --iniciar no mueven nada.
El estado del lote es el rastro de auditoría: cada tarea preparada, hecha, verificada o integrada es un evento encadenado como cualquier otro, no un archivo de estado aparte.
Cada agente sabe que está en el lote. Las otras conversaciones del requerimiento —el coordinador y las otras tareas— no son un conflicto y no se le pregunta a nadie; solo se avisa de otra conversación en su mismo árbol. Si el árbol trae trabajo de un intento anterior, el pedido dice qué archivos y que son de esa misma tarea.
Terminar preguntando no es terminar. Si un agente termina sin cambios y esperando una respuesta, el lote lo dice y la corrección le contesta. Y una verificación que no corrió ninguna prueba —un filtro sin coincidencias que sale con 0— no deja la tarea verificada.

`kb lote informe` y la demo

kb lote informe da el veredicto de cualquier lote y lo guarda en evidencias/LOTE-INFORME.md: cuántas tareas corrieron a la vez, el tiempo en paralelo contra una tras otra, si cada una pasó su verificación y se integró, si kb lote final quedó en verde, qué modelo usó cada tarea según los registros de Copilot —no según el agente— contra el que pedía el plan, y el gasto en créditos y dólares, por tarea y de la coordinación.

Para probar en una máquina que el paralelo funciona antes de usarlo en un requerimiento real:

kb lote demo --modelo <id> --cantidad 3     # arma la demo en ~/kbspec-demo-lote
kb lote demo --modelo <id> --correr         # y la corre ya, con la CLI de Copilot
kb lote demo --limpiar

La demo arma su propio repositorio de documentación y de código con N tareas chicas e independientes (3 si no se dice, hasta 10), y fija esa carpeta a ellos con .kb/fijado.json: no toca la configuración real de la máquina. Sin --correr, se abre la carpeta en VS Code y la corre el agente kb-lote desde la ventana de agentes. Con --correr la autoriza quien la lanza, con un tope de 30 créditos (u otro con --hasta), y termina con el informe.