Resumen

  • El borrador individual AER-1, revisión 04, exige formar cada hoja del flujo con el receipt_id; la página pública observada usa la secuencia y la huella de salida, seq:receipt_hash.
  • Los cinco recibos respondieron correctamente, se verificaron y coincidieron con el manifiesto. La construcción de la página reproduce su raíz publicada, pero la construcción del borrador obtiene otra.
  • Las funciones de Python, Rust y TypeScript del repositorio siguen la revisión 04. El corpus de 43 casos sigue marcado como -03 y no incluye ninguna prueba de flujo o árbol de Merkle.

El quinto recibo no está roto

Tomemos la última etapa del flujo público “get BTC price”. Su identificador es estable. Su punto de verificación responde. La huella de salida que devuelve coincide con la huella declarada en el manifiesto. Lo mismo ocurre con las otras cuatro etapas. Cinco peticiones HTTP 200; cinco respuestas verified: true; cinco coincidencias.

La página reúne esas evidencias mediante una regla explícita. Ante cada paso concatena su número de secuencia, dos puntos y la huella de salida en minúsculas. Calcula SHA-256 sobre esos bytes UTF-8, combina los hijos como bloques crudos de 32 bytes y duplica el último cuando un nivel queda impar. El resultado es a4b2fcb4684cec481e4ece889ed15c7d9e47e58d9ba4fb02ea354c0cb2ca44c4, exactamente la raíz publicada.

Ahora se mantiene el orden, SHA-256, la combinación binaria y la duplicación impar, pero se usa como hoja el identificador de cada recibo. El resultado pasa a ser 7c4817ca249edfeae259b98abf63ed38a31d9dbeebf5ee23139410a7a7f63b37.

Esa segunda regla es la que manda la revisión 04 de AER-1: A Portable Execution Receipt for AI Agent Tool Calls, presentada el 29 de septiembre de 2026. Es un Internet-Draft individual de carácter Informational, no un RFC ni un texto adoptado por un grupo de trabajo del IETF. Aun así, la comparación es factual: el documento actual y la superficie pública actual no nombran el mismo árbol.

Nada en este hallazgo exige afirmar que el recibo final sea falso o que el algoritmo criptográfico haya fallado. La prueba importante es más incómoda: cada lado puede ejecutar bien su propia regla.

La hoja es parte del protocolo

Hablar de “una raíz SHA-256” borra casi todo lo que un verificador necesita saber. Debe conocer el objeto seleccionado, su codificación, el orden, la forma de combinar hijos, el tratamiento de niveles impares y el formato final.

La revisión 04 define la hoja como SHA-256 sobre los bytes UTF-8 de receipt_id. Indica que la construcción alternativa permitida antes se elimina porque varias raíces para un mismo flujo rompen la verificación cruzada. Aunque el párrafo usa primero la palabra “recomendada”, la frase normativa posterior exige esa construcción con un MUST.

La página pública toma otra decisión: incorpora posición y compromiso de salida directamente en la hoja. Eso no es un error sintáctico. Es otro modelo de identidad. En el borrador, el flujo se construye sobre recibos estables que después deben resolverse y verificarse. En la página, el flujo se construye sobre una representación ordenada de sus salidas comprometidas.

Se puede debatir cuál preserva mejor la intención. Lo que no se puede hacer es llamar equivalentes a las dos. Una raíz desnuda no revela su propia gramática. Si un aprobador recibe solo 64 caracteres hexadecimales, no puede reconstruir qué campo fue elevado a prueba.

El código en ejecución revela dos conjuntos de compatibilidad

El repositorio público, observado en el commit f3aacbb5cf7d00977fd107afc34fc24b08c4f569, permite localizar la separación. La función Python recibe identificadores de recibo. Rust aplica el hash a los bytes del identificador. TypeScript lo hace sobre su UTF-8. Las tres repiten el último nodo impar y combinan los hijos crudos. Coinciden con la revisión 04.

El JavaScript de la página, en cambio, obtiene las huellas verificadas y crea hojas seq:hash. La división no está entre teoría y una implementación inexistente. Está dentro de las superficies públicas del mismo proyecto.

La primacía del código en funcionamiento no significa que una página pueda redefinir en silencio un contrato portátil. Significa que la adopción se mide donde el código realmente corre. Tampoco significa que publicar una revisión transforme los recibos ya emitidos. El texto, las bibliotecas y el servicio deben converger; mientras no lo hagan, existen dos conjuntos de compatibilidad.

La lección de especificación mínima de Lu Heng es útil porque evita una falsa economía. Una capa común debe ser pequeña, pero no ambigua. La selección de hojas es un invariante indispensable para que dos participantes validen localmente sin pedir interpretación al operador de origen.

Cuarenta y tres respuestas correctas a otras preguntas

El repositorio anuncia 43/43 en Rust, Go, TypeScript, Python, Java, C# y Swift. Ese dato demuestra consistencia frente a los 43 casos enumerados. No demuestra cobertura automática de una función añadida después.

El README delimita el alcance: miembros obligatorios del recibo, UUID, fechas, base64, UTF-8, compromiso de salida, procedencia, perfil del productor, anclas y emisores. No incluye flujos de trabajo. El índice de vectores identifica la revisión -03 y organiza casos válidos, inválidos, de perfil y anclados. No hay un caso denominado workflow, Merkle, step, sequence u odd node.

Por tanto, los siete ejecutores pueden obtener un resultado perfecto sin construir una sola raíz de flujo. La cifra es correcta; la interpretación amplia sería errónea.

Una prueba nueva debe congelar no solo la raíz esperada, sino los cinco identificadores, las cinco entradas de hoja, sus digestos, cada nivel y la duplicación del quinto elemento. La misma prueba debe recorrer la página desplegada, la API y todos los lenguajes admitidos. Así, la conformidad deja de ser una reputación y se convierte en una observación reproducible.

Verificar no es una operación única

Este caso separa seis controles que suelen aparecer bajo un solo adjetivo.

La integridad de etapa confirma que los bytes conservados coinciden con su compromiso. La vinculación al manifiesto confirma que la página usa las huellas que declara. La semántica de hoja confirma que se escogió el campo definido por un perfil concreto. La compatibilidad de raíz confirma que otra implementación del mismo perfil obtiene el mismo resultado. El anclaje confirma que un testigo registró un compromiso. El efecto externo confirma que la acción tuvo la consecuencia que interesa al negocio.

La página observada satisface sus controles locales y publica un ancla Nostr parcial. Pero un testigo solo puede atestiguar la raíz que recibe. No puede decidir retroactivamente si la hoja debía contener el identificador o la huella.

La agregación tampoco mejora la procedencia. Un paso reportado por otro agente sigue siendo un reporte; una observación desde una pasarela sigue limitada a esa pasarela. Consultar un precio no demuestra una operación, y una llamada aceptada no demuestra entrega.

El panel debería completar siempre la frase: bytes verificados, paso verificado, raíz compatible, ancla observada o efecto confirmado. Si no lo hace, la siguiente persona hereda una decisión que el sistema nunca tomó.

La raíz necesita documento de identidad

Para cruzar fronteras organizativas, la raíz debe viajar con versiones de esquema, identificador de construcción, codificación exacta, regla de padres, regla impar, formato de salida, lista ordenada de recibos, compromisos de etapa, procedencia, definición de la salida final, alcance del ancla y versión de vectores.

La decisión que la acepta debe registrar también su política y su principal. El objetivo no es producir papel. Es poder responder después quién aceptó cuál árbol.

Si el servicio migra de seq:receipt_hash a receipt_id, no debe recalcular en silencio el pasado. Debe conservar la raíz histórica, publicar un compromiso sucesor versionado y calcular ambas durante la transición. La adopción voluntaria se hace visible cuando los consumidores cambian de perfil, no cuando un texto nuevo declara que siempre hubo una sola interpretación.

Fuentes y límites

La observación se congeló el 30 de septiembre de 2026, hora de Shanghái. Demuestra una diferencia reproducible entre la revisión 04, un commit público fijo y la página activa en ese momento. No demuestra fraude, debilidad de SHA-256, intrusión, fallo de un efecto externo, adopción general ni respaldo del IETF. Solo se inspeccionaron las funciones de flujo de Python, Rust y TypeScript. El borrador y el servicio pueden cambiar.