Estado técnico de Check-ins (2026-02-16)

Esta página resume qué está realmente implementado y qué sigue temporal en el módulo Check-ins.

Estado por capa

Capa	Estado	Detalle
Navegación web	Disponible	La ruta /checkins aparece para OWNER_ADMIN, GYM_MANAGER, STAFF.
UI web /checkins	Temporal / diseño	Formulario visual sin integración de alta real al backend desde esa pantalla.
API POST /api/v1/checkins	Implementado	Endpoint operativo con validaciones de rol, tenant, gym scope y deduplicación por dedupKey.
Discovery visual	Parcial	Valida render de pantalla y acción UI, pero no valida persistencia real.
Documentación de flujos por rol	En ajuste	Se marca WARN/WIP hasta completar integración web + estabilizar errores intermitentes.

Qué está implementado hoy

• Endpoint: POST /api/v1/checkins
• Roles permitidos: SUPER_ADMIN, OWNER_ADMIN, GYM_MANAGER, STAFF
• Guardas de seguridad: JwtAuthGuard, RolesGuard, TenantGuard
• Validaciones de negocio:
  • owner scope y gym scope por rol
  • pertenencia miembro-gimnasio
  • idempotencia con dedupKey por gimnasio
  • límite diario por política (CHECKIN.MAX_PER_DAY) si existe scope CENTER

Qué sigue temporal / incompleto

• La página web /checkins mantiene copy explícito de modo diseño y no ejecuta POST /checkins desde el botón.
• El e2e específico de página solo valida que renderiza el título.
• El flujo de discovery checkins_manual rellena y hace click, pero no verifica registro persistido.
• En Staff existe registro de error 500 intermitente en discovery.

Criterio para pasar a "Operativo"

1. Integrar el formulario web con POST /api/v1/checkins.
2. Añadir feedback de éxito/error e idempotencia en UI.
3. Actualizar e2e para validar persistencia real (no solo render/click).
4. Eliminar error 500 intermitente en flujo Staff.
5. Regenerar capturas y actualizar estado en guías/backoffice a Operativo.