Diferencias

Muestra las diferencias entre dos versiones de la página.

--- clase:daw:daw-proyecto:tema08 [2026/10/29 20:22] – Tests de API y E2E en tests/; quitar que CI pasa los tests claude
+++ clase:daw:daw-proyecto:tema08 [2026/11/04 10:16] (actual) – Prefijo do-/k- en las skills que escribe el alumno claude
@@ Línea 7: / Línea 7: @@
 **Por cada issue** (varios a la vez, cada uno en su worktree). Cada fase, en una conversación nueva:
-  - **Start.** ''/git-flow issue-create "título" "descripción"'' (''bug'' como tercer argumento; si no, ''feature''): lo crea en GitHub, en //Todo//, y responde con su número. ''/git-flow issue-start N'': rama, worktree y ''.env'' con sus puertos. ''cd'' al worktree y ''./devops-desktop.sh deploy''.
+  - **Start.** ''/do-git-flow issue-create "título" "descripción"'' (''bug'' como tercer argumento; si no, ''feature''): lo crea en GitHub, en //Todo//, y responde con su número. ''/do-git-flow issue-start N'': rama, worktree y ''.env'' con sus puertos. ''cd'' al worktree y ''./devops-desktop.sh deploy''.
-  - **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.
+  - **Specification.** Si es un CRUD, ''/do-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, ''./devops-desktop.sh deploy'' para recompilarlo. Probar en la URL del worktree.
+  - **Implementation.** ''/do-git-flow update'' y ''/do-sdd spec impl'' (CRUD) o ''/do-code impl plan_<algo>.md'' (resto). Si ha cambiado el backend, ''./devops-desktop.sh deploy'' para recompilarlo. 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, ''mvn package'', ''npm run test:api'' y ''npm run test:e2e'' (los dos últimos tras ''undeploy'', ''delete-db'' y ''deploy''). Si un cambio posterior rompe tests, ''/test <tipo> repair''.
+  - **Testing.** ''/do-test unit create'', ''/do-test api create <escenarios>'' y ''/do-test e2e create <escenarios>'' (''/do-test arch create <reglas>'' solo al empezar el proyecto o al cambiar una regla). Después, ''mvn package'', ''npm run test:api'' y ''npm run test:e2e'' (los dos últimos tras ''undeploy'', ''delete-db'' y ''deploy''). Si un cambio posterior rompe tests, ''/do-test <tipo> repair''.
-  - **Review & Finish.** ''/code review'' (lo revisa un subagente, nunca el que lo ha escrito). 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 update'' en el worktree y, desde la carpeta principal, ''/git-flow issue-finish N'': comprueba tareas, revisión y que la rama tiene ''develop'', pasa los tests en ella, fusiona en ''develop'' y cierra el issue.
+  - **Review & Finish.** ''/do-code review'' (lo revisa un subagente, nunca el que lo ha escrito). Leer ''review.md'', cerrar a mano los mejorables que no se hacen, y ''/do-code impl review.md''. Después ''/do-git-flow commit'' y ''/do-git-flow update'' en el worktree y, desde la carpeta principal, ''/do-git-flow issue-finish N'': comprueba tareas, revisión y que la rama tiene ''develop'', pasa los tests en ella, fusiona en ''develop'' y cierra el issue.
 **Cuando hay algo que sacar:**
-  - **Publish.** Antes, ''./devops-cloud.sh deploy develop'' en el ordenador local y probarla en su URL. ''/git-flow publish'': ''develop'' → ''main''. Después, ''./devops-cloud.sh deploy main'' en el servidor. Si no arranca, ''./devops-cloud.sh log main'' y preguntárselo al agente.
+  - **Publish.** Antes, ''./devops-cloud.sh deploy develop'' en el ordenador local y probarla en su URL. ''/do-git-flow publish'': ''develop'' → ''main''. Después, ''./devops-cloud.sh deploy main'' en el servidor. Si no arranca, ''./devops-cloud.sh log main'' 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 commit'', ''/code review''), como en ''docker login''. Lo que empieza por ''/'' es una skill; lo que acaba en ''.sh'', un script.
+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á (''/do-git-flow commit'', ''/do-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'' | ''issue-create "título" "descripción" [bug]'' | Crea el issue (''feature'' si no se dice ''bug''), lo pone en //Todo// con ''scripts/issue_create.sh'' y responde con su número |
+| ''/do-git-flow'' | ''issue-create "título" "descripción" [bug]'' | Crea el issue (''feature'' si no se dice ''bug''), lo pone en //Todo// con ''scripts/issue_create.sh'' y responde con su número |
 | | ''issue-start N'' | Rama ''<slug>-N'', worktree hermano y ''.env'' con puertos libres. No levanta la aplicación |
 | | ''commit'' | Agrupa los cambios por intención en commits con solo la descripción (el ''type(#N):'' lo pone ''issue-finish''), los hace sin preguntar y sube la rama a GitHub |
@@ Línea 38: / Línea 38: @@
 | | ''log <rama>'' | Últimas líneas del log del backend |
 | | ''delete-db <rama>'' | Con la aplicación parada, borra su base de datos. Nunca ''main'' |
-| ''/sdd'' | ''spec create'' | Solo para un CRUD: lee el issue de la rama y genera requisitos, diseño y tareas en ''.kiro/specs/slug-N/'' con cc-sdd. Se puede relanzar |
+| ''/do-sdd'' | ''spec create'' | Solo para un CRUD: lee el issue de la rama y genera requisitos, diseño y tareas en ''.kiro/specs/slug-N/'' con cc-sdd. Se puede relanzar |
 | | ''spec impl'' | Implementa las tareas pendientes de ''tasks.md''. Tests unitarios y de arquitectura tras cada una, y de API y E2E al acabar; si fallan, arregla su código |
-| ''/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 |
+| ''/do-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 |
 | | ''unit repair'' / ''arch 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'' | Un subagente revisor compara 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 |
+| ''/do-code'' | ''review'' | Un subagente revisor compara el código contra la spec, las convenciones y ''k-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''. Los mismos tests que ''spec impl'' |
-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''.
+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: ''k-convenciones-backend'', ''k-convenciones-frontend'' y ''k-calidad-codigo''.
 ===== Los comandos de tests, sin skill =====
-Los tests no los ejecuta ''/test'': se lanzan a mano.
+Los tests no los ejecuta ''/do-test'': se lanzan a mano.
 ^ Comando ^ Dónde ^ Qué pasa ^
@@ Línea 62: / Línea 62: @@
   * Tablero creado y un issue de prueba cerrado por ''issue-finish'' y en //Done//.
   * 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''.
+  * Dos CRUD hechos con ''/do-sdd'', iguales, y un issue que no es CRUD hecho con modo plan y ''/do-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 package''.
   * 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.
+  * ''/do-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 issue-finish'' se ha parado por uno abierto y ''/code impl'' lo ha corregido.
+  * ''/do-code review'' ha dejado hallazgos en ''review.md'', ''/do-git-flow issue-finish'' se ha parado por uno abierto y ''/do-code impl'' lo ha corregido.
   * Repositorio ''<proyecto>-devops'' con ''devops-cloud.sh'', ''devops-cloud.yaml'', ''compose.yaml'', los ''Dockerfile'' y ''nginx.conf''; ''develop'' probada en el ordenador local con ''./devops-cloud.sh deploy develop''.
   * ''main'' desplegada en el servidor con ''./devops-cloud.sh deploy main'' en su URL, y un segundo despliegue que conserva los datos.
-  * ''AGENTS.md'' con: comandos, dónde corren los tests, git solo con ''/git-flow'', ''.kiro/specs/'' es histórico.
+  * ''AGENTS.md'' con: comandos, dónde corren los tests, git solo con ''/do-git-flow'', ''.kiro/specs/'' es histórico.
 ===== Ejercicios =====
@@ Línea 80: / Línea 80: @@
 ==== Ejercicio 2 ====
-  * Elige un issue real de tu proyecto que no sea un CRUD y hazlo de principio a fin siguiendo solo esta página: ''issue-create'', ''issue-start'', plan, ''/code impl'', tests, ''/code review'', ''issue-finish'', ''publish'' y ''./devops-cloud.sh deploy main'' en el servidor. Comprueba el cambio en ''%%http://<alumno>.daw.cip.fpmislata.com%%''.
+  * Elige un issue real de tu proyecto que no sea un CRUD y hazlo de principio a fin siguiendo solo esta página: ''issue-create'', ''issue-start'', plan, ''/do-code impl'', tests, ''/do-code review'', ''issue-finish'', ''publish'' y ''./devops-cloud.sh deploy main'' en el servidor. Comprueba el cambio en ''%%http://<alumno>.daw.cip.fpmislata.com%%''.