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 chuleta de las skills y la lista de comprobación. El diagrama del flujo con quién hace cada cosa está en el tema 1.

El flujo, en pasos

Por cada issue (varios a la vez, cada uno en su worktree):

Crear el issue en GitHub y ponerlo en el tablero.
/git-flow iniciar N: rama, worktree y .env con sus puertos. cd al worktree y ./arrancar.sh.
Modo plan: decir qué se quiere, pedir que pregunte, revisar el plan. Sale planes/N-slug.md.
/clear y Ejecuta @planes/N-slug.md. Si el issue es un CRUD, /crud <Entidad> y nada más.
Los tests: /crear-test-unitarios para el dominio que haya cambiado, /crear-test-api para los endpoints nuevos y /crear-test-e2e planes/N-slug.md. Y /crear-test-arquitectura si hay reglas nuevas. Si el issue era un CRUD, /crud ya los ha generado.
Pasar los tests: npm run api-test y npm run e2e-test. Probar en la URL del worktree; si ha cambiado el backend, ./arrancar.sh antes.
/git-flow commit.
/git-flow finalizar: pasa /revisar; si no hay nada grave, fusiona en develop y GitHub cierra el issue. CI en verde.

Cuando hay algo que sacar:

/git-flow publicar: develop → main, CI, despliegue en el servidor, smoke test.
Si algo sale en rojo, /ci-revisar.

De vez en cuando (tras un /crud, antes de publicar): /revisar-calidad sobre el paquete o el backend entero, y corregir los graves.

Scripts y comandos

Comando	Dónde	Qué hace
`./arrancar.sh`	raíz del worktree	Levanta la aplicación del worktree (reconstruyendo lo que ha cambiado) y dice su URL
`./parar.sh`	raíz del worktree	La para conservando los datos; con `-v` borra la base de datos

Los tres comandos de tests

Comando	Dónde	Qué pasa
`mvn test`	`backend/`	Unitarios y ArchUnit. No necesita nada levantado
`npm run api-test`	`frontend/`	Resetea la base de datos y pasa los de API contra la aplicación del worktree. No forman parte del build
`npm run e2e-test`	`frontend/`	Lo mismo con los E2E

Chuleta de skills

Skill	Para qué
`/git-flow iniciar N`	Empezar un issue: rama, worktree y `.env` con puertos
`/git-flow commit`	Agrupar los cambios en commits con sentido, `type(#N):título`
`/git-flow actualizar`	Traer `develop` a la rama
`/git-flow finalizar`	Revisar, fusionar en `develop` con `Closes #N`, push, parar contenedores y borrar el worktree
`/git-flow publicar`	`develop` → `main`: despliega
`/crear-test-arquitectura`	Reglas en castellano → tests ArchUnit con descripción
`/crear-test-unitarios <clase>`	Un test JUnit por comportamiento del dominio, con Mockito
`/crear-test-api <Entidad>`	Un test Playwright por endpoint y por error previsto
`/crear-test-e2e <plan>`	Criterios de aceptación → tests Playwright pasando
`/revisar`	Diff contra el plan y las convenciones, grave / mejorable
`/revisar-calidad <ruta>`	Informe de calidad del código con las reglas de `calidad-codigo`; no toca nada
`/crud <Entidad>`	CRUD completo igual que el de referencia
`/ci-revisar`	Seguir el workflow y diagnosticar si falla
`convenciones-backend`, `convenciones-frontend`, `calidad-codigo`	No se invocan: el agente las carga al tocar código

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 finalizar.
Dos worktrees con la aplicación levantada a la vez, cada uno con sus datos.
Un CRUD hecho con el flujo de plan y un segundo con /crud.
convenciones-backend y convenciones-frontend escritas a partir del primer CRUD.
Tests ArchUnit con su descripción y unitarios pasando en mvn test.
Tests de API y E2E generados pasando en npm run api-test y npm run e2e-test.
/git-flow finalizar se para ante una revisión con algo grave.
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, planes/ es histórico.