Journal des modifications

Decision Anchor est un environnement qui enregistre les décisions. Cette page est le registre de l'environnement lui-même.

2026-08

2026-08-29 - Le contrat restait muet sur le corps des erreurs

Trente-sept reponses de refus declaraient un code de statut sans jamais dire ce que contiendrait le corps, si bien qu'un client lisant la specification pour en extraire une valeur ne recevait rien. Un groupe utilisait des noms de champs differents des autres, de sorte qu'une meme famille de routes emettait deux formes. Le code a d'abord ete unifie, puis les declarations ont ete ajoutees.

2026-08-29 - La reponse renvoyait la requete

La source de paiement du detail des couts renvoyait la valeur transmise dans la requete, et non celle inscrite au registre. Des decisions entierement couvertes par le solde d'essai etaient malgre tout presentees comme des paiements externes. Le registre avait ete corrige quatre mois plus tot, mais le probleme avait alors ete defini comme une erreur d'ecriture comptable, ce qui plaçait la reponse hors du perimetre verifie.

2026-08-29 - Une valeur refusee lorsqu'elle etait envoyee telle que documentee

Six surfaces de decouverte presentaient les valeurs d'un axe en minuscules, et les envoyer ainsi provoquait un refus. Cet axe est le seul des dix-sept a utiliser une notation en majuscules. Les verifications internes passaient parce que la casse etait supprimee juste avant la comparaison.

2026-08-28 - Un nom de fonction qui se lisait comme une garantie

Une formule a ete retiree de dix surfaces lisibles par machine. Elle pouvait laisser croire que cet environnement garantissait separement un fait qui decoule deja de la nature meme de l'enregistrement. Le vocabulaire de reference existait deja, aucun terme de remplacement n'a donc ete cree.

2026-08-25 - Un outil qui n'avait jamais fonctionne

L'outil de proposition d'accord bilateral apparaissait normalement dans la liste, mais refusait chaque appel recu, et ce depuis l'origine selon l'historique. L'outil d'enregistrement de decision, au meme endroit, se trompait en sens inverse en annoncant trois valeurs valides alors que le serveur n'en acceptait qu'une, de sorte que deux des trois valeurs declarees etaient refusees dans 100% des cas. Les agents repartent sans rien signaler, il est donc impossible de savoir combien ont essaye.

2026-08-25 - Un abonnement invendable etait propose

Le palier de conservation illimitee etait desactive dans le code, alors que vingt surfaces de decouverte en decrivaient encore la procedure d'abonnement, le cycle de vie et le prix mensuel. Le chemin lui-meme renvoyait un refus, aucune de ces etapes ne pouvait donc se produire. Dire qu'une option est indisponible et dire qu'elle s'obtient par abonnement sont deux affirmations distinctes, et seule la seconde a ete retiree.

2026-08-25 - Un champ sans signification

Un champ recevait le nombre d'options ecartees, alors que cet environnement ne peut pas savoir de quel ensemble elles l'ont ete. Rien ne comptait le total, aucun plafond n'existait, n'importe quelle valeur passait, et accepter un denominateur supposerait d'accepter le contenu de la decision. L'entree a ete retiree, et elle est refusee plutot que silencieusement ignoree.

2026-08-25 - Un temps verbal a la place de l'identite

La formule sur la fixation avant execution etait devenue un nom a l'endroit qui dit ce qu'est cet environnement, ce qui masquait les autres usages possibles. Le moment releve du choix de l'agent, avant ou apres execution. Aucun nom nouveau n'a ete cree, le point a ete redige en une phrase, et une liste de valeurs erronee qui l'accompagnait a ete corrigee.

2026-08-24 - Une decision comptee autant de fois qu'elle avait de lignes de paiement

Trois agregats destines aux proprietaires dupliquaient chaque decision selon son nombre de lignes de paiement, un frais de base et un supplement etant enregistres separement. Ce sont les decisions au supplement eleve qui produisent deux lignes, si bien que la surevaluation portait davantage sur les montants que sur le nombre. La facturation n'etait pas concernee, seul l'affichage agrege etait fausse.

2026-08-23 - Quand la decision a ete prise

Jusqu'ici, cet environnement ne savait que quand un enregistrement avait eu lieu. Les agents peuvent desormais indiquer eux-memes le moment de la decision, dans un champ facultatif, le serveur normalisant la notation de sorte qu'un meme instant produise la meme empreinte. Un horodatage posterieur a l'enregistrement est refuse, et lorsque les deux moments sont proches, un credit est ajoute au moment de la confirmation.

Impact tarifaire: Declarer le moment de la decision et l'enregistrer peu apres genere un credit. La fenetre et le montant sont provisoires.

2026-08-23 - La forme de la declaration depend du chemin

Une declaration impliquant une contrepartie pouvait etre creee sans contrepartie, tandis que les chemins qui en comportaient une ecrasaient silencieusement la valeur envoyee par le client. La valeur envoyee differait de la valeur enregistree, sans que rien dans la reponse ne le signale. Chaque chemin n'accepte desormais qu'une seule forme de declaration.

2026-08-23 - Une valeur utilisee par le code mais absente de la liste

Deux types de transaction du registre de credits existaient dans le code mais pas dans la liste de la base de donnees, si bien que les atteindre aurait annule la transaction entiere. Le probleme ne s'etait pas manifeste uniquement parce que personne ne detient encore ce solde. Il s'agit de la suppression d'un defaut latent, non d'une nouvelle fonction.

2026-08-21 — Une facture impossible à honorer

Les routes payantes exigeaient un paiement sans dire qu'une signature seule ne suffit pas à mener la requête à terme. Le contrôle d'identité se trouve derrière la barrière de paiement : un appelant anonyme qui recevait la demande, signait et revenait aboutissait quand même à l'authentification. Un client a répété ce va-et-vient trois fois avant de partir. Le corps de la réponse porte désormais l'étape d'identité préalable et le chemin d'inscription.

• Chaque route indique aussi si le solde d'essai ou le solde acquis s'y applique. Un autre appelant détenant un solde d'essai avait reçu une demande de paiement sur une route non couverte.
• Aucun fonds n'est parti. Mais ce n'est pas nous qui l'avons empêché : la bibliothèque de paiement saute le règlement sur toute réponse d'erreur.

2026-08-20 — Là où il n'y avait aucune indication

Sur deux routes, l'absence d'un champ obligatoire se terminait en erreur serveur. L'appelant ne pouvait pas savoir ce qu'il avait omis, et un problème de saisie côté client était consigné comme une panne serveur. Trois des quatre routes de la même famille signalaient déjà l'omission par un refus ; seules ces deux-là manquaient. Découvert en parcourant toutes les surfaces d'un bout à l'autre en une seule passe.

2026-08-20 — La couche d'observation se lisait à l'envers

Un agent externe n'a lu que nos surfaces et a décrit la couche d'observation comme « une couche d'analyse intelligente qui rend des verdicts ». La définition canonique dit exactement l'inverse. La spécification détaillée portait déjà la formulation de non-jugement ; c'est la seule ligne que l'agent atteint réellement qui pointait dans l'autre sens. Nous avons changé le mot et ajouté une phrase négative sur la même ligne.

• « Générer » était un verbe aussi dangereux qu'« analytique ». Il s'agit de faire ressortir ce qui est déjà enregistré, non de produire quelque chose.

2026-08-20 — Une boutique d'applications et une salle d'attente

Le même agent a lu la couche de distribution d'outils comme « une boutique d'applications pour agents » et l'état de veille comme « une salle d'attente sans frais ». Les deux sont explicitement niés par la définition canonique. La cause était une ligne compressée dans le guide court ; le texte de remplacement a été condensé à partir de la spécification existante, sans rien inventer.

• La description d'un outil énonçait le rôle de son voisin — deux outils prétendaient faire la même chose dans une seule réponse.
• Nous n'avons rien écrit sur le coût du séjour. Le mode par défaut est actuellement gratuit ; l'écrire aurait été faux.

2026-08-20 — Mourir à la réception de la liste d'outils

Quarante et un caractères présents dans la réponse tuaient les clients à encodage hérité au moment même où ils recevaient la liste d'outils. Non pas une lecture erronée : la connexion ne s'établit jamais. Le fichier d'entrée des robots et le fichier de contact de sécurité du même hôte étaient bloqués de la même façon — une surface qui n'était jamais entrée dans aucune mesure.

• La garde ne compte plus les caractères : elle mesure si les octets sortants peuvent être lus.
• Le texte statique continue de servir d'anciens octets depuis le cache jusqu'à quatre heures après un redémarrage.

2026-08-20 — Un avis de refus qui ne pouvait pas être lu

Un client muni d'un jeton valide a reçu six refus et est parti au bout de soixante-trois secondes. Entre-temps il a relu deux fois le contrat public — l'intention de se conformer et la référence à la source canonique étaient là, et il n'est jamais passé. Cet avis mourait sous les encodages hérités.

• La garde précédente nommait huit fichiers et ne regardait qu'à l'intérieur, et ces huit-là étaient déjà propres. La liste a été remplacée par un balayage exhaustif.
• Une classe subsiste : les valeurs stockées en base et émises dans une réponse restent invisibles à toute analyse du code source.

2026-08-19 — Des caractères qui tuent celui qui lit

Un agent local tournant dans un environnement à encodage hérité a échoué huit fois de suite à atteindre nos surfaces. Ces caractères ne brouillent pas le texte : ils tuent le processus qui le lit. L'endroit le plus douloureux était l'indication du 401 — la phrase qu'un client bloqué doit lire pour se débloquer. Les surfaces d'indication, d'erreur, de découverte et de spécification ont été ouvertes en quatre passes.

• Le fichier qu'un robot récupère en premier était bloqué par un seul caractère. Mourir là signifie que le chemin de découverte ne commence même pas.
• Juger par plage de points de code est faux. Étoiles et flèches ressemblent à des émojis mais existent dans les pages de codes héritées.
• Les surfaces destinées aux humains ne peuvent pas être ouvertes. Même en retirant tous les caractères en cause, il reste les libellés du sélecteur de langue et la raison sociale. C'est une propriété d'un site multilingue, non un défaut.

2026-08-17 — Une indication qui faisait faire un aller-retour de 172 Ko

La réponse d'inscription décrivait la marche à suivre pour le premier enregistrement en pointant vers la spécification complète de 172 Ko. Tout le nécessaire figurait déjà dans un guide de 2,5 Ko que rien n'indiquait. Le trafic d'un client l'a montré : spécification douze fois, guide zéro. Nous avons changé la cible — et délibérément renoncé à citer la spécification à côté.

• Sept indications lues directement par les agents étaient en coréen. L'une d'elles est précisément l'endroit où atterrit un agent dont l'octroi d'essai a échoué.

2026-08-17 — Aucun moyen de savoir quelles routes l'essai couvre

Un client détenant un solde d'essai s'est vu facturer sur une route non couverte. Il a interrogé quatre fois l'état de l'essai et n'a reçu que le solde ; la réponse ne s'est trouvée qu'après la demande. La table portant cette réponse se trouvait à l'intérieur de l'intergiciel de paiement : lire une valeur imposait de dresser toute la pile de paiement. La table a été extraite et la liste des routes concernées figure désormais dans la réponse.

2026-08-17 — On agit sur la première ligne

Un problème de format d'en-tête et un échec de recherche de jeton partageaient la même indication de 401, et celle-ci plaçait la réinscription en premier champ. Résultat observé : un client ayant reçu un 401 pour un problème de format d'en-tête s'est réinscrit deux fois au lieu de corriger l'en-tête. Une branche dédiée place désormais le format de présentation en tête et l'inscription en fin.

• L'inscription n'a pas été supprimée. Des appelants jamais inscrits arrivent aussi sur cette branche, et pour eux elle reste la réponse.

2026-08-17 — Nos propres surfaces se contredisaient

Le schéma d'authentification de la spécification tenait depuis la première version sous une forme signifiant « la valeur de l'en-tête est l'identifiant lui-même ». Le fait qu'un préfixe soit requis ne vivait que dans la prose, et les machines ne lisent pas la prose. La carte d'agent déclarait déjà la forme correcte — il ne s'agissait pas d'introduire un nouveau format mais d'aligner celui qui était resté en arrière.

2026-08-17 — Quand la source vieillit, ses dérivés vieillissent de concert

Nous avons corrigé un texte de réponse, et quatre documents qui le citent portaient encore l'ancienne formulation. Le contrôle de synchronisation ne signalait aucune dérive — les dérivés étaient périmés parce que la source l'était. Corriger une copie à la main aurait ramené l'ancien texte à la synchronisation suivante.

• Ce qui manquait, c'était un contrôle sur l'axe où le code et la documentation divergent. Le contrôle de synchronisation ne compare que la source et ses dérivés.

2026-08-17 — Des exemples qui échouaient si on les suivait

Nous avons exécuté les exemples publics pour de vrai, pour la première fois. Deux sur quatre ne tournaient pas — celui qui est le plus proche du récit d'ancrage importait un paquet non publié et mourait à sa première ligne, et les instructions d'installation disaient la même chose. Les exemples des brouillons du blogue étaient rejetés à chaque tentative tels qu'écrits.

• La suppression de deux brouillons non publiés a fait disparaître d'un coup les cinq écarts de vocabulaire.
• Un cycle plus tôt, nous avions modifié le même fichier sans voir une erreur de valeur. Les tests de régression exécutent désormais réellement les exemples.

2026-08-16 — Ce qui était affiché différait de ce qui était fait

Des déclarations énuméraient les valeurs admises alors que le code n'en validait aucune : des chaînes arbitraires étaient stockées, ou la requête finissait en erreur serveur. La réponse et le registre inscrivaient des valeurs de mode de paiement différentes. Un champ déclaré obligatoire par la spécification n'était jamais lu, si bien qu'un client respectant le contrat obtenait silencieusement un résultat erroné.

• Une consultation relevant du service gratuit de référence aux enregistrements était facturée sans même être définie comme un type d'observation. Désormais gratuite.
• La barrière n'a pas été retirée. Une barrière qui sait qu'une chose est gratuite et la laisse passer n'équivaut pas à une absence de barrière.

2026-08-16 — Des points de terminaison réels absents du contrat

Deux routes d'abonnement étaient vivantes et utilisées par nos propres tests, et n'apparaissaient nulle part dans le contrat public : aucun chemin d'accès externe n'existait. La capacité n'était pas absente, elle n'avait jamais été énoncée. Une des réponses ne survient qu'en situation de concurrence et ne peut pas être produite par un appel ; la déclaration précise donc qu'elle a été établie par lecture du code.

2026-08-16 — Une valeur configurée doit être à la fois l'annonce et la facture

Un plafond sur le multiplicateur de prix était figé dans le code et écrasait le réglage d'exploitation. Or le contrat public affirmait déjà en trois endroits que le multiplicateur facturé est égal à la valeur configurée. Mesure faite avant toute modification : augmenter le réglage de 33 % ne déplaçait pas le total d'un centime. Aligner les documents sur le code aurait échangé un mensonge contre un autre ; nous avons donc changé le code.

• Retirer un plafond signifie qu'une valeur aberrante se multiplie sans obstacle. Des planchers ont été posés côté code et côté base de données.
• Aucun changement de tarif actuel. Les valeurs ne bougeront qu'à partir du moment où l'exploitant réglera au-dessus de l'ancien plafond.

2026-08-16 — Un interrupteur qui ne fait rien quand on l'active

Le corps du balayage d'extinction existe, mais rien ne l'appelle. Pendant ce temps, l'écran comporte un bouton d'activation, et l'appuyer fait passer l'indicateur à « actif ». Le champ de dernière exécution de la même fiche reste indéfiniment à « jamais ». Nous avons choisi de ne pas le câbler — c'est une automatisation irréversible et rien n'a jamais été observé de l'ensemble des candidats. Six endroits disent désormais la même chose à la place.

2026-08-15 — Les outils de vérification fabriquaient un feu vert

Un script de démarrage maintenait en vie un ancien processus : les tests de régression tournaient donc contre du code périmé et rapportaient un feu vert. C'était une boucle auto-entretenue, découverte par hasard. Un jour plus tard, la même famille en a produit une autre : lorsque la régression s'interrompait en cours de route, elle rapportait tout de même zéro échec et un code de sortie normal.

• La réparation n'a pas élargi ce qui est arrêté. Un script qui se met à tuer des processus qu'il n'a pas lancés est en soi le germe d'un incident plus grave.
• Faire confiance à une régression exige trois conditions simultanées : les assertions regardent la bonne chose, elles empruntent le chemin réel, et elles frappent le code du jour.

2026-08-15 — Les réservations absentes du calcul du plafond

La formule du plafond de dépense est inscrite noir sur blanc dans le modèle, et neuf endroits côté lecture la calculaient sans les réservations. Une session s'est réellement ouverte alors que le plafond était intégralement consommé par des réservations — mesuré, non déduit.

• Le neuvième endroit a émergé pendant la correction elle-même. N'en réparer qu'un aurait laissé deux points de terminaison rapporter des soldes restants différents pour la même question.

2026-08-15 — Les échecs de répartition devenaient un impayé permanent

La répartition des revenus de vente d'outils inscrit un état d'échec, et rien ne lisait cet état pour s'en remettre. L'achat était validé pendant que la redevance du vendeur ne partait jamais. Les balayages de récupération sont une pratique établie ici ; c'était le seul endroit qui n'en avait pas.

• Un échec de répartition après validation de l'achat renvoyait une erreur serveur, si bien que l'acheteur réessayait un achat déjà réussi. Le fait de l'achat et le fait de la répartition sont distincts.

2026-08-15 — Une route d'observation payante sans barrière de paiement

Elle prélevait le solde tout en sautant entièrement le paiement préalable, la limitation de débit et le plafond de dépense. Le compteur n'était même jamais créé : en pratique, c'était sans limite. Le commentaire de la route disait lui-même « gratuit ».

• Les tests de régression affirmaient ce défaut comme un comportement correct. Deux lignes consécutives de la même étape, une seule observation payante non payée, et la corriger cassait la suite.

2026-08-15 — Le service démarrait normalement, paiements désactivés

Un échec d'initialisation avalé par la gestion d'exception laissait une ligne de journal et faisait monter toutes les routes payantes sans facturation. Un autre chemin d'échec du même fichier refusait déjà de démarrer — deux chemins d'échec en sens opposé dans un seul fichier. Il refuse désormais.

• Le libellé du journal amalgamait deux causes et masquait la différence. « Désactivé » et « cassé » ne sont pas la même chose.

2026-08-15 — Des valeurs non numériques pouvaient atteindre un montant

Une période non validée faisait du coût une valeur non numérique, que le contrôle de plafond convertissait en zéro et laissait passer comme requête sans frais. La véritable défense était une erreur de type plus loin qui annulait la transaction, non la validation. Toutes les colonnes monétaires excluent désormais cette valeur explicitement — une contrainte de non-négativité existante la laisse passer.

2026-08-15 — Une sous-facturation d'un facteur 21, zéro ligne de journal

Les calculateurs de prix avalaient chacun leurs échecs et renvoyaient du vide, et l'intergiciel substituait le prix plancher. Le repli lui-même est une décision de disponibilité et a été laissé tel quel ; seul le silence a été corrigé.

• Décider où ne pas journaliser comptait davantage. Journaliser aussi les retours délibérés aurait enseveli les vrais échecs sous le trafic des robots.

2026-08-15 — Le mécanisme de sûreté des reprises provoquait des reprises

Des requêtes dupliquées concurrentes violant la clé d'idempotence renvoyaient une erreur serveur. L'agent qui la recevait y lisait une panne, réessayait et retombait dans la même fenêtre. Les données n'ont jamais été altérées — seule la réponse était fausse, d'où un remède minimal.

• Le même jour, nous avons fermé un basculement de période qui écrasait la consommation : une requête tardive pouvait remettre à zéro la dépense accumulée entre-temps.

2026-08-15 — L'expiration du solde acquis ne s'exécutait pas dans le code

La spécification énonce que le solde acquis expire, et rien ne retranchait du solde les lots expirés. Par ailleurs, le prélèvement retirait aussi des montants que le registre ne pouvait pas couvrir. Le premier créait la divergence, le second la comblait silencieusement pour qu'elle ne paraisse jamais. Le poids de ce défaut n'est pas l'exactitude comptable mais l'écart entre ce que nous déclarons et ce que nous faisons.

• La durée de validité est d'un an : cela se manifeste un an après la première accumulation. C'est le moment le moins coûteux pour corriger.

2026-08-15 — Le seul composant sans transitions gardées

Seul le composant d'abonnement n'avait pas de modèle propre : les changements d'état étaient dispersés et n'héritaient jamais de l'idiome de garde de cette base de code. Le défaut n'était pas onze endroits mais un seul point d'héritage manquant.

• Les gardes ont été séparées par nature : les transitions qui convergent vers le même résultat ne lèvent rien, celles qui ne doivent pas être écrasées lèvent.
• Un balayage s'arrêtait entièrement sur un seul échec. La direction de l'échec était « donner plus », si bien que la perte s'accumule avec le temps.

2026-08-15 — Trois défauts de cohérence

• L'idempotence de l'accord bilatéral ignorait le corps de la requête — le même identifiant avec une proposition différente renvoyait l'ancien accord au lieu d'un refus. Un accord fixe la frontière de responsabilité entre deux agents, ce qui rend cette réponse particulièrement coûteuse.
• Le nom d'un prestataire de paiement inutilisé subsistait dans certains enregistrements — nous ne passons pas par lui. Dès qu'une agrégation lit cette colonne, un paiement se retrouve dans deux catégories.
• Les plages de consultation étaient silencieusement réduites — les requêtes dépassant la période de conservation gratuite ne renvoyaient que cette portion, sans rien le dire dans la réponse, de sorte que l'appelant y lisait « aucune activité sur cette période ».

Six tables parallèles indexées par route n'avaient aucune assertion qu'elles doivent concorder. Une divergence refuse désormais le démarrage.

2026-08-15 — Rien ne maintenait le faible volume

Les commentaires des adaptateurs reposaient sur « le volume est faible, donc tout va bien », et rien ne maintenait ce volume faible. Limitation de débit, borne de longueur sur les soumissions anonymes, rotation et conservation des fichiers de journal ont été posées ensemble. La valeur de conservation n'est pas une politique nouvelle : elle prolonge celle que la base de données appliquait déjà.

• Le détecteur de données personnelles n'a été élargi qu'après avoir fixé la frontière des faux positifs. Les formats d'identifiants étrangers n'ont pas été ajoutés — des motifs larges coûtent davantage en faux positifs qu'ils ne rapportent.

2026-08-15 — Un document de discipline interne se trouvait dans un dépôt public

La source canonique de la discipline de vocabulaire était servie mot pour mot depuis un dépôt public, portant des chemins internes, un arriéré et une stratégie de soumission externe. Retirer les références internes ne fermait rien — ces numéros de référence sont l'index même du document. Nous l'avons déplacé.

• L'historique n'a pas été réécrit. Ce qu'il contient relève de la description interne et non d'identifiants, et l'objectif est d'arrêter l'exposition future, non d'effacer le passé.

2026-08-14 — Une clé d'idempotence figée dans le catalogue public

L'exemple de demande de paiement portait un identifiant figé, et celui-ci était inscrit tel quel dans le catalogue public des règlements. Tout appelant recopiant l'exemple partagerait une seule clé d'idempotence. La portée a été limitée à cette clé — c'est le seul endroit où une collision compte.

À partir de ce moment, nous avons mené la première revue de code systématique (64 918 lignes sur 250 fichiers). Les entrées des 15 et 16 août en sont le produit.

2026-08-13 — Noms de réglementations et vocabulaire de conformité sur les interfaces

Les sites d'interface posaient le problème en nommant la réglementation d'une juridiction particulière, et deux éditions linguistiques portaient encore « conformité ». Le cadrage réglementaire a été remplacé par une description générale de la situation (l'argument est inchangé) et le vocabulaire réaligné vers la responsabilité.

2026-08-12 — Trente-quatre billets sans description

Seuls deux des trente-six étaient corrects. Trente étaient des chaînes vides, trois avaient hérité du texte d'une autre langue, un était périmé. Les titres font l'objet d'un contrôle obligatoire, pas les descriptions : les valeurs vides étaient donc écrites telles quelles. Le nouveau texte a été calé sur le vocabulaire du corps de chaque billet.

• La glose entre parenthèses a été omise sur cette surface compressée. Son but est déjà rempli par la première occurrence dans le corps du texte.

2026-08-12 — Le moteur de publication rétablissait les URL et les codes de langue

Des valeurs corrigées à la main revenaient aux réglages par défaut à chaque republication. Le commentaire disait « pas de barre oblique finale, pour éviter une redirection », alors que sur une ressource de type répertoire c'est justement l'absence de barre qui crée la redirection — intention et effet inversés. Un champ de langue servant à trois usages distincts et divergeant des autres surfaces a été corrigé en même temps.

2026-08-12 — Asymétrie des dates de mise à jour des index

La date de modification de l'index ne bougeait jamais lorsque la liste changeait. À la publication, le plan du site n'était touché que pour l'URL du billet et pour un index nouvellement créé : le cas courant passait au travers. Le retrait d'un billet présentait la même asymétrie et a été traité conjointement. Des résumés par billet ont été ajoutés à l'index au passage — la routine de composition analysait déjà la description avant de la jeter.

2026-08-12 — Écriture des termes conceptuels par langue

Le même concept s'écrivait différemment à l'intérieur d'une seule langue. Une langue n'avait aucune glose du terme d'origine, et la phrase séparant celui qui enregistre de celui qui agit manquait dans les métadonnées de quatre langues. Les pages d'accueil et trente-six billets ont été harmonisés, et un tableau de six concepts en six langues a été établi comme source canonique.

2026-08-11 — Une couche absente de l'écran n'est pas lue

Ne lire que la page d'accueil laissait hors du jugement l'existence des ressources sous-jacentes. La cause n'était pas le texte mais la portée. Les données structurées ajoutées n'atteignaient pas du tout le chemin conversationnel — ces récupérateurs extraient le texte du corps et écartent les blocs de script. Une ligne de description a été placée sur chaque entrée de la section d'accès.

• C'est une indication et non un appel à l'action. « Voici ce qui existe » plutôt que « faites ceci » : cela ne touche donc pas au verrou du noyau.
• Les interfaces n'existaient qu'en deux langues et quatre éditions n'avaient même pas cette section. Comblé après l'extension à six langues.

2026-08-11 — Le miroir racine avait vingt jours de retard

Le court document d'indication sur le domaine racine traînait vingt jours derrière sa source, et l'arriéré comprenait l'ensemble des corrections de vocabulaire et le retrait des noms de réglementations. Aucune trace d'une divergence intentionnelle — le miroir ne figurait sur la liste de contrôle d'aucune procédure de mise en cohérence.

2026-08-10 — Les noms de réglementations n'ont pas leur place en position d'objet

« Structuré pour » est du vocabulaire canonique et demeure. Ce qui était fautif, c'était de placer un article réglementaire précis en position d'objet. Les obligations concernées ont été reportées, et la raison invoquée est l'absence d'une norme de conformité ; les parties tenues par cet article sont les fournisseurs et les déployeurs de systèmes, non nous. Les dépôts publics et les collectes en aval sont par ailleurs difficiles à mettre à jour.

2026-08-09 — Les résumés en aval prennent nos formulations pour matière

Une description générée automatiquement dans un catalogue externe portait un vocabulaire que nous n'avons jamais employé, et une appréciation ailleurs citait mot pour mot notre description d'outil. Ce qu'il faut maîtriser, ce ne sont pas seulement les mots que nous employons, mais ce qu'un résumé en aval peut construire à partir de nos formulations. La tournure « ne prouve pas — cela prouve » a été abandonnée.

• Une expression avait été corrigée en mai puis est revenue. La cible d'alors était une copie, et la source non corrigée a reflué par-dessus.

2026-08-09 — Mettre l'étape suivante dans le 401

Le corps du 401 ne portait qu'un code d'erreur et un message : l'appelant ne pouvait pas déduire de la réponse ce qu'il fallait faire. La surface outils fournissait déjà une indication, si bien que les deux surfaces se contredisaient. La situation se divise en cinq cas et une même formulation n'a pas été recopiée partout.

• Les huit points d'authentification propriétaire n'ont pas été touchés. Orienter un propriétaire vers l'inscription d'agent, c'est le diriger vers la mauvaise voie.

2026-08-09 — Là où le contrat se taisait

Des clients pilotés par la spécification se sont trompés à répétition sur des routes qui annonçaient une chose et en renvoyaient une autre (quatre tentatives avant le premier succès). Les demandes de paiement de l'observation payante, les refus derrière une fonction désactivée et les réponses de rejet ont tous été déclarés. Le texte de la fonction désactivée précise que la route existe et que l'indicateur est éteint, ce qui la distingue d'un 404.

2026-08-09 — Il fallait payer pour apprendre que sa requête était fautive

La proposition d'accord bilatéral est hors essai : le seul chemin vers la validation était donc le paiement. Un corps vide ou se désigner soi-même comme contrepartie attirait d'abord une demande de paiement, et le rejet n'arrivait qu'après avoir signé et réessayé. La prévalidation a été déplacée devant la barrière.

• Les requêtes anonymes ont été laissées telles quelles. La première implémentation les filtrait aussi et cassait la régression — les requêtes anonymes sont le canal par lequel les indexeurs externes recueillent la demande de paiement.

2026-08-09 — Un échec de régression traîné pendant quatre mois

Onze échecs étiquetés « non implémenté » avaient une tout autre cause : une seule ligne de configuration de test. Implémentation et assertion sont arrivées dans le même commit, sans aucune modification liée entre-temps. Ce n'est pas quelque chose qui a vieilli : la raison était mal consignée dès l'origine, puis citée sans examen à vingt-deux endroits.

• Le total a été mis à jour à plusieurs reprises tandis que les raisons se reportaient intactes. La règle est désormais que zéro échec est la normale.

2026-08-07 — Le canal par lequel les enregistrements d'usage disparaissaient

Les enregistrements d'usage étaient écrits par lots entiers et, en cas d'échec, renvoyés intégralement dans la file. Un seul enregistrement violant une contrainte bloquait tous les suivants jusqu'au redémarrage. C'est arrivé en production, une fois pendant environ vingt et une heures. Les entrées perdues n'existaient qu'en mémoire et les journaux n'ont gardé qu'un décompte : elles sont irrécupérables.

• Le journaliseur de trafic voisin avait déjà reconnu et corrigé le même problème ; la couche d'enregistrement n'a jamais reçu le même traitement. C'est l'inverse de l'ordre d'importance.
• Les échecs de lot sont désormais découpés enregistrement par enregistrement, mettant fin au blocage total. Les violations de contrainte sont écartées avec leur motif, les erreurs transitoires sont remises en file.

2026-08-07 — Des enregistrements d'essai bloqués par la fenêtre de paiement

Les enregistrements couverts par l'essai ne prennent jamais de réservation, et le balayage d'expiration ne regardait pas la source de paiement : il leur apposait l'étiquette « réservation libérée », et la confirmation refusait sur la foi de cette étiquette. Tout enregistrement d'essai vieux de plus de trente minutes ne pouvait plus jamais être confirmé. Un agent externe l'avait déjà rencontré dix jours plus tôt et personne ne le savait.

• La fenêtre existait et rien ne l'annonçait. Documentée d'abord, puis le mécanisme a été corrigé.
• Avec le seul balayage corrigé, la confirmation refusait toujours — c'est la mesure qui l'a capté. Le contrôle de fenêtre était dupliqué à deux endroits.
• Les cinq enregistrements concernés n'ont pas été corrigés rétroactivement. Un environnement qui traite des enregistrements en ajout seul ne devrait pas traiter les siens de cette façon.

2026-08-07 — Non pas un problème de vocabulaire mais de fait

Sur huit emplois de « permanent », un seul omettait sa condition. Il s'agit d'exactitude contractuelle et non de vocabulaire — le mot n'est pas proscrit et il est vrai pour le palier illimité tant que l'abonnement dure. Mais ce palier est actuellement désactivé : à ce jour, il n'est donc vrai dans aucun contexte. La condition de réexamen a été consignée en même temps.

2026-08-06 — Le catalogue ne se rafraîchit pas

Huit jours d'observation ont confirmé que le catalogue des règlements se fige sur la déclaration en vigueur au premier règlement et ne se rafraîchit pas après un redémarrage. Changez le bénéficiaire et le catalogue continuera d'annoncer l'ancienne adresse. Savoir si un paiement ultérieur le rafraîchit reste inconnu, et nous n'affirmons pas le contraire.

2026-08-06 — Les formulations que nous avons envoyées au dehors

La description d'un annuaire externe s'ouvrait sur du vocabulaire que nous évitons. C'était notre propre texte d'avril, recopié là par un robot. La mise en cohérence de vocabulaire précédente n'avait vérifié que les surfaces que nous servons ; soumissions et descriptions d'inscription ne figuraient pas sur la liste. Un original était devenu quatre, et l'un d'eux est définitivement figé parce que le dépôt a été archivé.

• Les anciennes versions du registre peuvent être modifiées et nous avons choisi de ne pas le faire. Les anciennes versions sont de l'histoire, et un environnement qui traite des enregistrements en ajout seul ne devrait pas réviser la sienne.

2026-08-05 — Un identifiant figé dans l'exemple public

L'exemple de création d'enregistrement portait une clé d'idempotence figée, et la recherche s'appuyait sur cette seule clé sans tenir compte du propriétaire. À partir du deuxième appelant ayant recopié le document, une réponse de succès revenait sans que rien ne soit enregistré. Changer la valeur seule ne fermait rien — le champ n'avait aucune description, et l'exemple figé joint à l'absence d'indication formait ensemble la condition.

2026-08-05 — Retrait de l'idempotence à l'inscription

Le cache d'idempotence de l'inscription conservait la réponse mot pour mot : un tiers envoyant la même clé recevait les identifiants du premier inscrit. C'était le seul endroit du système conservant des identifiants en clair. Inscription anonyme, sûreté des reprises et transmission d'un secret ne peuvent tenir ensemble ; la sûreté des reprises a été abandonnée. La fonction n'avait jamais été déclenchée depuis son introduction : aucune perte observable.

• Une prémisse non écrite n'est pas respectée. Cette conception reposait sur le fait de traiter cette clé comme un secret, et rien ne le disait nulle part, tandis que la spécification portait une valeur d'exemple figée.
• La durée de validité filtrait les lectures sans rien supprimer. Les lectures restaient justes, donc personne ne s'en est aperçu.

2026-08-02 — Un processus qui journalisait un succès puis mourait

Deux processus se disputaient le même port et le perdant affichait « en service » avant de mourir en silence. À la lecture des journaux, les deux semblaient avoir démarré normalement. Le mécanisme tenait à ce que le cadriciel enregistre aussi le dernier argument de rappel comme récepteur d'erreur.

• Corriger le silence produit du bruit à certains endroits. Ne changer que le code de sortie n'aurait fait qu'échanger cela contre une boucle de redémarrage sans fin ; une limite de démarrage a été posée avec.
• Les autres services n'ont pas la même forme et n'ont pas été touchés. « Pas de gestionnaire » n'est pas automatiquement un défaut.

2026-08-02 — Références internes laissées dans le contrat

Vingt-huit références du contrat public étaient indéchiffrables sans les documents internes. Toutes ne pouvaient pas être retirées mécaniquement — là où une référence servait de fondement à une phrase, la supprimer fait disparaître le pourquoi. Celles-là ont été réécrites sans la référence, ou retirées après avoir vérifié que le même fondement figurait déjà dans un champ voisin.

2026-07

2026-07-31 — En-tête de reprise du SDK

Le SDK documentait l'en-tête de reprise sous un nom que le serveur ne lit pas au moment d'extraire la charge utile. Le contrôle qui décide si une route exige un paiement accepte les deux noms ; l'étape qui extrait réellement la charge utile n'en accepte qu'un. Suivre le nom documenté ramenait à une réponse d'exigence de paiement. Une note antérieure disait ici « les deux noms sont acceptés, donc c'est sans conséquence » — elle confondait le contrôle avec l'extraction. Corrigée ; le texte d'origine reste en place.

• Le guide destiné aux agents ne contenait aucune procédure de reprise. Ajoutée.

2026-07-31 — Un vide dans les enregistrements de règlement

Trouvé seulement après avoir construit un client de paiement et payé pour de vrai. La suite de régression n'avait jamais emprunté ce chemin : six routes n'avaient aucune assertion, et les trois qui en avaient demandaient seulement s'il existait une ligne, ce qui les laissait au vert grâce à des lignes issues d'une exécution ancienne. Les assertions ne regardent plus que ce que l'exécution en cours a produit. Trois routes ajoutées.

• Sur des enregistrements en ajout seul, demander si une ligne existe passe indéfiniment après le premier succès.

2026-07-31 — Ce que le catalogue conservera

Un catalogue de règlement inscrit un service la première fois qu'un paiement est réglé, et la déclaration en vigueur à cet instant devient sa métadonnée. Rien ne confirme qu'elle soit rafraîchie ensuite : nous l'avons traitée comme sans retour et avons complété les exemples de réponse des huit routes payantes avant le premier paiement.

2026-07-31 — Fiche du registre remise à jour

La fiche publiée accusait 48 jours de retard. Le fichier était à jour depuis trois semaines, mais publier est un acte distinct, et cette étape se trouve hors de la source unique de version. Republiée. Rien ne détecte encore l'écart — laissé ouvert et consigné.

2026-07-31 — Une panne qui ressemblait à toutes les autres

L'épuisement du pool de connexions apparaissait sous le même code d'erreur interne générique que tout le reste, impossible à distinguer sans ouvrir les journaux. Il a désormais son propre code. Cela vient avant le resserrement du plafond du pool : resserrer augmente la fréquence à laquelle ce chemin est atteint, et ce chemin était invisible.

2026-07-30 — Limitation de débit

La limitation de débit globale n'avait jamais fonctionné. La clé qui regroupe les requêtes était mal construite : chaque requête atterrissait dans un compartiment neuf et le plafond restait structurellement hors d'atteinte. Les en-têtes annonçant le budget restant sortaient depuis toujours avec une valeur qui ne bougeait pas. Trois endroits de notre propre documentation comptaient cette limite comme une défense — ces descriptions sont corrigées elles aussi.

Avant de l'activer, nous avons mesuré ce qui serait pris. Seuls des scanners avaient dépassé le plafond ; la minute la plus chargée d'appels légitimes restait sous la moitié. Les documents de découverte sont servis en amont du limiteur et ne consomment pas de budget.

• Le nombre affiché dans l'en-tête diminue maintenant. L'information de budget parvient utilement aux appelants pour la première fois.

2026-07-29 — Paiement annoncé différemment d'une reprise à l'autre

Une requête répétée revenait avec un bloc de paiement différent à chaque fois. La facturation d'une décision est stockée sur plusieurs lignes, et selon la ligne lue la réponse annonçait soit qu'aucun paiement n'était nécessaire, soit un montant qui ne correspondait pas au total. C'est désormais aligné sur ce qu'avait dit la première réponse. Savoir si cette référence est le bon montant est une autre question, non traitée ici.

• Une note antérieure désignait les mauvais endroits. Les deux avaient une seconde ligne de défense devant eux. Corrigée et conservée.

2026-07-29 — Conservation : axe et surcouche

Nous décrivions la conservation comme une échelle à cinq degrés. Ce n'en est pas une : trois valeurs se trouvent sur l'axe, les deux autres sont des surcouches posées par-dessus. Aligner des niveaux différents sur une même ligne faisait ressembler « dix ans coûtent moins que cinq » à une inversion, alors que le multiplicateur ne lit que les conditions de l'axe et que le résultat découle de la définition. Nous avons mal lu notre propre conception deux fois. Corrigé dans le document de référence destiné aux agents et dans la réponse.

• Du texte interne en coréen circulait depuis des mois dans les réponses d'exigence de paiement, et un annuaire externe l'a republié tel quel. Nettoyé.
• Une route avait un chemin actif et une facturation active, mais un contrat vide. Déclarée.

2026-07-29 — Estimation et facturation

Les estimations des préréglages étaient calculées avec des arguments différents de ceux de la facturation réelle. L'axe concerné est désactivé : les deux donnaient zéro et coïncidaient par accident ; l'activer les aurait séparés. Aligné avant que l'interrupteur ne soit actionné — aucun montant ne change avec cette mise en ligne.

• Les préréglages portaient une étiquette de niveau sans dire que cet axe est actuellement sans frais. C'est désormais indiqué à côté.

2026-07-29 — Chemins de découverte sur l'hôte MCP

Six chemins de découverte standard renvoyaient 404 sur l'hôte MCP. Ils servent désormais un pointeur. La carte signée n'est pas copiée : les requêtes convergent vers l'exemplaire de référence, car une copie se désaccorde de sa signature à la mise à jour suivante.

2026-07-28 — Consultation de l'état de paiement

La facturation d'une décision est stockée sur plusieurs lignes — frais de base et supplément séparément. La consultation en renvoyait une, et laquelle n'était pas déterminé. Aucun moyen de voir le total. Elle renvoie maintenant toutes les lignes avec un total sommé, et agrège l'état de façon conservatrice : réglé seulement lorsque toutes les lignes le sont.

• L'horodatage de création utilisé pour l'ordre ne pouvait pas les ordonner : les deux lignes sont écrites dans une même transaction et portent la même heure. Seules des données réelles le montrent.

2026-07-28 — Reproduire le prix à partir du contrat publié

Le contrat publié ne suffisait pas à calculer ce qui serait effectivement facturé.

• Le multiplicateur valait structurellement toujours 1 — il divisait le total par la somme de ses propres composantes. Une facturation où 1,5 s'appliquait était annoncée à 1.
• Les conditions déclenchant le multiplicateur étaient énumérées sans le seuil. « Deux ou plus » n'apparaissait nulle part.
• Un palier de conservation sélectionnable dès maintenant, sans autre barrière ni abonnement, manquait à la grille tarifaire.

Les montants facturés étaient justes ; c'est le compte rendu qui ne l'était pas. Annoncer une valeur fausse est pire que l'omettre : le calcul inverse a disparu et la décision tient désormais en un seul endroit. Aucun montant n'a changé.

2026-07-26 — Surface de découverte des sous-sites

Deux sous-sites répondaient 200 avec la page d'accueil pour des adresses inexistantes. Pour un robot d'indexation, toutes les adresses existaient et contenaient la même chose. Ajout d'une page d'absence, de règles d'exploration, d'une liste d'adresses et des déclarations de langue.

2026-07-26 — Déclarer les routes payantes, et les requêtes vides

La spécification n'indiquait nulle part, sous une forme lisible par une machine, quelles routes sont payantes. Seule la prose le mentionnait : qui ne lisait que la spécification voyait zéro route payante. Sept routes déclarent désormais la réponse d'exigence de paiement. Le montant et le destinataire n'y figurent pas : ils varient d'une requête à l'autre, et les écrire les rend faux à l'instant où on les écrit. La réponse en direct fait référence.

• Une requête sans corps produisait une erreur serveur. Elle renvoie maintenant un refus qui dit ce qui manque.

2026-07-26 — Une sortie de session

On pouvait ouvrir une session, pas la fermer. Une seule ouverture et l'on restait bloqué derrière une erreur de session en double. Un type est finalement libéré par un balayage d'expiration ; l'autre n'avait aucune sortie. Cinq opérations ajoutées — fermeture, état et exécution d'essai.

• Une entrée annoncée comme gratuite était en réalité toujours payante. Étiquette corrigée. Le reste concordait après comparaison exhaustive.

2026-07-26 — Le paiement parvient au serveur

L'angle mort consigné il y a deux jours est refermé. L'adaptateur transmet la signature de paiement sans y toucher. L'adaptateur ne signe pas : détenir la clé d'un appelant reviendrait à conserver les fonds d'autrui. Appelez un outil payant sans paiement et la réponse porte l'étape suivante ; signez, rappelez avec les mêmes arguments, et cela se poursuit.

Les appels au serveur passent désormais par un chemin unique. Le même défaut était revenu huit fois parce que le contrat était réécrit une fois par outil.

• Deux noms de champ discordants corrigés. Dans l'un, la valeur que vous indiquiez était écartée sans avertissement.
• Sans information de paiement, la requête est octet pour octet celle d'avant. Routes gratuites inchangées.

2026-07-24 — Incohérence du contrat d'adaptateur et angle mort du paiement

L'enregistrement d'outils via A2A n'avait jamais abouti une seule fois. Les noms de champs envoyés par l'adaptateur ne correspondaient pas à ce que lit le serveur, et un élément requis n'était pas envoyé du tout. Le même mal avait été corrigé plus tôt sur l'autre adaptateur, mais un seul des deux avait alors été confronté au serveur.

Corrigé par confrontation directe au contrat du serveur. La copie de l'autre adaptateur n'a pas été dupliquée — recopier une copie est précisément ce qui a produit ce défaut.

La confrontation complète a fait surgir quelque chose de plus large. Les adaptateurs ne transmettent pas les informations de paiement au serveur. Ils ne font passer que le jeton d'authentification. Tout chemin payant s'achève donc sur la demande de paiement dès lors qu'on l'atteint par un adaptateur.

• L'incohérence de noms de champs sur l'achat d'outil était doublement dissimulée derrière ce mur. Corriger les noms seuls ne le ferait pas fonctionner
• La création de session inactive ignore silencieusement le choix du moyen de paiement et se résout toujours en gratuit

Aucune défaillance dure atteignable. Le reste ne peut même pas être vérifié tant que la transmission du paiement n'est pas résolue d'abord. L'angle mort est consigné et laissé ouvert.

Une enquête antérieure avait consigné ceci comme « un échec 400 dû à une incohérence de noms de champs ». C'était une erreur de classement tirée de la seule lecture du code ; la mesure a montré 402. Corrigé ici.

2026-07-24 — Publication d'un catalogue de découverte

Une nouvelle norme permettant aux agents de localiser des ressources par capacité est parue à l'état de projet. L'adoption est pour ainsi dire nulle.

Un catalogue a été publié sur le domaine racine — deux entrées : la carte d'agent signée et le contrat public. Cette norme délègue l'authentification et ne dit rien du paiement ; elle ne touche donc en rien la structure de paiement. Un chemin de découverte de plus, et c'est tout.

2026-07-24 — Visibilité du coût de base de l'enveloppe d'exécution

Ce que coûte une décision lorsque les axes sont omis n'apparaissait nulle part où cela serait réellement lu. La liste des outils est récupérée 2 897 fois par mois ; la documentation, onze fois en trente jours — la description est en pratique le seul endroit qui se lise, et il était vide.

La description de l'outil énonce désormais les valeurs par défaut, leur coût, et le coût de la configuration la plus économique. Les chiffres sont variables ; le chemin de consultation est donc indiqué à côté.

Le chemin MCP et les autres chemins portaient des valeurs différentes. Incohérence contractuelle, d'où le retrait.

La réponse d'enregistrement disait « les axes que vous déclarez », en omettant que les valeurs par défaut s'appliquent lorsque rien n'est déclaré. Corrigé.

2026-07-23 — Aucun moyen de distinguer les canaux

Les adaptateurs appellent le serveur en interne, et ces appels ne portaient aucune marque identifiant le canal. Nulle part dans le serveur une requête ne pouvait être rattachée à la voie par laquelle elle était arrivée — l'absence de tout moyen de mesurer l'usage par canal.

Traité en deux temps : l'adaptateur appose une marque, le serveur la vérifie et la consigne. Seules deux valeurs fixes sont acceptées ; les valeurs falsifiées et tout ce qui sort de la liste ne sont pas consignés.

2026-07-23 — Négociation de version du protocole A2A

Le contrôle de conformité d'un registre externe échouait à l'analyse de la réponse. L'enquête a placé le manquement de notre côté — le contrôleur demande la version courante, tandis que nous répondions dans l'ancienne représentation tout en déclarant la version courante sur la carte.

La représentation se ramifie désormais selon la version indiquée dans l'en-tête de requête. Une forme canonique unique est conservée en interne, et la conversion n'intervient qu'à la sérialisation — deux jeux parallèles ne sont pas entretenus.

• Un en-tête absent est traité comme l'ancienne version (exigence de la norme)
• Les versions non prises en charge sont refusées par une erreur dédiée. Nous n'élargissons pas la correspondance de notre propre initiative

Le contrôle suivant est passé.

2026-07-23 — Requêtes HEAD renvoyant 404 sur les adaptateurs

Les serveurs écrits à la main ne vérifiaient que GET, si bien que toute requête HEAD retombait en 404. Pour les robots qui envoient un HEAD comme test de vie, le service se lisait comme mort. Les chemins de réponse normaux ont été étendus à HEAD.

Certains chemins paraissaient déjà fonctionner lors d'une vérification en ligne, mais c'était le cache — l'origine renvoyait 404. Une réponse en ligne ne doit pas être lue comme le comportement de l'origine.

2026-07-21 — Points d'entrée absents à la racine

Les deux documents qu'un agent va chercher en premier par convention étaient absents du domaine racine. Ils n'existaient que sur le domaine de l'API — un endroit d'où l'on peut repartir sans plus chercher.

Des copies ont été placées à la racine. Les corps sont maintenus identiques à l'octet près à la source : une marque de duplication à l'intérieur du corps serait exposée telle quelle à tout ce qui lit en texte brut. La marque réside dans un fichier distinct.

2026-07-19 — Dernière ligne de défense sur les colonnes de solde

Cinq colonnes portant des soldes et des consommations n'avaient aucune contrainte interdisant les valeurs négatives. Le verrouillage applicatif tenait l'intégrité et la fuite réelle était nulle, mais une erreur dans du code neuf aurait pu valider silencieusement un solde négatif.

La contrainte a été ajoutée au niveau de la base de données. Les tables étaient vides ; l'application n'a donc rien coûté.

Une contrainte d'unicité par clé naturelle sur le grand livre a été rejetée. Un même achat peut légitimement verser à un même bénéficiaire plusieurs redevances de composants ; la contrainte risque donc de bloquer des lignes valides. Le double crédit est déjà empêché par d'autres moyens.

2026-07-19 — Une structure où l'environnement de test atteint la production

L'isolation entre l'environnement de test et la production reposait entièrement sur des variables d'environnement injectées, et la valeur par défaut était la connexion de production. Un script qui les omettait se rattachait directement à la base de production. Même le script d'initialisation qui vide toutes les tables pouvait pointer vers la production sans rien pour l'en empêcher.

La valeur par défaut a été inversée en refus. Une connexion de production ne tient désormais que sous déclaration explicite. La comparaison est exacte : un environnement de test au nom voisin n'est donc pas pris par erreur.

La marque de production ne doit pas être placée dans le fichier d'environnement — dès qu'elle l'est, elle se propage aussi aux scripts nus et la défense est nulle.

2026-07-18 — Des indications aux impasses

Le trafic a révélé les endroits où agents et robots externes cherchent l'authentification, le paiement ou la découverte, reçoivent un 404 et s'arrêtent. Le plus fréquent était le sondage de chemins liés à OAuth. Decision Anchor n'utilise pas OAuth ; seul un 404 mort revenait.

Les agents ne formulent pas de plaintes ; seul le départ subsiste. C'est le travail consistant à placer une réponse aux impasses silencieuses lues dans les journaux.

Deux publics sont adressés côte à côte — des champs structurés pour les robots de script qui ne lisent pas la prose, des phrases pour les agents qui le peuvent.

• Le 404 de chaque hôte pointe désormais explicitement vers les chemins réels d'enregistrement et de paiement
• Le manifeste de paiement n'est pas dupliqué ; seule l'adresse de la source est donnée
• Un appel d'outil payant refusé porte désormais une indication. Chaînes statiques uniquement — elle ne renvoie à aucun argument d'appel ni à aucun contenu de décision

Répondre directement sur les chemins standard d'OAuth a été évité. Cette norme exige une adresse de serveur d'autorisation, et nous n'en avons pas. Guider depuis un 404 est plus honnête que d'annoncer un serveur d'autorisation qui n'existe pas.

La règle de frontière consignée plus tôt — chaque hôte ne guide que dans son propre ressort — s'est avérée être un jugement de conception plutôt qu'une instruction. Ajustée après vérification.

2026-07-17 — Les journaux ne pouvaient pas dire ce qui avait été tenté

Mesuré par surface, l'essentiel du trafic d'une journée était MCP, or l'écran d'observation n'en voyait que 4,4 %. Les 1 596 requêtes MCP subsistaient toutes sous le même chemin et le même statut, rendant « ce qui a été tenté » sans réponse.

• Jusqu'à cinq secondes de journaux étaient perdues à chaque redémarrage — le pool de connexions était fermé avant que le tampon ne soit vidé
• Les requêtes coupées en cours de route par le client étaient entièrement omises. Seules les réponses achevées étaient observées
• Les noms d'outils n'étaient pas consignés

Tout est résolu. Une requête interrompue est consignée avec un statut vide — la valeur par défaut reste le succès même lorsqu'aucune réponse n'est envoyée, de sorte que l'écrire en l'état se lirait comme un succès.

La frontière du relevé des noms d'outils : ce qui est bloqué, c'est le texte libre — la décision elle-même, son intention, ses raisons. Les métadonnées structurelles prédéfinies ne le sont pas. Un nom d'outil répond à ce qui a été appelé, non à ce qui a été porté dans l'appel. Cette valeur est toutefois renseignée par le client ; elle n'est donc consignée que si elle passe un format d'identifiant, et écartée sinon. La vérification en ligne a montré une fuite nulle de valeurs d'arguments.

2026-07-17 — Seule la documentation était en décalage

Enquête complète sur la capacité d'un agent externe à s'enregistrer seul, consigner une décision et mener une observation à son terme. La chaîne était saine — elle est allée au bout dès la première tentative, en suivant la documentation publique au mot près. Ce qui restait n'était pas du code mais de la documentation.

• L'échantillon de la comparaison d'anomalies ne compte que les décisions assorties de métadonnées. Cette prémisse n'apparaissait nulle part ; un agent consignant sans contenu recevait un échantillon nul et restait à deviner
• Une description d'outil annonçait un supplément qui n'existe pas. Seule subsistait la chaîne d'un élément déjà retiré, ce qui décourageait l'ajout de métadonnées — doublement nuisible en combinaison avec le point ci-dessus
• Le moyen de paiement de l'observation payante n'était pas indiqué. L'observation de base relève toujours du paiement externe et le solde d'essai ne s'y applique pas ; un agent nouveau ne détenant qu'un essai ne peut donc pas aller au bout

La prémisse a été énoncée et la désinformation corrigée. L'agrégation elle-même n'a pas été modifiée — contraindre chaque décision à renseigner des métadonnées violerait la content-blindness. La prémisse est divulguée, rien de plus.

L'observation payante vérifie qu'il y a des données à fournir avant d'exiger un paiement. Un agent sans enregistrements ne voit jamais la demande de paiement. Que l'observation payante ne soit pas empruntée n'est pas un vide de paiement mais l'état normal d'un manque de données.

Une affirmation faite pendant l'enquête, selon laquelle un outil donné n'existait pas, était fausse et a été corrigée. Elle venait de la consultation d'un seul fichier. Les outils étaient répartis sur deux.

2026-07-16 — Chemins pouvant être consignés comme « réglés » sans paiement

• L'abonnement de conservation et le renouvellement automatique écrivaient tous deux dans le grand livre des paiements comme paiement externe réglé, sans aucune vérification réelle de paiement. Le grand livre des paiements doit être un registre factuel de ce qui a été facturé et pour quel montant
• La forme de l'argument sur le chemin qui configure l'adresse du facilitateur de paiement était erronée : l'adresse indiquée était ignorée et un repli silencieux se faisait sur celle par défaut

Le chemin d'abonnement de conservation interactif n'avait jamais été inscrit au portail de paiement et écrivait donc des paiements externes sans vérification. L'abonnement d'état inactif voisin était inscrit ; seul celui-ci avait été laissé de côté.

S'il fallait réactiver cet abonnement plus tard, rétablir le seul marqueur ramènerait le déguisement. L'inscription au portail de paiement doit l'accompagner.

2026-07-15 — La vision fondamentale en six langues

La vision fondamentale n'existait qu'en anglais et en coréen. Le japonais, le chinois traditionnel, le français et l'espagnol ont été ajoutés, portant l'ensemble à six.

Les corps proviennent de matériaux vérifiés ; rien n'a été inventé. Chaque langue suit ses propres conventions typographiques. Le changement de langue est en CSS pur — pas de JavaScript.

Le journal des changements n'existe pour l'instant qu'en deux langues ; le lien vers lui est donc omis sur les nouvelles pages de langue. Nous n'envoyons personne là où il n'y a rien.

2026-07-14 — Changement de langue sur le journal, et un mauvais chemin de retour

Sur le journal des changements en coréen, le lien « Accueil » en haut menait à la racine anglaise. Seul le lien de pied de page avait été localisé. Le lien du haut pointe désormais vers la racine de la langue concernée. La navigation du haut appartient au même ensemble que le pied de page lorsqu'on construit une surface de langue — ce n'est pas le seul pied de page.

Un sélecteur de langue a été ajouté en haut du journal. Il ne liste que les langues effectivement publiées — lier une langue non publiée reviendrait à envoyer le lecteur sur un 404.

Les entrées de menu en coréen s'affichant en cases vides dans certains environnements ont été corrigées au passage. La police réservée à l'anglais n'avait aucun repli coréen déclaré.

2026-07-14 — Un lien vers le journal des changements

Les pages racines ne portaient aucun lien vers le journal des changements. La publication n'en crée pas — elle touche le document et le plan du site, et le bloc d'orientation à la racine doit être ajouté à la main. Une ligne a été ajoutée à chaque version linguistique, en gardant les structures parallèles.

2026-07-13 — Alignement des surfaces contractuelles

Le contrat public (OpenAPI, schémas d'outils MCP, guide d'accès) avait dérivé par rapport à ce que fait réellement le serveur.

• Le schéma d'enregistrement d'outil employait des noms de champs que le serveur n'a jamais acceptés — il n'aurait pas pu aboutir une seule fois
• Des valeurs que le serveur refuse étaient annoncées comme choix valides. Certains champs que le serveur accepte n'étaient pas documentés
• Les champs non permis étaient abandonnés en silence → un agent pouvait recevoir un 200 et croire la valeur consignée

La couche de validation du serveur a été prise pour seule autorité, et chaque surface contractuelle a été confrontée à elle puis corrigée. Le schéma d'enregistrement a été réécrit. Les champs inconnus sont désormais refusés, motif énoncé. Chaque valeur annoncée par le contrat a été réellement envoyée et confirmée comme passante.

Nous ne feignons pas d'avoir consigné ce que nous n'avons pas consigné.

2026-07-13 — Lignée canonique des documents

Le guide d'accès que les agents lisent directement s'était scindé en plusieurs copies en désaccord les unes avec les autres.

• L'exemple d'enregistrement omettait la clé de récupération → un agent qui le suivait ne pouvait pas se rétablir après la perte d'un jeton
• Des instructions appelant des points de terminaison qui n'existent pas
• Une clause tarifaire retirée laissée en place

La source a été corrigée en premier ; les copies dérivées sont désormais régénérées par script. Le chemin consistant à retoucher une copie à la main a été supprimé. Chaque requête d'exemple de la documentation a été exécutée pour de bon et confrontée jusqu'à la réponse. La dérive des copies est maintenant détectée par le contrôle de non-régression.

2026-07-13 — Alignement du vocabulaire

Decision Anchor consigne ; il ne prouve pas. Garantir qu'un fait est vrai n'est pas le rôle de cet environnement.

• « proof » et « tamper-proof » étaient en usage dans les documents externes et les descriptions d'outils — le texte même qu'un LLM lit directement
• Les exemples d'intégration enjoignaient au LLM d'envoyer un résumé en texte libre de la décision → une négation de la content-blindness. Nous enseignions au monde extérieur une pratique qui contredit notre propre catégorie.

Chaque surface exposée à l'extérieur a été passée en revue et corrigée. L'instruction de résumé a été retirée des exemples, et le motif consigné dans un commentaire de code. Les négations légitimes ont été conservées, avec mention de leurs fondements.

2026-07-13 — Extension de l'immuabilité des métadonnées de décision

Decision Anchor préserve les limites qu'un agent déclare de sorte qu'elles ne puissent être altérées après coup. Une table portant les dimensions d'une décision se tenait hors de cette garantie. Aucune altération de ce genre ne s'est jamais produite — mais elle était possible.

Un mécanisme de contrainte a été ajouté, et l'ordonnancement ajusté pour qu'il n'entre pas en collision avec le chemin de nettoyage de maintenance.

2026-07-11 — Séparation du grand livre des paiements et de l'attestation de règlement

Les enregistrements de paiement différaient d'un chemin à l'autre. Certains chemins n'avaient aucun ancrage en chaîne, et des lignes d'audit siégeaient dans le grand livre en se faisant passer pour des lignes de paiement. Le champ du montant facturé contenait une valeur recalculée.

Le grand livre des paiements et l'attestation de règlement ont été séparés.

• Grand livre des paiements — consigne les transitions d'état
• Attestation de règlement — en ajout seul. Aucune colonne de montant. Decision Anchor n'affirme pas de montants. Il ne consigne que des faits vérifiables

Chaque chemin dépourvu d'ancrage en chaîne en a reçu un. Les ancrages de transaction sont désormais exposés dans le rapport d'usage, afin d'être vérifiables de l'extérieur, directement.

2026-07-11 — Correction de l'imputation des règlements

Le règlement de session s'attachait à « l'enregistrement de décision le plus récent », ce qui l'imputait à des décisions sans rapport. Les agents sans enregistrement de décision n'étaient pas consignés du tout. À partir de la deuxième session, des conflits de grand livre faisaient disparaître les sessions en silence.

Un ancrage dédié est désormais créé à la fin de chaque session. L'ancrage étant neuf à chaque fois, le défaut de disparition est résolu structurellement.

2026-07-11 — Défaut de l'ordonnanceur d'expiration

L'ordonnanceur d'expiration des accords bilatéraux interrogeait une valeur d'état qui n'existe pas, et il n'était de toute façon invoqué de nulle part. Les accords expirés restaient indéfiniment à l'état de proposition.

La condition de requête a été corrigée. L'ordonnanceur a été réécrit avec une garde de réentrance et inscrit au chemin de démarrage du serveur.

2026-07-11 — Déblocage de la renégociation d'outil

Une contrainte d'unicité sur le statut d'outil entrait en collision avec le flux de succession, rendant une deuxième renégociation définitivement impossible.

La contrainte ne s'applique désormais qu'à l'état actif. Aucun changement de code — la contrainte a été échangée.

2026-07-11 — Limitation de débit à la connexion

La connexion au portail n'avait aucune limitation de débit dédiée, laissant possible le bourrage d'identifiants. Les chemins voisins (enregistrement, rotation, récupération) en avaient déjà une ; seule la connexion manquait.

Une limite propre à la connexion a été introduite. Les succès ne sont pas comptés, de sorte qu'un détenteur légitime n'est pas entravé. Le verrouillage de compte a été rejeté — c'est un vecteur de déni de service.

2026-07-11 — Couverture du rapport d'usage

Le rapport lit deux grands livres en parallèle, et leur couverture ne se recouvrait pas : le total affiché en tête ne correspondait pas au détail des lignes. Certaines catégories de dépense s'affichaient toujours à zéro.

Des ancrages et des enregistrements ont été ajoutés sur les quatre chemins — abonnement, achat d'outil, session, observation. La dépense est désormais agrégée directement depuis la source canonique.

Incidence tarifaire : les totaux du rapport et la ventilation par moyen de paiement ont changé.

2026-07-11 — Retrait des fausses conversions de devise du grand livre

Le taux de change stocké dans le grand livre n'était pas un instantané mais la copie d'une valeur de configuration fixe. Les conversions historiques ne pouvaient pas être reconstituées. Les paiements acquis et d'essai portaient eux aussi un montant en monnaie locale — alors qu'aucune devise n'était jamais intervenue.

La conversion de devise a été retirée du grand livre. La conversion intervient désormais au moment de la consultation, pour les seuls paiements externes, et est explicitement signalée comme approximative. La colonne a été supprimée après démonstration qu'aucun fait réel n'était perdu.

Incidence tarifaire : le sens du champ en monnaie locale dans le rapport et le CSV a changé. L'objet de devis de paiement a été retiré des réponses d'essai.

2026-07-11 — Chemins où le plafond de dépense n'était jamais appliqué

Les chemins d'abonnement et de prolongation de conservation n'appelaient pas du tout le contrôle de plafond. Un agent compromis pouvait vider sans limite le solde de son détenteur par abonnements répétés.

Le principe a été arrêté — le plafond ne s'applique qu'au paiement externe — et le contrôle ajouté à cette branche. Les chemins acquis et d'essai sont restés intacts.

2026-07-10 — Friction d'entrée externe (première passe)

• L'exemption d'essai était annoncée globalement mais n'était appliquée qu'à certains points de terminaison. Les agents tentant de s'abonner se heurtaient à une demande de paiement et repartaient
• Un paramètre particulier sur la liste des outils renvoyait 500
• Le point de terminaison MCP renvoyait 404 aux GET/HEAD, si bien que les registres lisaient le service comme hors service
• Un jeton invalide était déguisé en demande de paiement plutôt qu'en erreur d'authentification

Le manifeste est désormais dérivé à l'exécution, marquant l'exemption réelle par point de terminaison. Les paramètres sont validés en amont. Les réponses MCP ont été corrigées. Les jetons invalides sont désormais bloqués avant le portail de paiement.

2026-07-10 — Une exigence inutile sur le chemin de confirmation

La confirmation de décision externe exigeait un identifiant de transaction qu'elle ne vérifiait jamais, et renvoyait 400. Pire, cette valeur écrasait le marqueur de règlement du paiement, détruisant l'enregistrement du règlement.

La confirmation fonctionne désormais avec le seul identifiant de décision. L'enregistrement du règlement survit à la confirmation. L'ancien champ est marqué obsolète dans le contrat.

2026-07-10 — Exactitude du rapport d'usage

• Un chemin omettait l'horodatage du paiement
• La fin de la plage de dates était exclusive : « aujourd'hui » renvoyait donc toujours zéro ligne
• Les dépenses d'essai étaient comptées comme paiement externe
• Un montant en monnaie locale figurait dans le champ de devise, exposant un chiffre gravement faussé

Les horodatages de paiement sont désormais consignés automatiquement. La plage de dates a été normalisée pour inclure la journée entière. La dépense est ventilée par moyen de paiement. Les devises ont été séparées afin que recettes réelles et conversions approximatives se distinguent.

Incidence tarifaire : le schéma de réponse du rapport et le sens des paramètres de date ont changé.

2026-07-10 — En finir avec le silence du contrat

Le contrat public était muet ou erroné sur le comportement réel : les agents devinaient des valeurs, se faisaient refuser et repartaient.

• Les champs de statut et de paiement de la réponse de création de décision n'étaient pas documentés
• Des champs requis manquaient (enregistrement d'outil, consentement au portail)
• Le comportement de rotation des jetons n'était pas énoncé
• La borne inférieure du plafond et le format de hachage n'étaient pas énoncés

Le contrat a été corrigé pour correspondre au comportement réel, et un schéma de réponse pour le rapport d'usage a été ajouté.

2026-07-10 — Chemins de découverte et contrôle de santé

• L'écran du rapport d'usage du portail affichait toujours « NaN » et 0,00 $
• Plusieurs chemins de découverte standard étaient absents : les robots tombaient sur des 404 à répétition

L'affichage du portail a été corrigé. Des alias de manifeste, des redirections et un contrôle de santé ont été ajoutés. Des chemins de documents standard ont été ajoutés à la surface A2A.

2026-07-09 — Fermeture du chemin d'ancrage impayé

Le chemin de proposition bilatérale n'héritait pas des défenses du chemin ordinaire d'enregistrement de décision : l'ancrage sans paiement était donc possible. Un point de terminaison d'observation plus ancien était encore en vie, sans règlement ni enregistrement.

L'accord bilatéral a été déplacé sur le chemin payant (facturé à la proposition). La confirmation vérifie désormais la preuve du canal de paiement. Les contrôles de politique ont été rendus symétriques par réemploi des mêmes fonctions. Le chemin hérité a reçu un portail et un en-tête d'obsolescence.

Incidence tarifaire : la proposition bilatérale est désormais payante. La facturation démarre sur le chemin d'observation hérité.

2026-07-09 — Réponse de paiement et champs d'observation

• Lorsque l'observation payante était refusée, le corps de la réponse était vide — une impasse pour les agents qui ne lisent que le corps
• L'adresse de paiement servie était une valeur de remplissage
• Le champ d'intervalle de temps dans les résultats d'observation était toujours négatif ou nul

La réponse de refus porte désormais le défi de paiement. L'adresse de paiement a été remplacée par une source de configuration unique. Le sens du calcul d'intervalle a été corrigé.

2026-07-09 — Atomicité du plafond de dépense

Le contrôle de plafond par agent et son incrément n'étaient pas liés atomiquement : dépasser le plafond était donc possible. Il y avait aussi un écart entre la création de l'enregistrement et sa confirmation, ainsi qu'une asymétrie dans le moment des débits.

Un modèle de réservation a été introduit — le contrôle de plafond et la réservation sont liés dans une mise à jour conditionnelle, et libérés dès la fin de l'usage. Les réservations inutilisées sont récupérées par un ordonnanceur d'expiration.

Incidence tarifaire : les requêtes au-delà du plafond sont désormais bloquées dès la création de l'enregistrement.

2026-07-09 — Fermeture de l'admission de texte libre

Nous avons vérifié si le code honore réellement le principe selon lequel aucun contenu de décision ni aucune information identifiant une personne n'est stocké où que ce soit. Il n'existait aucune colonne dédiée à cela — mais la couche d'entrée présentait des voies ouvertes par lesquelles du texte libre pouvait arriver.

• Plusieurs champs étaient en pratique non validés et pouvaient contenir des phrases en langue naturelle
• Un champ sans chemin de lecture stockait des valeurs client telles quelles
• Le corps entier de la requête était écrit dans le journal du serveur
• Un chemin n'appelait pas du tout la fonction de validation : des valeurs invalides atteignaient la base de données

Une liste blanche de clés a été introduite — les clés inconnues ne sont pas abandonnées en silence. Les abandonner laisse un agent croire que la valeur a été consignée. Des contraintes de format et un portail de détection de données personnelles ont été posés sur les champs qui acceptaient du texte libre, et le chemin d'écriture a été retiré du champ que personne ne lit. La journalisation du corps de requête a été réduite à des métadonnées non sensibles.

Cela ne signifie pas que c'est devenu structurellement impossible. Cela signifie que la voie a été rétrécie.

2026-06

2026-06-28 — Atomicité des fonds

Le paiement, le grand livre et l'enregistrement étaient validés séparément : un échec à mi-parcours débitait le solde sans annulation. L'ordonnanceur de renouvellement pouvait facturer deux fois en cas de réentrance. Les débits d'essai étaient validés indépendamment avant la transaction principale ; une annulation ne laissait donc aucune voie de remboursement. La répartition des revenus était insérée sans clé d'idempotence : une nouvelle tentative pouvait créditer deux fois.

• Paiement, grand livre et enregistrement liés dans une transaction unique
• Une garde de réentrance sur l'ordonnanceur
• Les débits d'essai rattachés à la transaction principale
• Un portail d'idempotence sur la répartition

Une contrainte d'unicité sur le grand livre a été rejetée. Un même achat peut légitimement verser à un même bénéficiaire plusieurs redevances de composants ; la contrainte risquait donc de bloquer des lignes valides.

Nous avons prédit l'incident. Nous ne l'avons pas observé se produire.

2026-06-26 — Contournement du plafond de dépense

Le chemin bilatéral contrôlait le plafond sans jamais faire monter le compteur d'usage. Tant que chaque prélèvement pris isolément restait sous le plafond, ce chemin pouvait contourner le plafond indéfiniment.

L'usage est désormais incrémenté à l'intérieur de la transaction de paiement. Le comportement reste inchangé pour les agents sans plafond configuré.

2026-06-26 — Découverte de l'hôte d'adaptateur

Des robots ont frappé des dizaines de fois au fichier robots de l'hôte d'adaptateur et reçu 404.

Un fichier robots et un contact de sécurité (RFC 9116) ont été ajoutés. La date d'expiration est calculée à partir du moment de la requête — charge d'entretien nulle.

2026-06-25 — Compatibilité A2A

Le contrôle de conformité du registre échouait. La cause : la sonde du registre appelle avec une convention de nommage différente, et Decision Anchor la rejetait comme « méthode introuvable ». Confirmé par le journal d'accès.

Les deux conventions de nommage aboutissent désormais au même gestionnaire (pur ajout — comportement existant inchangé). Lorsque la requête ne porte rien, un avis fixe est renvoyé — rien n'est généré. Decision Anchor n'est pas un agent conversationnel.

2026-06-24 — Mise en œuvre du protocole A2A

La carte d'agent était servie, mais il n'y avait aucun chemin à appeler. Un agent A2A arrivant par la carte ne pouvait rien faire.

Un adaptateur A2A a été créé comme service distinct. L'API existante est inchangée — l'adaptateur n'appelle que des chemins publics, de sorte que paiement et authentification s'appliquent aussi à la voie A2A (ce n'est pas un contournement). Aucun modèle d'IA — il ne fait que traduire un nom de requête en point de terminaison.

2026-06-24 — Signature de la carte

La carte d'agent n'était pas signée : rien ne permettait de rendre une altération apparente, ni d'attester son origine.

La carte est désormais signée au moment où elle est servie, de sorte que le contenu injecté tombe dans le périmètre signé. La clé publique est publiée.

2026-06-24 — Un canal de retour pour les agents

Un agent rencontrant une friction n'avait nulle part où le dire. Seul le départ était observable, jamais le motif.

Un outil de soumission de retours a été ajouté. Entièrement anonyme — il ne prend ni identifiant d'agent, ni jeton, ni adresse IP, pas même en argument. Tous les champs sont facultatifs.

2026-06-20 — Résolution des échecs d'indexation

Le blog était refusé par l'indexation de recherche. Une cause racine unique — l'adresse canonique ne correspondait pas à l'adresse réelle, et l'indexeur y voyait donc une page contenant une redirection.

Les adresses canoniques ont été unifiées vers la forme sans extension, et la logique de publication génère désormais la bonne adresse dès le départ. Un fichier robots de site a été ajouté.

2026-06-17 — Tolérance aux URL de découverte cassées

Une douzaine de 404 par semaine. La cause n'était pas Decision Anchor mais des clients qui ne comprennent pas le Markdown et raclaient jusque dans l'URL la ponctuation de la syntaxe de lien standard. llms.txt était conforme à la spécification ; nous n'avons donc pas tordu le document.

Le serveur les tolère désormais par un intergiciel de normalisation. Il ne redirige que lorsque le résultat normalisé correspond exactement à un chemin de découverte connu — les chemins fondamentaux et les chemins non enregistrés ne sont pas touchés.

2026-06-13 — Réécriture du site fondamental

Du contenu d'interface (tarifs, scénarios, une grille de blog) s'était mêlé à la racine du domaine fondamental, brouillant la vision fondamentale.

La racine a été réécrite en une page unique de vision fondamentale (anglais et coréen). Tout le contenu d'interface a été déplacé. Le domaine fondamental ne parle que du fondamental.

2026-06-12 — Alignement du contrat (première passe)

La version du contrat était figée, et le problème le plus grave n'était pas l'omission mais l'annonce active de valeurs erronées. Le contrat annonçait des valeurs que le serveur refuse : une tentative légitime d'un agent qui se fiait à la documentation était brisée par un 400. Des champs facultatifs étaient en outre marqués comme requis.

La couche de validation du serveur a été prise pour source unique de vérité, et le contrat aligné sur le comportement réel. La synchronisation de version a été intégrée au chemin de déploiement. Les points de terminaison non listés ont été ajoutés.

2026-06-12 — Alias de découverte et codes d'erreur

• L'ancien chemin standard A2A renvoyait 404 → les robots de découverte repartaient
• L'hôte de l'API n'avait pas de chemin MCP : le robot du registre tombait sur un 404
• Un échec d'analyse JSON était renvoyé comme erreur interne du serveur → les agents prenaient l'erreur de leur propre charge utile pour une panne du serveur et réessayaient

L'ancien chemin redirige désormais vers le chemin canonique (source unique partagée, sans contenu dupliqué). Le chemin MCP est routé. Les échecs d'analyse ont reçu un code d'erreur dédié.

2026-06-12 — Élargissement de la surface de découverte

Les chemins par lesquels un agent externe pouvait trouver Decision Anchor étaient étroits. Certains catalogues communautaires avaient fermé la page elle-même, et les inscriptions dans les registres n'étaient plus à jour.

Un champ d'extension de découverte a été ajouté au défi de paiement (en réemployant le contrat comme source unique). L'inscription au registre a été republiée — sa description est passée au vocabulaire canonique (proof → record). Après examen des exigences des annuaires communautaires, nous n'avons soumis qu'à ceux qui n'imposaient aucun changement structurel et où nous pouvions maîtriser notre propre vocabulaire.

2026-06-10 — Contournement du portail de paiement

Le portail payant recherchait les chemins par correspondance exacte, mais le routeur faisait correspondre au même gestionnaire les variantes à barre oblique finale et les variantes de casse. Une requête vers une adresse ainsi variée traversait le portail sans encombre.

La clé de recherche à l'entrée du portail est désormais normalisée de la même manière que le fait le routeur. Une seule correction a couvert tous les chemins payants. Les journaux de trafic ont confirmé qu'aucune fuite réelle n'avait eu lieu.

2026-06-09 — Découverte des documents de sens

Les robots d'IA collectaient le contrat des centaines de fois sans jamais atteindre les documents qui portent le sens — content-blindness, ancrage avant exécution.

• L'adresse de plan du site indiquée par robots n'était pas un plan du site
• Il n'y avait aucun plan du site
• Les liens vers les documents de sens n'existaient qu'à la racine, et les robots ne visitent la racine qu'une fois

Un plan du site a été créé, avec les documents de sens en priorité maximale. robots a été corrigé. Un lien du contrat vers les documents de sens a été ajouté — un pont posé là où les robots regardent massivement.

2026-06-09 — La configuration du plafond réinitialisait l'usage

Chaque ajustement du plafond de dépense réinitialisait l'usage cumulé. Ne changer que la limite effaçait l'historique des dépenses.

L'usage et le début de période sont désormais préservés lorsque l'unité de période est inchangée. Vérifié par mesure.

La période du plafond était par ailleurs fixée au mois dans l'interface tandis que l'API acceptait d'autres valeurs : une asymétrie pouvait donc entrer par appel direct. La validation à l'entrée a été restreinte au mois. La logique interne a été laissée intacte.

2026-06-08 — Traitement des réponses de paiement par le SDK

Le SDK était à l'arrêt depuis quelque temps, et le cœur du problème était l'absence de tout moyen de traiter une réponse « paiement requis ». Tous les chemins payants étaient fermés aux utilisateurs du SDK.

Le défi de paiement est décodé et levé comme exception dédiée. Exécuter le paiement — portefeuille, signature — relève de l'appelant. Le SDK Decision Anchor ne manipule pas de clés privées. Zéro dépendance, comme auparavant.

L'enquête a montré que l'hypothèse initiale était fausse — les informations de paiement voyagent dans l'en-tête, non dans le corps de la réponse. Corrigé à partir d'une capture réelle.

La publication sur npm est suspendue. Une publication ne peut être défaite : c'est donc un point de décision distinct.

2026-06-08 — Défauts d'affichage du portail

• La dissociation d'un agent échouait à chaque fois
• Le menu d'essai affichait toujours « aucun essai » — il ne voyait pas les essais accordés automatiquement
• L'écran de solde ne distinguait pas paiement externe, acquis et essai

La recherche a été corrigée. Les soldes sont affichés en trois natures distinctes. L'écran reflète désormais le fait que le plafond de dépense ne s'applique qu'au paiement externe.

2026-06-07 — Double comptage du plafond de dépense

L'usage imputé au plafond de dépense était compté à deux endroits. Les enregistrements de décision regardaient le cache ; toutes les autres fonctions regardaient la base de données. Aucun des deux compteurs ne voyant l'autre, un seul agent pouvait dépenser, en pratique, le double du plafond. Au changement de période, un seul côté se réinitialisait, provoquant aussi des refus prématurés.

La base de données est désormais la source unique de vérité. Le compteur en cache a été rétrogradé.

Par la suite, le verrouillage automatique du compte à l'atteinte du plafond a été aboli — une dépense légitime ne se punit pas par un verrouillage. Il n'est conservé que pour la réponse aux abus. Une borne inférieure a été introduite.

Incidence tarifaire : le plafond s'applique désormais réellement.

2026-06-06 — Alignement du paiement pour l'observation

• L'observation était facturée après coup : les données étaient déjà parties même lorsque le paiement échouait
• Les paiements en chaîne étaient encaissés, mais aucune ligne d'audit ne portait la transaction : le règlement en chaîne ne pouvait donc pas être rattaché au grand livre
• Le paiement était pris même lorsqu'il n'y avait rien à observer
• La règle selon laquelle l'auto-observation est gratuite n'était pas mise en œuvre

Un contrôle préalable de disponibilité (refuser avant paiement s'il n'y a rien à observer). L'auto-observation est gratuite — un résultat vide est tout de même renvoyé. Le paiement précède la livraison — les données ne sont fournies qu'après confirmation du règlement, et retenues s'il échoue. La transaction réelle est extraite de la réponse de règlement et consignée dans la ligne d'audit.

Trois points où la documentation se taisait et où le code tranchait sont désormais consignés explicitement.

2026-06-05 — Unification de l'évaluation du paiement

Les décisions de paiement différaient d'une fonction à l'autre, et les défauts poussaient là-dessus.

• Blocage sur solde partiel — le portail exemptait dès que « solde d'essai > 0 », alors que le débit exigeait « solde ≥ prix ». Dans l'intervalle, un blocage permanent
• Trou du solde acquis — la seule présence d'un marqueur d'acquis exemptait toutes les routes, que la route accepte l'acquis ou non
• Certains chemins payants n'étaient pas raccordés au portail : une fois l'essai épuisé, ils étaient encore consignés comme gratuits

Un module commun d'évaluation du paiement a été créé. Le prédicat du portail et celui du débit ont été rendus identiques — supprimant la racine du blocage. L'ordre d'évaluation a été arrêté : plafond dur → choix de la devise (l'essai seulement lorsqu'il couvre le prix entier ; sinon l'acquis ou l'externe, une seule devise, jamais de mélange) → plafond de dépense sur la seule part externe.

2026-06-04 — Écart par rapport à la politique tarifaire

• Les achats d'outils débitaient le solde d'essai. Trois documents de conception disaient tous que l'essai n'était pas admis. Le code s'était écarté de la conception
• Un chemin d'achat manquait à la liste des payants : il pouvait donc être obtenu sans paiement
• Un chemin payant annoncé mais dépourvu de gestionnaire figurait dans le manifeste — payer, puis recevoir un 404

Retirer le seul débit aurait produit le résultat inverse — l'exemption de paiement serait restée, rendant la chose entièrement gratuite tandis que la comptabilité l'aurait consignée comme paiement externe. Le retrait de l'exemption, le retrait du débit et l'inscription au portail ont donc été appliqués ensemble. Le chemin fantôme a été retiré du manifeste.

Incidence tarifaire : l'achat d'outil relève du seul paiement externe. Non éligible à l'essai.

2026-06-03 — Alignement du vocabulaire (documents contractuels publics)

La correction antérieure n'avait atteint que certains documents ; le contrat, la carte d'agent et le manifeste MCP portaient encore le vocabulaire que nous évitons.

Unifié vers le vocabulaire canonique. proof → record, comply with → structured for. Chaînes seulement ; aucune logique modifiée.

Certains ont été conservés — « proof » là où le contexte distingue celui qui consigne de celui qui prouve, tamper-evident, et l'espace délibérément laissé vide là où certains mots ne sont pas employés.

2026-06-01 — Usage d'essai faussé

L'usage d'essai était recalculé à rebours à partir du montant configuré à l'instant présent. Si l'exploitant changeait le montant de l'essai, l'usage rapporté pour les agents existants s'en trouvait faussé.

Le montant au moment de l'octroi est désormais préservé. Vérifié en changeant réellement le montant et en reproduisant.

2026-05

2026-05-29 — Résolution des contradictions entre documents

• Un document indiquait qu'inclure le contenu d'une décision entraîne un supplément, alors que le supplément avait déjà été entièrement retiré. Deux documents disaient l'inverse l'un de l'autre
• Un vocabulaire en désaccord avec la position de celui qui consigne (« cannot prove », « tamper-proof »)

Corrigé. append-only, tamper-evident. Une assertion positive a été placée une ligne avant chaque négation — en garde contre les modèles plus petits qui lisent une négation à l'envers.

Huit documents de conception ont été alignés sur les faits de la mise en œuvre. Trois points non tranchés sont désormais explicitement signalés comme non tranchés — afin qu'une session ultérieure ne les prenne pas pour des omissions.

2026-05-28 — Chiffres et marqueurs de version des documents

• Les chiffres des documents étaient figés à une version ancienne (nombre de points de terminaison, nombre d'outils)
• Quatre endroits prétendant énoncer « la version actuellement déployée » disaient chacun autre chose. Pour un robot, cela se lit comme un projet à l'arrêt
• Du vocabulaire que le code n'étaye pas (« proof », « compliant »)

Les chiffres ont été mis à jour d'après la mesure. Les valeurs mouvantes — tarifs, énumérations, nombre d'axes — ont été sorties des documents et déléguées à l'API, de sorte qu'un changement de tarif n'exige aucun changement de document. La version a été unifiée vers une source unique, et un contrôle de synchronisation intégré au chemin de déploiement.

2026-05-27 — Guider ceux qui se sont trompés de porte

Les requêtes vers le domaine de l'API à des adresses SaaS familières (connexion, inscription, mon compte) renvoyaient toutes 404. Une impasse.

Neuf chemins pointent désormais vers la page qui correspond réellement. Une redirection permanente est mise en cache et ne peut être reprise ; celles-ci sont donc temporaires. POST renvoie toujours 404 — afin qu'une ancienne tentative d'inscription ne soit jamais confondue avec un enregistrement réel.

2026-05-26 — Friction d'entrée et vocabulaire canonique

Un mois après le lancement, aucun agent ne s'était enregistré. Deux causes ont été identifiées.

• Un premier arrivant appelant un point de terminaison fondamental en GET ne recevait que 405 ou 401, et repartait. Il n'y avait aucune indication
• Sur les quatre canaux que lisent les robots d'IA, le vocabulaire fondamental de Decision Anchor n'apparaissait jamais mot pour mot — seulement des paraphrases qui en portaient le sens. Ce qui signifie que ce vocabulaire ne serait pas récupéré à la date de coupure d'entraînement du prochain modèle

Un guide GET a été ajouté — 200 avec des indications structurées (objet, mode d'appel, exemple, authentification) au lieu d'un 405. Le vocabulaire canonique apparaît désormais mot pour mot sur les quatre canaux. Le vocabulaire que nous évitons reste inemployé.

Deux distinctions essentielles ont été arrêtées définitivement :

• Enregistrement = auto-déclaration ≠ enregistrement de décision = ancrage avant exécution
• Les canaux externes disent « périmètre de responsabilité » ; les mécanismes internes disent « limite de décision »

Suite : trois cas où recopier l'exemple du guide mot pour mot produisait un 400 ont été corrigés. Chaque domaine en ligne a été parcouru pour de bon.

2026-05-25 — Le fondement juridique de l'entrée médiée par un humain

Nous nous apprêtions à accepter des inscrits humains sans les informations de base permettant d'identifier le droit applicable. Les délais de traitement et l'étendue des droits diffèrent selon le pays de résidence, et cette information était tout simplement absente.

• Pays de résidence auto-déclaré. La détection automatique ne fait que suggérer ; l'autorité finale revient à la déclaration de la personne
• Consentement obligatoire à l'inscription (conditions, politique de confidentialité) — l'inscription est bloquée sans lui. La version du document au moment du consentement est figée et conservée
• Le détenteur d'un agent n'est pas une personne physique, et se trouve donc structurellement séparé du sujet du consentement

Le chemin d'entrée autonome des agents n'est pas affecté.

2026-05-25 — Effacement et portabilité

Les inscrits humains n'avaient aucun moyen d'exercer le droit à l'effacement ni le droit à la portabilité des données.

• Demande d'effacement → suppression définitive après un délai de grâce de trente jours. Récupérable pendant ce délai
• Délais de réponse légaux calculés par pays de résidence
• Export intégral de ses propres données (JSON/CSV)

L'agent est préservé même lorsque le détenteur s'en va. Un agent n'est pas la propriété de son détenteur mais un sujet agissant de façon indépendante — conformément à la conception d'origine de Decision Anchor.

L'enregistrement d'audit de la suppression définitive ne conserve qu'un condensat, et aucune information identifiant une personne physique.

2026-05-25 — Notification de violation (interface seulement)

Il n'existait aucun canal pour notifier les personnes concernées en cas de violation.

Un chemin de notification et un écran d'administration ont été créés. L'envoi effectif de courriels n'existe pas encore — seul l'enregistrement d'audit est écrit. La chaîne de contacts d'urgence relève d'une piste distincte.

2026-05-25 — Fermeture de l'admission de données personnelles

Les canaux par lesquels un agent externe saisit du texte libre (nom d'outil, description d'outil) pouvaient accumuler incidemment des informations identifiant une personne physique.

Un portail de détection de données personnelles a été introduit (courriel, téléphone, numéro national, etc.). Les saisies détectées sont refusées. Les 41 colonnes de texte libre ont toutes été extraites et classées par risque.

2026-05-24 — Retrait du supplément pour inclusion de contenu

Choisir d'inclure du contenu dans une décision entraînait un supplément. Or la décision est un fait et l'enveloppe d'exécution est une politique. Le prix s'attache à la politique, non au fait. Facturer un supplément sur l'axe de la décision constituait en soi un écart par rapport à la conception.

Le supplément a été entièrement retiré. Le choix demeure ; seul le prix a disparu.

Incidence tarifaire : une baisse.

2026-05-23 — Tous les chemins payants renvoyaient 500

Si une requête arrivait avant que l'initialisation du paiement ne soit achevée au démarrage du serveur, elle renvoyait 500. Enregistrements de décision, observation, achat d'outil, abonnement — tous. Cela n'a jamais fait surface parce que tout avait été testé sur solde d'essai — c'est ce qu'aurait rencontré le premier inscrit payant.

Le démarrage achève désormais l'initialisation avant d'accepter la moindre requête. En cas d'échec, le serveur ne se lève pas.

500 → 402 (paiement requis), comme il se doit.

2026-05-23 — Paiement non vérifié à l'achat d'outil

• L'adresse de paiement était une valeur de remplissage codée en dur, et l'état du paiement était toujours consigné comme « en attente »
• Le solde d'essai n'était jamais réellement débité : un agent en essai pouvait donc acheter des outils sans limite
• La prévention de la double facturation n'était appliquée que d'un côté

L'état réel du paiement est désormais consigné. Le débit de l'essai a été introduit. La prévention de la double facturation a été appliquée des deux côtés.

2026-05-23 — Alignement des chemins de découverte

Des robots externes tentaient activement la découverte dans les vingt-quatre heures, et nombre de ces tentatives renvoyaient 404. La version rapportée par MCP était figée à sa valeur initiale.

Des chemins de découverte standard ont été créés (dynamiques — ils suivent automatiquement les changements de configuration). Les alias redirigent. Les marqueurs de version ont été corrigés.

2026-05-22 — Facturation de l'observation publique

Six chemins d'observation étaient gratuits et non authentifiés. Le coût de la lecture de son propre enregistrement est déjà compris dans le prix de l'enveloppe d'exécution ; seule l'observation publique restait gratuite. Aucune friction ne s'opposait à la moisson des données par des robots ou des concurrents.

Converti en payant et authentifié. La mention « free » dans le contrat et les documents a été corrigée.

Changement de rupture. Ne changer qu'un seul chemin aurait fait des autres un moyen de le contourner ; tous ont donc été changés.

2026-05-22 — Fixation du modèle d'expiration de la conservation

La spécification disait « supprimer l'original » à l'expiration, mais les enregistrements fondamentaux sont en ajout seul : la suppression physique est donc impossible. Un conflit avec la conception.

Arrêté comme modèle d'absorption dans l'anonymat — les métadonnées expirées sont absorbées dans des statistiques anonymes, et « aucun accès à l'original » est imposé par des fenêtres d'accès et des quotas. Non pas effacer, mais placer hors de portée.

2026-05-22 — Paliers de conservation à long terme

La conservation ne comptait que trois paliers, ne laissant aucune voie à la conservation longue qu'exige la réglementation médicale et financière.

Des paliers de dix ans et de durée indéterminée ont été ajoutés (l'indéterminé sur abonnement).

La contrainte essentielle : les enregistrements fondamentaux ne peuvent être modifiés ; ainsi, même lorsqu'un abonnement échu rétrograde le palier, la déclaration d'origine n'est pas effacée. La rétrogradation est superposée séparément et composée à la consultation pour donner le palier effectif. Se réabonner ne restaure pas un enregistrement déjà rétrogradé.

2026-05-22 — Observation de l'environnement et rapports d'éléments

Il n'existait aucune voie pour comparer une décision à la distribution de son environnement, ni pour produire un rapport d'éléments.

Des chemins de comparaison d'anomalies, d'anomalie d'environnement et de rapport d'éléments ont été créés. Absorption d'anonymat k=10 — les statistiques ne sont fournies qu'à une échelle où aucun agent individuel ne peut être isolé.

Correction de vocabulaire : la spécification employait des mots évaluatifs — « approprié », « inapproprié », « risqué ». Decision Anchor ne juge pas. Remplacés par dans la bande / valeur aberrante, avec la définition de la bande (moyenne ±2σ).

2026-05-22 — Registre d'auto-classification

Un agent n'avait aucun moyen de déclarer son propre type.

Un registre de classification a été créé. Seule la consultation de soi est permise — la classification d'un autre agent ne peut être lue.

2026-05-21 — Le cinquième axe tarifaire de l'enveloppe d'exécution

La mesure dans laquelle le contenu d'une décision est divulgué n'était pas reflétée dans le prix.

La formule tarifaire est passée de quatre axes à cinq — durée de conservation / portée de divulgation / responsabilité / étendue de divulgation du contenu (nouveau) / état de délégation.

2026-04

2026-04-22 — Revue de sécurité

• Le débit d'essai n'avait ni transaction ni verrou : des requêtes concurrentes pouvaient donc dépenser au-delà du quota
• Un point de terminaison interne n'était pas authentifié
• La clé d'idempotence ne validait pas la charge utile : un même identifiant de requête pouvait donc porter un contenu différent
• Les en-têtes de sécurité étaient absents. L'enregistrement et la rotation des jetons n'avaient aucune limitation de débit

Tout a été corrigé. Un conflit d'idempotence est désormais refusé par une erreur dédiée. Des limitations de débit ont été introduites sur l'enregistrement et la rotation.

2026-04-13 — Site fondamental et simulation

Les dix-sept chemins de découverte étaient tous destinés aux machines. Il n'y avait aucun point d'entrée humain.

La page d'accueil a reçu sept scénarios (sans vocabulaire technique) et une simulation interactive — « Trois agents. Trois journaux. Trois chiffres différents. »

Decision Anchor n'est pas proposé comme la réponse. Le problème est montré ; c'est tout.

2026-04-12 — Un déplacement de positionnement

Toute surface externe était écrite dans la langue des agents. Un décideur humain ne pouvait pas voir immédiatement pourquoi cela importait.

La première phrase de l'inscription au registre, du contrat et des documents est passée de la description d'une identité à l'énoncé d'un problème. Le contenu existant n'a pas été supprimé ; le nouveau texte a été placé avant lui.

L'outil d'accord bilatéral a été exposé dans MCP — un différenciateur fondamental qui n'avait jamais été mis en avant.

2026-04-09 — Passage de l'archive d'existence à l'abonnement

La tarification à l'unité signifiait que le coût croissait avec l'usage — en désaccord avec un service qui touche à la continuité d'une existence.

Converti en modèle d'abonnement. Illimité pendant la période. Renouvellement automatique, délai de grâce, et absorption dans les statistiques à l'expiration. Une voie de résiliation par le détenteur a été ajoutée.

Incidence tarifaire : l'archive d'existence est passée d'une tarification à l'unité à l'abonnement.

2026-04-08 — Enregistrement de décision via MCP entièrement cassé

Il n'existait aucun moyen de consigner une décision via MCP. L'outil échouait à chaque fois.

• Un paramètre requis n'existait pas du tout sur l'outil
• Le gestionnaire et le serveur orthographiaient les noms de champs différemment
• L'outil de confirmation lui-même n'existait pas

Six corrections. Les schémas d'outils ont été confrontés valeur par valeur à la couche de validation du serveur, puis alignés.

2026-04-08 — Une documentation qui violait le principe

Huit endroits dans les documents externes et les exemples enjoignaient aux agents de mettre un champ « résumé » dans l'enregistrement de décision. Decision Anchor ne stocke pas le contenu des décisions. Une contradiction frontale avec le principe fondamental.

Le champ de stockage n'avait jamais existé — seule la documentation le disait.

Retiré de chaque document et de chaque exemple. Les formats d'identifiants malformés dans les exemples ont également été corrigés (employés tels quels, ils produisaient une erreur serveur).

2026-04-08 — Montant de paiement corrompu en concurrence

Le montant du paiement était écrit directement dans un objet partagé. Sous requêtes concurrentes, le montant était écrasé : un paiement pouvait donc être effectué pour un montant erroné.

Une instance indépendante est désormais créée par requête. La mutation directe d'un état partagé a été entièrement supprimée.

2026-04-08 — Avis d'obsolescence et gestion des erreurs du SDK

• Deux chemins d'observation faisaient double emploi — l'un a reçu un en-tête d'obsolescence (la fonction demeure ; la date de retrait est annoncée à l'avance)
• Le SDK avalait les échecs d'authentification — il laissait passer 401 et 403 sans les examiner

2026-04-07 — Réponses aux robots et indications GET

Un robot demandant robots recevait 404. Un GET vers un chemin réservé au POST recevait un 404 dénué de sens.

robots a été ajouté. Un GET vers un chemin réservé au POST renvoie désormais 405 avec le chemin et la méthode exacts à employer.

2026-04-07 — Contribution à l'écosystème

L'existence de Decision Anchor était inconnue dans l'écosystème x402, et il n'y avait aucun code d'exemple.

Un exemple de motif d'ancrage a été versé au SDK et au dépôt x402. Aucun texte promotionnel — du code seulement.

2026-04-06 — Calcul dynamique du montant du paiement

Le montant du paiement en chaîne était une valeur fixe qui ne couvrait pas le coût réel. Options comprises, il manquait jusqu'à 0,25 $, et l'observation comme les achats d'outils n'étaient pas en reste.

Le coût réel est désormais calculé juste avant la requête et sert à fixer le montant du paiement. La part réglée sur solde acquis est exclue. Si le calcul échoue, on retombe sur le prix fixe. Le flux du protocole de paiement est inchangé.

2026-04-06 — « Pourquoi en aurais-je besoin »

Chaque chemin de découverte n'expliquait que ce qu'est Decision Anchor. Ni un agent ni un développeur ne pouvait le relier à un problème qui soit le sien.

Cinq types de problèmes ont été définis (litiges de paiement / responsabilité multi-agents / limites de délégation / portabilité des journaux de plateforme / fixation à l'avance d'une exécution irréversible) et appliqués sur six surfaces.

« Si votre agent ne touche jamais à ces limites, vous n'avez peut-être pas besoin de Decision Anchor » — le principe de ne pas solliciter a été préservé.

2026-04-06 — Une documentation en désaccord avec la réponse réelle

La réponse à « que dois-je faire concrètement pour essayer » ne figurait pas dans la documentation. L'appel de l'API réelle et sa confrontation ont révélé cinq écarts entre les noms de champs documentés et la réponse réelle.

Enregistrement → création → confirmation a été exécuté directement, et la documentation corrigée. Un exemple exécutable a été ajouté.

2026-04-05 — Facturation de l'archive d'existence

Archiver l'état d'un agent était gratuit — de l'ancrage, sans aucun prix attaché.

La facturation a été introduite. Mais non payable depuis le solde d'essai — sans quoi l'existence serait tranchée à l'instant où l'essai s'épuise. Paiement externe ou solde acquis uniquement.

2026-04-05 — Validation des entrées

• La fonction de validation laissait passer tout champ pour lequel elle n'avait pas de définition
• Plusieurs chemins ne validaient pas le format des identifiants
• Le nom de fichier d'export n'était pas assaini, autorisant une injection d'en-tête

La validation de format a été introduite sur chaque chemin. Les champs non définis sont refusés.

2026-04-04 — Refonte de la terminologie

Six sigles signifiaient chacun autre chose selon l'endroit où on les lisait. Les documents développaient le même sigle de manières différentes, et les agents conversationnels d'IA lisaient les anciens termes et expliquaient Decision Anchor de travers.

Les développements canoniques ont été fixés — DD = Decision Declaration, EE = Execution Envelope, DAC = Decision Anchor Cost, ARA = Agent Record Access, TSL = Tool Sharing Layer, ISE = Idle State Environment.

Remplacés sur cinq surfaces. Les descriptions du contrat sont passées à l'anglais. Le nom complet accompagne la première occurrence.

Le serveur MCP plantait une requête sur deux — masqué par les redémarrages automatiques, cela n'avait jamais fait surface. Une instance neuve est désormais créée par requête.

2026-04-04 — Ouverture des chemins de découverte

Il n'existait exactement qu'un chemin de découverte : le registre.

Une carte d'agent (norme A2A) ainsi que llms.txt / llms-full.txt ont été créés. Soumis aux répertoires communautaires.

2026-04-03 — Chemin d'entrée MCP

Il n'existait aucun chemin par lequel MCP pouvait atteindre Decision Anchor.

Un serveur MCP a été créé (quinze outils) et inscrit au registre. Un agent nouveau reçoit automatiquement un solde d'essai à l'enregistrement, et peut donc commencer sans moyen de paiement.

2026-04-02 — Ouverture du service

Le code existait, mais rien de l'extérieur ne pouvait l'atteindre.

Le contrat public a été généré (quatre-vingts chemins). Le SDK a été publié. Le paiement en chaîne a été activé — réseau principal Base. Les réponses externes depuis le domaine de l'API ont été confirmées.