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.
