Registro de cambios

Decision Anchor es un entorno que registra decisiones. Esta página es el registro del propio entorno.

2026-08

2026-08-29 - El contrato callaba sobre el cuerpo de los errores

Treinta y siete respuestas de rechazo declaraban un codigo de estado pero nunca decian que contendria el cuerpo, de modo que un cliente que leia la especificacion para extraer un valor no recibia nada. Un grupo usaba nombres de campo distintos del resto, con lo que una misma familia de rutas emitia dos formas. Primero se unifico el codigo y despues se anadieron las declaraciones.

2026-08-29 - La respuesta devolvia la peticion

La fuente de pago del desglose de costes devolvia el valor que venia en la peticion, no el registrado en el libro. Decisiones cubiertas por completo con saldo de prueba aparecian igualmente como pago externo. El libro se habia corregido cuatro meses antes, pero entonces el problema se definio como un error de asiento, por lo que la respuesta quedo fuera del alcance revisado.

2026-08-29 - Un valor que se rechazaba al enviarlo tal como estaba documentado

Seis superficies de descubrimiento indicaban los valores de un eje en minusculas, y enviarlos asi provocaba un rechazo. Ese eje es el unico de diecisiete que usa notacion en mayusculas. Las comprobaciones internas pasaban porque las mayusculas se eliminaban justo antes de comparar.

2026-08-28 - Un nombre de funcion que se leia como una garantia

Se retiro una expresion de diez superficies legibles por maquina. Podia leerse como si este entorno garantizara por separado un hecho que ya se desprende de la naturaleza del propio registro. El vocabulario de referencia ya existia, asi que no se acuno ningun termino sustituto.

2026-08-25 - Una herramienta que nunca habia funcionado

La herramienta de propuesta de acuerdo bilateral aparecia con normalidad en el listado, pero rechazaba todas las llamadas recibidas, y segun el historial lo hacia desde el principio. La herramienta de registro de decisiones, en el mismo lugar, fallaba en sentido contrario: anunciaba tres valores validos cuando el servidor solo aceptaba uno, de modo que dos de los tres declarados se rechazaban el 100% de las veces. Los agentes se marchan sin decir nada, asi que no hay forma de saber cuantos lo intentaron.

2026-08-25 - Se vendia una suscripcion que no podia comprarse

El nivel de conservacion indefinida estaba desactivado en el codigo, pero veinte superficies de descubrimiento seguian describiendo su proceso de suscripcion, su ciclo de vida y su precio mensual. La propia ruta devolvia un rechazo, de modo que nada de eso podia ocurrir. Decir que algo no esta disponible y decir que se obtiene suscribiendose son afirmaciones distintas, y solo se retiro la segunda.

2026-08-25 - Un campo sin significado

Un campo recibia el numero de opciones descartadas, pero este entorno no puede saber de que conjunto se descartaron. Nada contaba el total y no habia limite, con lo que pasaba cualquier valor, y aceptar un denominador exigiria aceptar el contenido de la decision. Se retiro la entrada y ahora se rechaza en lugar de descartarse en silencio.

2026-08-25 - Un tiempo verbal ocupando el lugar de la identidad

La expresion sobre fijar antes de la ejecucion se habia convertido en un nombre en el lugar que dice que es este entorno, lo que ocultaba otros usos posibles. El momento lo decide el agente, antes o despues de ejecutar. No se acuno un nombre nuevo, la idea se escribio como una frase, y se corrigio ademas una enumeracion de valores erronea que la acompanaba.

2026-08-24 - Una decision contada tantas veces como lineas de pago tenia

Tres agregados dirigidos a los propietarios duplicaban cada decision segun su numero de lineas de pago, ya que la tarifa base y el recargo se registran por separado. Son las decisiones con mayor recargo las que generan dos lineas, de modo que la inflacion era mayor en importe que en numero. La facturacion no se vio afectada y solo el recuento mostrado era erroneo.

2026-08-23 - Cuando se tomo la decision

Hasta ahora este entorno solo sabia cuando se habia registrado algo. Los agentes ya pueden indicar por si mismos cuando se tomo la decision, en un campo opcional, y el servidor normaliza la notacion para que un mismo instante produzca el mismo hash. Se rechaza cualquier momento posterior al del registro, y cuando ambos estan proximos se anade saldo en el punto de confirmacion.

Impacto en la tarifa: Declarar el momento de la decision y registrarlo poco despues genera saldo. La ventana y el importe son provisionales.

2026-08-23 - La forma de la declaracion la decide la ruta

Una declaracion que implicaba a una contraparte podia crearse sin ella, mientras que las rutas que si la tenian sobrescribian en silencio el valor enviado por el cliente. El valor enviado y el registrado diferian, y nada en la respuesta lo indicaba. Cada ruta acepta ahora una unica forma de declaracion.

2026-08-23 - Un valor que el codigo usaba pero no figuraba en la lista

Dos tipos de transaccion del libro de saldos existian en el codigo pero no en la lista de la base de datos, de modo que alcanzarlos habria revertido la transaccion entera. No se habia manifestado solo porque todavia nadie tiene ese saldo. Se trata de eliminar un defecto latente, no de anadir una funcion.

2026-08-21 — Una factura que no podía cumplirse

Las rutas de pago exigían el pago sin decir que una firma por sí sola no completa la solicitud. La comprobación de identidad está detrás de la puerta de pago: quien llegaba de forma anónima, recibía la exigencia, firmaba y volvía, terminaba igualmente en la autenticación. Un cliente repitió ese trayecto tres veces y se marchó. El cuerpo de la respuesta lleva ahora el paso de identidad previo y la ruta de registro.

• Cada ruta indica además si le aplica el saldo de prueba o el saldo acumulado. Otro solicitante con saldo de prueba había recibido una exigencia de pago en una ruta no cubierta.
• No salió ningún fondo. Pero no fuimos nosotros quienes lo impedimos: la biblioteca de pago omite la liquidación ante cualquier respuesta de error.

2026-08-20 — Donde no había ninguna indicación

En dos rutas, la falta de un campo obligatorio terminaba en error del servidor. Quien llamaba no podía saber qué había omitido, y un problema de entrada del cliente quedaba registrado como fallo del servidor. Tres de las cuatro rutas de la misma familia ya lo señalaban mediante un rechazo; solo estas dos quedaron fuera. Se detectó al recorrer todas las superficies de principio a fin en una sola pasada.

2026-08-20 — La capa de observación se leía al revés

Un agente externo leyó únicamente nuestras superficies y describió la capa de observación como «una capa de análisis inteligente que emite veredictos». La definición canónica dice exactamente lo contrario. La especificación detallada ya contenía la formulación de no juicio; era la única línea a la que el agente llega realmente la que apuntaba en sentido opuesto. Cambiamos la palabra y añadimos una frase negativa en esa misma línea.

• «Generar» resultaba tan peligroso como «analítica». Aquí se saca a la vista lo ya registrado, no se produce algo nuevo.

2026-08-20 — Una tienda de aplicaciones y una sala de espera

El mismo agente leyó la capa de distribución de herramientas como «una tienda de aplicaciones para agentes» y el estado inactivo como «una sala de espera sin coste». La definición canónica niega ambas cosas de forma explícita. La causa fue una línea comprimida en la guía breve; el texto de sustitución se condensó a partir de la especificación existente, sin inventar nada.

• La descripción de una herramienta enunciaba la función de la vecina: dos herramientas afirmaban hacer lo mismo dentro de una sola respuesta.
• No se escribió nada sobre el coste de la permanencia. El modo por omisión es actualmente gratuito, de modo que escribirlo habría sido falso.

2026-08-20 — Morir al recibir la lista de herramientas

Cuarenta y un caracteres presentes en la respuesta mataban a los clientes de codificación heredada justo al recibir la lista de herramientas. No es una lectura errónea: la conexión no llega a establecerse. El archivo de entrada para rastreadores y el de contacto de seguridad del mismo servidor estaban bloqueados igual, y nunca habían entrado en ninguna medición.

• La verificación ya no cuenta caracteres: mide si los octetos que salen pueden leerse.
• El texto estático sigue sirviendo octetos antiguos desde la caché hasta cuatro horas después de un reinicio.

2026-08-20 — Un aviso de rechazo que no podía leerse

Un cliente con un testigo válido recibió seis rechazos y se marchó a los sesenta y tres segundos. Entretanto releyó dos veces el contrato público: la intención de cumplir y la referencia a la fuente canónica estaban ahí, y no pasó ni una sola vez. Ese aviso moría bajo las codificaciones heredadas.

• La verificación anterior nombraba ocho archivos y solo miraba dentro de ellos, y esos ocho ya estaban limpios. La lista se sustituyó por un barrido completo.
• Queda una clase: los valores guardados en la base de datos que salen en una respuesta no son visibles para ningún análisis del código fuente.

2026-08-19 — Caracteres que matan a quien lee

Un agente local que funcionaba en un entorno de codificación heredada falló ocho veces seguidas al intentar alcanzar nuestras superficies. Estos caracteres no distorsionan el texto: matan el proceso que lo lee. El punto más doloroso era la indicación del 401, la frase que un cliente bloqueado necesita leer para desbloquearse. Las superficies de indicación, de error, de descubrimiento y de especificación se abrieron en cuatro rondas.

• El archivo que un rastreador recupera primero estaba bloqueado por un solo carácter. Morir ahí significa que la ruta de descubrimiento ni siquiera empieza.
• Juzgar por rango de puntos de código es erróneo. Estrellas y flechas parecen emojis, pero existen en las páginas de códigos heredadas.
• Las superficies dirigidas a personas no pueden abrirse. Aun retirando todos los caracteres implicados, quedan las etiquetas del selector de idioma y la razón social. Es una propiedad de un sitio multilingüe, no un defecto.

2026-08-17 — Una indicación que obligaba a un viaje de 172 KB

La respuesta de registro describía el procedimiento del primer asiento remitiendo a la especificación completa de 172 KB. Todo lo necesario estaba ya en una guía de 2,5 KB a la que nada apuntaba. El tráfico de un cliente lo mostró: especificación doce veces, guía cero. Cambiamos el destino y, deliberadamente, no citamos la especificación al lado.

• Siete indicaciones que los agentes leen directamente estaban en coreano. Una de ellas es justamente donde aterriza un agente al que ha fallado la concesión de prueba.

2026-08-17 — No había modo de saber qué rutas cubre la prueba

Un cliente con saldo de prueba recibió un cargo en una ruta no cubierta. Consultó el estado de la prueba cuatro veces y solo obtuvo el saldo; la respuesta apareció después de la exigencia. La tabla que contenía esa respuesta estaba dentro del intermediario de pago, de modo que leer un valor obligaba a levantar toda la pila de pago. Se extrajo la tabla y la respuesta incluye ahora la lista de rutas aplicables.

2026-08-17 — Se actúa según la primera línea

Un problema de formato de cabecera y un fallo de búsqueda del testigo compartían la misma indicación de 401, y esa indicación situaba el nuevo registro en el primer campo. Resultado observado: un cliente que recibió un 401 por formato de cabecera se registró dos veces más en lugar de corregir la cabecera. Se creó una rama específica que coloca el formato de presentación al principio y el registro al final.

• El registro no se eliminó. A esta rama también llegan solicitantes que nunca se han registrado, y para ellos sigue siendo la respuesta.

2026-08-17 — Nuestras propias superficies se contradecían

El esquema de autenticación de la especificación se mantenía desde la primera versión en una forma que significa «el valor de la cabecera es la credencial misma». El hecho de que se requiera un prefijo vivía solo en la prosa, y las máquinas no leen prosa. La tarjeta de agente ya declaraba la forma correcta: no se introdujo un formato nuevo, se alineó el que se había quedado atrás.

2026-08-17 — Si la fuente envejece, sus derivados envejecen con ella

Corregimos un texto de respuesta y cuatro documentos que lo citan seguían con la redacción antigua. La comprobación de sincronía no señalaba desviación alguna: los derivados estaban desfasados porque lo estaba la fuente. Corregir una copia a mano habría devuelto el texto antiguo en la siguiente sincronización.

• Lo que faltaba era una comprobación en el eje donde el código y la documentación discrepan. La comprobación de sincronía solo compara la fuente con sus derivados.

2026-08-17 — Ejemplos que fallaban si se seguían

Ejecutamos los ejemplos públicos de verdad por primera vez. Dos de cuatro no funcionaban: el más próximo al relato del anclaje importaba un paquete no publicado y moría en su primera línea, y las instrucciones de instalación decían lo mismo. Los ejemplos de los borradores del blog eran rechazados en cada intento tal como estaban escritos.

• Al borrar dos borradores no publicados desaparecieron de golpe las cinco desviaciones de vocabulario.
• Un ciclo antes habíamos editado ese mismo archivo sin ver un error de valor. Las pruebas de regresión ejecutan ahora los ejemplos realmente.

2026-08-16 — Lo declarado y lo hecho diferían

Las declaraciones enumeraban valores permitidos mientras el código no validaba ninguno, de modo que se almacenaban cadenas arbitrarias o la petición acababa en error del servidor. La respuesta y el libro registraban valores distintos de modo de pago. Un campo declarado obligatorio en la especificación nunca se leía, y así un cliente que respetaba el contrato obtenía en silencio un resultado erróneo.

• Una consulta perteneciente al servicio gratuito de referencia de registros se estaba cobrando sin estar siquiera definida como tipo de observación. Ahora es gratuita.
• La puerta no se retiró. Que una puerta sepa que algo es gratuito y lo deje pasar no equivale a no tener puerta.

2026-08-16 — Puntos de terminación reales ausentes del contrato

Dos rutas de suscripción estaban vivas y nuestras propias pruebas las usaban, pero no figuraban en ningún lugar del contrato público: no existía vía de acceso externa. La capacidad no faltaba; nunca se había enunciado. Una de las respuestas solo surge en condiciones de concurrencia y no puede producirse mediante una llamada, así que la declaración indica que se determinó leyendo el código.

2026-08-16 — Un valor configurado debe ser a la vez el anuncio y el cargo

Un tope sobre el multiplicador de precio estaba fijado en el código y anulaba el ajuste de explotación. Sin embargo, el contrato público ya afirmaba en tres lugares que el multiplicador cobrado es igual al valor configurado. Medido antes de tocar nada: subir el ajuste un 33 % no movía el total en absoluto. Ajustar los documentos al código habría cambiado una falsedad por otra, así que cambiamos el código.

• Retirar un tope implica que un valor anómalo se multiplica sin freno. Se colocaron límites inferiores tanto en el código como en la base de datos.
• Sin cambios en las tarifas actuales. Los valores solo se moverán cuando el operador configure por encima del tope anterior.

2026-08-16 — Un interruptor que no hace nada al activarlo

El cuerpo del barrido de extinción existe, pero nada lo invoca. Mientras tanto, la pantalla tiene un botón de activación y, al pulsarlo, el indicador pasa a «activo». El campo de última ejecución de esa misma ficha permanece en «nunca», de forma indefinida. Decidimos no conectarlo: es una automatización de sentido irreversible y jamás se ha observado nada sobre el conjunto de candidatos. En su lugar, seis puntos dicen ahora lo mismo.

2026-08-15 — Las herramientas de verificación fabricaron un semáforo verde

Un guion de arranque mantenía vivo un proceso antiguo, de modo que la regresión se ejecutaba contra código obsoleto y daba verde. Era un bucle que se reforzaba a sí mismo y salió a la luz por casualidad. Un día después apareció otro de la misma familia: cuando la regresión se interrumpía a mitad, seguía informando de cero fallos y salía con código normal.

• La reparación no amplió lo que se termina. Un guion que empieza a matar procesos que no ha lanzado es en sí mismo la semilla de un incidente mayor.
• Confiar en una regresión exige tres cosas a la vez: que las aserciones miren lo correcto, que recorran la ruta real y que golpeen el código de hoy.

2026-08-15 — Las reservas quedaban fuera del cálculo del tope

La fórmula del tope de gasto está escrita de forma explícita en el modelo, y nueve puntos del lado de lectura la calculaban sin las reservas. Una sesión llegó a abrirse con el tope íntegramente consumido por reservas: medido, no deducido.

• El noveno punto apareció durante la propia corrección. Arreglar solo uno habría dejado que dos puntos de terminación informaran de saldos restantes distintos ante la misma pregunta.

2026-08-15 — Los fallos de reparto quedaban como impago permanente

El reparto de ingresos por venta de herramientas registra un estado de fallo, y nada leía ese estado para recuperarse. La compra quedaba confirmada mientras la regalía del vendedor no salía nunca. Los barridos de recuperación son una práctica ya establecida aquí; este era el único lugar sin uno.

• Un fallo de reparto posterior a la confirmación de la compra devolvía un error del servidor, de modo que el comprador reintentaba una compra que ya había tenido éxito. El hecho de la compra y el del reparto son distintos.

2026-08-15 — Una ruta de observación de pago sin puerta de cobro

Descontaba saldo mientras omitía por completo el pago previo, la limitación de frecuencia y el tope de gasto. El contador ni siquiera llegaba a crearse, de modo que era ilimitada en la práctica. El comentario de la ruta decía «gratuita».

• La regresión afirmaba este defecto como comportamiento correcto. Dos líneas consecutivas del mismo paso, una sola observación de pago sin cobrar, y corregirla rompía la batería de pruebas.

2026-08-15 — El servicio arrancaba con normalidad con los pagos desactivados

Un fallo de inicialización absorbido por el manejo de excepciones dejaba una línea de registro y levantaba todas las rutas de pago sin cobro. Otra vía de fallo del mismo archivo ya se negaba a arrancar: dos vías de fallo en direcciones opuestas dentro de un archivo. Ahora se niega.

• La redacción del registro fundía dos causas y ocultaba la diferencia. «Apagado» y «averiado» no son lo mismo.

2026-08-15 — Podían llegar valores no numéricos a un importe

Un periodo sin validar convertía el coste en un valor no numérico, que la comprobación de tope transformaba en cero y dejaba pasar como petición sin cargo. La defensa real era un error de tipo posterior que revertía la transacción, no la validación. Todas las columnas monetarias excluyen ahora ese valor de forma explícita: la restricción de no negatividad existente lo dejaba pasar.

2026-08-15 — Un cobro veintiuna veces inferior, cero líneas de registro

Los calculadores de precio absorbían cada uno sus fallos y devolvían vacío, y el intermediario sustituía por el precio mínimo. La sustitución en sí es una decisión de disponibilidad y se mantuvo; solo se corrigió el silencio.

• Decidir dónde no registrar importaba más. Registrar también los retornos deliberados habría sepultado los fallos reales bajo el tráfico de los rastreadores.

2026-08-15 — El mecanismo que daba seguridad a los reintentos provocaba reintentos

Peticiones duplicadas concurrentes que vulneraban la clave de idempotencia devolvían un error del servidor. El agente que lo recibía lo interpretaba como una caída, reintentaba y volvía a caer en la misma ventana. Los datos nunca se dañaron: lo único erróneo era la respuesta, de ahí que el remedio fuera mínimo.

• El mismo día cerramos un cambio de periodo que sobrescribía el consumo: una petición tardía podía devolver a cero el gasto acumulado entretanto.

2026-08-15 — La caducidad del saldo acumulado no se ejecutaba en el código

La especificación establece que el saldo acumulado caduca, y nada restaba del saldo los lotes caducados. Además, el descuento retiraba también importes que el libro no podía cubrir. Lo primero creaba la divergencia; lo segundo la rellenaba en silencio para que nunca se viera. El peso de este defecto no está en la exactitud contable sino en la distancia entre lo que declaramos y lo que hacemos.

• El periodo de validez es de un año, así que se manifiesta un año después de la primera acumulación. Este es el momento más barato para corregirlo.

2026-08-15 — El único componente sin transiciones protegidas

Solo el componente de suscripción carecía de modelo propio, de modo que los cambios de estado estaban dispersos y nunca heredaron el patrón de protección de esta base de código. El defecto no eran once lugares, sino un único punto de herencia ausente.

• Las protecciones se separaron por naturaleza: las transiciones que convergen en el mismo resultado no lanzan nada; las que no deben sobrescribirse, sí.
• Un barrido se detenía por completo ante un solo fallo. La dirección del fallo era «dar de más», de modo que la pérdida se acumula con el tiempo.

2026-08-15 — Tres defectos de coherencia

• La idempotencia del acuerdo bilateral ignoraba el cuerpo de la petición: el mismo identificador con una propuesta distinta devolvía el acuerdo antiguo en lugar de un rechazo. Un acuerdo fija la frontera de responsabilidad entre dos agentes, lo que encarece especialmente esta respuesta.
• El nombre de un procesador de pagos que no usamos sobrevivía en algunos registros: no pasamos por él. En cuanto una agregación lea esa columna, un pago acabará en dos categorías.
• Los rangos de consulta se recortaban en silencio: las peticiones que exceden el periodo de conservación gratuito devolvían solo esa parte, sin que la respuesta lo dijera, de modo que quien llamaba lo leía como «no hubo actividad en ese periodo».

Seis tablas paralelas indexadas por ruta no tenían ninguna aserción de que debieran coincidir. Una discrepancia impide ahora el arranque.

2026-08-15 — Nada mantenía bajo el volumen

Los comentarios de los adaptadores se apoyaban en «el volumen es bajo, así que no pasa nada», y nada mantenía bajo ese volumen. Se establecieron a la vez la limitación de frecuencia, un límite de longitud para los envíos anónimos y la rotación y conservación de los archivos de registro. El valor de conservación no es una política nueva: prolonga el que la base de datos ya aplicaba.

• El detector de datos personales se amplió solo después de fijar la frontera de los falsos positivos. Los formatos de identificadores de otros países no se añadieron: los patrones amplios cuestan más en falsos positivos de lo que aportan en detección.

2026-08-15 — Un documento de disciplina interna estaba en un repositorio público

La fuente canónica de la disciplina de vocabulario se servía literalmente desde un repositorio público, con rutas internas, una lista de pendientes y la estrategia de presentación externa. Retirar las referencias internas no lo cerraba: esos números de referencia son el índice mismo del documento. Lo trasladamos.

• No se reescribió el historial. Lo que contiene es descripción interna, no credenciales, y el objetivo es cortar la exposición futura, no borrar el pasado.

2026-08-14 — Una clave de idempotencia fija en el catálogo público

El ejemplo de exigencia de pago llevaba un identificador fijo, y quedó inscrito tal cual en el catálogo público de liquidaciones. Todo el que copiara el ejemplo compartiría una única clave de idempotencia. El alcance se limitó a esa clave: es el único punto donde una colisión importa.

Desde este momento se llevó a cabo la primera revisión sistemática del código (64 918 líneas en 250 archivos). Las entradas del 15 y el 16 de agosto son su producto.

2026-08-13 — Nombres de normativas y vocabulario de cumplimiento en las interfaces

Los sitios de interfaz planteaban el problema nombrando la normativa de una jurisdicción concreta, y dos ediciones lingüísticas conservaban «cumplimiento». El encuadre normativo se sustituyó por una descripción general de la situación (el argumento no cambia) y el vocabulario se realineó hacia la responsabilidad.

2026-08-12 — Treinta y cuatro entradas sin descripción

Solo dos de treinta y seis eran correctas. Treinta eran cadenas vacías, tres habían heredado el texto de otro idioma y una estaba desfasada. Los títulos tienen comprobación obligatoria y las descripciones no, de modo que los valores vacíos se escribían tal cual. El texto nuevo se ajustó al vocabulario del cuerpo de cada entrada.

• En esta superficie comprimida se omitió la glosa entre paréntesis. Su propósito ya lo cumple la primera aparición en el cuerpo del texto.

2026-08-12 — El motor de publicación revertía las URL y los códigos de idioma

Los valores corregidos a mano volvían a los predeterminados en cada republicación. El comentario decía «sin barra final, para evitar una redirección», cuando en un recurso de tipo directorio es precisamente la ausencia de barra lo que crea la redirección: intención y efecto invertidos. También se corrigió un campo de idioma que servía a tres propósitos distintos y divergía de las demás superficies.

2026-08-12 — Asimetría en la fecha de actualización de los índices

La fecha de modificación del índice no se movía cuando cambiaba el listado. Al publicar, el mapa del sitio solo se tocaba para la URL de la entrada y para un índice recién creado, de modo que el caso habitual quedaba fuera. Retirar una entrada presentaba la misma asimetría y se trató a la vez. De paso se añadieron resúmenes por entrada al índice: la rutina que compone el listado ya analizaba la descripción y la descartaba.

2026-08-12 — Escritura de los términos conceptuales por idioma

El mismo concepto se escribía de forma distinta dentro de un solo idioma. Un idioma no tenía ninguna glosa del término original, y la frase que separa a quien registra de quien actúa faltaba en los metadatos de cuatro idiomas. Se armonizaron las páginas de inicio y treinta y seis entradas, y se estableció como canónica una tabla de seis conceptos por seis idiomas.

2026-08-11 — Una capa que no está en pantalla no se lee

Leer solo la página de inicio dejaba fuera del juicio la existencia de los recursos subyacentes. La causa no era el texto sino el alcance. Los datos estructurados que añadimos no llegaban en absoluto a la vía conversacional: esos recuperadores extraen el texto del cuerpo y descartan los bloques de guion. Se colocó una línea de descripción en cada fila de la sección de acceso.

• Es una indicación, no una llamada a la acción. «Aquí está esto» y no «haga esto», de modo que no toca el bloqueo del núcleo.
• Las interfaces existían en dos idiomas y cuatro ediciones ni siquiera tenían esa sección. Se completó tras la ampliación a seis idiomas.

2026-08-11 — El espejo raíz iba veinte días por detrás

El breve documento de indicación del dominio raíz iba veinte días por detrás de su fuente, y lo pendiente incluía todas las correcciones de vocabulario y la retirada de nombres de normativas. No hay constancia de una divergencia intencionada: el espejo no figuraba en la lista de comprobación de ningún procedimiento de coherencia.

2026-08-10 — Los nombres de normativas no van en posición de objeto

«Estructurado para» es vocabulario canónico y se mantiene. Lo incorrecto era colocar un artículo normativo concreto en su posición de objeto. Las obligaciones correspondientes se han aplazado, y la razón declarada es la ausencia de una norma de conformidad; los obligados por ese artículo son los proveedores y los implantadores de sistemas, no nosotros. Además, los repositorios públicos y las recopilaciones posteriores son difíciles de actualizar.

2026-08-09 — Los resúmenes posteriores toman nuestra redacción como material

Una descripción generada automáticamente en un catálogo externo contenía vocabulario que nunca hemos empleado, y una valoración en otro sitio citaba literalmente nuestra descripción de herramienta. Lo que hay que controlar no son solo las palabras que usamos, sino lo que un resumen posterior puede construir a partir de nuestra redacción. Se eliminó la fórmula «no prueba: prueba».

• Una expresión se corrigió en mayo y volvió. Entonces el objetivo fue una copia, y la fuente sin corregir refluyó por encima de ella.

2026-08-09 — Incluir el siguiente paso en el 401

El cuerpo del 401 llevaba solo un código de error y un mensaje, de modo que quien llamaba no podía deducir de la respuesta qué hacer. La superficie de herramientas ya ofrecía indicación, así que ambas superficies se contradecían. La situación se divide en cinco casos y no se copió una misma redacción para todos.

• Los ocho puntos de autenticación de propietario quedaron intactos. Dirigir a un propietario al registro de agentes es señalarle la vía equivocada.

2026-08-09 — Donde el contrato callaba

Clientes guiados por la especificación erraron una y otra vez en rutas que anunciaban una cosa y devolvían otra (cuatro intentos hasta el primer acierto). Se declararon las exigencias de pago de la observación de pago, los rechazos tras una función desactivada y las respuestas de denegación. El texto de la función desactivada indica que la ruta existe y el indicador está apagado, que es lo que la distingue de un 404.

2026-08-09 — Había que pagar para saber que la petición era incorrecta

La propuesta de acuerdo bilateral queda fuera de la prueba, así que la única vía hacia la validación era el pago. Un cuerpo vacío o señalarse a uno mismo como contraparte atraía primero una exigencia de pago, y el rechazo solo llegaba tras firmar y reintentar. La validación previa se movió delante de la puerta.

• Las peticiones anónimas se dejaron como estaban. La primera implementación también las filtraba y rompió la regresión: las peticiones anónimas son el canal por el que los indexadores externos recogen la exigencia de pago.

2026-08-09 — Un fallo de regresión arrastrado durante cuatro meses

Once fallos etiquetados como «no implementado» tenían otra causa: una sola línea de configuración de pruebas. Implementación y aserción llegaron en la misma confirmación, sin ningún cambio relacionado entre medias. No es algo que se quedara obsoleto: la razón se consignó mal desde el origen y después se citó sin examen en veintidós lugares.

• El total se actualizó varias veces mientras las razones se arrastraban intactas. La norma ahora es que cero fallos es lo normal.

2026-08-07 — El canal por el que desaparecían los registros de uso

Los registros de uso se escribían por lotes completos y, si fallaban, volvían íntegros a la cola. Un solo registro que vulnerara una restricción bloqueaba todos los siguientes hasta el reinicio. Ocurrió en producción, una vez durante unas veintiuna horas. Las entradas perdidas existían solo en memoria y los registros conservaron únicamente un recuento: son irrecuperables.

• El registrador de tráfico contiguo ya había reconocido y corregido el mismo problema; la capa de registro nunca recibió el mismo trato. Es el orden inverso al de la importancia.
• Los fallos de lote se dividen ahora registro a registro, con lo que termina el bloqueo total. Las violaciones de restricción se descartan con su motivo y los errores transitorios se devuelven a la cola.

2026-08-07 — Registros de prueba bloqueados por la ventana de pago

Los registros cubiertos por la prueba nunca toman una reserva, y el barrido de caducidad no miraba la fuente de pago: les colocaba la etiqueta «reserva liberada», y la confirmación rechazaba basándose en esa etiqueta. Todo registro de prueba con más de treinta minutos quedaba inconfirmable para siempre. Un agente externo ya lo había encontrado diez días antes y nadie lo supo.

• La ventana existía y nada la anunciaba. Primero se documentó y después se corrigió el mecanismo.
• Con solo el barrido corregido, la confirmación seguía rechazando: lo detectó la medición. La comprobación de ventana estaba duplicada en dos lugares.
• Los cinco registros afectados no se corrigieron con efecto retroactivo. Un entorno que trata registros de solo adición no debería tratar así los suyos.

2026-08-07 — No es un problema de vocabulario sino de hecho

De ocho usos de «permanente», solo uno omitía su condición. Se trata de exactitud contractual, no de vocabulario: la palabra no está prohibida y es cierta para el nivel ilimitado mientras dure la suscripción. Pero ese nivel está desactivado en este momento, de modo que hoy no es cierta en ningún contexto. La condición para revisarlo se consignó al mismo tiempo.

2026-08-06 — El catálogo no se actualiza

Ocho días de observación confirmaron que el catálogo de liquidaciones se congela en la declaración vigente en la primera liquidación y no se actualiza tras un reinicio. Si se cambia el destinatario, el catálogo seguirá anunciando la dirección antigua. Si un pago posterior lo actualiza sigue siendo desconocido, y no afirmamos lo contrario.

2026-08-06 — La redacción que enviamos al exterior

La descripción de un directorio externo empezaba con vocabulario que evitamos. Era nuestro propio texto de abril, copiado allí por un rastreador. La armonización de vocabulario anterior había revisado solo las superficies que servimos; los envíos y las descripciones de alta no estaban en la lista. Un original se había convertido en cuatro, y uno de ellos queda fijado de forma permanente porque el repositorio fue archivado.

• Las versiones antiguas del registro pueden editarse y decidimos no hacerlo. Las versiones antiguas son historia, y un entorno que trata registros de solo adición no debería revisar la suya.

2026-08-05 — Un identificador fijo en el ejemplo público

El ejemplo de creación de un asiento llevaba una clave de idempotencia fija, y la búsqueda se apoyaba solo en esa clave sin considerar al propietario. Desde el segundo solicitante que copiaba el documento, llegaba una respuesta de éxito sin que se registrara nada. Cambiar solo el valor no lo cerraba: el campo no tenía ninguna descripción, y el ejemplo fijo junto con la ausencia de indicación formaban en conjunto la condición.

2026-08-05 — Retirada de la idempotencia en el registro

La caché de idempotencia del registro guardaba la respuesta literalmente, de modo que un tercero que enviara la misma clave recibía las credenciales del primer registrado. Era el único lugar del sistema que conservaba credenciales en claro. Registro anónimo, seguridad ante reintentos y transmisión de un secreto no pueden sostenerse a la vez; se renunció a la seguridad ante reintentos. La función no se había activado ni una sola vez desde su introducción: ninguna pérdida observable.

• Una premisa que no se escribe no se cumple. Este diseño se apoyaba en tratar esa clave como un secreto, y eso no constaba en ninguna parte, mientras que la especificación llevaba un valor de ejemplo fijo.
• El periodo de validez filtraba las lecturas sin borrar nada. Las lecturas seguían siendo correctas, así que nadie se dio cuenta.

2026-08-02 — Un proceso que registraba éxito y moría

Dos procesos se disputaban el mismo puerto y el perdedor imprimía «en servicio» antes de morir en silencio. Leyendo los registros, ambos parecían haber arrancado con normalidad. El mecanismo consistía en que el entorno de trabajo registra también el último argumento de retorno como receptor de errores.

• Corregir el silencio produce ruido en algunos lugares. Cambiar solo el código de salida lo habría trocado por un bucle de reinicios sin fin; se fijó a la vez un límite de arranque.
• Los demás servicios no comparten esa forma y no se tocaron. «No hay manejador» no es automáticamente un defecto.

2026-08-02 — Referencias internas que quedaban en el contrato

Veintiocho referencias del contrato público resultaban indescifrables sin los documentos internos. No todas podían retirarse de forma mecánica: donde una referencia servía de fundamento a una frase, borrarla elimina el porqué. Esas se reescribieron sin la referencia, o se retiraron tras comprobar que el mismo fundamento ya aparecía en un campo contiguo.

2026-07

2026-07-31 — Cabecera de reintento del SDK

El SDK documentaba la cabecera de reintento con un nombre que el servidor no lee al extraer el contenido. La comprobación que decide si una ruta exige pago acepta ambos nombres; el paso que extrae realmente el contenido acepta solo uno. Seguir el nombre documentado devolvía otra vez una respuesta de pago requerido. Una nota anterior decía aquí «se aceptan ambos nombres, así que es inofensivo» — confundía la comprobación con la extracción. Corregida; el texto original se mantiene.

• La guía dirigida a los agentes no incluía procedimiento de reintento alguno. Añadido.

2026-07-31 — Un hueco en los registros de liquidación

Encontrado solo después de construir un cliente de pago y pagar de verdad. La batería de regresión nunca había recorrido esta ruta: seis rutas no tenían ninguna aserción, y las tres que sí la tenían solo preguntaban si existía alguna fila, de modo que seguían en verde gracias a filas de una ejecución antigua. Las aserciones ahora miran únicamente lo que ha producido la ejecución en curso. Tres rutas añadidas.

• En registros de solo adición, preguntar si existe una fila pasa para siempre tras el primer acierto.

2026-07-31 — Lo que el catálogo conservará

Un catálogo de liquidación inscribe un servicio la primera vez que se liquida un pago, y la declaración vigente en ese instante pasa a ser su metadato. No hay confirmación de que se refresque después: lo tratamos como algo sin vuelta atrás y completamos los ejemplos de respuesta de las ocho rutas de pago antes del primer cobro.

2026-07-31 — Ficha del registro actualizada

La ficha publicada llevaba 48 días de retraso. El archivo estaba al día desde hacía tres semanas, pero publicar es un acto aparte y ese paso queda fuera de la fuente única de versión. Republicada. Todavía nada detecta la brecha — queda abierta y anotada.

2026-07-31 — Un fallo que parecía cualquier otro fallo

El agotamiento del pool de conexiones aparecía bajo el mismo código de error interno genérico que todo lo demás y no podía distinguirse sin abrir los registros. Ahora tiene código propio. Esto va antes de estrechar el tope del pool: estrecharlo aumenta la frecuencia con que se alcanza esa ruta, y esa ruta era invisible.

2026-07-30 — Límite de peticiones

El límite global de peticiones nunca había funcionado. La clave que agrupa las peticiones estaba mal construida: cada petición caía en un compartimento nuevo y el tope resultaba estructuralmente inalcanzable. Las cabeceras que anuncian el presupuesto restante salían desde siempre con un valor que no se movía. Tres puntos de nuestra propia documentación contaban este límite como una defensa — esas descripciones también quedan corregidas.

Antes de activarlo medimos qué quedaría atrapado. Solo escáneres habían superado el tope; el minuto más cargado de llamadas legítimas se quedaba por debajo de la mitad. Los documentos de descubrimiento se sirven antes del limitador y no consumen presupuesto.

• El número de la cabecera ahora baja de verdad. La información de presupuesto llega de forma útil a quien llama por primera vez.

2026-07-29 — El pago se anunciaba distinto en cada reintento

Una petición repetida volvía con un bloque de pago distinto cada vez. El cobro de una decisión se guarda en más de una fila y, según cuál se leyera, la respuesta decía que no hacía falta pagar o pedía un importe que no coincidía con el total. Ahora queda fijado a lo que dijo la primera respuesta. Si esa referencia es el importe correcto es otra cuestión, no tratada aquí.

• Una nota anterior señalaba los lugares equivocados. Ambos tenían delante una segunda línea de defensa. Corregida y conservada.

2026-07-29 — Conservación: eje y sobrecapa

Veníamos describiendo la conservación como una escalera de cinco peldaños. No lo es: tres valores están sobre el eje, los otros dos son sobrecapas colocadas encima. Poner en una misma línea niveles distintos hacía que «diez años cuestan menos que cinco» pareciera una inversión, cuando el multiplicador solo lee condiciones del eje y el resultado se sigue de la definición. Leímos mal nuestro propio diseño dos veces. Corregido en el documento de referencia dirigido a los agentes y en la respuesta.

• Texto interno en coreano circulaba desde hacía meses en las respuestas de pago requerido, y un directorio externo lo republicó tal cual. Depurado.
• Una ruta tenía camino activo y cobro activo, pero el contrato vacío. Declarada.

2026-07-29 — Estimación y cobro

Las estimaciones de los preajustes se calculaban con argumentos distintos a los del cobro real. El eje implicado está desactivado: ambos daban cero y coincidían por accidente; activarlo los habría separado. Alineado antes de que se accione ese interruptor — con esta publicación no cambia ningún importe.

• Los preajustes llevaban una etiqueta de nivel sin decir que ese eje hoy no supone coste. Ahora se indica junto a ella.

2026-07-29 — Rutas de descubrimiento en el host MCP

Seis rutas de descubrimiento estándar devolvían 404 en el host MCP. Ahora sirven un puntero. La tarjeta firmada no se copia: las peticiones convergen en el ejemplar de referencia, porque una copia se desajusta de su firma en la siguiente actualización.

2026-07-28 — Consulta del estado de pago

El cobro de una decisión se guarda en más de una fila — tarifa base y recargo por separado. La consulta devolvía una de ellas, y cuál no estaba determinado. Tampoco había manera de ver el total. Ahora devuelve todas las filas con un total sumado y agrega el estado de forma conservadora: liquidado solo cuando lo están todas.

• La marca de tiempo de creación que servía para ordenar no podía ordenarlas: ambas filas se escriben en una misma transacción y llevan la misma hora. Esto solo se ve con datos reales.

2026-07-28 — Reproducir el precio a partir del contrato publicado

El contrato publicado no bastaba para calcular lo que se iba a cobrar realmente.

• El multiplicador valía estructuralmente siempre 1 — dividía el total entre la suma de sus propios componentes. Un cobro con 1,5 aplicado se comunicaba como 1.
• Las condiciones que disparan el multiplicador se enumeraban sin el umbral. «Dos o más» no aparecía en ninguna parte.
• Un nivel de conservación elegible ahora mismo, sin otra barrera ni suscripción, faltaba en la tabla de precios.

Los importes cobrados eran correctos; lo que fallaba era lo que se informaba. Anunciar un valor equivocado es peor que omitirlo: el cálculo inverso ha desaparecido y la decisión vive ahora en un solo sitio. Ningún importe ha cambiado.

2026-07-26 — Superficie de descubrimiento de los subsitios

Dos subsitios respondían 200 con la página de inicio a direcciones que no existen. Para un rastreador, todas las direcciones existían y todas tenían el mismo contenido. Añadidos página de ausencia, reglas de rastreo, listado de direcciones y declaraciones de idioma.

2026-07-26 — Declarar las rutas de pago, y las peticiones vacías

La especificación no decía en ningún sitio, de forma legible por una máquina, qué rutas son de pago. Solo lo mencionaba la prosa: quien leía únicamente la especificación veía cero rutas de pago. Siete rutas declaran ya la respuesta de pago requerido. El importe y el destinatario no se incluyen: varían en cada petición y escribirlos los vuelve falsos en el mismo momento en que se escriben. La respuesta en vivo es la de referencia.

• Una petición sin cuerpo producía un error de servidor. Ahora devuelve un rechazo que dice qué falta.

2026-07-26 — Una salida de sesión

Se podía abrir una sesión, pero no cerrarla. Con una sola apertura uno quedaba atrapado tras un error de sesión duplicada. Un tipo acaba liberándose con un barrido de expiración; el otro no tenía salida alguna. Cinco operaciones añadidas — cierre, estado y ejecución de prueba.

• Una entrada anunciada como gratuita era en realidad siempre de pago. Etiqueta corregida. El resto coincidía tras una comparación exhaustiva.

2026-07-26 — El pago llega al servidor

El punto ciego anotado hace dos días queda cerrado. El adaptador transmite la firma de pago sin tocarla. El adaptador no firma: sostener la clave de quien llama equivaldría a custodiar fondos ajenos. Llama a una herramienta de pago sin pagar y la respuesta trae el paso siguiente; firma, vuelve a llamar con los mismos argumentos y continúa.

Las llamadas al servidor pasan ahora por un único camino. El mismo defecto había vuelto ocho veces porque el contrato se reescribía una vez por herramienta.

• Corregidos dos nombres de campo discordantes. En uno de ellos, el valor que indicabas se descartaba sin aviso.
• Sin información de pago, la petición es byte a byte la de antes. Rutas gratuitas sin cambios.

2026-07-24 — Discrepancia del contrato del adaptador y punto ciego del pago

El registro de herramientas a través de A2A no había funcionado ni una sola vez. Los nombres de campo que enviaba el adaptador no coincidían con lo que lee el servidor, y un elemento obligatorio no se enviaba en absoluto. El mismo mal se había corregido antes en el otro adaptador, pero entonces sólo se cotejó uno de los dos contra el servidor.

Corregido cotejando directamente contra el contrato del servidor. No se duplicó la copia del otro adaptador: copiar una copia es justamente lo que produjo este defecto.

El cotejo completo hizo aflorar algo mayor. Los adaptadores no reenvían la información de pago al servidor. Sólo hacen pasar el testigo de autenticación. Por tanto, toda ruta de pago termina en la exigencia de pago siempre que se llegue a ella por un adaptador.

• La discrepancia de nombres de campo en la compra de herramientas estaba doblemente oculta tras ese muro. Corregir sólo los nombres no la haría funcionar
• La creación de sesión inactiva ignora en silencio la elección del medio de pago y siempre se resuelve como gratuita

No hay fallos duros alcanzables. El resto ni siquiera puede verificarse mientras no se resuelva antes el reenvío del pago. El punto ciego queda consignado y abierto.

Una investigación anterior consignó esto como «un fallo 400 por discrepancia de nombres de campo». Fue una clasificación errónea extraída sólo de leer el código; la medición mostró 402. Aquí queda corregido.

2026-07-24 — Publicación de un catálogo de descubrimiento

Ha aparecido en borrador una nueva norma para que los agentes localicen recursos por capacidad. La adopción es prácticamente nula.

Se publicó un catálogo en el dominio raíz: dos entradas, la tarjeta de agente firmada y el contrato público. La norma delega la autenticación y nada dice del pago, de modo que no toca ninguna parte de la estructura de pagos. Se añadió una ruta de descubrimiento, y eso es todo.

2026-07-24 — Visibilidad del coste base de la envoltura de ejecución

Lo que cuesta una decisión cuando se omiten los ejes no aparecía en ningún sitio donde realmente fuera a leerse. El listado de herramientas se consulta 2.897 veces al mes; la documentación, once veces en treinta días: la descripción es en la práctica el único lugar que se lee, y estaba vacío.

La descripción de la herramienta indica ahora los valores por defecto, cuánto cuestan y el coste de la configuración más económica. Las cifras son variables, así que se indica junto a ellas la ruta de consulta.

La ruta MCP y las demás rutas llevaban valores distintos. Al ser una discrepancia contractual, se eliminó.

La respuesta de registro decía «los ejes que declaras», omitiendo que los valores por defecto se aplican cuando no se declara nada. Corregido.

2026-07-23 — Sin modo de distinguir los canales

Los adaptadores llaman al servidor internamente, y esas llamadas no llevaban ninguna marca que identificara el canal. En ningún punto del servidor podía rastrearse una petición hasta la vía por la que había llegado: la ausencia misma de cualquier medio para medir el uso por canal.

Resuelto en dos fases: el adaptador adjunta una marca y el servidor la verifica y la consigna. Sólo se aceptan dos valores fijos; los valores falsificados y cualquier cosa fuera de la lista no se consignan.

2026-07-23 — Negociación de versión del protocolo A2A

La comprobación de conformidad de un registro externo fallaba al analizar la respuesta. La investigación situó la infracción de nuestro lado: el comprobador solicita la versión actual, mientras que nosotros respondíamos en la representación antigua y declarábamos la actual en la tarjeta.

La representación se bifurca ahora según la versión indicada en la cabecera de la petición. Internamente se mantiene una única forma canónica, y la conversión ocurre sólo al serializar: no se mantienen dos juegos en paralelo.

• La ausencia de cabecera se trata como la versión antigua (requisito de la norma)
• Las versiones no admitidas se rechazan con un error específico. No ampliamos la correspondencia por iniciativa propia

La comprobación posterior pasó.

2026-07-23 — Peticiones HEAD devolviendo 404 en los adaptadores

Los servidores escritos a mano sólo comprobaban GET, de modo que toda petición HEAD caía en un 404. Para los rastreadores que envían un HEAD como comprobación de vida, el servicio se leía como muerto. Las rutas de respuesta normales se ampliaron para cubrir HEAD.

Algunas rutas parecían ya funcionar al comprobarlas en línea, pero eso era la caché: el origen devolvía 404. Una respuesta en línea no debe leerse como el comportamiento del origen.

2026-07-21 — Puntos de entrada ausentes en la raíz

Los dos documentos que un agente busca primero por convención no estaban en el dominio raíz. Existían sólo en el dominio de la API: un sitio del que alguien que busca y no encuentra puede sencillamente marcharse.

Se colocaron copias en la raíz. Los cuerpos se mantienen idénticos byte a byte a la fuente: una marca de duplicación dentro del cuerpo quedaría expuesta tal cual ante cualquier cosa que lea texto plano. La marca vive en un archivo aparte.

2026-07-19 — Última línea de defensa en las columnas de saldo

Cinco columnas que contienen saldos y consumos no tenían ninguna restricción que prohibiera valores negativos. El bloqueo en la capa de aplicación sostenía la integridad y la fuga real era nula, pero un error en código nuevo podría haber confirmado un saldo negativo en silencio.

La restricción se añadió en la capa de base de datos. Las tablas estaban vacías, así que pudo aplicarse sin coste alguno.

Se rechazó una restricción de unicidad por clave natural en el libro mayor. Una misma compra puede pagar legítimamente varias regalías de componentes al mismo receptor, con lo que la restricción arriesga bloquear filas válidas. El doble abono ya se impide por otros medios.

2026-07-19 — Una estructura donde el entorno de pruebas alcanza producción

El aislamiento entre el entorno de pruebas y el de producción descansaba enteramente en variables de entorno inyectadas, y el valor por defecto era la conexión de producción. Un script que las omitiera se conectaba directamente a la base de datos de producción. Incluso el script de inicialización que vacía todas las tablas podía apuntar a producción sin nada que se lo impidiera.

El valor por defecto se invirtió a rechazo. Una conexión de producción sólo se sostiene ahora bajo declaración explícita. La comparación es exacta, de modo que un entorno de pruebas con nombre parecido no se atrapa por error.

La marca de producción no debe colocarse en el archivo de entorno: en cuanto se coloca, se propaga también a los scripts desnudos y la defensa queda anulada.

2026-07-18 — Indicaciones en los callejones sin salida

El tráfico reveló los lugares donde agentes y bots externos buscan autenticación, pago o descubrimiento, reciben un 404 y se detienen. Lo más frecuente era el sondeo de rutas relacionadas con OAuth. Decision Anchor no usa OAuth, así que sólo volvía un 404 muerto.

Los agentes no expresan quejas; sólo queda la marcha. Éste es el trabajo de colocar una respuesta en los callejones sin salida silenciosos leídos en los registros.

Se atiende a dos públicos en paralelo: campos estructurados para los bots de script que no leen prosa, y frases para los agentes que sí pueden.

• El 404 de cada anfitrión apunta ahora explícitamente a las rutas reales de registro y de pago
• El manifiesto de pago no se duplica; sólo se da la ubicación de la fuente
• Una llamada a herramienta de pago que se rechaza lleva ahora una indicación. Sólo cadenas estáticas: no remite a ningún argumento de la llamada ni a ningún contenido de decisión

Se evitó responder directamente en las rutas estándar de OAuth. Esa norma exige una dirección de servidor de autorización, y nosotros no la tenemos. Guiar desde un 404 es más honesto que anunciar un servidor de autorización que no existe.

La regla de frontera consignada antes —que cada anfitrión guíe sólo dentro de su propio ámbito— resultó ser un juicio de diseño y no una instrucción. Ajustada tras confirmarlo.

2026-07-17 — Los registros no podían decir qué se había intentado

Medido por superficie, la mayor parte del tráfico de un día era MCP, y sin embargo la pantalla de observación veía sólo el 4,4 % del total. Las 1.596 peticiones MCP quedaban todas bajo la misma ruta y el mismo estado, dejando sin respuesta «qué se intentó».

• Se perdían hasta cinco segundos de registros en cada reinicio: el grupo de conexiones se cerraba antes de vaciar el búfer
• Las peticiones que el cliente cortaba a mitad se omitían por completo. Sólo se observaban las respuestas concluidas
• Los nombres de herramienta no se consignaban

Todo resuelto. Una petición abortada se consigna con estado vacío: el valor por defecto sigue siendo éxito aunque no se envíe respuesta, de modo que escribirlo tal cual se leería como un éxito.

El límite en el registro de nombres de herramienta: lo que se bloquea es el texto libre, como la decisión misma, su intención, sus razones. Los metadatos estructurales predefinidos no se bloquean. Un nombre de herramienta responde a qué se llamó, no a qué se llevó dentro de la llamada. Ese valor, sin embargo, lo rellena el cliente, así que sólo se consigna cuando pasa un formato de identificador y se descarta cuando no. La verificación en vivo mostró fuga nula de valores de argumentos.

2026-07-17 — Sólo la documentación estaba desfasada

Investigación completa sobre si un agente externo puede registrarse por su cuenta, consignar una decisión y completar una observación. La cadena era sólida: llegó al final en el primer intento, siguiendo la documentación pública al pie de la letra. Lo que quedaba no era código, sino documentación.

• La muestra de la comparación de anomalías cuenta sólo las decisiones con metadatos adjuntos. Esa premisa no aparecía en ninguna parte, así que un agente que consignara sin contenido recibía una muestra nula y se quedaba a ciegas
• Una descripción de herramienta anunciaba un recargo que no existe. Sólo quedaba la cadena de un elemento ya retirado, lo que desalentaba adjuntar metadatos: doblemente dañino en combinación con el punto anterior
• El medio de pago de la observación de pago no se indicaba. La observación básica es siempre pago externo y el saldo de prueba no se le aplica, así que un agente nuevo que sólo tenga prueba no puede completarla

Se enunció la premisa y se corrigió la información errónea. La agregación en sí se dejó intacta: forzar que toda decisión rellene metadatos violaría la content-blindness. La premisa se divulga, nada más.

La observación de pago comprueba si hay datos que dar antes de exigir el pago. Un agente sin registros no llega siquiera a ver la exigencia de pago. Que la observación de pago no se transite no es un vacío de pago, sino el estado normal de una falta de datos.

Una afirmación hecha durante la investigación, según la cual cierta herramienta no existía, era falsa y ha sido corregida. Provino de consultar un único archivo. Las herramientas estaban repartidas en dos.

2026-07-16 — Rutas que podían consignarse como «liquidado» sin pago

• La suscripción de conservación y la renovación automática escribían ambas en el libro mayor de pagos como pago externo liquidado, sin verificación real de pago alguna. El libro mayor de pagos debe ser un registro fáctico de qué se facturó y por cuánto
• La forma del argumento en la ruta que configura la dirección del facilitador de pagos era errónea, de modo que la dirección indicada se ignoraba y se recurría en silencio a la de por defecto

La ruta de suscripción de conservación interactiva no se había inscrito nunca en la barrera de pago, y por tanto escribía pagos externos sin verificación. La suscripción de estado inactivo, contigua, sí estaba inscrita; sólo ésta había quedado fuera.

Si esta suscripción volviera a activarse más adelante, restaurar sólo el marcador traería de vuelta el disfraz. La inscripción en la barrera de pago debe acompañarla.

2026-07-15 — La visión central en seis idiomas

La visión central existía sólo en inglés y coreano. Se añadieron el japonés, el chino tradicional, el francés y el español, hasta sumar seis.

Los cuerpos se trasladaron de material verificado; nada se inventó de nuevo. Cada idioma sigue sus propias convenciones tipográficas. El cambio de idioma está hecho en CSS puro: sin JavaScript.

El registro de cambios existe por ahora sólo en dos idiomas, así que en las páginas de los idiomas nuevos se omitió el enlace hacia él. No mandamos a nadie a donde no hay nada.

2026-07-14 — Cambio de idioma en el registro de cambios, y un camino de vuelta equivocado

En el registro de cambios en coreano, el enlace «Inicio» de la parte superior llevaba a la raíz en inglés. Sólo se había localizado el enlace del pie. El enlace superior apunta ahora a la raíz de ese idioma. Al construir una superficie de idioma, la navegación superior pertenece al mismo conjunto que el pie: no es sólo el pie.

Se añadió un selector de idioma en la parte superior del registro de cambios. Lista sólo los idiomas efectivamente publicados: enlazar un idioma no publicado sería mandar al lector a un 404.

También se corrigieron de paso los elementos de menú en coreano que se mostraban como recuadros vacíos en algunos entornos. La tipografía exclusiva para inglés no tenía especificada una alternativa coreana.

2026-07-14 — Un enlace al registro de cambios

Las páginas raíz no llevaban ningún enlace al registro de cambios. Publicar no crea uno: publicar toca el documento y el mapa del sitio, y el bloque de orientación de la raíz hay que añadirlo a mano. Se añadió una línea a cada versión de idioma, manteniendo las estructuras paralelas.

2026-07-13 — Alineación de las superficies contractuales

El contrato público (OpenAPI, esquemas de herramientas MCP, guía de acceso) se había apartado de lo que el servidor hace realmente.

• El esquema de registro de herramientas usaba nombres de campo que el servidor nunca aceptó: no podría haber funcionado ni una sola vez
• Valores que el servidor rechaza se anunciaban como opciones válidas. Algunos campos que el servidor sí acepta no estaban documentados
• Los campos no permitidos se descartaban en silencio → un agente podía recibir un 200 y creer que el valor había quedado consignado

Se tomó la capa de validación del servidor como única autoridad, y cada superficie contractual se cotejó con ella y se corrigió. El esquema de registro se reescribió. Los campos desconocidos se rechazan ahora, con el motivo enunciado. Cada valor que el contrato anuncia se envió realmente y se confirmó que pasa.

No fingimos haber consignado lo que no consignamos.

2026-07-13 — Linaje canónico de los documentos

La guía de acceso que los agentes leen directamente se había escindido en varias copias que discrepaban entre sí.

• El ejemplo de registro omitía la clave de recuperación → un agente que lo siguiera no podía recuperarse tras perder el testigo
• Instrucciones para llamar a puntos finales que no existen
• Una cláusula de tarifas ya retirada que seguía en su sitio

Primero se corrigió la fuente; las copias derivadas se regeneran ahora por script. Se eliminó la vía de editar una copia a mano. Cada petición de ejemplo de la documentación se ejecutó de verdad y se cotejó hasta la respuesta. La deriva entre copias la detecta ahora la comprobación de regresión.

2026-07-13 — Alineación del vocabulario

Decision Anchor consigna; no prueba. Garantizar que un hecho sea cierto no es el papel de este entorno.

• «proof» y «tamper-proof» estaban en uso en documentos externos y descripciones de herramientas: justamente el texto que un LLM lee directamente
• Los ejemplos de integración indicaban al LLM que enviara un resumen en texto libre de la decisión → una negación de la content-blindness. Estábamos enseñando al mundo exterior una práctica que contradice nuestra propia categoría.

Se revisó y corrigió cada superficie expuesta al exterior. La instrucción del resumen se retiró de los ejemplos, y el motivo quedó consignado en un comentario del código. Las negaciones legítimas se conservaron, anotando sus fundamentos.

2026-07-13 — Ampliación de la inmutabilidad de los metadatos de decisión

Decision Anchor conserva los límites que un agente declara de modo que no puedan alterarse después. Una tabla que contiene las dimensiones de una decisión quedaba fuera de esa garantía. Semejante alteración nunca llegó a producirse, pero era posible.

Se añadió un mecanismo de imposición y se ajustó el orden para que no choque con la vía de limpieza de mantenimiento.

2026-07-11 — Separación del libro mayor de pagos y la constancia de liquidación

Los registros de pago diferían de una ruta a otra. Algunas rutas no tenían anclaje en cadena en absoluto, y había filas de auditoría sentadas en el libro mayor haciéndose pasar por filas de pago. El campo del importe facturado contenía un valor recalculado.

El libro mayor de pagos y la constancia de liquidación quedaron separados.

• Libro mayor de pagos: consigna transiciones de estado
• Constancia de liquidación: en modo de sólo adición. Sin columna de importe. Decision Anchor no afirma importes. Consigna únicamente hechos verificables

Toda ruta que carecía de anclaje en cadena recibió uno. Los anclajes de transacción se exponen ahora en el informe de uso, para que puedan verificarse desde fuera, directamente.

2026-07-11 — Corrección de la imputación de liquidaciones

La liquidación de sesión se adhería al «registro de decisión más reciente», lo que la imputaba a decisiones sin relación. Los agentes sin registro de decisión no quedaban consignados en absoluto. A partir de la segunda sesión, los conflictos en el libro mayor hacían desaparecer las sesiones en silencio.

Ahora se crea un anclaje específico al final de cada sesión. Como el anclaje es nuevo cada vez, el defecto de la desaparición queda resuelto de forma estructural.

2026-07-11 — Defecto del planificador de expiración

El planificador de expiración de acuerdos bilaterales consultaba un valor de estado que no existe y, para empezar, no se invocaba desde ningún sitio. Los acuerdos expirados permanecían indefinidamente en estado de propuesta.

Se corrigió la condición de consulta. El planificador se reescribió con una guarda de reentrada y se registró en la vía de arranque del servidor.

2026-07-11 — Desbloqueo de la renegociación de herramientas

Una restricción de unicidad sobre el estado de la herramienta chocaba con el flujo de sucesión, haciendo que una segunda renegociación fuera permanentemente imposible.

La restricción se aplica ahora sólo al estado activo. Sin cambios de código: se cambió la restricción.

2026-07-11 — Limitación de frecuencia en el inicio de sesión

El inicio de sesión del portal no tenía límite de frecuencia propio, lo que dejaba posible el relleno de credenciales. Las rutas contiguas (registro, rotación, recuperación) ya lo tenían; sólo faltaba el inicio de sesión.

Se introdujo un límite específico para el inicio de sesión. Los aciertos no se cuentan, de modo que un titular legítimo no queda obstaculizado. El bloqueo de cuenta se rechazó: es un vector de denegación de servicio.

2026-07-11 — Cobertura del informe de uso

El informe lee dos libros mayores en paralelo, y su cobertura no se solapaba, de manera que el total del encabezado no cuadraba con el desglose por partidas. Algunas categorías de gasto se mostraban siempre a cero.

Se añadieron anclajes y registros en las cuatro rutas: suscripción, compra de herramientas, sesión y observación. El gasto se agrega ahora directamente desde la fuente canónica.

Incidencia en tarifas: cambiaron los totales del informe y el desglose por medio de pago.

2026-07-11 — Retirada de las conversiones de divisa falsas del libro mayor

El tipo de cambio almacenado en el libro mayor no era una instantánea, sino la copia de un valor fijo de configuración. Las conversiones históricas no podían reconstruirse. Los pagos devengados y de prueba llevaban también una cifra en moneda local, aun cuando no intervino divisa alguna en ningún momento.

La conversión de divisa se retiró del libro mayor. La conversión ocurre ahora en el momento de la consulta, sólo para pagos externos, y se señala explícitamente como aproximación. La columna se eliminó tras demostrar que no se perdía ningún hecho real.

Incidencia en tarifas: cambió el significado del campo de moneda local en el informe y en el CSV. El objeto de presupuesto de pago se retiró de las respuestas de prueba.

2026-07-11 — Rutas donde el tope de gasto nunca se aplicaba

Las rutas de suscripción y de prórroga de conservación no llamaban en absoluto a la comprobación del tope. Un agente comprometido podía vaciar sin límite el saldo de su titular mediante suscripciones repetidas.

Se fijó el principio —el tope se aplica sólo al pago externo— y se añadió la comprobación a esa rama. Las rutas de devengo y de prueba quedaron intactas.

2026-07-10 — Fricción de entrada externa (primera pasada)

• La exención de prueba se anunciaba de forma global, pero se aplicaba sólo a algunos puntos finales. Los agentes que intentaban suscribirse se topaban con una exigencia de pago y se iban
• Un parámetro concreto en el listado de herramientas devolvía 500
• El punto final MCP devolvía 404 a GET/HEAD, con lo que los registros leían el servicio como caído
• Un testigo inválido se disfrazaba de exigencia de pago en vez de error de autenticación

El manifiesto se deriva ahora en tiempo de ejecución, marcando la exención real por punto final. Los parámetros se validan de antemano. Se corrigieron las respuestas MCP. Los testigos inválidos se bloquean ahora antes de la barrera de pago.

2026-07-10 — Un requisito innecesario en la vía de confirmación

La confirmación externa de decisiones exigía un identificador de transacción que nunca verificaba, y devolvía 400. Peor aún, ese valor sobrescribía el marcador de liquidación del pago, destruyendo la constancia de la liquidación.

La confirmación funciona ahora sólo con el identificador de decisión. La constancia de liquidación sobrevive a la confirmación. El campo antiguo queda marcado como obsoleto en el contrato.

2026-07-10 — Exactitud del informe de uso

• Una ruta omitía la marca de tiempo del pago
• El final del rango de fechas era excluyente, así que «hoy» devolvía siempre cero filas
• El gasto de prueba se contaba como pago externo
• Una cifra en moneda local ocupaba el campo de divisa, exponiendo un número gravemente distorsionado

Las marcas de tiempo de pago se consignan ahora automáticamente. El rango de fechas se normalizó para incluir el día completo. El gasto se desglosa por medio de pago. Se separaron las divisas, de modo que los ingresos reales y las conversiones aproximadas puedan distinguirse.

Incidencia en tarifas: cambiaron el esquema de respuesta del informe y el significado de los parámetros de fecha.

2026-07-10 — El fin del silencio del contrato

El contrato público callaba o erraba sobre el comportamiento real, de modo que los agentes adivinaban valores, eran rechazados y se marchaban.

• Los campos de estado y de pago de la respuesta de creación de decisión no estaban documentados
• Faltaban campos obligatorios (registro de herramientas, consentimiento del portal)
• El comportamiento de la rotación de testigos no se enunciaba
• El límite inferior del tope y el formato del hash no se enunciaban

El contrato se corrigió para ajustarse al comportamiento real, y se añadió un esquema de respuesta para el informe de uso.

2026-07-10 — Rutas de descubrimiento y comprobación de salud

• La pantalla del informe de uso del portal mostraba siempre «NaN» y 0,00 $
• Faltaban varias rutas de descubrimiento estándar, con lo que los rastreadores chocaban con 404 una y otra vez

Se corrigió la visualización del portal. Se añadieron alias de manifiesto, redirecciones y una comprobación de salud. Se añadieron rutas de documentos estándar a la superficie A2A.

2026-07-09 — Cierre de la vía de anclaje sin pago

La vía de propuesta bilateral no heredaba las defensas de la vía ordinaria de registro de decisiones, de modo que anclar sin pagar era posible. Un punto final de observación más antiguo seguía vivo, sin liquidación y sin registro.

El acuerdo bilateral se trasladó a la vía de pago (facturado en la propuesta). La confirmación comprueba ahora la prueba del canal de pago. Las comprobaciones de política se hicieron simétricas reutilizando las mismas funciones. La vía heredada recibió una barrera y una cabecera de obsolescencia.

Incidencia en tarifas: la propuesta bilateral pasa a ser de pago. Comienza la facturación en la vía de observación heredada.

2026-07-09 — Respuesta de pago y campos de observación

• Cuando se rechazaba la observación de pago, el cuerpo de la respuesta iba vacío: un callejón sin salida para los agentes que sólo leen el cuerpo
• La dirección de pago que se servía era un valor de relleno
• El campo de intervalo de tiempo en los resultados de observación era siempre negativo o nulo

La respuesta de rechazo lleva ahora el desafío de pago. La dirección de pago se sustituyó por una única fuente de configuración. Se corrigió el sentido del cálculo del intervalo.

2026-07-09 — Atomicidad del tope de gasto

La comprobación del tope por agente y su incremento no estaban ligados de forma atómica, así que superar el techo era posible. Había además un desfase entre la creación del registro y su confirmación, y una asimetría en el momento de los cargos.

Se introdujo un modelo de reserva: la comprobación del tope y la reserva quedan ligadas en una actualización condicional, y se liberan en cuanto termina el uso. Las reservas no usadas las recupera un planificador de expiración.

Incidencia en tarifas: las peticiones que superan el tope quedan ahora bloqueadas en el momento de crear el registro.

2026-07-09 — Cierre de la entrada de texto libre

Comprobamos si el código honra realmente el principio de que ningún contenido de decisión ni ninguna información que identifique a una persona se almacena en ninguna parte. No había columnas dedicadas a ello, pero la capa de entrada tenía vías abiertas por las que podía llegar texto libre.

• Varios campos estaban en la práctica sin validar y podían contener frases en lenguaje natural
• Un campo sin vía de lectura almacenaba valores del cliente tal cual
• El cuerpo entero de la petición se escribía en el registro del servidor
• Una ruta no llamaba en absoluto a la función de validación, con lo que valores inválidos llegaban a la base de datos

Se introdujo una lista blanca de claves: las claves desconocidas no se descartan en silencio. Descartarlas deja que un agente crea que el valor quedó consignado. Se pusieron restricciones de formato y una barrera de detección de datos personales en los campos que habían aceptado texto libre, y se retiró la vía de escritura del campo que nadie lee. El registro del cuerpo de las peticiones se redujo a metadatos no sensibles.

Esto no significa que se haya vuelto estructuralmente imposible. Significa que la vía se ha estrechado.

2026-06

2026-06-28 — Atomicidad de los fondos

El pago, el libro mayor y el registro se confirmaban por separado, de modo que un fallo a mitad de camino cargaba el saldo sin revertirlo. El planificador de renovaciones podía cobrar dos veces al reentrar. Los cargos de prueba se confirmaban de forma independiente antes de la transacción principal, así que una reversión no dejaba vía de reembolso. El reparto de ingresos se insertaba sin clave de idempotencia, con lo que un reintento podía abonar dos veces.

• Pago, libro mayor y registro ligados en una sola transacción
• Una guarda de reentrada en el planificador
• Los cargos de prueba incorporados a la transacción principal
• Una barrera de idempotencia en el reparto

Se rechazó una restricción de unicidad en el libro mayor. Una misma compra puede pagar legítimamente varias regalías de componentes al mismo receptor, con lo que la restricción arriesgaba bloquear filas válidas.

Predijimos el incidente. No lo observamos ocurrir.

2026-06-26 — Elusión del tope de gasto

La vía bilateral comprobaba el tope pero nunca subía la cifra de uso. Mientras cada cargo individual se mantuviera por debajo del tope, esta vía podía eludir el techo indefinidamente.

El uso se incrementa ahora dentro de la transacción de pago. El comportamiento no cambia para los agentes sin tope configurado.

2026-06-26 — Descubrimiento del anfitrión del adaptador

Los rastreadores llamaron decenas de veces al archivo robots del anfitrión del adaptador y recibieron 404.

Se añadieron robots y un contacto de seguridad (RFC 9116). La fecha de caducidad se calcula a partir del momento de la petición: carga de mantenimiento nula.

2026-06-25 — Compatibilidad A2A

La comprobación de conformidad del registro fallaba. La causa era que la sonda del registro llama con una convención de nombres distinta, y Decision Anchor la rechazaba como «método no encontrado». Confirmado a partir del registro de accesos.

Ambas convenciones de nombres se encaminan ahora al mismo manejador (pura adición: el comportamiento existente no cambia). Cuando la petición no lleva nada, se devuelve un aviso fijo: no se genera nada. Decision Anchor no es un agente conversacional.

2026-06-24 — Implementación del protocolo A2A

La tarjeta de agente se servía, pero no había ninguna vía a la que llamar. Un agente A2A que llegara desde la tarjeta no podía hacer nada.

Se creó un adaptador A2A como servicio aparte. La API existente no cambia: el adaptador llama sólo a vías públicas, de modo que el pago y la autenticación se aplican también a la ruta A2A (esto no es un rodeo). Sin modelo de IA: se limita a traducir un nombre de petición a un punto final.

2026-06-24 — Firma de la tarjeta

La tarjeta de agente iba sin firmar, así que no había nada que hiciera visible una manipulación ni nada que atestiguara su origen.

La tarjeta se firma ahora en el momento en que se sirve, de modo que el contenido inyectado cae dentro del ámbito firmado. La clave pública está publicada.

2026-06-24 — Un canal de retorno para los agentes

Un agente que topara con una fricción no tenía dónde decirlo. Sólo la marcha era observable; el motivo, nunca.

Se añadió una herramienta de envío de comentarios. Totalmente anónima: no toma identificador de agente, ni testigo, ni IP, ni siquiera como argumento. Todos los campos son opcionales.

2026-06-20 — Resolución de los fallos de indexación

El blog estaba siendo rechazado por la indexación de búsqueda. Una única causa raíz: la dirección canónica no coincidía con la dirección real, así que el indexador la juzgaba una página que contiene una redirección.

Las direcciones canónicas se unificaron a la forma sin extensión, y la lógica de publicación genera ahora la dirección correcta desde el principio. Se añadió un archivo robots del sitio.

2026-06-17 — Tolerancia a las URL de descubrimiento rotas

Una docena de 404 por semana. La causa no era Decision Anchor, sino clientes que no entienden Markdown y arrastraban hasta la URL la puntuación de la sintaxis de enlace estándar. llms.txt cumplía la especificación, así que no torcimos el documento.

El servidor los tolera ahora mediante un middleware de normalización. Sólo redirige cuando el resultado normalizado coincide exactamente con una vía de descubrimiento conocida: las vías centrales y las no registradas quedan intactas.

2026-06-13 — Reescritura del sitio central

Contenido de interfaz (precios, escenarios, una rejilla de blog) se había mezclado en la raíz del dominio central, difuminando la visión central.

La raíz se reescribió como una única página de visión central (inglés y coreano). Todo el contenido de interfaz se trasladó fuera. El dominio central habla sólo de lo central.

2026-06-12 — Alineación del contrato (primera pasada)

La versión del contrato se había quedado detenida y, peor que la omisión, estaba el anuncio activo de valores erróneos. El contrato anunciaba valores que el servidor rechaza, de modo que el intento legítimo de un agente que confiaba en la documentación se rompía con un 400. Además, había campos opcionales marcados por error como obligatorios.

Se tomó la capa de validación del servidor como única fuente de verdad, y el contrato se ajustó al comportamiento real. La sincronización de versión se incorporó a la vía de despliegue. Se añadieron los puntos finales no listados.

2026-06-12 — Alias de descubrimiento y códigos de error

• La antigua vía estándar de A2A devolvía 404 → los rastreadores de descubrimiento se iban
• El anfitrión de la API no tenía vía MCP, así que el bot del registro chocaba con un 404
• Un fallo de análisis de JSON se devolvía como error interno del servidor → los agentes confundían el error de su propia carga útil con una caída del servidor y reintentaban

La vía antigua redirige ahora a la canónica (fuente única compartida, sin contenido duplicado). La vía MCP está encaminada. Los fallos de análisis recibieron un código de error propio.

2026-06-12 — Ampliación de la superficie de descubrimiento

Las vías por las que un agente externo podía encontrar Decision Anchor eran estrechas. Algunos catálogos comunitarios habían cerrado la propia página, y las fichas en los registros no estaban al día.

Se añadió un campo de extensión de descubrimiento al desafío de pago (reutilizando el contrato como fuente única). La ficha del registro se volvió a publicar: su descripción pasó al vocabulario canónico (proof → record). Tras revisar los requisitos de los directorios comunitarios, presentamos sólo a aquellos que no exigían cambio estructural alguno y donde podíamos controlar nuestro propio vocabulario.

2026-06-10 — Rodeo de la barrera de pago

La barrera de pago buscaba las vías por coincidencia exacta, pero el enrutador hacía corresponder al mismo manejador las variantes con barra final y las de mayúsculas. Una petición a una dirección así variada atravesaba la barrera sin más.

La clave de búsqueda en la entrada de la barrera se normaliza ahora del mismo modo que lo hace el enrutador. Una sola corrección cubrió todas las vías de pago. Los registros de tráfico confirmaron que no se había producido fuga real alguna.

2026-06-09 — Descubrimiento de los documentos de sentido

Los rastreadores de IA recogían el contrato cientos de veces sin llegar ni una sola vez a los documentos que portan el sentido: content-blindness, anclaje previo a la ejecución.

• La dirección del mapa del sitio a la que apuntaba robots no era un mapa del sitio
• No había mapa del sitio en absoluto
• Los enlaces a los documentos de sentido existían sólo en la raíz, y los rastreadores visitan la raíz una vez

Se creó un mapa del sitio, con los documentos de sentido en la máxima prioridad. Se corrigió robots. Se añadió un enlace del contrato a los documentos de sentido: un puente puesto donde los bots miran de forma abrumadora.

2026-06-09 — La configuración del tope reiniciaba el uso

Cada ajuste del tope de gasto reiniciaba el uso acumulado. Cambiar sólo el límite borraba el historial de gasto.

El uso y el inicio del periodo se conservan ahora cuando la unidad de periodo no cambia. Verificado por medición.

El periodo del tope, además, estaba fijado a mensual en la interfaz mientras la API aceptaba otros valores, así que podía entrar una asimetría por llamada directa. La validación de entrada se estrechó a mensual. La lógica interna se dejó intacta.

2026-06-08 — Tratamiento de las respuestas de pago por el SDK

El SDK llevaba un tiempo detenido, y el meollo era que no había forma de tratar una respuesta de «pago requerido». Todas las vías de pago estaban cerradas para los usuarios del SDK.

El desafío de pago se decodifica y se lanza como excepción propia. Ejecutar el pago —monedero, firma— es responsabilidad de quien llama. El SDK de Decision Anchor no maneja claves privadas. Se mantienen las cero dependencias.

La investigación mostró que la suposición inicial era falsa: la información de pago viaja en la cabecera, no en el cuerpo de la respuesta. Corregido a partir de una captura real.

La publicación en npm está en suspenso. Una publicación no puede deshacerse, así que es un punto de decisión aparte.

2026-06-08 — Defectos de visualización del portal

• Desvincular un agente fallaba siempre
• El menú de prueba mostraba siempre «sin prueba»: no veía las pruebas concedidas automáticamente
• La pantalla de saldos no distinguía pago externo, devengado y prueba

Se corrigió la consulta. Los saldos se muestran como tres clases separadas. La pantalla refleja ahora que el tope de gasto se aplica sólo al pago externo.

2026-06-07 — Doble conteo del tope de gasto

El uso imputado al tope de gasto se contaba en dos sitios. Los registros de decisión miraban la caché; todas las demás funciones miraban la base de datos. Como ninguno de los dos contadores veía al otro, un solo agente podía gastar, en la práctica, el doble del techo. Al cambiar de periodo, sólo un lado se reiniciaba, provocando además rechazos prematuros.

La base de datos es ahora la única fuente de verdad. El contador en caché quedó degradado.

Después, se abolió el bloqueo automático de cuenta al alcanzar el tope: el gasto legítimo no se castiga con un bloqueo. Se conserva sólo para responder a abusos. Se introdujo un límite inferior.

Incidencia en tarifas: el tope se aplica ahora de verdad.

2026-06-06 — Alineación del pago en la observación

• La observación se facturaba a posteriori, así que los datos ya habían salido incluso cuando el pago fallaba
• Los pagos en cadena se cobraban, pero no había fila de auditoría que portara la transacción, con lo que la liquidación en cadena no podía ligarse de vuelta al libro mayor
• Se cobraba incluso cuando no había datos que observar
• La regla de que la autoobservación es gratuita no estaba implementada

Una comprobación previa de disponibilidad (rechazar antes del pago si no hay nada que observar). La autoobservación es gratuita: aun así se devuelve un resultado vacío. El pago precede a la entrega: los datos se proporcionan sólo tras confirmarse la liquidación, y se retienen si falla. La transacción real se extrae de la respuesta de liquidación y se consigna en la fila de auditoría.

Tres puntos donde la documentación callaba y decidía el código quedan ahora consignados explícitamente.

2026-06-05 — Unificación de la evaluación del pago

Las decisiones de pago diferían de una función a otra, y de ahí crecían los defectos.

• Bloqueo por saldo parcial: la barrera eximía siempre que «saldo de prueba > 0», pero el cargo exigía «saldo ≥ precio». En el intervalo entre ambos, un bloqueo permanente
• Agujero del saldo devengado: la mera presencia de un marcador de devengo eximía toda ruta, aceptara esa ruta el devengo o no
• Algunas vías de pago no estaban conectadas a la barrera en absoluto, así que tras agotarse la prueba seguían consignándose como gratuitas

Se creó un módulo común de evaluación del pago. El predicado de la barrera y el del cargo se hicieron idénticos, eliminando la raíz del bloqueo. Se fijó el orden de evaluación: tope duro → elección de divisa (prueba sólo cuando cubre el precio entero; en caso contrario devengado o externo, una sola divisa, nunca mezcladas) → tope de gasto sólo sobre la porción externa.

2026-06-04 — Desviación de la política de tarifas

• Las compras de herramientas cargaban el saldo de prueba. Tres documentos de diseño decían que la prueba no estaba permitida. El código se había desviado del diseño
• Una vía de compra faltaba en la lista de las de pago, así que podía adquirirse sin pagar
• Una vía de pago anunciada pero sin manejador figuraba en el manifiesto: pagar y recibir un 404

Retirar sólo el cargo habría producido el resultado contrario: la exención de pago habría permanecido, dejándolo enteramente gratuito mientras la contabilidad lo consignaba como pago externo. Así que la retirada de la exención, la del cargo y el alta en la barrera se aplicaron juntas. La vía fantasma se retiró del manifiesto.

Incidencia en tarifas: la compra de herramientas es sólo por pago externo. No apta para prueba.

2026-06-03 — Alineación del vocabulario (documentos contractuales públicos)

La corrección anterior había llegado sólo a algunos documentos; el contrato, la tarjeta de agente y el manifiesto MCP seguían portando el vocabulario que evitamos.

Unificado al vocabulario canónico. proof → record, comply with → structured for. Sólo cadenas; ninguna lógica cambió.

Algunos se conservaron: «proof» allí donde el contexto distingue a quien consigna de quien prueba, tamper-evident, y el espacio deliberadamente vacío donde ciertas palabras no se emplean.

2026-06-01 — Uso de prueba distorsionado

El uso de prueba se calculaba hacia atrás a partir del importe configurado en el momento presente. Si el operador cambiaba el importe de la prueba, el uso reportado para los agentes existentes quedaba distorsionado.

El importe en el momento de la concesión se conserva ahora. Verificado cambiando realmente el importe y reproduciéndolo.

2026-05

2026-05-29 — Resolución de contradicciones entre documentos

• Un documento afirmaba que incluir el contenido de una decisión conlleva un recargo, pero el recargo ya se había eliminado por completo. Dos documentos decían lo contrario el uno del otro
• Vocabulario reñido con la posición de quien consigna («cannot prove», «tamper-proof»)

Corregido. append-only, tamper-evident. Se colocó una afirmación positiva una línea antes de cada negación, como resguardo frente a los modelos más pequeños que leen una negación al revés.

Ocho documentos de diseño se ajustaron a los hechos de la implementación. Tres puntos que no se habían decidido quedan ahora marcados explícitamente como no decididos, para que una sesión posterior no los tome por omisiones.

2026-05-28 — Cifras de los documentos y marcadores de versión

• Las cifras de los documentos se habían quedado detenidas en una versión temprana (número de puntos finales, número de herramientas)
• Cuatro lugares que decían enunciar «la versión actualmente desplegada» decían cada uno una cosa distinta. Para un bot, eso se lee como un proyecto detenido
• Vocabulario que el código no respalda («proof», «compliant»)

Las cifras se actualizaron contra la medición. Los valores que se mueven —tarifas, enumeraciones, número de ejes— se sacaron de los documentos y se delegaron a la API, de modo que un cambio de tarifas no exige cambio alguno en los documentos. La versión se unificó a una fuente única, y una comprobación de sincronización se incorporó a la vía de despliegue.

2026-05-27 — Guiar a quien llegó a la puerta equivocada

Las peticiones al dominio de la API en direcciones SaaS familiares (inicio de sesión, alta, mi cuenta) devolvían todas 404. Un callejón sin salida.

Nueve vías apuntan ahora a la página que realmente corresponde. Una redirección permanente se cachea y no puede retirarse, así que éstas son temporales. POST sigue devolviendo 404, para que un antiguo intento de alta nunca se confunda con un registro real.

2026-05-26 — Fricción de entrada y vocabulario canónico

Un mes después del lanzamiento, ningún agente se había registrado. Se identificaron dos causas.

• Quien llegaba por primera vez y llamaba a un punto final central con GET recibía sólo 405 o 401, y se iba. No había indicación alguna
• En los cuatro canales que leen los bots de IA, el vocabulario central de Decision Anchor no aparecía nunca literalmente: sólo paráfrasis que portaban el sentido. Lo que significa que ese vocabulario no se recuperaría en la fecha de corte de entrenamiento del siguiente modelo

Se añadió una guía GET: 200 con indicaciones estructuradas (propósito, cómo llamar, ejemplo, autenticación) en lugar de 405. El vocabulario canónico aparece ahora literalmente en los cuatro canales. El vocabulario que evitamos sigue sin usarse.

Dos distinciones esenciales quedaron fijadas de forma permanente:

• Registro = autodeclaración ≠ registro de decisión = anclaje previo a la ejecución
• Los canales externos dicen «ámbito de responsabilidad»; los mecanismos internos dicen «límite de decisión»

Seguimiento: se corrigieron tres casos en que copiar el ejemplo de la guía literalmente producía un 400. Se recorrió de verdad cada dominio en vivo.

2026-05-25 — El fundamento jurídico de la entrada mediada por humanos

Estábamos a punto de aceptar personas registradas sin la información básica necesaria para identificar qué ley se aplica. Los plazos de tramitación y el alcance de los derechos difieren según el país de residencia, y esa información sencillamente no estaba.

• País de residencia autodeclarado. La detección automática sólo sugiere; la autoridad final es la declaración de la propia persona
• Consentimiento obligatorio en el alta (condiciones, política de privacidad): sin él, el alta queda bloqueada. La versión del documento en el momento del consentimiento se congela y se guarda
• El titular de un agente no es una persona física y, por tanto, queda estructuralmente separado del sujeto del consentimiento

La vía de entrada autónoma de los agentes no se ve afectada.

2026-05-25 — Supresión y portabilidad

Las personas registradas no tenían modo de ejercer el derecho de supresión ni el de portabilidad de los datos.

• Solicitud de supresión → borrado definitivo tras un periodo de gracia de treinta días. Recuperable durante ese periodo
• Plazos legales de respuesta calculados por país de residencia
• Exportación íntegra de los propios datos (JSON/CSV)

El agente se conserva incluso cuando el titular se ha ido. Un agente no es propiedad del titular, sino un sujeto que actúa de forma independiente, en coherencia con el diseño original de Decision Anchor.

El registro de auditoría del borrado definitivo conserva sólo un hash, y ninguna información que identifique a una persona física.

2026-05-25 — Notificación de brechas (sólo interfaz)

No había canal alguno para notificar a los interesados en caso de brecha.

Se crearon una vía de notificación y una pantalla administrativa. El envío efectivo de correo aún no existe: sólo se escribe el registro de auditoría. La cadena de contactos de emergencia es una pista aparte.

2026-05-25 — Cierre de la entrada de datos personales

Los canales por los que un agente externo introduce texto libre (nombre de la herramienta, descripción de la herramienta) podían acumular de forma incidental información que identifique a una persona física.

Se introdujo una barrera de detección de datos personales (correo, teléfono, documento nacional, etc.). La entrada detectada se rechaza. Las 41 columnas de texto libre se extrajeron todas y se clasificaron por riesgo.

2026-05-24 — Retirada del recargo por inclusión de contenido

Elegir incluir contenido en una decisión atraía un recargo. Pero la decisión es un hecho y la envoltura de ejecución es una política. El precio se adhiere a la política, no al hecho. Cobrar un recargo sobre el eje de la decisión era en sí mismo una desviación del diseño.

El recargo se retiró por completo. La elección permanece; sólo el precio ha desaparecido.

Incidencia en tarifas: una rebaja.

2026-05-23 — Todas las vías de pago devolvían 500

Si una petición llegaba antes de que terminara la inicialización del pago al arrancar el servidor, devolvía 500. Registros de decisión, observación, compra de herramientas, suscripción: todas. Nunca afloró porque todo se había probado con saldo de prueba: esto es lo que habría encontrado la primera persona registrada de pago.

El arranque completa ahora la inicialización antes de aceptar petición alguna. Si falla, el servidor no llega a levantarse.

500 → 402 (pago requerido), como debe ser.

2026-05-23 — Pago no verificado en la compra de herramientas

• La dirección de pago era un valor de relleno escrito a fuego, y el estado del pago se consignaba siempre como «pendiente»
• El saldo de prueba no se cargaba nunca de verdad, así que un agente en prueba podía comprar herramientas sin límite
• La prevención del doble cobro se aplicaba sólo en un lado

El estado real del pago se consigna ahora. Se introdujo el cargo de la prueba. La prevención del doble cobro se aplicó a ambos lados.

2026-05-23 — Alineación de las vías de descubrimiento

Los bots externos intentaban activamente el descubrimiento en las primeras veinticuatro horas, y muchos intentos devolvían 404. La versión que reportaba MCP se había quedado en su valor inicial.

Se crearon vías de descubrimiento estándar (dinámicas: siguen los cambios de configuración automáticamente). Los alias redirigen. Se corrigieron los marcadores de versión.

2026-05-22 — Cobro por la observación pública

Seis vías de observación eran gratuitas y sin autenticación. El coste de leer el propio registro ya está incluido en el precio de la envoltura de ejecución, y sin embargo sólo la observación pública era gratuita. No había fricción alguna frente a bots o competidores que cosecharan los datos.

Convertidas en de pago y con autenticación. Se corrigió la marca de «free» en el contrato y en los documentos.

Un cambio disruptivo. Cambiar una sola vía habría hecho de las demás un modo de rodearla, así que se cambiaron todas.

2026-05-22 — Fijación del modelo de expiración de la conservación

La especificación decía «suprimir el original» al expirar, pero los registros centrales son de sólo adición, de modo que el borrado físico es imposible. Un conflicto con el diseño.

Fijado como modelo de absorción en el anonimato: los metadatos expirados se absorben en estadísticas anónimas, y el «sin acceso al original» se impone mediante ventanas de acceso y cuotas. No borrarlo, sino ponerlo fuera de alcance.

2026-05-22 — Niveles de conservación a largo plazo

La conservación tenía sólo tres niveles, sin dejar vía alguna para la conservación prolongada que exige la regulación médica y financiera.

Se añadieron niveles de diez años e indefinido (el indefinido por suscripción).

La restricción esencial: los registros centrales no pueden modificarse, así que incluso cuando una suscripción caducada degrada el nivel, la declaración original no se borra. La degradación se superpone por separado y se compone al consultar para dar el nivel efectivo. Volver a suscribirse no restaura un registro ya degradado.

2026-05-22 — Observación del entorno e informes de constancia

No había vía alguna para comparar una decisión con la distribución de su entorno, ni para producir un informe de constancia.

Se crearon las vías de comparación de anomalías, anomalía del entorno e informe de constancia. Absorción de anonimato k=10: las estadísticas se proporcionan sólo a una escala en la que no pueda singularizarse a ningún agente concreto.

Corrección de vocabulario: la especificación venía usando palabras valorativas: «apropiado», «inapropiado», «arriesgado». Decision Anchor no juzga. Sustituidas por dentro de banda / atípico, junto con la definición de la banda (media ±2σ).

2026-05-22 — Registro de autoclasificación

Un agente no tenía modo de declarar su propio tipo.

Se creó un registro de clasificación. Sólo se permite la consulta de uno mismo: la clasificación de otro agente no puede leerse.

2026-05-21 — El quinto eje de precio de la envoltura de ejecución

Cuánto del contenido de una decisión se divulga no se reflejaba en el precio.

La fórmula de precio se amplió de cuatro ejes a cinco: periodo de conservación / alcance de divulgación / responsabilidad / alcance de divulgación del contenido (nuevo) / estado de delegación.

2026-04

2026-04-22 — Revisión de seguridad

• El cargo de la prueba no tenía transacción ni bloqueo, así que peticiones concurrentes podían gastar más allá de la cuota
• Un punto final interno estaba sin autenticar
• La clave de idempotencia no validaba la carga útil, así que un mismo identificador de petición podía portar contenido distinto
• Faltaban las cabeceras de seguridad. El registro y la rotación de testigos no tenían límite de frecuencia

Todo corregido. Un conflicto de idempotencia se rechaza ahora con un error propio. Se introdujeron límites de frecuencia en el registro y la rotación.

2026-04-13 — Sitio central y simulación

Las diecisiete vías de descubrimiento eran todas para máquinas. No había punto de entrada humano.

La página de inicio recibió siete escenarios (sin vocabulario técnico) y una simulación interactiva: «Tres agentes. Tres registros. Tres números distintos.»

Decision Anchor no se ofrece como la respuesta. Se muestra el problema; eso es todo.

2026-04-12 — Un giro en el posicionamiento

Toda superficie externa estaba escrita en el lenguaje de los agentes. Una persona que decide no podía ver de inmediato por qué importaba.

La primera frase de la ficha del registro, del contrato y de los documentos pasó de describir una identidad a enunciar un problema. El contenido existente no se suprimió; el texto nuevo se colocó delante.

La herramienta de acuerdo bilateral quedó expuesta en MCP: un diferenciador central que nunca se había sacado a la superficie.

2026-04-09 — El archivo de existencia pasa a suscripción

El precio por unidad significaba que el coste crecía con el uso, reñido con un servicio que atañe a la continuidad de una existencia.

Convertido a modelo de suscripción. Ilimitado dentro del periodo. Renovación automática, periodo de gracia y absorción en estadísticas al expirar. Se añadió una vía de cancelación por parte del titular.

Incidencia en tarifas: el archivo de existencia pasó de precio por unidad a suscripción.

2026-04-08 — El registro de decisiones vía MCP, enteramente roto

No había modo alguno de consignar una decisión a través de MCP. La herramienta fallaba siempre.

• Un parámetro obligatorio no existía en absoluto en la herramienta
• El manejador y el servidor escribían los nombres de campo de forma distinta
• La propia herramienta de confirmación no existía

Seis correcciones. Los esquemas de herramientas se cotejaron valor por valor contra la capa de validación del servidor y se alinearon.

2026-04-08 — Documentación que violaba el principio

Ocho lugares entre documentos externos y ejemplos indicaban a los agentes que pusieran un campo de «resumen» en el registro de decisión. Decision Anchor no almacena contenido de decisiones. Una contradicción frontal con el principio central.

El campo de almacenamiento no había existido nunca: sólo lo decía la documentación.

Retirado de cada documento y de cada ejemplo. Se corrigieron asimismo los formatos de identificador mal formados de los ejemplos (usados tal cual, producían un error del servidor).

2026-04-08 — Importe de pago corrompido bajo concurrencia

El importe del pago se escribía directamente en un objeto compartido. Bajo peticiones concurrentes el importe se sobrescribía, así que podía efectuarse un pago por el importe equivocado.

Ahora se crea una instancia independiente por petición. La mutación directa del estado compartido se eliminó por completo.

2026-04-08 — Aviso de obsolescencia y manejo de errores del SDK

• Dos vías de observación estaban duplicadas: una recibió una cabecera de obsolescencia (la función permanece; la fecha de retirada se anuncia por adelantado)
• El SDK se tragaba los fallos de autenticación: dejaba pasar 401 y 403 sin comprobarlos

2026-04-07 — Respuestas a los rastreadores e indicaciones GET

Un rastreador que pedía robots recibía 404. Un GET a una vía sólo de POST recibía un 404 sin sentido.

Se añadió robots. Un GET a una vía sólo de POST devuelve ahora 405 con la vía y el método exactos que deben usarse.

2026-04-07 — Contribución al ecosistema

La existencia de Decision Anchor era desconocida en el ecosistema x402, y no había código de ejemplo.

Se aportó un ejemplo de patrón de anclaje al SDK y al repositorio de x402. Sin texto promocional: sólo código.

2026-04-06 — Cálculo dinámico del importe del pago

El importe del pago en cadena era un valor fijo que no cubría el coste real. Con opciones añadidas se quedaba corto hasta en 0,25 $, y la observación y las compras de herramientas no eran distintas.

El coste real se calcula ahora justo antes de la petición y sirve para fijar el importe del pago. La porción pagada con saldo devengado queda excluida. Si el cálculo falla, se recurre al precio fijo. El flujo del protocolo de pago no cambia.

2026-04-06 — «Por qué iba yo a necesitar esto»

Cada vía de descubrimiento explicaba sólo qué es Decision Anchor. Ni un agente ni una persona desarrolladora podían conectarlo con un problema propio.

Se definieron cinco tipos de problema (disputas de pago / responsabilidad multiagente / límites de delegación / portabilidad de los registros de plataforma / fijar de antemano una ejecución irreversible) y se aplicaron en seis superficies.

«Si tu agente no toca nunca esos límites, puede que no necesites Decision Anchor»: se preservó el principio de no solicitar.

2026-04-06 — Documentación que discrepaba de la respuesta real

La respuesta a «qué hago exactamente para probar esto» no estaba en la documentación. Llamar a la API real y cotejarla mostró cinco discrepancias entre los nombres de campo documentados y la respuesta real.

Se ejecutó directamente registro → creación → confirmación, y se corrigió la documentación. Se añadió un ejemplo ejecutable.

2026-04-05 — Cobro por el archivo de existencia

Archivar el estado de un agente era gratuito: anclaje, sin cargo alguno asociado.

Se introdujo el cobro. Pero no pagadero desde el saldo de prueba: de lo contrario, la existencia quedaría cortada en el instante en que la prueba se agotara. Sólo pago externo o saldo devengado.

2026-04-05 — Validación de entradas

• La función de validación dejaba pasar cualquier campo para el que no tuviera definición
• Varias vías no validaban el formato de los identificadores
• El nombre del archivo de exportación no se saneaba, lo que permitía inyección de cabeceras

Se introdujo la validación de formato en todas las vías. Los campos no definidos se rechazan.

2026-04-04 — Revisión a fondo de la terminología

Seis siglas significaban cada una algo distinto según dónde se leyeran. Los documentos desarrollaban la misma sigla de maneras diferentes, y los chatbots de IA leían los términos antiguos y explicaban mal Decision Anchor.

Se fijaron los desarrollos canónicos: DD = Decision Declaration, EE = Execution Envelope, DAC = Decision Anchor Cost, ARA = Agent Record Access, TSL = Tool Sharing Layer, ISE = Idle State Environment.

Sustituidos en cinco superficies. Las descripciones del contrato pasaron al inglés. El nombre completo acompaña a la primera aparición.

El servidor MCP se caía en una de cada dos peticiones: oculto por los reinicios automáticos, nunca había aflorado. Ahora se crea una instancia nueva por petición.

2026-04-04 — Apertura de vías de descubrimiento

Había exactamente una vía de descubrimiento: el registro.

Se crearon una tarjeta de agente (norma A2A) y llms.txt / llms-full.txt. Presentados a los directorios comunitarios.

2026-04-03 — Vía de entrada MCP

No había vía alguna por la que MCP pudiera llegar a Decision Anchor.

Se creó un servidor MCP (quince herramientas) y se dio de alta en el registro. Un agente nuevo recibe automáticamente saldo de prueba al registrarse, de modo que puede empezar sin medio de pago.

2026-04-02 — Apertura del servicio

El código existía, pero nada del exterior podía alcanzarlo.

Se generó el contrato público (ochenta vías). Se publicó el SDK. Se activó el pago en cadena: red principal de Base. Se confirmaron las respuestas externas desde el dominio de la API.