shakedal1/lecture-deck-remake

Reconstrucción de presentaciones de clase

Convierte una presentación de curso árida en una de la que un estudiante realmente aprenda. El resultado es una presentación hecha con el tipo de artefacto Slides (uno por idioma). Todo sobre el formato de diapositivas, archivos y publicación proviene de las instrucciones de ese tipo. Esta habilidad añade el diseño pedagógico, las reglas de animación y comandos, y la técnica RTL para hebreo por encima.

Lee references/patterns.md antes de escribir la primera diapositiva. Contiene marcado listo para copiar para cada patrón mencionado a continuación.

1. Lee toda la fuente primero

• PDF: Read con pages en fragmentos de máximo 20 hasta que se haya visto cada página. PPTX: usa la habilidad pptx para extraer texto e imágenes.
• Mientras lees, enumera: los temas en orden, cada comando o fragmento de código, cada definición, cada cuestionario o pregunta ya existente en la presentación, y cualquier diapositiva que repita la misma captura de pantalla con un solo cambio de viñeta. Esas diapositivas repetidas son lo primero que hay que fusionar.
• También enumera cada imagen que valga la pena conservar: fotos, objetos reales o modelos, capturas de herramientas, y figuras que muestren algo que un dibujo a mano no puede. Anota la página y la posición aproximada de cada una en la vista previa de Read, porque la recortarás más tarde (§6).
• Conserva todos los datos de la fuente: nombres, fechas, correos electrónicos, calificaciones, enlaces, parámetros de comandos. Nunca inventes números, citas o comportamientos de herramientas que no puedas derivar de la fuente o de la lógica del ejemplo en sí.

2. Planifica la enseñanza, luego construye

Indica el plan en una línea al usuario y comienza. No esperes aprobación.

• Un ejemplo principal. Toma el ejemplo propio de la fuente y asígnale una imagen física concreta (un FSM one-hot de 3 bits se convirtió en "un perseguidor de luces de 3 lámparas"). Reutilízalo en cada diapositiva: las propiedades se convierten en preguntas simples sobre él, los resultados se explican en sus términos.
• Una analogía por concepto, de la vida cotidiana, escrita en cursiva en la diapositiva junto a la definición formal (simulación vs formal = probar 1,000 llaves vs un cerrajero que demuestra el mecanismo; reset = "Nueva partida"; reloj = metrónomo; límite = la cafetería más cercana en una calle; depurar "Por qué" = un detective que retrocede en el tiempo).
• Cuestionarios cada 4-6 diapositivas: predecir antes de ejecutar, trazar a mano, "¿qué pasa si cambiamos X", verdadero/falso. La respuesta es un cuadro anclado que se construye al hacer clic; pon la respuesta también en las notas del orador.
• Conserva las imágenes de la fuente y dibuja el resto. El usuario quiere las imágenes relevantes de la fuente en la presentación. No las elimines en favor de dibujos. Para cada imagen de tu lista:
  • Si muestra lo mismo que mostraría tu dibujo (una tira de resolución, la ventana real de una herramienta, una comparación antes/después), usa la imagen en lugar del dibujo.
  • Si añade algo que un dibujo no puede (una foto real, un modelo 3D real, un conjunto de datos real), colócala junto a tu dibujo del ejemplo principal en la misma diapositiva, con un pie de foto de una línea que los vincule.
  • Si es puramente decorativa o repite otra imagen, déjala fuera y menciónala en el informe. Dibuja como SVG/divs (patterns.md) todo lo que la fuente solo dice con palabras: diagramas de estados, formas de onda, líneas de tiempo, rectas numéricas, construcciones paso a paso del ejemplo principal.
• Una idea por diapositiva, alrededor de 20-26 diapositivas. Usa el ritmo: diapositivas de declaración oscuras para la portada, cada apertura de sección y el resumen; diapositivas de contenido claras; un fondo de tono cálido para las diapositivas de cuestionario.
• Termina con una hoja de referencia: cada comando en orden con un glosario de 2-3 palabras, más un glosario de los términos clave.

3. La animación es obligatoria, no opcional

El usuario pidió más animación. Cada presentación debe:

• Poner data-transition en cada sección: fade para la mayoría, push al entrar en una nueva sección, magic entre dos diapositivas que muestran el mismo diagrama en dos estados.
• Dar a cada diapositiva de contenido al menos una secuencia de construcción: los elementos clave son hijos position:absolute con data-build-in="<efecto> <orden>" para que aparezcan uno a la vez en modo Presentación. Las construcciones solo funcionan en hijos anclados, por lo que las diapositivas que se revelan paso a paso se diseñan con left/top/width explícitos.
• Usa construcciones que enseñen. Revela un flujo un paso a la vez (rise 1, rise 2, …), dibuja una máquina de estados flecha por flecha (un SVG anclado por grupo de flechas), recorre una forma de onda ciclo por ciclo, revela la analogía después de la definición y muestra las respuestas del cuestionario al final.
• Usa magic move para animar un cambio: el mismo id en el elemento anclado coincidente de dos diapositivas consecutivas (una lámpara encendiéndose, un resaltado moviéndose al siguiente ciclo, un intervalo de límite estrechándose).
• Varía los efectos con propósito: rise para listas y pasos, pop para un resultado o una marca, left/right para cosas que llegan desde una dirección, fade para anotaciones, scale para la gran revelación. No uses más de unos 6 builds por diapositiva.

4. Los comandos deben resaltar en la diapositiva

El usuario pidió comandos más notorios. Cada comando, parámetro o línea Tcl o shell usa el chip de comando de patterns.md, y nada más en la presentación se parece a él:

• Su propio bloque (<p>), nunca en línea dentro de una oración. Los spans solo pueden llevar color, por lo que font-family en un span se elimina silenciosamente.
• Una fuente monoespaciada (JetBrains Mono) de 32-40 px, negrita. Fondo de chip oscuro, un color de acento brillante reservado solo para comandos, una barra de acento gruesa en el borde frontal y un glifo de indicación (% para Tcl, $ para shell).
• Junto a cada chip, una etiqueta corta que indique lo que hace ("compilar", "probar todo").
• En una diapositiva de paso, el chip de comando es lo más grande después del título, y se construye primero.
• Los listados de código (archivos completos) usan un estilo de tarjeta de código separado y más silencioso para que los comandos aún se destaquen.

5. Idiomas

Si el usuario solicita dos idiomas, haz dos presentaciones separadas del tipo, con los mismos ids de diapositiva y contenido. Construye primero el idioma fuente (o inglés), luego el otro. El hebreo necesita la técnica RTL de patterns.md: aísla cada bloque de texto hebreo con ⁧…⁩, envuelve el código en línea dentro de hebreo en ⁦…⁩, usa text-align:right y filas row-reverse, invierte el orden de las columnas de la tabla, usa ← en secuencias, y aísla cada línea separada por <br> individualmente. Mantén el código, los chips de comando, las formas de onda y los esquemas de GUI de izquierda a derecha. Rubik cubre hebreo y latín.

6. Construir y publicar

Sigue las instrucciones del tipo Slides para archivos y llamadas, con estas reglas aprendidas del uso:

• Escribe project/deck.json (order, sections, faces completos) y la portada, publica, luego escribe y publica aproximadamente 4 diapositivas por ronda.
• Una publicación con edits no puede llevar también files. Edita con la herramienta Edit, luego publica los archivos.
• Si una publicación falla con un error de red, reenvía los mismos archivos. Es seguro.
• Recortar imágenes fuente de un PDF (haz esto antes de escribir las diapositivas que las usan):
  • Copia el PDF en su propia carpeta nueva en el bloc de notas y escribe los recortes en una carpeta assets separada.
  • Obtén el tamaño de página con python -I -c "import pypdf,sys;print(pypdf.PdfReader(sys.argv[1]).pages[0].mediabox)" <pdf>. PyMuPDF y Pillow no están instalados aquí; pdftoppm (MiKTeX) sí lo está. Ignora su advertencia "requires Windows 10".
  • Recorta directamente desde la página: pdftoppm -f N -l N -r 250 -x X -y Y -W W -H H -png -singlefile <pdf> <assets>/<nombre>. Las coordenadas provienen de la vista previa de Read: escala = (250 / 72) × ancho de página en pt / ancho de vista previa en px. Una página de 720 pt con vista previa de 1000 px de ancho da ×2,5.
  • Read cada recorte una vez y corrige sus bordes antes de subir: es común una franja de la imagen vecina.
  • Divide una tira de paneles (por ejemplo, una imagen con 7 resoluciones) en un recorte por panel, para que los paneles se puedan construir uno por uno.
  • Sube todos los recortes en una sola llamada: publicación del artefacto con url, asset: true y file_paths (hasta 25). Usa cada /_blob/<id> devuelto textualmente en <img src>, con object-fit:contain y un ancho/alto que coincida con la relación de aspecto del recorte.
  • Desde un PPTX, toma las imágenes que extrae la habilidad pptx, luego súbelas de la misma manera.
• Presupuesta la altura: 824 px dentro de los márgenes. Bloque de título ≈130 px, fila de tabla ≈ 2,1 × tamaño de fuente por línea, los cuadros anclados deben terminar por encima de y 952. Acorta el texto antes de encogerlo y mantén el texto a 24 px o más.
• No renderices ni tomes capturas de pantalla para verificar a menos que el usuario lo pida.

7. Informe

Proporciona el enlace de cada presentación, qué cambió en comparación con la original (el ejemplo principal, las analogías, las ilustraciones, qué imágenes de la fuente se conservaron, dónde, y cuáles se dejarón fuera, los cuestionarios, las animaciones, el estilo de los comandos, qué diapositivas repetitivas se fusionaron) y qué no verificaste. Recuerda al usuario que las presentaciones son privadas hasta que se compartan.