GitHub

Desde 3.153.0 el tablero puede ser los issues de un repositorio de GitHub, y el código puede vivir en GitHub aunque el tablero esté en Azure DevOps. Es la misma cadena —kb init lee el ticket, kb publicar sincroniza, kb pr crea el Pull Request— con las traducciones adentro: la capa de integraciones elige el cliente por plataforma y kb.py no sabe con quién habla.

Configurar

kb tablero url https://github.com/<owner>/<repo>   # plataforma: github, organizacion, proyecto
kb tablero check --escribir                        # el mapa de etapas: open / closed
kb integracion probar                              # qué se puede y qué no

En aplicaciones/TABLERO.md: plataforma: github, organizacion es la cuenta u organización (owner) y proyecto el repositorio. tipo_requerimiento y tipo_tarea se conservan como etiquetas; revisores son logins de GitHub, o org/equipo para un equipo.

Qué se traduce

Azure DevOps	GitHub
Work item del requerimiento	Issue, buscado por título
Sub tarea (enlace jerárquico)	Sub-issue colgado del principal
Tipo de work item	Etiqueta (`Task`, `Story`…)
Estados del proceso	`open` / `closed`
Iteración (el sprint)	El milestone, por su título: el sprint del requerimiento llega al expediente —con la fecha de vencimiento como fin— y las sub tareas lo heredan. Uno que no existe no se crea
Área	No existe; se ignora
Revisores del PR (identidades)	Logins; equipos como `org/equipo`
Adjuntos del PR (capturas incrustadas)	No hay API: las capturas quedan enlazadas
Enlace work item ↔ PR	`Work item: #N` en el cuerpo del PR
Hilos de revisión del PR (`kb pr hilos`)	Los comentarios sobre el código —con su archivo y su línea—, el texto de cada revisión y la conversación; la respuesta va dentro del hilo y el hilo se resuelve (GraphQL)
Adjuntos de la tarea (`kb init` los trae a `entradas/`)	Los enlaces de `github.com/user-attachments/…` en el issue y sus comentarios, bajados con la credencial solo hacia GitHub

La credencial

En orden: KB_GITHUB_TOKEN / GITHUB_TOKEN / GH_TOKEN, la sesión de gh (gh auth token), o la credencial que git ya tiene para github.com (la del push). Con gh auth login alcanza. Un token fino necesita issues y pull_requests de lectura y escritura (o repo en uno clásico). kb integracion probar dice si el repositorio se ve, si hay permiso de escritura y si los revisores existen; kb integracion log tiene cada llamada.

Tablero en Azure DevOps, código en GitHub

El destino del código sale del remoto origin de cada repositorio: si es github.com, el PR va por la API de GitHub aunque el tablero sea Azure DevOps, cada destino con su plataforma y su credencial. Sin remoto que lo diga, kb tablero url <URL del repositorio> --codigo lo deja fijo (codigo_plataforma: github). Un work item de Azure DevOps no se enlaza a un PR de GitHub —no existe el vínculo— y kb pr lo dice.