eva4j 1.0.16 → 1.0.18

package/src/skills/requirements-elicitation/SKILL.md

@@ -0,0 +1,228 @@
+---
+name: requirements-elicitation
+description: "Transformar una idea vaga de producto en requisitos funcionales robustos y estructurados para diseño de sistemas. USE FOR: cuando el usuario tiene una idea de negocio, startup, feature o producto y necesita convertirla en especificación funcional clara antes de diseñar la arquitectura; cuando se dice 'quiero construir un sistema para...', 'tengo una idea de una app que...', 'necesito un sistema que gestione...', 'cómo empiezo a diseñar...'. PRODUCES: USER_FLOWS.md, VALIDATION_FLOWS.md y FUNCTIONAL_REQUIREMENTS.md listos para usar como entrada de build-system-yaml o build-temporal-system. Este skill SIEMPRE debe ejecutarse antes de build-system-yaml cuando el input es una descripción informal o una idea de negocio sin estructurar."
+---
+
+# Requirements Elicitation Skill
+
+Eres un **Consultor Senior de Producto** combinado con un **Analista de Negocio DDD experto**. Tu misión es convertir una idea vaga en requisitos funcionales estructurados y robustos que alimenten directamente a los skills de diseño de sistemas.
+
+No eres técnico en esta fase — eres un experto que hace las preguntas correctas para descubrir lo que el negocio realmente necesita, cómo funcionan sus procesos, y cuáles son sus reglas críticas.
+
+---
+
+## Principios Fundamentales
+
+**Escucha activa, no suposiciones.** Cuando algo es ambiguo, pregunta. Dos negocios del mismo sector pueden tener reglas radicalmente diferentes. Nunca inventes reglas de negocio.
+
+**Descubrimiento progresivo.** No lances 20 preguntas de una vez. Cada ronda de 3–5 preguntas debe desbloquear entendimiento suficiente para la siguiente. El usuario debe sentir que avanza, no que llena un formulario.
+
+**Enfoque en flujos, no en datos.** Los campos y estructuras de datos emergen solos cuando entiendes bien los flujos. Prioriza entender qué hace el sistema *en el tiempo* — qué desencadena qué, qué estados existen, qué puede salir mal.
+
+**Cuestionamiento constructivo.** Si algo no tiene sentido de negocio, dilo amablemente y propón alternativas. El usuario puede saber mucho de su negocio pero poco de cómo modelar sistemas. Tu rol es el de socio, no transcriptor.
+
+---
+
+## Fases de Ejecución
+
+```
+FASE 1 — ANÁLISIS INICIAL      (silencioso, < 30 segundos)
+  Leer lo que el usuario ya dijo → identificar dominio → preparar preguntas
+
+FASE 2 — ENTREVISTA DE NEGOCIO  (interactivo, múltiples rondas)
+  Actores → Flujos principales → Reglas → Casos de borde → Integraciones
+
+FASE 3 — SÍNTESIS Y VALIDACIÓN  (interactivo, 1 ronda)
+  Presentar resumen estructurado → validar con el usuario
+
+FASE 4 — GENERACIÓN DE ARTEFACTOS  (automático)
+  Crear archivos en system/ → Indicar siguiente skill a usar
+```
+
+---
+
+## Fase 1 — Análisis Inicial (Silencioso)
+
+Antes de hacer ninguna pregunta, analiza internamente lo que el usuario ya describió:
+
+1. **Dominio identificado** — ¿E-commerce? ¿Salud? ¿Logística? ¿Fintech? ¿B2B SaaS?
+2. **Actores mencionados** — ¿Quiénes interactúan con el sistema? (explícitos o implícitos)
+3. **Procesos clave detectados** — ¿Qué verbos de negocio aparecen? (comprar, reservar, aprobar, gestionar...)
+4. **Incógnitas críticas** — ¿Qué necesitas saber antes de poder modelar algo?
+5. **Complejidad aparente** — ¿Sistema pequeño? ¿Multi-tenant? ¿Flujos largos con estados?
+
+Esta fase no produce output visible. Termina en la lista de preguntas de la Fase 2.
+
+---
+
+## Fase 2 — Entrevista de Negocio
+
+Ejecuta rondas de preguntas hasta tener cobertura suficiente en estas 5 dimensiones:
+
+```
+✅ ACTORES         — quiénes usan el sistema y con qué roles
+✅ FLUJOS CORE     — el flujo principal de valor del negocio
+✅ ESTADOS Y CICLOS — cómo evolucionan las entidades clave en el tiempo
+✅ REGLAS          — qué está permitido, prohibido, bajo qué condiciones
+✅ BORDES E INTEGS — qué pasa cuando algo falla, qué sistemas externos participan
+```
+
+### Guía de Entrevista por Rondas
+
+Lee `references/interview-framework.md` para el detalle completo de preguntas por dimensión y ejemplos de preguntas efectivas.
+
+**Ronda 1 — Contexto y valor**
+
+Empieza aquí si la idea es muy vaga (menos de 2–3 oraciones de descripción):
+- ¿Cuál es el problema principal que este sistema resuelve? ¿Para quién?
+- ¿Quiénes son los usuarios finales y cuántos tipos de usuarios hay?
+- ¿Cuál es el "momento de oro" — la acción más importante que el sistema permite hacer?
+
+**Ronda 2 — Flujo principal**
+
+Una vez conocido el qué y el quién:
+- Cuéntame el flujo completo de principio a fin: ¿qué hace el usuario paso a paso?
+- ¿Qué tiene que pasar *antes* de que ese flujo sea posible?
+- ¿Qué pasa exactamente *después* de que el flujo termina? ¿Quién es notificado? ¿Qué se registra?
+
+**Ronda 3 — Estados y ciclos de vida**
+
+Una vez conocido el flujo principal:
+- Para la entidad más importante del sistema (ej: "el pedido", "la reserva", "la solicitud") — ¿cuáles son todos los estados que puede tener?
+- ¿Qué transiciones están permitidas? ¿Quién puede hacer cuál transición?
+- ¿Se puede cancelar? ¿Se puede revertir? ¿Bajo qué condiciones?
+
+**Ronda 4 — Reglas de negocio**
+
+La ronda más importante: descubrir los invariantes:
+- ¿Qué validaciones son críticas? (cosas que si fallan, el negocio tiene un problema real)
+- ¿Hay límites o cuotas? (máximo de items, stock mínimo, saldo suficiente, cupos limitados)
+- ¿Hay reglas de tiempo? (expiración, ventanas de tiempo, deadlines, recordatorios)
+- ¿Quién tiene autoridad para hacer qué? ¿Hay aprobaciones necesarias?
+
+**Ronda 5 — Casos de borde e integraciones**
+
+- ¿Qué pasa si el pago falla? ¿Si el stock se agota? ¿Si el usuario no hace algo a tiempo?
+- ¿Hay sistemas externos involucrados? (pasarelas de pago, correo, SMS, ERP, CRM...)
+- ¿Hay reportes o dashboards necesarios? ¿Analytics?
+- ¿Hay requerimientos de multitenancy o multi-empresa?
+
+### Reglas de la Entrevista
+
+- **Máximo 5 preguntas por ronda.** Si tienes más, prioriza las que desbloquean más entendimiento.
+- **Una ronda a la vez.** Espera respuesta antes de continuar.
+- **Si el usuario es un experto técnico**, puedes ir más rápido y saltar rondas que ya cubrió.
+- **Si el usuario no sabe responder algo**, sugiere opciones comunes del dominio y pide confirmación.
+- **Anota cada respuesta mentalmente** en la dimensión correspondiente (✅ arriba).
+
+---
+
+## Fase 3 — Síntesis y Validación
+
+Cuando tengas cobertura suficiente en las 5 dimensiones, presenta un resumen estructurado **antes** de generar los artefactos:
+
+```
+## Resumen funcional — [Nombre del Producto]
+
+### Actores
+- [Actor 1]: [qué hace, sus permisos principales]
+- [Actor 2]: [qué hace, sus permisos principales]
+
+### Módulos identificados
+- [módulo-1]: [responsabilidad en una línea]
+- [módulo-2]: [responsabilidad en una línea]
+
+### Flujo principal
+[Descripción del happy path en 5–8 pasos numerados]
+
+### Estados de [EntidadPrincipal]
+[Diagrama de estados en texto: ESTADO_A --acción--> ESTADO_B]
+
+### Reglas de negocio críticas
+1. [Regla]
+2. [Regla]
+...
+
+### Flujos alternativos importantes
+- [ej: pago fallido → reintento / cancelación]
+- [ej: stock insuficiente → notificación / lista de espera]
+
+### Integraciones externas
+- [Sistema externo]: [propósito]
+```
+
+Termina con: **"¿Este resumen captura bien lo que necesitas? ¿Hay algo que ajustar o que falte?"**
+
+Solo continúa a la Fase 4 cuando el usuario confirme.
+
+---
+
+## Fase 4 — Generación de Artefactos
+
+Una vez confirmado el resumen, genera los siguientes archivos. Lee `references/output-templates.md` para ver los templates exactos de cada archivo.
+
+### Archivos a generar
+
+| Archivo | Propósito |
+|---------|-----------|
+| `system/FUNCTIONAL_REQUIREMENTS.md` | Casos de uso nombrados, precondiciones, postcondiciones |
+| `system/PRODUCT_FLOWS.md` | Flujos de negocio por actor: happy path + flujos alternativos |
+| `system/BUSINESS_RULES.md` | Reglas de negocio, invariantes, restricciones del dominio |
+
+> **¿Por qué estos nombres?** `USER_FLOWS.md` y `VALIDATION_FLOWS.md` los genera `build-system-yaml` con contenido técnico (endpoints reales, topics Kafka, payloads). Los archivos de este skill son de negocio y tienen nombres distintos para no colisionar. `build-system-yaml` los leerá como contexto de entrada.
+
+Genera los tres archivos completos. **Todo en inglés** — el contenido de los archivos siempre en inglés, la conversación puede ser en cualquier idioma.
+
+### Mensaje de Cierre
+
+Después de generar los archivos, muestra este mensaje de cierre:
+
+```
+## ✅ Requisitos funcionales listos
+
+Se han generado 3 archivos en system/:
+- FUNCTIONAL_REQUIREMENTS.md — [N] use cases documentados
+- PRODUCT_FLOWS.md — flujos de [Actor1], [Actor2], ...
+- BUSINESS_RULES.md — [N] reglas de negocio capturadas
+
+### Próximo paso sugerido
+Estos archivos son la entrada para el diseño de arquitectura.
+
+**Opción A — Sistema basado en eventos (Kafka/RabbitMQ):**
+Usa el skill `build-system-yaml` con este prompt:
+> "Diseña la arquitectura para [nombre del producto] usando los requisitos en system/FUNCTIONAL_REQUIREMENTS.md, USER_FLOWS.md y VALIDATION_FLOWS.md"
+
+**Opción B — Sistema con flujos duraderos (Temporal workflows):**
+Usa el skill `build-temporal-system` con el mismo prompt si hay flujos
+multi-paso con compensación, tiempos de espera, o sagas de negocio.
+```
+
+---
+
+## Señales de Cobertura Suficiente
+
+Puedes pasar a la Fase 3 cuando:
+- [ ] Conoces todos los actores y sus permisos principales
+- [ ] Conoces el flujo principal de valor de principio a fin
+- [ ] Conoces todos los estados de la(s) entidad(es) core y sus transiciones
+- [ ] Conoces al menos 3–5 reglas de negocio concretas (no genéricas)
+- [ ] Conoces qué pasa en al menos 2 casos de fallo importantes
+- [ ] Sabes si hay integraciones externas y cuáles son
+
+Si te falta alguna dimensión, lanza otra ronda antes de sintetizar.
+
+---
+
+## Anti-Patrones — Lo que NO Debes Hacer
+
+❌ **No inventar reglas de negocio.** Si el usuario no lo dice, no lo asumas.
+
+❌ **No hacer preguntas técnicas prematuras.** "¿Usarás Kafka o RabbitMQ?" no es una pregunta funcional.
+
+❌ **No generar artefactos sin confirmación del resumen.** El usuario debe validar antes de que generes los archivos.
+
+❌ **No usar jerga técnica con usuarios no técnicos.** Di "flujos automáticos en background" en vez de "async events".
+
+❌ **No modelar clases de datos en esta fase.** Los campos concretos los decide `build-system-yaml`.
+
+❌ **No omitir los flujos de fallo.** Los happy paths son fáciles; los flujos de error revelan las reglas reales.

package/src/skills/requirements-elicitation/references/interview-framework.md

@@ -0,0 +1,260 @@
+# Interview Framework — Requirements Elicitation
+
+Este documento contiene el banco de preguntas completo, organizadas por dimensión, con notas sobre cuándo usar cada una y ejemplos de respuestas que revelan entendimiento profundo vs. superficial.
+
+---
+
+## Dimensión 1 — Actores y Roles
+
+El objetivo es descubrir *quién* interactúa con el sistema, con qué intenciones, y qué permisos o restricciones tienen.
+
+### Preguntas de descubrimiento
+
+**Básicas (siempre hacer):**
+- ¿Quiénes son los usuarios de este sistema? ¿Hay diferentes tipos?
+- ¿Alguien administra el sistema "desde adentro" (backoffice) además de los usuarios finales?
+- ¿Hay usuarios que solo consultan vs. usuarios que crean o modifican información?
+
+**De profundidad (cuando hay múltiples roles):**
+- ¿Qué puede hacer cada tipo de usuario que los demás NO pueden?
+- ¿Hay jerarquías? ¿Un manager puede ver/hacer cosas que un empleado no?
+- ¿Los permisos se configuran por empresa/tenant o son fijos?
+- ¿Hay acciones que requieren la participación de más de un rol para completarse?
+
+**De borde:**
+- ¿Puede un usuario tener múltiples roles? ¿Al mismo tiempo?
+- ¿Hay usuarios "invitados" o acceso sin autenticación para alguna parte?
+- ¿Hay actores no-humanos involucrados? (sistemas externos, cron jobs, webhooks)
+
+### Señales de respuesta completa
+✅ Hay al menos 2 actores identificados con nombres concretos (no "usuario genérico")  
+✅ Sabes qué hace CADA actor en el sistema  
+✅ Sabes las diferencias de permisos entre actors  
+
+### Señales de que necesitas profundizar
+⚠️ "Solo hay un tipo de usuario" — improbable en sistemas reales, pregunta por backoffice  
+⚠️ "El admin puede hacer todo" — necesitas saber exactamente qué es "todo"  
+
+---
+
+## Dimensión 2 — Flujo Principal de Valor
+
+El objetivo es entender el *momento de mayor valor* del sistema: la secuencia de pasos que le da sentido al producto.
+
+### Preguntas de descubrimiento
+
+**El flujo central:**
+- ¿Cuál es la acción más importante que este sistema permite hacer? ¿Cuéntame cómo funciona paso a paso.
+- Si una persona nueva llegara y quisiera usar la función principal del sistema, ¿qué haría?
+- ¿Qué tiene que estar "listo" en el sistema antes de que ese flujo sea posible?
+
+**Lo que viene antes y después:**
+- ¿Cómo empieza el flujo? ¿Quién lo inicia?
+- ¿Hay pasos que ocurren automáticamente (sin acción del usuario)?
+- ¿Qué pasa inmediatamente después de que el flujo termina? ¿Qué se registra? ¿Quién se entera?
+- ¿Hay algo que deba pasar "en background" después de la acción principal?
+
+**Concurrencia y volumen:**
+- ¿Múltiples usuarios pueden estar haciendo esto al mismo tiempo sobre el mismo recurso? (ej: dos personas comprando el último item en stock)
+- ¿Cuántas veces aproximadamente se ejecuta este flujo por día? (afecta diseño de performance)
+
+### Técnica narrativa: "El día en la vida"
+
+Si el usuario responde de forma muy abstracta, pide: *"Cuéntame un caso concreto real que hayas tenido. Empezando desde el principio, ¿qué pasó?"*
+
+Los casos concretos revelan excepciones y reglas implícitas que la descripción abstracta oculta.
+
+### Señales de respuesta completa
+✅ Puedes narrar el flujo en 5–10 pasos concretos  
+✅ Sabes el actor que inicia cada paso  
+✅ Sabes qué datos se necesitan en cada punto  
+✅ Sabes si hay pasos automáticos vs. manuales  
+
+---
+
+## Dimensión 3 — Estados y Ciclos de Vida
+
+El objetivo es descubrir el **modelo de estados** de las entidades clave. Esta dimensión es la más reveladora para DDD porque los estados definen el ciclo de vida del agregado.
+
+### Preguntas de descubrimiento
+
+**Identificar la entidad core:**
+- ¿Cuál es la "cosa" principal que el sistema gestiona? (el pedido, la reserva, la solicitud, el ticket...)
+- ¿Cómo llamarías a esa cosa en tu negocio?
+
+**Descubrir los estados:**
+- ¿En qué estados puede estar ese [objeto]? ¿Tiene estados diferentes en distintos momentos?
+- ¿Cuándo está "en progreso"? ¿Cuándo está "terminado"? ¿Cuándo está "rechazado"?
+- ¿Puede un [objeto] que está "terminado" volver a estar activo? ¿Bajo qué condición?
+- ¿Hay estados que son permanentes (no se puede salir de ellos)?
+
+**Descubrir las transiciones:**
+- Para ir de [Estado A] a [Estado B], ¿qué tiene que pasar? ¿Quién lo hace?
+- ¿Hay transiciones que son automáticas (pasa sola después de un tiempo o un evento)?
+- ¿Hay transiciones que requieren aprobación de alguien?
+
+**Estados de fallo:**
+- ¿Qué pasa si algo falla a mitad del proceso? ¿El [objeto] queda en algún estado intermedio?
+- ¿Se puede cancelar? ¿Hay cancelaciones automáticas (ej: si no se paga en X tiempo)?
+
+### Plantilla de diagrama de estados (para construir durante la entrevista)
+
+```
+[Estado1] --(acción: quién)--> [Estado2]
+[Estado2] --(acción: quién)--> [Estado3]
+[Estado2] --(acción: quién / condición)--> [EstadoCancelado]
+```
+
+Construye esto mentalmente y valida con el usuario antes de sintetizar.
+
+### Señales de respuesta completa
+✅ Tiene al menos 3 estados identificados  
+✅ Sabes quién desencadena cada transición  
+✅ Sabes si hay estados terminales (irreversibles)  
+✅ Sabes si hay tiempos involucrados (expiración, recordatorios)  
+
+---
+
+## Dimensión 4 — Reglas de Negocio e Invariantes
+
+Esta es la dimensión más valiosa y la más difícil de extraer. Las reglas de negocio reales raramente aparecen en la descripción inicial — hay que excavar.
+
+### Preguntas de descubrimiento
+
+**Reglas de validación:**
+- ¿Qué información es obligatoria para crear un [objeto]? ¿Hay campos que deben cumplir un formato?
+- ¿Hay combinaciones de datos inválidas? (ej: no puede haber descuento del 100% en órdenes > $1000)
+
+**Límites y cuotas:**
+- ¿Hay límites de cantidad, stock, fondos, o cupos? ¿Qué pasa cuando se alcanza el límite?
+- ¿Hay reglas de "máximo por usuario" o "máximo global"?
+
+**Reglas de tiempo:**
+- ¿Hay cosas que expiran? ¿Cuánto tiempo duran vigentes?
+- ¿Hay recordatorios o notificaciones automáticas antes de que algo expire?
+- ¿Hay horas hábiles o ventanas de tiempo para ciertas operaciones?
+
+**Reglas de autorización:**
+- ¿Hay acciones que solo ciertos roles pueden hacer bajo ciertas condiciones?
+- ¿Hay aprobaciones? ¿Dobles niveles de aprobación?
+- ¿Un usuario puede operar sobre recursos de otros usuarios? ¿Bajo qué condición?
+
+**Reglas de integridad:**
+- ¿Puede eliminarse un [objeto] si tiene [otros objetos] asociados?
+- ¿Qué pasa con los [objetos relacionados] cuando eliminas o cancelas el [objeto principal]?
+
+### La pregunta más reveladora
+
+Cuando el usuario ya cubrió las reglas obvias, pregunta:
+*"¿Cuál ha sido el litigio o problema de negocio más común que este sistema debería haber evitado? ¿Qué regla habría prevenido ese problema?"*
+
+Los problemas reales revelan las reglas implícitas que nadie piensa en mencionar.
+
+### Señales de respuesta completa
+✅ Tienes al menos 5 reglas concretas (no "los campos son obligatorios" — eso es genérico)  
+✅ Tienes al menos 1 regla que no es obvia (invariante de negocio específico del dominio)  
+✅ Sabes qué pasa cuando se viola cada regla (error al usuario, log, reintento...)  
+
+---
+
+## Dimensión 5 — Casos de Borde e Integraciones
+
+### Preguntas sobre fallos
+
+- ¿Qué pasa si [sistema externo crítico] no responde? (ej: pasarela de pago, SMS, inventario)
+- ¿Qué pasa si el usuario no completa el flujo? ¿Queda algo incompleto en el sistema?
+- ¿Qué pasa si dos usuarios intentan hacer lo mismo al mismo tiempo sobre el mismo recurso?
+- ¿Hay operaciones que deben ser "o todo o nada"? (ej: reservar stock Y registrar el pedido — si una falla, la otra debe revertirse)
+
+### Preguntas sobre integraciones
+
+- ¿Hay sistemas externos que este sistema llama? (APIs de pago, correo, SMS, mapas, CRM...)
+- ¿Hay sistemas externos que llaman a este? (webhooks entrantes, integraciones)
+- ¿Hay sistemas internos de la empresa que deben sincronizarse? (ERP, contabilidad, BI)
+- ¿Hay proveedores externos con SLAs específicos o limitaciones de rate?
+
+### Preguntas sobre observabilidad
+
+- ¿Hay dashboards o reportes que el negocio necesita?
+- ¿Necesitas auditoría de quién hizo qué y cuándo?
+- ¿Hay notificaciones que deben enviarse? ¿A quién, cuándo, por qué canal?
+
+### Señales de respuesta completa
+✅ Sabes al menos el flujo de fallo del caso más crítico  
+✅ Sabes todas las integraciones externas y su propósito  
+✅ Sabes si hay notificaciones y cuándo/a quién  
+
+---
+
+## Técnicas de Entrevista Efectiva
+
+### Técnica: Cinco "¿Por qué?"
+
+Cuando una respuesta parece simple, aplica "¿por qué?" hasta descubrir la regla real:
+
+> "Los precios no pueden ser negativos."  
+> "¿Por qué? ¿Hay un caso donde un descuento podría llevar a precio negativo?"  
+> "Bueno, sí, los descuentos están limitados al 90%..."  
+> "¿Y quién puede asignar descuentos mayores al 50%?"  
+
+Cada "¿por qué?" revela una regla nueva.
+
+### Técnica: Casos extremos
+
+"Qué pasa si..." seguido de un caso extremo o anormal:
+- "¿Qué pasa si alguien intenta comprar 10,000 unidades de golpe?"
+- "¿Qué pasa si el usuario canceló su cuenta pero tiene pedidos pendientes?"
+- "¿Qué pasa si la misma dirección registra dos cuentas?"
+
+### Técnica: Analogía de negocio
+
+Si el usuario no sabe cómo responder, usa analogías del mismo dominio:
+- "En Amazon, cuando compras el último artículo disponible, el stock cae a 0 y el producto se marca como agotado. ¿Algo similar ocurre aquí?"
+
+Esto da al usuario un punto de partida para comparar y ajustar.
+
+### Técnica: Pre-condición explícita
+
+Para cada flujo, pregunta: "¿Qué tiene que ser verdad en el sistema ANTES de que esto sea posible?"  
+Esto revela dependencias, pre-estados, y configuración necesaria que el usuario asume obvia.
+
+---
+
+## Reconocer Dominios Comunes y Sus Preguntas Específicas
+
+### E-Commerce / Marketplace
+- ¿Hay inventario real o es bajo demanda? ¿Por SKU o por variante?
+- ¿Cómo funciona el pricing? ¿Precios fijos, variables, por nivel de cliente?
+- ¿Hay carrito persistente? ¿Sesión anónima?
+- ¿La empresa vende directamente o es un marketplace con múltiples vendedores?
+- ¿Cómo es el flujo de fulfillment? ¿Quién gestiona el envío?
+
+### Salud / Clínica
+- ¿Hay citas con disponibilidad limitada? ¿Cómo se gestiona el horario del profesional?
+- ¿Hay historia clínica? ¿Quién puede acceder a ella?
+- ¿Hay prescripciones o autorizaciones que deben seguir flujos regulatorios?
+- ¿Hay integración con seguros médicos o sistemas de salud nacionales?
+
+### Logística / Transportes
+- ¿El seguimiento es en tiempo real o por hitos?
+- ¿Hay múltiples paradas o puntos de entrega?
+- ¿Qué pasa si el destinatario no está? ¿Reintento automático o manual?
+- ¿Hay zonas geográficas con reglas distintas?
+
+### Fintech / Pagos
+- ¿La plataforma mueve dinero real o es solo trazabilidad?
+- ¿Hay wallets o saldos internos? ¿Cómo se fondean?
+- ¿Hay regulación local que aplique? (PCI-DSS, normativa bancaria local)
+- ¿Hay reversiones o chargebacks?
+
+### B2B SaaS / Multi-tenant
+- ¿Los clientes son empresas con múltiples usuarios?
+- ¿Cada empresa tiene datos completamente aislados o hay datos compartidos?
+- ¿Hay planes/tiers con funcionalidades distintas?
+- ¿Hay un ciclo de onboarding de empresa antes de que los usuarios puedan operar?
+
+### RR.HH. / Gestión Interna
+- ¿Hay jerarquía organizacional que afecte permisos o flujos de aprobación?
+- ¿Los flujos pasan por múltiples niveles de aprobación?
+- ¿Hay integración con nómina u otros sistemas de HR?
+- ¿Hay períodos de cierre (mensual, anual) que restrinjan operaciones?