dsl-springboot-generator

Valida end-to-end TODOS los escenarios (A, B, C…) de los flujos `FL-{BC}-{N}` de `{bc}-flows.md` contra la aplicación corriendo y la infraestructura real (DB, cache, broker, storage): ejecuta la request de cada escenario y verifica el status y los side effects esperados (o su ausencia). Opera en dos modos: `validate` (secuencial: recorre los flujos uno a uno reseteando la DB antes de cada uno; ni compila ni edita) y `fix` (serial: el fix-loop completo hasta que el flujo pasa). La usa el especialista `flow-validator`. Úsala cuando necesites probar un flujo de un BC end-to-end, validar escenarios de error/borde, o confirmar que un UC está realmente "completado" (no solo compilando).

Punto de entrada de la Fase 3 del pipeline DSL: orquesta la implementación completa de un bounded context generado por la Fase 2 lanzando agentes especialistas en un DAG (Fase 1 en paralelo: `todo-implementer` completa los `// TODO: implement business logic` e `infra-provisioner` levanta la infraestructura; Fase 2: un `flow-validator` en modo `validate` recorre secuencialmente todos los flujos —reseteando la DB antes de cada uno— y, si hay rojos, una única pasada `fix` secuencial que un solo agente aplica sobre todos los flujos rojos, validando todos los escenarios de cada flujo; Fase 3 en paralelo: `java-quality-auditor` audita la calidad Java y `postman-builder` emite las colecciones Postman). Es el único interlocutor con el usuario. Esta skill debe usarse cuando el usuario diga "implementa el BC X", "completa los TODO del bounded context Y", "fase 3 para el BC Z", "implementa la lógica de negocio de X", o pida finalizar la Fase 3 de un scaffold generado.

Referencia compartida de la Fase 3 del pipeline DSL, consultada por la skill de orquestación `logic-implementation` (el punto de entrada del usuario) y por los agentes especialistas. Define el DAG multi-agente, los roles, el contrato de handoff entre orquestador y especialistas, la adaptación por harness y —para TODOS los agentes— las reglas inviolables y los criterios de "cuándo detenerse". No es el punto de entrada del usuario: esta skill debe consultarse cuando se necesite coordinar el DAG de la Fase 3, conocer qué recibe y devuelve cada especialista, o aplicar las reglas compartidas al implementar o validar un bounded context.

Soporte para completar los // TODO de lógica de negocio (handlers, aggregates y domain services) de un bounded context generado por la Fase 2. Reúne las guías de detalle del especialista `todo-implementer`: cómo leer los artefactos de diseño (`{bc}.yaml` / `{bc}-flows.md`), cuándo y cómo extraer domain services, cuándo usar concurrencia con hilos virtuales y cómo integrar el almacenamiento de objetos. Úsala al implementar la lógica de negocio de un BC, completar handlers con `UnsupportedOperationException`, o decidir si un caso requiere domain service / hilos virtuales / storage.

Levanta y verifica la infraestructura local de un proyecto Spring Boot generado por la Fase 2 (base de datos, broker, cache, Keycloak, MinIO…) con Docker o Podman, y provee el cheatsheet de comandos CLI exactos por servicio para comprobar su estado. La usan el especialista `infra-provisioner` (Paso 0b) y el `flow-validator` (para verificar side effects). Úsala cuando necesites arrancar el compose, comprobar que un servicio está operativo, o consultar el comando CLI exacto de `psql`/`mysql`/`sqlcmd`/`sqlplus`, `kcat`, `redis-cli`, `mc`, o el health de Keycloak/RabbitMQ.

Genera las colecciones Postman de un bounded context ya validado: `postman/{bc}-collection.json` (una carpeta por flujo `FL-{BC}-{N}`, una request por escenario A/B/C…, más una carpeta CRUD con los endpoints triviales del OpenAPI) y `postman/auth-collection.json` (compartido entre BCs, una request de token por rol — solo se crea si no existe). La usa el especialista `postman-builder`. Úsala cuando necesites emitir/regenerar colecciones Postman reutilizables para revalidar los flujos de un BC manualmente.

Audita y ajusta la calidad del código Java de un bounded context ya implementado y validado: imports faltantes o sin usar, inyección de dependencias por constructor, campos `final`, tipado de excepciones de dominio, uso correcto de `@Transactional`, convenciones de `AGENTS.md` (sin Lombok ni setters en dominio). Aplica **solo cambios no-conductuales** que preserven el comportamiento ya validado por `flow-validator`, y define la frontera "no-conductual vs conductual". La usa el especialista `java-quality-auditor`. Úsala al pulir/limpiar el código Java de un BC sin cambiar su comportamiento.