Kit del instructor

Navegación: Inicio · Currículo · Rúbrica · Programa · Checklist de laboratorio

Esta guía explica cómo llevar el programa a un aula real: cómo planificarlo según el calendario disponible, cómo preparar el entorno, cómo evaluar con criterios y no con respuestas, y cómo manejar con seguridad los laboratorios que trabajan con contratos vulnerables.

Cómo usar el programa

El material está diseñado para dos formatos. Ambos cubren los 19 módulos (00–18) y el proyecto final; cambia el ritmo, no el alcance.

• Semestre largo (24–26 semanas). Una sesión conceptual y una de laboratorio por semana. Es el formato de referencia del programa académico. Deja espacio para checkpoints, retroalimentación y una defensa amplia del capstone.
• Intensivo (8 semanas). Dos o tres módulos por semana, laboratorios seleccionados y capstone reducido en alcance. Prioriza fundamentos (00–06), seguridad (09) y un proyecto acotado; convierte los módulos avanzados (12–18) en lecturas guiadas.

En cualquier formato mantén el ciclo pedagógico: comprender, experimentar, explicar, construir y verificar. El detalle didáctico está en diseño pedagógico y planes de clase.

Preparación previa

Antes de la primera sesión:

1. Ejecuta pnpm check y pnpm test para confirmar que el repositorio está sano.
2. Fija las versiones del semestre (Node, pnpm, Foundry, Docker) y comunícalas por escrito.
3. Prepara Anvil y Bitcoin Core en regtest sin acceso a redes con fondos reales.
4. Aplica el diagnóstico (pnpm course:diagnostic) y asigna una ruta con rutas de aprendizaje.
5. Define un canal privado para reportes de seguridad y explica la política de divulgación de SECURITY.md.

Estructura de cada clase

1. Enuncia un objetivo observable y verificable.
2. Demuestra un caso correcto y un contraejemplo.
3. Pide al estudiante predecir el resultado antes de ejecutar.
4. Exige bitácora razonada, no solo capturas.
5. Cierra con un riesgo identificado y una decisión justificada.

Laboratorios peligrosos

Los módulos de seguridad usan contratos deliberadamente vulnerables. Trátalos como material de laboratorio controlado:

• Solo en red local (Anvil) o testnet; nunca en mainnet ni contra sistemas de terceros.
• Wallets exclusivas sin fondos reales; jamás claves o seeds de valor.
• Los exploits se escriben y ejecutan como pruebas (forge test), no como despliegues.
• Refuerza la regla ética en cada sesión.

El checklist de laboratorio formaliza estas verificaciones antes, durante y después de cada práctica.

Evaluación

La rúbrica maestra vive en docs/evaluacion.md; úsala como fuente única de criterios. Complementa con:

• Checkpoints para cortes formativos.
• Banco de preguntas para exámenes y quizzes.
• Plantilla de informe de auditoría para el módulo de seguridad.

Uso de solutions/

La carpeta ../solutions/ contiene criterios de revisión, no respuestas para entregar. Úsala para calibrar tu corrección y para señalar al estudiante en qué se distingue un buen trabajo de uno pobre. Copiar de allí no acredita aprendizaje; la guía conceptual lo explica por tipo de entrega.

Cómo dar retroalimentación

Primero corrige el modelo mental, después la implementación. Un resultado correcto con una explicación falsa debe repetirse. En seguridad, separa siempre cinco planos: causa raíz, exploit, impacto, mitigación y riesgo residual.

Módulos, tiempo de clase y entregable

Enlaces útiles

• Programa de 24 semanas
• Checklist de laboratorio
• Rúbrica general
• Bibliografía
• Especificación del capstone