diff --git a/docs/assets/images/specs-customer-free_1.png b/docs/assets/images/specs-customer-free_1.png new file mode 100644 index 0000000..6c8067e Binary files /dev/null and b/docs/assets/images/specs-customer-free_1.png differ diff --git a/docs/assets/images/specs-customer-free_2.png b/docs/assets/images/specs-customer-free_2.png new file mode 100644 index 0000000..b7ec543 Binary files /dev/null and b/docs/assets/images/specs-customer-free_2.png differ diff --git a/docs/assets/images/specs-customer-free_3.png b/docs/assets/images/specs-customer-free_3.png new file mode 100644 index 0000000..e587f64 Binary files /dev/null and b/docs/assets/images/specs-customer-free_3.png differ diff --git a/docs/assets/images/specs-customer-free_4.png b/docs/assets/images/specs-customer-free_4.png new file mode 100644 index 0000000..ce918a4 Binary files /dev/null and b/docs/assets/images/specs-customer-free_4.png differ diff --git a/docs/assets/images/specs-customer-paid_1.png b/docs/assets/images/specs-customer-paid_1.png new file mode 100644 index 0000000..e9def68 Binary files /dev/null and b/docs/assets/images/specs-customer-paid_1.png differ diff --git a/docs/assets/images/specs-customer-paid_2.png b/docs/assets/images/specs-customer-paid_2.png new file mode 100644 index 0000000..dfab048 Binary files /dev/null and b/docs/assets/images/specs-customer-paid_2.png differ diff --git a/docs/assets/images/specs-customer-paid_3.png b/docs/assets/images/specs-customer-paid_3.png new file mode 100644 index 0000000..25a4dcf Binary files /dev/null and b/docs/assets/images/specs-customer-paid_3.png differ diff --git a/docs/assets/images/specs-customer-paid_4.png b/docs/assets/images/specs-customer-paid_4.png new file mode 100644 index 0000000..8fcabc4 Binary files /dev/null and b/docs/assets/images/specs-customer-paid_4.png differ diff --git a/docs/assets/images/specs-install_1.png b/docs/assets/images/specs-install_1.png new file mode 100644 index 0000000..1e1b8af Binary files /dev/null and b/docs/assets/images/specs-install_1.png differ diff --git a/docs/assets/images/specs-install_2.png b/docs/assets/images/specs-install_2.png new file mode 100644 index 0000000..98bdfed Binary files /dev/null and b/docs/assets/images/specs-install_2.png differ diff --git a/docs/specs/customers_free.md b/docs/specs/customers_free.md new file mode 100644 index 0000000..8d9f858 --- /dev/null +++ b/docs/specs/customers_free.md @@ -0,0 +1,599 @@ +# Gestión de clientes (modelo gratuito) + +!!! warning Atención + Esta sección se encuentra en desarrollo 🚧. + **NO se recomienda realizarla** a menos que te lo hayan indicado expresamente. + +## Punto de partida + +Si has llegado hasta aquí, entiendo que ya has leído tanto la introducción como la instalación del entorno. A partir de ahora voy a dar por hecho que partimos todos desde el mismo punto y que tenemos ya la estructura de directorios creada y los proyectos descargados. + +Dicho esto, nos vamos a la consola (o desde el terminal de tu IDE), nos situamos en el **directorio raíz** y lanzamos el inicializador de OpenSpec. + +``` +openspec init +``` + +Seleccionamos **``GitHub Copilot``**, pulsamos **``Enter``** para añadirlo y después **``Tab``** para validar la selección. + +![workspace](../assets/images/specs-install_2.png) + +Esto instalará las plantillas necesarias para poder trabajar con **OpenSpec + GitHub Copilot**. + +## Requisitos funcionales + +- CRUD de clientes. +- Entidad cliente con `id` y `name`. +- Listado simple sin filtros ni paginación. +- Alta/edición en modal. +- El nombre es el único campo editable. +- No se permite guardar clientes con nombre duplicado. + +## Estrategia del modo gratuito + +Vamos a trabajar con un **modelo gratuito**, así que es importante tener claras sus limitaciones: + +- El contexto es **muy limitado** +- El número de operaciones mensuales también lo es +- El número de operaciones por hora también + +Así que, te pido paciencia ya que posiblemente no puedas hacer todo el tutorial completo en el mismo día, deberás trocearlo por exceso de límite de peticiones. + + +Para intengar mitigar un poco esto, vamos a: + +- Dividir el trabajo en tareas pequeñas +- Ser muy explícitos en los prompts +- Dar más contexto “artificial” al modelo + +> Con un modelo de pago podríamos plantear el ejercicio de forma más generalista y con menos fragmentación. + +El modelo que utilizaremos será **``Claude Haiku``**. Para ello debes: + +1. Hacer login con tu cuenta de GitHub +2. Activar GitHub Copilot +3. En el chat, abrir el tercer desplegable +4. Seleccionar el modelo **Claude Haiku** + +![Claude Haiku](../assets/images/specs-customer-free_1.png) + +En cualquier momento puedes ver el consumo mensual de tu cuenta pulsando el icono de la rana 🐸 en la esquina inferior derecha. El contador **se reinicia cada mes**. + +Vamos a dividir el ejercicio en **dos grandes bloques**: + +1. Primero trabajaremos únicamente con el **``backend``** +2. Después abordaremos el **``frontend``** + +De esta forma limitamos el contexto a un solo proyecto y facilitamos el trabajo al modelo. + +Además, recuerda que el comportamiento del modelo **no es determinista**. Si a ti te genera algo diferente a lo que ves aquí, probablemente seguirá siendo válido. No te frustres y ajusta los prompts si es necesario. + +## Flujo de trabajo OpenSpec + +Seguiremos el ciclo completo de : + +``` +1. Explore +2. Propose +3. Apply +4. Archive +``` + +## Generación de backend + +### Explore + +El objetivo de esta fase es **analizar el sistema existente**, sin modificar nada. + +Buscamos: + +- Entender la estructura actual +- Identificar patrones reutilizables +- Comprender cómo se comunican frontend y backend + +Aspectos a revisar: + +**Organización por dominios** + +- Estructura de carpetas +- Dominios existentes + +**Angular** + +- Componentes +- Servicios +- Modelos +- Routing + +**Spring Boot** + +- Controller +- Service +- Repository +- Entity +- DTO + +**Patrón CRUD** + +- Listados +- Creación / edición +- Borrado + +**Conexión frontend-backend** + +- Endpoints +- URLs +- DTOs + +**Reutilización** + +- Código común +- Patrones repetidos + +⚠️ En esta fase: + +- **NO** se escribe código +- **NO** se diseña la solución +- **NO** se inventan estructuras nuevas + +Solo se analiza el **sistema actual**. + +--- + +**📜 Prompt** + +Lo que haremos será escribir en el chat de ``Visual Studio Code`` el comando y las instrucciones que queramos darle. ``Recuerda haber elegido Claude Haiku``. + +``` +/opsx:explore + +Analiza el proyecto actual que está en el directorio 'backend', es una aplicación Spring Boot. Una vez analizado, responde: + +1. ¿Cómo están implementados los CRUD existentes? +- Controller +- Service +- Repository + +2. ¿Qué estructura siguen los dominios? + +3. ¿Cómo se implementan las operaciones? +- Listado +- Creación/edición +- Borrado + +4. ¿Qué formato tienen los endpoints y que relación tiene con los métodos HTTP? + +5. ¿Qué patrones o estructuras comunes se repiten en los CRUD existentes? +- Clases reutilizables +- Lógica repetida +- Estructuras comunes entre dominios + +6. ¿Existen test unitarios y de integración? ¿Cómo están implementados? ¿Utiliza algo especial al arrancar o al mockear? + +Analiza únicamente la parte de backend (Spring Boot) +NO propongas soluciones. +NO diseñes nuevas funcionalidades. +Solo analiza el sistema actual. +Escríbe el resultado del contexto dentro del fichero backend-explore.md en el directorio de las specs para poder utilizarlo en siguientes fases. + +``` + +Este comando realizará un análisis exhaustivo de tu sistema y lo dejará escrito dentro de la carpeta ``specs`` en un fichero llamado ``backend-explore.md``. Al final te mostrará un texto con el resumen del sistema y además escribirá el fichero de explore. + +!!! tip "Sobre los permisos" + Es posible que durante el análisis te pida permiso para hacer ciertas tareas. Le puedes ir dando permiso una a una o darle permiso en todo el workspace, eso lo dejamos a tu elección. + + +En cualquier momento puedes ver el consumo de la ventana de contexto para saber si todo el conocimiento del sistema está en memoria o no. En el icono de la gráfica de pastel que está dentro del chat en la parte superior derecha. + +![Ventana contexto](../assets/images/specs-customer-free_2.png) + + + +### Propose + +En esta fase definimos **qué vamos a construir**, basándonos estrictamente en el resultado del Explore. + +Durante esta fase debes especificar. + +**Descripción funcional** + +- Qué hace la funcionalidad +- Qué problema resuelve + +**Reglas de negocio** + +- Validaciones +- Restricciones +- Comportamientos esperados + +**Diseño backend** + +- Endpoints necesarios +- Estructura del dominio (Entity, DTO, Service, Repository) +- Tipo de operaciones (listado, creación, edición, borrado) + +**Diseño frontend** + +- Componentes necesarios +- Flujo de usuario (listado, abrir modal, guardar, borrar) +- Servicios Angular + +**Decisiones técnicas** + +- Qué patrones existentes se reutilizan +- Qué se mantiene igual que en otros dominios +- Qué diferencias introduce esta funcionalidad + +**Plan de implementación** + +- Tareas ordenadas +- Separación backend / frontend + +Aquí dejamos claro: + +- Qué funcionalidad se va a añadir +- Qué reglas de negocio existen +- Qué piezas del sistema se ven afectadas +- Qué tareas habrá que ejecutar + +⚠️ En esta fase: + +- **NO** se implementa código +- **NO** se redefine el sistema + +--- + +**📜 Prompt** + +Para nuestro ejemplo, lo que haremos será escribir en el chat de ``Visual Studio Code`` el siguiente prompt: + +``` + +/opsx:propose manage-customers-backend + +Define la funcionalidad de gestión de clientes basándote en el sistema actual y en los patrones identificados en la fase Explore, tienes el resultado en el fichero "backend-explore.md". + +Nos han pedido esta nueva funcionalidad. + +Por un lado necesita poder tener una base de datos de sus clientes. Para ello nos ha pedido que si podemos crearle una pantalla de CRUD sencilla, al igual que hicimos con las categorías donde él pueda dar de alta a sus clientes. + +Nos ha pasado un esquema muy sencillo de lo que quiere, tan solo quiere guardar un listado de los nombres de sus clientes para tenerlos fichados, y nos ha hecho un par de pantallas sencillas muy similares a Categorías. + +Un listado sin filtros de ningún tipo ni paginación. + +Un formulario de edición / alta, cuyo único dato editable sea el nombre. Además, la única restricción que nos ha pedido es que NO podamos dar de alta a un cliente con el mismo nombre que otro existente. Así que deberemos comprobar el nombre, antes de guardar el cliente. + +Para empezar te daré unos consejos: +- Recuerda crear la tabla de la BBDD y sus datos +- Intenta primero hacer el listado completo, en el orden que más te guste: frontend o backend. +- Completa el listado conectando ambas capas. +- Termina el caso de uso haciendo las funcionalidades de edición, nuevo y borrado. Presta atención a la validación a la hora de guardar un cliente, NO se puede guardar si el nombre ya existe. + + +Te voy a dar otras directrices que pienso que te pueden servir: +- Se necesita un CRUD de clientes +- Un cliente solo tiene: id, name +- El listado será simple, sin filtros ni paginación +- Existirá un formulario de alta / edición en modal +- El único campo editable será el nombre +- No se puede crear un cliente con un nombre ya existente, será una validación obligatoria que deberemos cumplir en el guardado + + +Necesito que definas: + +1. Descripción de la funcionalidad + +2. Reglas de negocio + +3. Diseño backend: +- Endpoints necesarios +- Estructura del dominio (Entity, DTO, Service, Repository) + +4. Decisiones técnicas: +- Qué patrones del sistema actual se reutilizan + + +NO implementes código. +NO analices de nuevo el proyecto. +Basa la propuesta en los patrones detectados en la fase Explore. +Haz la propuesta únicamente de backend. +Como última tarea añade al fichero de tasks generar un resumen del cambio realizado, con el contrato de los endpoints y la información necesaria para que luego el frontend pueda implementar sus llamadas de forma sencilla. + +Tendrás que escribir los ficheros de proposal, design, spec y tasks en la propuesta correspondiente. + +``` + +De nuevo al ser un modelo gratuito tenemos que delimitarle mucho las tareas y recordarle que debe generar los ficheros de ``proposal``, ``design``, ``spec`` y ``tasks``, además de basarse en el fichero de ``backend-explore``. También debemos centrarle para que **SOLO** genere la parte de backend. + +Por último si te fijas en el prompt hay una tarea que le indica claramente que genere un fichero con los contratos de los endpoints para poder implementar, en un futuro, la parte frontend. Esto es solamente una idea de generar un resumen para que el frontend sepa como comunicarse con el backend. + +Este paso debe generar una propuesta dentro de `changes` con los artefactos `proposal`, `design`, `spec` y `tasks`. + +Si necesitas recordar el papel de cada artefacto, revisa la `introducción`. + +!!! tip "Responsabilidades como developer IA" + En este punto la IA te ha hecho una propuesta que puede ser correcta o no, recordemos que se trata de un modelo matemático-probabilístico. Si hay algo de lo propuesto que no te encaja o es erróneo deberías comentarlo mediante el chat o corregirlo de forma manual en el fichero que corresponda. Por ejemplo si quieres añadir una tarea porqué se te ha olvidado incluirla en el prompt original, deberías decirle al modelo que te incluya la nueva tarea. + +Una vez estemos de acuerdo con la propuesta que nos ha hecho la IA, podemos pasar al siguiente punto. + + + +### Apply + +Una vez validada la propuesta, ejecutamos la implementación: + +El objetivo de esta fase es transformar los artefactos generados +(`proposal.md`, `design.md`, `spec.md`, `tasks.md`) en **código funcional**, asegurando que: + +- Se respetan los requisitos funcionales definidos en `spec.md` +- Se siguen las decisiones técnicas establecidas en `design.md` +- Se ejecutan las tareas en el orden definido en `tasks.md` + +--- + +**📜 Prompt** + +Esto es tan fácil como escribir en el chat de ``Visual Studio Code`` el siguiente prompt: + +``` + +/opsx:apply + +``` + +El agente empezará a realizar un montón de tareas y pedirnos permisos. Es posible que algunas de esas tareas fallen y él mismo lo reintente de otra forma. El resultado debería ser el código generado e implementado dentro de la carpeta de ``backend`` y un resumen de todas las tareas realizadas y checkeadas por la IA. + +### Verificación del backend + +Un paso que no pertenece a OpenSpec pero que es altamente recomendable es probar los cambios realizados. +Arranca el backend y verifica: + +- Que el servidor levanta +- Que los endpoints existen y funcionan +- Que los tests pasan + +!!! warning "Ojo no te fies" + Ojo no te fies de todo lo que construya la IA. Tu estás al mando, tu debes decidir si el sistema está correctamente implementado o no. Es tu responsabilidad. + +Si **NO** estás a gusto con la implementación o se ha dejado algo por hacer, es el momento de escribirlo por el chat indicándole exactamente que es lo que falta. Cuanto más preciso y conciso seas, mejor implementará la IA. + + + + +### Archive + +Y llegamos a la última etapa que nos define OpenSpec, donde se archiva el cambio y se da por finalizada la funcionalidad. + +El objetivo de esta fase es marcar la funcionalidad como completada, consolidar todos los artefactos generados durante el proceso y dejar el sistema en un estado estable, coherente y preparado para nuevas evoluciones. + +En esta fase se asegura que: + +- La funcionalidad ha sido correctamente implementada y validada +- No existen incidencias críticas pendientes +- La documentación asociada al cambio está completa y actualizada +- Existe una trazabilidad entre requisitos, diseño e implementación + +Aunque parezca mentira, este paso es muy importante ya que nos servirá para actualizar el contexto del sistema y archivar todos los cambios para futuras consultas. + +--- + +**📜 Prompt** + +De nuevo nos vamos al chat de ``Visual Studio Code`` el siguiente prompt: + +``` + +/opsx:archive + +``` + +En este punto el sistema pedirá confirmación para sincronizar requisitos antes de archivar. + +Sincronizar es obligatorio si quieres mantener trazabilidad entre lo implementado y los specs oficiales. + + +**📜 Actualización del contexto** + + +Además, para forzar al ``modelo gratuito`` y dejarlo todo listo, es recomendable lanzar un último prompt que nos actualice el fichero de `backend-explore.md` + +``` + +Actualiza el fichero de backend-explore con los nuevos datos implementados + +``` + + +## Generación de frontend + +Bueno, pues ahora que ya tenemos el backend implementado, realizaremos de nuevo un ciclo completo de OpenSpec pero está vez para frontend: + +``` +1. Explore +2. Propose +3. Apply +4. Archive +``` + +**Es muy importante** que cada nuevo cambio que hagamos, lo empecemos en un chat nuevo, para limpiar el contexto anterior y no arrastrar posibles errores o incoherencias. + +### Explore + +De nuevo el objetivo de esta fase es analizar el sistema existente, sin modificar nada, pero esta vez nos centraremos en el frontend. + +--- + +**📜 Prompt** + +Vamos **a un nuevo** chat de ``Visual Studio Code`` y escribimos el comando: + +``` +opsx:explore + +Analiza el proyecto actual que está en el directorio "frontend", es una aplicación Angular. Ojo no escanees la carpeta de "node_modules" no tiene sentido. Una vez analizado, responde: + +1. ¿Cómo están implementados los CRUD existentes? +- Componentes +- Servicios +- Modelos + +2. ¿Qué estructura siguen los dominios? + +3. ¿Cómo se implementan las operaciones? +- Listado +- Creación/edición +- Borrado +- Cómo funcionan las ventanas de creación y edición (modales) + +4. ¿Como se comunican frontend con backend? +- Servicios en Angular +- Construcción de URLs + +5. ¿Qué patrones o estructuras comunes se repiten en los CRUD existentes? +- Clases reutilizables +- Lógica repetida +- Estructuras comunes entre dominios + + +Analiza únicamente la parte de frontend (Angular) +NO propongas soluciones. +NO diseñes nuevas funcionalidades. +Solo analiza el sistema actual. +Escríbe el resultado del contexto dentro del fichero frontend-explore.md en el directorio de las specs para poder utilizarlo en siguientes fases. + +``` + +Este comando realizará un análisis exhaustivo de tu sistema y lo dejará escrito dentro de la carpeta ``specs`` en un fichero llamado ``frontend-explore.md``. Al final te mostrará un texto con el resumen del sistema y además escribirá el fichero de explore. Este análisis estará más centrado en el frontend y debes pedirle que compruebe como se comunica con el backend para que lo tenga en cuenta. + + +### Propose + +Una vez definido el análisis inicial, lo siguiente es pedirle una propuesta de lo que queremos construir. + +--- + +**📜 Prompt** + +De nuevo en el chat de ``Visual Studio Code`` escribimos el comando: + +``` +/opsx:propose manage-customers-frontend + +Define la funcionalidad de gestión de clientes basándote en el sistema actual y en los patrones identificados en la fase Explore, tienes el resultado en el fichero "frontend-explore.md". Además tendrás que ver el cambio realizado en la spec de "manage-customers-backend", sobre todo los endpoints generados que lo tienes definido en "FRONTEND_API_CONTRACT.md" + +Nos han pedido esta nueva funcionalidad. + +Por un lado necesita poder tener una base de datos de sus clientes. Para ello nos ha pedido que si podemos crearle una pantalla de CRUD sencilla, al igual que hicimos con las categorías donde él pueda dar de alta a sus clientes. + +Nos ha pasado un esquema muy sencillo de lo que quiere, tan solo quiere guardar un listado de los nombres de sus clientes para tenerlos fichados, y nos ha hecho un par de pantallas sencillas muy similares a Categorías. + +Un listado sin filtros de ningún tipo ni paginación. + +Un formulario de edición / alta, cuyo único dato editable sea el nombre. Además, la única restricción que nos ha pedido es que NO podamos dar de alta a un cliente con el mismo nombre que otro existente. Así que deberemos comprobar el nombre, antes de guardar el cliente. + +Para empezar te daré unos consejos: +- Recuerda crear la tabla de la BBDD y sus datos +- Intenta primero hacer el listado completo, en el orden que más te guste: frontend o backend. +- Completa el listado conectando ambas capas. +- Termina el caso de uso haciendo las funcionalidades de edición, nuevo y borrado. Presta atención a la validación a la hora de guardar un cliente, NO se puede guardar si el nombre ya existe. + + +Te voy a dar otras directrices que pienso que te pueden servir: +- Se necesita un CRUD de clientes +- Un cliente solo tiene: id, name +- El listado será simple, sin filtros ni paginación +- Existirá un formulario de alta / edición en modal +- El único campo editable será el nombre +- No se puede crear un cliente con un nombre ya existente, será una validación obligatoria que deberemos cumplir en el guardado + + +Necesito que definas: + +1. Descripción de la funcionalidad + +2. Reglas de negocio + +3. Diseño frontend: +- Componentes necesarios +- Flujos de interacción (listado, abrir modal, guardar borrar) + +4. Uso de endpoints para llamar a backend + +5. Decisiones técnicas: +- Qué patrones del sistema actual se reutilizan + + +NO implementes código. +NO analices de nuevo el proyecto. +Basa la propuesta en los patrones detectados en la fase Explore. +Haz la propuesta únicamente de frontend. +Olvídate de los test, en frontend no tenemos tests. +Añade el nuevo punto de menú en el header para que se pueda acceder. +No te inventes estilos, respeta los estilos de las pantallas (anchuras, alturas, colores, disposición de las tablas). +Utiliza los alert dialog de Angular Material para las alertas, no uses la opción alert() del navegador. + +Tendrás que escribir los ficheros de proposal, design, spec y tasks en la propuesta correspondiente. +``` + +Puntos a destacar de este prompt: + +- Además del contexto inicial le hemos pedido que busque el fichero de `FRONTEND_API_CONTRACT.md` que es el fichero que generamos junto con el backend y que tiene las reglas de los endpoints del backend. Esto lo tenemos que hacer así ya que el modelo es gratuito y tiene limitaciones, no puede analizar frontend y backend a la vez en el mismo contexto. +- También le hemos pedido que **NO** invente estilos y que se fije en las pantallas existentes, además de decirle que utilice componentes de Angular Material. A veces los modelos gratuitos tienden a inventar mucho, por falta de contexto. De nuevo cuanto más concretos y precisos seamos, mejor implementará. + + +### Apply + +Cuando estemos de acuerdo con la propuesta que nos ha hecho la IA y sobre todo con las tasks que propone realizar, lanzamos la fase de implementación. + +--- + +**📜 Prompt** + +Esto es tan fácil como escribir en el chat de ``Visual Studio Code`` el siguiente prompt: + +``` + +/opsx:apply + +``` + +El agente empezará a realizar un montón de tareas y pedirnos permisos. Es posible que algunas de esas tareas fallen y él mismo lo reintente de otra forma. El resultado debería ser el código generado e implementado dentro de la carpeta de ``frontend`` y un resumen de todas las tareas realizadas y checkeadas por la IA. + + +### Verificación del frontend + +Ahora sí, prueba de 🔥 fuego 🔥. Es hora de levantar el sistema completo, ``frontend`` y ``backend``, navegar por la aplicación y comprobar que todo funciona. + +Si algo no encaja, es buen momento para conversarlo con la IA y que realice los cambios necesarios hasta conseguir que todo funcione perfectamente. + + +### Archive + +Una vez tengamos todo funcionando y perfectamente implementado, pasamos a la última etapa para archivar y sincronizar nuestro cambio. + +--- + +**📜 Prompt** + +De nuevo nos vamos al chat de ``Visual Studio Code`` el siguiente prompt: + +``` +/opsx:archive +``` + +En ese caso, el sistema solicita confirmación para sincronizar los requisitos antes de archivar el cambio. + + +**📜 Actualización del contexto** + + +Y por último forzamos una actualización del contexto inicial. + +``` +Actualiza el fichero de frontend-explore con los nuevos datos implementados +``` + + + + diff --git a/docs/specs/customers_paid.md b/docs/specs/customers_paid.md new file mode 100644 index 0000000..706768e --- /dev/null +++ b/docs/specs/customers_paid.md @@ -0,0 +1,362 @@ +# Gestión de clientes (modelo con licencia) + +!!! warning Atención + Esta sección se encuentra en desarrollo 🚧. + **NO se recomienda realizarla** a menos que te lo hayan indicado expresamente. + +## Punto de partida + +Si has llegado hasta aquí, entiendo que ya has leído tanto la introducción como la instalación del entorno. A partir de ahora voy a dar por hecho que partimos todos desde el mismo punto y que tenemos ya la estructura de directorios creada y los proyectos descargados. + +Dicho esto, nos vamos a la consola (o desde el terminal de tu IDE), nos situamos en el **directorio raíz** y lanzamos el inicializador de OpenSpec. + +``` +openspec init +``` + +Seleccionamos **``GitHub Copilot``**, pulsamos **``Enter``** para añadirlo y después **``Tab``** para validar la selección. + +![workspace](../assets/images/specs-install_2.png) + +Esto instalará las plantillas necesarias para poder trabajar con **OpenSpec + GitHub Copilot**. + +## Requisitos funcionales + +- CRUD de clientes. +- Entidad cliente con `id` y `name`. +- Listado simple sin filtros ni paginación. +- Alta/edición en modal. +- El nombre es el único campo editable. +- No se permite guardar clientes con nombre duplicado. + +## Estrategia del modo con licencia + +Vamos a trabajar con un **modelo de pago**, por lo que es importante entender qué ventajas nos ofrece frente al modelo gratuito. + +En este caso podremos: + +- Trabajar con **mayor contexto** +- Analizar **frontend y backend simultáneamente** +- Reducir la fragmentación de tareas +- Obtener propuestas e implementaciones más completas y robustas + +El modelo que utilizaremos será **``Claude Sonnet 4.6``**. Para ello debes: + +1. Tener una **cuenta premium con acceso a modelos de pago** +2. Hacer login con tu cuenta de GitHub +3. Activar GitHub Copilot +4. En el chat, abrir el tercer desplegable +5. Seleccionar el modelo **Claude Sonnet 4.6** + +![Claude Sonnet 4.6](../assets/images/specs-customer-paid_1.png) + +En cualquier momento puedes ver el consumo mensual de tu cuenta pulsando el icono de la rana 🐸 en la esquina inferior derecha. El contador **se reinicia cada mes**. + +Vamos a abordar el ejercicio como un **único bloque de trabajo**, analizando y construyendo la funcionalidad de forma **simultánea en backend y frontend**. + +De esta manera aprovechamos el **mayor contexto** del modelo de pago, permitiendo: + +1. Analizar **``backend`` y ``frontend`` al mismo tiempo** +2. Diseñar la funcionalidad de forma coherente en ambas capas desde el inicio + +Esto nos permite mantener una visión global del sistema durante todo el proceso y reducir la necesidad de dividir artificialmente el trabajo en fases independientes por capa. + +Además, recuerda que el comportamiento del modelo **no es determinista**. Si a ti te genera algo diferente a lo que ves aquí, probablemente seguirá siendo válido. No te frustres y ajusta los prompts si es necesario. + +## Flujo de trabajo OpenSpec + +Seguiremos el ciclo completo de OpenSpec: + +``` +1. Explore +2. Propose +3. Apply +4. Archive +``` + +### Explore + +El objetivo de esta fase es **analizar el sistema existente**, sin modificar nada. + +Buscamos: + +- Entender la estructura actual de la aplicación +- Identificar patrones y estructuras reutilizables +- Comprender cómo se comunican frontend y backend + +Aspectos a revisar: + +**Organización por dominios** + +- Cómo están estructurados los dominios existentes (category, author, game…) +- Qué carpetas existen en frontend y backend +- Cómo se relacionan los dominios entre capas + +**Angular** + +- Componentes +- Servicios +- Modelos +- Routing + +**Spring Boot** + +- Controller +- Service +- Repository +- Entity +- DTO + +**Patrón CRUD** + +- Cómo se implementan los listados +- Cómo se implementan las operaciones de creación, edición y borrado +- Cómo funcionan las ventanas de creación y edición (modales) + +**Conexión frontend-backend** + +- Cómo Angular llama a los endpoints +- Cómo se construyen las URLs +- Qué DTOs se utilizan en la comunicación + +**Reutilización** + +- Código común entre dominios +- Patrones repetidos +- Estructuras compartidas entre diferentes funcionalidades + +⚠️ En esta fase: + +- **NO** se escribe código +- **NO** se diseña la solución +- **NO** se inventan estructuras nuevas + +Solo se analiza el **sistema actual**. + +--- + +**📜 Prompt** + +Lo que haremos será escribir en el chat de ``Visual Studio Code`` el comando y las instrucciones que queramos darle. ``Recuerda haber elegido Claude Sonnet 4.6 y estar trabajando en modo Agent``. + +En este caso, hemos añadido las carpetas del proyecto **``frontend`` y ``backend`` al contexto**, por lo que el análisis se realizará sobre **el sistema completo**. + +Para ello, desde el propio Chat de Copilot, pulsando el botón **“+”**, puedes seleccionar y añadir tanto **archivos individuales** como **directorios completos** del proyecto. También es posible añadirlos **arrastrándolos directamente al chat**. + +![Ventana de chat](../assets/images/specs-customer-paid_2.png) + +``` +/opsx:explore + +Analiza el proyecto actual (Angular 17 + Spring Boot) que se ha añadido al contexto. Una vez analizado, responde: + +1. ¿Cómo están implementados los CRUD existentes? +- Backend: Controller, Service, Repository +- Frontend: componentes, servicios y modelo + +2. ¿Qué estructura siguen los dominios en backend y en frontend? + +3. ¿Cómo se implementan las operaciones? +- Listado +- Creación/edición +- Borrado +- Cómo funcionan las ventanas de creación y edición (modales) + +4. ¿Cómo se comunican frontend y backend? +- Servicios Angular +- Construcción de URLs + +5. ¿Qué patrones o estructuras comunes se repiten en los CRUD existentes? +- Clases reutilizables +- Lógica repetida +- Estructuras comunes entre dominios + +NO propongas soluciones. +NO diseñes nuevas funcionalidades. +Solo analiza el sistema actual. +``` + +Este comando realizará un análisis exhaustivo de tu sistema que servirá como base para definir la nueva funcionalidad en la siguiente fase. + +!!! tip "Sobre los permisos" + Es posible que durante el análisis te pida permiso para hacer ciertas tareas. Le puedes ir dando permiso una a una o darle permiso en todo el workspace, eso lo dejamos a tu elección. + +En cualquier momento puedes ver el consumo de la ventana de contexto para saber si todo el conocimiento del sistema está en memoria o no. En el icono de la gráfica circular que está situada en la parte inferior derecha del chat. + +![Ventana contexto](../assets/images/specs-customer-paid_3.png) + +### Propose + +Una vez analizado el sistema en la fase Explore, el siguiente paso es definir de forma clara y estructurada **la nueva funcionalidad a implementar**. + +En esta fase establecemos **qué vamos a construir**, basándonos estrictamente en el resultado del Explore y aprovechando que el modelo dispone de una **visión completa del sistema** (frontend y backend). + +Esta fase actúa como puente entre el análisis y la implementación, permitiendo diseñar la solución antes de escribir código y reduciendo el riesgo de errores durante el desarrollo. + +Durante esta fase debes especificar: + +**Descripción funcional** + +- Qué hace la funcionalidad +- Qué problema resuelve + +**Reglas de negocio** + +- Validaciones +- Restricciones +- Comportamientos esperados + +**Diseño backend** + +- Endpoints necesarios +- Estructura del dominio (Entity, DTO, Service, Repository) +- Tipo de operaciones (listado, creación, edición, borrado) + +**Diseño frontend** + +- Componentes necesarios +- Flujo de usuario (listado, abrir modal, guardar, borrar) +- Servicios Angular + +**Decisiones técnicas** + +- Qué patrones existentes se reutilizan +- Qué se mantiene igual que en otros dominios +- Qué diferencias introduce esta funcionalidad + +**Plan de implementación** + +- Tareas ordenadas +- Separación backend / frontend + +Aquí dejamos claro: + +- Qué funcionalidad se va a añadir +- Qué reglas de negocio existen +- Qué piezas del sistema se ven afectadas +- Qué tareas habrá que ejecutar + +⚠️ En esta fase: + +- **NO** se implementa código +- **NO** se redefine el sistema + +--- + +**📜 Prompt** + +Recuerda que seguimos trabajando en **modo Agent**, con las carpetas del proyecto **``frontend`` y ``backend`` añadidas al contexto**. + +Para nuestro ejemplo, lo que haremos será escribir en el chat de ``Visual Studio Code`` el siguiente prompt: + +``` +/opsx:propose client + +Define la funcionalidad de gestión de clientes basándote en el sistema actual (Angular 17 + Spring Boot) y en los patrones identificados en la fase Explore. + +Requisitos funcionales: +- Se necesita un CRUD de clientes +- Un cliente solo tiene: id, name +- El listado será simple, sin filtros ni paginación +- Existirá un formulario de alta / edición en modal +- El único campo editable será el nombre +- No se puede crear un cliente con un nombre ya existente (validación obligatoria) + +Define: + +1. Descripción de la funcionalidad + +2. Reglas de negocio + +3. Diseño backend: +- Endpoints necesarios +- Estructura del dominio (Entity, DTO, Service, Repository) + +4. Diseño frontend: +- Componentes necesarios +- Flujo de interacción (listado, abrir modal, guardar, borrar) + +5. Decisiones técnicas: +- Qué patrones del sistema actual se reutilizan + +NO implementes código. +NO analices de nuevo el proyecto. +Basa la propuesta en los patrones detectados en la fase Explore. +``` + +Este comando debe generar una propuesta en `changes` con los artefactos `proposal`, `design`, `spec` y `tasks`. + +Si necesitas recordar el papel de cada artefacto, revisa la `introducción`. + +!!! tip "Responsabilidades como developer IA" + En este punto la IA te ha hecho una propuesta que puede ser correcta o no, recordemos que se trata de un modelo matemático-probabilístico. Si hay algo de lo propuesto que no te encaja o es erróneo deberías comentarlo mediante el chat o corregirlo de forma manual en el fichero que corresponda. Por ejemplo si quieres añadir una tarea porqué se te ha olvidado incluirla en el prompt original, deberías decirle al modelo que te incluya la nueva tarea. + +Una vez estemos de acuerdo con la propuesta que nos ha hecho la IA, podemos pasar al siguiente punto. + +### Apply + +Una vez validada la propuesta, ejecutamos la implementación: + +El objetivo de esta fase es transformar los artefactos generados +(`proposal.md`, `design.md`, `spec.md`, `tasks.md`) en **código funcional**, asegurando que: + +- Se respetan los requisitos funcionales definidos en `spec.md` +- Se siguen las decisiones técnicas establecidas en `design.md` +- Se ejecutan las tareas en el orden definido en `tasks.md` + +--- + +**📜 Prompt** + +Esto es tan fácil como escribir en el chat de ``Visual Studio Code`` el siguiente prompt: + +``` +/opsx:apply +``` + +El agente empezará a realizar un montón de tareas y pedirnos permisos. Es posible que algunas de esas tareas fallen y él mismo lo reintente de otra forma. El resultado debería ser el código generado e implementado tanto en la carpeta ``backend`` como en la carpeta ``frontend`` y un resumen de todas las tareas realizadas y checkeadas por la IA. + +### Verificación + +Un paso que no pertenece a OpenSpec pero que es altamente recomendable es probar los cambios realizados. + +Arranca el **backend** y el **frontend** y verifica: + +- La aplicación levanta correctamente +- Las nuevas funcionalidades añadidas están accesibles +- Los flujos principales definidos en `spec.md` funcionan como se espera + +!!! warning "Ojo no te fies" + Ojo no te fies de todo lo que construya la IA. Tu estás al mando, tu debes decidir si el sistema está correctamente implementado o no. Es tu responsabilidad. + +Si **NO** estás a gusto con la implementación o se ha dejado algo por hacer, es el momento de escribirlo por el chat indicándole exactamente que es lo que falta. Cuanto más preciso y conciso seas, mejor implementará la IA. + + +### Archive + +Y llegamos a la última etapa que nos define OpenSpec, donde se archiva el cambio y se da por finalizada la funcionalidad. + +El objetivo de esta fase es marcar la funcionalidad como completada, consolidar todos los artefactos generados durante el proceso y dejar el sistema en un estado estable, coherente y preparado para nuevas evoluciones. + +En esta fase se asegura que: + +- La funcionalidad ha sido correctamente implementada y validada +- No existen incidencias críticas pendientes +- La documentación asociada al cambio está completa y actualizada +- Existe una trazabilidad entre requisitos, diseño e implementación + +Aunque parezca mentira, este paso es muy importante ya que nos servirá para actualizar el contexto del sistema y archivar todos los cambios para futuras consultas. + +--- + +**📜 Prompt** + +De nuevo nos vamos al chat de ``Visual Studio Code`` el siguiente prompt: + +``` +/opsx:archive +``` + +En este punto el sistema pedirá confirmación para sincronizar requisitos antes de archivar. + +Sincronizar es obligatorio si quieres mantener trazabilidad entre lo implementado y los specs oficiales. \ No newline at end of file diff --git a/docs/specs/intro.md b/docs/specs/intro.md new file mode 100644 index 0000000..0c80dfe --- /dev/null +++ b/docs/specs/intro.md @@ -0,0 +1,263 @@ +# Introducción a Spec-Driven Development + +!!! warning Atención + Esta sección se encuentra en desarrollo 🚧. + **NO se recomienda realizarla** a menos que te lo hayan indicado expresamente. + +## Contexto + +En este bloque del tutorial vamos a implementar nuevas funcionalidades usando **Spec-Driven Development (SDD)** con **OpenSpec**. + +El objetivo no es únicamente desarrollar nuevas funcionalidades, sino hacerlo siguiendo un proceso estructurado que permita separar claramente las distintas fases del desarrollo y garantizar **trazabilidad entre análisis, definición, implementación y validación**. + +Para llevar a cabo este enfoque de manera práctica, se utiliza la metodología **OpenSpec**, que proporciona un flujo de trabajo claro y repetible para definir, implementar y consolidar cambios en el sistema. + +Las funcionalidades abordadas se organizan en dos bloques principales: + +- **Gestión de clientes** +- **Gestión de préstamos** + +Ambas se implementan siguiendo las fases definidas por **OpenSpec**, reutilizando los patrones existentes del sistema y manteniendo coherencia técnica y funcional con el resto de la aplicación. + +--- + +## ¿Qué es Spec-Driven Development? + +**Spec-Driven Development (SDD)** es un enfoque de desarrollo en el que el comportamiento del sistema se define de forma explícita **antes de escribir código**. + +En lugar de comenzar directamente con la implementación, SDD propone describir primero: + +- Qué debe hacer el sistema +- Qué reglas y restricciones deben cumplirse +- Qué comportamiento se espera en cada escenario + +Las especificaciones (*specs*) se convierten en el eje central del desarrollo y sirven como referencia común durante todo el proceso. + +Este enfoque permite: + +- Reducir ambigüedades sobre el comportamiento esperado +- Detectar errores de diseño de forma temprana +- Mantener coherencia en sistemas que evolucionan con el tiempo +- Facilitar la comunicación entre personas y herramientas implicadas en el desarrollo + +--- + +## OpenSpec como metodología de trabajo + +**OpenSpec** es una metodología que materializa el enfoque de **Spec-Driven Development**, proporcionando un flujo de trabajo estructurado para implementar cambios de forma controlada y trazable. + +OpenSpec organiza el desarrollo en una serie de fases bien definidas que permiten: + +- Analizar el contexto y el alcance del cambio +- Definir el comportamiento funcional esperado +- Implementar la solución de forma alineada con lo definido +- Cerrar y consolidar el cambio de manera ordenada + +A lo largo de esta guía se utilizará OpenSpec como marco de trabajo para aplicar SDD en la implementación de las funcionalidades de gestión de clientes y gestión de préstamos. + +!!! tip "SDD y agentes de IA" + Al trabajar con agentes de IA, el código puede generarse rápidamente, pero sin una guía clara existe el riesgo de que la IA tome decisiones no deseadas para que “el código funcione”. + + OpenSpec traslada el foco a las especificaciones, que definen explícitamente el comportamiento esperado del sistema y sirven como contrato para la IA, reduciendo ambigüedades y asegurando trazabilidad entre lo definido y lo implementado. + +Es **sumamente importante** que se defina de forma concreta y muy concisa los requisitos y las reglas que debe seguir la IA a la hora de analizar y generar. + + +## Fases de OpenSpec + +El flujo de trabajo de OpenSpec se estructura en cuatro fases principales: + +``` +1. Explore +2. Propose +3. Apply +4. Archive +``` + +Cada una de estas fases cumple un propósito específico y se apoya en la anterior, formando un ciclo completo de definición, implementación y cierre del cambio. + +--- + +### Explore + +Fase inicial orientada a **comprender el contexto** en el que se va a trabajar. + +**Objetivo** + +- Analizar la información disponible +- Entender la necesidad, iniciativa o cambio a abordar +- Identificar posibles limitaciones, dependencias y patrones existentes + +Esta fase no implica necesariamente la existencia de un sistema previo. + +Puede consistir en: + +- Analizar un sistema existente +- Revisar documentación o requisitos +- Definir el contexto cuando se parte desde cero + +**Resultado** + +Una comprensión clara del punto de partida y del alcance del cambio a realizar. + +--- + +### Propose + +Fase orientada a la **definición de la solución** a implementar. + +**Objetivo** + +- Definir qué se va a construir +- Delimitar el alcance del cambio (qué se incluye y qué queda fuera) +- Establecer el comportamiento funcional esperado + +**Resultado** + +Una propuesta clara, estructurada y alineada con el objetivo del cambio, que servirá como base para su implementación. En esta fase se deberían generar 4 ficheros. + + +**📄 proposal.md** + +Define la funcionalidad a alto nivel. + +Incluye: + +- El problema que se quiere resolver (Why) +- Qué cambios se van a introducir (What Changes) +- El alcance funcional +- El impacto en la aplicación + +Responde a: ¿Qué se va a construir y por qué? + +**📄 design.md** + +Describe el diseño técnico de la solución. + +Incluye: + +- Contexto del sistema actual +- Objetivos (Goals / Non-Goals) +- Decisiones técnicas y su justificación +- Alternativas consideradas +- Riesgos y trade-offs + +Responde a: ¿Cómo se va a construir y por qué se ha elegido este enfoque? + +**📄 spec.md** + +Define el comportamiento funcional esperado. + +Incluye: + +- Requisitos funcionales +- Casos de uso expresados como escenarios (WHEN / THEN) +- Reglas de negocio +- Validaciones y restricciones + +Responde a: ¿Qué debe hacer el sistema? + +**📄 tasks.md** + +Descompone la implementación en tareas ejecutables. Quizá es el fichero más importante. + +Incluye: + +- Lista ordenada de tareas +- Pasos concretos para implementar la funcionalidad + +Responde a: ¿Cómo se implementa paso a paso? + +**Relación entre los artefactos** + +Cada uno de los ficheros generados cumple un rol específico dentro del flujo de OpenSpec: + +- **spec.md** → define el comportamiento esperado (*qué debe hacer el sistema*) +- **design.md** → define la solución técnica (*cómo se va a construir*) +- **proposal.md** → aporta contexto y alcance (*por qué se construye*) +- **tasks.md** → guía la ejecución paso a paso (*cómo se implementa*) + +Esta separación de responsabilidades permite: + +- Evitar mezclar requisitos con implementación +- Revisar cada nivel de forma independiente +- Detectar errores e inconsistencias antes de escribir código + +Estos artefactos constituyen la base para la siguiente fase. + + +--- + +### Apply + +Fase en la que se lleva a cabo la **implementación** de la solución definida en la fase Propose. + +**Objetivo** + +- Desarrollar la solución definida +- Asegurar la coherencia entre lo definido y lo implementado +- Integrar y validar funcionalmente el resultado + +**Resultado** + +Una solución implementada, coherente con la propuesta definida y preparada para su validación final. + +--- + +### Archive + +Fase final de **cierre y consolidación** del cambio. + +**Objetivo** + +- Confirmar que el cambio está completo +- Consolidar la documentación generada durante el proceso +- Garantizar la trazabilidad para futuras evoluciones + +**Resultado** + +Un cambio finalizado, validado y correctamente documentado. +En esta fase se pedirá sincronizar los requisitos antes de archivar y consolidar. + +**¿Qué significa sincronizar?** + +Al seleccionar la opción de sincronización: + +- Se integran los nuevos requisitos definidos en spec.md +- Se crea o actualiza el spec definitivo +- Los requisitos pasan a formar parte oficial del sistema + +Es decir, los requisitos pasan de ser un cambio temporal a formar parte permanente del sistema. + +**¿Qué ocurre si no se sincroniza?** + +Si se decide no sincronizar: + +- El código permanece implementado +- Los requisitos no se registran en los specs principales + +Esto puede provocar: + +- Pérdida de trazabilidad +- Dificultad para futuras evoluciones +- Desalineación entre código y documentación + +**Tras completar el proceso de Archive:** + +- La funcionalidad queda documentada como completada +- El cambio deja de formar parte de los cambios activos +- Los requisitos quedan integrados definitivamente en el sistema (si se ha sincronizado) + + + +## Principios de calidad + +!!! tip "SDD y agentes de IA" + Con agentes de IA se genera código muy rápido, pero la responsabilidad técnica sigue siendo tuya. + +Durante todo el proceso: + +- revisa siempre la propuesta antes de aplicar, +- valida funcionalmente lo implementado, +- corrige tareas o requisitos cuando detectes desviaciones, +- no asumas que la primera respuesta de la IA es correcta. \ No newline at end of file diff --git a/docs/specs/loans_free.md b/docs/specs/loans_free.md new file mode 100644 index 0000000..38a48c8 --- /dev/null +++ b/docs/specs/loans_free.md @@ -0,0 +1,667 @@ +# Gestión de préstamos (modelo gratuito) + + +!!! warning Atención + Esta sección se encuentra en desarrollo 🚧. + **NO se recomienda realizarla** a menos que te lo hayan indicado expresamente. + +## Punto de partida + +Si has llegado hasta aquí, entiendo que ya has completado la funcionalidad de **gestión de clientes** utilizando el modelo gratuito. + +A partir de ahora vamos a dar por hecho que partimos de ese estado del sistema, donde: + +- Existe un CRUD funcional de clientes +- La funcionalidad está implementada, validada y archivada +- Los patrones de backend y frontend introducidos ya forman parte del sistema + +Una vez llegados a este punto, asumimos que el proyecto **ya está descargado y configurado**, y que hemos trabajado previamente sobre la funcionalidad de **gestión de clientes**. + +Por tanto, **continuaremos utilizando los mismos proyectos y directorios**, sin realizar ninguna instalación ni configuración adicional. + +En este tutorial seguiremos trabajando sobre: + +- ``server-springboot`` como **``backend``** +- ``client-angular17`` como **``frontend``** + + +## Requisitos funcionales + +- Gestión de préstamos entre clientes y juegos. +- Listado paginado con filtros por juego, cliente y fecha. +- Alta/edición en modal con campos obligatorios (salvo identificador). +- Validaciones de fechas y restricciones de solapamiento. +- Máximo 14 días por préstamo. +- Un juego no puede estar prestado a dos clientes en el mismo día. +- Un cliente no puede tener más de dos préstamos activos en el mismo día. + +## Estrategia del modo gratuito + +Continuaremos trabajando con un **modelo gratuito**, utilizando **``Claude Haiku``** y el mismo workspace que en la funcionalidad de **gestión de clientes**. + +Antes de comenzar, ten en cuenta lo siguiente: + +- Para cada **nueva funcionalidad**, es recomendable iniciar una **nueva conversación de chat** dentro del mismo proyecto + +Esto ayuda a mantener el contexto limpio y a que el modelo se centre exclusivamente en la funcionalidad que vamos a abordar. + +Recuerda que en cualquier momento puedes ver el consumo mensual de tu cuenta pulsando el icono de la rana 🐸 en la esquina inferior derecha. El contador **se reinicia cada mes**. + +Al igual que el ejercicio anterior, vamos a dividir el ejercicio en **dos grandes bloques**: + +1. Primero trabajaremos únicamente con el **``backend``** +2. Después abordaremos el **``frontend``** + +De esta forma limitamos el contexto a un solo proyecto y facilitamos el trabajo al modelo. + + +Además, recuerda que el comportamiento del modelo **no es determinista**. Si a ti te genera algo diferente a lo que ves aquí, probablemente seguirá siendo válido. No te frustres y ajusta los prompts si es necesario. + +## Flujo de trabajo OpenSpec + +Seguiremos el ciclo completo de : + +``` +1. Explore +2. Propose +3. Apply +4. Archive +``` + +## Generación de backend + +Aunque no es obligatorio, es altamente recomendable volver a ejecutar la fase de **``Explore``**. El sistema ha podido cambiar desde tu último cambio, alguien ha podido hacer modificaciones, etc. En tu caso no sería necesario ya que estás trabajando tu solo y no has cambiado nada, pero es buena práctica hacerlo siempre. + + +### Explore + +El objetivo de esta fase es **analizar el sistema existente**, sin modificar nada. + +A diferencia de la gestión de clientes, este caso de uso introduce una mayor complejidad, principalmente por: + +- Relaciones entre entidades (cliente, juego, préstamo) +- Uso de **paginación** en los listados +- Aplicación de **filtros combinados** +- Necesidad de **validaciones de negocio más complejas** + +En esta fase se analizará qué partes del sistema actual ya resuelven este tipo de problemas y pueden reutilizarse, y qué aspectos no están implementados y deberán abordarse en fases posteriores. + +Aspectos a revisar: + +**Paginación** + +- Cómo se implementa en backend (uso de Page) + +**Filtros** + +- Cómo se implementa en el catálogo de juegos +- Cómo se implementan filtros por rangos de fechas (si existen) +- DTOs de filtro utilizados +- Construcción de queries en backend +- Cómo se construyen queries con condiciones combinadas y operadores distintos de igualdad + +**Relaciones entre entidades** + +- Cómo se modelan relaciones en JPA +- Ejemplos existentes en el proyecto +- Cómo se representan en DTOs +- Cómo se cargan y exponen los datos relacionados + +**Validaciones en backend** + +- Dónde se implementan (Service) +- Cómo se gestionan errores +- Cómo se propagan al frontend +- Cómo se implementan validaciones sobre rangos de fechas +- Cómo se validan restricciones que dependen de registros existentes (solapamientos, límites por cliente, etc.) + +⚠️ En esta fase: + +- **NO** se escribe código +- **NO** se diseña la solución +- **NO** se inventan estructuras nuevas + +Solo se analiza el **sistema actual**. + +--- + +**📜 Prompt** + +Lo que haremos será escribir en el chat de ``Visual Studio Code`` el comando y las instrucciones que queramos darle. ``Recuerda haber elegido Claude Haiku y estar trabajando en modo Agent``. + +``` + +/opsx:explore + +Analiza el proyecto actual que está en el directorio "backend", es una aplicación Spring Boot. Una vez analizado, responde: + +1. ¿Cómo están implementados los CRUD existentes? +- Controller +- Service +- Repository +- Paginación y respuestas paginadas + +2. ¿Qué estructura siguen los dominios? + +3. ¿Cómo se implementan las operaciones? +- Listado +- Creación/edición +- Borrado +- DTOs de filtro utilizados y construcción de queries en backend +- Uso de condiciones combinadas (no solo igualdad) +- Ejemplos de filtros por rango de fechas (si existen) +- Ejemplos de consultas donde una fecha debe estar contenida dentro de un rango (si existen) + +4. ¿Cómo se gestionan relaciones entre entidades? +- Modelado en JPA +- Ejemplos en el proyecto +- Cómo se representan en DTOs +- Cómo se exponen los datos relacionados + +5. ¿Cómo se implementan validaciones en backend? +- Dónde se ubican (Service) +- Cómo se gestionan errores +- Cómo se propagan al frontend +- Si existen validaciones que dependan de múltiples registros o condiciones +- Si existen validaciones relacionadas con fechas o rangos +- Cómo se validan restricciones basadas en datos existentes + +6. ¿Qué formato tienen los endpoints y que relación tiene con los métodos HTTP? + +7. ¿Qué patrones o estructuras comunes se repiten en los CRUD existentes? +- Clases reutilizables +- Lógica repetida +- Estructuras comunes entre dominios + +8. ¿Existen test unitarios y de integración? ¿Cómo están implementados? ¿Utiliza algo especial al arrancar o al mockear? + + +Analiza únicamente la parte de backend (Spring Boot) +NO propongas soluciones. +NO diseñes nuevas funcionalidades. +Solo analiza el sistema actual. +Ya tienes un contexto previo en el fichero backend-explore.md en el directorio de las specs, utilizalo y lo actualizas con lo que analices y no esté. + +``` + +Si te fijas, le hemos indicado que aproveche el contexto previo generado en el ejercicio anterior y le hemos pedido que lo actualice con los cambios que considere. + + +Este comando realizará un análisis exhaustivo de tu sistema que servirá como base para definir la nueva funcionalidad en la siguiente fase. + +!!! tip "Sobre los permisos" + Es posible que durante el análisis te pida permiso para hacer ciertas tareas. Le puedes ir dando permiso una a una o darle permiso en todo el workspace, eso lo dejamos a tu elección. + +### Propose + +Una vez analizado el sistema en la fase Explore, el siguiente paso es definir de forma clara y estructurada **la nueva funcionalidad a implementar**. + +En esta fase establecemos **qué vamos a construir**, apoyándonos en el conocimiento ya consolidado del sistema y en el resultado del Explore. + +Esta fase actúa como puente entre el análisis y la implementación, permitiendo diseñar la solución antes de escribir código y reduciendo el riesgo de errores durante el desarrollo. + +Durante esta fase debes especificar: + +**Descripción funcional** + +- Qué hace la funcionalidad +- Qué problema resuelve + +**Reglas de negocio** + +- Validaciones sobre fechas: + - La fecha de fin no podrá ser anterior a la fecha de inicio +- Restricciones de duración del préstamo: + - El período de préstamo máximo solo podrá ser de 14 días +- Validaciones de solapamiento de préstamos: + - El mismo juego no puede estar prestado a más de un cliente para ninguno de los días incluidos en el rango del préstamo +- Límites de préstamos simultáneos por cliente: + - Un mismo cliente no puede tener más de 2 préstamos activos para ninguno de los días incluidos en el rango del préstamo + +**Diseño backend** + +- Endpoints necesarios +- Estructura del dominio (Entity, DTO, Service, Repository) +- Tipo de operaciones (listado, creación, edición, borrado) +- Estrategia para filtros por fecha dentro de rangos + +**Decisiones técnicas** + +- Qué patrones existentes se reutilizan +- Qué partes deben extenderse +- Cómo se gestionarán los filtros de fecha y condiciones combinadas +- Cómo se implementarán validaciones basadas en múltiples registros (solapamientos y límites) + +**Plan de implementación** + +- Tareas ordenadas +- Separación backend / frontend +- Prioridad de desarrollo (listado → filtros → validaciones) + +Aquí dejamos claro: + +- Qué funcionalidad se va a añadir +- Qué reglas de negocio existen +- Qué piezas del sistema se ven afectadas +- Qué tareas habrá que ejecutar + +⚠️ En esta fase: + +- **NO** se implementa código +- **NO** se redefine el sistema + +--- + +**📜 Prompt** + +Para nuestro ejemplo, lo que haremos será escribir en el chat de ``Visual Studio Code`` el siguiente prompt: + +``` +/opsx:propose manage-loans-backend + +Define la funcionalidad de gestión de préstamos de juegos basándote en el sistema actual y en los patrones identificados en la fase Explore, tienes el resultado en el fichero "backend-explore.md". + +Nos han pedido esta nueva funcionalidad. + +Se quiere hacer uso de su catálogo de juegos y de sus clientes, y quiere saber que juegos ha prestado a cada cliente. Para ello nos ha pedido una página bastante compleja donde se podrá consultar diferente información y se permitirá realizar el préstamo de los juegos. + +Nos ha pasado el siguiente boceto y requisitos. + +La pantalla tendrá dos zonas: + +- Una zona de filtrado donde se permitirá filtrar por: + - Título del juego, que deberá ser un combo seleccionable con los juegos del catálogo de la Ludoteca. + - Cliente, que deberá ser un combo seleccionable con los clientes dados de alta en la aplicación. + - Fecha, que deberá ser de tipo Datepicker y que permitirá elegir una fecha de búsqueda. Al elegir un día nos deberá mostrar que juegos están prestados para dicho día. OJO que los préstamos son con fecha de inicio y de fin, si elijo un día intermedio debería aparecer el elemento en la tabla. +- Una zona de listado paginado que deberá mostrar + - El identificador del préstamo + - El nombre del juego prestado + - El nombre del cliente que lo solicitó + - La fecha de inicio del préstamo + - La fecha de fin del préstamo + - Un botón que permite eliminar el préstamo + + +Al pulsar el botón de Nuevo préstamo se abrirá una pantalla donde se podrá ingresar la siguiente información, toda ella obligatoria: +- Identificador, inicialmente vacío y en modo lectura +- Nombre del cliente, mediante un combo seleccionable +- Nombre del juego, mediante un combo seleccionable +- Fechas del préstamo, donde se podrá introducir dos fechas, de inicio y fin del préstamo. + +Las validaciones son sencillas aunque laboriosas: +- La fecha de fin NO podrá ser anterior a la fecha de inicio +- El periodo de préstamo máximo solo podrá ser de 14 días. Si el usuario quiere un préstamo para más de 14 días la aplicación no debe permitirlo mostrando una alerta al intentar guardar. +- El mismo juego no puede estar prestado a dos clientes distintos en un mismo día. OJO que los préstamos tienen fecha de inicio y fecha fin, el juego no puede estar prestado a más de un cliente para ninguno de los días que contemplan las fechas actuales del rango. +- Un mismo cliente no puede tener prestados más de 2 juegos en un mismo día. OJO que los préstamos tienen fecha de inicio y fecha fin, el cliente no puede tener más de dos préstamos para ninguno de los días que contemplan las fechas actuales del rango. + +Para empezar te daré unos consejos: + +- Recuerda crear la tabla de la BBDD y sus datos +- Intenta primero hacer el listado paginado sin filtros, en el orden que más te guste: frontend o backend. Recuerda que se trata de un listado paginado, así que deberás utilizar el objeto Page. +- Completa el listado conectando ambas capas. +- Ahora implementa los filtros, presta atención al filtro de fecha, es el más complejo. +- Para la paginación filtrada solo tienes que mezclar los conceptos que hemos visto en los puntos del tutorial anteriores. +- Si hiciste el backend en Springboot recuerda revisar Baeldung por si tienes dudas sobre las queries y recuerda que las Specifications son muy útiles, pero en este caso deberás implementar otro tipo de operaciones, no te sirve solo con la operación de igualdad :, que ya vimos en el tutorial. +- Implementa la pantalla de alta de préstamo, sin ninguna validación. +- Cuando ya te funcione, intenta ir añadiendo una a una las validaciones. Algunas de ellas pueden hacerse en frontend, mientras que otras deberán validarse en backend +- Os recordamos que han de poder crearse y editarse préstamos según las reglas de validación indicadas anteriormente. Aplican las mismas reglas para ambas operaciones. +- El Backend ha de validar siempre, independientemente de que el Frontend ya lo haya validado. Nunca confíes de manera exclusiva en terceras partes (Frontend o en otro Backend). + + + + +Te voy a dar otras directrices que pienso que te pueden servir: +- Se necesita un CRUD de prestamos +- Debe tener una búsqueda y una paginación, todo en el mismo endpoint +- Fíjate en como están relacionadas las entidades del modelo ya que aquí tendrás que relacionar juego y cliente +- Tienes que implementar las validaciones dentro del método de guardado y creación y, siempre que se pueda, la validación se debe delegar en una query de BBDD. + + +Necesito que definas: + +1. Descripción de la funcionalidad + +2. Reglas de negocio + +3. Diseño backend: +- Endpoints necesarios +- Estructura del dominio (Entity, DTO, Service, Repository) + +4. Decisiones técnicas: +- Qué patrones del sistema actual se reutilizan + + +NO implementes código. +NO analices de nuevo el proyecto. +Basa la propuesta en los patrones detectados en la fase Explore. +Haz la propuesta únicamente de backend. +Como última tarea añade al fichero de tasks generar un resumen del cambio realizado, con el contrato de los endpoints y la información necesaria para que luego el frontend pueda implementar sus llamadas de forma sencilla. + +Tendrás que escribir los ficheros de proposal, design, spec y tasks en la propuesta correspondiente. + +``` + +Igual que en la gestión de clientes, este comando genera dentro del directorio ``changes`` la propuesta correspondiente, que incluye los siguientes ficheros: `proposal.md`, `design.md`, `spec.md`, `tasks.md`. + +Estos artefactos están adaptados a la funcionalidad de **gestión de préstamos**, incorporando las reglas de negocio, filtros y validaciones específicas de este caso de uso. + +Constituyen la base para la siguiente fase: **Apply**, donde se ejecutará la implementación siguiendo las tareas definidas. + +!!! tip "Responsabilidades como developer IA" + En este punto la IA te ha hecho una propuesta que puede ser correcta o no, recordemos que se trata de un modelo matemático-probabilístico. Si hay algo de lo propuesto que no te encaja o es erróneo deberías comentarlo mediante el chat o corregirlo de forma manual en el fichero que corresponda. Por ejemplo si quieres añadir una tarea porqué se te ha olvidado incluirla en el prompt original, deberías decirle al modelo que te incluya la nueva tarea. + +Una vez estemos de acuerdo con la propuesta que nos ha hecho la IA, podemos pasar al siguiente punto. + +### Apply + +Una vez validada la propuesta, ejecutamos la implementación: + +El objetivo de esta fase es transformar los artefactos generados +(`proposal.md`, `design.md`, `spec.md`, `tasks.md`) en **código funcional**, asegurando que: + +- Se respetan los requisitos funcionales definidos en `spec.md` +- Se siguen las decisiones técnicas establecidas en `design.md` +- Se ejecutan las tareas en el orden definido en `tasks.md` + +--- + +**📜 Prompt** + +Esto es tan fácil como escribir en el chat de ``Visual Studio Code`` el siguiente prompt: + +``` +/opsx:apply +``` + +El agente empezará a realizar un montón de tareas y pedirnos permisos. Es posible que algunas de esas tareas fallen y él mismo lo reintente de otra forma. El resultado debería ser el código generado e implementado dentro de la carpeta de ``backend`` y un resumen de todas las tareas realizadas y checkeadas por la IA. + +### Verificación del backend + +Un paso que no pertenece a OpenSpec pero que es altamente recomendable es probar los cambios realizados. +Arranca el backend y verifica: + +- Que el servidor levanta +- Que los endpoints existen y funcionan +- Que los tests pasan + +!!! warning "Ojo no te fies" + Ojo no te fies de todo lo que construya la IA. Tu estás al mando, tu debes decidir si el sistema está correctamente implementado o no. Es tu responsabilidad. + +Si **NO** estás a gusto con la implementación o se ha dejado algo por hacer, es el momento de escribirlo por el chat indicándole exactamente que es lo que falta. Cuanto más preciso y conciso seas, mejor implementará la IA. + + + + + +### Archive + +Y llegamos a la última etapa que nos define OpenSpec, donde se archiva el cambio y se da por finalizada la funcionalidad. + +El objetivo de esta fase es marcar la funcionalidad como completada, consolidar todos los artefactos generados durante el proceso y dejar el sistema en un estado estable, coherente y preparado para nuevas evoluciones. + +--- + +**📜 Prompt** + +De nuevo nos vamos al chat de ``Visual Studio Code`` el siguiente prompt: + +``` + +/opsx:archive + +``` + +Durante el proceso de Archive, el sistema solicitará confirmación para sincronizar los requisitos antes de archivar el cambio. + +Recuerda que al sincronizar, los requisitos definidos en `spec.md` pasan de ser un cambio temporal a formar parte permanente del sistema. + +Si no se sincroniza, el código queda implementado, pero los requisitos no se registran en los specs principales afectando a la trazabilidad y futuras evoluciones del sistema. + + +**📜 Actualización del contexto** + + +Además, para forzar al ``modelo gratuito`` y dejarlo todo listo, es recomendable lanzar un último prompt que nos actualice el fichero de `backend-explore.md` + +``` + +Actualiza el fichero de backend-explore con los nuevos datos implementados + +``` + + +## Generación de frontend + +Una vez implementado el backend, nos ponemos a trabajar con el frontend. De nuevo recordar que **es muy importante** que cada nuevo cambio que hagamos, lo empecemos en un chat nuevo, para limpiar el contexto anterior y no arrastrar posibles errores o incoherencias. + +### Explore + +Al igual que en backend, aquí también lanzamos una exploración del sistema por si hubiera algún cambio con respecto a la anterior versión. + +--- + +**📜 Prompt** + +Vamos **a un nuevo** chat de ``Visual Studio Code`` y escribimos el comando: + +``` + +/opsx:explore + +Analiza el proyecto actual que está en el directorio "frontend", es una aplicación Angular. Ojo no escanees la carpeta de "node_modules" no tiene sentido. Una vez analizado, responde: + +1. ¿Cómo están implementados los CRUD existentes? +- Componentes +- Servicios +- Modelos + +2. ¿Qué estructura siguen los dominios? + +3. ¿Cómo se implementan las operaciones? +- Listado +- Creación/edición +- Borrado +- Cómo funcionan las ventanas de creación y edición (modales) + +4. ¿Como se comunican frontend con backend? +- Servicios en Angular +- Construcción de URLs + +5. ¿Cómo se implementa la paginación? +- Consumo de datos paginados +- Integración en tablas + + +6. ¿Cómo se implementan los filtros en los listados? +- Especialmente en el catálogo de juegos +- Cómo se envían los filtros desde Angular + +7. ¿Cómo se cargan datos en combos (selects) en frontend? +- Servicios Angular utilizados +- Cómo se obtienen los datos +- Flujo de carga en componentes + + +8. ¿Qué patrones o estructuras comunes se repiten en los CRUD existentes? +- Clases reutilizables +- Lógica repetida +- Estructuras comunes entre dominios + + +Analiza únicamente la parte de frontend (Angular) +NO propongas soluciones. +NO diseñes nuevas funcionalidades. +Solo analiza el sistema actual. +Ya tienes un contexto previo en el fichero frontend-explore.md en el directorio de las specs, utilizalo y lo actualizas con lo que analices y no esté. + +``` + +Si te fijas en este explore hemos añadido tanto la paginación como los filtros. Al finalizar debería actualizar el fichero explore de frontend y además ofrecernos un resumen. + +### Propose + +Una vez analizado el sistema en la fase Explore, el siguiente paso es definir de forma clara y estructurada **la nueva funcionalidad a implementar**. + +**📜 Prompt** + +De nuevo en el chat de ``Visual Studio Code`` escribimos el siguiente prompt: + +``` + +/opsx:propose manage-loans-frontend + +Define la funcionalidad de gestión de préstamos de juegos basándote en el sistema actual y en los patrones identificados en la fase Explore, tienes el resultado en el fichero "frontend-explore.md". Además tendrás que ver el cambio realizado en la spec de "manage-loans-backend", sobre todo los endpoints generados. Por si acaso también deberías tener en cuenta el fichero de "backend-explore.md". + + +Nos han pedido esta nueva funcionalidad. + +Se quiere hacer uso de su catálogo de juegos y de sus clientes, y quiere saber que juegos ha prestado a cada cliente. Para ello nos ha pedido una página bastante compleja donde se podrá consultar diferente información y se permitirá realizar el préstamo de los juegos. + +Nos ha pasado el siguiente boceto y requisitos. + +La pantalla tendrá dos zonas: + +- Una zona de filtrado donde se permitirá filtrar por: + - Título del juego, que deberá ser un combo seleccionable con los juegos del catálogo de la Ludoteca. + - Cliente, que deberá ser un combo seleccionable con los clientes dados de alta en la aplicación. + - Fecha, que deberá ser de tipo Datepicker y que permitirá elegir una fecha de búsqueda. Al elegir un día nos deberá mostrar que juegos están prestados para dicho día. OJO que los préstamos son con fecha de inicio y de fin, si elijo un día intermedio debería aparecer el elemento en la tabla. +- Una zona de listado paginado que deberá mostrar + - El identificador del préstamo + - El nombre del juego prestado + - El nombre del cliente que lo solicitó + - La fecha de inicio del préstamo + - La fecha de fin del préstamo + - Un botón que permite eliminar el préstamo + + +Al pulsar el botón de Nuevo préstamo se abrirá una pantalla donde se podrá ingresar la siguiente información, toda ella obligatoria: +- Identificador, inicialmente vacío y en modo lectura +- Nombre del cliente, mediante un combo seleccionable +- Nombre del juego, mediante un combo seleccionable +- Fechas del préstamo, donde se podrá introducir dos fechas, de inicio y fin del préstamo. + +Las validaciones son sencillas aunque laboriosas: +- La fecha de fin NO podrá ser anterior a la fecha de inicio +- El periodo de préstamo máximo solo podrá ser de 14 días. Si el usuario quiere un préstamo para más de 14 días la aplicación no debe permitirlo mostrando una alerta al intentar guardar. +- El mismo juego no puede estar prestado a dos clientes distintos en un mismo día. OJO que los préstamos tienen fecha de inicio y fecha fin, el juego no puede estar prestado a más de un cliente para ninguno de los días que contemplan las fechas actuales del rango. +- Un mismo cliente no puede tener prestados más de 2 juegos en un mismo día. OJO que los préstamos tienen fecha de inicio y fecha fin, el cliente no puede tener más de dos préstamos para ninguno de los días que contemplan las fechas actuales del rango. + +Para empezar te daré unos consejos: + +- Recuerda crear la tabla de la BBDD y sus datos +- Intenta primero hacer el listado paginado sin filtros, en el orden que más te guste: frontend o backend. Recuerda que se trata de un listado paginado, así que deberás utilizar el objeto Page. +- Completa el listado conectando ambas capas. +- Ahora implementa los filtros, presta atención al filtro de fecha, es el más complejo. +- Para la paginación filtrada solo tienes que mezclar los conceptos que hemos visto en los puntos del tutorial anteriores. +- Si hiciste el backend en Springboot recuerda revisar Baeldung por si tienes dudas sobre las queries y recuerda que las Specifications son muy útiles, pero en este caso deberás implementar otro tipo de operaciones, no te sirve solo con la operación de igualdad :, que ya vimos en el tutorial. +- Implementa la pantalla de alta de préstamo, sin ninguna validación. +- Cuando ya te funcione, intenta ir añadiendo una a una las validaciones. Algunas de ellas pueden hacerse en frontend, mientras que otras deberán validarse en backend +- Os recordamos que han de poder crearse y editarse préstamos según las reglas de validación indicadas anteriormente. Aplican las mismas reglas para ambas operaciones. +- El Backend ha de validar siempre, independientemente de que el Frontend ya lo haya validado. Nunca confíes de manera exclusiva en terceras partes (Frontend o en otro Backend). + + + + +Te voy a dar otras directrices que pienso que te pueden servir: +- Se necesita un CRUD de prestamos +- Debe tener una búsqueda y una paginación, así que fíjate en como está hecho en otras pantallas +- Todo lo que se pueda tendrá que estar con componentes de tipo dropdown +- Es posible que tengas que implementar algún nuevo endpoint para rellenar los componentes dropdown, diseña eso también para el backend. + + +Necesito que definas: + +1. Descripción de la funcionalidad + +2. Reglas de negocio + +3. Diseño frontend: +- Componentes necesarios +- Flujos de interacción (listado, abrir modal, guardar borrar) + +4. Uso de endpoints para llamar a backend + +5. Decisiones técnicas: +- Qué patrones del sistema actual se reutilizan + + +NO implementes código. +NO analices de nuevo el proyecto. +Basa la propuesta en los patrones detectados en la fase Explore. +Haz la propuesta únicamente de frontend. +Olvídate de los test, en frontend no tenemos tests. +Añade el nuevo punto de menú en el header para que se pueda acceder. +No te inventes estilos, respeta los estilos de las pantallas (anchuras, alturas, colores, disposición de las tablas). +Utiliza los componentes de Angular Material para todo lo que puedas, no componentes nativos del navegador. + +Tendrás que escribir los ficheros de proposal, design, spec y tasks en la propuesta correspondiente. + + +``` + +Aquí es importante destacar que debe tener en cuenta: + +- debe coger el contexto generado anteriormente +- además, le debe sumar el contexto del último cambio de backend con los endpoints +- debe respetar estilos y componentes de Angular material y no inventar +- debe revisar como se rellenan los dropdown + +De nuevo este comando genera dentro del directorio ``changes`` la propuesta correspondiente, que incluye los siguientes ficheros: `proposal.md`, `design.md`, `spec.md`, `tasks.md`. Que deberemos revisar. + + +!!! tip "No nos cansaremos de decirlo" + Esta es la fase más importante, aquí es donde debes revisar toda la propuesta y si algo no te encaja o es erróneo deberías comentarlo mediante el chat o corregirlo de forma manual en el fichero que corresponda. Es tú responsabilidad. + +Una vez estemos de acuerdo con la propuesta que nos ha hecho la IA, podemos pasar al siguiente punto. + + +### Apply + +Una vez validado todo, pasamos a ejecutarlo. + +**📜 Prompt** + +Esto es tan fácil como escribir en el chat de ``Visual Studio Code`` el siguiente prompt: + +``` +/opsx:apply +``` + +El agente empezará a realizar un montón de tareas y pedirnos permisos. Es posible que algunas de esas tareas fallen y él mismo lo reintente de otra forma. El resultado debería ser el código generado e implementado tanto en la carpeta ``backend`` como en la carpeta ``frontend`` y un resumen de todas las tareas realizadas y checkeadas por la IA. + +### Verificación del frontend + +Un paso que no pertenece a OpenSpec pero que es altamente recomendable es probar los cambios realizados. + +Arranca el **backend** y el **frontend** y verifica: + +- La aplicación levanta correctamente +- Las nuevas funcionalidades añadidas están accesibles +- Los flujos principales definidos en `spec.md` funcionan como se espera + +!!! warning "Ojo no te fies" + Ojo no te fies de todo lo que construya la IA. Tu estás al mando, tu debes decidir si el sistema está correctamente implementado o no. Es tu responsabilidad. + +Si **NO** estás a gusto con la implementación o se ha dejado algo por hacer, es el momento de escribirlo por el chat indicándole exactamente que es lo que falta. Cuanto más preciso y conciso seas, mejor implementará la IA. + +### Archive + +Y llegamos a la última etapa que nos define OpenSpec, donde se archiva el cambio y se da por finalizada la funcionalidad. + +El objetivo de esta fase es marcar la funcionalidad como completada, consolidar todos los artefactos generados durante el proceso y dejar el sistema en un estado estable, coherente y preparado para nuevas evoluciones. + +--- + +**📜 Prompt** + +De nuevo nos vamos al chat de ``Visual Studio Code`` el siguiente prompt: + +``` +/opsx:archive +``` + +Durante el proceso de Archive, el sistema solicitará confirmación para sincronizar los requisitos antes de archivar el cambio. + +Recuerda que al sincronizar, los requisitos definidos en `spec.md` pasan de ser un cambio temporal a formar parte permanente del sistema. + +Si no se sincroniza, el código queda implementado, pero los requisitos no se registran en los specs principales afectando a la trazabilidad y futuras evoluciones del sistema. \ No newline at end of file diff --git a/docs/specs/loans_paid.md b/docs/specs/loans_paid.md new file mode 100644 index 0000000..a09b4ad --- /dev/null +++ b/docs/specs/loans_paid.md @@ -0,0 +1,444 @@ +# Gestión de préstamos (modelo con licencia) + +!!! warning Atención + Esta sección se encuentra en desarrollo 🚧. + **NO se recomienda realizarla** a menos que te lo hayan indicado expresamente. + +## Punto de partida + +Si has llegado hasta aquí, entiendo que ya has completado la funcionalidad de **gestión de clientes** utilizando el modelo con licencia. + +A partir de ahora vamos a dar por hecho que partimos de ese estado del sistema, donde: + +- Existe un CRUD funcional de clientes +- La funcionalidad está implementada, validada y archivada +- Los patrones de backend y frontend introducidos ya forman parte del sistema + +Una vez llegados a este punto, asumimos que el proyecto **ya está descargado y configurado**, y que hemos trabajado previamente sobre la funcionalidad de **gestión de clientes**. + +Por tanto, **continuaremos utilizando los mismos proyectos y directorios**, sin realizar ninguna instalación ni configuración adicional. + +En este tutorial seguiremos trabajando sobre: + +- ``server-springboot`` como **``backend``** +- ``client-angular17`` como **``frontend``** + +## Requisitos funcionales + +- Gestión de préstamos entre clientes y juegos. +- Listado paginado con filtros por juego, cliente y fecha. +- Alta/edición en modal con campos obligatorios (salvo identificador). +- Validaciones de fechas y restricciones de solapamiento. +- Máximo 14 días por préstamo. +- Un juego no puede estar prestado a dos clientes en el mismo día. +- Un cliente no puede tener más de dos préstamos activos en el mismo día. + +## Estrategia del modo con licencia + +Continuaremos trabajando con un **modelo de pago**, utilizando **``Claude Sonnet 4.6``** y el mismo workspace que en la funcionalidad de **gestión de clientes**. + +Antes de comenzar, ten en cuenta lo siguiente: + +- Para cada **nueva funcionalidad**, es recomendable iniciar una **nueva conversación de chat** dentro del mismo proyecto + +Esto ayuda a mantener el contexto limpio y a que el modelo se centre exclusivamente en la funcionalidad que vamos a abordar. + +Recuerda que en cualquier momento puedes ver el consumo mensual de tu cuenta pulsando el icono de la rana 🐸 en la esquina inferior derecha. El contador **se reinicia cada mes**. + +Vamos a abordar el ejercicio como un **único bloque de trabajo**, analizando y construyendo la funcionalidad de forma **simultánea en backend y frontend**. + +De esta manera aprovechamos el **mayor contexto** del modelo de pago, permitiendo: + +1. Analizar **``backend`` y ``frontend`` al mismo tiempo** +2. Diseñar la funcionalidad de forma coherente en ambas capas desde el inicio + +Esto nos permite mantener una visión global del sistema durante todo el proceso y reducir la necesidad de dividir artificialmente el trabajo en fases independientes por capa. + +Además, recuerda que el comportamiento del modelo **no es determinista**. Si a ti te genera algo diferente a lo que ves aquí, probablemente seguirá siendo válido. No te frustres y ajusta los prompts si es necesario. + +## Flujo de trabajo OpenSpec + +Seguiremos el ciclo completo de OpenSpec: + +``` +1. Explore +2. Propose +3. Apply +4. Archive +``` + +### Backend y frontend + +Aunque no es obligatorio, es altamente recomendable volver a ejecutar la fase de **``Explore``**. El sistema ha podido cambiar desde tu último cambio, alguien ha podido hacer modificaciones, etc. En tu caso no sería necesario ya que estás trabajando tu solo y no has cambiado nada, pero es buena práctica hacerlo siempre. + + +### Explore + +El objetivo de esta fase es **analizar el sistema existente**, sin modificar nada. + +A diferencia de la gestión de clientes, este caso de uso introduce una mayor complejidad, principalmente por: + +- Relaciones entre entidades (cliente, juego, préstamo) +- Uso de **paginación** en los listados +- Aplicación de **filtros combinados** +- Necesidad de **validaciones de negocio más complejas** + +En esta fase se analizará qué partes del sistema actual ya resuelven este tipo de problemas y pueden reutilizarse, y qué aspectos no están implementados y deberán abordarse en fases posteriores. + +Aspectos a revisar: + +**Paginación** + +- Cómo se implementa en backend (uso de Page) +- Cómo se consume en frontend +- Cómo se integra en tablas + +**Filtros** + +- Cómo se implementa en el catálogo de juegos +- Cómo se implementan filtros por rangos de fechas (si existen) +- DTOs de filtro utilizados +- Construcción de queries en backend +- Cómo se construyen queries con condiciones combinadas y operadores distintos de igualdad +- Cómo se envían los filtros desde Angular + +**Relaciones entre entidades** + +- Cómo se modelan relaciones en JPA +- Ejemplos existentes en el proyecto +- Cómo se representan en DTOs +- Cómo se cargan y exponen los datos relacionados + +**Validaciones en backend** + +- Dónde se implementan (Service) +- Cómo se gestionan errores +- Cómo se propagan al frontend +- Cómo se implementan validaciones sobre rangos de fechas +- Cómo se validan restricciones que dependen de registros existentes (solapamientos, límites por cliente, etc.) + +**Combos (selects) en frontend** +- Cómo se cargan datos (clientes, juegos) +- Uso de servicios Angular +- Flujo de carga en componentes + +⚠️ En esta fase: + +- **NO** se escribe código +- **NO** se diseña la solución +- **NO** se inventan estructuras nuevas + +Solo se analiza el **sistema actual**. + +--- + +**📜 Prompt** + +Lo que haremos será escribir en el chat de ``Visual Studio Code`` el comando y las instrucciones que queramos darle. ``Recuerda haber elegido Claude Sonnet 4.6 y estar trabajando en modo Agent``. + +En este caso, hemos añadido las carpetas del proyecto **``frontend`` y ``backend`` al contexto**, por lo que el análisis se realizará sobre **el sistema completo**. + +Para ello, desde el propio Chat de Copilot, pulsando el botón **“+”**, puedes seleccionar y añadir tanto **archivos individuales** como **directorios completos** del proyecto. También es posible añadirlos **arrastrándolos directamente al chat**. + +![Ventana de chat](../assets/images/specs-customer-paid_2.png) + +``` +/opsx:explore + +Analiza el proyecto actual (Angular 17 + Spring Boot) centrándote en las funcionalidades necesarias para implementar la gestión de préstamos y responde: + +1. ¿Cómo se implementa la paginación? +- Backend: uso de Page y construcción de respuestas paginadas +- Frontend: consumo de datos paginados +- Integración en tablas + +2. ¿Cómo se implementan los filtros en los listados? +- Especialmente en el catálogo de juegos +- DTOs de filtro utilizados +- Construcción de queries en backend +- Uso de condiciones combinadas (no solo igualdad) +- Ejemplos de filtros por rango de fechas (si existen) +- Ejemplos de consultas donde una fecha debe estar contenida dentro de un rango (si existen) +- Cómo se envían los filtros desde Angular + +3. ¿Cómo se gestionan relaciones entre entidades? +- Modelado en JPA +- Ejemplos en el proyecto +- Cómo se representan en DTOs +- Cómo se exponen los datos relacionados + +4. ¿Cómo se implementan validaciones en backend? +- Dónde se ubican (Service) +- Cómo se gestionan errores +- Cómo se propagan al frontend +- Si existen validaciones que dependan de múltiples registros o condiciones +- Si existen validaciones relacionadas con fechas o rangos +- Cómo se validan restricciones basadas en datos existentes + +5. ¿Cómo se cargan datos en combos (selects) en frontend? +- Servicios Angular utilizados +- Cómo se obtienen los datos +- Flujo de carga en componentes + +NO propongas soluciones. +NO diseñes la funcionalidad de préstamos. +NO repitas el análisis básico del sistema. +NO incluyas código completo. Resume la lógica cuando sea necesario. + +Céntrate únicamente en los aspectos necesarios para implementar la funcionalidad de gestión de préstamos. +``` + +Este comando realizará un análisis exhaustivo de tu sistema que servirá como base para definir la nueva funcionalidad en la siguiente fase. + +!!! tip "Sobre los permisos" + Es posible que durante el análisis te pida permiso para hacer ciertas tareas. Le puedes ir dando permiso una a una o darle permiso en todo el workspace, eso lo dejamos a tu elección. + +En cualquier momento puedes ver el consumo de la ventana de contexto para saber si todo el conocimiento del sistema está en memoria o no. En el icono de la gráfica circular que está situada en la parte inferior derecha del chat. + +![Ventana contexto](../assets/images/specs-customer-paid_3.png) + +### Propose + +Una vez analizado el sistema en la fase Explore, el siguiente paso es definir de forma clara y estructurada **la nueva funcionalidad a implementar**. + +En esta fase establecemos **qué vamos a construir**, apoyándonos en el conocimiento ya consolidado del sistema y en el resultado del Explore. + +Esta fase actúa como puente entre el análisis y la implementación, permitiendo diseñar la solución antes de escribir código y reduciendo el riesgo de errores durante el desarrollo. + +Durante esta fase debes especificar: + +**Descripción funcional** + +- Qué hace la funcionalidad +- Qué problema resuelve + +**Reglas de negocio** + +- Validaciones sobre fechas: + - La fecha de fin no podrá ser anterior a la fecha de inicio +- Restricciones de duración del préstamo: + - El período de préstamo máximo solo podrá ser de 14 días +- Validaciones de solapamiento de préstamos: + - El mismo juego no puede estar prestado a más de un cliente para ninguno de los días incluidos en el rango del préstamo +- Límites de préstamos simultáneos por cliente: + - Un mismo cliente no puede tener más de 2 préstamos activos para ninguno de los días incluidos en el rango del préstamo + +**Diseño backend** + +- Endpoints necesarios +- Estructura del dominio (Entity, DTO, Service, Repository) +- Tipo de operaciones (listado, creación, edición, borrado) +- Estrategia para filtros por fecha dentro de rangos + +**Diseño frontend** + +- Componentes necesarios +- Flujo de usuario (listado, abrir modal, guardar, borrar) +- Servicios Angular +- Gestión de combos (clientes y juegos) +- Integración de filtros y paginación +- Integración de Datepicker para filtro por fecha +- Estructura de pantalla: + - **Listado**, seguirá la estructura general de las pantallas ya existentes, reutilizando: + - Patrón de filtros de catálogo. Para este caso, se permitirá filtrar por: + - Título del juego (combo) + - Cliente (combo) + - Fecha (Datepicker): la fecha seleccionada debe estar contenida entre la fecha de inicio y la fecha de fin del préstamo + - Patrón de paginación del listado de autores + - El orden de las columnas del listado será: + - Identificador + - Nombre del juego + - Nombre del cliente + - Fecha de préstamo + - Fecha de devolución + - Las fechas se mostrarán siempre en formato DD/MM/YYYY + - **Alta/edición**: + - El identificador aparecerá vacío en creación y en modo solo lectura + - Debajo se mostrará el campo de nombre de cliente (combo seleccionable) + - Debajo se mostrará el campo de nombre de juego (combo seleccionable) + - Debajo se mostrará la sección de fechas de préstamo: la fecha de inicio y la fecha de fin estarán en la misma fila + - Todos los campos, salvo el identificador, serán obligatorios + +**Decisiones técnicas** + +- Qué patrones existentes se reutilizan +- Qué partes deben extenderse +- Cómo se gestionarán los filtros de fecha y condiciones combinadas +- Cómo se implementarán validaciones basadas en múltiples registros (solapamientos y límites) + +**Plan de implementación** + +- Tareas ordenadas +- Separación backend / frontend +- Prioridad de desarrollo (listado → filtros → validaciones) + +Aquí dejamos claro: + +- Qué funcionalidad se va a añadir +- Qué reglas de negocio existen +- Qué piezas del sistema se ven afectadas +- Qué tareas habrá que ejecutar + +⚠️ En esta fase: + +- **NO** se implementa código +- **NO** se redefine el sistema + +--- + +**📜 Prompt** + +Recuerda que seguimos trabajando en **modo Agent**, con las carpetas del proyecto **``frontend`` y ``backend`` añadidas al contexto**. + +Para nuestro ejemplo, lo que haremos será escribir en el chat de ``Visual Studio Code`` el siguiente prompt: + +``` +/opsx:propose loan + +Define la funcionalidad de gestión de préstamos basándote en el sistema actual (Angular 17 + Spring Boot), en los patrones identificados en la fase Explore y en los requisitos funcionales indicados. + +Requisitos funcionales: +- Se necesita una funcionalidad de gestión de préstamos + +- Un préstamo relaciona un cliente y un juego + +- El listado será paginado + +- Existirá una zona de filtros en la parte superior del listado + +- Se podrá filtrar por: + - Juego (combo seleccionable) + - Cliente (combo seleccionable) + - Fecha (Datepicker) + +- La fecha seleccionada deberá estar contenida entre la fecha de inicio y la fecha de fin del préstamo para que el registro aparezca en el listado + +- El listado deberá mostrar: + - Identificador + - Nombre del juego + - Nombre del cliente + - Fecha de préstamo + - Fecha de devolución + +- Las fechas se mostrarán en formato DD/MM/YYYY + +- Existirá una pantalla modal de alta / edición + +- En alta / edición: + - El identificador aparecerá vacío en creación y en modo solo lectura + - Se seleccionará cliente mediante combo + - Se seleccionará juego mediante combo + - Se introducirán fecha de inicio y fecha de fin en la misma fila + - Todos los campos, salvo el identificador, serán obligatorios + +Reglas de negocio: +- La fecha de fin no podrá ser anterior a la fecha de inicio +- El período máximo del préstamo será de 14 días +- El mismo juego no podrá estar prestado a más de un cliente para ninguno de los días incluidos en el rango del préstamo +- Un mismo cliente no podrá tener más de 2 préstamos activos para ninguno de los días incluidos en el rango del préstamo +- Las mismas validaciones aplican tanto en creación como en edición +- El backend deberá validar siempre, aunque el frontend también realice validaciones + +Define: + +1. Descripción de la funcionalidad + +2. Reglas de negocio + +3. Diseño backend: +- Endpoints necesarios +- Estructura del dominio (Entity, DTO, Service, Repository) +- Tipo de operaciones (listado, creación, edición, borrado) +- Estrategia para filtros por fecha dentro de rangos + +4. Diseño frontend: +- Componentes necesarios +- Flujo de interacción (listado, abrir modal, guardar, borrar) +- Servicios Angular +- Gestión de combos (clientes y juegos) +- Integración de filtros y paginación +- Integración de Datepicker para filtro por fecha +- Estructura funcional del listado y del formulario de alta/edición + +5. Decisiones técnicas: +- Qué patrones del sistema actual se reutilizan +- Qué partes deben extenderse +- Cómo se gestionarán los filtros de fecha y condiciones combinadas +- Cómo se implementarán validaciones basadas en múltiples registros (solapamientos y límites) + +NO implementes código. +NO analices de nuevo el proyecto. +Basa la propuesta en los patrones detectados en la fase Explore. + +``` + +Igual que en la gestión de clientes, este comando genera dentro del directorio ``changes`` la propuesta correspondiente, que incluye los siguientes ficheros: `proposal.md`, `design.md`, `spec.md`, `tasks.md`. + +Estos artefactos están adaptados a la funcionalidad de **gestión de préstamos**, incorporando las reglas de negocio, filtros y validaciones específicas de este caso de uso. + +Constituyen la base para la siguiente fase: **Apply**, donde se ejecutará la implementación siguiendo las tareas definidas. + +!!! tip "Responsabilidades como developer IA" + En este punto la IA te ha hecho una propuesta que puede ser correcta o no, recordemos que se trata de un modelo matemático-probabilístico. Si hay algo de lo propuesto que no te encaja o es erróneo deberías comentarlo mediante el chat o corregirlo de forma manual en el fichero que corresponda. Por ejemplo si quieres añadir una tarea porqué se te ha olvidado incluirla en el prompt original, deberías decirle al modelo que te incluya la nueva tarea. + +Una vez estemos de acuerdo con la propuesta que nos ha hecho la IA, podemos pasar al siguiente punto. + +### Apply + +Una vez validada la propuesta, ejecutamos la implementación: + +El objetivo de esta fase es transformar los artefactos generados +(`proposal.md`, `design.md`, `spec.md`, `tasks.md`) en **código funcional**, asegurando que: + +- Se respetan los requisitos funcionales definidos en `spec.md` +- Se siguen las decisiones técnicas establecidas en `design.md` +- Se ejecutan las tareas en el orden definido en `tasks.md` + +--- + +**📜 Prompt** + +Esto es tan fácil como escribir en el chat de ``Visual Studio Code`` el siguiente prompt: + +``` +/opsx:apply +``` + +El agente empezará a realizar un montón de tareas y pedirnos permisos. Es posible que algunas de esas tareas fallen y él mismo lo reintente de otra forma. El resultado debería ser el código generado e implementado tanto en la carpeta ``backend`` como en la carpeta ``frontend`` y un resumen de todas las tareas realizadas y checkeadas por la IA. + +### Verificación + +Un paso que no pertenece a OpenSpec pero que es altamente recomendable es probar los cambios realizados. + +Arranca el **backend** y el **frontend** y verifica: + +- La aplicación levanta correctamente +- Las nuevas funcionalidades añadidas están accesibles +- Los flujos principales definidos en `spec.md` funcionan como se espera + +!!! warning "Ojo no te fies" + Ojo no te fies de todo lo que construya la IA. Tu estás al mando, tu debes decidir si el sistema está correctamente implementado o no. Es tu responsabilidad. + +Si **NO** estás a gusto con la implementación o se ha dejado algo por hacer, es el momento de escribirlo por el chat indicándole exactamente que es lo que falta. Cuanto más preciso y conciso seas, mejor implementará la IA. + +### Archive + +Y llegamos a la última etapa que nos define OpenSpec, donde se archiva el cambio y se da por finalizada la funcionalidad. + +El objetivo de esta fase es marcar la funcionalidad como completada, consolidar todos los artefactos generados durante el proceso y dejar el sistema en un estado estable, coherente y preparado para nuevas evoluciones. + +--- + +**📜 Prompt** + +De nuevo nos vamos al chat de ``Visual Studio Code`` el siguiente prompt: + +``` +/opsx:archive +``` + +Durante el proceso de Archive, el sistema solicitará confirmación para sincronizar los requisitos antes de archivar el cambio. + +Recuerda que al sincronizar, los requisitos definidos en `spec.md` pasan de ser un cambio temporal a formar parte permanente del sistema. + +Si no se sincroniza, el código queda implementado, pero los requisitos no se registran en los specs principales afectando a la trazabilidad y futuras evoluciones del sistema. \ No newline at end of file diff --git a/docs/specs/prepare.md b/docs/specs/prepare.md new file mode 100644 index 0000000..43c5587 --- /dev/null +++ b/docs/specs/prepare.md @@ -0,0 +1,127 @@ +# Preparación del entorno + +!!! warning Atención + Esta sección se encuentra en desarrollo 🚧. + **NO se recomienda realizarla** a menos que te lo hayan indicado expresamente. + +En esta sección asumimos que ya completaste el tutorial base y que el entorno de Angular y Spring Boot está configurado. + +También es recomendable haber hecho el ejercicio **`Ahora hazlo tu!`** para que el contexto funcional te resulte familiar. + +Partimos, por tanto, de un entorno con las herramientas básicas ya instaladas. + +Daremos por hecho que ya dispones de: + +- **Visual Studio Code** +- **Node.js** +- **Angular CLI** +- **Java (17 o superior)** + +Estas herramientas son **prerrequisitos** y aquí no repetiremos su instalación en detalle. + +!!! info "Info" + Si alguna de estas herramientas no está instalada o necesitas revisar el proceso completo de configuración, puedes consultar los siguientes apartados del tutorial: + + - Entorno de desarrollo – Angular + - Entorno de desarrollo – Spring Boot + +--- + +## Prerrequisitos técnicos + +Vamos a preparar el entorno para trabajar con **Spec-Driven Development** usando **OpenSpec** desde **Visual Studio Code**, en un único workspace con frontend, backend y especificaciones. + +--- + +### Verificación de Node.js + +OpenSpec se distribuye como una herramienta basada en Node.js, por lo que es necesario tener instalado **Node.js 20.19.0 o superior**. + +Para comprobar la versión instalada, ejecuta en una terminal: + +``` +node --version +``` + +Si no tienes Node.js instalado o tu versión es inferior, puedes descargarlo desde su [web oficial](https://nodejs.org/). + +Se recomienda instalar la versión LTS más reciente. + +Si tienes restricciones de permisos en el portátil, también es posible instalar Node.js a través del Portal de Empresa, siguiendo el mismo procedimiento utilizado durante la configuración del Entorno de desarrollo para el tutorial: + +1. Accede al Portal de Empresa +2. Entra en el catálogo de aplicaciones pre‑aprobadas +3. Busca Node.js +4. Instálalo desde ahí + +Una vez finalizada la instalación, vuelve a ejecutar el comando `node --version` para verificar que Node.js está correctamente instalado. + +--- + +### Instalación de OpenSpec + +OpenSpec se puede instalar de forma global con cualquier gestor compatible con Node.js. + +Si utilizas **npm**, ejecuta el siguiente comando: + +``` +npm install -g @fission-ai/openspec@latest +``` + +!!! info "Info" + OpenSpec también es compatible con `pnpm`, `yarn` o `bun`. En esta guía usaremos `npm` por simplicidad. + +Una vez finalizada la instalación, verifica que OpenSpec está correctamente instalado ejecutando: +``` +openspec --version +``` + +Si el comando responde correctamente mostrando la versión instalada, el entorno ya está preparado para trabajar con Spec‑Driven Development utilizando OpenSpec. + + +## Convenciones de trabajo (aplican a todos los ejercicios) + +### GitHub Copilot + +Necesitas una cuenta de GitHub con Copilot (gratuita o premium) y haber iniciado sesión en `Visual Studio Code` para usar el chat. + + +### Estructura inicial del proyecto + +A partir de aquí necesitas los proyectos base (*sin el ejercicio hecho*). +Si no los tienes, puedes descargarlos en [https://github.com/ccsw-csd/tutorial-proyectos](https://github.com/ccsw-csd/tutorial-proyectos). + + +En esta guía vamos a usar `server-springboot` y `client-angular17`. Ambos deben estar en el mismo directorio raíz. Para simplificar, durante todo el documento, los llamaremos: + +- **`backend`** +- **`frontend`** + +La estructura debería ser similar a esta: + +![workspace](../assets/images/specs-install_1.png) + + +### Reglas generales y de ejecución + +Durante todos los ejercicios: + +- Empieza cada cambio relevante en un chat nuevo para no arrastrar contexto innecesario. +- Revisa siempre la propuesta antes de ejecutar la fase de `Apply`. +- Valida manualmente los resultados funcionales después de aplicar. + +### ¿Y ahora qué? + +A partir de aquí eliges ruta: + +- Con licencia de pago 💰 tendrás más contexto y menos fragmentación. +- Con licencia gratuita 🆓 tendrás menos contexto y más iteraciones. Además es posible que superes las limitaciones diarias o de hora y tengas que esperar al día siguiente para continuar con el tutorial. + +El flujo funcional es el mismo en ambos casos. + +Elige tu camino: + +- [🆓 Gestión de clientes](./customers_free.md) +- [🆓 Gestión de préstamos](./loans_free.md) +- [💰 Gestión de clientes](./customers_paid.md) +- [💰 Gestión de préstamos](./loans_paid.md) diff --git a/mkdocs.yml b/mkdocs.yml index 07f7572..d68fd7c 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -38,11 +38,14 @@ nav: - 🟢 Spring Boot: develop/filtered/springboot.md - 🟢 Nodejs: develop/filtered/nodejs.md - Ahora hazlo tú!: exercise.md + - Spec Driven Development: + - Introducción: specs/intro.md + - Preparación entorno: specs/prepare.md + - 🆓 Gestión de clientes: specs/customers_free.md + - 🆓 Gestión de préstamos: specs/loans_free.md + - 💰 Gestión de clientes: specs/customers_paid.md + - 💰 Gestión de préstamos: specs/loans_paid.md - "Anexos": - - "GIT: Tutorial básico": appendix/git.md - - API Rest: appendix/rest.md - - TDD: appendix/tdd.md - - "Spring Data: JPA": appendix/jpa.md - Spring Cloud: - Introducción: appendix/springcloud/intro.md - Listado simple: appendix/springcloud/basic.md @@ -57,12 +60,16 @@ nav: - Limpieza: appendix/springbatch/clean.md - Resumen: appendix/springbatch/summary.md - Ahora hazlo tú!: appendix/springbatch/exercise.md + - "Spring Data: JPA": appendix/jpa.md - Dockerízate: - Instalar docker: appendix/docker/installdocker.md - ¿Qué es docker?: appendix/docker/docudocker.md - Practiquemos: appendix/docker/traindocker.md - Resumen: appendix/docker/summary.md - AWS CLI: appendix/aws.md + - "GIT: Tutorial básico": appendix/git.md + - API Rest: appendix/rest.md + - TDD: appendix/tdd.md - Multidioma: appendix/multilanguage.md - Fechas: appendix/dates.md theme: