Cómo funciona
Cómo funciona RADAR.
Una visión técnica para desarrolladores. RADAR ejecuta agentes de programación y solo cierra una tarea después de volver a ejecutar por sí mismo la prueba de aceptación de la tarea. El «terminado» de un agente es una declaración; la nueva ejecución es la evidencia.
01 El bucle
Un mismo bucle para cada tarea.
Cada tarea recorre el mismo bucle, y cada paso solo se ejecuta si el anterior ha pasado.
- 01 · abrir Tarea y prueba de aceptación Escrita antes de empezar el trabajo
- 02 · asignar Un solo responsable, su propio worktree Lease y fence token
- 03 · trabajar El agente trabaja En su propia copia del proyecto
- 04 · declarar El agente dice que ha terminado Anotado como declaración, no como resultado
- 05 · verificar RADAR vuelve a ejecutar la prueba Sobre la revisión actual
- si pasa Cerrada La evidencia se guarda en el registro
- si falla · intento n de 3 Reabierta, con el fallo adjunto El mismo agente lo intenta de nuevo desde el paso 03
- tras 3 intentos Otro agente toma el relevo Hasta 3 intentos más, desde el paso 03
- tras 3 más La tarea te espera El registro rechaza más intentos
- Abrir
- Una tarea se abre con su objetivo y un comando de aceptación que se puede volver a ejecutar. El comando se comprueba al abrir la tarea, sin ejecutarlo: un criterio que no puede ejecutarse tal como está escrito se rechaza en ese momento, en lugar de descubrirse al final.
- Asignar
- Cada tarea tiene un solo responsable a la vez, mediante un lease y un fence token. Se rechaza cualquier escritura de un responsable caducado.
- Trabajar
- El agente trabaja en su propio git worktree, en su propia rama.
- Declarar
- El aviso del agente de que ha terminado se anota como una declaración. Una declaración no cierra la tarea.
- Verificar
- RADAR ejecuta él mismo el comando de aceptación, sobre la revisión actual del trabajo. El informe del propio agente se lee, pero no es evidencia.
- Cerrar o reabrir
- Si pasa, la tarea puede cerrarse y el registro de verificación se guarda como su evidencia. Si falla, la tarea se reabre con el fallo adjunto.
- Límites
- Tres intentos del worker y, después, tres relevos por otro agente. A partir de ahí, el registro rechaza más intentos y la tarea te espera. Cambiar de modelo, de sesión o de máquina no reinicia el recuento, y cada reintento tiene que indicar qué ha cambiado.
02 El registro
Un único registro en el que escriben todos los agentes.
Todos los agentes leen y escriben en el mismo registro de tareas: un archivo SQLite local. Es la única constancia de quién tiene cada tarea, qué se declaró y qué mostró la prueba.
- Tareas
- El objetivo y el comando de aceptación, escritos antes de empezar el trabajo.
- Responsable
- El responsable actual de cada tarea, con su lease y su fence token.
- Intentos
- Se cuentan por tarea, entre agentes, modelos y máquinas.
- Declaraciones
- El aviso de un agente de que el trabajo está hecho, guardado aparte de los resultados.
- Registros de verificación
- Cada ejecución de aceptación, vinculada al commit y al árbol de trabajo sobre los que se ejecutó.
- Cambios
- Un cambio en el comando de aceptación se anota con la versión antigua y la nueva; una anulación manual también queda anotada.
Memoria
Las decisiones y las lecciones son notas en Markdown con una fuente y un ámbito. Un índice local las busca sin conexión, y un hook pone las pertinentes delante de un agente antes de que actúe. Como las notas son Markdown sin más, puedes abrirlas en Obsidian.
03 Aislamiento
Cada intento, en su propia copia.
- Cada intento trabaja en su propio git worktree, en su propia rama. Dos workers nunca comparten un árbol.
- Un worker no puede reescribir su propio comando de aceptación. Solo el gestor puede cambiarlo, y solo antes de que la tarea se cierre; cada cambio conserva la versión antigua y la nueva.
- El trabajo solo llega a tu rama principal después de pasar la verificación, y el comando de aceptación se ejecuta una vez más tras el merge.
- Los force-push se rechazan para todos los roles.
- Estas reglas se ejecutan como código, antes y después de llamar a un modelo. No son un prompt, así que un agente no puede saltárselas con argumentos.
04 Agentes
Los agentes que ya usas.
RADAR ejecuta Claude Code, Codex CLI, OMP y Hermes Agent, en tu ordenador o en tus propios servidores Linux. No los sustituye: siguen haciendo el trabajo.
- Claude Code
- Codex CLI
- OMP
- Hermes Agent
- Un solo contrato
- Las mismas reglas, el mismo registro, el mismo control de verificación y los mismos límites de intentos se aplican a los cuatro.
- Gestor
- El agente con el que hablas es el gestor: abre tareas, las entrega a los workers y solo cierra una tarea con un registro de verificación superado.
- Workers
- Los workers hacen el trabajo en sus propios worktrees. No pueden cerrar tareas ni cambiar su comando de aceptación.
05 Local ante todo
Local ante todo.
RADAR no necesita cuenta ni nube.
- En tu máquina
- El registro, las notas de memoria, los worktrees y cada ejecución de verificación, en tu ordenador o en tus propios servidores Linux.
- Necesita red
- Tus agentes, que hablan con sus propios proveedores como hacen hoy. Cualquier otro servicio externo es opcional y está desactivado hasta que lo actives.
- Requisitos
- Windows o Linux (macOS aún no es compatible), Python 3.12 o posterior, y Git. RADAR usa únicamente la biblioteca estándar de Python.
- Coste
- No genera facturas propias. Los agentes siguen usando las cuentas con las que has iniciado sesión en ellos. Solo se usa una API de pago si indicas el proveedor y un presupuesto.
- Instalación
- Dale a tu agente de programación el enlace del repositorio y dile «instala esto». Comprueba tu ordenador, pregunta antes de instalar lo que falte, instala RADAR en un entorno virtual e informa de lo que dicen radar init y radar doctor.
06 Comandos
Una lista corta de comandos.
Los comandos que usarás primero. Los marcadores de posición van entre corchetes angulares.
| Comando | Qué hace |
|---|---|
radar init | Prepara el directorio base de RADAR y el registro. |
radar doctor | Comprueba la instalación y enumera los servicios opcionales sin configurar. |
radar task new --project P --goal "…" --accept "<command>" | Abre una tarea con su comando de aceptación. |
radar dispatch <task> | Entrega una tarea a un agente, que trabaja en su propio worktree. |
radar status | Muestra el estado de todo el sistema. |
radar verify <task> | Vuelve a ejecutar el comando de aceptación sobre la revisión actual. |
radar task done <task> --evidence "<verification report>" | Cierra una tarea. Se rechaza hasta que la verificación haya pasado. |
radar collect | Recoge el trabajo terminado. |
radar integrate | Integra el trabajo verificado en main. |
radar stop | Aparca el trabajo y activa STOP. |
radar go | Quita STOP y enumera lo que puede continuar. |
radar memory search --local "<words>" | Busca en las notas de memoria sin conexión. |
radar uiradar web | Abre el panel de control en el terminal o en un navegador. |
radar help --all | Enumera todos los comandos. radar <command> -h muestra los detalles. |
07 Lo que no hace
Lo que RADAR no hace.
- No sustituye a tus agentes. Ellos siguen escribiendo el código; RADAR les da un único registro, una comprobación que no pueden saltarse y una memoria.
- No escribe tus pruebas. Una comprobación vale lo que vale su prueba; RADAR hace explícita la prueba antes de empezar el trabajo, para que una persona pueda leerla.
- No cierra trabajo que no tiene prueba. Una tarea sin un comando de aceptación ejecutable se rechaza al abrirse.
- No mantiene a tus agentes sin conexión. Siguen hablando con sus propios proveedores, como hacen hoy.
- La edición abierta es para desarrolladores individuales, no para equipos; hay una edición para empresas en desarrollo.
08 Estado
En acceso anticipado
Acceso anticipado ahora. Código abierto en el lanzamiento público.
RADAR está en acceso anticipado. Se publicará como código abierto bajo la licencia Apache-2.0 en su lanzamiento público. Para unirte, escríbenos.