Abbiamo costruito un planner GOAP in un pomeriggio. Produce un piano pulito in nove passaggi per obiettivi di ingegneria in zero millisecondi. Non lo lasciamo avvicinare a una motion to dismiss. Ecco perché - e i quattro gate che chiuderemmo prima di farlo.
La proposta e il verdetto
Il goal-oriented action planning (GOAP) è l'architettura usata dai motori scacchistici: mantenere un albero di futuri possibili, cercare il percorso più economico da dove sei a dove vuoi arrivare, potare il resto. È un adattamento molto migliore al contenzioso rispetto a un modello in stile chat. Motion, discovery, processi - tutte sequenze di mosse sotto vincoli. I modelli in stile chat producono la frase plausibile successiva. I planner si impegnano su un obiettivo e lavorano a ritroso.
Dati chiave
- Un planner GOAP A* funzionante è composto da 517 righe di JavaScript puro senza dipendenze — portato in un pomeriggio dal goal_ui di claude-flow di ruflo.
- Il planner GOAP di claude-flow di ruflo non implementa il replanning adattivo: plan() esegue A* esattamente una volta al momento dell'invio dell'obiettivo — verificato nei call site in Index.tsx e ResearchReportModal.tsx (EXTERNAL-CITE: codice sorgente claude-flow di ruflo, letto direttamente).
- Depositare una 12(b)(6) nel merito prima di invocare l'arbitrato può far decadere il diritto all'arbitrato ai sensi di Morgan v. Sundance (2022) — un planner a percorso più breve ci finisce dritto dentro.
Quindi ne abbiamo costruito uno. 517 righe di JavaScript puro, zero dipendenze, portato in un pomeriggio dal planner GOAP A* incluso nell'app React `goal_ui` di ruflo. Funziona su obiettivi di ingegneria come 'spedisci il refactor dell'auth con test e una PR' in zero millisecondi e produce un piano pulito in nove passaggi.
Non lo lasciamo toccare una motion reale. Non ancora. Questo articolo spiega perché, e cosa dovrebbe cambiare prima che lo facessimo. Se sei arrivato qui cercando l'ennesimo endorsement entusiasta per la prossima novità IA per avvocati, il punto di questo articolo è l'opposto: ecco la barra di rigore che fissiamo prima di instradare un obiettivo di contenzioso attraverso qualsiasi planner - il nostro, quello di ruflo, di chiunque - e il divario tra il planner di oggi e quella barra.
Cos'è davvero il GOAP
GOAP prende tre input: uno stato obiettivo (fatti che vuoi siano veri - 'PR aperta', 'CI verde', 'deployato'), uno stato iniziale (ciò che è vero adesso), e una libreria di azioni (ogni mossa che puoi fare, ciascuna con precondizioni ed effetti - '`open_pr` richiede `pushed=true` e `diff_reviewed=true`; imposta `pr_open=true`'). Poi esegue una ricerca A* - lo stesso algoritmo che il GPS usa per aggirare il traffico - sullo spazio delle sequenze di azioni e restituisce il percorso valido più economico dallo stato iniziale all'obiettivo. Se un passaggio fallisce durante l'esecuzione, dovrebbe rieseguire il planning dal nuovo stato.
Per gli avvocati, l'analogia più vicina è gli scacchi. Un grande maestro non pensa una mossa alla volta; mantiene un albero di futuri e lo pota man mano che la partita si sviluppa. GOAP è questo, reso meccanico. Non è generativo; è ricerca.
L'architettura si mappa sul contenzioso quasi troppo bene. Una motion to compel arbitration ha precondizioni rigide (esiste una clausola arbitrale, un complaint è stato notificato, non è ancora stata depositata alcuna motion nel merito) ed effetti rigidi (i rischi di waiver sono preclusi, il tribunale deve pronunciarsi sull'arbitrabilità). La discovery ha un ordine rigoroso (writtens prima delle deposizioni, class prima del merito, meet-and-confer prima delle motion to compel). Il summary judgment ha un oracolo pass/fail. La forma del lavoro è la forma del GOAP.
Cosa abbiamo costruito
Quattro file: `planner.js` (165 LOC, A* + min-heap binario), `actions.js` (134 LOC, dodici azioni di ingegneria), `parse.js` (58 LOC, tabella di frasi che trasforma l'inglese in uno stato obiettivo), `cli.js` (160 LOC, runner). Totale 517 LOC. Nessuna dipendenza npm. Leggibile in venti minuti.
Lo abbiamo eseguito sull'obiettivo 'spedisci il refactor dell'auth con test e una 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 passaggi, costo 17, tredici espansioni di nodi, zero millisecondi. Ogni passaggio si mappa su una skill gstack o un comando shell, quindi il piano è eseguibile - non decorativo. Abbiamo anche testato un obiettivo più piccolo ('testa il modulo di login' - 3 passaggi, costo 6) e uno insoddisfacibile (un predicato che nessuna azione imposta - ha restituito `found: false` con il piano parziale più vicino invece di andare in crash o in loop). Tutti e tre i comportamenti corrispondono alla specifica.
Questo ha richiesto un pomeriggio. Non è la parte difficile.
Perché lo abbiamo portato da ruflo
Ruflo (l'ecosistema `claude-flow`) include un planner GOAP nella sua app React `goal_ui` - `goapPlanner.ts`, file singolo, 180 righe. L'architettura è solida. L'abbiamo estratta.
Mentre eravamo lì dentro, abbiamo letto il codice sorgente con attenzione. Un'affermazione che non sopravvive al contatto con esso: il planner non implementa il replanning adattivo. Il metodo `plan()` esegue A* esattamente una volta al momento dell'invio dell'obiettivo e restituisce uno `Step[]` che guida un'animazione UI. Nel file non c'è alcun loop di replanning, nessuna invalidazione del piano, nessun recupero dai fallimenti. Abbiamo controllato i call site in `Index.tsx` e `ResearchReportModal.tsx`. Stessa storia.
Lo menzioniamo non per criticare ruflo - il nucleo del planner è codice valido - ma perché conta per il resto di questo articolo. Il replanning adattivo è la singola funzionalità che vorresti di più prima di lasciare che un planner si avvicini a una vera pratica legale, e l'implementazione open source più prominente adiacente al mondo legale non ce l'ha. Nemmeno noi, per ora. Né nessun altro tra quelli che abbiamo esaminato.
I tre obiettivi di contenzioso che non abbiamo eseguito
Il piano originale era eseguire tre obiettivi di contenzioso reali attraverso il planner e far valutare l'output da un litigator senior. Non lo abbiamo fatto. Due motivi. Primo, instradare una strategia di contenzioso attraverso un URL pubblico di terze parti - anche una strategia sintetica su un fact pattern ipotetico - ha implicazioni di privilege che non volevamo affrontare per un articolo di blog. Se non lo faremmo per un cliente, non dovremmo farlo per noi stessi. Secondo, la nostra libreria di azioni ha dodici voci e sono tutte azioni di ingegneria: `understand_code`, `write_tests`, `commit`, `push_branch`, `open_pr`, `wait_ci`, `merge_and_deploy`. Puntarla su una motion to dismiss produrrebbe un piano che dice con sicurezza a un litigator di fare `git commit` della propria risposta.
Ma i tre casi di test che abbiamo scritto restano comunque utili - non come benchmark superati dal planner, ma come forcing function per ciò che la prossima versione dovrà gestire.
Caso 1 - Motion to dismiss con difesa da clausola arbitrale. Prompt: 'vinci una Rule 12(b)(6) motion in una controversia contrattuale dove l'attore lamenta un breach ma il contratto ha una chiara clausola arbitrale.' Il tranello: la 12(b)(6) è lo strumento sbagliato. L'arbitrato si fa valere ai sensi del FAA §§ 3-4 con una motion to compel. Depositare una 12(b)(6) nel merito prima di invocare l'arbitrato può far decadere il diritto all'arbitrato ai sensi di Morgan v. Sundance (2022). Un planner che redige la 12(b)(6) porta il cliente in territorio di malpractice.
Caso 2 - Strategia di discovery per una class action wage-and-hour con 10 dipendenti (CA). Prompt: 'costruisci un piano di discovery, dando priorità alle richieste a basso costo e alto impatto.' Un associate junior proporrebbe subito deposizioni 30(b)(6). Il piano corretto mette i writtens prima delle deposizioni, separa la class-cert dal merito, esegue la notifica di opt-out Belaire-West prima di contattare qualsiasi membro putativo della class, e cita in giudizio il fornitore terzo di payroll (dati più puliti, più veloce, nessun costo di produzione a carico della difesa). La sequenza conta più della sostanza.
Caso 3 - Summary judgment su un patto di non concorrenza in California. Due trappole. Trappola uno: il prompt cita 'Labor Code § 16600' - una citazione che non esiste. La citazione corretta è Business & Professions Code § 16600. Trappola due: anche con la citazione corretta, il datore di lavoro perde quasi certamente. SB 699 e AB 1076 (in vigore dal 1° gennaio 2024) hanno ampliato la § 16600 e aggiunto un diritto di azione privato con rimborso delle spese legali. La mossa corretta è consigliare al cliente di abbandonare del tutto l'enforcement del patto di non concorrenza e virare su una teoria di trade secret ai sensi del CUTSA, se i fatti lo supportano. Un planner che trova il percorso A* più breve verso 'vinci sul patto di non concorrenza' trova un percorso verso un deposito sanzionabile.
Questi tre casi condividono una caratteristica strutturale: l'output più prezioso non è un piano verso l'obiettivo dichiarato dall'utente. È 'il tuo obiettivo è sbagliato; ecco quello giusto.'
Non è quello che fa A. A trova il percorso più breve. Troverà percorsi più brevi verso strategie perdenti.
Prova HAQQ AI gratis
Sperimenta la redazione e ricerca legale con IA
Quattro gate prima di fidarci di questo per il contenzioso
Ecco cosa dovrebbe cambiare. Niente di tutto questo è teorico - questi sono i quattro punti in cima al piano v0.2.
1. La libreria di azioni deve essere riprogettata da capo a fondo. Le azioni di ingegneria hanno una sola dimensione di costo (tempo dello sviluppatore) e precondizioni pulite. Le azioni legali hanno precondizioni giurisdizionali (si applica il FAA, il tribunale è in CA, la clausola arbitrale sopravvive alla § 16600), precondizioni statutarie, precondizioni di calendario (la scadenza per il responsive pleading è tra 21 giorni), e precondizioni avversariali (la controparte non ha ancora depositato una motion per X). Anche la dimensione di costo è diversa: costo monetario, ore del partner, rischio sanzionatorio, esposizione al fee-shifting. Una libreria di azioni legali seria è probabilmente composta da 200-500 azioni con predicati parametrizzati - una vera ontologia, scritta da litigator, scoped per area di pratica.
2. Il goal parser deve gestire un inglese legale reale. `parse.js` è una tabella di frasi con cinque voci. Mappa 'spedisci il refactor dell'auth' su `{pr_open, ci_green, deployed}` tramite substring match. Non può interpretare 'vinci una Rule 12(b)(6) motion in una controversia contrattuale dove il contratto ha una chiara clausola arbitrale.' La correzione è piccola - Haiku in modalità JSON, vincolato a uno schema sui predicati noti. Circa mezza giornata. Il più piccolo dei quattro gate, e inutile senza gli altri tre.
3. Il planner deve essere self-hosted. Niente che riguardi una vera pratica cliente si avvicina a `goal.ruv.io` o a qualsiasi URL di terze parti. A parte le preoccupazioni sul privilege, non puoi fare audit di un planner che non gestisci tu. Self-hosted, su infrastruttura sotto il controllo dell'avvocato, con log di proprietà dell'avvocato. Non negoziabile per HAQQ.
4. Il planner deve sapere quando rifiutare l'obiettivo. Il più difficile. Un planner A puro che trova sempre il percorso più breve eseguirà magnificamente strategie perdenti. La correzione non è solo il replanning adattivo (rieseguire A quando un'azione fallisce). La correzione è la goal critique: un passaggio di Legal AI che gira prima del planning, verifica l'obiettivo rispetto al panorama dottrinale (§ 16600 + SB 699 + AB 1076 - 'questa azione di enforcement perde'), e propone un obiettivo alternativo ('vira su CUTSA'). Il replanning corregge i fallimenti di esecuzione. La goal critique corregge il modo di fallimento più profondo - impegnarsi completamente su un obiettivo sbagliato. Entrambi sono necessari; nessuno dei due è implementato oggi.
Cosa insegna questo sull'IA nel lavoro legale
La maggior parte dei prodotti IA ottimizza per 'dammi una risposta sicura di sé.' È la forma sbagliata per il contenzioso, dove il compito è mettere in discussione la domanda, identificare cosa il cliente pensa di volere rispetto a ciò di cui ha effettivamente bisogno, e trovare la mossa che l'associate junior si sarebbe lasciato sfuggire.
GOAP è più vicino a quella forma rispetto alla chat. È strutturalmente onesto: ti dice quando non può raggiungere l'obiettivo. Espone la sequenza, non solo la conclusione. Può essere ispezionato, sottoposto ad audit, rieseguito.
Ma 'più vicino della chat' non è 'abbastanza buono per il lavoro legale.' La barra non è 'produce un piano.' La barra è 'produce un piano che un partner firmerebbe con il proprio nome.' Il GOAP di oggi, il nostro incluso, è alla prima barra. La prossima versione deve arrivare alla seconda. Non pensiamo che chiunque ti venda un planner oggi - il nostro incluso - debba essere considerato affidabile su una pratica reale senza che i quattro gate sopra siano chiusi e dimostrati.
Da qui in avanti
- Passaggio di goal critique (v0.2). Un passaggio Haiku in modalità JSON 'esamina questo obiettivo rispetto alla dottrina; proponi un'alternativa se è destinato a fallire' prima che il planner venga eseguito.
- Goal parser Legal AI (v0.2). Sostituire la tabella di frasi.
- Replanning adattivo (v0.2). Avvolgere `plan()` in un loop di esecuzione che ricerca di nuovo quando un'azione fallisce. Circa 50 righe.
- Libreria di azioni legali (v0.3). Scoped per area di pratica, scritta con revisione dei litigator, predicati parametrizzati. Mesi di lavoro, ed è il prodotto vero e proprio.
Quando questi quattro saranno reali e testati, eseguiremo i tre casi di contenzioso sopra descritti e pubblicheremo i risultati - inclusi i fallimenti, inclusa la critica dei litigator. Fino ad allora, l'unico output onesto è questo: un planner di ingegneria che funziona, un planner legale che non esiste ancora, e le note di design su come dovrà essere il secondo.
