workspace-v1/orchestration/analisis/03-VALIDACION-PLAN-FIX-STUDENT-PORTAL-2026-01-10.md

VALIDACIÓN DE PLAN: FIX-STUDENT-PORTAL-001

Fecha: 2026-01-10 Documento: Fase 4 - Validación del Plan contra el Análisis Referencia:

• 01-ANALISIS-FIX-STUDENT-PORTAL-2026-01-10.md
• 02-PLAN-FIX-STUDENT-PORTAL-2026-01-10.md

---

1. CHECKLIST DE VALIDACIÓN

1.1 Cobertura de Requisitos

Requisito del Análisis	¿Cubierto en Plan?	Ciclo	Observaciones
Verificar ambiente	✅ SÍ	Ciclo 1	Incluye backend, frontend, BD
Recrear BD con seeds	✅ SÍ	Ciclo 2	drop-and-recreate-database.sh
Verificar relaciones classroom	✅ SÍ	Ciclo 3	Queries SQL específicas
Probar endpoints backend	✅ SÍ	Ciclo 4	curl con JWT
Validar UI muestra datos	✅ SÍ	Ciclo 5	Navegación manual
Validación final	✅ SÍ	Ciclo 6	Compilación + scripts

1.2 Cobertura de Objetos Afectados

Objeto (del Análisis)	¿Validado en Plan?	Método de Validación
user_stats	✅ SÍ	SELECT COUNT en Ciclo 2, Endpoint en Ciclo 4
achievements	✅ SÍ	SELECT COUNT en Ciclo 2, Endpoint en Ciclo 4
user_achievements	✅ SÍ	SELECT COUNT en Ciclo 2
modules	✅ SÍ	SELECT COUNT en Ciclo 2
exercises	✅ SÍ	SELECT COUNT en Ciclo 2, Endpoint en Ciclo 4
classroom_students	✅ SÍ	Query específica en Ciclo 3
socialAPI.ts	✅ SÍ	Verificación de VITE_USE_MOCK_DATA en Ciclo 1

1.3 Cobertura de Riesgos

Riesgo Identificado	¿Mitigado en Plan?	Estrategia
Seeds no ejecutados	✅ SÍ	Recreación completa de BD
Backend no corriendo	✅ SÍ	Verificación en Ciclo 1
Relaciones faltantes	✅ SÍ	Queries de verificación en Ciclo 3
Token JWT inválido	✅ SÍ	Obtención de token nuevo en Ciclo 4

---

2. ANÁLISIS DE DEPENDENCIAS (Resumen Ejecutivo)

2.1 Dependencias Críticas Identificadas

Base de Datos:

user_stats (TABLA CORE)
├── Depende de: profiles (FK)
├── Afecta a: user_ranks, ml_coins_transactions
├── Triggers: 4 (level, missions, comodines, streak)
└── Funciones: 5 (award_ml_coins, claim_achievement, etc.)

achievements (CATÁLOGO)
├── Depende de: profiles (FK)
├── Afecta a: user_achievements
└── Funciones: check_and_award_achievements()

exercises (CONTENIDO)
├── Depende de: modules (FK CRITICAL)
├── Afecta a: assignment_exercises
└── Campos JSONB: config, content, solution

Backend:

LeaderboardService
├── Depende de: UserStatsService, RanksService
└── Consulta: user_stats, profiles

AchievementsService
├── Depende de: UserStatsService, MlCoinsService
└── Consulta: achievements, user_achievements

ModulesService
├── Depende de: ExercisesService
└── Consulta: modules, exercises

Frontend:

LeaderboardPage
├── Hooks: useLeaderboards, useAuth, useUserGamification
├── Stores: leaderboardsStore
└── APIs: /leaderboard/global, /gamification/user/{id}

GamificationPage
├── Stores: ranksStore, economyStore, achievementsStore
└── APIs: /ranks/progress, /economy/balance, /achievements

ModuleDetailPage
├── Hooks: useModuleDetail
└── APIs: /modules/{id}, /modules/{id}/exercises

2.2 Puntos de Sincronización

Punto	Dependencia	Verificación en Plan
BD → Backend	user_stats poblado	Ciclo 2 + Ciclo 4
Backend → Frontend	Endpoints respondiendo	Ciclo 4 + Ciclo 5
Seeds → BD	Datos cargados	Ciclo 2
classroom_students	Relación usuario-aula	Ciclo 3

2.3 Impacto de Cambios

El plan NO modifica código. Solo verifica y recrea ambiente.

Cambios que SÍ ocurren:

• Recreación de BD (DROP + CREATE)
• Re-ejecución de seeds

Impacto esperado:

• Datos limpios y consistentes
• Todas las tablas con registros de seeds
• Relaciones FK válidas

---

3. VALIDACIÓN DE COMPLETITUD

3.1 ¿El plan cubre todos los problemas?

Problema Original	¿Solucionado?	Cómo
Leaderboard: usuarios genéricos	✅ SÍ	Seeds de user_stats + verificación endpoint
Achievements: sin datos	✅ SÍ	Seeds de achievements + user_achievements
ModuleDetail: error ejercicios	✅ SÍ	Seeds de modules/exercises + relaciones

3.2 ¿El plan considera todas las dependencias?

Dependencia	¿Considerada?	Observación
FK user_stats → profiles	✅ SÍ	Seeds en orden correcto
FK exercises → modules	✅ SÍ	Seeds ejecutan en orden
RLS policies	⚠️ PARCIAL	Verificar acceso con token
Triggers de BD	✅ SÍ	Ejecutan con seeds

3.3 ¿El plan tiene criterios de éxito claros?

Criterio	¿Definido?	¿Medible?
Leaderboard muestra 10+ usuarios	✅ SÍ	✅ SÍ (count)
Achievements retorna 20 items	✅ SÍ	✅ SÍ (count)
Exercises retorna 5+ items	✅ SÍ	✅ SÍ (count)
Sin errores de compilación	✅ SÍ	✅ SÍ (exit code)

---

4. GAPS IDENTIFICADOS

4.1 Gaps en Cobertura

Gap	Severidad	Mitigación Propuesta
No verifica todos los triggers	BAJA	Agregar test de trigger en Ciclo 3
No prueba arquitectura dual (manual/auto)	BAJA	Fuera de alcance actual
No verifica WebSocket	BAJA	No aplica a estas páginas

4.2 Gaps en Dependencias

Gap	Severidad	Mitigación Propuesta
Portal Admin no verificado	MEDIA	Agregar verificación opcional
Portal Teacher no verificado	MEDIA	Agregar verificación opcional
Integración con auth completa	BAJA	Cubierto por login en Ciclo 4

---

5. RECOMENDACIONES DE REFINAMIENTO

5.1 Agregar al Plan

1. Ciclo 2.5: Verificar triggers ejecutaron

   -- Verificar que trigger creó user_ranks para todos los user_stats
   SELECT COUNT(*) FROM gamification_system.user_ranks;
   -- Debe coincidir con COUNT de user_stats
   

2. Ciclo 3: Agregar verificación de assignments

   -- Verificar que hay assignments con ejercicios
   SELECT a.title, COUNT(ae.exercise_id) as exercises
   FROM educational_content.assignments a
   JOIN educational_content.assignment_exercises ae ON ae.assignment_id = a.id
   GROUP BY a.id, a.title;
   

3. Ciclo 4: Agregar prueba de endpoint user-rank

   curl -s -H "Authorization: Bearer $TOKEN" \
     http://localhost:3006/api/v1/gamification/leaderboards/user-rank
   

5.2 Criterios Adicionales

• user_ranks tiene mismo COUNT que user_stats
• Todos los classrooms tienen al menos 1 assignment
• Endpoint user-rank responde con datos del usuario

---

6. APROBACIÓN

6.1 Checklist Final

• Plan cubre todos los requisitos del análisis
• Plan considera dependencias críticas
• Plan tiene criterios de éxito medibles
• Gaps identificados son de baja severidad
• Recomendaciones de refinamiento documentadas

6.2 Decisión

✅ PLAN APROBADO CON REFINAMIENTOS

El plan es válido y cubre los requisitos. Se recomienda incorporar las mejoras propuestas en la Fase 6 (Refinamiento).

---

Validado por: Orquestador (Tech Lead) Fecha: 2026-01-10 Versión: 1.0 Estado: Aprobado para refinamiento