Caso de estudio: cómo se construyó CrasterDoc

El problema

Un estudiante recibe un enunciado y una rúbrica, y entrega un documento. Muchas notas se pierden por algo que no tiene que ver con saber el tema: una sección que faltaba, una norma de citas distinta, un dato de portada sin completar. Y quien trabaja en equipo tiene el problema de siempre: cada persona da formato a su manera.

CrasterDoc nace de esa pregunta: ¿puede una herramienta leer lo que pidió el docente, armar el documento con ese orden y decir qué falta antes de entregar? Lo que sigue es cómo se resolvió, con las decisiones y los límites. Para la parte de uso, vea cómo funciona y las guías.

Arquitectura local-first

Los documentos viven en el navegador de quien los escribe. La base es SQLite compilada a WebAssembly (sql.js) y se persiste en IndexedDB; no hay una base de datos de documentos en un servidor. Es una decisión de privacidad y también de simplicidad: no hay cuentas que administrar para usar la herramienta, y un documento abre aunque no haya conexión.

• Next.js (App Router) con React y TypeScript. Las páginas públicas son de servidor y no cargan la capa del archivero; esa capa (base local, respaldo, Drive) se descarga solo donde se usa.
• Google Drive y el asistente de IA son opcionales y solo envían datos cuando la persona los usa.
• El costo de esta decisión es real: si alguien borra los datos del sitio, pierde sus documentos salvo que haya descargado una copia. Por eso el producto lo dice y ofrece «Descargar todo».

Del enunciado a una especificación verificable

Un extractor determinista, sin IA, lee el texto del enunciado (copiado de Moodle o de un PDF) y produce una especificación: requisitos con identificador estable, la rúbrica con su escala real (puntos, porcentajes o niveles cualitativos), las secciones exigidas en el orden y con los títulos del docente, los campos de portada, la norma de citas, el formato y la fecha de cierre.

Que sea determinista es una decisión de ingeniería: el mismo texto produce siempre la misma especificación, se puede probar con casos fijos y no depende de que un modelo acierte. Cada requisito se asocia al criterio de la rúbrica por similitud de palabras. Está diseñado para cualquier materia; los casos de prueba son sintéticos y anónimos.

Una sola función de ensamblado pone el cuerpo en el orden exigido. La vista previa, el PDF, el Word y el evaluador usan esa misma función, así que no pueden contradecirse.

Un auditor antes de exportar

Antes de descargar, un auditor cruza el documento con la especificación y devuelve hallazgos priorizados y una estimación honesta por criterio de la rúbrica. Lo que no se puede verificar (por ejemplo, la calidad de un video) queda como «no evaluable» y no suma.

• Lo que solo la persona sabe (código, grupo, enlace del video) nunca se inventa: queda como pendiente hasta que lo escriba.
• El asistente de IA recibe la especificación completa, sin recortar el enunciado.
• Las comprobaciones finas de un tema concreto (por ejemplo, lógica proposicional) son un módulo opcional que solo aporta evidencia y nunca sube una estimación por sí solo.

PDF con fuente Unicode embebida

El PDF se genera en el navegador con jsPDF. Las fuentes estándar de PDF no dibujan símbolos como ∧ ∨ ¬ → ni subíndices, y rompen con algunas tildes, así que el PDF académico embebe DejaVu Serif (licencia libre) en sus cuatro estilos. El Word se genera con la librería docx a partir del mismo modelo de documento.

Hay una prueba que abre el PDF ya generado con pdf.js y mide el texto real de cada página: tamaño mínimo de letra y márgenes. No se confía en la configuración, se mide el resultado.

Accesibilidad, instalación y uso sin conexión

• Enlace para saltar al contenido, foco visible, controles táctiles de al menos 44 px y contraste AA como criterios de la guía de calidad del proyecto.
• Pruebas con axe sobre la landing, el catálogo y el archivero, además de la revisión de Lighthouse.
• Aplicación instalable (PWA) con un service worker: las páginas van primero a la red y guardan copia; los archivos estáticos se sirven desde la caché; sin conexión se muestra la copia o una página sin conexión.

Cómo se mantiene la calidad

Cada cambio pasa por un CI que corre las comprobaciones de tipos, el lint, la compilación de producción, las pruebas unitarias, las pruebas de extremo a extremo con Playwright y una auditoría de Lighthouse con presupuestos mínimos para SEO, accesibilidad y buenas prácticas.

• Hay 11 plantillas con código y 6 normas de citas.
• Hay más de 700 pruebas automáticas, entre ellas casos de enunciados sintéticos de distintas materias.
• Las páginas públicas tienen pruebas de metadata, JSON-LD, canónicas y enlaces internos, y las respuestas llevan cabeceras de seguridad, incluida una política de contenido (CSP).

Límites y lo que sigue

• La vista previa, el PDF y el Word comparten estructura y tipografía, pero los saltos de línea pueden diferir un poco entre los tres formatos.
• Los documentos viven en un solo navegador; la sincronización entre equipos pasa por Drive o por copias descargadas.
• Las reglas de cada norma de citas se aplican en general; cuando una universidad tiene variantes, manda la guía de la universidad.

El código está en GitHub y el autor tiene su perfil profesional. Si algo de lo anterior no coincide con lo que usted ve, escriba: es información que sirve para mejorar el producto.