Aplicaciones nuevas y épicas

Para quien desarrolla, una aplicación nueva se trabaja igual que una que existe: escribe el pedido en el chat y KB decide. kbspec resuelve lo que cambia.

El camino lo decide kbspec

Antes de crear el expediente, el agente consulta kb camino con lo que leyó del pedido:

kb camino --aplicacion COBROS --modulos 3 --pantallas 9 --json

Responde si la aplicación existe, está por crear o no está —y a cuáles se parece—, si tiene una épica con partes libres, el tamaño (XS, S, M, L o ÉPICA) con su porqué y los pasos antes de empezar. La regla es la misma para todo el equipo. Propone; decide la persona: si el developer ya dijo «es una app nueva», «es una épica» o «hacelo como un L», eso manda (--nueva, --epica, --tamano).

Una aplicación nueva: lo decidido, por escrito

La captura (/kb-configurar app nueva) pregunta de a una cosa, proponiendo lo que el equipo ya usa: qué hace, módulos, stack, componentes con su repositorio, pruebas, despliegue, datos, no funcionales e integraciones. Lo que no esté decidido, el agente lo recomienda con dos o tres opciones y lo que cuesta cada una. Queda en la ficha, con lo que falta decidir.

kb arquitectura COBROS --ver     # la página: componentes, plataforma, lo decidido y lo que falta

La épica: partes que se entregan solas

kb epica crear EP-0001 "Cobros" --aplicacion COBROS
kb epica EP-0001 partes --desde partes.json --aplicar
kb epica EP-0001 revisar

• Cada parte funciona sola cuando se cierra: se corre, se prueba y se le muestra a quien la usa, sin esperar al resto. Su 01 lo dice desde que nace.
• P-01 es el cimiento de una aplicación sin código: compila, corre, se despliega y se prueba, sin negocio.
• Cortes verticales, no capas: «el ejecutivo registra un cobro» y no «las tablas».
• PR chicos: partes S o M, que se revisan en una sentada.

Los fundamentos, en el inventario

En la épica de una aplicación nueva se decide todo lo que hace falta para empezar a programar: stack y versiones, componentes y repositorios, arquitectura y patrones, base de datos, autenticación y roles, el diseño de la interfaz, estándares, pruebas y despliegue. El agente recomienda, el developer ajusta y queda escrito en el inventario —la ficha de la app, su interfaz.md, los estándares—, donde lo lee cada requerimiento y lo usan los demás developers. La persona lo aprueba; sin eso ninguna parte aprueba su análisis técnico.

kb epica EP-0001 fundamentos              # qué está decidido y qué falta
kb epica EP-0001 interfaz --ver           # la guía visual: el marco y los componentes
kb epica EP-0001 fundamentos --aprobar    # lo confirma la persona

Un requerimiento por parte

kb epica EP-0001 requerimientos --pase PN-00142 --tickets P-02=REQ-123456 --temporales --aplicar
kb abrir REQ-123456        # lo toma quien lo vaya a trabajar

Cada parte nace como su requerimiento —con su ticket, el alcance de su parte y su PR—, por tomar. Varios a la vez, de distintos developers: kb epica EP-0001 dice quién tiene cuál. Sin número todavía, un temporal por parte que pasa al real con kb renombrar.

Verla antes de construirla: el prototipo de cada requerimiento

• Cada requerimiento tiene su prototipo —uno o varios—, con el alcance de su parte y dentro de la guía visual de la app: kb prototipo --brief --nombre <qué es>.
• Lo aprueba ese requerimiento: la persona escribe «aprobado prototipo». kb epica EP-0001 prototipo muestra cómo va el de cada parte.

En el tablero

Épica → requerimientos (sus partes) → tareas. La épica es un work item (kb epica EP-0001 tablero --wid N o --crear) y cada requerimiento cuelga de él, con sus tareas debajo. Cuando se finaliza la última parte, la épica queda entregada sola: su estado, su retrospectiva y su work item cerrado.

El repositorio y lo que sigue

kb apps repo COBROS-API --crear    # la carpeta con git, un primer commit y kbspec

El repositorio en el servidor lo crea la persona. Si un requerimiento crece de más, kb partir lo vuelve épica.