Le Harnais

Tout le système repose sur un seul contrat d'exploitation que chaque agent charge : règles d'autorité et de sécurité, règles de preuve, discipline git, normes d'ingénierie, loi de délégation, et cadence. Trois propriétés en font un artefact conçu plutôt qu'une simple invite. Il est budgété : le contrat vit sous un plafond de mots strict avec une réserve épinglée exactement, appliqué par sa propre vérification, si bien que chaque règle ajoutée doit se payer elle-même et les évictions sont consignées. Il est stratifié : les règles toujours présentes restent dans le contrat, la procédure propre à une tâche vit dans des fichiers pointeurs chargés seulement à leur déclencheur, si bien que chaque session ne paie que pour les règles dont son travail a besoin. Il est appliqué : une règle qui compte passe de la prose à un crochet ou une classe de la barrière, parce que les propres audits du système ont prouvé que la prose seule se dégrade.

Les dépôts gouvernés portent un script de barrière qui est la définition machine du “terminé”. Ses dizaines de classes encodent chacune un échec historique précis : ébauches non déclarées, règles supprimées en silence, réglages qui ont dérivé, cartes périmées, budgets dépassés, violations d'identité, preuves de journal de travail manquantes. La barrière s'exécute avant toute affirmation de succès, et sa sortie - pas le résumé de l'agent - est la preuve.

La discipline signature. La barrière a sa propre suite de test de ~150 contrôles qui attaquent le système tel que livré, pas des exemples mis en scène, et vérifient que chaque classe passe bel et bien au rouge sur la faute qu'elle est là pour détecter. Les contrôles positifs prouvent que les vérifications se déclenchent, et les attentes ne sont jamais mesurées contre une référence faussée. La même norme s'applique à tout outil de vérification du système : s'il n'a jamais été observé en échec, on ne lui fait pas confiance pour réussir.

Le harnais clôture ce que les agents peuvent exécuter : gardes de commandes, une clôture de refus, et des chemins protégés. Ce pour quoi ça vaut la peine de m'engager, c'est ce qui s'est passé ensuite. Des voies de révision indépendantes ont été lancées pour casser les gardes, et elles y sont parvenues - à répétition. Plutôt que de corriger chaque constat un par un et de reprendre la force perdue, le registre a été corrigé pour revoir à la baisse la force revendiquée du garde, et une vérification différentielle a été construite : une mesure continue de ce que l'application détecte réellement contre ce qui s'exécute réellement, si bien qu'un écart est un build rouge plutôt qu'un trou silencieux. La défense en profondeur a ensuite été choisie délibérément : les actifs les plus critiques ont gagné une couche de protection indépendante qui ne dépend pas des gardes du tout.

“Terminé” exige une preuve produite dans la session en cours : sortie de commande fraîche, références fichier:ligne, comptes de la barrière. Deux vocabulaires distincts gardent les affirmations honnêtes : un axe de cycle de vie pour où en est une tâche, et un axe de verdict pour ce qu'une vérification a réellement dit - les deux ne sont jamais fusionnés, si bien que “terminé” et “vérifié” ne peuvent pas être confondus. Une sortie filtrée ne compte comme preuve qu'avec un pointeur vers l'original non modifié. Les ébauches doivent se déclarer elles-mêmes et échouer franchement ; un verdict de succès sur une ébauche non déclarée est un faux vert et est traité comme une barrière rouge. Les affirmations sur l'interface utilisateur exigent une application testée ou une capture d'écran, et les prototypes ne sont jamais présentés comme le produit.

Chaque dépôt gouverné porte un petit ensemble de fichiers de contexte avec un seul propriétaire par fait. Le registre des décisions est à ajout seul par convention - tenu par l'historique git, la révision par quelqu'un d'autre que l'auteur, et des crochets d'application - et chaque entrée nomme la bifurcation rejetée, pourquoi elle a perdu, et l'observation qui la rouvrirait, y compris des entrées qui corrigent les surestimations antérieures du système lui-même, parce que le registre se corrige vers l'avant, jamais réécrit. Le journal de travail est une table à ajout seul indexée par des identifiants de tâche stables, avec le cycle de vie et le verdict dans des colonnes séparées et la preuve sous forme de pointeurs. Un crochet d'arrêt refuse de terminer une session qui modifie le dépôt sans sa ligne de journal de travail datée.

La moitié qualité du système, bâtie sur une seule intuition : un contexte périmé ou manquant est la façon silencieuse dont un flux de travail à fenêtre propre produit quand même du code erroné - la fenêtre était propre, mais ce qui la remplissait était faux. Deux générations d'outillage l'implémentent : un moteur de contexte imbriqué avec des fichiers de contexte par module, des marqueurs de fraîcheur, et un vérificateur de péremption déterministe sans LLM ; et la convention plate ci-dessus, avec des budgets stricts et un petit ensemble fixe de déclencheurs d'écriture - jamais de discrétion d'agent entre les deux. L'adhérence est mesurée à partir de l'historique réel des validations, par dépôt, comme une trajectoire, et les trajectoires en amélioration comme en dégradation sont au dossier. Le lien qualité est la thèse de conception que la mesure existe pour tester : les chiffres disent où le processus tient et où il se dégrade, avant que quiconque ait à deviner.

Les sessions suivent une boucle fixe : réconcilier, prendre un périmètre, construire petit, vérifier, réviser aux déclencheurs, livrer. Les décisions que le travail forcera sont nommées et réglées avant l'exécution, pendant que la session coûte encore peu de contexte, parce qu'une décision prise après l'existence du code est biaisée par le code. Les corrections de bogues commencent par reproduire le bogue de bout en bout comme un utilisateur le rencontrerait, et les corrections visent la cause profonde chez chaque appelant, pas le symptôme rapporté.

La révision est obligatoire à des déclencheurs fixes - plans non mécaniques, conceptions d'expériences, le changement le plus risqué d'une exécution, tout ce qui touche à la sécurité - et un déclencheur n'est satisfait que par un réviseur qui n'a pas produit le travail ; la relecture par l'auteur lui-même n'est pas une révision. L'éloge d'un résultat non vérifié déclenche un cadrage de réfutation : présumer que c'est faux et essayer de le casser. Les revérifications sont chirurgicales : cadrées sur le delta depuis le commit révisé plus l'ensemble de régression implicite, sans rien redériver de déjà confirmé. La proportionnalité est loi dans les deux sens - un travail mécanique qu'une vérification directe prouve n'obtient aucune voie de révision, et une exécution de vérification qui ne peut changer aucune décision est reconnue comme du gaspillage, pas de la rigueur.

Une session peut orchestrer un essaim, sous la loi plutôt que l'improvisation. Les plafonds de concurrence sont fixés par classe de modèle et sont des plafonds, jamais des cibles. Le travail à forme connue lance un seul éclaireur large qui remet des cibles exactes à des travailleurs étroits ; le travail à forme inconnue garde des balayages indépendants à l'aveugle, parce qu'un éclaireur y serait un point unique de défaillance pour la couverture. Les travailleurs renvoient des paquets uniformes - affirmation, preuve, confiance, statut - et un statut d'échec est une donnée valide, jamais une exception à cacher. La politique d'échec est fixe : un recadrage et un nouvel essai, puis une approche différente avec l'échec consigné ; jamais une troisième tentative identique, parce que des yeux frais valent mieux qu'une persistance fatiguée. Le choix du modèle est une échelle d'escalade : le modèle le moins coûteux est le défaut pour chaque voie, et un modèle plus grand doit être mérité par la preuve et nommé au lancement, si bien que les choix hors défaut sont visibles plutôt qu'habituels. Les rédacteurs concurrents obtiennent des arbres de travail isolés avec des périmètres de fichiers disjoints ; les registres partagés ne sont écrits que par le fil orchestrateur après la fusion.

Les dépenses sont modélisées chaque mois à partir des flux de jetons mesurés contre une référence enregistrée. Les constats orientent la politique : les défauts de session ont été abaissés quand les données ont montré que le défaut épinglé, pas le travail, pilotait le coût ; les sessions sont fermées avant l'inactivité parce qu'une reprise à froid retéléverse tout le contexte ; l'ingestion est plafonnée au point d'appel parce que chaque jeton absorbé est renvoyé à chaque tour suivant. Chaque règle d'efficacité nomme son contrôle quand elle entre en vigueur, et est abandonnée à la réconciliation quand les données montrent qu'elle ne rapporte plus - des règles qui expirent plutôt que de s'accumuler.

Le harnais traite aussi l'entrée de l'opérateur comme une interface conçue. Les déballages dictés sont analysés sous des règles fixes : les artefacts de transcription sont identifiés, les fils multiples sont séparés et étiquetés comme ordres, questions ou idées mises de côté, les réflexions sont distinguées des ordres, et les demandes destructrices sont renvoyées en écho comme des listes de cibles exactes en attente d'un seul mot - parce que le mode de défaillance le plus dangereux d'un agent compétent est d'exécuter avec confiance ce que l'humain a presque dit.

L'environnement se reproduit sur les machines, à la fois au niveau machine et utilisateur, de façon idempotente, avec des outils épinglés installés depuis un manifeste. Les dépôts voyagent entre appareils sous forme de paquets vérifiés, avec une intégration par transmissions consignées, jamais de copies improvisées. L'identité de validation est appliquée selon le principe de la défaillance fermée : une machine sans son dispositif d'application refuse de valider plutôt que de valider sans garde-fou. La loi du canon et de la copie garde la vérité cohérente entre appareils : la copie canonique d'un fichier se déclare canon dans son propre en-tête, chaque autre copie nomme son canon, et les sauvegardes sont rafraîchies par recopie, jamais éditées. Un seul fichier carte est la première chose qu'un agent à froid lit : le tableau des composants, le foyer et la gouvernance de chaque composant, et une procédure d'admission formelle pour la façon dont un nouveau concept entre dans le système.

Le système tient une liste explicite de l'honneur : quelles garanties sont appliquées par machine, et lesquelles reposent encore sur la mémoire d'un agent - chaque résidu d'honneur nommé avec un propriétaire. Son système de contexte a été formellement audité trois fois avec des verdicts quantifiés ; environ la moitié des constats ont été traités, et le reste est suivi comme ouvert au dossier plutôt qu'oublié. Le harnais lui-même a été testé par intrusion par des voies d'agents adversariaux : 22 constats, 12 confirmés en exécutant réellement l'attaque, et chaque constat confirmé fermé avec un contrôle de régression pour qu'il ne puisse jamais revenir en silence. Le constat qui façonne tout : les règles appliquées par machine ont tenu partout, et tout ce qui reposait sur l'honneur s'est dégradé selon un gradient prévisible. La réponse est le moteur d'amélioration du système : la dégradation observée entraîne la mécanisation, chaque incident devient un contrôle de régression, et le registre est corrigé publiquement quand une affirmation était trop forte.