Skip to content

English · Español

Fase 41 — Portal del learner: Entregando el currículo a muchos

Requiere: 40 — Hardening, postmortem, "qué sigue" Enseña: web-portal · argon2id · csrf · spaced-repetition · multi-tenancy Salta a cualquier capítulo desde el índice de referencia de fases.

Mapa del capítulo

🇪🇸 La fase 41 no añade conocimiento de IA: añade acceso. Un único proceso FastAPI sirve el currículo de 40 fases a varios estudiantes, con login (sin contraseña por defecto), vista de profesor / admin, registro de proceso por estudiante, y repetición espaciada de preguntas de examen falladas. La construcción real espera a las fases 33 (serving) y 37 (seguridad). Esto es el portal — no el tutor.

Dónde encaja esta fase en el currículo

  • Anclaje de spec: LYNX_CORTEX.md §3 (audiencia: cohortes futuras) + §4 / Fase 33 (FastAPI) + §4 / Fase 37 (seguridad / modelo de amenazas).
  • Anclaje de enmienda: LYNX_CORTEX_ADDENDUM.md §A14 — la Fase 41 es una fase post-currículo añadida tras el alcance original de 40 fases y se rige por A14 (redactado junto con este README).
  • Anclaje de tema: §A13 — la materia que el portal entrega es el currículo del tutor de gramática (20 verbos × 5 tiempos × 3 personas con traducciones al español pareadas). El portal en sí no tiene modelo.
  • Anclaje de método: §A12 — esta fase está pre-escrita: plan + teoría + enunciados de lab antes de abrir la fase; soluciones just-in-time.
  • Prerrequisitos: las Fases 33 y 37 deben cerrarse primero.
  • Plan: PHASE_41_PLAN.md en la raíz del repo.

Qué produce el portal

Un único comando — just portal — arranca un proceso FastAPI en localhost:8000 que hace lo siguiente:

  1. Autentica a los estudiantes mediante credenciales hasheadas con Argon2id respaldadas por el módulo src/minivault/. Nunca se establece ni transmite una contraseña por defecto; el admin emite un enlace de invitación de un solo uso, el learner lo canjea y establece su propia contraseña.
  2. Renderiza el currículo fase por fase desde docs/phase-NN-*/. La teoría y los enunciados de lab se leen en vivo desde el repo; la base de datos solo guarda el estado del learner, nunca el contenido del currículo.
  3. Captura el proceso mediante una tabla event_log: quién leyó qué, cuándo, contra qué SHA de artefacto. El profesor / admin puede inspeccionar la traza cronológica de cualquier learner.
  4. Quizzes y exámenes extraídos del banco de preguntas de cada fase (materia: tutor de gramática §A13). Las notas en formato libre se guardan al lado.
  5. Re-presenta los fallos a través de src/minireview/: las preguntas de examen falladas entran en el mazo de revisión del learner, programadas por SM-2, drenadas una a una hasta que se respondan correctamente.
  6. Administra mediante un rol de profesor / admin que puede: crear nuevos estudiantes, inspeccionar progreso, auditar notas y ver la salud del mazo de revisión por learner.

Además, commiteado al repo:

  • src/miniportal/BLUEPRINT.md — diseño de la app FastAPI, mapa de rutas, inventario de plantillas.
  • src/minivault/BLUEPRINT.md — configuración de Argon2id, manejo del pepper, API de verificación.
  • src/minireview/BLUEPRINT.md — diseño del scheduler SM-2 (y FSRS bajo feature flag).
  • docs/phase-41-learner-portal/theory/ — motivación + arquitectura.
  • docs/phase-41-learner-portal/lab/ — seis enunciados de lab (00 → 05).
  • infra/portal/Caddyfile.example — configuración recomendada del reverse proxy (citada; no incluida en just portal).
  • PHASE_41_REPORT.md — reflexión de fase al cierre.

Mapa de archivos hands-off

Ruta Propietario Estado
PHASE_41_PLAN.md Claude (pre-write) → Borja (revisiones) Pre-escrito
docs/phase-41-learner-portal/README.md Claude (pre-write) Pre-escrito (este archivo)
docs/phase-41-learner-portal/theory/00-motivation.md Claude (pre-write) Pre-escrito
docs/phase-41-learner-portal/theory/01-architecture.md Claude (pre-write) Pre-escrito
docs/phase-41-learner-portal/lab/0[0-5]-*.md Claude (pre-write de enunciados; sin soluciones) Pre-escrito por separado
docs/phase-41-learner-portal/solutions/*.md Claude (just-in-time, tras el intento de Borja) ⏳
src/miniportal/BLUEPRINT.md Claude (scaffold) → Borja (revisión) ⏳
src/minivault/BLUEPRINT.md Claude (scaffold) → Borja (revisión) ⏳
src/minireview/BLUEPRINT.md Claude (scaffold) → Borja (revisión) ⏳
src/miniportal/*.py, src/minivault/*.py, src/minireview/*.py Solo Borja (CLAUDE.md §0.2) ⏳
PHASE_41_REPORT.md Borja (al cierre de la fase) ⏳

Cadena de teoría (leer en orden)

  1. theory/00-motivation.md — por qué existe un portal; la separación currículo / mentorización; por qué pre-escribir no basta; la elección del primer login sin contraseña; el eje multi-estudiante / profesor-admin; ética del registro de proceso.
  2. theory/01-architecture.md — diagramas C4 de contexto + contenedores; stack FastAPI + Jinja2 + HTMX + SQLite + Argon2id; inventario de rutas; la secuencia canónica de "enviar respuesta de examen" con los middlewares de la Fase 37 aplicados.

Cadena de labs (hacer en orden, tras cerrar las Fases 33 + 37)

  1. lab/00-bring-up-and-first-student.md — bootstrap, creación del admin, primer estudiante.
  2. lab/01-passwordless-first-login.md — emisión, canje, revocación y expiración del token de invitación.
  3. lab/02-vault-and-sessions.md — curva temporal de Argon2id; ida y vuelta de cookie de sesión firmada; logout y rotación del pepper.
  4. lab/03-progress-and-events.md — consultas al log de proceso; construcción del dashboard de admin.
  5. lab/04-spaced-repetition.md — sembrar fallos de examen; avanzar el reloj; verificar el calendario SM-2; drenar el mazo.
  6. lab/05-security-replay.md — re-ejecutar las tres amenazas demo de la Fase 37 a través del portal.

Definición de Done (binaria, al estilo docs/DONE_ENOUGH.md)

Enunciada por completo en PHASE_41_PLAN.md (raíz del repo) §7. Nueve checks, todos binarios, todos automatizados:

  • just portal arranca en < 2 s; /health devuelve 200.
  • just portal-admin --create-admin <name> emite un enlace de invitación de un solo uso; el enlace canjeado establece la contraseña; el enlace queda revocado.
  • Un segundo estudiante creado por el admin puede iniciar sesión, ver la fase 01, enviar una nota, hacer el quiz, hacer el examen.
  • Una pregunta de examen fallada aparece en la cola de revisión del estudiante en el momento programado por SM-2.
  • La vista de progreso del admin muestra last-active, tasa de aprobado de exámenes y tamaño del mazo de revisión por estudiante.
  • experiments/41-security-replay/ confirma que las tres amenazas demo de la Fase 37 son detectadas.
  • pytest src/miniportal/ src/minivault/ src/minireview/ está en verde.
  • bandit -r src/miniportal src/minivault src/minireview reporta 0 hallazgos de severidad alta.
  • PHASE_41_REPORT.md está commiteado según LYNX_CORTEX.md §7.6.

Qué NO cubre esta fase

  • Ninguna técnica nueva de ML. La Fase 41 no tiene modelo ni entrenamiento.
  • No SPA. Anti-objetivo §10 de la spec. Solo HTMX + Jinja2.
  • Sin aislamiento multi-cohorte. Un archivo SQLite = una cohorte.
  • Sin SSO / OAuth. Solo credenciales locales.
  • Sin envío de email en v1. Enlaces de invitación impresos en el terminal del admin.
  • Sin auto-evaluación de notas en formato libre. Las notas se guardan, no se puntúan.
  • Sin refactors "de pulido" de fases anteriores. Si un contrato de la Fase 33 o 37 necesita cambiar para satisfacer al portal, regístralo como una revisión de la Fase 33/37 según la cláusula de flexibilidad de A12 — no lo parchees en silencio desde la Fase 41.

Qué hacer cuando termines

Escribe PHASE_41_REPORT.md según LYNX_CORTEX.md §7.6. Concretamente: resultados por lab, la curva temporal empírica de Argon2id, el dimensionado del mazo de revisión observado en el estudiante sembrado, y los pendientes (probablemente: envío de email, SSO, aislamiento de cohortes, migración a FSRS).

Siguiente: theory/00-motivation.md.

Lecturas recomendadas

Opcional — enriquece pero no es necesario para aprobar la fase.