8. Resumen

El arnés está montado. Esta página es la que se tiene abierta mientras se trabaja en la 2ª evaluación: el flujo en pasos, la gramática de los comandos y la lista de comprobación. La figura del ciclo está en el tema 1.

El flujo, en pasos

Por cada issue (varios a la vez, cada uno en su worktree). Cada fase, en una conversación nueva:

Start. /git-flow issue-create "título" "descripción" (bug como tercer argumento; si no, feature): lo crea en GitHub, en Todo, y responde con su número. /git-flow issue-start N: rama, worktree y .env con sus puertos. cd al worktree y ./devops-desktop.sh deploy.
Specification. Si es un CRUD, /sdd spec create; leer y corregir requirements.md (criterios comprobables, casos de error), design.md (igual que el CRUD de referencia) y tasks.md. Si no, modo plan: se le dice lo que se quiere y escribe plan_<algo>.md; salir del modo plan, leerlo y corregirlo. No se implementa en esa conversación.
Implementation. /git-flow update y /sdd spec impl (CRUD) o /code impl plan_<algo>.md (resto). Si ha cambiado el backend, ./devops-desktop.sh deploy para recompilarlo. Probar en la URL del worktree.
Testing. /test unit create, /test api create <escenarios> y /test e2e create <escenarios> (/test arch create <reglas> solo al empezar el proyecto o al cambiar una regla). Después, mvn package, npm run test:api y npm run test:e2e (los dos últimos tras undeploy, delete-db y deploy). Si un cambio posterior rompe tests, /test <tipo> repair.
Review & Finish. /code review (lo revisa un subagente, nunca el que lo ha escrito). Leer review.md, cerrar a mano los mejorables que no se hacen, y /code impl review.md. Después /git-flow commit y /git-flow update en el worktree y, desde la carpeta principal, /git-flow issue-finish N: comprueba tareas, revisión y que la rama tiene develop, pasa los tests en ella fusiona en develop y cierra el issue. CI en develop pasa lo mismo que acaba de pasar issue-finish.

Cuando hay algo que sacar:

Publish. Antes, ./devops-cloud.sh deploy develop en el ordenador local y probarla en su URL. /git-flow publish: develop → main. Después, ./devops-cloud.sh deploy main en el servidor. Si no arranca, ./devops-cloud.sh log main y preguntárselo al agente.

La gramática

Siempre familia, sustantivo y verbo, como docker container ls o gh issue create; el sustantivo se omite cuando es el issue en el que se está (/git-flow commit, /code review), como en docker login. Lo que empieza por / es una skill; lo que acaba en .sh, un script.

Familia	Subcomando	Qué hace
`/git-flow`	`issue-create "título" "descripción" [bug]`	Crea el issue (`feature` si no se dice `bug`), lo pone en Todo con `scripts/issue_create.sh` y responde con su número
	`issue-start N`	Rama `<slug>-N`, worktree hermano y `.env` con puertos libres. No levanta la aplicación
	`commit`	Agrupa los cambios por intención en commits con solo la descripción (el `type(#N):` lo pone `issue-finish`), los hace sin preguntar y sube la rama a GitHub
	`update`	Trae `develop` a la rama; si hay conflicto, se para y dice qué hacer
	`issue-finish N`	Desde la carpeta principal. Comprueba tareas, revisión y que la rama tiene `develop` (si no, pide `update`); tests en la rama; `--squash` en `develop`, push, cierra el issue y pasa la tarjeta a Done con `scripts/issue_close.sh`, `./devops-desktop.sh undeploy` y `delete-db`, borra el worktree
	`publish`	`develop` → `main` con `--ff-only` y push
`./devops-desktop.sh`	`deploy`	Compila y arranca la aplicación del worktree (la base de datos en Docker, el backend y el frontend en la máquina) con datos de prueba y dice su URL. Si ya estaba arrancada, la vuelve a compilar y arrancar
	`undeploy`	La para; los datos se quedan en `tmp/db`
	`status`	Si están arrancados la base de datos, el backend y el frontend
	`log`	Últimas líneas del log del backend
	`delete-db`	Con la aplicación parada, borra su base de datos: el siguiente `deploy` la crea con los datos de prueba
`./devops-cloud.sh`	`deploy <rama>`	Baja el código de la rama, construye las imágenes y levanta o actualiza la aplicación en contenedores, en la URL que tiene la rama en `devops-cloud.yaml`. Si no compila o falla un test, sigue la versión anterior. Nunca borra los datos
	`undeploy <rama>`	La para; los datos se quedan en su volumen
	`status <rama>`	Estado de los contenedores y si responde su URL
	`log <rama>`	Últimas líneas del log del backend
	`delete-db <rama>`	Con la aplicación parada, borra su base de datos. Nunca `main`
`/sdd`	`spec create`	Solo para un CRUD: lee el issue de la rama y genera requisitos, diseño y tareas en `.kiro/specs/slug-N/` con cc-sdd. Se puede relanzar
	`spec impl`	Implementa las tareas pendientes de `tasks.md`. Tests unitarios y de arquitectura tras cada una, y de API y E2E al acabar; si fallan, arregla su código
`/test`	`unit create` / `arch create <reglas>` / `api create <escenarios>` / `e2e create <escenarios>`	Genera los tests de ese tipo y los deja pasando. `unit` sin argumento, todas las clases sin tests; `arch`, al empezar el proyecto
	`unit repair` / `arch repair` / `api repair` / `e2e repair`	Por cada test roto decide si está mal el test o el código y arregla lo que toca; si no lo sabe, pregunta
`/code`	`review`	Un subagente revisor compara el código contra la spec, las convenciones y `calidad-codigo`; los tests contra los criterios de aceptación y `tests.md`. Cada hallazgo, una tarea en `review.md`. No bloquea
	`impl <plan>`	Hace las tareas pendientes de un plan: el `plan_<algo>.md` de un issue que no es CRUD, o `review.md`. Los mismos tests que `spec impl`

Fuera de la gramática, por ser de cc-sdd y usarse una vez: /kiro-steering y /kiro-steering-custom (tema 5). Y las skills de conocimiento, que no se invocan: convenciones-backend, convenciones-frontend y calidad-codigo.

Los comandos de tests, sin skill

Los tests no los ejecuta /test: se lanzan a mano.

Comando	Dónde	Qué pasa
`mvn package`	`backend/`	Unitarios y ArchUnit, dentro del build. No necesita nada levantado
`npm run test:api`	`frontend/`	Los de API contra la aplicación arrancada del worktree, con la base de datos recién borrada (antes, `undeploy`, `delete-db` y `deploy`). No forman parte del build
`npm run test:e2e`	`frontend/`	Lo mismo con los E2E

Listo para la 2ª evaluación

Antes de empezar el proyecto, todo esto tiene que estar hecho y comprobado:

Tablero creado y un issue de prueba cerrado por issue-finish y en Done.
Dos worktrees con la aplicación levantada a la vez, cada uno con sus datos.
Dos CRUD hechos con /sdd, iguales, y un issue que no es CRUD hecho con modo plan y /code impl.
Steering de cc-sdd con backend.md y frontend.md condicionales, y las skills de convenciones apuntando a ellos.
Tests ArchUnit con su descripción y unitarios pasando en mvn package.
Tests de API y E2E generados pasando en npm run test:api y npm run test:e2e.
/test <tipo> repair ha actualizado un test por un cambio intencionado y ha arreglado el código por una regresión.
/code review ha dejado hallazgos en review.md, /git-flow issue-finish se ha parado por uno abierto y /code impl lo ha corregido.
Repositorio <proyecto>-devops con devops-cloud.sh, devops-cloud.yaml, compose.yaml, los Dockerfile y nginx.conf; develop probada en el ordenador local con ./devops-cloud.sh deploy develop.
main desplegada en el servidor con ./devops-cloud.sh deploy main en su URL, y un segundo despliegue que conserva los datos.
AGENTS.md con: comandos, dónde corren los tests, git solo con /git-flow, .kiro/specs/ es histórico.

Ejercicios

Ejercicio 1

Repasa sobre tu repositorio la lista de arriba, «Listo para la 2ª evaluación». Lo que no cumpla, un issue y se arregla con el flujo.

Ejercicio 2

Elige un issue real de tu proyecto que no sea un CRUD y hazlo de principio a fin siguiendo solo esta página: issue-create, issue-start, plan, /code impl, tests, /code review, issue-finish, publish y ./devops-cloud.sh deploy main en el servidor. Comprueba el cambio en http://<alumno>.daw.cip.fpmislata.com.