Résumé

  • Le dépôt public Hackathon de LACNIC demande à l’agent de lire, et en mode actif d’actualiser, un cadre commun nommé ai-harness. Dans l’arbre Git du projet, ce cadre n’est représenté que par un lien symbolique de treize octets vers ../ai-harness.
  • Le commit du projet identifie donc sa propre porte d’entrée, mais ni l’URL, ni le commit immuable, ni l’empreinte du référentiel frère qui fournit les règles exécutées. Un reçu d’instructions externes permettrait de conserver la souplesse du cadre partagé tout en rendant chaque mutation reconstituable.

Le fichier le plus influent d’un dépôt n’est pas toujours le plus volumineux. Dans l’arbre actuel de LACNIC/hackathon, le chemin ai-harness pèse treize octets. Git lui attribue le mode 120000 : il s’agit d’un lien symbolique. Le blob associé ne contient ni script ni manifeste, seulement ../ai-harness.

Ce choix a une logique opérationnelle. Un même harnais peut diffuser des règles de revue, des contrôles de démarrage et des pratiques de test à plusieurs projets. Une correction réalisée au centre évite de recopier le même dispositif partout. Le changement de septembre montre d’ailleurs une volonté de discipline : il sépare un mode de maintenance d’un mode actif, impose un dépôt canonique propre avant toute session modificatrice et exclut les worktrees liés pour ce type de tâche.

Le problème n’est donc pas l’existence du lien. Il tient à ce que le commit Hackathon permet de reconstituer — et à ce qu’il laisse hors champ. Il fixe son propre AGENTS.md. Il fixe le blob du lien et sa destination relative. Mais il ne dit pas quel dépôt, quelle branche ou quelle révision se trouvait réellement dans le répertoire frère au moment où l’agent y a lu ses règles.

Or ce répertoire extérieur ne sert pas simplement de documentation facultative. Le texte de septembre demande, avant toute commande, de lire exclusivement la première ligne de ai-harness/AGENTS.md et d’appliquer la valeur AI_HARNESS_MODE. Si la valeur indique la maintenance, le harnais ne doit être ni actualisé ni exécuté. Si elle indique le mode actif, l’agent doit lancer ./ai-harness/harness/framework/update-framework.sh, puis suivre la carte complète. Cette carte déclenche à son tour git-preflight avant l’ouverture d’une session qui modifie l’état.

Autrement dit, le contenu du dépôt frère contribue à décider quelles règles existent, si une mise à jour doit avoir lieu et quelles conditions autorisent une mutation. Deux postes peuvent posséder exactement le même commit Hackathon et recevoir néanmoins des consignes différentes si leurs copies du harnais divergent. Les sources ne montrent pas que cela s’est produit. Elles montrent seulement que le SHA du projet ne suffit pas, à lui seul, à démontrer l’état complet des instructions.

Deux dates, deux couches de règles

Le 12 juillet 2026, le commit 16c37db9fe6e1c1b0bc7260b744ee7595a10de67, intitulé « chore: adopt shared ai-harness », a introduit le fichier d’entrée, le lien relatif et plusieurs modèles propres au projet. Le texte demandait déjà d’actualiser sans interaction le cadre commun avant une nouvelle session, puis d’en lire la carte.

Le 8 septembre, le commit a68504f87dd5226238bb65b62b89d40419ed7c1f a détaillé le contrat. Il a ajouté les deux modes, limité les lectures et écritures permises en maintenance et précisé le contrôle préalable : checkout canonique, propre, non ouvert dans un linked worktree. Le changement a été intégré dans 6f9f60846acb30d4dcbf3969908743671c4a2921.

L’arbre de ce commit de fusion lie AGENTS.md au blob 34e8fb06a0d71b939283dea4d77381ff029ad981. Il lie également ai-harness au blob 2244dfc17eaa1d54869e0bb3ff01ff258c6b0a0e, avec le mode symbolique et la taille de treize octets. Ces identités décrivent exactement les objets conservés dans le dépôt Hackathon. La seconde ne désigne toutefois aucun commit d’un autre dépôt : elle ne prouve que le chemin relatif.

Le fichier local ne fournit ni URL Git du harnais, ni tag, ni commit immuable, ni somme de contrôle. Il se peut qu’une image de poste, un script d’installation privé ou un manuel d’exploitation impose cette identité ailleurs. Le constat public est plus limité : une personne qui ne possède que le dépôt Hackathon et son commit ne possède pas cette preuve.

Rester à jour n’oblige pas à perdre la trace

Le mot « épinglé » mérite ici une définition précise. Il ne s’agit pas d’exiger que le harnais cesse d’évoluer. Sa valeur vient justement de sa capacité à recevoir rapidement une correction commune. L’enjeu consiste à séparer le choix dynamique de la trace durable.

Un poste peut sélectionner « la dernière révision approuvée » au début d’une session. Après résolution, il peut inscrire l’URL et le commit immuable retenus. Si l’outil de mise à jour passe d’une révision à une autre, le reçu peut conserver les deux identités ainsi que le résultat de l’opération. La fraîcheur est préservée ; la possibilité de rejouer le contexte l’est aussi.

La pratique de provenance logicielle fournit ici un repère, pas une obligation juridique ou normative. SLSA 1.2 définit la provenance comme une information vérifiable permettant de remonter, à travers les éléments mobiles d’une chaîne, au lieu, au moment et à la manière dont un artefact a été produit. LACNIC n’affirme pas appliquer SLSA à ce dépôt, et un corpus de consignes n’est pas nécessairement un artefact de build. L’analogie reste utile : une dépendance mobile devient contrôlable lorsque son identité résolue accompagne le résultat.

Le reçu qui manque

Un reçu d’instructions externes pourrait rester très court. Il contiendrait le commit Hackathon, le blob du lien, l’URL du dépôt frère et son commit immuable, la valeur observée de AI_HARNESS_MODE, la révision du harnais avant et après l’actualisation, la version et le résultat de git-preflight, l’identité du checkout canonique, l’heure et l’identité de l’opérateur ou de l’automatisation.

En cas d’échec de l’actualisation, le reçu indiquerait si la tâche s’est arrêtée ou si elle a continué avec l’ancienne révision. En cas de changement de mode, il conserverait le passage. Une correction ultérieure ajouterait une entrée reliée aux sessions concernées au lieu de réécrire silencieusement leur histoire. Il n’est pas nécessaire d’exposer des secrets, les prompts ou l’intégralité de l’environnement local : il suffit de nommer l’autorité technique suivie.

Cette liaison aiderait aussi le réviseur. Une différence entre deux résultats pourrait venir du code du projet, du modèle, des données ou des règles du harnais. Sans identité externe, ces causes restent mêlées. Avec elle, la comparaison commence au bon endroit.

Rien dans le dossier public ne démontre un incident, une mauvaise sortie ou l’utilisation du dépôt en production. Le signal est plus sobre : les règles externes sont désormais assez importantes pour déterminer un mode, déclencher une mise à jour et contrôler l’accès à la mutation. À ce stade, identifier leur version n’est plus une commodité documentaire. C’est une partie de l’identité de la décision.

Sources