petid-wikimemoria rápida, no arquitectura

QA Deployments

Checklist de humo tras un deploy, en el orden que respeta las dependencias reales entre apps: primero el backend, después quien provisiona un tenant, después quien da de alta gente dentro de ese tenant, y al final quien la consume. No es un test suite — es lo mínimo para confirmar que un deploy no rompió el camino feliz.

1. petid-api

  1. GET /health → 200.
  2. Login con una cuenta existente sin 2FA (POST /auth/login) → devuelve accessToken + cookie de refresh; un segundo POST /auth/refresh debe rotar el token, no reusar el mismo (ver login-refresh-rotation).

2. petid-admin

  1. Login superadmin. Usar una cuenta sin 2FA — LoginComponent.submit() no maneja el challenge ({mfaRequired, challengeToken}): con 2FA activo "entra" igual a /dashboard, pero sin token real, y todo lo demás falla en silencio con 401.
  2. Crear un tenant nuevo en Tenants → confirmar que también aparece del lado de notification-api — el espejo no es transaccional, puede quedar huérfano ahí si algo falla (ver tenant-provisioning).
  3. Abrir Templates y Notification logs — aunque estén vacíos, confirma que el token del superadmin autentica de verdad contra endpoints protegidos, no solo contra /auth/login.

3. petid-crm

  1. Login staff del tenant recién creado (o uno existente). Si esta cuenta sí tiene 2FA, el challenge acá sí está manejado — a diferencia de admin.
  2. Dar de alta un owner nuevo en Users → dispara el email de activación; confirmar que llega y que el link apunta a un dominio real, no al placeholder de petid-landing (ver account-activation).
  3. Cargar una mascota y una cita para ese owner — deja el terreno listo para el paso 4.

4. petid-client

  1. Activar la cuenta desde el link del email y hacer login.
  2. Activar 2FA en Ajustes, cerrar sesión y volver a entrar — confirmar el challenge con TOTP y con un backup code (ver 2fa-lifecycle).
  3. Confirmar que el push token se registra — en un dispositivo/emulador con Play Store (un AVD sin Play Store no genera token real, ver push-token-registration).
  4. Desde crm, cancelar la cita cargada en el paso 3 → debe llegar push al owner; probar también otro cambio de estado (ej. completada) y confirmar que ese no dispara nada (ver appointment-status-push).
  5. Visitar la URL pública de la placa QR de la mascota → perfil visible según los toggles configurados, y aviso al dueño solo una vez cada 10 min si se repite el scan (ver pet-tag-scan-notify).