Construímos um planeador GOAP numa tarde. Ele produz um plano limpo de nove passos para objetivos de engenharia em zero milissegundos. Não vamos deixá-lo perto de uma motion to dismiss. Eis o porquê — e as quatro barreiras que fecharíamos antes de o fazer.
O argumento e o veredito
Goal-oriented action planning (GOAP) é a arquitetura que os motores de xadrez usam: manter uma árvore de futuros, procurar o caminho mais barato de onde se está até onde se quer chegar, e podar o resto. É um encaixe muito melhor para litígio do que um modelo em estilo chat. Motions, discovery, julgamentos — tudo sequências de movimentos sob restrições. Modelos em estilo chat produzem a próxima frase plausível. Planeadores comprometem-se com um objetivo e trabalham de trás para a frente.
Factos-chave
- Um planeador GOAP A* funcional tem 517 linhas de JavaScript puro, sem dependências — portado numa tarde a partir do goal_ui do claude-flow da ruflo.
- O planeador GOAP do claude-flow da ruflo não implementa replaneamento adaptativo: plan() executa o A* exatamente uma vez, no momento da submissão do objetivo — verificado nos pontos de chamada em Index.tsx e ResearchReportModal.tsx (EXTERNAL-CITE: código-fonte do claude-flow da ruflo, lido diretamente).
- Apresentar uma 12(b)(6) de mérito antes de invocar a arbitragem pode implicar a renúncia ao direito de arbitrar, ao abrigo de Morgan v. Sundance (2022) — um planeador de caminho mais curto entra direto nessa armadilha.
Por isso, construímos um. 517 linhas de JavaScript puro, sem dependências, portado numa tarde a partir do planeador GOAP A* que vem embutido na app React `goal_ui` da ruflo. Corre sobre objetivos de engenharia como 'lançar o refactor de auth com testes e um PR' em zero milissegundos e produz um plano limpo de nove passos.
Não o vamos deixar tocar numa motion real. Ainda não. Este artigo é sobre o porquê, e sobre o que teria de mudar antes de o fazermos. Se vieram à procura de um elogio entusiasmado à próxima novidade de IA para advogados, o ponto deste artigo é o oposto: aqui está a fasquia de rigor que definimos antes de encaminharmos um objetivo de litígio através de qualquer planeador — o nosso, o da ruflo, o de quem quer que seja — e o fosso entre o planeador de hoje e essa fasquia.
O que o GOAP realmente é
O GOAP recebe três inputs: um estado-objetivo (factos que se querem verdadeiros — 'o PR está aberto', 'o CI está verde', 'implementado'), um estado inicial (o que é verdade agora) e uma biblioteca de ações (cada movimento possível, com pré-condições e efeitos — '`open_pr` requer `pushed=true` e `diff_reviewed=true`; define `pr_open=true`'). Depois executa uma pesquisa A* — o mesmo algoritmo que o GPS usa para contornar trânsito — sobre o espaço de sequências de ações, e devolve o caminho válido mais barato do estado inicial até ao objetivo. Se um passo falhar durante a execução, deve replanear a partir do novo estado.
Para advogados, a analogia mais próxima é o xadrez. Um grande mestre não pensa um movimento de cada vez; mantém uma árvore de futuros e vai podando à medida que o jogo avança. O GOAP é isso, tornado mecânico. Não é generativo; é pesquisa.
A arquitetura encaixa em litígio quase na perfeição. Uma motion to compel arbitration tem pré-condições rígidas (existe uma cláusula de arbitragem, a petição foi notificada, ainda não foi apresentada nenhuma motion de mérito) e efeitos rígidos (riscos de renúncia afastados, o tribunal tem de decidir sobre a arbitrabilidade). O discovery tem uma ordem estrita (writtens antes de depoimentos, class antes de mérito, meet-and-confer antes de motions to compel). O summary judgment tem um oráculo de aprovado/reprovado. A forma do trabalho é moldada para o GOAP.
O que construímos
Quatro ficheiros: `planner.js` (165 LOC, A* + min-heap binário), `actions.js` (134 LOC, doze ações de engenharia), `parse.js` (58 LOC, tabela de expressões que transforma inglês em estado-objetivo), `cli.js` (160 LOC, executor). Total: 517 LOC. Sem dependências npm. Legível em vinte minutos.
Corremo-lo contra o objetivo 'lançar o refactor de auth com testes e um PR':
goal predicates: {"pr_open":true,"ci_green":true,"deployed":true}
1. understand_code (cost 2) -> /zoom-out
2. write_tests (cost 3) -> /tdd
3. run_tests (cost 1) -> bash:test
4. review_diff (cost 1) -> /review
5. commit (cost 1) -> git:commit
6. push_branch (cost 1) -> git:push
7. open_pr (cost 1) -> /ship
8. wait_ci (cost 5) -> bash:ci-wait
9. merge_and_deploy (cost 2) -> /land-and-deploy
total cost: 17
expansions: 13 time: 0 ms found: trueNove passos, custo 17, treze expansões de nós, zero milissegundos. Cada passo mapeia para uma skill do gstack ou um comando de shell, por isso o plano é executável — não decorativo. Também testámos um objetivo mais pequeno ('testar o módulo de login' — 3 passos, custo 6) e um insatisfazível (um predicado que nenhuma ação define — devolveu `found: false` com o plano parcial mais próximo, em vez de rebentar ou entrar em loop). Os três comportamentos correspondem à especificação.
Isto levou uma tarde. Não é a parte difícil.
Porque portámos isto da ruflo
A ruflo (o ecossistema `claude-flow`) inclui um planeador GOAP dentro da sua app React `goal_ui` — `goapPlanner.ts`, ficheiro único, 180 linhas. A arquitetura é sólida. Extraímo-la.
Enquanto estávamos lá dentro, lemos o código-fonte com cuidado. Uma afirmação que não sobrevive ao contacto com ele: o planeador não implementa replaneamento adaptativo. O método `plan()` corre o A* exatamente uma vez, na submissão do objetivo, e devolve um `Step[]` que alimenta uma animação de interface. Não há loop de replaneamento, nem invalidação de plano, nem recuperação de falhas no ficheiro. Verificámos os pontos de chamada em `Index.tsx` e `ResearchReportModal.tsx`. A mesma história.
Não mencionamos isto para criticar a ruflo — o núcleo do planeador é bom código — mas porque importa para o resto deste artigo. O replaneamento adaptativo é a funcionalidade que mais se quereria ter antes de deixar um planeador chegar perto de um caso jurídico real, e a implementação open-source mais proeminente adjacente ao jurídico não a tem. Nós também não, ainda. Mais ninguém que tenhamos analisado também não.
Os três objetivos de litígio que não corremos
O plano original era correr três objetivos reais de litígio através do planeador e ter um litigante sénior a avaliar o resultado. Não o fizemos. Duas razões. Primeiro, encaminhar estratégia de litígio através de um URL público de terceiros — mesmo estratégia sintética sobre um cenário factual hipotético — tem implicações de privilégio que não quisemos navegar para um artigo de blog. Se não o faríamos por um cliente, não o devíamos fazer por nós próprios. Segundo, a nossa biblioteca de ações tem doze entradas e são todas ações de engenharia: `understand_code`, `write_tests`, `commit`, `push_branch`, `open_pr`, `wait_ci`, `merge_and_deploy`. Apontá-la a uma motion to dismiss produziria um plano que diria com confiança a um litigante para fazer `git commit` da sua resposta.
Mas os três casos de teste que escrevemos continuam a ser úteis — não como benchmarks que o planeador passou, mas como força motriz do que a próxima versão tem de conseguir tratar.
Caso 1 — Motion to dismiss com defesa de cláusula de arbitragem. Prompt: 'ganhar uma motion ao abrigo da Rule 12(b)(6) numa disputa contratual em que o autor alega breach mas o contrato tem uma cláusula de arbitragem clara.' A armadilha: a 12(b)(6) é o veículo errado. A arbitragem é imposta ao abrigo do FAA §§ 3-4, através de uma motion to compel. Apresentar uma 12(b)(6) de mérito antes de invocar a arbitragem pode implicar a renúncia ao direito de arbitrar, ao abrigo de Morgan v. Sundance (2022). Um planeador que redige a 12(b)(6) leva o cliente para território de malpractice.
Caso 2 — Estratégia de discovery para uma class action de salários e horas com 10 trabalhadores (CA). Prompt: 'construir um plano de discovery, priorizando pedidos de baixo custo e alta alavancagem.' Um associado júnior proporia depoimentos ao abrigo da 30(b)(6) de imediato. O plano correto coloca writtens antes de depoimentos, separa a certificação de classe do mérito, corre o aviso de opt-out Belaire-West antes de contactar qualquer membro putativo da classe, e intima o fornecedor terceiro de processamento salarial (dados mais limpos, mais rápido, sem custo de produção para a defesa). A sequência importa mais do que a substância.
Caso 3 — Summary judgment sobre uma cláusula de não-concorrência na Califórnia. Duas armadilhas. Armadilha um: o prompt cita 'Labor Code § 16600' — uma citação que não existe. A citação correta é Business & Professions Code § 16600. Armadilha dois: mesmo com a citação corrigida, o empregador quase de certeza perde. A SB 699 e a AB 1076 (em vigor desde 1 de janeiro de 2024) expandiram o § 16600 e acrescentaram um direito de ação privado com honorários de advogado. O movimento correto é aconselhar o cliente a abandonar totalmente a execução da não-concorrência e a mudar para uma teoria de segredo comercial ao abrigo da CUTSA, se os factos o suportarem. Um planeador que encontra o caminho A* mais curto para 'ganhar na não-concorrência' encontra um caminho para uma apresentação sancionável.
Estes três casos partilham uma característica estrutural: a saída mais valiosa não é um plano em direção ao objetivo declarado pelo utilizador. É 'o teu objetivo está errado; este é o objetivo certo.'
Isso não é o que o A faz. O A encontra o caminho mais curto. Vai encontrar caminhos mais curtos para estratégias perdedoras.
Experimente HAQQ AI grátis
Experimente a redação e pesquisa jurídica com IA
Quatro barreiras antes de confiarmos nisto com litígio
Eis o que teria de mudar. Nada disto é teórico — estes são os quatro itens no topo do plano v0.2.
1. A biblioteca de ações tem de ser redesenhada, de ponta a ponta. As ações de engenharia têm uma dimensão de custo (tempo de programador) e pré-condições limpas. As ações jurídicas têm pré-condições jurisdicionais (o FAA aplica-se, o tribunal está na Califórnia, a cláusula de arbitragem sobrevive ao § 16600), pré-condições estatutárias, pré-condições de calendário (o prazo da responsive pleading termina em 21 dias) e pré-condições adversariais (a contraparte ainda não apresentou X). A dimensão de custo também é diferente: custo monetário, horas de sócio, risco de sanções, exposição a fee-shifting. Uma biblioteca de ações jurídica séria tem provavelmente 200-500 ações com predicados parametrizados — uma ontologia real, escrita por litigantes, delimitada por área de prática.
2. O parser de objetivos tem de conseguir lidar com inglês jurídico real. O `parse.js` é uma tabela de expressões com cinco entradas. Mapeia 'lançar o refactor de auth' para `{pr_open, ci_green, deployed}` por correspondência de substring. Não consegue analisar 'ganhar uma motion ao abrigo da Rule 12(b)(6) numa disputa contratual em que o contrato tem uma cláusula de arbitragem clara.' A correção é pequena — Haiku em modo JSON, restringido por esquema aos predicados conhecidos. Cerca de meio dia. A mais pequena das quatro barreiras, e inútil sem as outras três.
3. O planeador tem de ser self-hosted. Nada relacionado com um caso real de cliente se aproxima de `goal.ruv.io` ou de qualquer URL de terceiros. Para além das questões de privilégio, não se pode auditar um planeador que não se controla. Self-hosted, em infraestrutura sob controlo do advogado, com registos que o advogado possui. Não negociável para a HAQQ.
4. O planeador tem de saber quando recusar o objetivo. A mais difícil. Um planeador A puro que encontra sempre o caminho mais curto vai executar estratégias perdedoras na perfeição. A correção não é apenas replaneamento adaptativo (voltar a correr o A quando uma ação falha). A correção é a crítica de objetivo: um passo de IA jurídica que corre antes do planeamento, verifica o objetivo face ao panorama doutrinário (§ 16600 + SB 699 + AB 1076 — 'esta ação de execução perde') e apresenta um objetivo alternativo ('mudar para CUTSA'). O replaneamento corrige falhas de execução. A crítica de objetivo corrige a falha mais profunda — o comprometimento total com um objetivo errado. Ambos são necessários; nenhum está implementado hoje.
O que isto ensina sobre IA no trabalho jurídico
A maioria dos produtos de IA otimiza para 'dá-me uma resposta confiante.' Essa é a forma errada para litígio, onde o trabalho é questionar a pergunta, identificar o que o cliente pensa que quer versus o que realmente precisa, e encontrar o movimento que o associado júnior teria falhado.
O GOAP está mais próximo dessa forma do que o chat. É estruturalmente honesto: diz quando não consegue chegar ao objetivo. Apresenta a sequência, não apenas a conclusão. Pode ser inspecionado, auditado, reproduzido.
Mas 'mais próximo do que o chat' não é 'suficientemente bom para trabalho jurídico.' A fasquia não é 'produz um plano.' A fasquia é 'produz um plano que um sócio assinaria com o próprio nome.' O GOAP de hoje, incluindo o nosso, está na primeira fasquia. A próxima versão tem de chegar à segunda. Não achamos que alguém que hoje vende um planeador — incluindo nós — deva ser confiado num caso real sem as quatro barreiras acima fechadas e demonstradas.
Para onde vamos a partir daqui
- Passo de crítica de objetivo (v0.2). Uma passagem em modo JSON do Haiku — 'examinar este objetivo face à doutrina; propor alternativa se estiver condenado' — antes de o planeador correr.
- Parser de objetivos de IA jurídica (v0.2). Substituir a tabela de expressões.
- Replaneamento adaptativo (v0.2). Envolver `plan()` num loop de execução que volta a pesquisar quando uma ação falha. Cerca de 50 linhas.
- Biblioteca de ações jurídica (v0.3). Delimitada por área de prática, escrita com revisão de litigantes, predicados parametrizados. Meses de trabalho, e o produto verdadeiro.
Quando estas quatro forem reais e testadas, vamos correr os três casos de litígio acima e publicar os resultados — incluindo as falhas, incluindo a crítica do litigante. Até lá, a única saída honesta é esta: um planeador de engenharia que funciona, um planeador jurídico que ainda não existe, e as notas de design de como o segundo tem de ser.
