====== 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 [[.:tema01#el_ciclo_de_vida_de_un_cambio|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.