petid — overview

Memoria rápida de los flujos del ecosistema petid que no se reconstruyen fácil leyendo el código. No es un manual de arquitectura — si un CRUD o un concepto genérico del framework no aparece acá, es a propósito.

Ecosistema

Cuatro clientes contra un único backend (petid-api), que delega todo email/push anotification-api. notification-worker es el único que habla con FCM/APNs/el email-server, y es también el único camino de vuelta hacia petid-api(purga de tokens muertos, vía webhook).

Notificaciones: un tenant fijo, no el de la clínica

Todo email/push que sale de petid-api viaja bajo el tenant literal "petid-system" en notification-api — nunca el tenant real de la clínica que disparó el evento. Ese tenant real solo va como dato de analytics, no decide qué plantilla ni qué credenciales se usan. Detalle completo en notification-template-routing.

Todos los flujos

• 2FA: setup, activación, login y baja

  TOTP con secret provisional, backup codes de un solo uso mostrados una vez, y fallback de código de respaldo en el challenge de login.

  petid-apipetid-client
• Alta de usuario → activación por email

  El staff da de alta (o el owner se registra); la contraseña temporal nunca se conoce, la cuenta se activa siempre por el link de email.

  petid-apipetid-crmpetid-landingpetid-client
• Cambio de estado de cita → push solo en cancelación

  Solo CANCELLED dispara push al dueño; COMPLETED/NO_SHOW/SCHEDULED quedan en silencio a propósito.

  petid-crmpetid-apipetid-client
• Contact Request (descubrimiento cross-tenant)

  Staff pide acceso a un perfil externo público; el código de 6 dígitos viaja solo al dispositivo del dueño, nunca al que lo pidió.

  petid-crmpetid-apipetid-client
• Login: refresh rotation + detección de reuso

  Cada refresh gira el token y mata la sesión; si el token viejo reaparece, se asume robo y se revoca toda la familia de sesiones.

  petid-api
• Provisioning de tenant desde superadmin

  Transacción atómica en petid-api + espejo NO transaccional en notification-api — si el espejo falla, el tenant queda huérfano allá.

  petid-adminpetid-apinotification-api
• Recordatorios de cita (cron diario)

  Cron a las 18:00 que empuja recordatorios; una cita CANCELLED programada para mañana igual recibe el push si nadie más la filtra.

  petid-apipetid-client
• Registro de push token + purga de tokens muertos

  Upsert por token (no por usuario) para manejar rotación y dispositivos compartidos; la purga de tokens muertos llega por webhook desde notification-worker.

  petid-apipetid-clientnotification-worker
• Ruteo de notificaciones: tenant fijo + code por evento

  Todo email/push de petid-api sale bajo el tenant 'petid-system' en notification-api — el tenant real de la clínica solo viaja como dato de analytics.

  petid-apinotification-api
• Scan de placa QR → perfil público + push con cooldown

  Página pública sin auth que respeta toggles de visibilidad y solo avisa al dueño una vez cada 10 minutos, no en cada scan.

  petid-landingpetid-apipetid-client