Orbit

El modelo produce más rápido de lo que puedes revisar

Un modelo ayuda a definir una solución: te ordena las ideas y te propone por dónde cortar, y después va más rápido de lo que alcanzas a leer.

Me pasa seguido. La última vez fue con una funcionalidad complicada del propio Orbit, que terminó en una rama que dejé ahí sin integrar, porque llegamos a un punto donde ni el modelo ni yo sabíamos si el resultado cumplía con lo que habíamos definido.

Necesitas verlo mientras está pasando, y un lugar donde parar antes de que llegue a tu rama.

Corre el CLI que ya tienes

Claude Code, Codex, OpenCode, Antigravity. Le das la tarea, corre en su propio worktree, y queda escrito lo que hizo.

Un worktree por tarea

Cada tarea corre en su propio checkout, sobre su propia rama, así que nada de lo que escribe está en la tuya hasta que tú lo digas.

Fases que paran donde dijiste

Entre fase y fase pones un gate: un comando que corre y deja pasar o devuelve el trabajo. Responde con un código de salida, no con una opinión.

Autopilot, con freno

Las tareas pendientes hacen cola y el autopilot las va tomando solo, hasta que se acumulan diez terminadas que nadie ha leído, y entonces deja de arrancar nuevas.

Tu CLI, en los dos sentidos

Una tecla le entrega la terminal, ya dentro del worktree de la tarea. Y tu CLI, por MCP, escribe tareas, las corre, y te lee de vuelta lo que pasó mientras no estabas.

Un supervisor al que le puedes decir que no

Lee el resultado de una corrida, decide si hizo lo que se pidió, y arregla lo que falta, en un hilo en el que tú escribes.

Lo que ya sabe de tu código

Lo que Orbit ya sabe de tu repositorio, con su fuente y su alcance. Vive fuera del modelo, así que cambias de motor y sigue ahí.

Lo que ves de cada tarea

Lo que gastó, qué corrió cada gate, qué negó el sandbox, la línea de tiempo evento por evento, los artefactos, el razonamiento que mostró y el diff.

Todo escrito, al lado del código

orbit show lee una corrida seis meses después, y orbit export saca el registro completo.

Lo que el diff no muestra

La pestaña de impacto lee el historial del repositorio: si un archivo casi siempre cambia junto a otro, y esta vez el otro no cambió, te lo dice.

Aprende de ti, y nada llega a un agente sin que lo apruebes

Reglas sobre tu código que llegan al prompt antes de que el agente trabaje, y que devuelven el trabajo cuando les pones un comando que responde sí o no. En la pantalla se llama lo que Orbit sabe. Yo le digo el cerebro.

El modelo olvida entre sesiones, y olvida cuando lo cambias. CLAUDE.md lo lee Claude y AGENTS.md lo lee Codex, así que el día que cambias de motor el nuevo no abre el archivo del otro. Lo que Orbit sabe vive afuera de los dos. Estrenas un CLI y sigue sabiendo que en este repositorio las migraciones se generan.

lo dices tú un modelo lo encuentra lo sigues diciendo el proyecto ya lo dijo

la bandejanada pasa sin que lo leas

→

una reglaaplicando

→

el prompt de cada fasey el gate

→

se te atraviesala saltas, o la pausas

→

la revisióncon la evidencia delante

corregir · acotar · apagar · reanudar

Cuatro entradas, una sola cola, y una regla que se puede echar para atrás. Nada que escribas tú llega a un prompt sin que lo hayas visto, y no pierdes una regla porque te molestó una vez. Lo que viene en el repositorio cuando clonas lo revisas en el diff, como cualquier otro cambio.

Las cuatro entradas

01Lo dices tú

Le dices al supervisor "nunca subas un pull request sin que pasen los tests" y Orbit te la ofrece de vuelta como regla. Lo nota por cómo empieza la frase, con una lista corta de arranques escrita a mano, sin gastar modelo.

02Un modelo lo encuentra

Un agente que se traba a mitad de tarea anota lo que aprendió con orbit_learn. Queda esperando tu aprobación.

03Lo sigues diciendo

Lo que repites tanto que ya ni te das cuenta de que lo pides. "Métele fuzz testing" dicho en la fase de test de seis tareas seguidas es una regla que nunca escribiste, y Orbit la junta y un modelo la redacta.

04El proyecto ya lo dijo

Un repositorio con dos años de historia ya tiene la mitad de sus reglas escritas en el CONTRIBUTING y el README. Y sus commits dicen cuáles siguen siendo verdad.

$ orbit rules read -with claude

process   CONTRIBUTING.md:182      Corre make check y lee su código de salida antes de abrir un PR.
style     CONTRIBUTING.md:122      Nunca escribas un color hex fuera de internal/ui/theme.
testing   362 commits leídos       un cambio bajo internal viene con su test,
                                     como en 264 de los 281 que lo tocaron

Cada regla que sale de un documento cita la línea exacta. Si el modelo no puede citar ninguna, la propuesta se descarta: pedirle que resuma dos años de CONTRIBUTING produce frases que suenan bien y nadie escribió nunca.

Las que salen de la historia traen su conteo. Y una regla que el documento pide y los commits contradicen ni te la ofrece: una frase que nadie sostuvo en un año no llegó a ser regla.

La primera vez que corres Orbit en un repositorio trae pocas y buenas, porque si te llegan cuarenta propuestas malas dejas de abrir la bandeja, y ahí pierdes también las otras tres entradas.

La bandeja

La única pregunta que tienes cuando te sientas es qué hay que decidir.

$ orbit rules

  1  2026-09-13 18:52  ACME-1 · modelo  internal/db  las migraciones se generan

e2dada18 acme                 la cobertura se queda por encima de 75%
         acme nunca ha pasado de 60, eso lo estamos arreglando primero

Las numeradas son frases que nadie ha contestado. Con identificador salen las reglas que se mandaron a mirar otra vez. Desde ahí la guardas con tus palabras, o acotada a una carpeta, o con un comando que detenga el trabajo.

Qué es una regla

---
id: 875c38ec
scope: dir
source: model
path: internal/db
---

las migraciones se generan, nunca se editan a mano

El nombre se pone una vez y no cambia

Corriges la frase, mueves el lugar, la apagas, y sigue siendo la misma regla.

Seis alcances

Todo, un lenguaje, un repositorio, un directorio, un archivo, un símbolo. Se leen en ese orden, y la última palabra la tiene el más cercano a lo que está por tocar.

De dónde salió

Tú, un motor a mitad de tarea, un documento con su línea, o los commits con su conteo. Lo que repites cuenta como dicho por ti. Una regla sin fuente no entra.

Dice algo, o rechaza

Rechazar necesita algo que responda sí o no sin opinión adentro. Si una regla manda a parar pero no trae comando, solo avisa.

El comando es tuyo

Lo escribes tú, nunca un modelo. Corre en cada fase futura de ese repositorio, y uno lento es una hora de tarea que nadie aprobó.

Activa, pausada o apagada

Solo la activa entra al prompt. La pausada la frenaste tú con su razón escrita, y la apagada se queda guardada y no entra a ningún prompt.

Cuando una regla te frena

Estás en el medio de otra cosa, así que solo hay dos salidas, las dos baratas y reversibles.

saltarlaPasas esta vez, y la regla sigue puesta.

pausarlaDeja de aplicar, y escribes para qué.

Las dos la mandan a revisión, y solo la primera vez. Saltarla una vez no prueba nada, pero saltarla cuatro veces sí dice algo.

Por eso la pausa te pide una razón. Es lo que vas a leer cuando vuelvas.

Apagarla y reescribirla no aparecen ahí. Esas dos deciden si la regla sigue viva, y no las resuelves con una tarea a medias.

Sentarte a decidir

$ orbit rules review -rule e2dada18

e2dada18 acme                 la cobertura se queda por encima de 75%
         acme nunca ha pasado de 60, eso lo estamos arreglando primero

  la guardaste el 12 de agosto
  detuvo el trabajo 4 veces en test, y te la saltaste todas
  detuvo el trabajo 2 veces en build, y las dos se arreglaron
  la pausaste el 9 de septiembre: acme nunca ha pasado de 60

Una regla que el modelo obedece no aparece en esa lista. Así que verla vacía quiere decir dos cosas opuestas: que funciona, o que nunca le tocó nada. Una regla es buena hasta que te molesta, y solo la fricción queda escrita.

En acme pediste 75% de cobertura y ese repositorio nunca ha pasado de 60. La regla está bien, llegó temprano. Ningún número resuelve eso, y por eso Orbit te pone los datos delante y decides tú.

Acotarla resuelve casi todos los casos. Una regla que molesta en docs y sirve en payments se escribió muy general, y sin un alcance más chico lo único que puedes hacer con ella es borrarla.

Dónde vive cada regla

Dos lugares para las reglas, y la pregunta es una: ¿viaja? El registro es aparte.

<repo>/.orbit/knowledge/Reglas sobre ese checkout. Se van con el push, así que quien clona el proyecto las recibe, y una regla nueva entra por un diff, como cualquier cambio, y alguien la revisa antes.

$ORBIT_HOME/knowledge/Reglas sobre todo, y sobre un lenguaje. No son de ningún checkout, así que se quedan en esta máquina, y si cambias de máquina no van contigo.

el registroLo que le ha pasado a cada regla. Va en SQLite, porque un historial escrito en el archivo dejaría un diff en tu checkout cada vez que corre un gate. Un gate que pasa ni se anota, así que en el registro solo queda la fricción.

Las diez pantallas

Cada una tiene su demo corriendo en getorbit.sh.

01

Empezar

Cuatro comandos, y el único que tienes que pensar es el tercero: apuntar la cabina al directorio donde están tus repositorios.

02

Los menús

Presionas m sobre cualquier cosa y sale todo lo que le puedes hacer. Lo que no aplica sale en gris, con la frase que dice por qué.

03

Una corrida completa

Una lista de fases, cada una lo bastante pequeña para revisarla, con un veredicto escrito después de cada una.

04

Autopilot

Toma la siguiente pendiente y la lleva por su flujo. Con diez tareas terminadas sin leer, deja de arrancar nuevas.

05

Varias en paralelo

Tres corridas andando, en tres worktrees, en una sola ventana. Dos agentes en dos checkouts no se pisan, porque cada uno está en su rama.

06

Leer lo que hizo

El resumen, el reporte, el diff tarjeta por tarjeta, y lo que el agente dice que consideró y decidió no hacer.

07

El CLI

Veintidós herramientas MCP, así que tu CLI escribe tareas, las corre, lee lo que pasó y las dirige.

08

El supervisor

Le dices "la migración tiene que ser reversible" y sigue ahí la próxima sesión, y el mes que viene.

09

Lo que Orbit sabe

La pantalla donde vives con las reglas. Ahí las corriges, las acotas, las pausas con su razón, o las apagas.

10

Flujos que escribes tú

Un flujo es la lista de fases de una tarea. Cinco vienen incluidos. Los tuyos son JSON, y los nombres de las fases son tuyos.

Lo que Orbit te promete mientras miras

Orbit existe para que le creas.

Nada se esconde

Ningún error se traga ni se cambia por una frase amable. Si un check falló, la ventana dice que falló, qué dijo, y en qué fase fue. Y cuando Orbit no sabe algo, lo dice.

Lo que ves, lo ves completo

Una acción que arranca algo avisa al arrancar y otra vez al terminar, y si la espera es larga la ventana dice qué está esperando. Y una tecla que no se puede presionar explica por qué, en tu idioma.

Todo queda escrito

Cada falla y cada cambio de estado pasa por el log con su etiqueta. Nada escribe por detrás de la ventana, porque eso corrompe la terminal y pierde el registro a la vez.

El registro es textual

Lo que dijo un motor queda escrito como lo dijo. Un resumen siempre va al lado del texto original.

Cada regla se argumentó antes de existir

A un modelo hay que decirle cómo se trabaja en tu repositorio. Parte va en un documento. El resto son límites que revientan la compilación si se los salta, y la mayoría de ellos son pruebas con nombre propio.

Donde una regla puede hacer fallar la compilación, la hace fallar, y donde no puede, la razón queda escrita al lado, para que el que venga discuta con la razón y no con la regla.

Los seis límites

Todos se corren con make check.

16

Pruebas de arquitectura

Una salta si un paquete exporta algo que no es una puerta de entrada, otra si aparece un import fuera del mapa de capas, otra si el go.mod suma una dependencia que nadie argumentó, y así trece más.

300

Líneas por archivo

Código y comentario, sin contar blancos. Un archivo por encima del techo son dos temas que todavía no se separaron, y se parte por la costura.

100

Columnas por línea

El límite son 100 columnas, y el trinquete anota cuántas líneas se pasan hoy. Ese número solo puede bajar, nunca subir. Una frase que lee una persona queda exenta, porque partirla para que entre la empeora.

90%

De cobertura, como piso

Es un gate, y el comando sale en error si baja. Un número que se imprime y nadie mira se va cayendo de a poco, y el día que alguien lo ve en 60% ya nadie sabe quién se lo gastó.

2-3

Métodos por interfaz

La interfaz es de quien la necesita, y se declara donde se usa. Una que crece se marca como puerta de entrada, y la siguiente que la toque la deja más chica.

1

Un error se atiende una vez

Se envuelve y se pasa, o se registra y se detiene. Las dos cosas a la vez dejan el mismo problema contado dos veces en dos lugares distintos.

Seis tipos de prueba, cada uno con su cuándo

Cada cambio trae los que le tocan, casi siempre dos o tres. Y al que no trae ninguno no hay quién lo refactorice después.

01Unitarias

Siempre. Un comportamiento, con nombre, en el paquete que lo tiene. El nombre dice el comportamiento: TestADeletedIdIsFreeAgain, en vez de TestDelete.

02De propiedades

Aplica cuando algo tiene una ley en vez de una respuesta. Un ida y vuelta que no puede perder nada, un costo que solo sube, una fila que nunca sale más ancha que la terminal.

03Fuzzing

Cuando llegan bytes de afuera. No puede reventar con ninguna entrada, y el caso que encuentra queda guardado en el repositorio. Un crash encontrado una vez es un caso que la suite se queda.

04Integración

El binario real, un repositorio git real con un módulo Go adentro, gates corriendo comandos reales. Solo el modelo es de mentira, porque un modelo no es gratis ni es igual dos veces.

05Mutation testing

Antes del pull request. Cambia el código por debajo de las pruebas y pregunta si se dan cuenta. Un mutante que sobrevive es una prueba que mira sin ver, y toca matarlo o escribir por qué da igual.

06Adversariales

El caso que escribe alguien tratando de romperlo. La entrada vacía, la que llega dos veces, el archivo borrado entre listarlo y leerlo, el valor legal y absurdo. Casi todos los bugs que este proyecto ha soltado fueron uno de esos, y cada uno es hoy una prueba con su comentario.

En qué va Orbit

v0.1.x. Lo uso todos los días, y es joven: el número de versión lo dice.

Estable La cabina, los flujos y los gates, el aislamiento por worktree, el registro en SQLite, el servidor MCP, los pull requests de GitHub.

En uso, todavía moviéndose El supervisor, autopilot, lo que Orbit sabe, la lectura de impacto, el conteo de cuota, el diseñador de flujos.

Sus límites de hoy La lectura de impacto va por archivo y no por símbolo. El texto de los issues solo se lee de Linear.

Motores Claude Code, Codex, OpenCode, Antigravity.

Plataformas macOS y Linux.

Y además

Apache 2.0 Español e inglés Seis temas de color Veintidós herramientas MCP Cinco flujos incluidos Doce paneles por tarea Seis alcances de conocimiento orbit join abre un segundo repositorio orbit export saca el registro completo orbit show lee una corrida vieja $ORBIT_HOME, que por defecto es ~/.orbit go install con Go 1.26+ Se aceptan issues y pull requests y lo que vaya saliendo

La serie

Voy escribiendo cada parte de Orbit en el blog.

01 Orbit necesita a Orbit 13 sep 2026