UR Desafío Mate 2.0

Desafío Mate 2.0 será un sistema de aprendizaje adaptativo en Matemática. Cada estudiante avanzará durante el año sobre los Objetivos de Aprendizaje (OA) correspondientes a su eje y nivel académico, recibiendo cápsulas remediales cuando se detecten brechas de base y cápsulas del nivel inmediatamente superior solo cuando domine todos los OA del eje/nivel objetivo.

Al final de cada cápsula se ejecutará un Evaluador Personal con una cantidad variable de preguntas. Estas preguntas entregarán evidencias sobre el OA principal trabajado, OA descendidos y OA anteriormente dominados que requieran validación. La próxima cápsula se seleccionará únicamente después de procesar esas evidencias.

Contexto actual

WebClass ya dispone de OA organizados por asignatura, eje y nivel; cápsulas interactivas de Desafío Mate; preguntas utilizadas por el Evaluador Personal; y clasificación de preguntas por uno o más OA.

Incluido en el alcance

• Guardar la progresión curricular entre OA.
• Relacionar cápsulas con uno o más OA.
• Construir evaluaciones personales dinámicas y sin repeticiones recientes.
• Guardar evidencias históricas y estado actual del alumno frente a los OA.
• Calcular dominio, confianza, cobertura y prioridad.
• Seleccionar automáticamente el OA y la cápsula siguiente.
• Mostrar la experiencia de mundos/islas al alumno.
• Entregar paneles, informes, alertas y trazabilidad al profesor.

Fuera del alcance inicial

• Generación automática de nuevas preguntas mediante IA.
• Clasificación automática de dificultad, ya que actualmente solo se conoce el OA.
• Permitir al profesor construir manualmente la ruta individual.
• Avanzar más de un nivel sobre el nivel académico del alumno.

Objetivo pedagógico

Maximizar la cobertura y consolidación de los OA esperados para cada eje/nivel, sin impedir que el alumno reconstruya aprendizajes de niveles anteriores cuando sean prerrequisitos necesarios.

Objetivo de producto

Convertir los datos de respuestas en una ruta explicable, personalizada y actualizada continuamente.

Indicadores sugeridos

• OA: ya almacenados y relacionados con asignatura, eje y nivel.
• Cápsulas interactivas: ya existentes en una tabla de contenidos.
• Preguntas: ya existentes y utilizadas en la sección Evaluador Personal.
• Clasificación pregunta ↔ OA: una pregunta puede estar vinculada a múltiples OA.

La progresión se almacenará como un grafo dirigido en una tabla relacional. Se recomienda guardar una única dirección canónica para evitar contradicciones.

Reglas

• Los OA relacionados deben pertenecer a la misma asignatura.
• Para el motor de un mundo, se priorizan relaciones dentro del mismo eje.
• Se deben evitar ciclos de prerrequisitos mediante validación al cargar la progresión.
• La relación puede cruzar niveles.
• La prioridad resuelve alternativas; el peso queda preparado para una versión futura.

Una cápsula puede estar asociada a varios OA y un OA puede disponer de varias cápsulas. Se requiere una tabla muchos-a-muchos.

• Cada cápsula activa deberá tener exactamente un OA principal para su selección instruccional.
• Los OA secundarios describen contenidos utilizados, pero no reemplazan las evidencias generadas por las respuestas.
• Un OA puede ofrecer distintas cápsulas para rotación y para evitar repeticiones.
• Si no existe cápsula para un OA necesario, el sistema debe registrar una brecha de contenido y no seleccionar una cápsula arbitraria.

Una respuesta puede generar evidencia para varios OA. Para evitar inflar artificialmente la confianza, la contribución de una pregunta se repartirá entre sus OA asociados.

Más adelante, el equipo pedagógico podrá definir pesos distintos cuando una pregunta mida principalmente un OA y secundariamente otros.

El Evaluador Personal se ejecutará siempre al final de la cápsula. La cantidad de preguntas será variable y configurable por cápsula o por regla global.

Distribución inicial recomendada

• Valor predeterminado sugerido: 12 preguntas, con mínimo configurable de 10.
• La conversión de porcentajes a cantidades usará redondeo por resto mayor.
• Dentro de un mismo Evaluador no se repetirá una pregunta.
• Se mantendrá un porcentaje general de la evaluación y un desglose por OA.
• La configuración usada se guardará como “snapshot” para auditoría.

Evitar repetición

Excluir preguntas vistas por el alumno durante una ventana configurable. Propuesta inicial: 60 días o las últimas 50 preguntas, aplicando la condición más restrictiva. Si el banco es insuficiente, flexibilizar gradualmente y registrar el nivel de fallback utilizado.

Resultado observado por OA

Actualización del dominio

Si el OA no tiene historia previa, se utilizará el resultado observado como estimación inicial, pero con confianza baja.

Confianza

Estados derivados

• No evaluado: confianza = 0.
• Evidencia insuficiente: confianza < 50%.
• Dominado: dominio ≥ 80% y confianza ≥ 70%.
• Requiere validación: dominio ≥ 80% y confianza < 70%.
• Brecha confirmada: dominio < 80% y confianza ≥ 50%.

No se crearán filas para todos los cruces alumno × OA desde el primer día. Un OA sin registro se interpretará como no evaluado, dominio desconocido y confianza 0.

El “universo completo” se obtiene con todos los OA activos de Desafío Mate y un LEFT JOIN a usuario_oa_estado. Esto permite mostrar OA dominados, descendidos, por validar y no evaluados sin generar millones de registros vacíos.

• El descenso no será arbitrario: deberá seguir el grafo de prerrequisitos.
• El alumno conserva siempre su nivel objetivo, aunque trabaje una cápsula de nivel inferior.
• Después de una intervención remedial, el motor intentará retornar al OA pendiente del nivel objetivo.
• La habilitación del nivel superior se calcula por eje, no por toda la asignatura.
• Un estudiante puede estar avanzado en Números y remedial en Geometría.
• Los OA del nivel superior no podrán exceder un nivel sobre el nivel académico.
• La validación de OA del nivel objetivo continuará aunque se habilite el nivel superior.

Orden de decisión

1. Revisar OA activos del eje/nivel objetivo no dominados.
2. Priorizar brechas confirmadas sobre resultados de baja confianza.
3. En empate, priorizar OA basales/prerrequisitos de más OA.
4. Evitar trabajar repetidamente el mismo OA si existen otras brechas equivalentes.
5. Si el OA requiere un prerrequisito no dominado, descender por el grafo hasta el límite permitido.
6. Si todos los OA del eje/nivel objetivo están dominados, seleccionar un OA del nivel +1.
7. Buscar cápsulas activas cuyo OA principal sea el OA seleccionado, evitando repeticiones recientes.
8. Registrar la decisión y revelar la próxima isla.

Trazabilidad obligatoria

Cada eje se presentará como un mundo. Dentro del mundo se mostrará una progresión lineal visual, aunque el motor utilice un grafo curricular.

• La próxima isla no muestra OA, nivel ni tipo de cápsula.
• Se revela solo después de procesar el Evaluador Personal.
• Mostrar misión actual, progreso, estrellas, desafíos y tiempo.
• Distinguir estrellas del nivel, remediales y superiores.
• Permitir revisar la cápsula anterior sin modificar la decisión histórica de la ruta; una repetición puede actualizar estrellas, pero su efecto adaptativo deberá definirse.
• Animaciones: islas flotantes, agua, niebla, cascada, partículas y transición de revelación, respetando prefers-reduced-motion.

La experiencia del profesor será analítica, no gamificada. Debe responder rápidamente:

• ¿Qué OA del nivel están cubiertos y cuáles faltan?
• ¿Qué estudiantes requieren intervención hoy?
• ¿Qué brechas se repiten en el curso?
• ¿Quiénes están trabajando contenidos remediales?
• ¿Quiénes habilitaron el nivel superior en cada eje?
• ¿Qué tan confiables son las estimaciones?
• ¿Por qué el sistema asignó una cápsula determinada?

Filtros transversales

Periodo, curso, eje, nivel del OA, estado de dominio, tipo de cápsula, estudiante, OA, familia conceptual, nivel de confianza y rango de actividad.

Acciones

Abrir detalle, agrupar estudiantes por brecha, exportar listado, ver ruta individual, revisar evidencia, registrar intervención docente y descargar informe.

Las alertas deben ser configurables, tener estado (nueva, vista, en seguimiento, resuelta) y permitir registrar una nota de intervención.

19.1. Principios de experiencia

• La prioridad visual del alumno será siempre qué debe hacer ahora, no el algoritmo ni el listado completo de OA.
• El alumno no deberá ver por adelantado el OA, nivel o tipo exacto de la próxima cápsula.
• El profesor sí podrá ver código OA, nivel, eje, dominio, confianza, historial y motivo de asignación.
• El color nunca será el único medio para comunicar un estado; se combinará con texto, icono y forma.
• El diseño general respetará la identidad actual de WebClass, utilizando una capa más ilustrada y lúdica solo en la experiencia del alumno.

19.2. Arquitectura de información y flujos principales

19.3. Inventario de pantallas

Los códigos se utilizarán en Figma, historias de usuario, QA y documentación técnica. “MVP” indica que la pantalla o variante es necesaria para la primera versión funcional.

19.4. Composición de las pantallas clave

19.5. Estados y variantes obligatorias

19.6. Sistema visual y componentes

El diseñador deberá partir del sistema visual vigente de WebClass y documentar las extensiones específicas de Desafío Mate.

• Componentes compartidos: encabezados, navegación, botones, tarjetas, chips, alertas, filtros, tablas, paginación, modales, tooltips, toasts y estados vacíos.
• Componentes alumno: isla, nodo de misión, niebla, estrellas, racha, barra de progreso, tarjeta de misión, mascota y recompensas.
• Componentes profesor: KPI, leyenda dominio/confianza, heatmap, gráfico de cobertura, ranking OA, línea temporal y panel de alerta.
• Terminología visible: usar lenguaje pedagógico y comprensible. “Confianza” deberá incluir tooltip o ayuda contextual para el profesor.

19.7. Ilustraciones y movimiento

• Las islas, niebla, agua, cascadas, partículas, vegetación y mascota deberán exportarse como capas independientes cuando requieran movimiento.
• Preferir WebP/AVIF transparente para ilustraciones rasterizadas y SVG para iconos/elementos vectoriales.
• Entregar variantes 1× y 2×, área segura, punto de anclaje y nombre consistente del asset.
• La isla anterior, actual y futura deberán mantener una composición coherente, pero con jerarquía por escala, iluminación y nitidez.
• Movimiento flotante suave; evitar que la interfaz compita con la lectura o provoque mareo.
• La revelación de isla podrá durar aproximadamente 1,5–2,5 segundos, con opción de omitir y variante sin movimiento.
• Respetar prefers-reduced-motion y evitar animaciones infinitas intensas.

19.8. Responsive, accesibilidad y densidad

• Contraste mínimo WCAG AA.
• Foco visible y navegación por teclado.
• Texto alternativo para ilustraciones informativas; decoración marcada como tal.
• Gráficos con leyenda, tooltip y alternativa tabular.
• No depender únicamente de hover, especialmente en tablets.

19.9. Estructura esperada del archivo Figma

• Usar Auto Layout, componentes, variantes y variables de diseño.
• Cada pantalla deberá incluir variantes default, loading, vacío, error y sin permisos cuando corresponda.
• Anotar origen de datos, acción al hacer clic, reglas de visibilidad y comportamiento responsive.
• Los prototipos mínimos serán: flujo completo del alumno; drill-down profesor; creación/publicación de una relación de progresión.

19.10. Criterios de aceptación de diseño

1. Existe una pantalla o variante para todos los códigos marcados MVP.
2. El alumno solo ve anterior, actual y próxima misión oculta.
3. La próxima isla no revela información antes del cálculo adaptativo.
4. Las misiones normal, refuerzo y superior se distinguen sin estigmatizar.
5. El Evaluador contempla cantidad variable de preguntas.
6. Se diseñan estados de reanudación y conexión interrumpida.
7. El dashboard del profesor muestra filtros y jerarquía de información.
8. Dominio y confianza se diferencian y explican.
9. El heatmap dispone de alternativa que no depende solo del color.
10. La ficha del alumno explica la trayectoria y motivo de asignación.
11. Las pantallas de administración validan ciclos y asociaciones incompletas.
12. Todos los componentes están documentados con estados y variantes.
13. Se entregan vistas responsive definidas.
14. Se entrega inventario de assets ilustrados y animables.
15. El prototipo es navegable y permite demostrar los tres flujos principales.

1. La prioridad anual son los OA del eje y nivel académico del alumno.
2. El progreso superior se habilita por eje.
3. Solo se puede subir un nivel.
4. Solo se puede subir cuando todos los OA activos/evaluables del eje/nivel están dominados con confianza suficiente.
5. Se puede bajar hasta un máximo configurable de 2 o 3 niveles.
6. El descenso debe seguir relaciones de prerrequisito.
7. La próxima cápsula se decide después del Evaluador Personal.
8. La cantidad de preguntas del Evaluador es variable.
9. La selección inicial usa 60/20/20 y es parametrizable.
10. Se evitan preguntas y cápsulas repetidas recientemente.
11. Una pregunta puede aportar evidencia a varios OA.
12. El porcentaje general de la cápsula y los resultados por OA se conservan.
13. Una sola evidencia no reemplaza el dominio histórico.
14. La confianza disminuye con la antigüedad; el dominio no disminuye solo por paso del tiempo.
15. Toda asignación automática debe poder explicarse.

• Dado un alumno y un eje, el sistema puede listar todos los OA activos del nivel objetivo y su estado.
• Al finalizar una cápsula, se genera un Evaluador con la cantidad y distribución configuradas.
• El Evaluador excluye preguntas repetidas según la ventana definida o registra el fallback.
• Cada respuesta genera evidencia para todos sus OA relacionados con el peso correspondiente.
• El sistema actualiza dominio y confianza sin reemplazar abruptamente el histórico.
• El sistema registra el porcentaje general y el desglose por OA.
• La próxima cápsula no se asigna antes de procesar todas las respuestas.
• Ante una brecha confirmada de prerrequisito, puede seleccionar una cápsula de hasta el máximo remedial.
• No selecciona un OA superior si falta al menos un OA del eje/nivel objetivo por dominar.
• No selecciona OA de más de un nivel superior.
• La decisión queda auditada con motivo, datos y versión del algoritmo.
• El profesor puede abrir cada informe del MVP, filtrar y llegar al detalle del alumno/OA.
• La próxima isla del alumno permanece oculta hasta que exista una decisión válida.

• Rendimiento: la selección de la próxima cápsula debe finalizar en pocos segundos después del Evaluador.
• Escalabilidad: índices por usuario, OA, eje, fecha y estado; procesos de agregación asíncronos para reportes pesados.
• Idempotencia: procesar dos veces el mismo Evaluador no debe duplicar evidencias.
• Versionado: guardar versión de algoritmo y parámetros usados.
• Auditoría: cambios de progresión curricular y configuración deben registrar autor y fecha.
• Privacidad: acceso a datos de estudiantes según rol, curso y permisos WebClass.
• Accesibilidad: navegación por teclado, contraste suficiente y reducción de movimiento.
• Exportación: informes docentes en formatos definidos por producto, idealmente XLSX/PDF.
• Observabilidad: registrar errores de selección, falta de banco, ciclos curriculares y decisiones sin cápsula candidata.

Fase 1 · Base curricular y datos

Identificar tablas actuales, configurar OA de alcance, cargar progresión, relacionar cápsulas/OA y validar pregunta/OA.

Fase 2 · Evaluador y modelo de conocimiento

Generación dinámica, exclusión de repetidas, evidencias, dominio, confianza y pruebas con datos.

Fase 3 · Motor de ruta y experiencia alumno

Selección de OA/cápsula, trazabilidad, mundos, isla oculta y revelación.

Fase 4 · Profesor e informes MVP

R01–R08, R11, R12, alertas y exportaciones.

Decisiones todavía abiertas

1. Confirmar máximo de descenso: 2 o 3 niveles.
2. Validar umbrales de dominio/confianza y fórmula con datos reales.
3. Definir cantidad predeterminada y límites de preguntas por Evaluador.
4. Confirmar ventana de no repetición de preguntas y cápsulas.
5. Definir qué OA existentes estarán activos/evaluables en Desafío Mate 2.0.
6. Definir quién y mediante qué interfaz cargará la progresión curricular.
7. Definir cómo tratar repeticiones voluntarias de cápsulas anteriores.
8. Definir reglas finales de estrellas y recompensas.
9. Definir formatos y destinatarios del informe anual.
10. Confirmar si “Entrenador” y “cápsula” son equivalentes en la nomenclatura técnica actual.