Historial de documentos

Fecha: mayo de 2026. Para qué sirve: punto de partida del proyecto. Reúne la visión (capacitación interna de empleados y externa de clientes), la infraestructura existente del servidor de la empresa y sus restricciones, el stack elegido (Moodle 4.5 LTS, MariaDB, Traefik, Cloudflare), los plugins confirmados, el plan de seis fases, las integraciones (PowerBuilder, YouTube, Cloudflare), las consideraciones de seguridad y cumplimiento (CIS v8, LOPDP, MFA) y una lista de puntos abiertos.

Vigencia: histórico. Su arquitectura de RAG (servicio propio en Python con ChromaDB) fue descartada en favor de Dify.

Fecha: junio de 2026. Para qué sirve: explica por qué el RAG pasó de un servicio propio a Dify (mantenimiento sin desarrollo continuo, cambio de modelo por interfaz, ingesta automática de cursos nuevos) y define el principio de portabilidad de proveedor en tres capas: Moodle habla siempre con un único endpoint compatible con OpenAI; la fuente de verdad del RAG es texto con metadatos sin vectores (chunks.jsonl); y la conexión con los proveedores es compatible con OpenAI. Describe la arquitectura objetivo, los tres roles de modelo en Dify (LLM, embedding bge-m3, reranker), la decisión abierta de recuperación (base de conocimiento nativa o External Knowledge API), el plugin local_dify_sync y los riesgos (memoria del servidor, refragmentación).

Vigencia: referencia vigente para el diseño del RAG con Dify (v4 lo remite a sus secciones 2, 4 y 5). Ver Pipeline de contenido.

Fecha: junio de 2026. Para qué sirve: primer plan completo por fases: restricciones vinculantes, arquitectura de servicios, flujo de datos, los dos sistemas de IA (asistente para estudiantes y agente de gestión) y fases 0 a 7 (servidor y seguridad base, capacitación del desarrollador, Moodle en producción, respaldo externo y DRP, plugins de Recursos Humanos, contenido, IA, salida a producción).

Vigencia: reemplazado por v3 y v4.

Fecha: junio de 2026. Para qué sirve: responde a un documento de requisitos (temp/3.md) con una matriz de trazabilidad de requisitos, arquitectura final con inventario de componentes y presupuesto de memoria, correcciones técnicas respecto a v2, fases F0 a F7, pruebas de validación (spikes) para las incógnitas, el contrato de operación "sin TI", cronograma, riesgos y costos. Introduce las tres entregas: R1 plataforma operativa, R2 asistentes de IA y R3 catálogo completo, y el diseño de respaldo que asume que el servidor puede volver a ser comprometido.

Vigencia: reemplazado por v4. Siguen como detalle: el respaldo (sección 5, F2), los spikes (sección 6) y el presupuesto de memoria (sección 3.3).

Fecha: junio de 2026. Para qué sirve: responde a una segunda ronda de preguntas (temp/4.md) y convierte el plan en tareas pequeñas con definición de terminado, pruebas y KPI. Novedades: el servidor se decide al final y todo se construye primero en Docker; política de actualizaciones (automáticas solo de seguridad); auditoría de la configuración de Moodle; principio configuración como código y datos como respaldo; visibilidad del último respaldo; incorporación masiva de personal y autorregistro de clientes; Groq como proveedor del chat; reformulación del flujo de postulantes como proceso de reclutamiento; contratos de datos del contenido (inventario, chunks.jsonl, GIFT, checkpoints, código PowerBuilder); y el roadmap del repositorio hermano lms-course-scrap (apéndice A).

Vigencia: línea base de la planificación. La implementación avanzó más allá de varias tareas y difiere en algunos puntos (por ejemplo, el chat usa Groq directamente; Dify sigue pendiente).

Fecha: junio de 2026. Para qué sirve: revisión crítica de v4. Lista diez brechas (G-1 a G-10), entre ellas la compatibilidad con Moodle 4.5 de los plugins incluidos en la imagen (G-1), el tratamiento transfronterizo de datos al usar Groq frente a la LOPDP (G-2), la integración no probada de local_ai_manager con Dify (G-3), que la operación "sin TI" es una promesa de R2 y no de R1 (G-4) y la falta de contingencia en el cronograma de un solo desarrollador (G-5). Incluye una lista de verificación de cierre.

Vigencia: sus brechas se integraron en v4; se conserva como lista de verificación viva.

Fecha: octubre de 2026. Para qué sirve: manual para TI con qué se protege (base de datos y moodledata; el código se reconstruye desde el repositorio; las variables de entorno se guardan aparte), el plan de respaldo (respaldo diario a las 2:00 hora de Ecuador con 14 días de retención, copia externa de 90 días, aviso en Moodle y por correo si falla), cómo activarlo, cómo recuperar (incluido el correo SMTP) y el registro de pruebas. Objetivos: RPO 24 horas y RTO de unas 2 horas.

Vigencia: vigente. Pendientes que declara: destino de la copia externa, snapshot de Proxmox, guardar las variables de entorno en un gestor de contraseñas y sincronizar el reloj del servidor. Ver Operación.