Minga: el control de versiones sin dueño — hecho para agentes de IA, firma cada commit, entiende el código y recuerda tu máquina entera

Cada vez que alguien guarda un cambio en un programa, lo guarda en un control de versiones: la máquina del tiempo que recuerda qué cambió, quién lo cambió y cuándo, y que permite volver atrás. Desde hace más de quince años esa máquina se llama git, y la historia de casi todo el software del planeta vive en un mismo lugar: GitHub, propiedad de Microsoft desde 2018. Este artículo cuenta qué es minga, el control de versiones que alguien escribió para tawasuyu y que hoy es su repositorio principal; qué hace que git no hace —empezando por algo que git no imaginó: muchos agentes de IA trabajando sobre la misma historia—, y qué pasó a fines de octubre, cuando dejó de guardar sólo código y empezó a guardar la máquina entera. Con los números a la vista, incluidos los que no salieron bien.

El nombre

En los Andes, la minka —minga, en buena parte del continente— es el trabajo colectivo: la comunidad se junta para levantar una casa, una acequia o una cosecha, y lo hecho es de todos y de nadie en particular. Es un homenaje a esa forma de trabajar, no una bandera: el proyecto no habla en nombre de ningún pueblo, aprende de ellos. Y describe bien lo que este programa quiere ser: una historia que se levanta entre muchas manos —algunas humanas y otras no—, sin un patrón que la guarde.

Lo que git hace muy bien, y lo que no le toca

Hay que decirlo sin caricatura: git es una obra maestra. Es rápido, es distribuido por diseño —cada copia tiene la historia entera— y su modelo de objetos direccionados por su propio hash es tan bueno que minga hace lo mismo. Ganó porque lo merecía.

Pero tiene límites que no son defectos sino decisiones de 2005, cuando nadie imaginaba que la mitad de los cambios los iba a escribir una máquina:

• Supone una persona frente a su copia. Doce agentes sobre el mismo repositorio se pisan los archivos, se roban el índice y se enteran de que tocaron la misma función recién cuando el merge falla.
• No sabe quién escribió qué. El autor de un commit en git es un nombre y un correo que cualquiera puede escribir. Firmar existe, pero es opcional, se configura aparte y la mayoría no lo hace. En la práctica, «quién lo hizo» lo certifica la cuenta del servidor.
• No sabe qué es una función. Para git un programa es un montón de líneas de texto. Si movés una función de un archivo a otro, git ve un archivo que perdió cuarenta líneas y otro que las ganó; y para fusionar dos ramas compara líneas, no sintaxis.
• Distribuido en teoría, centralizado en la práctica. git no necesita servidor, pero los equipos se coordinan en uno, y la revisión, la integración continua, los permisos, los issues y los avisos viven ahí. Bajarse de GitHub es posible; bajarse sin perder nada no lo es.

Minga adelante, git detrás

En tawasuyu la relación ya se invirtió. minga es el repositorio principal y git es su espejo: cada sesión de trabajo commitea en minga, en su propia rama; la fusión la hace minga, y de ahí el resultado viaja a git. Armar el árbol de git de un commit de minga tarda entre 0,08 y 0,42 segundos —reusa todo lo que no cambió—, contra 23,7 del camino que reconstruía el árbol entero.

Git sigue al frente sólo hacia afuera: quien llega de otro lado clona y empuja con git, porque es lo que tiene instalado. Y hasta eso lo atiende minga: desde el 22 de octubre, git.tawasuyu.net no es un gitea sino el hospedaje de minga, que habla git por la puerta y guarda minga por dentro.

Hecho para trabajar con agentes de IA

Buena parte de tawasuyu se escribe con asistentes de IA trabajando en paralelo —en una misma máquina hubo días con hasta dieciocho sesiones a la vez—, y minga creció para eso. Es la primera diferencia con git, y la más grande:

• Cada agente en su rama, sobre el mismo repositorio. minga commit --branch commitea sin mover el puntero de nadie, un servicio (minga host) es el único dueño del almacén y atiende a todas las sesiones por un socket, y juntar el trabajo de dos agentes no es «gana el último»: es una fusión de tres vías del árbol. Medido: sin el servicio, dos commits al mismo tiempo dejaban a uno en el piso; con él entran los dos.
• El choque se avisa antes del commit. Como el servicio ve a todas las sesiones de la máquina, sabe qué funciones tiene tocadas cada una sin commitear, y minga status avisa: «esta función también la está cambiando otro árbol». En git eso se descubre en el merge.
• Preguntar sin clonar, por MCP. El hospedaje habla MCP, el protocolo con el que los asistentes usan herramientas: un agente pregunta quién llama a una función, busca definiciones por nombre o pide «la rebanada» de una tarea —los archivos y las definiciones que toca— sin bajar el repositorio. Y un clon perezoso trae los commits y deja los archivos en el origen hasta que alguien los lee: una sesión no carga 4 GB para tocar uno.
• La ayuda queda firmada. Cada commit declara con qué modelo se hizo (Assisted-by:), firmado junto con el resto, y puede llevar su intención —arreglo, refactor, ruptura de API— como campo propio adentro de la firma. Quien lea la historia sabe qué escribió una persona y qué una máquina, y para qué.
• La memoria del porqué. minga why toma una función y devuelve, versión por versión y a través de renombres, el commit que la cambió con su mensaje entero, su intención, quién ayudó, las revisiones firmadas y la conversación del forge sobre ese cambio. Es el contexto que un agente necesita antes de tocar algo que no escribió.
• Tareas con dueño y con vara. Un agente toma una tarea con su llave por un plazo, y la cierra su propio push y no el de otro. Una tarea con vara —la prueba que dice si está hecha— se da por cerrada sólo cuando M claves de confianza firmaron esa prueba en verde, y el cierre no puede salirse de los archivos que la tarea declaró tocar.
• Llaves delegadas, no contraseñas. Un agente firma con una llave que su dueño le delega con alcance y vencimiento; el hospedaje dice de quién es cada agente y hasta cuándo puede escribir.
• La IA ayuda donde sirve, y se la verifica. El mensaje de un commit se sugiere desde lo que cambió por definición, y una fusión que choca puede resolverla un modelo —pero lo que propone se vuelve a validar, y una respuesta basura se rechaza—. Lo que sale limpio sin IA, no la llama.

Entiende el código, no las líneas

minga parsea el código (Rust, Python, JavaScript, TypeScript, Go y C) y guarda, junto a cada commit, qué funciones y tipos nacieron, cambiaron o murieron. Cada definición tiene una identidad que no depende de su nombre: funny_add y amusing_add con el mismo cuerpo dan la misma huella, en cuatro lenguajes. De ahí salen preguntas que git no puede contestar:

• minga impact: quién llama a esta función, por símbolo resuelto y no por texto —un comentario que la nombra no es un llamador—.
• minga blame y minga log-def: de quién es cada definición y toda su historia, aunque haya cambiado de nombre o de archivo.
• minga api-check: si un cambio rompe la API pública, decidido por la firma de lo público y no por una convención.
• minga graft: traer una función de otra rama, no un commit entero.
• minga grep: buscar por sentido —«decidir a quién le toca compilar»— y no por palabra, también en la historia, diciendo cuándo existió lo que encontró.
• minga query: la historia como base de datos. Un Datalog chico sobre commits, autores, definiciones, firmas y llamadas: «qué funciones públicas cambió alguien que no tiene una revisión firmada», en una línea.

Fusionar leyendo la sintaxis

Cuando dos ramas tocan el mismo archivo, git compara líneas. minga fusiona el árbol sintáctico: dos cambios en funciones distintas del mismo archivo no chocan, una función movida de lugar y editada del otro lado no se duplica, y el archivo fusionado sale con su formato y sus comentarios, no re-impreso. Cuando sí hay choque, el conflicto no es un archivo roto con marcas: es un valor guardado adentro del árbol, se puede commitear, mover de base y resolver después, y sólo la sentencia que chocó lleva marcas.

Medido sobre el repositorio real: de 1.059 fusiones de tres vías tomadas de su propia historia, 982 salen limpias, y sólo una duplicó algo. Y se compara contra mergiraf, la herramienta de fusión estructural de referencia, como oráculo de paridad.

Confianza sin autoridad central

En git, en quién confiar lo decide el servidor. En minga lo decide cada uno, y queda firmado:

• Todo commit va firmado con la identidad del repositorio (Ed25519), y un commit puede llevar K firmas de una comunidad, con umbral.
• Las revisiones son firmas con quórum M-de-N, y su consenso no es un conteo: una aprobación tibia de un revisor pesa menos que una convencida, y un rechazo de alguien de reputación alta no se diluye. Cada uno declara en quién confía y cuánto, y puede exigir más firmas a un cambio según cuánto código toca.
• Las claves se revocan y se rotan por quórum de guardianes, y esa revocación viaja por la red como cualquier otra cosa.
• Un pedazo del repositorio puede ir cifrado a ciertas claves: viaja, se verifica y se fusiona como cualquier otro, pero sólo lo leen sus destinatarios.
• La puerta tiene portero: un nodo se abre a todos, sólo a los de confianza para escribir, o sólo a los de confianza para todo.

El forge entero, sin servidor

Lo que hace a GitHub difícil de dejar no es git: es todo lo de alrededor. En minga cada pieza es un registro firmado que viaja con la historia por la misma sesión de sincronización:

• Propuestas de integración con quórum, que se revalidan contra la punta de hoy cuando la rama destino avanza (minga revalidate): cada una queda integrada, limpia, verificada, rompiendo la prueba o chocando, y el veredicto se firma.
• Comentarios anclados a una función, no a una línea: si la función se muda de archivo, el comentario se muda con ella.
• Issues, releases con su changelog sacado del cambio por definición, eventos de estado, y una wiki versionada en el mismo repositorio.
• Integración continua firmada: cada máquina firma «construí este commit, dio verde, el binario tiene este hash», y con M máquinas el commit queda certificado. De ahí salen un bisect que no vuelve a correr nada, fusiones que se juzgan con una prueba antes de entrar, una caché de builds reproducibles y la concesión con la que arje, el init de tawasuyu, deja arrancar un binario.

El hospedaje: un forge para agentes, con git como puerta

Para el mundo que usa git, minga tiene un hospedaje: minga-serve. Desde el 22 de octubre sirve git.tawasuyu.net y git.gioser.net en lugar de gitea, con los 55 repositorios mudados y una vuelta atrás preparada. Por la puerta habla git —cualquiera clona y empuja con lo que tiene instalado—, y por dentro todo lo de arriba: las ramas protegidas no piden «pasó el CI del servidor» sino M atestaciones firmadas; los agentes entran con sus llaves delegadas; la API y el MCP contestan sin clonar; y una cara web sin JavaScript, en castellano, inglés y quechua, muestra las tareas, las propuestas con su cambio por definición, las atestaciones y la procedencia de cada commit.

El día a día

• Sin área de preparación. El árbol de trabajo es el commit en curso; no hay git add.
• Deshacer todo. Cada operación —commit, fusión, rebase, borrar una rama— queda en un diario, y minga undo la deshace; también se puede mirar el repositorio como estaba después de cualquier operación, sin tocar nada.
• Rápido sin preguntar. Un vigía del sistema de archivos le dice al servicio qué cambió, y un archivo que no cambió no se vuelve a leer ni a parsear.
• Un commit como carpeta. minga mount monta el árbol de cualquier commit como un directorio, sin sacarlo.
• Edición en vivo entre dos máquinas. Dos personas editando el mismo archivo a la vez, cada una en su computadora, convergen al mismo contenido —medido entre una laptop y un servidor: el mismo md5 de los dos lados— y lo convergido entra a la historia firmada.

Que aguante: los números

Un control de versiones se juzga con el repositorio grande, no con el de juguete. El de tawasuyu tiene más de 9.000 commits y unos 4 GB de historia, y minga la lleva entera desde septiembre. Tres mediciones de cómo llegó a aguantarla:

Y la tercera es la que más costó: entre septiembre y octubre la base de datos que guardaba los objetos se rompió dos veces al llenarse el disco a mitad de una escritura, y la segunda vez la recuperación borró todo lo que se había escrito después del error. Se reemplazó entera. Los objetos y los commits viven ahora en paquetes de sólo agregar, con una suma de verificación por registro, un minga fsck que el propio servicio corre cada 24 horas, y una réplica viva de lo que git no puede rehacer. El espejo bajó de 9,4 a 4,0 GB. Sobre un banco de 200.000 commits, listar las ramas pasó de 1.128 a 9 milisegundos.

Fines de octubre: de guardar código a guardar la máquina

Los documentos ya vivían en minga: en pluma, el editor de la suite, cada párrafo conserva su identidad entre versiones, y hay blame por párrafo, propuestas de edición, sincronización de máquina a máquina y fusión de dos versiones párrafo por párrafo. El plan del proyecto tiene una línea que se llama, sin modestia, minga como sustrato de toda la suite: que el mismo almacén firmado guarde todo lo que una persona quiere poder recordar y deshacer. A fines de octubre se cerró. Seis piezas nuevas, todas funcionando:

Y la línea de tiempo de la máquina también lee la de takana: el diario donde el sistema anota cada archivo que cambia y las generaciones de cada actualización aparecen intercaladas con las fotos de tu configuración, y «volver» sobre una actualización le pide la vuelta atrás a takana, que es quien sabe hacerla. Probado contra una máquina de producción que corre takana: el diario de 9.299 renglones y sus 17 generaciones caben en 100 entradas, y la actualización del 16 de septiembre aparece como una entrada de 777 archivos —el mismo número de cambios que dice el manifiesto de su generación—.

Lo que salió mal, contado

Un proyecto que sólo muestra lo que anduvo está escondiendo algo. Cuatro tropiezos de esos días, y lo que enseñó cada uno:

• Un espejo roto en silencio durante cinco días. Revisando otra cosa apareció un aviso: el espejo de minga del repositorio de takana, en el servidor, no abría desde el 24 de octubre. El error sólo lo veía quien empujaba, y quien empujaba cada hora era una granja de compilación sin nadie mirando. Se rehízo desde git en 40 segundos —pasó de 1,8 GB a 238 MB— y los otros tres espejos que seguían en la base vieja se migraron con su historia intacta. Que el error del espejo llegue a algún lugar que alguien lea es trabajo pendiente.
• Una derivación que borraba al CI. La primera versión guardaba una atestación por máquina y por commit, sin mirar qué se había corrido. Una máquina que corría los tests y después una receta sobre el mismo commit se pisaba sola: el resultado científico, en verde, borraba el veredicto de los tests, en rojo.
• Y el arreglo rompió otra cosa. Para que convivieran, la herramienta entró a la clave de todas las atestaciones. Eso hizo que revalidar una propuesta dejara dos firmas de la misma máquina donde la nueva tenía que pisar a la vieja. No lo vio el test de la derivación: lo vio la suite completa, corrida horas después por otro motivo. Ahora sólo las derivaciones y las comprobaciones conviven; el resto, una por máquina, como antes.
• Una prueba que daba bien sin haber probado nada. La primera autoprueba del sistema operativo devolvía la huella correcta del árbol, y no había guardado nada: corría antes de que el disco estuviera montado, y la función de guardar devuelve la huella aunque no escriba. Por eso la línea que imprime ahora dice también si pudo releerlo.

Lo que todavía no

• Hacia afuera, la cara sigue siendo git. Por dentro minga es el principal, pero quien llega de otro lado todavía clona y empuja con git, y el viaje del espejo a origin sigue yendo por git. Que dos desconocidos colaboren directamente por minga es el paso que falta.
• La costumbre se mide. Las piezas para que cada agente trabaje en su rama de minga existían desde septiembre; medido el 1 de octubre, de 129 commits en 48 horas, sólo 2 habían nacido en minga. Desde ese día cada sesión nace en su propio árbol de trabajo, y el camino del agente publica por minga.
• El sistema operativo leyó minga en una máquina virtual, no en hierro. La prueba arranca dos veces sobre el mismo disco virtual; falta verlo en una computadora de verdad.
• El índice de takana no sabe todavía de clases de hardware. El quórum de kernels funciona en el ciclo de prueba y promoción; anotar en el índice firmado para qué hardware se certificó cada paquete cambia un formato firmado, y por eso es decisión de takana.
• Lo que se trae de la red no se guarda. Pedir un archivo suelto a otro nodo lo baja cada vez; takana guarda sus paquetes por su lado, pero minga no recuerda lo que bajó.
• La fusión estructural tiene techo en la gramática. De 1.059 fusiones reales, 77 dan conflicto —algunas son choques de verdad, otras son lo que el parser todavía no sabe juntar—, y quedan 16 archivos que el parser no entiende, todos C de terceros.

Cómo verlo

minga vive en la región raíz del repositorio de tawasuyu —git.tawasuyu.net, servido por el propio minga— bajo 03_ukupacha/minga. El plan, PLAN-VCS.md, cuenta cada fase con sus mediciones y sus fechas; las líneas de trabajo están en 03_ukupacha/minga/lineas/, cada una con lo que se certificó y lo que falta, tal como salió; y FLUJO-AGENTE.md cuenta cómo trabaja un agente con minga adelante y git detrás.