Zusammenfassung

  • LACNICs öffentliches Hackathon-Repository weist einen Agenten an, das gemeinsame ai-harness zu lesen und im aktiven Modus vor einer verändernden Sitzung zu aktualisieren. Im Git-Baum liegt dafür nur ein 13 Byte langer symbolischer Link auf ../ai-harness.
  • Der Hackathon-Commit identifiziert damit die lokale Einstiegsvorschrift und den relativen Pfad, nicht aber Repository-URL, unveränderlichen Commit oder Inhaltsdigest des Nachbar-Regelwerks. Ein externer Instruktionsbeleg könnte diese Nachweislücke schließen, ohne einen Vorfall oder fehlerhaften Lauf zu unterstellen.

Dreizehn Byte können mehr operative Autorität tragen als ein langes Handbuch. Im aktuellen Baum von LACNIC/hackathon ist der Pfad ai-harness mit dem Modus 120000 eingetragen, also als symbolischer Link. Der zugehörige Blob enthält genau eine Angabe: ../ai-harness.

Für diese Architektur gibt es gute Gründe. Ein gemeinsam gepflegtes Harness kann Prüfregeln, Testverfahren und Startkontrollen auf mehrere Projekte verteilen. Eine zentrale Korrektur muss nicht in jedes Repository kopiert werden. Auch die im September veröffentlichte Änderung ist von Vorsicht geprägt: Sie trennt Wartungs- und Aktivmodus, verlangt vor verändernder Arbeit einen sauberen kanonischen Checkout und schließt einen linked worktree als Startpunkt aus.

Die offene Frage betrifft deshalb nicht den symbolischen Link an sich, sondern die Identität dessen, worauf er in einem konkreten Lauf zeigte. Der Hackathon-Commit belegt die Version seines eigenen AGENTS.md. Er belegt Modus, Größe und relativen Zielpfad des Links. Aus ihm allein folgt jedoch nicht, welches Repository und welcher Commit im Nachbarverzeichnis lagen, als der Agent die erste Zeile las, den Updater ausführte oder den Preflight durchlief.

Das externe Verzeichnis ist keine unverbindliche Lektüre. Das September-AGENTS.md verlangt vor jedem Befehl, ausschließlich die erste Zeile von ai-harness/AGENTS.md zu lesen und AI_HARNESS_MODE anzuwenden. Im Modus maintenance darf das Harness weder aktualisiert noch synchronisiert noch ausgeführt werden. Im Modus active soll der Agent ./ai-harness/harness/framework/update-framework.sh ausführen, anschließend die vollständige Regelkarte lesen und vor einer neuen verändernden Sitzung git-preflight bestehen.

Der Nachbar-Checkout wirkt damit an drei Entscheidungen mit: welche Regeln gelten, ob eine Aktualisierung erfolgt und welche Voraussetzungen eine Mutation zulassen. Zwei Rechner können denselben Hackathon-Commit halten und trotzdem unterschiedliche Moduszeilen, Updater oder Preflight-Regeln erhalten, wenn ihre Kopien von ../ai-harness abweichen. Die Quellen zeigen nicht, dass dies tatsächlich geschehen ist. Sie zeigen nur den engeren Befund, dass der Projekt-SHA allein den vollständigen Instruktionszustand nicht rekonstruiert.

Einführung im Juli, Präzisierung im September

Am 12. Juli 2026 führte Commit 16c37db9fe6e1c1b0bc7260b744ee7595a10de67 unter der Beschreibung „chore: adopt shared ai-harness“ die lokale Einstiegsdatei, den relativen Link und projektspezifische Vorlagen ein. Bereits diese Fassung verlangte, das gemeinsame Framework vor einer neuen Sitzung nichtinteraktiv zu aktualisieren und danach seine Regelkarte zu lesen.

Am 8. September erweiterte Commit a68504f87dd5226238bb65b62b89d40419ed7c1f den Vertrag. Er definierte maintenance und active, begrenzte Lesen und Schreiben im Wartungsmodus und erklärte die Anforderung eines sauberen kanonischen Checkouts. Die Änderung ging als Merge-Commit 6f9f60846acb30d4dcbf3969908743671c4a2921 in den Baum ein.

Dieser Baum bindet AGENTS.md an Blob 34e8fb06a0d71b939283dea4d77381ff029ad981. Den Link ai-harness bindet er an Blob 2244dfc17eaa1d54869e0bb3ff01ff258c6b0a0e, mit Größe 13 und symbolischem Modus. Das sind belastbare Identitäten für die im Hackathon-Repository gespeicherten Objekte. Der zweite Blob ist aber kein Gitlink auf einen Commit in einem anderen Repository. Er beweist lediglich den relativen Pfad.

Die lokale Vorschrift nennt weder die Git-URL des Nachbarn noch Tag, unveränderlichen Commit oder Inhaltsdigest. Eine Workstation-Abbildung, ein privates Einrichtungsskript oder ein Betriebsleitfaden könnte diese Festlegung außerhalb des öffentlichen Repositorys liefern. Die Quellen erlauben nicht die Behauptung, eine solche Kontrolle existiere nicht. Sie erlauben nur die Feststellung, dass sie nicht Bestandteil des Hackathon-Commits ist.

Aktualität und Rekonstruktion sind vereinbar

„Ungepinnt“ soll hier nicht heißen, das Harness müsse dauerhaft eingefroren werden. Sein Nutzen beruht gerade darauf, eine verbesserte Prüfung oder gemeinsame Korrektur schnell zu verteilen. Zu trennen sind die dynamische Auswahl und die dauerhafte Aufzeichnung.

Eine Umgebung kann zu Sitzungsbeginn „letzte freigegebene Revision“ auswählen. Nach der Auflösung zeichnet sie Repository-URL und unveränderlichen Commit auf. Bewegt der Updater das Harness von Revision A nach B, hält der Beleg beide Identitäten und das Ergebnis der Aktualisierung fest. So bleiben Regeln frisch und der damalige Zustand rekonstruierbar.

Software-Provenienz bietet dafür einen begrenzten Vergleich, keine an LACNIC gerichtete Norm. SLSA 1.2 beschreibt Provenienz als überprüfbare Information, die ein Artefakt durch die beweglichen Teile einer Lieferkette bis zu Ort, Zeit und Art seiner Herstellung zurückverfolgt. Ein Agenten-Regelwerk ist nicht automatisch ein Build-Artefakt, und LACNIC erklärt hier keine SLSA-Implementierung. Übertragbar ist lediglich: Eine bewegliche Abhängigkeit wird prüfbar, wenn ihre aufgelöste Identität das Ergebnis begleitet.

Ein kurzer Beleg für die externe Autorität

Ein solcher Beleg muss das Regelwerk nicht duplizieren. Er kann den Hackathon-Commit und Link-Blob, URL und unveränderlichen Commit des Nachbar-Repositorys, den gelesenen Wert von AI_HARNESS_MODE, die Harness-Revision vor und nach update-framework.sh, Version und Ergebnis von git-preflight, Identität von kanonischem Checkout und Worktree, Zeitpunkt sowie die auslösende Person oder Automatisierung enthalten.

Scheitert die Aktualisierung, sollte der Beleg unterscheiden, ob die Sitzung stoppte oder mit der älteren Revision fortfuhr. Wechselt der Modus, gehört der Übergang in die Aufzeichnung. Wird eine Regel später berichtigt, sollte eine Korrektur auf betroffene Belege verweisen, statt deren Geschichte still zu überschreiben. Geheimnisse, Prompts oder der vollständige Arbeitsplatz müssen nicht offengelegt werden; nachzuweisen ist die befolgte technische Autorität.

Auch die Überprüfung wird dadurch präziser. Unterschiede zwischen zwei Ergebnissen können aus Projektcode, Daten, Modell oder Harness stammen. Mit einer externen Identität lässt sich zuerst die prüfbare Ursache ausschließen. Ein Reviewer kann den Preflight reproduzieren, der die Sitzung zuließ. Später bleibt erkennbar, ob ein altes Ergebnis zu einem alten Projekt, einem alten Harness oder beidem gehört.

Das öffentliche Repository belegt weder einen Sicherheitsvorfall noch ein falsches Ergebnis oder einen Produktionspfad. Sichtbar ist ein engeres Governance-Problem: Die externen Regeln sind wichtig genug, einen Modus auszuwählen, eine Aktualisierung auszulösen und eine Mutation freizugeben oder zu stoppen. Sobald eine Regel Handlungen autorisiert, gehört ihre Version zur Identität dieser Handlung.

Quellen