Resumo

  • A revisão 04 do Internet-Draft individual AER-1 determina folhas baseadas em receipt_id; a página pública observada usa seq:receipt_hash.
  • Os cinco endpoints responderam HTTP 200, os cinco recibos retornaram verified: true e seus hashes coincidiram com o manifesto. A regra da página recompõe sua raiz; a regra do rascunho produz outra.
  • Os auxiliares em Python, Rust e TypeScript do commit congelado seguem o rascunho. O corpus anunciado como 43/43 ainda se identifica como revisão -03 e não testa raízes de workflow.

O navegador fez exatamente o que prometeu

O workflow público 42a3c2cf-2cdd-5b8a-aced-016e5a2fb634 mostra cinco etapas. Seu botão de verificação busca cada recibo, exige sucesso individual, extrai o hash de saída e compara esse valor com o manifesto. Uma repetição independente confirmou todos esses passos: cinco respostas HTTP 200, cinco estados positivos e cinco correspondências de hash.

Depois, o navegador forma cada folha com número de sequência, dois-pontos e hash em minúsculas. Aplica SHA-256 aos bytes UTF-8 de seq:receipt_hash, combina filhos como blocos crus de 32 bytes e duplica o último bloco quando o nível é ímpar. A conta chega a a4b2fcb4684cec481e4ece889ed15c7d9e47e58d9ba4fb02ea354c0cb2ca44c4, a raiz exibida.

Não há falha local para denunciar. A página explica sua regra e a executa de forma coerente.

Mas a revisão 04 de AER-1: A Portable Execution Receipt for AI Agent Tool Calls, publicada em 29 de setembro de 2026, manda formar a folha a partir dos bytes UTF-8 do receipt_id. Aplicada às mesmas cinco etapas, preservando árvore binária e duplicação ímpar, essa regra chega a 7c4817ca249edfeae259b98abf63ed38a31d9dbeebf5ee23139410a7a7f63b37.

AER-1 é um Internet-Draft individual com intenção Informational. Não é RFC nem documento adotado por um grupo de trabalho do IETF. O limite institucional é importante. O limite operacional também: duas superfícies públicas atualmente identificam o mesmo workflow com raízes diferentes.

A divergência está no objeto, não no algoritmo de hash

Dizer “a raiz usa SHA-256” é tão incompleto quanto dizer que um contrato usa tinta preta. O verificador precisa saber quais bytes recebem o hash, como são codificados, como os filhos são combinados, como se trata um elemento sem par e como se apresenta a saída.

A revisão 04 remove a permissão antiga para construções alternativas. Seu texto explica o motivo: raízes divergentes para o mesmo fluxo quebram a verificação entre implementações. Embora chame a construção de recomendada numa frase, logo depois usa MUST para torná-la obrigatória.

A página vincula posição e compromisso de saída diretamente à folha. O rascunho vincula a árvore às identidades estáveis dos recibos e exige que cada recibo seja resolvido à parte. Há razões técnicas para ambos. Não há equivalência entre ambos.

O valor final não conta sua própria história. Um auditor que receba apenas 64 caracteres hexadecimais não descobre se a folha continha ID, hash, sequência ou uma serialização específica. Uma raiz sem perfil é um identificador local disfarçado de prova portátil.

O repositório já está do outro lado

No commit público f3aacbb5cf7d00977fd107afc34fc24b08c4f569, a função Python calcula folhas a partir de IDs. Rust usa os bytes de cada ID. TypeScript usa UTF-8 do ID. Os três auxiliares seguem a revisão 04, inclusive na duplicação do último nó ímpar.

O JavaScript da página continua no modelo seq:hash. Isso mostra uma migração incompleta: texto e três bibliotecas estão em um conjunto de compatibilidade; a página em execução está em outro.

Running-Code Primacy não concede soberania automática ao código que chegou primeiro. Ela obriga a descrever o que está realmente implantado. Publicar uma revisão também não altera retroativamente recibos estáveis. A realidade surge quando documento, vetor, biblioteca e serviço convergem por implementação e uso.

Na formulação de Lu Heng, uma especificação inicial mínima deve eliminar decisões discricionárias do núcleo comum. Mínima não quer dizer vaga. A escolha da folha é justamente o que permite validação local. Se a resposta depende de perguntar ao operador qual convenção usou, a autoridade continua centralizada.

43/43 mede o corpus, não a reputação

O repositório registra 43/43 para sete linguagens. O README delimita as regras: forma do recibo, UUID, data, Base64, UTF-8, hash de saída, proveniência, perfil do produtor, âncoras e round-trip. Workflows não aparecem.

O índice dos vetores declara revisão -03. Entre os 43 casos não há grupo de workflow, Merkle root, sequência, step hash ou duplicação ímpar. Portanto, cada runner pode acertar todas as respostas sem calcular uma árvore de workflow.

O placar continua válido dentro da prova realizada. O erro seria transformá-lo em cobertura de uma função nova.

Um vetor da revisão 04 deve congelar IDs, entradas de folha, hashes de folha, níveis intermediários e raiz esperada. A página real, a API e cada linguagem precisam consumir esse mesmo material. Só então o número mede interoperabilidade de workflow.

Seis perguntas antes de exibir verde

Os bytes de cada recibo conferem com seu compromisso? O hash retornado confere com o manifesto? A folha segue uma construção nomeada? Outra implementação dessa construção encontra a mesma raiz? Uma testemunha externa registrou a raiz? A ação produziu o efeito esperado fora do sistema?

São seis perguntas. O caso público responde positivamente às duas primeiras e à coerência de sua própria construção. Também mostra uma âncora Nostr parcial. A âncora testemunha o compromisso recebido; não escolhe a semântica da folha.

Nem a raiz promove proveniência. Uma ação relatada por outro agente continua sendo relato. Uma observação via gateway continua limitada ao gateway. Um preço consultado não é uma ordem liquidada.

O produto precisa dizer o que verificou. “Hash de etapa válido”, “manifesto coerente”, “raiz compatível com construção X” e “efeito confirmado” não são sinônimos.

Um passaporte para a raiz

Uma raiz portátil precisa viajar com versões de schema, identificador de construção, codificação, função de hash, regra de pais, regra de nó ímpar, formato final, etapas ordenadas, compromissos, proveniência, definição dos bytes de saída, escopo da âncora e versão do vetor de teste.

A decisão de aceitá-la deve guardar política e principal. Assim, meses depois, a organização sabe quem aceitou qual árvore.

Uma migração de seq:receipt_hash para receipt_id deve preservar a raiz antiga, emitir compromisso sucessor versionado e calcular as duas durante a transição. Reescrever uma URL pública apagaria o próprio fato que os recibos deveriam conservar.

Fontes e limites

As fontes foram congeladas em 30 de setembro de 2026, no fuso de Xangai. Elas demonstram uma divergência reproduzível entre a revisão 04, um commit público fixo e a página então ativa. Não demonstram fraude, falha do SHA-256, invasão, fracasso de efeito externo, adoção geral ou endosso do IETF. A leitura de código limita-se aos auxiliares de workflow em Python, Rust e TypeScript. O rascunho e o serviço podem mudar.