Construimos un planificador GOAP en una tarde. Produce un plan limpio de nueve pasos para objetivos de ingeniería en cero milisegundos. No vamos a dejarlo cerca de una moción de desestimación. Aquí está el porqué — y las cuatro puertas que cerraríamos antes de hacerlo.
La propuesta y el veredicto
La planificación de acciones orientada a objetivos (GOAP) es la arquitectura que usan los motores de ajedrez: mantener un árbol de futuros, buscar el camino más barato desde donde estás hasta donde quieres llegar, podar el resto. Encaja mucho mejor con la litigación que un modelo de tipo chat. Mociones, discovery, juicios — todo son secuencias de movimientos bajo restricciones. Los modelos de tipo chat producen la siguiente frase plausible. Los planificadores se comprometen con un objetivo y trabajan hacia atrás.
Datos clave
- Un planificador GOAP A* funcional tiene 517 líneas de JavaScript plano sin dependencias — portado en una tarde desde el goal_ui de claude-flow de ruflo.
- El planificador GOAP de claude-flow de ruflo no implementa replanificación adaptativa: plan() ejecuta A* exactamente una vez al enviar el objetivo — verificado en los puntos de llamada en Index.tsx y ResearchReportModal.tsx (CITA EXTERNA: código fuente de ruflo claude-flow, leído directamente).
- Presentar una moción 12(b)(6) sustantiva antes de invocar el arbitraje puede renunciar al derecho a arbitrar bajo Morgan v. Sundance (2022) — un planificador de camino más corto se mete de lleno en esa trampa.
Así que construimos uno. 517 líneas de JavaScript plano, cero dependencias, portado en una tarde desde el planificador GOAP A* que viene incluido en la aplicación React `goal_ui` de ruflo. Funciona sobre objetivos de ingeniería como 'lanzar la refactorización de autenticación con pruebas y un PR' en cero milisegundos y produce un plan limpio de nueve pasos.
No vamos a dejar que toque una moción real. Todavía no. Este artículo trata sobre el porqué, y sobre qué tendría que cambiar antes de que lo hiciéramos. Si viniste aquí buscando un elogio entusiasta de la próxima novedad de IA para abogados, el objetivo de este artículo es el contrario: aquí está el nivel de rigor que exigimos antes de enrutar un objetivo de litigación a través de cualquier planificador — el nuestro, el de ruflo, el de quien sea — y la brecha entre el planificador de hoy y ese nivel.
Qué es realmente GOAP
GOAP toma tres entradas: un estado objetivo (hechos que quieres que sean verdaderos — 'el PR está abierto', 'CI está en verde', 'desplegado'), un estado inicial (lo que es verdad ahora mismo) y una biblioteca de acciones (cada movimiento que puedes hacer, cada uno con precondiciones y efectos — '`open_pr` requiere `pushed=true` y `diff_reviewed=true`; establece `pr_open=true`'). Luego ejecuta una búsqueda A* — el mismo algoritmo que usa el GPS para trazar rutas evitando el tráfico — sobre el espacio de secuencias de acciones y devuelve el camino válido más barato desde el estado inicial hasta el objetivo. Si un paso falla durante la ejecución, se supone que debe replanificar desde el nuevo estado.
Para los abogados, la analogía más cercana es el ajedrez. Un gran maestro no piensa un movimiento a la vez; mantiene un árbol de futuros y poda a medida que avanza la partida. GOAP es eso, hecho mecánico. No es generativo; es búsqueda.
La arquitectura encaja con la litigación casi demasiado bien. Una moción para compeler arbitraje tiene precondiciones estrictas (existe una cláusula de arbitraje, se ha notificado una demanda, aún no se ha presentado ninguna moción de fondo) y efectos estrictos (se cierran los riesgos de renuncia, el tribunal debe pronunciarse sobre la arbitrabilidad). El discovery tiene un orden estricto (interrogatorios escritos antes de las deposiciones, certificación de clase antes del fondo, reunión y consulta antes de las mociones para compeler). El juicio sumario tiene un oráculo de aprobado/reprobado. La forma del trabajo tiene forma de GOAP.
Lo que construimos
Cuatro archivos: `planner.js` (165 líneas, A* + min-heap binario), `actions.js` (134 líneas, doce acciones de ingeniería), `parse.js` (58 líneas, tabla de frases que convierte inglés en un estado objetivo), `cli.js` (160 líneas, ejecutor). Total 517 líneas. Sin dependencias de npm. Legible en veinte minutos.
Lo ejecutamos contra el objetivo 'lanzar la refactorización de autenticación con pruebas y un 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: trueNueve pasos, coste 17, trece expansiones de nodos, cero milisegundos. Cada paso se corresponde con una skill de gstack o un comando de shell, así que el plan es ejecutable, no decorativo. También probamos un objetivo más pequeño ('probar el módulo de login' — 3 pasos, coste 6) y uno irrealizable (un predicado que ninguna acción establece — devolvió `found: false` con el plan parcial más cercano en lugar de fallar o entrar en bucle). Los tres comportamientos coinciden con la especificación.
Esto tomó una tarde. No es la parte difícil.
Por qué portamos esto desde ruflo
Ruflo (el ecosistema `claude-flow`) incluye un planificador GOAP dentro de su aplicación React `goal_ui` — `goapPlanner.ts`, un solo archivo, 180 líneas. La arquitectura es sólida. La extrajimos.
Mientras estábamos ahí, leímos el código fuente con cuidado. Una afirmación que no sobrevive al contacto con él: el planificador no implementa replanificación adaptativa. El método `plan()` ejecuta A* exactamente una vez al enviar el objetivo y devuelve un `Step[]` que impulsa una animación de interfaz. No hay bucle de replanificación, ni invalidación de plan, ni recuperación de fallos en el archivo. Verificamos los puntos de llamada en `Index.tsx` y `ResearchReportModal.tsx`. La misma historia.
Mencionamos esto no para criticar a ruflo — el núcleo del planificador es buen código — sino porque importa para el resto de este artículo. La replanificación adaptativa es la característica única que más querrías antes de dejar que un planificador se acerque a un asunto legal real, y la implementación de código abierto más destacada adyacente a lo legal no la tiene. Nosotros tampoco, todavía. Nadie más que hayamos revisado la tiene tampoco.
Los tres objetivos de litigación que no ejecutamos
El plan original era ejecutar tres objetivos de litigación reales a través del planificador y hacer que un litigante sénior evaluara la salida. No lo hicimos. Dos razones. Primero, enrutar la estrategia de litigación a través de una URL pública de terceros — incluso una estrategia sintética sobre un patrón de hechos hipotético — tiene implicaciones de privilegio que no queríamos navegar para una entrada de blog. Si no lo haríamos por un cliente, no deberíamos hacerlo por nosotros mismos. Segundo, nuestra biblioteca de acciones tiene doce entradas y todas son acciones de ingeniería: `understand_code`, `write_tests`, `commit`, `push_branch`, `open_pr`, `wait_ci`, `merge_and_deploy`. Apuntarlo a una moción de desestimación produciría un plan que le diría con confianza a un litigante que hiciera `git commit` de su contestación.
Pero los tres casos de prueba que escribimos siguen siendo útiles — no como benchmarks que el planificador superó, sino como un factor forzador de lo que la próxima versión tiene que manejar.
Caso 1 — Moción de desestimación con defensa de cláusula de arbitraje. Prompt: 'ganar una moción de la Regla 12(b)(6) en una disputa contractual donde el demandante alega incumplimiento pero el contrato tiene una cláusula de arbitraje clara'. La trampa: 12(b)(6) es el vehículo equivocado. El arbitraje se hace cumplir bajo la FAA §§ 3-4 con una moción para compeler. Presentar una 12(b)(6) sustantiva antes de invocar el arbitraje puede renunciar al derecho a arbitrar bajo Morgan v. Sundance (2022). Un planificador que redacta la 12(b)(6) mete al cliente en territorio de negligencia profesional.
Caso 2 — Estrategia de discovery para una demanda colectiva de salarios y horas con 10 empleados (CA). Prompt: 'construir un plan de discovery, priorizando solicitudes de bajo coste y alto apalancamiento'. Un asociado junior propondría deposiciones 30(b)(6) de inmediato. El plan correcto pone los interrogatorios escritos antes de las deposiciones, bifurca la certificación de clase del fondo, ejecuta el aviso de exclusión voluntaria Belaire-West antes de contactar a cualquier miembro putativo de la clase, y emite una citación al proveedor externo de nómina (datos más limpios, más rápido, sin coste de producción para la defensa). La secuencia importa más que la sustancia.
Caso 3 — Juicio sumario sobre una cláusula de no competencia en California. Dos trampas. Trampa uno: el prompt cita el 'Código Laboral § 16600' — una cita que no existe. La cita correcta es el Código de Negocios y Profesiones § 16600. Trampa dos: incluso con la cita corregida, el empleador casi con certeza pierde. SB 699 y AB 1076 (vigentes desde el 1 de enero de 2024) ampliaron el § 16600 y añadieron un derecho de acción privado con honorarios de abogados. La jugada correcta es aconsejar al cliente que abandone por completo la aplicación de la no competencia y gire hacia una teoría de secreto comercial bajo CUTSA, si los hechos lo respaldan. Un planificador que encuentra el camino A* más corto hacia 'ganar sobre la no competencia' encuentra un camino hacia una presentación sancionable.
Estos tres casos comparten un rasgo estructural: la salida más valiosa no es un plan hacia el objetivo declarado por el usuario. Es 'tu objetivo está equivocado; aquí está el objetivo correcto'.
Eso no es lo que hace A. A encuentra el camino más corto. Encontrará los caminos más cortos hacia estrategias perdedoras.
Prueba HAQQ AI gratis
Experimenta la redacción e investigación legal con IA
Cuatro puertas antes de confiarle esto a la litigación
Esto es lo que tendría que cambiar. Nada de esto es teórico — estos son los cuatro elementos en la parte superior del plan v0.2.
1. La biblioteca de acciones tiene que rediseñarse de principio a fin. Las acciones de ingeniería tienen una dimensión de coste (tiempo de desarrollador) y precondiciones limpias. Las acciones legales tienen precondiciones jurisdiccionales (se aplica la FAA, el tribunal está en CA, la cláusula de arbitraje sobrevive al § 16600), precondiciones estatutarias, precondiciones de calendario (el plazo de contestación vence en 21 días) y precondiciones adversariales (la parte contraria aún no ha presentado X). La dimensión de coste también es distinta: coste monetario, horas de socio, riesgo de sanciones, exposición a traslado de honorarios. Una biblioteca de acciones legales seria probablemente tiene entre 200 y 500 acciones con predicados parametrizados — una ontología real, escrita por litigantes, delimitada por área de práctica.
2. El analizador de objetivos tiene que manejar inglés legal real. `parse.js` es una tabla de frases de cinco entradas. Mapea 'lanzar la refactorización de autenticación' a `{pr_open, ci_green, deployed}` mediante coincidencia de subcadenas. No puede analizar 'ganar una moción de la Regla 12(b)(6) en una disputa contractual donde el contrato tiene una cláusula de arbitraje clara'. La solución es pequeña — Haiku en modo JSON, restringido por esquema a predicados conocidos. Aproximadamente medio día. La más pequeña de las cuatro puertas, y absurda sin las otras tres.
3. El planificador tiene que ser autoalojado. Nada de un asunto real de un cliente se acerca a `goal.ruv.io` ni a ninguna URL de terceros. Dejando de lado las preocupaciones de privilegio, no puedes auditar un planificador que no ejecutas tú. Autoalojado, en infraestructura bajo el control del abogado, con registros que el abogado posee. No negociable para HAQQ.
4. El planificador tiene que saber cuándo rechazar el objetivo. El más difícil. Un planificador A puro que siempre encuentra el camino más corto ejecutará estrategias perdedoras de forma impecable. La solución no es solo la replanificación adaptativa (volver a ejecutar A cuando una acción falla). La solución es la crítica del objetivo: un paso de IA legal que se ejecuta antes de planificar, comprueba el objetivo contra el panorama doctrinal (§ 16600 + SB 699 + AB 1076 — 'esta acción de cumplimiento pierde') y presenta un objetivo alternativo ('girar hacia CUTSA'). La replanificación corrige fallos de ejecución. La crítica del objetivo corrige el fallo más profundo — comprometerse por completo con un objetivo equivocado. Ambas son necesarias; ninguna está implementada hoy.
Lo que esto enseña sobre la IA en el trabajo legal
La mayoría de los productos de IA optimizan para 'dame una respuesta con confianza'. Esa es la forma equivocada para la litigación, donde el trabajo consiste en cuestionar la pregunta, identificar lo que el cliente cree que quiere frente a lo que realmente necesita, y encontrar el movimiento que el asociado junior habría pasado por alto.
GOAP está más cerca de esa forma que el chat. Es estructuralmente honesto: te dice cuándo no puede alcanzar el objetivo. Presenta la secuencia, no solo la conclusión. Puede inspeccionarse, auditarse, reproducirse.
Pero 'más cerca que el chat' no es 'suficientemente bueno para el trabajo legal'. El listón no es 'produce un plan'. El listón es 'produce un plan al que un socio firmaría con su nombre'. El GOAP de hoy, el nuestro incluido, está en el primer listón. La próxima versión tiene que llegar al segundo. No creemos que nadie que te venda hoy un planificador — el nuestro incluido — deba merecer confianza en un asunto en curso sin las cuatro puertas anteriores cerradas y demostradas.
Hacia dónde vamos desde aquí
- Paso de crítica del objetivo (v0.2). Un pase de Haiku en modo JSON que 'examina este objetivo contra la doctrina; propone una alternativa si está condenado' antes de que se ejecute el planificador.
- Analizador de objetivos de IA legal (v0.2). Reemplazar la tabla de frases.
- Replanificación adaptativa (v0.2). Envolver `plan()` en un bucle de ejecución que vuelve a buscar cuando una acción falla. Unas 50 líneas.
- Biblioteca de acciones legales (v0.3). Delimitada por área de práctica, escrita con revisión de litigantes, predicados parametrizados. Meses de trabajo, y el producto real.
Cuando esas cuatro cosas sean reales y estén probadas, ejecutaremos los tres casos de litigación anteriores y publicaremos los resultados — incluidos los fallos, incluida la crítica del litigante. Hasta entonces, la única salida honesta es esta: un planificador de ingeniería que funciona, un planificador legal que todavía no existe, y las notas de diseño de lo que el segundo tiene que parecer.
