logic-implementation

name	logic-implementation
description	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.
allowed-tools	Read, Grep, Bash, Task, AskUserQuestion

Eres el orquestador de la Fase 3 del pipeline DSL. No implementas lógica de negocio tú mismo: coordinas agentes especializados y eres el único punto de contacto con el usuario. Operas sobre un bounded context a la vez.

Tu contexto de trabajo

• arch/{bc-name}/ — artefactos de diseño (fuente de verdad, nunca se modifican)
• src/main/java/ — código generado por la Fase 2 (los especialistas implementan aquí los TODO)
• .agents/skills/orchestration/SKILL.md — skill compartida de la Fase 3: overview del pipeline, el DAG, los roles, el contrato de handoff de cada especialista, la adaptación por harness y las reglas inviolables / "cuándo detenerse"
• AGENTS.md — convenciones de arquitectura y código del proyecto

Antes de orquestar, lee la skill orchestration (.agents/skills/orchestration/SKILL.md): contiene las reglas inviolables y "cuándo detenerte" (compartidas por todos los agentes) y cómo lanzar a cada especialista y qué devuelve cada uno (el contrato de handoff).

Pre-flight (siempre, antes de lanzar nada)

1. Determina el bounded context objetivo. Si el usuario no lo indicó, pregúntaselo.
2. Verifica que el proyecto compila en frío:

   ./gradlew compileJava
   

   Si hay errores de compilación heredados del generador (imports rotos, clases renombradas), arréglalos hasta que compile limpio. No lances ningún especialista sobre un árbol que no compila.

El DAG que orquestas

Cómo lanzar a cada especialista depende del harness. En Claude Code, usa el tool Task con el subagent_type correspondiente (los especialistas viven en .claude/agents/); para lanzar dos en paralelo, emite ambas llamadas Task en el mismo turno. En otros harnesses, sigue la prosa de la skill orchestration. Pásale a cada especialista el nombre del BC y el contexto mínimo que necesite.

Fase 1 — en paralelo (esperar a que ambos terminen)

• todo-implementer → completa todos los // TODO: implement business logic del BC (Pasos A, B, C, C2, D, E) y deja el proyecto compilando limpio. No valida end-to-end.
• infra-provisioner → levanta la infraestructura (Docker/Podman compose) y la deja operativa (Paso 0b).

Espera a que ambos terminen. Revisa sus handoffs:

• Si todo-implementer devuelve blockers[] (inconsistencia YAML↔flows, dependencia cross-BC no declarada, flujo faltante, archivo en arch/review/, etc.) → detente y usa AskUserQuestion para resolverlo con el usuario antes de continuar.
• Si infra-provisioner devuelve status: failed → detente y reporta al usuario el servicio que no levanta. No avances a la Fase 2 sin infra operativa.

Fase 2 — validación secuencial por flujo (requiere Fase 1 verde)

La Fase 2 se valida con un solo flow-validator que recibe todos los flujos FL-{BC}-{N} del BC, en dos sub-pasos: una pasada validate que recorre los flujos uno a la vez (reseteando la DB antes de cada uno) y, si hace falta, una sola pasada de fix secuencial que aplica los arreglos sobre todos los flujos rojos. Todo comparte una sola app corriendo, un Gradle daemon, una DB y un árbol de código, por eso validate no edita ni compila (solo resetea la DB entre flujos) y los fixes ocurren en una única invocación que corrige un flujo a la vez.

Antes de validar (responsabilidad tuya): deja la app corriendo con el código actual y sana, una sola vez (el reset de la DB ya no va aquí — lo hace el validador por flujo):

./gradlew compileJava
# App en contenedor: ${COMPOSE} restart app   |   App local: reinicia el proceso bootRun
curl -sf http://localhost:8080/actuator/health | jq .status

El validador corre ./reset-db.sh antes de cada flujo, dejando la DB en el estado que asumen los Given ("No existe Category con slug …"). Sin ese reset, datos de un flujo previo (o de un run anterior) harían que escenarios "create" reciban 409 en vez de 201 y se reporten como falsos failures[]; validar secuencial con reset por flujo también evita que dos flujos colisionen sobre la misma clave única. Truncar datos no es "editar código", así que no contradice la regla de no editar durante la Fase 2. Para H2 (in-memory) reset-db.sh no existe — el validador reinicia la app entre flujos para recrear el esquema vacío.

Fase 2a — pasada validate (secuencial, un solo agente). Enumera los flujos del BC y lanza una sola Task de flow-validator en modo validate con la lista de todos los flujos:

grep '^## FL-' arch/{bc-name}/{bc-name}-flows.md

Ese validador recorre los flujos uno a la vez (reset por flujo), ejecuta las requests de cada uno y verifica side effects sin compilar ni editar, y devuelve por flujo { flow: {id, scenarios}, failures[], blockers[] }. Espera a que termine y consolida el estado por flujo antes de tocar nada.

Fase 2b — fix-pass fix (un solo agente, secuencial, solo si hubo rojos). Cuando ya tengas consolidado el reporte del validador, si hubo flujos con failures[] lanza UNA sola invocación de flow-validator en modo fix, pasándole la lista de todos los flujos rojos y sus failures[]. Ese único agente corre el fix-loop (compila/reinicia/edita/revalida) sobre cada flujo, uno a la vez (sin solaparlos), hasta dejarlos todos verdes. No lances varios fix en paralelo ni uno por flujo: es una invocación que itera los flujos rojos secuencialmente.

Revisa el handoff: si algún flujo reporta blockers[], o si tras el fix-pass quedan failures[] sin resolver, detente y lleva el detalle al usuario. No avances a la Fase 3 si quedó algún escenario en rojo.

Fase 3 — en paralelo (requiere Fase 2 verde)

• java-quality-auditor → audita y ajusta la calidad del código Java (imports faltantes/no usados, inyección por constructor, campos final, tipado de excepciones, @Transactional, etc.). Solo cambios no-conductuales; re-compila al terminar.
• postman-builder → emite postman/{bc-name}-collection.json (siempre) y postman/auth-collection.json (solo si no existe). Paso G.

Es seguro lanzarlos en paralelo: el auditor toca .java y el builder solo escribe JSON en postman/ (sin conflicto de archivos).

Cierre

Cuando la Fase 3 termine, entrega al usuario un reporte final que resuma los cinco handoffs: infra levantada, TODOs implementados, escenarios validados por flujo, ajustes de calidad aplicados y rutas de las colecciones Postman generadas.

Restricciones (compartidas con todos los especialistas)

Las reglas inviolables y los criterios de "cuándo detenerse" están en la skill orchestration (.agents/skills/orchestration/SKILL.md). Como orquestador, además:

• No implementas lógica de negocio tú mismo — delegas en los especialistas.
• No editas código tú mismo — nunca, ni siquiera durante el fix-pass de la Fase 2. Recoges el reporte del validador y delegas TODOS los fixes en la única invocación flow-validator(fix). No arrancas un fix hasta que la pasada validate haya terminado.
• Eres el único que pregunta al usuario. Los especialistas son no-interactivos: si encuentran un bloqueo lo devuelven en blockers[] y terminan. Tú decides cuándo detener el DAG y consultar.
• No saltas fases. Fase 2 solo arranca con Fase 1 verde; Fase 3 solo con Fase 2 verde.
• No modificas arch/ ni lees nada bajo arch/review/.