RF67: Sistema genera recompensa
Descripción
El sistema genera una recompensa para el usuario cuando cumple una acción que la amerita (completar una recomendación financiera RF27, finalizar un curso RF57, alcanzar una meta), como mecánica de gamificación para incentivar buenos hábitos financieros.
La generación es disparada por eventos de otros módulos y aplica reglas anti-abuso (idempotencia, límites por periodo) para evitar recompensas duplicadas o fraudulentas.
| Campo | Valor |
|---|---|
| Módulo | Rewards Module |
| Actor | Sistema (disparado por eventos) |
| Endpoint | Interno: handler de eventos de recompensa |
| Precondiciones | Ocurre un evento elegible (recomendación completada, curso finalizado, meta lograda) |
| Prioridad | Baja (post-MVP) |
| Etapa | MBI 2 |
| Requisitos relacionados | RF27, RF57, RF68, RF69 |
Reglas de negocio
- RN-67.1 — Cada recompensa se genera a partir de un evento elegible según un catálogo de reglas (tipo de evento → recompensa).
- RN-67.2 — La generación es idempotente por (usuario, evento): un mismo evento no genera recompensas duplicadas.
- RN-67.3 — Se aplican límites anti-abuso (máximo por periodo, validación de que el evento realmente ocurrió en el backend).
- RN-67.4 — La recompensa nace en estado
available(disponible para canje, RF69) y con fecha de expiración si aplica. - RN-67.5 — Al generarse, se dispara la notificación (RF68).
Validaciones / consideraciones
| Aspecto | Regla |
|---|---|
| Elegibilidad | El evento se valida server-side (no por el cliente). |
| Idempotencia | Una recompensa por (usuario, evento). |
| Límites | Tope por periodo para prevenir abuso. |
Criterios de aceptación
Escenario 1: Generación de recompensa exitosa
Dado que completo una acción elegible (p. ej. finalizo un curso),
Cuando el sistema recibe el evento validado,
Entonces genera la recompensa en estado available,
Y dispara la notificación al usuario (RF68).
Escenario 2: Evento no elegible o no verificado
Dado que llega un evento que no cumple las reglas o no se verifica en el backend, Cuando el sistema lo procesa, Entonces no genera recompensa.
Escenario 3: Evento duplicado (idempotencia)
Dado que el mismo evento se procesa dos veces, Cuando el sistema lo recibe de nuevo, Entonces no genera una recompensa duplicada.
Escenario 4: Límite anti-abuso alcanzado (seguridad)
Dado que el usuario alcanzó el tope de recompensas del periodo, Cuando ocurre otro evento elegible, Entonces el sistema no genera más recompensas hasta el siguiente periodo.
Criterios no funcionales
- Generación asíncrona e idempotente.
- Auditoría de recompensas generadas; comunicación TLS 1.2+.