Foremerge coordina agentes de código en paralelo para cazar conflictos que Git no ve

Dos agentes de código trabajando a la vez sobre el mismo repositorio, cada uno en su worktree, sin tocar los mismos ficheros. Los dos terminan, los dos parecen correctos, y al juntarlo uno ha deshecho el trabajo del otro. Foremerge es un protocolo de coordinación abierto construido encima de Git que intenta avisar de eso antes de que el código aterrice. Va por la 0.5.0 y sus responsables lo describen como un MVP local-first, anterior al 1.0.

La pieza que falta en Git no es de texto, es de intención. Git compara líneas y avisa cuando dos ramas editan el mismo fragmento, pero no ve nada si un agente mueve todas las llamadas a un StripePaymentService nuevo y otro añade soporte de PayPal al PaymentService viejo. No hay solapamiento, el merge pasa sin quejarse, y el trabajo de PayPal queda colgando de una clase que ya nadie invoca.

Foremerge ataca eso haciendo que cada agente anuncie qué va a tocar antes de tocarlo. No el código: el objetivo. Algo del estilo "voy a modificar la función sendEmail". Todos leen de la misma lista, que es una base SQLite dentro de la carpeta .git del proyecto, de modo que Claude Code, Codex y Cursor ven el mismo estado en la misma máquina. Cuando dos planes chocan, la herramienta nombra a los dos agentes, explica el motivo del choque y sugiere cómo repartir el trabajo. En ese momento ninguno de los dos worktrees tiene cambios, así que no hay que tirar nada.

El detector compara declaraciones de ámbito sobre el mismo símbolo: uno dice que va a reemplazar PaymentService, el otro que va a extenderlo. Con eso levanta un aviso de nivel alto y propone coordinarse sobre una abstracción estable. El matiz importa: la operación se declara, no se deduce del resumen, así que "consolidar los pagos en Stripe" y "reemplazar PaymentService por Stripe" acaban en el mismo veredicto.

Lo que no hace

No bloquea ficheros ni frena agentes. La advertencia es consultiva y la decisión sigue siendo del humano, con el argumento de que un agente caído no puede paralizar a toda la flota. Tampoco mete un modelo a juzgar conflictos: el detector es determinista, las mismas entradas dan la misma salida. Y la coordinación entre máquinas distintas queda fuera del alcance del proyecto.

El estado real es el que es. Están implementados el CLI, una API JSON, un servidor MCP, el almacén SQLite, el detector y un ciclo de vida con validación por puerta. Los esquemas públicos todavía pueden cambiar y no hay resultados de benchmark publicados.

Para probarlo hace falta un Git reciente y jq. El instalador sirve binarios precompilados para macOS y Linux, con verificación de checksum, en ~/.local/bin; desde Rust 1.85 se puede compilar con cargo y hay binarios de Windows en la página de releases. Desde la 0.4.0 el mismo binario responde también a fmg, y si ya existe algo con ese nombre en el PATH, el instalador no lo toca. El camino corto es pedirle a tu agente que lo monte:

Set up Foremerge in this repository so we can coordinate parallel agents.
1. Install it: curl -fsSL https://foremerge.com/install.sh | sh
2. Initialize: foremerge init
3. Wire this client and any others in use: foremerge setup all
4. Register the check I should be validated against, for example:
   foremerge checks set test -- cargo test --all-targets
5. Confirm: foremerge doctor --client all
Then read the Foremerge skill that step 3 installed for this client and follow it from now on: publish your intent with semantic scopes before editing, claim the scope, and check for conflicts before you start.

El paso 3 habilita un servidor MCP, así que el cliente pedirá confirmación antes de hacerlo.

Merece la pena seguirlo aunque sea un MVP, porque el problema que señala es real y va a crecer: cuantos más agentes lance un equipo sobre el mismo repositorio, más caro sale el merge silencioso que Git considera limpio. Lo que falta por ver es si un registro de intenciones se mantiene útil cuando hay veinte agentes en lugar de dos, y si el detector aguanta sin convertirse en ruido.