# DECISIONES-RCH — Registro de decisiones de diseño y producto > Rebelocity Club · Iniciado: junio 2026 · Última actualización: julio 2026 > > Este documento registra las decisiones tomadas durante el diseño del producto, con el contexto y razonamiento detrás de cada una. Su propósito es evitar que decisiones ya debatidas se deshagan por desconocimiento, y dar a los nuevos integrantes del equipo el "por qué" de cómo está construido todo. > > Cada entrada tiene: la decisión, el contexto que la motivó, y la regla que se deriva de ella. --- ## Índice - [Color y marca](#color-y-marca) - [Componentes interactivos](#componentes-interactivos) - [Layout y estructura](#layout-y-estructura) - [Integridad de datos](#integridad-de-datos) - [Flujos de mensajería](#flujos-de-mensajería) - [Flujos de relay](#flujos-de-relay) - [Perfil de usuario](#perfil-de-usuario) - [Directorio](#directorio) --- ## Color y marca ### D-001 · El rojo de marca no se usa en botones de acción **Decisión:** El color rojo (`--accent: #E2261C`) se reserva exclusivamente para el logo, el wordmark y alertas críticas del sistema. Los botones de acción principal usan azul (`--blue`). **Contexto:** En una iteración temprana, los botones de acción usaban el rojo de marca porque es el color más reconocible de Rebelocity. Se decidió cambiar porque el rojo comunica "peligro" o "error" en convenciones de UX, lo que generaba confusión con acciones positivas como "Guardar" o "Inscribirse". **Regla:** Nunca usar `--accent` como fondo de un botón de acción genérica (primaria, secundaria o de envío). Los únicos botones que pueden tener rojo son los de rechazo o acciones destructivas, y estos usan `--red` (`#EF4444`) con fondo semitransparente, no el rojo de marca sólido. --- ### D-002 · El azul dark es diferente al azul de marca **Decisión:** En tema dark se usa `#4A80D6` como color azul primario, aunque el azul exacto de marca es `#234E9C`. **Contexto:** El azul de marca `#234E9C` tiene bajo contraste sobre fondos oscuros (ratio insuficiente para legibilidad). Se usó `#4A80D6` como adaptación para el tema dark que mantiene la identidad visual sin sacrificar accesibilidad. **Regla:** En tema dark → `--blue: #4A80D6`. En tema light → `--blue: #234E9C` (azul exacto de marca). Ambos son correctos en su contexto. --- ### D-003 · El footer siempre usa fondo oscuro fijo **Decisión:** El footer usa `background: #0B0F1A` en todos los casos, incluso cuando la página está en tema light. **Contexto:** El footer de Rebelocity tiene un diseño oscuro que forma parte de la identidad visual de la marca. Hacerlo cambiar con el tema de la página rompía la coherencia del footer como elemento de marca. **Regla:** El fondo del footer nunca cambia con el tema. El color de hover en links del footer es `#5B8FDE` (azul más claro) para garantizar contraste sobre el fondo muy oscuro. --- ## Componentes interactivos ### D-004 · Tabs activos, chips seleccionados y toggles usan azul **Decisión:** El estado activo/seleccionado de tabs, chips y toggles siempre es azul (`--blue`), sin excepción. **Contexto:** Se evaluó usar el rojo de marca para marcar selecciones, pero se reservó para los casos semánticos ya definidos. El azul es el color de "acción e interacción" en el sistema. **Regla:** - Tab activo → texto azul + border-bottom azul - Chip seleccionado → fondo azul 12% opacidad + borde azul + texto azul - Toggle activo → fondo azul - Excepción permitida: chips de nivel usan verde (`--green`) para diferenciarlos visualmente de los chips de disciplina/objetivo --- ### D-005 · Los botones de rechazo usan borde rojo semitransparente, no relleno sólido **Decisión:** Los botones de rechazo ("Rechazar") tienen `background: rgba(239,68,68,.08)` y `border: 1px solid rgba(239,68,68,.35)`, no un fondo sólido rojo. **Contexto:** Un botón de relleno sólido rojo llamaba demasiado la atención y hacía que el rechazo pareciera la acción principal, cuando en la mayoría de los flujos la acción esperada es aceptar. La versión semitransparente comunica la acción destructiva sin dominar visualmente. **Regla:** Nunca usar fondo sólido rojo en botones, ni siquiera para acciones de rechazo. El rojo sólido solo es el logo. --- ## Layout y estructura ### D-006 · El footer no aparece en vistas autenticadas **Decisión:** El footer del sitio solo aparece en páginas públicas (home, detalle de evento público, perfil compartido). No aparece en el perfil, Sherpa IA, membresía, mensajería ni panel de admin. **Contexto:** El footer es un componente de navegación pública (links institucionales, redes sociales, copyright). Incluirlo en vistas autenticadas genera ruido visual y confusión — el usuario ya está dentro de la app y no necesita esos links. **Regla:** Antes de agregar el footer a cualquier vista nueva, verificar: ¿esta vista es accesible sin iniciar sesión? Si no, el footer no va. --- ### D-007 · La Save Bar solo aparece en el tab Perfil **Decisión:** La barra de "Descartar / Guardar cambios" fija en la parte inferior solo es visible en el tab Perfil. Los tabs Sherpa IA y Membresía no la muestran. **Contexto:** Sherpa IA tiene su propio CTA de envío ("Enviar al Sherpa") contextual a ese flujo. Membresía no edita datos del perfil. Mostrar la Save Bar en esos tabs crearía confusión sobre qué se guarda. **Regla:** Cada tab que requiere guardar datos tiene su propio CTA contextual. La Save Bar global es exclusiva del tab Perfil. --- ### D-008 · El panel de mensajería es un overlay lateral, no una página nueva **Decisión:** Los flujos de mensajería (contactar coach, contactar club, etc.) se presentan como un panel lateral de 420px superpuesto sobre la vista de fondo, que queda desenfocada. **Contexto:** Mantener el contexto visual del directorio de fondo ayuda al usuario a recordar desde dónde inició la conversación y facilita el retorno a la búsqueda sin perder el estado. **Regla:** Los flujos de contacto siempre se presentan como panel lateral sobre el contexto de origen, nunca como página separada. --- ## Integridad de datos ### D-009 · Solo se muestra información capturada en formularios del perfil **Decisión:** Ninguna tarjeta, modal, chip o metadato puede mostrar un dato que el usuario no haya ingresado explícitamente en algún formulario del producto. **Contexto:** En varias iteraciones aparecieron datos inventados o asumidos (ej. "Coach ITU · 12 años de experiencia", "Martes y jueves 6am", "Fundado en 2018") que nunca se capturaron en ningún formulario. Esto crea expectativas en el usuario que el sistema no puede cumplir, y confunde a los desarrolladores sobre qué datos existen en la base de datos. **Regla:** Antes de mostrar cualquier dato en una tarjeta o modal, preguntar: ¿hay un campo en el formulario de perfil que capture esto? Si la respuesta es no, el dato no se muestra. Los datos del sistema (conteos, fechas de registro) son la única excepción. --- ### D-010 · Años de experiencia del coach no se muestran **Decisión:** No se muestra "X años de experiencia" en ninguna tarjeta ni modal de coaches. **Contexto:** No existe un campo en el formulario de perfil donde el coach ingrese sus años de experiencia. Se mostró en una iteración temprana como dato inventado. **Regla:** Aplica D-009. Si en el futuro se quiere mostrar este dato, primero hay que agregar el campo al formulario de perfil del coach. --- ### D-011 · Certificaciones del coach no se muestran **Decisión:** No se muestra "Coach ITU", "IRONMAN Certified" ni ninguna certificación en tarjetas ni modales. **Contexto:** No existe campo de certificaciones en el formulario. Aplica D-009. **Regla:** Si se quiere mostrar certificaciones en el futuro, crear primero el campo en el perfil (con validación o upload de documento) antes de mostrarlo en el directorio. --- ### D-012 · Horarios de entrenamiento del club no son datos estructurados **Decisión:** Los horarios, días y lugar de entrenamiento de un club (ej. "Martes y jueves 6am, Parque Bicentenario") no aparecen como datos estructurados en tarjetas ni modales del directorio. **Contexto:** No existe campo en el formulario de creación de club para capturar horarios ni lugar de entrenamiento. En iteraciones previas aparecieron como datos inventados en la tarjeta de contexto del club dentro de los flujos de mensajería. **Regla:** Esta información se comparte de forma libre en el chat entre el atleta y el admin del club. El chat es el canal correcto para este tipo de detalle operativo, no los campos estructurados del perfil. --- ### D-013 · Cupo máximo del club no se muestra **Decisión:** No existe un campo de "cupo máximo" ni "lugares disponibles" en los perfiles de clubs. **Contexto:** Se mostró "52 Cupo máx. / 4 Lugares libres" en una iteración del panel de admin del club. Estos datos nunca fueron capturados en ningún formulario. **Regla:** El único dato numérico permitido sobre el club es el número de miembros actuales, que es un conteo derivado del sistema (cuántos usuarios tienen ese club asignado), no un campo manual. --- ### D-014 · El año dentro del objetivo del atleta no se muestra en los chips de objetivo **Decisión:** Los chips de "Gran objetivo" muestran solo el nombre de la prueba (ej. "IRONMAN 70.3"), sin año. **Contexto:** El campo "Gran objetivo" del perfil captura la prueba, no la fecha. El año de una carrera específica se captura en el bloque relay (campo "Carrera"). En una iteración se mostró "IRONMAN 70.3 2026" en el chip de objetivo, mezclando datos de dos campos distintos. **Regla:** El campo objetivo → nombre de la prueba sin año. El año de una carrera específica solo vive en el campo relay. --- ### D-015 · El label "Nivel" se usa igual para atletas y coaches **Decisión:** En el directorio, tanto las tarjetas de atletas como las de coaches muestran el campo como "Nivel", con las mismas opciones (Principiante / Aficionado / Avanzado / Élite). **Contexto:** En una versión del modal del directorio se mostraba el label "Experiencia" para coaches (implicando años de experiencia) y "Nivel" para atletas, cuando ambos usan el mismo campo del formulario. **Regla:** El label siempre es "Nivel" para todos los roles. Si en el futuro se quiere un campo específico de nivel de expertise para coaches, debe crearse como campo independiente. --- ### D-016 · Datos derivados del sistema sí pueden mostrarse **Decisión:** Algunos datos no vienen de formularios del usuario pero sí pueden mostrarse porque los genera el sistema automáticamente. **Contexto:** Para no confundir con D-009, se definió qué datos son "del sistema" y por tanto válidos. **Datos del sistema permitidos:** - Número de miembros del club (conteo de usuarios con ese club asignado) - Fecha de registro como miembro ("Miembro desde 2024") - Puntos de lealtad acumulados - Número de eventos asistidos - Porcentaje de perfil completado **Regla:** Un dato "del sistema" es aquel que el sistema calcula o registra automáticamente sin que el usuario lo ingrese. Cualquier otro dato requiere su campo en el formulario. --- ## Flujos de mensajería ### D-017 · Aceptar el primer mensaje de un club no equivale a membresía **Decisión:** Cuando el admin de un club acepta abrir el chat con un atleta ("Abrir chat"), esto no convierte al atleta en miembro del club. Son dos acciones completamente separadas. **Contexto:** En el diseño inicial del flujo de mensajería con clubs, la pantalla de confirmación del paso 2 decía "¡Ya eres miembro del club!" al abrir el chat. Se corrigió cuando se aclaró el proceso real: primero hay un periodo de intercambio de mensajes (y posiblemente una sesión de entrenamiento de prueba) antes de que el admin decida si agrega formalmente al atleta como miembro. **Regla:** El flujo de mensajería con un club solo gestiona la comunicación. La membresía se otorga desde el panel de gestión del club (tab "Mi club" en el perfil del admin), de forma manual, cuando el admin lo considera apropiado. --- ### D-018 · La membresía del club se gestiona desde el panel de miembros, no desde el chat **Decisión:** No hay ningún botón de "Agregar como miembro" dentro de la ventana de chat del admin del club. **Contexto:** En una iteración del panel de admin existía un banner dentro del chat (paso 3) con el botón "Agregar". Se eliminó porque mezcla dos contextos distintos: la conversación (chat) y la gestión del club (panel de miembros). Además, la decisión de membresía no debería tomarse en caliente dentro de una conversación, sino desde la sección de gestión. **Regla:** La acción "Agregar miembro" existe exclusivamente en el panel de administración del club (sidebar → Miembros → Agregar miembro). El chat solo sirve para comunicarse. --- ### D-019 · "Ver perfil completo" no está disponible desde el chat **Decisión:** No hay un link o botón "Ver perfil completo" dentro de los paneles de mensajería. **Contexto:** Se incluyó en una iteración del panel de admin del club, debajo del nombre del atleta. La funcionalidad de ver el perfil completo de otro usuario desde el chat no está implementada ni diseñada aún. **Regla:** No agregar funcionalidades que no están diseñadas. Si en el futuro se diseña la vista de "perfil de otro usuario", entonces se puede agregar el link desde el chat. --- ### D-020 · Los flujos de mensajería tienen estado de rechazo con 2 pasos (no 3) **Decisión:** Cuando el coach o el admin del club rechaza la solicitud, el flujo termina en el paso 2 de confirmación. No existe un paso 3 (chat) en el flujo de rechazo. **Contexto:** En las versiones iniciales el paso 3 existía en todos los casos. Al diseñar el flujo de rechazo se identificó que el paso 3 (chat activo) solo tiene sentido si hay una conversación que continuar. **Regla:** En modo rechazo: 2 pasos (solicitud → confirmación de rechazo). En modo acepta: 3 pasos (solicitud → confirmación de apertura → chat). Los dots de progreso deben reflejar esto: "2/2" vs "2/3". --- ## Flujos de relay ### D-021 · El relay tiene solo dos estados: "Busco equipo" y "Relay completo" **Decisión:** Los estados del relay son únicamente dos — "Busco equipo" (dorado, 🤝) y "Relay completo" (verde, ✓). No existe un tercer estado de "Reemplazo" ni "Busca [disciplina]". **Contexto:** Cuando un integrante salía del equipo, se había diseñado un estado intermedio "Busca ciclista" (rojo, ⚠️) para indicar que el equipo necesitaba un reemplazo en una disciplina específica. Esto creaba tres estados distintos y generaba confusión en el directorio y en los filtros. El estado "Busca ciclista" también implicaba lógica adicional en los filtros (¿aparece o no en "Busco equipo"?). **Regla:** Cuando un integrante sale de un equipo, los miembros restantes simplemente vuelven a "Busco equipo" — exactamente el mismo estado que tenían antes de formar el equipo. El miembro que se fue también regresa a "Busco equipo". No hay estados intermedios. --- ### D-022 · La palabra "reemplazo" no se usa en ningún contexto del relay **Decisión:** En todos los textos del sistema relacionados con el relay, se usa "buscar un nuevo integrante" en lugar de "buscar un reemplazo". **Contexto:** La palabra "reemplazo" tiene una connotación impersonal que no encaja con el tono de comunidad del producto. "Nuevo integrante" es más neutro y positivo. **Regla:** En copywriting del relay: usar "nuevo integrante", "buscar equipo" o "completar el equipo". Evitar "reemplazo", "sustituto" o similares. --- ## Perfil de usuario ### D-023 · Rol Coach activa el tab "Mi club" y oculta "Busco coach" **Decisión:** Seleccionar el rol Coach en el formulario del perfil activa automáticamente el tab "Mi club" en la navegación de pestañas, y oculta el toggle "Busco coach o entrenador". **Contexto:** Un coach no busca coach para sí mismo (en el contexto de este producto), y sí necesita gestionar su club. La UI condicional evita mostrar opciones irrelevantes según el rol. **Regla:** Esta lógica se aplica con JavaScript en el cliente. El tab "Mi club" nunca es visible por defecto — solo aparece cuando el chip "Coach" está activo en el campo Rol. --- ### D-024 · El hero banner / portada del perfil está desactivado **Decisión:** Los perfiles no tienen imagen de portada (hero banner) en esta versión. **Contexto:** Se evaluó agregar una imagen de fondo en la sección del hero del perfil, similar a LinkedIn o Strava. Se decidió posponerlo para mantener la complejidad del formulario manejable y porque el valor diferencial de Rebelocity no está en la personalización visual del perfil sino en la funcionalidad de comunidad. **Regla:** No agregar campos de portada o imagen de fondo al perfil hasta que se diseñe explícitamente la funcionalidad y se valide con usuarios. --- ## Directorio ### D-025 · Las tarjetas del directorio se abren en modal, no en página nueva **Decisión:** Al hacer clic en una tarjeta del directorio, el detalle del perfil se muestra en un modal centrado sobre la misma página. **Contexto:** El modal permite ver el detalle y regresar al directorio (con el mismo filtro activo) de forma rápida. Una página nueva implicaría perder el estado del filtro y el scroll del grid. **Regla:** El modal se cierra con el botón ✕ o haciendo clic fuera de él (en el backdrop). El backdrop solo cierra el modal si el clic es directamente sobre él, no sobre el modal en sí. --- ### D-026 · Los filtros del directorio se resetean al cambiar de tab **Decisión:** Al cambiar entre tabs (Atletas / Coaches / Clubs), todos los filtros activos se limpian automáticamente. **Contexto:** Los filtros de cada tab son distintos (el filtro de "Especialidad" de coaches no aplica a atletas, por ejemplo). Mantener filtros activos de un tab al cambiar a otro podría mostrar resultados inesperados o vacíos. **Regla:** El cambio de tab siempre resetea: búsqueda por texto, disciplina seleccionada, filtros secundarios y chips de filtro activos. --- *Para agregar una nueva decisión: copiar el formato `### D-NNN · [Título]` con los campos Decisión, Contexto y Regla. Incrementar el número de decisión.*