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. Crearlo en GitHub y ponerlo en el tablero. /git-flow start N: rama, worktree y .env con sus puertos. cd al worktree y ./app.sh start.
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, ./app.sh start para reconstruirlo. 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, uno a uno, /test unit run, /test arch run, /test api run y /test e2e run. Si un cambio posterior rompe tests, /test <tipo> repair.
Review & Finish. /code review. 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 finish: comprueba tareas, revisión y tests; fusiona en develop y GitHub cierra el issue. CI en develop pasa lo mismo que acaba de pasar finish.

Cuando hay algo que sacar:

Publish. /git-flow publish: develop → main, CI, despliegue en el servidor, smoke test. Si sale en rojo, copiar el log del paso fallido 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 start, /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`	`start N`	Rama `<alumno>-N-<slug>`, worktree hermano y `.env` con puertos libres. No levanta la aplicación
	`commit`	Agrupa los cambios por intención en commits `type(#N): título` y los propone antes de hacerlos
	`update`	Trae `develop` a la rama; si hay conflicto, se para y dice qué hacer
	`finish`	Comprueba tareas, revisión y tests; `–squash` en `develop` con `Closes #N`, push, `./app.sh stop -v`, borra el worktree
	`publish`	`develop` → `main` con `–ff-only` y push: despliega
`./app.sh`	`start`	Levanta la aplicación del worktree reconstruyendo lo que ha cambiado y dice su URL. En el servidor, lo mismo con `COMPOSE_FILE=compose.yaml`
	`stop [-v]`	La para conservando los datos; con `-v` borra la base de datos
	`status`	Estado de sus contenedores
	`logs`	Últimas líneas de log de sus contenedores
`/sdd`	`spec create`	Solo para un CRUD: lee el issue de la rama y genera requisitos, diseño y tareas en `.kiro/specs/N-slug/` con cc-sdd. Se puede relanzar
	`spec impl`	Implementa las tareas pendientes de `tasks.md`, tests unitarios y de arquitectura tras cada una
`/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
	`arch run` / `unit run` / `api run` / `e2e run`	Los ejecuta, siempre un tipo cada vez, y explica el rojo
	`arch repair` / `unit 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`	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`. `/test unit run` tras cada una

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

Son los que ejecutan /test <tipo> run por dentro y CI sin ninguna IA:

Comando	Dónde	Qué pasa
`mvn test`	`backend/`	Unitarios y ArchUnit. No necesita nada levantado
`npm run test:api`	`frontend/`	Resetea la base de datos y pasa los de API contra la aplicación del worktree. 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 solo por el commit de finish.
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 test.
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 finish se ha parado por uno abierto y /code impl lo ha corregido.
CI en verde en develop.
Una publicación en main desplegada sola en http://<alumno>.proyectosdaw.cip.fpmislata.com.
AGENTS.md con: comandos, dónde corren los tests, git solo con /git-flow, .kiro/specs/ es histórico.