---
type: OUT
asset_id: OUT-REB-RClub-RespuestaValidacionPuntos-Jesus-v01
version: v01
status: Enviable — criterios para avanzar
owner: Victor Heredia
sherpa_owner: Jay
fecha_creacion: 2026-06-16
fecha_ultima_actualizacion: 2026-06-16
intellbank: IB-REB-Rebelocity
subbank: —
dirigido_a: Jesús — Equipo de Desarrollo
responde_a: 2026-06-15-guia-validacion-equipo.md (validación de point_actions y point_rewards + 17 preguntas)
tipo_largo: Respuesta de validación al equipo de desarrollo — datos de point_actions/point_rewards, respuestas a las 17 preguntas, y el cambio de modelo (red de lealtad financiada por el comercio + Clearing House) que fija los criterios para avanzar.
proposito: Dejar establecidos, en un solo documento, los criterios que Jesús necesita para avanzar: qué se valida tal cual, qué se corrige, qué se difiere, y la nueva dirección del programa de puntos como generador de ingresos.
referencias_canonicas:
  - DC-REB-RClub-SistemaPuntosMembresias-v01 (motor Points v2 · doc canónico)
  - SPEC-REB-RClub-ClearingHouse-v01 (modelo de red financiada por el comercio · economía)
  - SPEC-REB-RClub-NumeracionTarjetas-v02 (la tarjeta como riel transaccional)
  - SPEC-REB-RClub-CatalogosAfiliacion-v01 (catálogos de afiliación ratificados)
---

## Asset Header

- **Asset ID:** OUT-REB-RClub-RespuestaValidacionPuntos-Jesus-v01
- **Version:** v01 · **Status:** Enviable
- **Owner:** Victor Heredia · **Sherpa:** Jay
- **Dirigido a:** Jesús — Equipo de Desarrollo
- **Responde a:** `2026-06-15-guia-validacion-equipo.md`
- **Última actualización:** 2026-06-16

---

# Respuesta de validación — Sistema de Puntos RClub

Jesús, gracias por la guía. Abajo va todo lo que pediste: la validación fila por fila, las 17 respuestas, y —lo más importante— **un cambio de dirección del programa** que define los criterios para avanzar. Léelo en este orden: primero el cambio de modelo (§0), porque reordena varias de tus preguntas.

---

## 0. Cambio de modelo — los puntos pasan de PASIVO a GENERADOR DE INGRESO

Decisión de Victor. El programa de puntos **no es un costo de fidelización**; es una **red de lealtad financiada por el comercio** (modelo tipo monedero/cashback, ya analizado en `DC-IS-AnalisisCompetitivo-TDU`). El detalle completo está en `SPEC-REB-RClub-ClearingHouse-v01`. Lo esencial para ti:

- **Valor del punto (ancla declarada): 1 punto = US$0.02** (100 pts = $2). Todo se precia contra esto.
- **Compra en comercio afiliado:** el comercio paga **7% (MDR)** a RClub; RClub devuelve **2% en puntos** al socio; RClub retiene **5%** (más breakage). El punto se **gana** por consumo, financiado por la transacción que lo creó.
- **El canje se dirige hacia canales de bajo costo para RClub:** breakage (no se canjea) · **biblioteca/digital propio (~$0)** · eventos propios (tu margen, llena cupos) · regalo de sponsor (lo paga el sponsor). Efectivo/externo: **no se ofrece**.
- **La tarjeta (PAN de 16 díg., ver `…-NumeracionTarjetas-v02`) es el riel transaccional:** el comercio identifica al socio por número de tarjeta/QR y ancla la transacción.

**Implicación para backend:** además del motor Points v2 actual, entran tres componentes nuevos: **Clearing House** (liquidación), **Portal de comercio afiliado** (registro de consumo), y la **acción de earning por consumo** (`affiliate_purchase`, 2% del monto). No los construyas aún — primero valida criterios; pero tenlos en el radar de arquitectura.

---

## 1. Validación de `point_actions`

Leyenda: ✅ correcto · ❌ corregir · ➖ no aplica a RClub (es de MPB).

| action_key | pts | cooldown | Validación | Nota |
|---|---|---|---|---|
| `signup` | 100 | once | ✅ | OK global. |
| `verify_email` | 50 | once | ✅ | OK global. |
| `complete_profile` | 50 | once | ✅ | OK global. |
| `read_summary` | 10 | daily | ⚠️ | Falta `max_per_period` = **50/mes** (está en el doc canónico). Es de MPB, no de RClub. |
| `read_playbook` | 50 | once | ➖ | Acción de MPB. No aplica a socios RClub. |
| `purchase_playbook` | 200 | once | ➖ | MPB. |
| `purchase_membership` | 500 | monthly | ✅ | OK (aplica si RClub vende membresía premium). |
| `write_review` | 30 | weekly | ✅ | OK, con tope 4/mes. |
| `daily_visit` | 5 | daily | ✅ | OK — earning "gratis" pequeño, correcto. |
| `social_share` | 15 | daily | ❌ | La guía dice `daily` pero el doc canónico fija **máx 3/mes**. Sin tope es farmeable (450/mes). Fijar `max_per_period = 3`. |
| `referral_signup` | 200 | **once** | ❌ | **Bug crítico:** `once` deja referir a UNA sola persona en la vida. Debe ser **por-referido con tope mensual (máx 10/mes)**, como el doc canónico §8. Mata el motor de referidos si queda `once`. |
| `referral_complete` | 100 | once | ❌ | Igual que arriba — por-referido, no `once`. |
| `survey` | 100 | monthly | ✅ | OK. |
| `ticket_purchase` | 150 | NULL | ✅ | OK — clave para RClub (eventos). Considerar volverlo **2% del precio del boleto** para alinear con el modelo de spread. |
| `event_checkin` | 50 | NULL | ✅ | OK. |
| `event_complete` | 100 | NULL | ✅ | OK. |

**Acción nueva a crear (modelo nuevo):**

| action_key | pts | cooldown | Nota |
|---|---|---|---|
| `affiliate_purchase` | **2% del monto** (1pt=$0.02) | NULL | Consumo en comercio afiliado. La acción central del nuevo modelo; la registra el Clearing House, no el cliente. |

---

## 2. Validación de `point_rewards`

**Hallazgo de fondo:** el catálogo actual es de **MasterPlaybooks**, no de RClub. Un atleta no quiere un "playbook gratis" ni "Premium MPB". RClub necesita su **propio catálogo de recompensas temático de endurance**. El motor multi-org ya lo soporta (recompensas por `organization_id`).

| reward_key actual | Validación para RClub |
|---|---|
| `playbook_discount_10/25` | ➖ MPB. |
| `playbook_free` | ➖ MPB (pero el patrón "producto digital gratis" SÍ aplica → ver biblioteca abajo). |
| `premium_month/year` | ⚠️ Aplica solo si RClub vende membresía premium propia. |
| `event_priority` | ✅ Excelente para RClub. |
| `swag_pack` | ✅ Pero re-tematizar (jersey/merch deportivo). |

**Catálogo de recompensas propuesto para RClub** (precios a 1pt=$0.02, ordenado por costo para RClub de menor a mayor):

| reward_key | recompensa | costo (pts) | valor | canal / quién financia |
|---|---|---|---|---|
| `library_unlock` | Contenido/plan de entrenamiento digital | 500 | $10 | **Biblioteca propia (~$0 costo)** |
| `event_discount_10` | 10% off inscripción a evento | 1000 | $20 | Evento propio (tu margen) |
| `event_priority` | Cupo/slot prioritario | 1500 | $30 | Evento propio |
| `sponsor_gift` | Producto de sponsor (ej. remera UA en Sallutro) | variable | fijo | **Sponsor/comercio (su CAC)** |
| `race_entry` | Inscripción gratis a evento | 2500 | $50 | Evento propio |

> Regla de catálogo: **cargar el canje hacia biblioteca / eventos / sponsor; NO ofrecer canje a efectivo.**

---

## 3. Respuestas a las 17 preguntas

### Economía

1. **Balance correcto.** Con onboarding 200 pts, la recompensa más barata (100) queda cubierta de inmediato. La más cara (5000) **solo con visita diaria** tomaría ~2.6 años → confirma que el earning fuerte debe venir de **consumo afiliado, eventos y referidos**, no de acciones gratis. (Simulación hecha.)
2. **Thresholds.** NORMAL 0 · CLASICA 500 · ORO 2000 · PLATINO 5000 está bien calibrado: un socio activo llega a **Oro en ~3 meses** ✅. **Pero** un power-user llega a Platino en ~2 meses → recomendamos **subir Platino (~8–10K)** o agregar un 5º nivel por invitación, para que el tope no se devalúe.
3. **Penalización.** Sí. Refund/abuso = transacción **negativa** (el ledger es append-only, se reversa, no se borra). Crear `refund`/`adjust`. El abuso de farming ya lo cubren cooldowns + topes.
4. **Expiración.** Por diseño, los puntos **no expiran** (principio del doc canónico). El breakage natural (no canje) ya nos favorece en el modelo nuevo. Mantener sin expiración; revisar solo si el pasivo creciera.

### Organizaciones

5. **TRIBU** (RRHH): necesita acciones de aprendizaje/clima (curso completado, módulo, kudos, encuesta interna) — distintas a RClub.
6. **CLUB** (RClub): acciones de endurance — `affiliate_purchase`, `event_*`, `referral_*`, y nuevas: `log_PR` (registrar marca), `join_relay_team` (Directorio), `connect_member`, `attend_clinic`.
7. **Recompensas por organización**, no compartidas. Cada comunidad su catálogo (`organization_id`). `is_global` solo para lo universal (signup, referido, evento).

### Canje

8. **Swag/físico:** lo gestiona operación RClub; capturar dirección al canjear + estado de envío. Idealmente lo surte el sponsor.
9. **`event_priority`:** se consume con **voucher/código QR** validado en el registro del evento.
10. **`race_entry`/`library`:** **cupón** (trackeable), no descuento automático. La biblioteca se desbloquea en la plataforma al instante.
11. **`max_per_user`:** Sí — agregar límite de canjes por usuario, sobre todo en recompensas de stock limitado o alto valor.

### Rally

12. **Puntos de rally** (50 etapa / 200 finalizado / 300 top3): razonable. Alinear con el Rally de Bienvenida ya documentado (`DC-REB-RClub-BienvenidaGamificado`, 8 misiones).
13. **Por organización** (cada comunidad corre su propio rally).

### Frontend

14. **Notificaciones:** sí, al ganar puntos y al subir de nivel.
15. **Multi-org:** el saldo es por (usuario, organización). Mostrar **saldo por comunidad con selector**, nunca un total mezclado. (La tarjeta también es por comunidad.)
16. **Beneficios por tier:** la fuente de verdad es el JSON de la BD; la UI debe leer de ahí (validar que coincidan).
17. **Tarjeta pública/privada:** toggle en configuración de la tarjeta. Mensaje al escanear QR privado: "Tarjeta privada — el titular no comparte su perfil."

---

## 4. Criterios para avanzar (qué está cerrado y qué necesito de ti)

**Cerrado (puedes construir sobre esto):**

- Ancla de valor: **1 pt = US$0.02**.
- Spread del modelo: **MDR 7% → 2% en puntos → 5% margen**.
- Catálogos de afiliación de la tarjeta (tipo, canal, grupos) — ratificados, ver `…-CatalogosAfiliacion-v01`.
- Esquema de tarjeta PAN 16 díg. — ratificado, ver `…-NumeracionTarjetas-v02`.

**Correcciones inmediatas en lo que ya tienes:**

1. `referral_signup` / `referral_complete`: quitar `once` → por-referido, tope 10/mes.
2. `social_share`: fijar `max_per_period = 3`.
3. `read_summary`: documentar `max_per_period = 50`.
4. Separar catálogos por `organization_id`: RClub ≠ MPB.

**Lo que respondemos en la próxima iteración (con el SPEC del Clearing House):**

- Modelo de datos del Clearing House (transacciones de comercio, liquidación, conciliación).
- Portal de comercio afiliado (registro de consumo por tarjeta/QR).
- Acción `affiliate_purchase` y su flujo de acreditación.

**Pregunta de vuelta para ti (Jesús):** ¿el motor Points v2 actual puede registrar transacciones con monto y comercio (no solo `action_key` fijo), o eso requiere extender el esquema? Tu respuesta define el esfuerzo del Clearing House.

---

> **Tripleta WORX** — Owner: Victor Heredia · Sherpa: Jay · Ratificador: Victor Heredia. Documento enviable a Jesús.