Plan de implementación

Este plan describe el orden en que se construyó verificaOTP, fase por fase, desde la estructura visual más básica hasta el despliegue final. Sirve también como guía para quien necesite extender el proyecto más adelante: cada fase deja una base estable para la siguiente.

Fases

• 1. Shell: tokens, tipografías, encabezado con wordmark, pie y modo atenuado sin parpadeo.
• 2. Datos: tipos de serie, capítulo y bloque; contenido completo de las cinco series.
• 3. Biblioteca: tarjetas, filtros por tema, búsqueda insensible a tildes, anillos de progreso.
• 4. Capítulo y playground: renderizador de bloques, layout de tres columnas, scroll-spy, worker con SDK mx y watchdog.
• 5. Progreso y comentarios: autocompletado al 80%, celebración, sonido, notificación e hilos persistidos.
• 6. Grafo: mapa de prerrequisitos con resaltado de ancestros y navegación por teclado.
• 7. Docs: los seis documentos del proyecto.
• 8. Despliegue: metadatos por página, revisión de accesibilidad y publicación bajo verificaotp.cl.

Por qué este orden

El shell va primero porque cada pantalla posterior depende de los mismos tokens y del mismo encabezado; cambiarlos tarde habría significado retocar cada vista ya construida. Los datos van segundo porque sin contenido real es difícil validar si el layout de capítulo realmente soporta párrafos largos, listas con texto en negrita o un diff extenso.

El playground se dejó para la fase 4, después de que la biblioteca ya mostraba datos reales, porque es la pieza de mayor riesgo técnico del proyecto: aislar código arbitrario de un lector en un Web Worker con límites de tiempo y sin acceso a red necesitaba su propio ciclo de prueba y error antes de integrarse con el resto de la interfaz.

Riesgos identificados durante la construcción

El riesgo principal era que el watchdog del worker terminara interrumpiendo ejemplos legítimos con await encadenados, como varios OTP emitidos en secuencia. Se resolvió dejando el límite en 6 segundos, muy por encima de lo que tarda cualquier ejemplo real del curso, incluso con las esperas simuladas de entrega.

Un segundo riesgo fue la carga inicial del editor de código: CodeMirror es pesado, y cargarlo de inmediato en cada capítulo habría penalizado a lectores que ni siquiera llegan al primer playground. La carga perezosa activada por scroll resolvió ese costo sin sacrificar la experiencia de quien sí llega a esa sección.

Siguientes pasos posibles

Quedan fuera de este plan, pero son extensiones naturales: exportar o importar el progreso entre dispositivos mediante un archivo, agregar más playgrounds de caso compuesto, y un modo de impresión para capítulos individuales pensado para quien prefiere leer en papel.