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). Cada fase, en una conversación nueva:

Empezar el issue. 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.
Especificar. /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.
Implementar. /sdd spec impl. Si ha cambiado el backend, ./app.sh start para reconstruirlo. Probar en la URL del worktree.
Probar. /test unit create <Servicio>, /test api create <Entidad> y /test e2e create. Después, uno a uno, /test unit run, /test api run y /test e2e run. Si un cambio posterior rompe tests, /test <tipo> repair.
Revisar. /code review. Leer review.md, cerrar a mano los mejorables que no se hacen, y /code impl review.md.
Finalizar. /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:

Publicar. /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`	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`	`arch create` / `unit create <Clase>` / `api create <Entidad>` / `e2e create`	Genera los tests de ese tipo y los deja pasando. `arch`, una vez por 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 fichero markdown que no es la spec: `review.md` o un plan escrito a mano. `/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 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 <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.
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.