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 tema 1.
Por cada issue (varios a la vez, cada uno en su worktree). Cada fase, en una conversación nueva:
/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 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./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./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./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:
/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.
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.
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 |
Antes de empezar el proyecto, todo esto tiene que estar hecho y comprobado:
finish./sdd, iguales, y un issue que no es CRUD hecho con modo plan y /code impl.backend.md y frontend.md condicionales, y las skills de convenciones apuntando a ellos.mvn test.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.develop.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.