Repo Mesh
Solo en la nube
Repo Mesh está disponible solo en la versión Cloud. Coordina varios daemons de la misma cuenta, algo que la configuración autoalojada de máquina única no proporciona.
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).
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 un lote y la marcas como
completedoabandoneduna 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. - 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, Gemini 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.
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.
Verificación cruzada (MAGI)
Más allá de dividir tareas distintas, Repo Mesh puede enviar la misma investigación de solo lectura a varias réplicas máquina × proveedor y sintetizar los resultados — acuerdo y divergencia juntos (MAGI).
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.