Resumen

  • El repositorio público Hackathon de LACNIC ordena leer un ai-harness compartido y, en modo activo, actualizarlo antes de una sesión que modifica el proyecto. En el árbol del repositorio, ese arnés aparece como un enlace simbólico de trece bytes a ../ai-harness.
  • El commit fija el archivo local y el destino relativo, pero no la URL, el commit inmutable ni la huella del repositorio hermano. Un recibo de instrucciones externas cerraría la brecha de reproducibilidad sin sugerir que hubo un incidente o un resultado incorrecto.

En un repositorio de software, trece bytes pueden decidir más que cientos de líneas. El árbol actual de LACNIC/hackathon registra la ruta ai-harness con modo 120000, es decir, como enlace simbólico. El blob correspondiente contiene únicamente ../ai-harness.

El diseño tiene ventajas evidentes. Un arnés común permite compartir controles de revisión, reglas de arranque y prácticas de prueba entre distintos proyectos. Una mejora hecha en el marco central puede llegar a todos ellos sin copiar carpetas enteras. El cambio publicado en septiembre también añade frenos concretos: separa mantenimiento de actividad, exige un checkout canónico y limpio antes de modificar estado y prohíbe abrir esa tarea en un linked worktree.

Nada de eso constituye un defecto por sí mismo. La pregunta es otra: ¿qué versión exacta de la autoridad externa gobernó una ejecución determinada? El commit de Hackathon identifica su propio AGENTS.md y el blob del enlace. No identifica lo que había en el directorio hermano cuando el agente consultó la primera línea, ejecutó el actualizador o pasó el control previo.

La diferencia no es meramente documental. El AGENTS.md de septiembre indica que, antes de cualquier comando, se lea exclusivamente la primera línea de ai-harness/AGENTS.md y se aplique AI_HARNESS_MODE. En mantenimiento, el agente no debe actualizar, sincronizar ni ejecutar el arnés. En modo activo, debe lanzar ./ai-harness/harness/framework/update-framework.sh, leer el mapa completo y someter una nueva sesión mutante a git-preflight.

Por tanto, el repositorio hermano participa en tres decisiones: qué reglas existen, si debe actualizarse el marco y qué condiciones habilitan el cambio. Dos estaciones con el mismo SHA de Hackathon pueden leer instrucciones distintas si sus copias de ../ai-harness no coinciden. Las fuentes no demuestran que eso haya ocurrido. Demuestran algo más limitado y comprobable: el SHA del proyecto no basta para reconstruir por sí solo el estado total de las instrucciones.

Del enlace inicial al control de septiembre

El 12 de julio de 2026, el commit 16c37db9fe6e1c1b0bc7260b744ee7595a10de67, titulado “chore: adopt shared ai-harness”, incorporó el archivo local de entrada, el enlace relativo y varios modelos específicos del proyecto. Ya entonces se pedía actualizar el marco común sin interacción antes de una sesión nueva y leer después su mapa de reglas.

El 8 de septiembre, el commit a68504f87dd5226238bb65b62b89d40419ed7c1f amplió el contrato. Definió maintenance y active, restringió lo que el primero puede leer o escribir y explicó que el preflight exige un checkout canónico limpio. El cambio fue fusionado como 6f9f60846acb30d4dcbf3969908743671c4a2921.

Ese árbol liga AGENTS.md al blob 34e8fb06a0d71b939283dea4d77381ff029ad981. También liga ai-harness al blob 2244dfc17eaa1d54869e0bb3ff01ff258c6b0a0e, con modo simbólico y tamaño trece. Son identidades sólidas para los objetos guardados dentro de Hackathon. La segunda, sin embargo, sólo prueba una ruta relativa; no funciona como un puntero a un commit de otro repositorio.

El texto local no contiene una URL Git para el hermano, una etiqueta, un commit inmutable ni un digest. Puede existir otro control, privado o externo, que lo aprovisione de manera exacta. Una imagen de desarrollo o un manual del operador podría hacerlo. El registro público no autoriza a negar esa posibilidad; sólo obliga a reconocer que tal prueba no está dentro del commit analizado.

Actualizar y dejar constancia

“Sin fijar” no significa que el arnés deba quedar congelado. Un marco compartido resulta útil porque cambia: incorpora una regla mejor, un control más estricto o una corrección común. La tensión desaparece cuando se separa la selección de la constancia.

El sistema puede resolver “última revisión aprobada” al comenzar. Una vez resuelta, registra la URL y el commit inmutable. Si el actualizador mueve el arnés, conserva el identificador anterior, el nuevo y el resultado de la operación. Así mantiene la frescura sin perder la capacidad de reconstruir el contexto.

La práctica de procedencia de software ofrece una comparación útil, no una obligación para LACNIC. SLSA 1.2 describe la procedencia como información verificable que permite seguir un artefacto a través de las piezas móviles de una cadena hasta dónde, cuándo y cómo fue producido. Un conjunto de instrucciones para agentes no es automáticamente un artefacto de compilación, y LACNIC no afirma aplicar SLSA aquí. La idea trasladable es sencilla: una dependencia móvil se vuelve auditable cuando el resultado conserva su identidad resuelta.

Un recibo para la autoridad externa

El recibo puede ser más pequeño que el propio AGENTS.md. Debería incluir el commit de Hackathon, el blob del enlace, la URL y el commit inmutable del repositorio hermano, el valor observado de AI_HARNESS_MODE, la revisión antes y después de update-framework.sh, la versión y el resultado de git-preflight, la identidad del checkout canónico, la hora y la identidad del operador o automatización.

Si la actualización falla, el recibo debe decir si la sesión se detuvo o continuó con la versión anterior. Si cambia el modo, debe conservar esa transición. Si una regla se corrige después, una entrada de corrección puede señalar los recibos afectados sin reescribirlos. No hace falta publicar secretos, prompts ni todo el entorno local: el objetivo es identificar la autoridad seguida.

La misma prueba mejora la revisión. Ante dos salidas distintas, el equipo puede separar un cambio de código de un cambio de instrucciones. El revisor puede reproducir el preflight que habilitó la tarea. Quien mantenga el proyecto meses después puede saber si un resultado pertenece a un commit antiguo de Hackathon, a un arnés antiguo o a ambos.

El repositorio público no prueba un incidente de seguridad, una ejecución errónea ni un despliegue en producción. Expone una cuestión más precisa: las reglas externas ya son lo bastante importantes para escoger un modo, actualizarse y abrir o cerrar la puerta a una mutación. Cuando una regla adquiere esa autoridad, su identidad también forma parte de la identidad de la ejecución.

Fuentes