Resumo

  • O repositório público Hackathon da LACNIC manda o agente consultar um ai-harness compartilhado e, no modo ativo, atualizá-lo antes de uma sessão com mudanças. Na árvore Git, esse harness é apenas um link simbólico de treze bytes para ../ai-harness.
  • O commit fixa o arquivo de entrada e o caminho relativo, mas não a URL, o commit imutável ou o digest do repositório irmão. Um recibo de instruções externas fecharia essa lacuna sem insinuar que houve incidente, uso em produção ou resultado errado.

Treze bytes podem carregar mais autoridade do que um manual inteiro. Na árvore atual de LACNIC/hackathon, o caminho ai-harness aparece com modo 120000, a representação Git de um link simbólico. O blob associado contém uma única sequência: ../ai-harness.

Há uma boa razão para adotar esse arranjo. Um harness comum distribui regras de revisão, testes e controles de início por vários projetos. Uma correção feita no centro pode beneficiar todos eles sem uma sucessão de cópias. A atualização publicada em setembro também acrescenta barreiras cuidadosas: distingue manutenção de atividade, exige um checkout canônico e limpo antes de trabalho mutante e proíbe iniciar esse trabalho em um linked worktree.

O ponto não é condenar o link. É identificar a versão da autoridade que estava do outro lado dele. O commit do Hackathon prova qual AGENTS.md local foi gravado. Prova o modo, o tamanho e o destino relativo do link. Não prova, por si só, qual repositório ou revisão ocupava o diretório irmão quando o agente leu a primeira linha, rodou o atualizador ou passou pelo preflight.

Esse material externo não é uma referência opcional. O AGENTS.md de setembro determina que, antes de qualquer comando, o agente leia exclusivamente a primeira linha de ai-harness/AGENTS.md e aplique AI_HARNESS_MODE. No modo maintenance, não deve atualizar, sincronizar nem executar o harness. No modo active, deve executar ./ai-harness/harness/framework/update-framework.sh, ler o mapa completo e submeter uma nova sessão mutante ao git-preflight.

Assim, o checkout irmão participa de três decisões: quais regras valem, se haverá atualização e quais condições autorizam a mudança. Duas máquinas podem ter o mesmo commit do Hackathon e, ainda assim, receber modos, atualizadores ou verificações diferentes se suas cópias de ../ai-harness divergirem. As fontes não mostram que essa divergência ocorreu. Mostram apenas que o SHA do projeto não reconstrói sozinho o estado completo das instruções.

O que mudou entre julho e setembro

Em 12 de julho de 2026, o commit 16c37db9fe6e1c1b0bc7260b744ee7595a10de67, descrito como “chore: adopt shared ai-harness”, introduziu o arquivo local, o link relativo e modelos específicos do projeto. A regra já mandava atualizar o framework comum sem interação antes de uma nova sessão e, em seguida, ler o mapa do harness.

Em 8 de setembro, o commit a68504f87dd5226238bb65b62b89d40419ed7c1f detalhou o contrato. Criou os modos maintenance e active, limitou leituras e escritas no primeiro e explicou que o preflight exige o checkout canônico limpo. A mudança entrou na árvore por meio do merge 6f9f60846acb30d4dcbf3969908743671c4a2921.

Essa árvore associa AGENTS.md ao blob 34e8fb06a0d71b939283dea4d77381ff029ad981. Associa também o link ai-harness ao blob 2244dfc17eaa1d54869e0bb3ff01ff258c6b0a0e, com tamanho treze e modo simbólico. São identidades precisas para os objetos mantidos dentro do repositório Hackathon. O segundo blob, porém, não é um ponteiro de submódulo para o commit de outro repositório; ele atesta somente o caminho relativo.

O contrato local não informa uma URL Git do irmão, uma tag, um commit imutável ou um hash de conteúdo. É possível que uma imagem de desenvolvimento, um instalador privado ou um manual operacional faça essa fixação fora do repositório. O material público não permite concluir que tal controle inexiste. Permite concluir somente que ele não faz parte da prova contida no commit do Hackathon.

Atualidade não precisa apagar a reconstituição

“Sem versão fixada” não significa que o harness deva parar no tempo. A utilidade de um framework compartilhado está justamente em receber rapidamente uma nova regra ou um reparo comum. A solução é separar a escolha dinâmica do registro durável.

O ambiente pode selecionar “a última revisão aprovada” ao iniciar a sessão. Depois de resolvê-la, registra a URL e o commit imutável. Se o atualizador mover o harness da revisão A para B, o recibo conserva as duas identidades e o resultado da atualização. A equipe mantém a atualidade e ganha a capacidade de reconstruir o contexto.

A prática de proveniência de software oferece uma comparação limitada, não uma exigência dirigida à LACNIC. A SLSA 1.2 descreve proveniência como informação verificável capaz de acompanhar um artefato pelas partes móveis de uma cadeia até onde, quando e como ele foi produzido. Um conjunto de instruções de agentes não é automaticamente um artefato de build, e a LACNIC não afirma implementar SLSA neste caso. A ideia transferível é menor: uma dependência móvel se torna auditável quando sua identidade resolvida acompanha o resultado.

Um recibo menor do que as regras

O registro necessário cabe em poucas linhas. Deve conter o commit do Hackathon, o blob do link, a URL e o commit imutável do repositório irmão, o valor observado de AI_HARNESS_MODE, a revisão antes e depois de update-framework.sh, a versão e o resultado de git-preflight, a identidade do checkout canônico e do worktree, o horário e a identidade do operador ou automação.

Se a atualização falhar, o recibo precisa dizer se a sessão parou ou prosseguiu com a revisão anterior. Se o modo mudar, a transição deve aparecer. Se uma regra for corrigida mais tarde, um registro de correção deve apontar para os recibos afetados, sem reescrever a história. Não há necessidade de publicar segredos, prompts ou toda a estação de trabalho; o objetivo é identificar a autoridade técnica obedecida.

Essa ligação também melhora a revisão. Uma diferença entre duas saídas pode nascer do código, dos dados, do modelo ou do harness. Com a identidade externa, o revisor começa pela hipótese verificável. Também pode reproduzir o preflight que admitiu a sessão e distinguir um resultado regido por projeto antigo, harness antigo ou ambos.

O repositório público não demonstra incidente de segurança, saída incorreta ou caminho de produção. Ele expõe uma questão mais precisa: as regras externas já são importantes o bastante para escolher um modo, acionar uma atualização e abrir ou fechar uma sessão mutante. Quando a regra decide a ação, a identidade da regra integra a identidade da ação.

Fontes