Domain model

DOC-002: Modelo de dominio SaaS

Estado

Accepted — 2026-09-08 (producto: B2C Subscriber, no Tenant B2B).

Visión: DOC-001
Opciones / IV: DOC-003
Glosario corto (agentes/código): .cursor/rules/seed-domain.mdc
Aislamiento: ADR-018
Identidad: ADR-023

Este documento es la fuente de verdad del negocio SaaS. El motor de señales (CLI) sigue DOC-003. Si un agente no sabe “de qué trata el producto”, empieza aquí.

No es consejo financiero.

1. Qué es IVPrior (una frase)

IVPrior ayuda a traders retail de opciones a decidir qué mirar hoy: dirección probable, si la prima está cara o barata (régimen de IV (Implied Volatility / volatilidad implícita)), y qué tipo de jugada encaja.

No es broker, no ejecuta órdenes, no es asesor regulado, no garantiza retornos.

2. Modelo comercial (cerrado)

B2C de suscripción. El comprador es una persona de internet que paga un Plan para usar el scanner y el resto de funcionalidades.

Cashlane / FoodHub aportaron la fábrica (auth, billing, /platform, help). No aportan el modelo de negocio. Copiar “Tenants” como entidad de producto está prohibido a partir de este DOC.

3. Actores

No hay en V1: empleados del suscriptor, OWNER/FINANCE_ADMIN de una org, couriers, locations, “finance manager”.

4. Bounded contexts

┌─────────────────────┐     ┌──────────────────────────┐
│  Engine             │     │  Subscriber account      │
│  Python `apps/cli`  │     │  Nest/Next (SaaS)        │
│  Signal             │     │  Subscriber              │
│  Opportunity        │◄───►│  Watchlist (cuenta)      │
│  IvRegime           │     │  Subscription + Plan     │
│  DataSource         │     │  PaperDiary (futuro web) │
└─────────────────────┘     └──────────────────────────┘
                                        ▲
                                        │ entitlements
                               ┌────────┴────────┐
                               │  Billing        │
                               │  Plan catalog   │
                               │  Stripe         │
                               └────────┬────────┘
                                        │
                               ┌────────┴────────┐
                               │  Platform ops   │
                               │  PlatformUser   │
                               │  Branding/social│
                               │  Plans admin    │
                               │  IAM staff      │
                               └─────────────────┘

Comunicación Engine ↔ SaaS: contrato explícito (CLI hoy; API/worker después). No mezclar tablas food ni “tenant restaurant” en el motor.

5. Entidades de producto (SaaS)

Nombres en código = inglés. Docs en español pueden usar el alias.

Prohibido como entidad de producto

“Customer” en copy de marketing = el Subscriber. En código, preferir Subscriber para no chocar con el Customer deudor de Cashlane.

6. Superficies

/platform conserva módulos de fábrica que sí son genéricos: branding, redes sociales, planes, permisos/roles/usuarios de staff, audit, sesiones, jobs.

El ítem de nav Tenants es leftover de FoodHub: en producto es el listado de Subscribers. Rename de UI/schema = slice posterior (no este DOC). Hasta ese slice, los agentes MUST hablar de Subscribers en docs y no inventar features de “tenant restaurant”.

7. Aislamiento de datos

Ver ADR-018 (enmienda 2026-09-08).

• Toda fila de negocio del Subscriber lleva el id de cuenta (subscriberId en vocabulario; en Prisma de fábrica puede seguir llamándose organizationId hasta el remap).
• Un Subscriber no ve watchlists, corridas ni billing de otro.
• PlatformUser no usa un id mágico para “ver todos”; listados de platform son queries de ops con audit.
• V1: un usuario humano = un Subscriber. Seats / equipo del trader = fuera de V1.

8. leftover de fábrica (código vs vocabulario)

Tras SLICE-003-06 (Prisma DDL), el schema físico usa subscribers / subscriber_id. Quedan nombres de módulo/ruta legacy en código de aplicación:

Reglas para agentes:

1. No crear un segundo modelo “Organization B2B” encima de Subscriber.
2. No borrar branding / social / platform IAM porque “no son de opciones”: son ops de la marca.
3. No implementar locations, orders, menu, couriers.
4. Copy nueva: Subscriber / plan / scanner — nunca “tenant”, “orders”, “locations”.
5. Renombres de módulos Nest (tenant-* → subscriber-*) y UI = slices posteriores del epic FEAT-004; Prisma DDL ya aplicado (ADR-018).
6. Rutas con slug (/s/demo/login, /s/{slug}/scanner): leftover de FoodHub multi-tenant. En B2C V1 un humano = un Subscriber; el email identifica la cuenta, no el slug en la URL. Target de producto: /login + /app/* (sin slug visible). Migración = slice/ADR aparte; no crear copy que pida al usuario “elegir su workspace”.

9. Relación con el CLI

V0 no autentica Subscribers. El PowerUser corre el motor localmente.

Cuando el SaaS exponga el scanner: el Engine produce Opportunities; la cuenta Subscriber guarda watchlist, historial y entitlements del Plan. El CLI puede seguir siendo la misma lógica empaquetada.

10. Compliance (recordatorio)

• Disclaimer: herramienta de investigación, no advice.
• Gate legal externo antes de cobrar en EE.UU. (DOC-001 §9).
• Exactitud de IV/datos > growth copy.

11. Aprobación

Follow-up de ingeniería (fuera de este DOC): seed catálogo IAM platform (para que reaparezcan branding/roles en el nav); rename Tenants → Subscribers; Spec Kit del módulo Subscriber cuando se toque schema.