Azure DevOps

kbspec es nativo de Azure DevOps. Se configura una vez en aplicaciones/TABLERO.md: organización, proyecto, tipo de work item, revisores, el mapa de estados y sprint_dias.

Qué hace

Trae la tarea al requerimiento al crearlo (kb init, o kb solicitud para volver a traerla): la descripción, los criterios, el área y quién la pidió van al 01; también los comentarios del equipo —ahí se aclara lo que se pidió—, en orden y sin los de kbspec, y los adjuntos —y las imágenes pegadas en la descripción— a entradas/, con los mismos controles de datos sensibles que kb insumo. Si alguno no se puede bajar, no frena nada: se dice cuál y cómo registrarlo a mano.
Crea el work item del requerimiento (del tipo_requerimiento configurado) y una sub-tarea por fase —captura, requerimiento, análisis, plan, pruebas, UAT, entrega— más una por cada T-NN del plan.
Mueve los estados solos conforme avanza el ciclo: «en proceso» apenas una fase arranca, «cerrada» cuando el expediente avanza a la siguiente — nunca las dos cosas a la vez por la sola existencia del archivo, que nace vacío el mismo día que la fase empieza.
Al enviar el Pull Request nace su propia sub-tarea, que queda «en proceso» hasta la aprobación. Si el revisor pide cambios, esa misma sub-tarea y la de Pruebas vuelven a «en proceso» — nunca se duplican — y se cierran de nuevo al corregir.
La descripción del work item trae el vistazo del progreso actualizado en cada corrida: fase, tareas cerradas, documentos, bloqueos.
Formatea los tickets con tu KB_TICKET_PREFIX.

kb tablero check --escribir   # conecta el expediente con Azure DevOps
kb tablero sincronizar   # refleja el expediente en el tablero

El work item se resuelve, no se asume. El número del ticket NO es su id en DevOps: kbspec lo busca por título, lo enlaza (el wid: queda versionado en el 00) y lo crea si no existe — con las tareas de fase sembradas desde kb init, para que el líder vea el ciclo completo desde el día uno. Las sub tareas por T-NN llegan con el plan, y todo se sincroniza solo: al iniciar o cerrar una tarea, en cada kb publicar o kb cerrar, y al abrir, corregir o aprobar el Pull Request.

La credencial

Todo va por API REST, y la CLI busca con qué autenticarse en este orden:

El PAT de esa organización, si guardaste uno (ver abajo). Es lo más específico y por eso va primero.
Variables de entorno: KB_DEVOPS_BEARER, SYSTEM_ACCESSTOKEN (pipelines), AZURE_DEVOPS_EXT_PAT.
El login guardado. kb tablero login autentica por navegador (device code de Entra ID, sin az) y guarda el resultado en ~/.kb/devops-login.json —solo tu usuario lo lee— con su refresh token: se renueva solo y lo usa cualquier terminal. No se imprime ningún token ni hay nada que copiar. Es lo que Microsoft recomienda para una herramienta de línea de comandos.
La credencial que git ya tiene. Si desde esa máquina hiciste git push por https, el Credential Manager guardó una credencial para dev.azure.com/<org>; kb la toma prestada (git credential fill, sin abrir ningún diálogo). Es la fuente que casi siempre está.
La sesión de az, si az está instalado.

kb tablero login              # una vez por máquina; queda guardado y se renueva solo
kb integracion credenciales   # qué fuente hay y por qué no sirve, nunca el valor
kb integracion probar         # qué se puede y qué no, paso por paso

Cuando las tareas y el código están en organizaciones distintas

Los puntos 1 a 4 son globales: la primera credencial que aparece gana para todo. Si el tablero vive en una organización de Azure DevOps y los repositorios en otra —pasa, y más de lo que parece— un solo PAT no puede ser válido en las dos. El síntoma es que el mismo comando anda o no según a cuál organización le tocó hablar, y se confunde con un token vencido.

Un PAT por organización, y cada uno con el scope que le corresponde:

kb integracion credencial --tablero   # donde están las tareas y sub tareas
kb integracion credencial --codigo    # donde está el código y se hace el PR

El comando deduce la organización solo —la del tablero de TABLERO.md, la del código del remoto origin—, te dice de dónde sacar el PAT y qué scope necesita, lo lee sin mostrarlo, lo guarda en ~/.kb/devops-pats.json (solo tu usuario lo lee) y lo prueba en el acto contra esa organización.

No hay bandera para pasar el token en la línea de comandos: ahí quedaría en el historial de PowerShell y en el log de procesos. Se escribe sin eco, o llega por la entrada estándar.

kb integracion credencial --tablero --borrar   # sacarlo
kb integracion credenciales                    # cuál manda, y para qué organización

Por qué el push puede andar y el PR no. Son dos permisos —«Contribute» y «Contribute to pull requests»— y, hasta 3.152, dos credenciales: git tenía la suya y kbspec la de un login que vencía a la hora. kb integracion probar pregunta los permisos efectivos del repositorio en el proyecto del código (leer, push, crear ramas, crear PR) y lo dice con el permiso exacto que falta. Si nada sirve, kb pr imprime el formulario de crear PR ya prellenado, y cada llamada queda en la bitácora (kb integracion log).

Las sub tareas cuelgan del requerimiento. Cada fase y cada T-NN nace como hija del work item del requerimiento, nunca suelta, y hereda su iteración (el sprint) y su área: sin eso Azure DevOps las deja en la raíz del proyecto. Después de crearlas, kbspec comprueba que cuelguen de él. Su descripción va en HTML y el campo «Work item» de la ficha lleva el número de la propia tarea.

El sprint viaja en el expediente, y sale del work item. La iteración del requerimiento queda en el 00 (iteracion, sprint_nombre, sprint y las fechas del sprint) y se refresca en cada sincronización; kb estado la muestra. sprint_inicio en TABLERO.md (el día 1 del sprint 1) sigue sirviendo para los equipos sin ese dato, y kb estadisticas agrupa por sprint, mes o año.

El largo del sprint (sprint_dias) también lo usa el pronóstico por flujo.

Y wiki_url —la URL del wiki donde está publicada la documentación— es lo que hace que los Pull Requests enlacen la evidencia en vez de nombrar rutas de disco: el PR se revisa sin clonar. kb wiki la deduce del remoto y la deja escrita.

Tablero y código: dos destinos

Los work items viven en la organización y el proyecto de TABLERO.md. El código puede vivir en otro proyecto —o en otra organización—, y el Pull Request tiene que ir ahí: kbspec lo lee del remoto origin de cada copia local y kb pr imprime los dos destinos con su origen («← remoto origin», «← supuesto: el mismo proyecto que el tablero»). Cuando no puede saberlo, pide la URL en vez de adivinar:

kb tablero url https://dev.azure.com/ORG/Proyecto/_workitems/edit/123   # fija el TABLERO
kb tablero url https://dev.azure.com/ORG/Codigo/_git/Repo --codigo       # fija el CÓDIGO
kb pr --repositorio https://dev.azure.com/ORG/Codigo/_git/Repo           # solo esta vez

kb tablero check verifica los dos por separado: que el work item del expediente viva en el proyecto del tablero (leerlo funciona desde cualquier proyecto; crearle sub tareas, no), que el área y la iteración existan, y que cada repositorio del expediente esté en el proyecto del código. kb tablero sincronizar se niega antes de crear sub tareas huérfanas en el proyecto equivocado, y el error de permisos nombra la organización y el alcance que falta (Work Items para el tablero, Code para los PR).