Como funciona

natural-language task ──▶ planner (LLM, 1 call) ──▶ JSON action plan
                                                        │
       trajectory cache ◀── cheap verification ◀── deterministic executor
             │
             └──▶ subsequent runs: zero LLM, ~1s, $0

A parte cara — descobrir as ações do navegador — acontece uma única vez e é transformada em dados verificáveis em cache.

• Planos são dados, não código — JSON validado por schema; sem scripts gerados, sem condicionais.
• Verificação barata — pós-condições de DOM/URL após cada ação. Uma verificação que falha invalida o plano em cache e dispara um replanejamento automático.
• Mapa do site — cada execução alimenta um grafo de páginas e transições; windup scan popula esse grafo direto do seu código-fonte antes da primeira execução, para que o planejador use os seletores reais do seu app em vez de adivinhar.
• Fragmentos — blocos de ações comprovados (ex.: login) que o planejador compõe via { "type": "use" } em vez de regerar.
• Zero conhecimento do site embutido — o motor conhece frameworks e a web, nunca o seu site. Todo conhecimento do site chega como entrada (cenários, config, manifesto) ou é descoberto em tempo de execução.

Por que Windup

Scripts escritos à mão são baratos de rodar, mas caros de manter. Agentes de IA por execução são fáceis de escrever, mas lentos e não determinísticos. O Windup pega a metade boa de cada um.

Para os mecanismos mais profundos — fronteiras entre módulos, formatos de dados, postura de custo e segurança — veja Arquitetura e especificação.