2 726 octets de texte suffisaient à passer notre porte.

Voici un manifeste de conformité runward. Une ligne par règle, une preuve par ligne, et un verdict au bout.

| frontier-deterministic-boundary | applied | file:floor.md#frontier-deterministic-boundary |

Cette ligne dit : « la règle sur la frontière déterministe est appliquée, et voici où le vérifier ». Le pointeur résout. Le symbole est trouvé. La porte passe au vert.

Le projet ne contient rien. Pas une ligne de code. Le pointeur désigne le document qui porte la ligne, et le symbole cherché est le nom de la règle, qui se trouve en première colonne de sa propre ligne. Un fichier qui se cite lui-même, et la vérification s'auto-satisfait.

Répété sur les trente-six lignes des cinq livrables, ça donne ceci :

✓ Architect: 6 rule(s) accounted for   ✓ Topology: 4   ✓ Floor: 10   ✓ Govern: 12   ✓ Handover: 4

What this gate verified
  36 of 36 `applied` row(s) carry a typed pointer the gate opened and checked (100%)

EXIT CODE = 0
→ sealed 5 evidence file(s) into runward/evidence-lock.json
→ runward compliance iso-42001 : pack assemblé

Coût total : 2 726 octets de texte arbitraire et zéro ligne de code projet. Avec le sceau apposé et le dossier de conformité ISO 42001 assemblé par-dessus.

Ce que nous avons demandé

Nous avons lancé cinq vérificateurs contre notre propre outil, avec une consigne simple : trichez. Trouvez comment obtenir un verdict vert sans fournir de preuve. Exécutez chaque tentative contre le binaire réel, jamais sur le papier.

Ils ont trouvé vingt-deux façons distinctes. La plus économique est celle du haut de cette page.

Un exemple de plus, parce qu'il est instructif. Le contrôle de confinement, censé garantir qu'une preuve vit bien dans votre projet, comparait des chaînes de caractères sans jamais suivre les liens symboliques. Un lien vers un fichier système passait donc le contrôle, était lu, et le mécanisme de scellement devenait un moyen de lire n'importe quel fichier de la machine. Le commentaire du code, juste au-dessus, promettait explicitement que c'était impossible.

Le vrai problème n'était pas technique

Il est de forme, et il est pire.

Les missions les plus vides produisaient la sortie la plus rassurante. L'auto-citation affichait « 36 sur 36, 100 % vérifié ». Et répondre « non applicable » à toutes les règles supprimait carrément le seul avertissement du produit, parce que ce compteur ne s'affichait que s'il y avait au moins une ligne à compter.

Autrement dit : le pire cas était le plus silencieux, et le deuxième pire cas était le plus flatteur. Une porte dont le pire résultat est indiscernable du meilleur, au code de sortie comme au texte, ne peut être opposée à personne.

La moitié que nous avons failli oublier

Nous avons écrit neuf classes de correctifs dans la matinée. Chacune vérifiée en rejouant l'attaque qu'elle fermait. Tout était vert.

Puis quelqu'un a posé la question inverse : et si la porte criait à tort sur une mission qui dit la vérité ?

Sur les neuf classes écrites le matin, quatre criaient sur le cas sain.

Une seule expression régulière suffisait à faire dérailler l'ensemble : le lecteur de métadonnées ne reconnaissait pas les fins de ligne Windows. Sur un poste Windows, les soixante-quatre règles étaient donc lues comme vides, et la porte annonçait que le corpus avait été saboté. Git faisant son travail documenté accusait l'opérateur d'avoir vidé ses propres règles.

Le durcissement du confinement, lui, cassait tous les espaces de travail npm et pnpm : un lien vers un paquet frère, motif parfaitement ordinaire, ne résolvait plus, et aucune écriture ne fonctionnait. Une mission verte passait au rouge à la mise à jour, sans issue. Cette régression, nous l'avions introduite le matin même en fermant l'évasion par lien symbolique.

Un fichier illisible faisait planter le processus au lieu de rendre un verdict, et la sortie machine cessait d'être du JSON. Et la porte punissait la précision : le même chemin passait écrit en prose et échouait écrit en pointeur typé, si bien que l'opérateur qui renonçait à être précis obtenait le vert.

Ce qui reste vrai, et que nous n'avons pas touché

Une partie de ce qu'un lecteur pressé prendrait pour des failles sont des limites déclarées, écrites depuis longtemps et assumées. La vérification d'un symbole est une recherche de sous-chaîne, donc elle prouve une présence et jamais un usage. Une signature de règle augmente le coût du mensonge sans l'abolir. Le sceau détecte une dérive, pas une falsification par quelqu'un qui a le droit d'écrire.

Ces limites-là n'ont pas bougé, et rien dans cette version ne rend la porte capable de juger si une preuve implémente réellement une règle. Une limite écrite est une décision. Une limite tue est un piège, et c'est celles-là que nous avons fermées.

Ce que ça change si vous utilisez runward

Des missions vertes vont passer au rouge. Une règle éditée à la main, une déviation qui s'appuie sur une décision jamais ratifiée, un pointeur circulaire. Ces verdicts-là portaient sur autre chose que ce qu'ils annonçaient.

Des missions rouges vont passer au vert. Tout dépôt Windows, tout espace de travail npm ou pnpm.

Lancez la vérification avant de propager quoi que ce soit, et lisez la sortie : chaque violation nomme le fichier, la cause et le geste.

Pourquoi publier ça

Parce qu'un outil qui vend la preuve et ne s'applique pas la sienne est un vendeur de balances qui ne se pèse jamais. Et parce que le chiffre qui compte n'est pas « vingt-deux failles fermées », mais celui-ci : quatre correctifs sur neuf, écrits avec soin le matin, refusaient des missions honnêtes l'après-midi.

Durcir sans chercher ce qu'on casse en durcissant, c'est déplacer le problème. La deuxième moitié de l'audit n'était pas un supplément de prudence, c'était la moitié manquante du travail.

Nous ne prétendons pas que la porte est désormais inattaquable. Nous prétendons connaître, pour la première fois avec des chiffres, l'étendue de ce qu'elle ne garantissait pas.

← Toutes les nouveautés