🗺️ Mapa de Piezas — Ecosistema DKV Pet Flows

Fecha: 4 de abril de 2026 (actualizado) Audiencia: Product Owner / Equipo técnico Propósito: Visión de pájaro de TODAS las piezas implicadas y sus relaciones

---

1. Las 5 Piezas del Ecosistema

graph TB
    subgraph "LIBRERÍA (IP propia)"
        JARAXA["🔧 Jaraxa / ui-flows<br/>Librería npm visual de flows<br/>workspace.jaraxa/ui-flows"]
    end

    subgraph "PRODUCTO (Para DKV)"
        FLOWS["📊 dkv-pet-flows<br/>Plataforma Customer Engagement<br/>workspace.dkv/dkv-pet-flows"]

        subgraph "Frontend"
            ADMIN["dkv-pet-flows-admin<br/>React 18 + Vite"]
        end
        subgraph "Backend"  
            API["dkv-pet-flows-api<br/>Quarkus 3.32 + Dapr"]
        end
    end

    subgraph "FUENTE DE DATOS (Cliente)"
        PET["🐾 dkv-pet-cloud<br/>Spring Boot 3.5.9 + Pekko<br/>Monolito modular"]
        NTF["📲 dkv-notifications<br/>Erlang OTP<br/>Gorush → APNs + FCM"]
        DTM["⏰ distributed-task-manager<br/>Quartz Scheduler<br/>Planificaciones"]
        NETCOMP["🦎 netcomp<br/>Erlang legacy<br/>En proceso de migración"]
    end

    subgraph "INFRAESTRUCTURA (DKV)"
        HC["InterSystems Health Connect<br/>ESB Sanitario"]
        RMQ["RabbitMQ<br/>Mensajería bidireccional"]
    end

    JARAXA -->|"npm link / workspaces"| ADMIN
    ADMIN -->|"REST API"| API
    NETCOMP -->|"HTTP POST /api/v1/events"| API
    API -->|"AMQP publish"| RMQ
    RMQ -->|"AMQP consume"| API
    API -->|"Webhooks IN"| PET
    API -->|"REST OUT (proxy)"| PET
    API -.->|"Fase 2: absorbe"| NTF
    API -.->|"Strangler Fig"| DTM
    PET <-->|"Leader/Follower"| NETCOMP
    PET <-->|"AMQP"| RMQ
    NTF -->|"Push"| GORUSH["Gorush<br/>APNs + FCM"]
    HC -->|"Eventos clínicos"| PET

    style JARAXA fill:#7C3AED,color:#fff
    style FLOWS fill:#3b82f6,color:#fff
    style PET fill:#009BE0,color:#fff
    style NTF fill:#D97706,color:#fff
    style DTM fill:#6366f1,color:#fff
    style NETCOMP fill:#ef4444,color:#fff
    style HC fill:#0891B2,color:#fff

---

2. Estado Actual de Cada Pieza

#	Pieza	Estado	Lo que EXISTE	Lo que FALTA
1	Jaraxa (ui-flows)	🟡 30%	Canvas, BaseNode, RouterNode, EmptyTrigger, ModuleNode, AppSelectorDialog, ContextMenu, EdgeFilter, SettingsPanel, Store completo, 4 temas CSS	Iterator, Aggregator, nodos de control avanzados, sistema de scheduling, conexión con API real
2	dkv-pet-flows-admin	🔴 10%	Scaffolding React 18 + Vite, estructura MUI/Tailwind heredada de pet-cloud-admin	Integración de Jaraxa, páginas de escenarios, dashboard, analíticas
3	dkv-pet-flows-api	🟡 25%	AMQP Gateway nativo (SmallRye, 8 clases), subscribe/unsubscribe dinámico, webhook forwarding, mvn clean compile ✅	Modelo de datos Flow/Node/Edge, motor de ejecución Dapr, UI admin
4	dkv-pet-cloud	✅ Producción	API REST completa, Encounters, Queues con webhook_new_message_recipients, Pekko cluster	OpenAPI formal no publicada
5	dkv-notifications	✅ Producción	Push via Gorush, DB propia PostgreSQL 11.6	Nada — se absorberá en Fase 2
6	DTM	✅ Producción	Quartz Scheduler activo	Nada — Strangler Fig, expira orgánicamente

---

3. Flujo de Datos — MVP Backlog (Encuesta de Satisfacción)

sequenceDiagram
    participant PET as dkv-pet-cloud
    participant Q as Cola (Queue)
    participant FLOWS as dkv-pet-flows-api
    participant ENGINE as Dapr Workflow
    participant GORUSH as Gorush
    participant APP as QC+ App

    PET->>Q: Caso médico cerrado (Encounter CLOSED)
    Q->>FLOWS: Webhook POST (payload con datos del caso)
    FLOWS->>ENGINE: Dispara flow "Encuesta Post-Consulta"
    ENGINE->>ENGINE: Wait 5 días (Dapr Timer)
    ENGINE->>ENGINE: Evaluar condición (¿push habilitado?)
    ENGINE->>GORUSH: Enviar push con deep link
    GORUSH->>APP: Push notification → Deep link a encuesta
    APP->>PET: Usuario completa encuesta

---

4. Relación Jaraxa ↔ Flows (Librería vs Producto)

                    GENÉRICO                              ESPECÍFICO
                    ─────────                             ──────────

    ┌───────────────────────────────┐     ┌───────────────────────────────┐
    │     Jaraxa (ui-flows)         │     │    dkv-pet-flows              │
    │                               │     │                               │
    │  • Canvas React Flow          │     │  • 40 nodos de negocio DKV    │
    │  • BaseNode, RouterNode...    │     │  • Apps = { PET, Gorush... }  │
    │  • AppSelectorDialog          │ ──► │  • Triggers = eventos PET     │
    │  • Store Zustand              │     │  • Scheduling = colas PET     │
    │  • 4 temas CSS                │     │  • DomainIconPack pet-health  │
    │  • ModuleType taxonomy        │     │  • Backend Quarkus + Dapr     │
    │  • Edges con filtros          │     │  • Persistencia PostgreSQL    │
    │                               │     │                               │
    │  IP: Jaraxa Software          │     │  IP: Para DKV Seguros         │
    └───────────────────────────────┘     └───────────────────────────────┘

[!IMPORTANT] Jaraxa es agnóstica de dominio. No sabe qué es un "caso médico", una "cola", ni un "push". Solo sabe de nodos, edges, apps, módulos, y canvas. Todo lo específico de DKV vive en dkv-pet-flows.

---

5. Las 3 Grandes Tensiones Detectadas

Tensión 1 — Terminología: Make.com vs Customer Engagement

Jaraxa usa la taxonomía de Make.com (Scenario, Module, Blueprint, Trigger/Action/Search). Pero dkv-pet-flows es un sistema de Customer Engagement (la jerga es: Campaña, Segmento, Canal, Evento, Audiencia).

Make.com	Customer Engagement	¿Conflicto?
Scenario	Flujo / Campaña	⚠️ Naming
Module	Nodo / Bloque	⚠️ Naming
Trigger	Evento de entrada	✅ Compatible
Action	Canal / Acción	✅ Compatible
App	Integración / Conector	⚠️ Concepto clave
Filter (en edge)	Condición / Segmento	⚠️ Naming
Blueprint	Flow Definition	✅ Compatible

Tensión 2 — Filtro de Entrada al Flujo

En Make.com, un Scenario empieza con un Trigger de una App. En Customer Engagement, un flujo empieza con un criterio de audiencia:

• "En este flujo entran todos los pacientes que cierren un caso" → Event-based trigger
• "Usuarios que llevan 1 mes sin conectar" → Segment-based trigger (cron + query)
• "Flujo permanente que detecta cierres de caso" → Always-on webhook trigger

Esto implica que el nodo Trigger de Jaraxa necesita ser mucho más rico de lo que es en Make.com. No es solo "App X → Watch Rows". Es "PET.Queues → Case Closed → con filtros de segmento".

Tensión 3 — ¿Cómo expone PET sus objetos de negocio?

Pet Cloud tiene objetos de negocio ricos: Encounters, Queues, Users, Policies, Pets. Pero no tiene una API de "apps & modules" como Make.com. La pregunta es: ¿cómo traduzco los objetos de PET al concepto de "App" del AppSelectorDialog?

---

6. Inventario de Progreso por Capa

Capa	Pieza	Progreso	Detalle
L0 — Librería	@jaraxa/flow-canvas	🟡 70%	Canvas, store, dialogs, temas
L0 — Librería	@jaraxa/flow-nodes	🟡 50%	BaseNode, Router, EmptyTrigger, Module
L0 — Librería	@jaraxa/flow-edges	🟡 40%	AnimatedEdge básico
L0 — Librería	@jaraxa/flow-icons	🟢 80%	Resolución L1/L2 con lucide
L0 — Librería	@jaraxa/flow-config	🔴 0%	No iniciado
L0 — Librería	@jaraxa/flow-monitor	🔴 0%	No iniciado
L1 — Producto FE	dkv-pet-flows-admin	🔴 10%	Solo scaffolding
L1 — Producto BE	dkv-pet-flows-api	🟡 25%	AMQP Gateway: publish REST, consume AMQP, subscribe dinámico, webhook forwarding
L2 — Integración	netcomp → Flows → RabbitMQ	✅ Implementado	POST /api/v1/events vía hackney + SmallRye AMQP Gateway
L2 — Integración	PET → Flows webhook	📋 Diseñado	webhook_new_message_recipients confirmado
L2 — Integración	Flows → Gorush push	📋 Diseñado	Arquitectura clara, Gorush stateless
L3 — Modelo datos	Flow/Node/Edge types	🔴 0%	Definido conceptualmente, no implementado

---

Documentos Relacionados

Documento	Propósito
02 — Tensión Conceptual: Make.com vs Customer Engagement	Análisis profundo de la Tensión 1 y 2
03 — PET como App: Cómo exponer objetos de negocio	Resolución de la Tensión 3
04 — Anatomía del MVP Backlog: Flujo Encuesta de Satisfacción	Diseño completo del flujo MVP Backlog
05 — Direcciones Estratégicas: ¿Qué construir primero?	Opciones de priorización con análisis RICE