Configurar kbspec conversando

Instalado kbspec, falta decirle qué aplicaciones hay, dónde está su código, dónde viven los tickets y con qué se prueba. No hace falta llenarlo a mano: se hace conversando, en el chat, y se puede dejar a medias.

/kb-configurar

O el botón Configurar kbspec de la pestaña Puesta a punto del panel, que abre un chat nuevo con eso escrito.

Cómo es la conversación

1. Te pide la carpeta donde están las aplicaciones —la que las contiene a todas, o la de una sola si preferís empezar por esa— y la escanea (kb configuracion descubrir).

2. Te muestra lo que encontró, cada cosa con de dónde sale y con qué certeza:

   Lo que propone	De dónde lo saca
   Cada aplicación, sus módulos y sus componentes	angular.json, las soluciones .sln, los manifiestos, los nombres de los repositorios
   Qué hace cada una	la descripción del package.json o del csproj, o el primer párrafo del README
   Con qué está hecha	Angular y su versión, el kit de UI, .NET, SQL Server, Node, la autenticación que declara
   Con qué se prueba	Karma, Jest, Vitest, xUnit, NUnit; Playwright o Cypress si ya están configurados
   Quién responde	CODEOWNERS; si no hay, quienes más commitearon (solo orienta)
   Dónde viven los tickets	los remotos de git: Azure DevOps o GitHub, organización y proyecto
   El prefijo de los tickets	las ramas Feature/REQ-… y los commits
   Cómo ramifican	Release/PN-…, develop

3. Pregunta solo lo que el código no sabe, de a una y con la respuesta sugerida: cómo le dice el negocio a la aplicación, qué hace y para quién, quién responde por ella, la clasificación de sus datos. Lo que un manifiesto declara se confirma de a varios con un «sí».

4. Escribe cada respuesta apenas la confirmás, con los mismos comandos que usarías a mano: el inventario, la ficha de arquitectura, la guía funcional, la estrategia de pruebas.

Se puede dejar a medias

Lo confirmado queda escrito en el repositorio de documentación. kb configuracion —o la pestaña Puesta a punto— dice lo que falta y, arriba, lo que falta para poder empezar un requerimiento: solo lo que bloquea (el repositorio de documentación y la aplicación del requerimiento en el inventario). Lo demás —estándares, E2E, la guía de cada aplicación— se completa cuando quieras, con /kb-configurar de nuevo o con el «Completar con IA» de cada ítem.

Las credenciales

Para crear las tareas del tablero y abrir el Pull Request, kbspec necesita actuar en tu nombre. La conversación te explica qué es cada credencial y dónde se saca, pero nunca la pide en el chat: la guardás vos, en tu terminal.

• Lo recomendado: kb integracion login en Azure DevOps (entrás con tu SSO desde el navegador, se renueva solo y kbspec nunca ve tu contraseña), o gh auth login en GitHub.
• Con un PAT (Personal Access Token, una contraseña de uso limitado que creás vos): en Azure DevOps se saca en tu avatar → Personal access tokens → New Token. Para el tablero, Work Items (Read & Write); para el código, Code (Read & Write) y Pull Request Threads (Read & Write). Si el tablero y el código viven en organizaciones distintas, hace falta uno para cada una. Se guarda con kb integracion credencial --tablero y --codigo, sin mostrarse y sin quedar en el historial.

Los cuatro modos

Modo	Para qué	Botón del panel
/kb-configurar	El recorrido completo: documentación, tablero, credenciales, aplicaciones, pruebas	Configurar kbspec
/kb-configurar app	Una aplicación que ya tiene código y todavía no está en kbspec	Configurar una app
/kb-configurar app nueva	Una aplicación, un módulo o un componente que todavía no existe	App nueva
/kb-configurar <ítem>	Un punto de la puesta a punto: credenciales, fichas, guia-funcional, un estándar, las E2E…	«Completar con IA» en cada ítem

Una aplicación que todavía no existe

Un requerimiento puede ser sobre algo que todavía no tiene código: una aplicación nueva, o un módulo o componente nuevo de una que existe. La conversación:

1. Verifica que de verdad sea nueva (kb apps nueva <nombre>): la busca en el inventario —por código, apodo, módulo y aplicación— y en tu copia del código. Casi siempre «la app nueva» ya existe con otro nombre.
2. Captura lo que hay que decidir, proponiendo lo que el equipo ya usa: qué hace y para quién, módulos, responsables, clasificación, si se parece a otra aplicación (para copiar su ficha), la plataforma, las pruebas y cada componente con el repositorio que va a tener —de ahí salen las ramas—.
3. Te muestra lo que va a escribir y, con tu sí, lo escribe: el inventario con sus componentes en estado por crear, la ficha de arquitectura con lo decidido —rotulada como propuesta, con lo que falta decidir— y la portada de su guía funcional.

Cuando el código existe: kb apps editar <CÓDIGO> --estado activo y kb arquitectura --aplicar.

En la terminal

Lo mismo, sin conversación:

kb configuracion descubrir ~/repos                 # lo que se infiere, con certeza y preguntas
kb configuracion descubrir ~/repos --app ventas --json
kb configuracion                                   # la puesta a punto y lo que falta para empezar
kb configuracion --prefijo REQ                     # el prefijo de los tickets
kb apps nueva COBROS                               # ¿de verdad es nueva?
kb apps nueva --desde captura.json [--aplicar]     # darla de alta con lo decidido