Кратко

  • Публичный репозиторий Hackathon LACNIC предписывает агенту прочитать общий ai-harness, а в активном режиме — обновить его до начала сессии с изменениями. В дереве Git этот harness представлен только символической ссылкой длиной 13 байт на ../ai-harness.
  • Коммит Hackathon однозначно задаёт локальную точку входа и относительный путь, но не URL, неизменяемый коммит или дайджест соседнего репозитория. Квитанция о внешних инструкциях закрыла бы разрыв в воспроизводимости, не подразумевая инцидент, ошибочный результат или эксплуатацию в production.

Тринадцать байт способны нести больше операционной власти, чем длинное руководство. В текущем дереве LACNIC/hackathon путь ai-harness имеет режим 120000, то есть хранится как символическая ссылка. Содержимое связанного blob состоит только из ../ai-harness.

У такой схемы есть понятное преимущество. Общий harness позволяет централизованно поддерживать правила ревью, тестирования и входных проверок для нескольких проектов. Исправление в одном месте не приходится копировать повсюду. Сентябрьское изменение также вводит осмысленные ограничения: разделяет maintenance и active, требует чистый канонический checkout перед изменяющей работой и запрещает начинать её в linked worktree.

Поэтому вопрос не в допустимости символической ссылки. Вопрос — в идентичности правил на другом её конце во время конкретного запуска. Коммит Hackathon доказывает версию собственного AGENTS.md, режим, размер и относительную цель ссылки. Но только по нему нельзя установить, какой репозиторий и какой коммит находились в соседнем каталоге, когда агент прочитал первую строку, запустил обновление или прошёл предварительную проверку.

Внешний каталог — не факультативная справка. Сентябрьский AGENTS.md требует до любой команды прочитать только первую строку ai-harness/AGENTS.md и применить AI_HARNESS_MODE. В режиме maintenance запрещено обновлять, синхронизировать и исполнять harness. В режиме active агент должен выполнить ./ai-harness/harness/framework/update-framework.sh, затем прочитать полную карту правил и перед новой изменяющей сессией пройти git-preflight.

Следовательно, соседний checkout участвует в трёх решениях: какие правила действуют, нужно ли обновление и какие условия допускают изменение состояния. Две машины могут содержать один и тот же коммит Hackathon, но получить разные строки режима, обновляющие сценарии или preflight, если их копии ../ai-harness различаются. Источники не доказывают, что такое расхождение произошло. Они доказывают более узкий тезис: SHA проекта сам по себе не восстанавливает полное состояние инструкций.

Июльское подключение и сентябрьская детализация

12 июля 2026 года коммит 16c37db9fe6e1c1b0bc7260b744ee7595a10de67 с сообщением «chore: adopt shared ai-harness» добавил локальный файл входа, относительную ссылку и проектные шаблоны. Уже тогда правило предписывало перед новой сессией без диалога обновить общий framework, а затем прочитать карту harness.

8 сентября коммит a68504f87dd5226238bb65b62b89d40419ed7c1f расширил договор. Он ввёл два режима, ограничил чтение и запись в maintenance и описал требование чистого канонического checkout. Изменение вошло в дерево через merge-коммит 6f9f60846acb30d4dcbf3969908743671c4a2921.

Это дерево связывает AGENTS.md с blob 34e8fb06a0d71b939283dea4d77381ff029ad981. Ссылка ai-harness связана с blob 2244dfc17eaa1d54869e0bb3ff01ff258c6b0a0e, размером 13 и режимом символической ссылки. Это точные идентификаторы объектов внутри Hackathon. Но второй blob не является gitlink на коммит другого репозитория: он подтверждает только относительный путь.

В локальном договоре нет Git URL соседа, tag, неизменяемого коммита или хеша содержимого. Возможно, рабочий образ, частный установщик или внешняя инструкция закрепляет эту версию в другом месте. Публичные данные не позволяют утверждать, что такой контроль отсутствует. Они позволяют утверждать лишь то, что доказательство не находится внутри рассматриваемого коммита.

Свежесть не требует забывать прошлое

«Незакреплённый» не означает, что общий harness следует навсегда заморозить. Его ценность как раз в возможности быстро распространить лучшую проверку или общее исправление. Следует различать динамический выбор и долговременную запись результата выбора.

Среда может разрешить запрос «последняя одобренная ревизия» в начале сессии. После разрешения она записывает URL и неизменяемый коммит. Если updater переводит harness с ревизии A на B, квитанция сохраняет обе идентичности и итог обновления. Правила остаются свежими, а исторический контекст — реконструируемым.

Практика software provenance даёт ограниченную аналогию, но не создаёт требования к LACNIC. SLSA 1.2 описывает provenance как проверяемую информацию, которая проводит артефакт через подвижные части цепочки к месту, времени и способу его производства. Набор агентских правил не обязательно является build-артефактом, и LACNIC не заявляет о применении SLSA здесь. Полезен лишь принцип: разрешённая идентичность подвижной зависимости должна сопровождать результат.

Квитанция короче самого свода правил

Нужная запись может быть компактной. В неё входят коммит Hackathon и blob ссылки, URL и неизменяемый коммит соседнего репозитория, фактически прочитанный AI_HARNESS_MODE, ревизии harness до и после update-framework.sh, версия и итог git-preflight, идентичность канонического checkout и worktree, время, а также лицо или автоматизация, начавшие сессию.

Если обновление не удалось, квитанция должна отличать остановку от продолжения на прежней ревизии. При смене режима сохраняется переход. Если правило позднее исправлено, добавляется корректирующая запись со ссылкой на затронутые запуски, а история не переписывается. Секреты, prompts и полное состояние рабочей станции публиковать не нужно; важно назвать техническую власть, которой подчинился запуск.

Такая связь упрощает ревью. Разница между двумя результатами может идти от кода, данных, модели или harness. Внешняя идентичность позволяет начать с проверяемого различия. Ревьюер может воспроизвести preflight, допустивший сессию, а спустя месяцы определить, относится старый результат к старому проекту, старому harness или обоим.

Публичный репозиторий не доказывает инцидент безопасности, неверный вывод или производственный путь. Он показывает более точную проблему управления: внешние правила уже достаточно значимы, чтобы выбирать режим, запускать обновление и открывать или закрывать доступ к изменениям. Если правило разрешает действие, версия правила становится частью идентичности действия.

Источники