Flujo del MVP

Mapa del recorrido completo del clínico, derivado del código (apps/web) — no de la memoria. Un clínico, una sesión autenticada, dos carriles de producto desde la consola. El carril B es el MVP: la cuña del registro calificado por completitud, donde se construye el foso (moat). La extracción y el envío al registro son las dos bisagras que dependen de una bandera de configuración.

El recorrido

flowchart TD
Landing["Landing · poktacare.com<br/>capta al clínico"]:::xrepo --> SignIn

subgraph AUTH["Entrar"]
  direction TB
  SignIn["/iniciar-sesion<br/>login Privy"]:::ship --> Me{"GET /api/users/me"}
  Me -->|"403 access_required"| Req["/solicitar-acceso<br/>none · pending · approved · rejected"]:::ship
  Me -->|"sin onboarding"| Perfil["/consola/perfil<br/>perfil + cédula"]:::ship
  Me -->|"ok"| Home
  Req -->|"aprobado · Entrar"| Home
  Perfil --> Home
end

Home["/consola · ConsoleHome<br/>inicio RheumAI"]:::ship
Home --> NC
Home --> Inv

subgraph LANEA["Carril A · Consulta → Plan de paciente"]
  direction TB
  NC["/consola/nueva-consulta"]:::ship --> AE["/consola/borradores/:id<br/>Editor de aprobación"]:::ship
  AE -->|"Compartir · magic link"| PP["/p/plan<br/>plan del paciente (token, sin login)"]:::ship
end

subgraph LANEB["Carril B · Cuña BiobadamexAI — el MVP"]
  direction TB
  Up["/consola/biobadamex/subir<br/>subir .docx/.doc/.pdf/.txt · ≤25"]:::ship
  Wa["WhatsApp file-drop<br/>consent → auth → acuse → ingesta"]:::gate
  Up --> Inv
  Wa --> Inv
  Inv["/consola/biobadamex<br/>inventario · filtros de estado + canal"]:::ship
  Inv -->|"Extraer"| Ex{"extraer + calificar<br/>QUEUE_ENABLED"}:::gate
  Ex --> Rev["/consola/biobadamex/:id<br/>Compuerta de revisión · checklist por variante"]:::ship
  Rev --> Gr["/…/calificacion<br/>la calificación — dato del foso"]:::ship
  Rev -->|"Aprobar · dueño + checks"| Sub{"Enviar<br/>solo dueño · SUBMIT_ENABLED · Charlson"}:::gate
  Sub -->|"pg-boss → Tenki"| Reg[("Registro BIOBADAMEX")]:::ship
end

subgraph OUT["Un expediente · tres salidas"]
  direction LR
  O1["Completar<br/>el expediente enviado"]:::ship
  O2["Preguntar · Segunda opinión<br/>rheumai.xyz — NO cableado aquí"]:::xrepo
  O3["Plan de paciente<br/>/p/plan · 'pregunta a RheumAI' pendiente"]:::stub
end

Reg --> O1
AE --> O3
Home -.->|"halo de profundidad"| O2

classDef ship fill:#e4eef8,stroke:#2b6cb0,stroke-width:1px,color:#1b3a57;
classDef gate fill:#f6ecd6,stroke:#9a6a10,stroke-width:1px,color:#5c3f08;
classDef stub fill:#e9ebef,stroke:#6b7280,stroke-width:1px,color:#3b3f48;
classDef xrepo fill:#ece6fb,stroke:#6d45d9,stroke-width:1px,color:#3d2680;

Leyenda (colores del diagrama): azul = enviado y accesible · ámbar = tras bandera / condicional · gris = pendiente / sin construir · violeta = app aparte (rheumai.xyz).

Cada pantalla, cada punto de decisión

Los “puntos de decisión” son las bifurcaciones, compuertas y estados condicionales dentro de cada pantalla — donde el flujo se ramifica y donde tomamos decisiones de producto.

Pantalla	Propósito	Puntos de decisión y compuertas	Estado
`/iniciar-sesion` — Ingresar	Login alojado por Privy.	Al autenticar, retorna a `?next=` (p. ej. un enlace de revisión abierto desde WhatsApp aterriza ahí).	Enviado
`/solicitar-acceso` — Solicitar acceso	Compuerta fail-closed: un médico autenticado pero no aprobado pide acceso.	4 estados de `useAccessStatus`: none → formulario (nombre + cédula + especialidad + consentimiento) · pending · approved → “Entrar” · rejected. Se renderiza en el shell lateral con logout. El correo se sella del lado servidor.	Enviado
`/consola/perfil` — Onboarding	Perfil de primera vez (nombre, especialidad, cédula).	Compuerta en `Shell`: `canUseApp = onboarded
`/consola` — Inicio	Inicio RheumAI — “Nueva consulta” + consultas recientes.	Estados carga / vacío / lista; filas con `draftId` enlazan al Editor de aprobación. Es la entrada del Carril A — el producto de consulta, distinto de la cuña.	Enviado
`/consola/biobadamex` — Inventario	Una lista para toda la cuña; el estado es un filtro, no una pantalla.	Filtro de estado (revisar → sin extraer → en proceso → aprobadas → enviadas → rechazadas → todas) con default inteligente. Filtro de canal ortogonal (whatsapp/consola/masiva) sólo aparece con >1 canal. “Extraer” en lote sólo en el filtro “sin extraer”.	Enviado
`/consola/biobadamex/subir` — Subir	Ingesta desde consola.	Dos modos: pegar (extrae ya) vs archivo (queda en inventario, se extrae después). Acepta `.docx .doc .pdf .txt`, ≤ 25 archivos. La extracción depende de `QUEUE_ENABLED`.	Enviado
WhatsApp file-drop — (servidor, sin pantalla)	El carril de ingesta nativo del chat.	Whitelist o pass-through a triage. consentimiento (ACEPTO/BAJA) → clasifica documento por extensión → auth clínica fail-closed → acuse exactly-once → ingesta (núcleo compartido) → hitos sin PHI. El coach es otra bandera (`COACH_ENABLED`, off por defecto).	Tras bandera
`/consola/biobadamex/:id` — Compuerta de revisión	Revisión de completitud + aprobación no evitable. No edita el expediente en silencio — sólo aprobar/rechazar/corregir.	Checklist por variante: AR → NAD/NAT/DAS-28/VSG/PCR; vasculitis → BVAS; LES → SLEDAI (no obligatorio, pendiente de dueño clínico); ES → Valentini/EUSTAR; EspA/Sjögren → sin instrumento forzado. Compuerta de aprobación = diagnóstico resuelto Y cada fila confirmada Y episodios de biológico confirmados. Corregir reinicia todas las confirmaciones. Aquí no hay “Segunda opinión”.	Enviado
`…/:id → Enviar` — Envío al registro	Empuja el expediente aprobado a BIOBADAMEX (pg-boss → Tenki).	Sólo en la pantalla terminal (aprobada). Sólo dueño (`draft.medicId === me.id`; los admin ven texto, sin botón) · compuerta dura `SUBMIT_ENABLED=1` · comorbilidades Charlson no documentadas exigen un checkbox de “confirmar ausencia”.	Tras bandera
`/…/calificacion` — La calificación	Primera impresión del médico — y la fuente del foso. El veredicto se muestra antes de cualquier pregunta.	Un prompt por campo faltante; cada uno resuelve a acted (→ compuerta de revisión) o dismissed (con motivo). Alimenta el registro de calidad de interrupción.	Enviado
`/consola/borradores/:id` — Editor de aprobación (Carril A)	La pantalla original de aprobación de consulta — diagnóstico + decisiones de tratamiento.	No evitable: todas las filas confirmadas antes de aprobar; códigos de baja confianza marcados. Ya aprobada, “Compartir” genera un magic link del paciente.	Enviado
`/p/plan` — Plan del paciente	Vista de sólo lectura por token (sin login) — el pago del Carril A.	Implementada completa (tratamiento vs lenguaje simple, procedencia). Un stub dentro: “Pregúntale a RheumAI · próximamente”.	Enviado (+ stub)

Dónde muerden las compuertas de lanzamiento

Del registro de compuertas (workstreams/biobadamexai/LAUNCH-GATES.md), mapeadas sobre el flujo. BLOCKER = antes del lanzamiento público · CDSS = antes de anunciar “Preguntar” como apoyo a decisiones citado · BUILD = una superficie prometida aún sin cablear.

Compuerta	Severidad	Dónde muerde
G8 · G9 — orígenes Privy + smoke test de auth	Blocker	Paso de ingreso (login no funciona fuera de dominio hasta permitir orígenes)
G4 — `GET /api/registry/queue` sin proteger	Blocker	rheumai.xyz (app aparte)
G5 · G5c — ingesta WhatsApp + coach	Blocker (ya en producción; la fila del registro está desactualizada)	Carril WhatsApp file-drop
G5b — bypass de auto-respuesta del triage de paciente	Blocker* (aislado del piloto por la whitelist)	Ruta pass-through
G1 · G2 · G3 — barandal recomienda-no-diagnostica, estadísticas sin verificar, unificar citas	CDSS	Salida “Preguntar” (se puede enviar acotado sin esto)
G6 — cableado de Planes de paciente	Build	Salida Planes (el Carril A ya genera /p/plan; el chat in-plan es el stub)
G10 — chequeo de deriva del diccionario de campos	Build	Compuerta de revisión
G7 — bloque “Preguntar” en la landing (diseño)	Build	Landing

Decisiones por fijar

Lo que el mapa deja abierto para el flujo del MVP — las decisiones a tomar mientras lo recorremos.

¿“Preguntar / Segunda opinión” está en el MVP, y desde dónde? No está cableado en la consola — la compuerta de revisión no tiene UI de segunda opinión, y consultRheumaSupport es código muerto. La capacidad vive sólo en la app aparte rheumai.xyz. Decidir: enlazar hacia ella, cablearla, o sacarla del encuadre del MVP.
¿Dos carriles o uno? La consola lleva el producto original consulta→plan (Carril A) y la cuña BiobadamexAI (Carril B). El rebrand mantiene ambos como nav de nivel superior. Para el MVP, ¿el Carril A está en alcance, o el lanzamiento es estrictamente la cuña?
¿Dónde aterriza primero el clínico — y sobre qué? El inicio de consola es la superficie de consulta original, no la cuña. Para un clínico captado para BIOBADAMEX, ¿/consola debería abrir con la cuña (notas por revisar) en lugar de “Nueva consulta”?
SLEDAI y los conjuntos obligatorios por variante. Los instrumentos de LES se renderizan pero no son obligatorios (pendiente de dueño clínico); EspA/Sjögren no fuerzan instrumento. El conjunto de campos obligatorios por variante es la definición de completitud — necesita el visto bueno clínico antes de calificar notas reales.
Envío al registro — ¿activo para el piloto? El envío es sólo-dueño y con compuerta dura SUBMIT_ENABLED. Confirmar la postura de la bandera para el piloto de 20 médicos: ¿envían al registro en vivo, o paran en “aprobado” mientras se valida el ciclo?