Um pai pediu ao nosso agente para transformar o relatório de feira de ciências de um estudante — um documento Word sobre um bebedouro termoelétrico — em uma apresentação para uma competição municipal de inovação. Uma tarefa real, com prazo real e um professor de verdade lendo o resultado.
A apresentação final saiu bem — limpa o bastante para a versão editável parecer tão polida quanto a renderizada. Mas chegar lá quebrou de quatro jeitos diferentes, e cada quebra foi o tipo de bug que você só encontra quando alguém realmente baixa o arquivo e abre num laptop de escola. Aqui está o que aconteceu e o que mudamos no sistema por causa disso.
Quebra 1: três slides voltaram vazios
A prévia estava perfeita. O HTML baixado, não — nove imagens renderizaram em branco.
A causa: a apresentação referenciava imagens por caminho relativo
(src="assets/chart.png"), que resolve direito dentro da prévia do
workspace mas não aponta para lugar nenhum quando o arquivo .html viaja sozinho até
uma pasta de downloads.
A correção que importa não é "incorpore as imagens" — é o invariante: antes de uma
apresentação ser chamada de entrega, grep -c 'src="assets/' tem que
retornar zero. Corrigir imagens uma a uma foi como a primeira tentativa deixou três
gráficos passarem. Toda regra desta história termina do mesmo jeito: feche o ciclo com uma verificação, não com os olhos.
Quebra 2: gráficos que só existem online
Bibliotecas de gráficos interativos renderizam num canvas ao vivo. No clone de DOM do modo de rolagem da nossa prévia, os pixels pintados somem; offline, o script da CDN nunca chega. Para uma apresentação que precisa ser projetada numa sala de aula, "funciona quando está online" não basta — então apresentações agora pré-renderizam gráficos em PNG e os incorporam como imagens. Gráficos interativos continuam sendo opção só quando o ambiente é conhecido e a interação é o objetivo.
Quebra 3: a exportação que não cabia
O usuário queria duas versões: um PPTX renderizado e polido e um editável que o estudante pudesse ajustar antes de apresentar. O pipeline de exportação editável acabou tendo um limite rígido de entrada — uma apresentação totalmente autocontida é grande demais — e também descartava imagens de caminho relativo e mesclava caixas de texto incorretamente. Então a apresentação editável foi reconstruída nativamente com python-pptx. Isso revelou mais três falhas do mundo real:
- A matemática de tamanho de fonte tem que vir do slide, não da tela. Um slide 16:9 tem 960×540pt enquanto o canvas de design tem 1920×1080px, então
pt = px × 0.5— a conversão intuitiva por 96dpi deixa cada run 50% maior e o texto quebrava em colisões por toda parte. - O layout tem que sobreviver a métricas de fonte diferentes. Pares "número grande + legenda pequena" alinhavam lindamente no navegador e se sobrepunham no WPS, cujas larguras de glifo diferem. Empilhá-los verticalmente é imune; lado a lado com deslocamentos fixos, não.
- A geometria precisa de um lint. Uma imagem de capa passou 200px da borda do slide — flagrada pelos olhos do pai, não pelo build. Todo shape agora recebe uma asserção de limites antes de salvar.
Quebra 4: a verificação que quebrou a entrega
O script de QA certa vez moveu o arquivo finalizado de lugar enquanto o validava — a
própria verificação destruiu a coisa sendo verificada. Duas lições mais silenciosas
também sobreviveram: edições de texto em lote precisam de tolerância por item mais um grep de sobra para resíduos, e números de gráficos só podem vir das
tabelas do documento de origem — nunca relidos de uma captura de tela pequena, onde
4.62 uma vez virou 5.89.
O que mudou no produto
Cada uma dessas virou regra escrita no conjunto de skills do agente — as mesmas skills que todo usuário recebe. O invariante de estado de entrega (zero referências externas, verificado por hash), os limites do pipeline de exportação, as regras de geometria e layout do python-pptx, o slide de teste antes do build em lote e o loop de QA que renderiza cada página antes de entregar. Também guardamos o relato bruto como uma skill do workspace, para que as lições de um projeto real se acumulem em vez de evaporar.
Esta é a parte de "IA faz slides" que ninguém demonstra: o arquivo ainda precisa sobreviver à viagem até um laptop de escola, uma instalação do WPS e um projetor. A lacuna entre "lindo na prévia" e "abre corretamente em todo lugar" é exatamente onde mora o ofício — e é por isso que rodamos tarefas reais pelo produto nós mesmos e anotamos cada quebra.
Experimente o mesmo pipeline em Document to Slides — prévia gratuita, pague só se quiser o arquivo limpo.