plan

Prompt file imported from geovannymcode/sdd-kotlin-vaadin (.claude/commands/plan.md). Fill in {{arguments}} before use. Copyright stays with the author.

/plan {{arguments}}

Lee .specs/{{arguments}}/01-spec.md y su review. Descompón el feature en tareas pequeñas, cada una atada a sus criterios de aceptación.

Escribe estos artefactos en .specs/{{arguments}}/:

• 03-design.md: la arquitectura. Capas, paquete por feature, split api / internal dentro de com.baqjug.sdd.customer. Customer es una entidad JPA, no un agregado. El contrato REST y cómo la UI de Vaadin llama al servicio en la misma JVM.
• 04-tasks.md: las tareas en dos tracks. Backend T-001 (persistencia) → T-002 (servicio) → T-003 (HTTP). Frontend Vaadin T-004 (form) → T-005 (validación) → T-006 (wiring). Cada tarea lista sus archivos, sus AC y su test.
• adr/ADR-001-feature-package-structure.md: el split api/internal. Nota que en Kotlin no hay package-private, así que el límite es convención reforzada con ArchUnit.
• adr/ADR-002-email-uniqueness-strategy.md: chequeo proactivo en el servicio + unique constraint en la BD.
• .tdd-state.json: las tareas con phase: "pending" y active_task: null.

Mapea cada tarea a archivos Kotlin reales:

• T-001: customer/internal/Customer.kt, customer/internal/CustomerRepository.kt, db/migration/V1__*.sql.
• T-002: customer/api/CustomerService.kt, customer/api/CustomerRequest.kt, customer/api/CustomerResponse.kt, customer/api/DuplicateEmailException.kt, customer/internal/CustomerServiceImpl.kt.
• T-003: customer/api/CustomerController.kt, customer/api/CustomerExceptionHandler.kt.
• T-004 a T-006: customer/ui/MainLayout.kt, customer/ui/CustomerFormModel.kt, customer/ui/CustomerCreateView.kt.

Como el contrato queda en el diseño, los dos tracks pueden arrancar al tiempo. Al final, muestra la cadena de dependencias y di que el siguiente paso es /build T-001.