Onboarding status

TL;DR

Tablero de estado del onboarding del plantel: muestra cuántos jugadores tienen cuenta linkeada (auth_user_id != null), cuántos están elegibles para activar, cuántos no tienen email pre-cargado y los casos inconsistentes (onboarding_consumed_at seteado pero sin auth_user_id). Ruta en código: /dashboard/onboarding-status.

Para comercial

• Problema que resuelve: el HoP necesita saber quién falta activarse para repreguntarle por WhatsApp o cargarle el email. Sin esta vista, tendría que cruzar listas en Excel.
• Casos de uso típicos: segunda semana post-arranque de CÉNIT, el HoP revisa quién no entró y manda recordatorio al 30% que sigue afuera.
• Planes que lo incluyen: todos.
• Diferenciador: corta el ciclo de soporte — el club ve los estados sin escribirnos.

Cómo lo usa el staff

Acceso y permisos

• Roles: hop, dir, sc. Cualquier otro rol queda redirigido.

Flujos paso a paso

• Revisar contadores. En la cabecera hay 4 counters:
  • Linkeados (verde) — jugadores con auth_user_id != null.
  • Elegibles (warn) — activos, sin auth, con email pre-cargado. Pueden activar via link grupal sin tipear nada.
  • Sin email (neutral) — activos, sin auth, sin email. Van a tener que tipear su mail en el flow de confirmación, o el HoP se los carga desde Plantel.
  • Inconsistente (danger) — onboarding_consumed_at está seteado pero auth_user_id quedó NULL. Edge case del race handler que requiere intervención manual.
• Filtrar y accionar por jugador. La tabla lista todos los jugadores con foto, dorsal, posición, email cargado, estado y fecha de consumo. Desde acá el HoP identifica al jugador específico y va a Plantel a cargarle el mail si falta, o reinvitarlo via Plantel → Invitar (legacy individual).

Configuración relacionada

• El estado se computa en el server al renderizar la página: inactive > linked > consumed_unlinked > no_email > eligible. Pure read — esta página no muta datos.

FAQ / casos límite

• ¿Por qué un jugador aparece como consumed_unlinked? El handler linkPlayerAfterPasswordSet setea auth_user_id y onboarding_consumed_at en el mismo UPDATE, pero si el JWT no tiene user_metadata.player_id (caso histórico de invitación individual mal etiquetada) el linkeo no ocurre. Es el bug #10 documentado en PROJECT_STATE.md — sin repro reproducible. Si aparece, contactar soporte para parchar manualmente.
• Jugadores inactive: no entran en los contadores principales (se muestran en la tabla pero con badge separado).

Cómo lo ve el jugador

Player surface: N/A. Esta página es solo para staff.

Datos y métricas

Tablas DB

• players — auth_user_id, onboarding_consumed_at, email, status son los campos críticos para clasificar.

Estados posibles

Estado	Condición
linked	auth_user_id != null
consumed_unlinked	onboarding_consumed_at != null y auth_user_id == null (edge)
no_email	activo, sin auth, sin email cargado
eligible	activo, sin auth, con email cargado
inactive	status == 'inactive'

Integraciones

• Plantel — para corregir mails faltantes o reactivar jugadores inactive.
• Onboarding link grupal — esta página es el panel inverso del link: si el link es “salida”, este es “estado”.

Limitaciones / roadmap

• No hay export CSV de la tabla (consistente con el gap general de excel_export documentado en PROJECT_STATE.md).
• No hay filtro/búsqueda en el tab — para planteles grandes (>50) el HoP scrollea. [NEEDS_USER: validar si vale priorizar filtros.]
• El estado consumed_unlinked no tiene action de “re-linkear” desde la UI — hoy requiere intervención manual sobre la DB.