Un padre le pidió a nuestro agente que convirtiera el informe de feria de ciencias de un estudiante — un documento de Word sobre un dispensador de agua potable termoeléctrico — en una presentación para un concurso de innovación a nivel municipal. Una tarea real, con una fecha límite real y un profesor real leyendo el resultado.
La presentación terminada quedó bien — tan limpia que la versión editable se veía tan pulida como la elegante versión renderizada. Pero llegar hasta ahí se rompió de cuatro maneras distintas, y cada rotura era el tipo de bug que solo encuentras cuando alguien de verdad descarga el archivo y lo abre en un portátil de escuela. Esto es lo que pasó, y lo que cambiamos en el sistema por ello.
Rotura 1: tres diapositivas volvieron vacías
La vista previa se veía perfecta. El HTML descargado, no — nueve imágenes se
renderizaron en blanco. La causa: la presentación referenciaba imágenes por ruta
relativa (src="assets/chart.png"), que resuelve bien dentro de la vista
previa del workspace pero no apunta a ningún sitio cuando el archivo .html viaja
solo a una carpeta de descargas.
La corrección que importa no es "incrustar las imágenes" — es el invariante: antes
de llamar a una presentación un entregable, grep -c 'src="assets/' debe
devolver cero. Parchar imágenes de a una es como el primer intento de arreglo se
saltó tres gráficos. Todas las reglas de esta historia terminan igual: cierra el bucle con una comprobación, no con los ojos.
Rotura 2: gráficos que solo existen online
Las librerías de gráficos interactivos renderizan sobre un canvas en vivo. En el clon del DOM en modo scroll de nuestra vista previa, los píxeles pintados desaparecen; offline, el script del CDN nunca llega. Para una presentación que tiene que proyectarse en un aula, "funciona cuando hay internet" no es suficiente — así que las presentaciones ahora pre-renderizan los gráficos a PNG y los incrustan como imágenes. Los gráficos interactivos siguen siendo una opción solo cuando el entorno es conocido y la interacción es el objetivo.
Rotura 3: la exportación que no cabía
El usuario quería dos versiones: un PPTX renderizado y pulido, y uno editable que el estudiante pudiera retocar antes de presentar. El pipeline de exportación editable resultó tener un límite duro de entrada — una presentación totalmente autocontenida es demasiado grande — y además soltaba las imágenes de ruta relativa y fusionaba mal los cuadros de texto. Así que la presentación editable se reconstruyó de forma nativa con python-pptx. Eso sacó a la superficie tres fallos más del mundo real:
- Las matemáticas del tamaño de fuente tienen que venir de la diapositiva, no de la pantalla. Una diapositiva 16:9 es 960×540pt mientras que el lienzo de diseño es 1920×1080px,
así que
pt = px × 0.5— la intuitiva conversión a 96dpi sobredimensiona cada run un 50% y el texto se envolvía chocando por todas partes. - El layout tiene que sobrevivir a métricas de fuente distintas. Los pares "número grande + leyenda pequeña" se alineaban perfectamente en el navegador y se solapaban en WPS, cuyas anchuras de glifo difieren. Apilarlos verticalmente es inmune; lado a lado con desplazamientos fijos, no.
- La geometría necesita un lint. Una imagen de portada se pasaba 200px del borde de la diapositiva — detectado por los ojos del padre, no por el build. Ahora cada forma recibe una comprobación de límites antes de guardarse.
Rotura 4: la verificación que rompió el entregable
El script de QA una vez movió el archivo terminado de su sitio mientras lo
validaba — la propia comprobación destruyó lo que comprobaba. Dos lecciones más
silenciosas también sobrevivieron: las ediciones de texto en lote necesitan
tolerancia por elemento más un grep de restos para detectar residuos, y
los números de los gráficos solo pueden salir de las tablas del documento fuente —
nunca re-leídos de una captura pequeña, donde 4.62 una vez se convirtió en 5.89.
Qué cambió en el producto
Cada una de estas es ahora una regla escrita en el conjunto de skills del agente — las mismas skills que recibe cada usuario. El invariante de estado de entrega (cero referencias externas, verificado por hash), los límites del pipeline de exportación, las reglas de geometría y layout de python-pptx, builds de una-diapositiva-de-prueba-y-luego-en-lote, y el bucle de QA que renderiza cada página antes de entregarla. También guardamos el informe en bruto como una skill del workspace, para que las lecciones de un proyecto real se acumulen en vez de evaporarse.
Esta es la parte de "la IA hace diapositivas" que nadie demuestra: el archivo todavía tiene que sobrevivir al viaje a un portátil de escuela, una instalación de WPS y un proyector. La brecha entre "se ve genial en la vista previa" y "abre bien en todas partes" es exactamente donde vive el oficio — y es por eso que nosotros mismos pasamos tareas reales por el producto y anotamos cada rotura.
Prueba el mismo pipeline tú mismo en Document to Slides — vista previa gratis, pagas solo si quieres el archivo limpio.