Settings

TL;DR

/dashboard/settings concentra toda la configuración del club: identidad visual, subdomain (slug), perfil personal, parámetros de fórmulas (ventana MD, método ACWR), tabs visibles del perfil de jugador, tipos de sesión, umbrales de riesgo, gestión de equipos y accesos del staff. Es página única con sub-tabs internos (no hay páginas separadas).

Para comercial

• Problema que resuelve: cada club tiene su propia identidad, metodología y umbrales. Sin Settings, CÉNIT sería una caja rígida; con Settings, el club configura lo suyo sin pedirnos un release.
• Casos de uso típicos: subir el logo y los colores del club, ajustar el rango ACWR ok/warn según el sport-scientist del club, decidir qué tabs del perfil de jugador ven (esconder “mental” si no hay psicólogo todavía), ampliar la ventana de partido modelo (md_max_window_days) cuando hay pocas fechas históricas.
• Planes que lo incluyen: todos. La rama custom_branding (colores y logo) está prometida solo para pro/enterprise pero hoy no tiene gate — ver “Limitaciones”.
• Diferenciador: el grueso de competidores fija fórmulas y thresholds. CÉNIT los expone por org.

Cómo lo usa el staff

Acceso y permisos

• Tab “Configuración” (principal): lectura para todos; los forms que mutan la org solo aceptan escritura de hop y dir (helper requireAdminOrgId). El ProfileForm (perfil propio) es excepción: cualquier rol edita lo suyo.
• Tab “Equipos”: solo hop / dir. Crea sub-equipos (teams) y asigna jugadores y staff.
• Tab “Accesos”: solo hop / dir. Invita y revoca usuarios del staff de la org (ver también Usuarios).

Sub-secciones del tab “Configuración”

1. Identidad del club (ClubForm) — nombre, logo (PNG/JPG/WebP hasta 5MB), color primario y secundario en hex. Los colores sobreescriben las CSS custom properties --azul y --rojo para la org.
2. Slug del club (SlugForm) — subdomain kebab-case, 2-40 caracteres, regex ^[a-z0-9]+(-[a-z0-9]+)*$. Preview slug.cenitapp.com. Único por organización (white-label fase 1 pasiva — middleware.ts detecta el subdomain y lo expone como header, sin enforcement aún).
3. Perfil (ProfileForm) — nombre, locale (es/en/pt), avatar. Edita siempre el perfil propio, sin importar el rol.
4. Plantel — datos del equipo (SquadForm) — nombre del equipo, temporada, fecha de inicio de temporada, división.
5. Tipos de sesión (SessionTypesForm) — gestiona org_session_types (label, color, orden, activo). Lo usa el modal de evento del Calendario.
6. Ventana MD (MdWindowForm) — md_max_window_days, rango 90-360 días, default 90 (migration-100 amplió el rango y auto-bumpea valores legacy de 28). Define cuántos días hacia atrás mira get_md_reference_per_player para calcular el partido modelo (mean del top-3 con tier system T1/T2/T3 según minutos jugados).
7. Vista del microciclo (MicrocycleViewForm) — training (solo entrenamientos) o training_match (incluir partido como referencia). Default training_match.
8. Método ACWR (AcwrMethodForm) — rma (default, ratio convencional) o ewma (Williams 2017, opt-in via organizations.acwr_method).
9. Tabs visibles del jugador (VisibleTabsForm) — controla qué tabs del perfil de jugador se renderizan. Keys posibles: general, tactico, fisico, medica, mental, mensajes. Se guarda como JSONB en organizations.visible_player_tabs.
10. Umbrales de riesgo (RiskForm) — todos los thresholds que consume compute_daily_risk_snapshots y la UI de Risk Advisor: acwr_min/max/warn_min/warn_max, hooper_ok/warn, vmax_ok/warn, pain_warn, inj_warn, physio_thr, anxiety_thr. Sin defaults hardcoded — siempre lee DEFAULT_THRESHOLDS como fallback inicial.

FAQ / casos límite

• El slug ya está tomado: error de unique constraint a nivel DB; el form lo muestra como “Slug en uso”.
• Cambio de método ACWR: se aplica al próximo cron de compute_daily_risk_snapshots. Los snapshots históricos no se recalculan.
• Esconder tabs del jugador: el filtro corre en server side al renderizar /dashboard/plantel/[id]. Un staff con link directo al tab oculto sigue viendo la URL pero no el contenido.

Cómo lo ve el jugador

Player surface: N/A. El jugador no entra a Settings, pero lo que el HoP configura impacta directamente en lo que ve: colores y logo del club en su PWA, tabs del perfil, y umbrales de riesgo que generan alertas en su feed.

Datos y métricas

Tablas DB / RPCs

• organizations — todas las settings de la org (name, slug, logo_url, primary_color, secondary_color, plan, team_name, season, season_start, division, md_max_window_days, microcycle_view, acwr_method, visible_player_tabs, risk_*).
• user_profiles — perfil del usuario actual (full_name, locale, avatar_url).
• user_org_memberships — fuente de verdad multi-org para accesos.
• org_session_types — tipos de sesión personalizados.
• teams + staff_team_assignments — sub-equipos y asignaciones.

Integraciones

• Carga GPS: consume md_max_window_days, microcycle_view, acwr_method, org_session_types.
• Risk Advisor: consume todos los risk_* thresholds.
• Plantel: consume visible_player_tabs para filtrar tabs del perfil.
• Shell del dashboard: consume logo_url, primary_color, secondary_color para skin de la org.

Limitaciones / roadmap

• custom_branding sin gate: plan esencial puede subir logo y colores aunque el feature flag esté solo en pro/enterprise. TODO de gating documentado en PROJECT_STATE.md.
• Slug sin enforcement: la detección de subdomain es pasiva (white-label fase 1). Fase 2 (DNS wildcard + cookies cross-subdomain
  • login skin) pendiente.
• No hay audit log de cambios de settings. Los triggers de audit_log (migration-010) auditan datos clínicos / wellness / user_profiles, pero NO la tabla organizations. Cambios de slug, colores, ventana MD, pesos del riesgo, tipos de sesión, etc. no quedan registrados. Si Enterprise lo pide, agregar trigger sobre organizations.