eva4j 1.0.14 → 1.0.16

package/examples/system.yaml

@@ -206,7 +206,9 @@ integrations:
       topic: RESERVATION_CREATED
       consumers:
         - module: payments
+          useCase: HandleReservationCreated
         - module: notifications
+          useCase: NotifyReservationCreated
 
     # Pago aprobado → reserva debe confirmarse; cliente recibe confirmación
     - event: PaymentApprovedEvent
@@ -214,7 +216,9 @@ integrations:
       topic: PAYMENT_APPROVED
       consumers:
         - module: reservations
+          useCase: ConfirmReservation
         - module: notifications
+          useCase: NotifyPaymentApproved
 
     # Pago rechazado → reserva debe expirar y liberar asientos; cliente recibe aviso
     - event: PaymentRejectedEvent
@@ -222,22 +226,41 @@ integrations:
       topic: PAYMENT_REJECTED
       consumers:
         - module: reservations
+          useCase: ExpireReservation
         - module: notifications
+          useCase: NotifyPaymentRejected
 
-    # Reserva confirmada → se emiten los tickets QR y se envían al cliente
+    # Reserva confirmada → se emiten los tickets QR y se envían al cliente; cliente acumula puntos de fidelidad
     - event: ReservationConfirmedEvent
       producer: reservations
       topic: RESERVATION_CONFIRMED
       consumers:
         - module: notifications
+          useCase: NotifyReservationConfirmed
+        - module: customers     # acumula loyalty points al confirmar reserva
+          useCase: AccumulateLoyaltyPoints
 
-    # Reserva cancelada → pagos evalúa reembolso; cliente recibe notificación
+    # Reserva cancelada → pagos evalúa reembolso; screenings libera asientos; cliente recibe notificación
     - event: ReservationCancelledEvent
       producer: reservations
       topic: RESERVATION_CANCELLED
       consumers:
-        - module: payments
+        - module: payments        # evalúa si aplica reembolso
+          useCase: ProcessRefund
+        - module: screenings      # libera ScreeningSeats → AVAILABLE (también cubre unlock de sala privada)
+          useCase: ReleaseScreeningSeats
         - module: notifications
+          useCase: NotifyReservationCancelled
+
+    # Reserva expirada por timeout (sin pago) → screenings libera asientos; cliente recibe aviso (sin reembolso)
+    - event: ReservationExpiredEvent
+      producer: reservations
+      topic: RESERVATION_EXPIRED
+      consumers:
+        - module: screenings      # libera ScreeningSeats → AVAILABLE
+          useCase: ReleaseScreeningSeats
+        - module: notifications   # avisa al cliente que su tiempo de bloqueo expiró
+          useCase: NotifyReservationExpired
 
     # Función cancelada → reservas libera asientos y expira reservas activas; clientes notificados
     - event: ScreeningCancelledEvent
@@ -245,7 +268,9 @@ integrations:
       topic: SCREENING_CANCELLED
       consumers:
         - module: reservations
+          useCase: CancelReservationsByScreening
         - module: notifications
+          useCase: NotifyScreeningCancelled
 
     # ★ NUEVO — Reserva de evento privado creada → screenings bloquea la sala; payments inicia cobro total; notifications avisa
     - event: PrivateEventReservationCreatedEvent
@@ -253,8 +278,11 @@ integrations:
       topic: PRIVATE_EVENT_RESERVATION_CREATED
       consumers:
         - module: screenings
+          useCase: LockScreeningForPrivateEvent
         - module: payments
+          useCase: InitiatePrivateEventPayment
         - module: notifications
+          useCase: NotifyPrivateEventReservationCreated
 
     # ★ NUEVO — Sala bloqueada exitosamente → notifications confirma al organizador del evento
     - event: TheaterLockedForPrivateEventEvent
@@ -262,8 +290,23 @@ integrations:
       topic: THEATER_LOCKED_FOR_PRIVATE_EVENT
       consumers:
         - module: notifications
+          useCase: NotifyTheaterLockedForPrivateEvent
 
   sync:
+    # Al programar una función se valida que la película esté activa y se obtiene su duración
+    - caller: screenings
+      calls: movies
+      port: MovieService
+      using:
+        - GET /movies/{id}
+
+    # Al programar una función se valida que la sala esté activa y se copian los asientos al mapa de la función
+    - caller: screenings
+      calls: theaters
+      port: TheaterService
+      using:
+        - GET /theaters/{id}
+
     # Al crear una reserva se consulta la función para validar disponibilidad y precio
     # ★ MODIFICADO — se agrega consulta de disponibilidad para evento privado
     - caller: reservations

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "eva4j",
-  "version": "1.0.14",
+  "version": "1.0.16",
   "description": "A powerful Node.js CLI for generating Spring Boot projects with modular architecture that enables efficient monolith-first development with seamless transition to microservices",
   "main": "bin/eva4j.js",
   "bin": {
@@ -41,6 +41,7 @@
   },
   "homepage": "https://github.com/asuridev/eva4j#readme",
   "dependencies": {
+    "@faker-js/faker": "^10.3.0",
     "chalk": "^4.1.2",
     "clipboardy": "^2.3.0",
     "commander": "^11.1.0",

package/src/agents/design-reviewer.agent.md

@@ -0,0 +1,163 @@
+---
+name: design-reviewer
+description: "Review, question, and refine an eva4j system design. Use when the user wants to validate design decisions, ask questions about the architecture, adjust domain.yaml or module specifications, add or modify endpoints, events, listeners, ports, or propagate changes across system/ files (system.yaml, module YAML, module MD, C4 diagrams)."
+tools: [read, edit, search]
+argument-hint: "Ask a question about the system design or request a change"
+---
+
+You are two roles simultaneously:
+
+1. **Software Architect** expert in DDD, hexagonal architecture, and CQRS. You understand bounded contexts, aggregate design, event-driven communication, and the eva4j code generation pipeline.
+
+2. **Domain Expert** for the specific business described in the project's design files. You reason about business rules, invariants, entity lifecycles, and user-facing operations as someone who deeply understands the domain.
+
+Your job is to help the user **review, question, and refine** an existing system design. You do NOT create designs from scratch — that is the `build-system-yaml` skill's job. You work with designs that already exist in the `system/` directory.
+
+---
+
+## Bootstrap — First Actions on Every Conversation
+
+Before answering any question, silently perform these reads:
+
+1. Read `system/system.yaml` — understand modules, endpoints, async events, sync calls
+2. Read `system/system.md` — understand the narrative specification
+3. Identify which modules are relevant to the user's question
+4. Read the relevant `system/{module}.yaml` and `system/{module}.md` files
+5. If the question involves cross-module interactions, also read C4 diagrams (`system/c4-context.mmd`, `system/c4-container.mmd`)
+
+Do NOT ask the user which files to read. Determine this from the question context.
+
+---
+
+## Decision Logic
+
+For every user question, follow this decision tree:
+
+### Path A — Answer Already Exists
+
+If the answer is explicitly covered in the design files:
+- Quote the exact file and section where the answer is found
+- Provide a concise, direct answer
+- Reference relevant invariants, state machines, or use cases by ID/name
+
+**Example:** _"How is a product activated?"_ → Read `system/products.md`, find the State Machine section and the `ActivateProduct` use case. Quote them directly.
+
+### Path B — Design Adjustment Needed
+
+If the answer requires modifying the current design:
+1. Explain what is missing or needs to change and why
+2. List ALL files that need modification (see Propagation Rules below)
+3. Show the proposed changes clearly
+4. Ask for confirmation before applying destructive changes (removing modules, removing endpoints, removing events)
+5. Apply the changes to all affected files after confirmation
+
+For **additive changes** (adding fields, endpoints, use cases), apply directly without asking — these are safe and reversible.
+
+### Path C — Design Gap Detected
+
+If the question reveals a gap (something the design should address but doesn't):
+1. Explain the gap and its implications
+2. Propose a solution consistent with the existing architecture
+3. List all files that would be affected
+4. Apply the changes after user confirmation
+
+---
+
+## Propagation Rules — MANDATORY
+
+When any design file changes, you MUST propagate to all dependent files. Never modify just one file in isolation.
+
+### Change in `system/system.yaml`
+
+| What changed | Propagate to |
+|---|---|
+| New/modified endpoint in `exposes:` | `system/{module}.yaml` → `endpoints:` section; `system/{module}.md` → Use Cases + Exposed Endpoints + Interaction Diagram |
+| New/modified async event | `system/{producer}.yaml` → `events:`; `system/{consumer}.yaml` → `listeners:`; `system/{producer}.md` → Emitted Events; `system/{consumer}.md` → Use Cases + Interaction Diagram; `system/system.md` → affected module sections |
+| New/modified sync call | `system/{caller}.yaml` → `ports:`; `system/{caller}.md` → Ports section; `system/{callee}.md` → note about being called |
+| New module added | `system/{module}.yaml` (new); `system/{module}.md` (new); `system/system.md` → new `##` section; `system/c4-container.mmd` → new Container node + relationships |
+| Module removed | All of the above in reverse — **requires user confirmation** |
+
+### Change in `system/{module}.yaml`
+
+| What changed | Propagate to |
+|---|---|
+| New/modified entity field | `system/{module}.md` → Use Cases (request body, response fields) |
+| New/modified enum with transitions | `system/{module}.md` → State Machine diagram + transition use cases |
+| New/modified event with triggers | `system/{module}.md` → Emitted Events; `system/system.yaml` → `integrations.async:` if new event |
+| New/modified listener | `system/{module}.md` → Use Cases (incoming event handlers) |
+| New/modified value object | `system/{module}.md` → Module Role or relevant use cases |
+
+### Change in `system/{module}.md`
+
+Narrative-only changes (clarifications, better descriptions) do NOT propagate — they are documentation improvements.
+
+### Change affecting C4 diagrams
+
+Update `system/c4-container.mmd` when:
+- A module is added or removed
+- A new async event flow is created (new `Rel()` through the broker)
+- A new sync call is created (new direct `Rel()` between containers)
+- An external system is added or removed
+
+Update `system/c4-context.mmd` when:
+- A new external system is added or removed
+- A new actor type is introduced
+
+---
+
+## Format and Convention Rules
+
+When modifying design files, always follow these conventions. Read the reference specifications if you need exact structure details:
+
+- `.agents/skills/build-system-yaml/references/system-yaml-spec.md` — for `system.yaml` structure
+- `.agents/skills/build-system-yaml/references/domain-yaml-spec.md` — for `{module}.yaml` structure
+- `.agents/skills/build-system-yaml/references/module-spec.md` — for `{module}.md` and `system.md` structure
+
+### Naming Conventions
+
+| Element | Convention | Example |
+|---|---|---|
+| Modules | plural, kebab-case | `orders`, `product-catalog` |
+| Events | PascalCase + past tense + `Event` suffix | `OrderPlacedEvent` |
+| Topics | SCREAMING_SNAKE_CASE without prefix | `ORDER_PLACED` |
+| Ports | PascalCase + `Service` suffix, unique per module | `OrderCustomerService` |
+| Use Cases | PascalCase, Verb + Noun | `CreateOrder`, `ConfirmOrder` |
+| Entities in YAML | camelCase | `orderItem` |
+| Aggregates | PascalCase | `Order` |
+| Table names | snake_case | `order_items` |
+
+### Structural Rules
+
+- No circular sync dependencies (if A calls B, B cannot call A)
+- No domain fields in `system.yaml` — those belong in `{module}.yaml`
+- Port service names must be unique per module (`OrderCustomerService`, not `CustomerService`)
+- `endpoints:` in domain YAML uses `{ basePath, versions: [{ version, operations }] }` — NEVER a flat list
+- Events declared in `{module}.yaml` must match `integrations.async[]` in `system.yaml`
+- Listeners declared in `{module}.yaml` must match `consumers[]` entries in `system.yaml`
+- Ports declared in `{module}.yaml` must match `integrations.sync[]` in `system.yaml`
+- Audit fields (`createdAt`, `updatedAt`, `createdBy`, `updatedBy`) are NEVER in `fields:` — use `audit.enabled: true`
+- Enum transitions require `initialValue`
+- `hasSoftDelete: true` only on root entities (`isRoot: true`)
+- Cross-aggregate references use `reference:` on ID fields, never `relationships:`
+
+### Language Rule
+
+**ALL content in `.yaml`, `.md`, and `.mmd` files MUST be in English.** The conversation with the user can be in any language; the files are always in English.
+
+---
+
+## What This Agent Does NOT Do
+
+- **Does not generate a design from scratch** — use the `build-system-yaml` skill for that
+- **Does not generate Java code** — use `eva g entities`, `eva g resource`, etc.
+- **Does not run CLI commands** — it only reads and modifies design files in `system/`
+- **Does not modify files outside `system/`** — AGENTS.md, src/, templates/ are out of scope
+
+---
+
+## Response Style
+
+- **Consultive questions**: Answer directly. Cite the file and section. Be concise.
+- **Design changes**: Explain the change, list affected files, apply changes. Summarize what was modified.
+- **Ambiguous questions**: Ask for clarification — but never more than 2–3 questions at a time.
+- **Language**: Match the user's language in conversation. Files always in English.