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 aplicación levantada en sus puertos.
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.
Probar en la URL del worktree (/app-arrancar la dice).
/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.

Los tres comandos de tests

Comando	Dónde	Qué pasa
`mvn test`	`backend/`	Unitarios y ArchUnit. No necesita nada levantado
`mvn verify -Papi -DDB_PORT=<puerto>`	`backend/`	Los de API, contra la base de datos del worktree. No forman parte del build
`npm run e2e`	`frontend/`	Resetea la base de datos y pasa los E2E contra la aplicación del worktree

Chuleta de skills

Skill	Para qué
`/git-flow iniciar N`	Empezar un issue: rama, worktree, `.env` con puertos y aplicación levantada
`/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
`/app-arrancar`	Levantar la aplicación del worktree y decir su URL
`/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 REST Assured 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
`/crud <Entidad>`	CRUD completo igual que el de referencia
`/ci-revisar`	Seguir el workflow y diagnosticar si falla
`convenciones-backend`, `convenciones-frontend`	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; de API en mvn verify -Papi.
Tests E2E generados pasando en npm run e2e.
/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.