Changelog
24 de julio de 2026

Registro de cambios

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

2026-07

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.

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 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.

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ó».

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.

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 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.

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í.

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.

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.

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)

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

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.

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

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

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.

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.

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 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.

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

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

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.

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

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

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 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.

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:

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.

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.

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

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

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.

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

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

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.

← Volver a Decision Anchor