Dos requerimientos a la vez

Se puede llevar más de un requerimiento a la vez, y además seguir con lo tuyo —un arreglo urgente, cambios sin subir— en los mismos repositorios. La regla de kbspec es cada requerimiento en su ventana de VS Code y en su propia carpeta. No hace falta acordarse de nada: se le dice al agente «abrí también el REQ-0031000» y kbspec decide dónde va.

Cada uno en su ventana

Si el requerimiento toca varios repositorios —o VS Code está abierto en la carpeta que los junta a todos—, kb init y kb abrir arman su workspace y lo abren en una ventana nueva. Si la ventana de VS Code está vacía, lo abren ahí mismo; con algo abierto, el segundo requerimiento siempre va en su propia ventana. En esa ventana:

la primera carpeta es el expediente, y ahí vive la sesión del requerimiento. La terminal de esa ventana opera ese requerimiento aunque la carpeta de la documentación —que está en los workspaces de todos— tenga la sesión de otro;
antes de implementar, cada repositorio es una copia de lectura en la rama base (~/.kb/lectura/<TICKET>/; en Windows, C:\kbw\lectura\<TICKET>\): se lee lo que está en producción, y no se puede escribir;
al implementar, la ventana pasa sola a la carpeta del requerimiento.

Al implementar: su propia carpeta

Desde 3.205.0, cada requerimiento nuevo trabaja su código en su carpeta: un git worktree por repositorio, con la rama del ticket, todos juntos.

C:\Codigo\frontend\          ← tu copia: la rama que quieras, tus cambios
C:\Codigo\backend\           ← tu copia
C:\kbw\REQ-0031000\frontend\ ← la carpeta del requerimiento, Feature/REQ-0031000
C:\kbw\REQ-0031000\backend\  ← la carpeta del requerimiento, Feature/REQ-0031000
C:\kbw\REQ-0031001\frontend\ ← el otro requerimiento, Feature/REQ-0031001

Tu copia no se toca: ni su rama ni lo que tenga sin commitear. Un arreglo urgente en tu copia y dos requerimientos conviven sin cruzarse.
La raíz es corta —C:\kbw en Windows (o %USERPROFILE%\kbw si ahí no se puede crear), ~/kbw en macOS y Linux— por el límite de 260 caracteres que un node_modules hondo alcanza rápido. KB_ARBOLES la cambia en una máquina; arboles en la sección «Trabajo» de CICLO.md, para el equipo.
La configuración local viaja. Un árbol nace solo con lo versionado: kbspec copia de tu copia la configuración que git ignora y la app necesita para correr (.env, appsettings.*.json, *.local.*, local.settings.json, .npmrc) y lo dice. La ficha de la app amplía la lista (| al_arbol | … |) o la apaga (| al_arbol | ninguno |), y puede declarar lo que se corre una vez en el árbol nuevo (| preparar | npm ci |). Si igual falla un comando, kb pruebas dice qué tiene tu copia que el árbol no, y kb ramas --traer .env lo trae.
La sesión, kbspec y la rama. La carpeta nace con kbspec adentro y su rama se publica en el remoto. Si la rama ya la trabajó otra persona, se toma la del remoto.
La compuerta no deja que el agente escriba el código del requerimiento en tu copia ni en la carpeta de otro requerimiento: la negativa dice la misma ruta en la carpeta correcta.
Una app que no admite un segundo árbol (una ruta fija de IIS, por ejemplo) se queda en la copia con | trabajo | copia | en su ficha.

Los requerimientos que empezaron antes de 3.205.0 terminan como empezaron, en la copia, con kb ramas y kb paralelo de siempre. Un requerimiento nuevo puede pedir lo mismo con kb init … --en-la-copia.

Pases distintos, bases distintas

REQ-0031000 (PN-005) → main → Release/PN-005 → Feature/REQ-0031000
REQ-0031001 (PN-007) → main → Release/PN-007 → Feature/REQ-0031001

Cada carpeta nace de su base y el trabajo no se cruza. kbspec crea la cadena intermedia si falta, sin mover tu copia.

Cuando el pase avanza

Si otro ticket del mismo pase se integró después y tocó lo mismo, el PR no se podría completar. kbspec lo ve antes:

kb ramas dice cuánto avanzó el pase y si el merge chocaría, en qué archivos (lo simula sin tocar nada);
kb pr no arma un PR que chocaría (--forzar lo arma igual);
kb ramas --traer-pase trae lo nuevo del pase a la carpeta del requerimiento. Si choca, el merge queda ahí para resolverlo, con los archivos nombrados y cómo deshacerlo.

El consumo de cada uno

El consumo se reparte por conversación y por carpeta: lo de la ventana de agentes que corrió en la carpeta de un requerimiento es de ese, y cada conversación del chat de VS Code es del requerimiento de su ventana. Con dos abiertos, lo de uno no se le carga al otro.

¿Por qué una ventana y no otro chat?

Porque lo que se comparte no es el chat, es el disco:

	Chat nuevo, misma ventana	La ventana del requerimiento
Sesión	La misma — los dos escriben al mismo expediente	Una cada uno, en su expediente
Rama de Git activa	La misma	Una cada uno, en su carpeta
Archivos y build	Compartidos	Aislados

Al cerrar y al terminar

«cerrá por hoy» (kb cerrar) suelta el requerimiento y deja el otro como estaba.
«finalizá» (kb finalizar) borra su workspace y sus copias de lectura, y quita sus carpetas si están limpias y con todo publicado —y la del ticket, si quedó vacía—. Una con algo sin commitear o sin subir, o en la que estás parado, queda, y se dice. La rama nunca se borra: el trabajo vive en ella.
kb paralelo --cerrar REQ-0031000 publica lo pendiente y quita sus carpetas cuando quieras.