Diferencias

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

--- clase:daw:daw-proyecto:tema01 [2026/10/14 13:10] – «Fábrica» pasa a «arnés» / ingeniería de arneses (harness engineering, dicho en el tema 1); el día de trabajo en impersonal, sin Lorenzo; ejemplos con <alumno> claude
+++ clase:daw:daw-proyecto:tema01 [2026/10/14 14:08] (actual) – Tema nuevo «2. IA y agentes»: los temas 2 a 7 pasan a ser 3 a 8, con sus referencias cruzadas renumeradas claude
@@ Línea 43: / Línea 43: @@
 ==== 2. Specification ====
-Abre Claude Code en el worktree y pide la especificación del issue:
+Antes de escribir código, un fichero que diga qué se va a hacer. Hay **dos formas**, según el issue: la A, con una especificación, para los CRUD; la B, con un plan, para todo lo demás.
+=== Forma A: SDD ===
+El #12 es un CRUD (una entidad con su listado, alta, edición y borrado), así que va por especificación. Se abre Claude Code en el worktree y se pide:
 <code>
@@ Línea 68: / Línea 72: @@
 **Leer y corregir esos ficheros es el trabajo importante del día.** Arreglar una frase aquí cuesta un minuto; arreglar el código que sale de una frase mal escrita cuesta una tarde. Se añade un criterio que faltaba al de requisitos y se vuelve a lanzar ''/sdd spec create'': el diseño y las tareas se rehacen con el cambio. El diseño sale igual que el de los demás CRUD de la tienda, porque el agente lee antes la arquitectura del proyecto.
-El #12 es un CRUD, y por eso va por spec. El #13 de la tarde, un filtro por provincia en el listado, no lo es: ahí se pone el agente en **modo plan**, se le pide el cambio, y el agente lee el código y escribe un plan de tareas en ''plan_filtro-provincia.md'' sin tocar nada. Se lee y se corrige igual que la spec.
+=== Forma B: Plan ===
+Cuando el issue no es un CRUD (por ejemplo, el #13: un filtro por provincia en el listado de clientes), en vez de usar SDD se crea directamente un **plan**. Se pone el agente en **modo plan**, en el que solo lee y no toca código, y se le dice lo que se quiere y que escriba el plan en ''plan_filtro-provincia.md''. El agente lee el código, pregunta lo que no esté claro y deja en ese fichero la lista de tareas:
+<code>
+- [ ] 1. Backend: parámetro provincia en GET /api/clientes y filtro en ClienteRepository
+- [ ] 2. Frontend: desplegable de provincia en el listado, enlazado al parámetro
+</code>
+Al salir del modo plan, el fichero queda guardado en el worktree. Se lee y se corrige igual que la spec: que no falte una tarea y que cada una se pueda hacer y probar sola. Y aquí acaba la fase: el plan **no se implementa en esta conversación**. Si se hiciera, el contexto estaría lleno de todo lo que el agente ha leído para planificar, y eso empeora lo que programa después.
 ==== 3. Implementation ====
@@ Línea 78: / Línea 91: @@
 </code>
-Y una sola orden:
+Y una sola orden, que depende de la forma:
+=== Forma A: SDD ===
 <code>
@@ Línea 84: / Línea 99: @@
 </code>
-El agente va tarea a tarea: escribe la migración, las clases del backend en sus capas, el componente de Angular y los datos de prueba, siguiendo las **convenciones del proyecto** que tiene escritas. (Para el #13, lo mismo con ''/code impl plan_filtro-provincia.md''.) Después de cada tarea pasa los tests unitarios y de arquitectura y la marca como hecha en el fichero de tareas. Mientras tanto no se escribe código: se revisa lo que va saliendo.
+Implementa las tareas de la spec del worktree.
+=== Forma B: Plan ===
+<code>
+/code impl plan_filtro-provincia.md
+</code>
+Implementa las tareas del plan que se le pasa, en una conversación nueva que solo contiene el plan y el código que toca, no la planificación.
+En las dos el agente va tarea a tarea: escribe la migración, las clases del backend en sus capas, el componente de Angular y los datos de prueba, siguiendo las **convenciones del proyecto** que tiene escritas. Después de cada tarea pasa los tests unitarios y de arquitectura y la marca como hecha en el fichero de tareas. Mientras tanto no se escribe código: se revisa lo que va saliendo.
 Como el backend ha cambiado, lo reconstruye:
@@ Línea 96: / Línea 121: @@
 ==== 4. Testing ====
-Los tests también los escribe el agente, a partir de la spec:
+Los tests también los escribe el agente. Cuatro tipos, y para los cuatro los mismos tres verbos. Primero crearlos:
 <code>
-/test unit create ClienteService
+/test unit create
-/test api create Cliente
+/test arch create <reglas>
-/test e2e create
+/test api create <escenarios>
+/test e2e create <escenarios>
 </code>
-Salen los tests unitarios del servicio (uno por comportamiento), los de la API (cada endpoint, con sus errores) y los de extremo a extremo, uno por criterio de aceptación. Cada uno se ejecuta al crearlo y se deja pasando. Se vuelven a lanzar a mano, uno a uno, para verlo:
+  * ''unit create'': sin argumento, genera los tests unitarios de todas las clases que no los tienen, uno por comportamiento. Con una clase o un paquete, solo esos.
+  * ''arch create <reglas>'': recibe las reglas de arquitectura en castellano y las convierte en tests de ArchUnit. Se lanza al empezar el proyecto y cuando cambia una regla.
+  * ''api create <escenarios>'': recibe los escenarios que hay que probar en la API: cada endpoint con sus errores (alta válida, NIF repetido, sin nombre).
+  * ''e2e create <escenarios>'': recibe los escenarios de extremo a extremo; lo normal, los criterios de aceptación de la spec.
+Cada test se ejecuta al crearlo y se deja pasando.
+Después, lanzarlos a mano, uno a uno, para verlo:
 <code>
 /test unit run
+/test arch run
 /test api run
 /test e2e run
 </code>
-Todo en verde. Después abre ''%%http://localhost:4212%%'', da de alta un cliente, prueba un NIF repetido. El mensaje de error no le gusta y lo pide en la misma conversación. ''./app.sh start'' y listo. Pero el cambio del mensaje rompe el test E2E que comprobaba el texto antiguo:
+Todo en verde. Después se abre ''%%http://localhost:4212%%'', se da de alta un cliente, se prueba un NIF repetido. El mensaje de error no convence y se pide cambiarlo en la misma conversación. ''./app.sh start'' y listo. Pero el cambio del mensaje rompe el test E2E que comprobaba el texto antiguo. Para eso está el tercer verbo, uno por tipo:
 <code>
+/test unit repair
+/test arch repair
+/test api repair
 /test e2e repair
 </code>
-El agente mira por qué falla: el test está desactualizado por un cambio **intencionado** del código, así que actualiza el test. Si hubiera sido un error del código, habría arreglado el código y no el test. Y si no lo tuviera claro, no tocaría nada y preguntaría.
+Como lo que ha fallado es un test E2E, se lanza ''/test e2e repair''. El agente mira por qué falla: el test está desactualizado por un cambio **intencionado** del código, así que actualiza el test. Si hubiera sido un error del código, habría arreglado el código y no el test. Y si no lo tuviera claro, no tocaría nada y preguntaría.
 ==== 5. Review & Finish ====
@@ Línea 183: / Línea 220: @@
 | ''./app.sh'' | ''start'', ''stop'', ''status'', ''logs'' | La aplicación en Docker, en el worktree y en el servidor |
 | ''/sdd'' | ''spec create'', ''spec impl'' | La especificación del issue y su implementación |
-| ''/test'' | ''unit'', ''arch'', ''api'', ''e2e'', cada uno con ''create'', ''run'' o ''repair''. Siempre con el tipo delante: no hay un «todos» | Los cuatro tipos de tests |
+| ''/test'' | ''unit'', ''arch <reglas>'', ''api <escenarios>'', ''e2e <escenarios>'', cada uno con ''create'', ''run'' o ''repair''. Siempre con el tipo delante: no hay un «todos» | Los cuatro tipos de tests |
 | ''/code'' | ''review'', ''impl <plan>'' | El código del issue: revisarlo, y hacer las tareas de un plan: el ''plan_<algo>.md'' de un issue que no es CRUD, o ''review.md'' |
@@ Línea 193: / Línea 230: @@
 ^ Tema ^ Pieza ^ Lo que hace posible ^
-| 2 | Repositorio con instrucciones para el agente, tablero de issues y la skill ''/git-flow'' | Pasos 1, 5 y 6: ramas, worktrees, commits, cierre del issue, publicación |
+| 2 | Qué es un agente, Claude Code y OpenCode, skills, MCP, subagentes y bucles | El vocabulario con el que se entiende todo lo demás |
-| 3 | La aplicación en Docker, una copia por worktree, con datos de prueba, y el script ''app.sh'' | Paso 1: la aplicación propia en su puerto |
+| 3 | Repositorio con instrucciones para el agente, tablero de issues y la skill ''/git-flow'' | Pasos 1, 5 y 6: ramas, worktrees, commits, cierre del issue, publicación |
-| 4 | La skill ''/sdd'' sobre cc-sdd, ''/code impl'' para los planes y el steering con la arquitectura del proyecto | Pasos 2 y 3: especificar o planificar, y que el código salga como tiene que salir |
+| 4 | La aplicación en Docker, una copia por worktree, con datos de prueba, y el script ''app.sh'' | Paso 1: la aplicación propia en su puerto |
-| 5 | La skill ''/test'' y ''/code review'' | Pasos 4 y 5: los tests, la revisión y sus correcciones, y que ''finish'' pueda comprobar que todo está |
+| 5 | La skill ''/sdd'' sobre cc-sdd, ''/code impl'' para los planes y el steering con la arquitectura del proyecto | Pasos 2 y 3: especificar o planificar, y que el código salga como tiene que salir |
-| 6 | CI y despliegue automático, con el mismo ''app.sh'' | Pasos 5 y 6: CI en cada push, despliegue al publicar |
+| 6 | La skill ''/test'' y ''/code review'' | Pasos 4 y 5: los tests, la revisión y sus correcciones, y que ''finish'' pueda comprobar que todo está |
-| 7 | Resumen y lista de comprobación | Todo junto, para tenerlo a mano en la 2ª evaluación |
+| 7 | CI y despliegue automático, con el mismo ''app.sh'' | Pasos 5 y 6: CI en cada push, despliegue al publicar |
+| 8 | Resumen y lista de comprobación | Todo junto, para tenerlo a mano en la 2ª evaluación |
 Las **skills** son las instrucciones que le dicen al agente cómo se hace cada cosa en este proyecto. Las escribe el alumno durante el trimestre, con ayuda del propio agente, y son lo que convierte una lista de pasos en una sola orden. Lo que no necesita inteligencia (arrancar, parar, ver los logs) no es una skill: es un script.
@@ Línea 204: / Línea 242: @@
 ===== Herramientas =====
-Todo esto tiene que estar instalado y funcionando antes del tema 2:
+Todo esto tiene que estar instalado y funcionando antes del tema 3:
-  * **git** y **gh** (la CLI de GitHub) autenticado: ''gh auth status'' debe decir que estás conectado. En Windows, Git se instala con las opciones del tema 2, que traen **bash**: el script del proyecto es de bash y funciona igual en los tres sistemas.
+  * **git** y **gh** (la CLI de GitHub) autenticado: ''gh auth status'' debe decir que estás conectado. En Windows, Git se instala con las opciones del tema 3, que traen **bash**: el script del proyecto es de bash y funciona igual en los tres sistemas.
   * **Docker** con Docker Compose: ''docker compose version''.
   * **JDK 25** y **Maven**: ''mvn -v''.
@@ Línea 222: / Línea 260: @@
 ==== Ejercicio 2 ====
   * Crea en GitHub el repositorio de tu proyecto, vacío, con ''README'' y ''.gitignore''. Es el que se usa en todo el módulo.
-  * Clónalo y pide al agente que genere en ''backend/'' un Spring Boot con Maven y Java 25, **sin JPA** (la base de datos llega en el tema 3), con un ''GET /api/hola'' que devuelva un texto, y en ''frontend/'' un Angular que lo llame y lo muestre.
+  * Crea el tablero del proyecto: en GitHub, menú ''+'' de arriba a la derecha → //New project// → //Start from scratch// → plantilla **Board** → nombre del proyecto → //Create//. Salen las tres columnas, //Todo//, //In Progress// y //Done//. Después, en la pestaña //Projects// del repositorio, //Link a project// para enlazarlo.
+  * Clónalo y pide al agente que genere en ''backend/'' un Spring Boot con Maven y Java 25, **sin JPA** (la base de datos llega en el tema 4), con un ''GET /api/hola'' que devuelva un texto, y en ''frontend/'' un Angular que lo llame y lo muestre.
   * Arranca los dos a mano, ''mvn spring-boot:run'' y ''ng serve'', y comprueba en el navegador que el texto aparece.
   * Haz commit y push. En este tema los commits se hacen a mano: ''/git-flow'' llega en el siguiente.