Repo Mesh

Standalone y Cloud

Repo Mesh funciona tanto en la build autoalojada standalone como en Cloud: los nodos worktree, la cola de tareas, Refinery y el modo mesh de MCP funcionan todos localmente sin necesidad de cuenta ni inicio de sesión en la nube. Entre máquinas, los daemons standalone que se alcanzan directamente (misma red o Tailscale) pueden emparejarse con un código, sin cuenta; coordinar daemons de la misma cuenta en redes distintas es la función de Cloud. Consulta Multi-máquina.

Un panel te muestra un agente a la vez. Repo Mesh pone tus daemons conectados bajo un solo plano de control: una sesión coordinadora entrega trabajo a agentes que se ejecutan en muchas máquinas — o en muchos worktrees de git aislados de la misma máquina — y converge los resultados. Divide el trabajo, deja que los nodos inactivos lo reclamen y aterriza las fusiones.

El panel de la nube presenta el mesh en la página Repo Mesh (/mesh). Standalone no tiene página de mesh en el panel — gestiónalo con comandos de la CLI adhdev mesh y el modo mesh del servidor MCP.

Cómo funciona

Repo Mesh se ejecuta sobre un DataChannel P2P directo de daemon a daemon (vía node-datachannel). El WebSocket del servidor de la nube solo retransmite la señalización de SDP offer/answer/ICE y autoriza que ambos daemons pertenezcan a la misma cuenta.

Esto es coordinación de daemons — no es un fallback de comandos del panel. El tráfico de comandos y datos del panel sigue usando solo el canal P2P panel↔daemon; Repo Mesh nunca lo reenruta a través del servidor.

El daemon coordinador es propietario del snapshot agregado mesh_status. Las sesiones worker son despachadas por el coordinador y auto-aprobadas por defecto. La finalización se basa en evidencia — estado/checkpoint de git y eventos del ledger, no el autoinforme de un agente. Las herramientas de Repo Mesh se exponen a las sesiones coordinadoras a través del servidor MCP en modo mesh — consulta Servidor MCP.

Conceptos centrales

• Nodo — un workspace que participa en el mesh: un checkout de repo o un worktree de git aislado donde puede ejecutarse un agente.
• Misión — un objetivo que agrupa las tareas que trabajan hacia él y permanece como un registro duradero. Creas una misión antes de encolar trabajo de varias tareas y la marcas como completed o abandoned una vez que se decide el resultado.
• Tarea — una unidad de trabajo que un agente en un nodo realiza, moviéndose a través de pending → assigned → completed/failed. Encadenar una tarea tras otra con depends_on es la forma predeterminada de construir un plan — el grafo crece de este modo, un enlace a la vez, en lugar de declararse todo de una vez.
• Cola — la lista local del daemon de tareas en espera que los nodos inactivos reclaman de forma autónoma. La cola es local-first y autoritativa; Cloud/D1 solo mantiene metadatos ligeros de membresía y señalización.
• Ledger — el registro de auditoría del mesh, de solo anexión, de lo que ya ha sucedido entre los nodos (historial, no una lista de tareas pendientes). Reconciliado entre daemons sobre porciones acotadas de ledger P2P.
• Refinery — el proceso que converge una rama de worktree de vuelta a su base: validar → merge → push → limpieza.

Orquestación: cola de tareas basada en pull

No empujas una tarea a una máquina específica y esperas. Encolas tareas contra una misión, y los nodos inactivos extraen trabajo de forma autónoma de la cola local-first. Eso significa que:

• Puedes distribuir trabajo entre máquinas y proveedores a la vez — Claude Code en un nodo, Codex en otro, Cursor CLI en un tercero.
• Los nodos lentos u ocupados simplemente no reclaman más trabajo; los nodos rápidos e inactivos vacían la cola.
• El coordinador vigila los eventos de finalización/fallo en lugar de sondear cada sesión.

Esto es lo que permite que una persona coordine muchos agentes a la vez: descompone el objetivo en tareas, deja que los nodos inactivos se autoasignen y revisa la convergencia.

Encadenar tareas

La mayor parte del trabajo de varios pasos se descubre de forma incremental, no se planifica de antemano — así que la forma predeterminada de construir un plan es encolar una tarea, y luego encolar la siguiente con depends_on apuntando a ella en cuanto sepas que hace falta. El grafo de dependencias crece de este modo, un enlace a la vez, en lugar de declararse todo de una vez. Una tarea que depende de otra recibe automáticamente un breve resumen de lo que informó su predecesora al completarse, de modo que los resultados fluyen hacia adelante sin que tengas que copiar nada a mano.

Cuando ya tienes varias tareas confirmadas, mesh_enqueue_batch las encola juntas en una sola llamada atómica — las mismas relaciones depends_on, enviadas a la vez. Es una comodidad, no un motor distinto.

Si falla o se cancela una tarea de la que dependen otras, las dependientes quedan bloqueadas (el panel las muestra como bloqueadas por una dependencia) y se notifica al coordinador. Una política del mesh (onDependencyFailure: cancel) puede, en cambio, cancelar toda la cadena posterior.

Colaboración centrada en el repo

Repo Mesh está construido en torno a el mismo repo, trabajado desde varios lugares a la vez:

• Aislamiento de worktree — cada nodo puede ser un worktree de git aislado, para que los agentes en paralelo en el mismo repo nunca pisen el árbol de trabajo del otro.
• Convergencia automática — la refinery toma una rama de worktree terminada y la converge de vuelta a su base: valida, fusiona, hace push y limpia.
• Clasificación de convergencia de rama — cada nodo/rama tocado aterriza en exactamente un estado final (fusionado a main, rama de característica pusheada que necesita merge, bloqueado en revisión, candidato a limpieza o no fusionable) para que nada quede silenciosamente en una rama perdida.
• Manejo seguro de submódulos — la convergencia tiene en cuenta la accesibilidad de los submódulos; una rama cuyos commits de submódulo aún no son accesibles desde el origin del submódulo se retiene para revisión en lugar de fusionarse a ciegas.

Limpieza de workers inactivos

Una sesión worker delegada que queda inactiva (sin trabajo activo, y que no es el coordinador) se detiene automáticamente después de 30 minutos por defecto — un ciclo de mantenimiento del mesh comprueba esto cada 5 minutos. Esto evita que los runtimes CLI inactivos se acumulen en los nodos; el TTL es un ajuste de política por mesh (delegatedSessionIdleTtlMinutes) si lo necesitas más corto, más largo o desactivado.

Verificación cruzada

Más allá de dividir tareas distintas, el coordinador puede enviar la misma pregunta de solo lectura a 2–3 workers de distintos proveedores con mesh_send_task, esperar sus informes y sintetizar las respuestas él mismo — acuerdo y divergencia juntos.

Ejecutar la misma pregunta a través de agentes independientes en máquinas independientes es más fiable que la opinión de un solo agente: el consenso hace emerger la respuesta y el desacuerdo hace emerger las partes que necesitan una mirada más cercana.

Próximos pasos

• Multimáquina →
• Servidor MCP →
• Panel →