7. Resumen

La fábrica está montada. 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). /clear al empezar cada paso:

Crear el issue 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.
/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 se cambia algo, volver a generar.
/sdd spec impl. Si ha cambiado el backend, ./app.sh start para reconstruirlo. Probar en la URL del worktree.
/test create unit <Servicio>, /test create api <Entidad> y /test create e2e. Después /test run all. Si un cambio posterior rompe tests, /test repair <tipo>.
/developer review code y /developer review test. Leer review.md; las correcciones ya están en tasks.md: /sdd spec impl.
/git-flow commit.
/git-flow finish: comprueba tareas, revisión y tests; fusiona en develop y GitHub cierra el issue. CI en develop; si sale en rojo, /developer review ci.

Cuando hay algo que sacar:

/git-flow publish: develop → main, CI, despliegue en el servidor, smoke test. Si sale en rojo, /developer review ci.

La gramática

Siempre familia, verbo y objeto. 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`	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`	`create arch` / `unit <Clase>` / `api <Entidad>` / `e2e`	Genera los tests de ese tipo y los deja pasando. `arch`, una vez por proyecto
	`run arch` / `unit` / `api` / `e2e` / `all`	Los ejecuta y explica el rojo
	`repair arch` / `unit` / `api` / `e2e` / `all`	Por cada test roto decide si está mal el test o el código y arregla lo que toca; si no lo sabe, pregunta
`/developer`	`review code`	Diff contra la spec, las convenciones y `calidad-codigo`. Escribe `review.md` y añade los graves a `tasks.md`. No bloquea
	`review test`	Los tests contra los criterios de aceptación y `tests.md`. Lo que falta, a `tasks.md`
	`review ci`	Lee el workflow fallido en GitHub y explica la causa

Fuera de la gramática, por ser de cc-sdd y usarse una vez: /kiro-steering y /kiro-steering-custom (tema 4). 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 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.
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 repair ha actualizado un test por un cambio intencionado y ha arreglado el código por una regresión.
/developer review code ha dejado hallazgos en review.md y tareas en tasks.md, y /git-flow finish se ha parado por uno abierto.
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.