Glossaire de l'usine

Un modèle dans une boucle : il reçoit une tâche, appelle des outils, observe les résultats et recommence jusqu'à rendre un travail. Dans l'usine, l'agent est un nœud borné à une phase nommée — jamais le chef d'orchestre.

Le mécanisme par lequel un modèle demande l'exécution d'une action (lire un fichier, lancer une commande) et en reçoit le résultat dans son contexte. C'est ce qui transforme un modèle en agent.

Le résumé automatique des anciens messages d'une session quand le contexte dépasse la fenêtre moins une réserve (reserveTokens), en gardant les plus récents (keepRecentTokens). Chaque compaction est un appel modèle de plus ; dans une usine aux phases courtes elle reste rare, sauf dans les boucles de correction en session vivante.

La quantité maximale de jetons qu'un modèle peut considérer à la fois (couramment 1 M sur les modèles récents). Tout ce qu'un agent « sait » dans une session doit y tenir — et chaque tour refacture ce qui s'y trouve.

L'entreprise qui sert un modèle par API. Un même modèle est souvent servi par plusieurs fournisseurs — c'est pourquoi le roster exige toujours un identifiant qualifié provider/id.

Réseau de neurones entraîné sur d'immenses corpus, qui prédit la suite d'une séquence de jetons. C'est le moteur de tout agent — mais un moteur seul n'est pas une usine.

Affirmation plausible mais fausse produite par un modèle. C'est une raison d'être de l'usine : ne jamais croire une déclaration d'agent sans la vérifier par du code — enveloppes validées, gates, état des lieux.

La discipline qui gouverne ce qui entre dans la fenêtre de contexte : quoi, quand, sous quelle forme. L'usine en est une application radicale — le contexte ne traverse les frontières qu'en enveloppes typées.

L'art de formuler la demande pour obtenir un meilleur résultat. Puissant mais borné : au-delà d'un certain point, le levier n'est plus dans la formulation mais dans la structure qui entoure l'agent.

L'unité de lecture, d'écriture et de facturation des modèles : un fragment de mot (3-4 caractères en moyenne). Les prix s'expriment en dollars par million de jetons, en entrée et en sortie.

Les trois étages de moteurs de l'usine — frontier, workhorse, léger — définis par ce qu'on leur achète : du jugement, de l'exécution, du volume. Chaque marche vaut un à deux ordres de grandeur de prix ; les noms de modèles tournent en quelques semaines, les étages leur survivent.

Le haut du catalogue : le plus capable et le plus cher (ordre de 5 $/M en entrée, 25 $/M en sortie au moment d'écrire). L'usine le réserve aux décisions qui portent tout le run, comme le plan.

Le bas du catalogue en prix (quelques centimes par million de jetons), suffisant pour les tâches mécaniques : reconnaissance, lecture-rapport, formatage. Le scout de l'usine en est le client type.

Modèle dont les poids sont publiés : n'importe quel hébergeur peut le servir. Son identifiant devient un marché de routes concurrentes — prix tirés vers le bas, failover naturel, et souveraineté d'hébergement possible. GLM, Kimi ou DeepSeek en sont des exemples au moment d'écrire.

Le modèle intermédiaire, capable et abordable, qui abat le gros du travail — typiquement l'implémentation. Le bon roster met le workhorse partout où le frontier n'apporte rien.

Obtenir un résultat en une seule requête, sans itération ni vérification. La baseline du livre : Plume générée en un shot — parfois brillant, jamais reproductible.

Un point d'entrée unique vers des centaines de modèles multi-fournisseurs, avec une seule clé d'API et une seule facture. OpenRouter est celle utilisée dans ce livre.

Le texte envoyé au modèle pour obtenir une réponse. On distingue le prompt système (qui l'agent est, son rôle, son contrat de sortie) du prompt utilisateur (la tâche du jour).

Compression des poids d'un modèle (fp8, fp4…) pour le servir moins cher et plus vite. Deux routes peuvent servir le même identifiant à des précisions différentes : sur une voie mécanique la nuance est invisible, sur un siège de jugement elle peut compter.

Les jetons de réflexion qu'un modèle produit avant sa réponse. Le niveau se règle (échelle off → max côté pi, budget de réflexion côté Claude Code) : haut pour ceux qui décident, bas pour ceux qui rapportent.

Le catalogue public d'une passerelle de modèles : identifiants, prix du jour, fenêtres de contexte. L'usine le consulte à zéro token via sa jauge des moteurs (model_stack.py) pour vérifier que chaque modèle du roster existe encore et ce qu'il coûte aujourd'hui — pas le jour où le roster a été écrit.

Le couple fournisseur + conditions de service qui sert concrètement un identifiant du registre à un instant donné. La passerelle choisit la route à chaque requête ; le prix facturé est celui de la route servie, pas celui affiché au registre.

Un agent lancé par un autre agent pour paralléliser ou isoler une sous-tâche, avec sa propre fenêtre de contexte. Le parent ne reçoit que le rapport final — une forme de handoff.

La liste ordonnée des transformations qui font passer un test au vert par le plus petit pas : {} → nil/null, null → constant, constant → variable, statement → statements, unconditional → conditional, scalar → collection, statement → recursion/iteration. Dans le cycle de l'usine, la transformation appliquée est déclarée dans l'enveloppe de GREEN et doit être l'un de ces pas, tel quel — un switch ou une boucle complexe signalent un test trop ambitieux.

Le décompte que porte chaque message d'assistant dans pi : jetons d'entrée, de sortie, de cache, et coût calculé depuis le registre de modèles. C'est la facture d'un tour ; additionnée sur une session, elle donne le coût que le pied de page affiche et que la trace harnais conserve.

Coder en dialoguant avec un agent sans relire chaque ligne, en jugeant au résultat. Productif pour explorer ; insuffisant dès qu'il faut de la répétabilité — c'est là que l'usine commence.

La loi fondamentale du livre. L'agent produit des propositions (du texte, du code, une enveloppe) ; c'est toujours du code déterministe qui décide si c'est accepté, rejoué ou refusé.

La latitude de décision laissée à l'agent : jugement et adaptation, payés en jetons et en variance. L'usine en donne juste assez, à l'intérieur d'une phase nommée — jamais le graphe entier.

Une ligne de l'usine qui nomme le payload — le chemin de Plume dans une gate, une recette ou le préflight. Le stamp les relève et les rapporte sans les modifier : c'est la dette que la relecture hexagonale du chapitre 27 rembourse en déplaçant le payload dans le roster.

Une façon de relire l'usine : un cœur déterministe (runner, enveloppes, gates) qui ne dépend de rien de sortant, des ports qui disent ce dont il a besoin (le port harnais, le roster, la déclaration du payload) et des adaptateurs qui le fournissent (pi, Claude Code, OpenRouter, exe.dev, SQLite). Les flèches pointent vers le cœur ; la mesure honnête est le nombre de fichiers à toucher quand une dépendance change.

Le point de comparaison que tout le reste doit battre : Plume générée en un shot par un agent seul, sans usine. Chiffrer les progrès exige de savoir d'où l'on part.

Un des N runs d'un best-of-N : une boîte, une clé jetable, un roster, un patch, une trace. Un bras rouge est un résultat, pas une panne du lot ; sa boîte reste debout pour diagnostic.

Le projet de fin de livre : une refonte de Plume en ports et adaptateurs, lancée en best-of-N sur les quatre rosters, moissonnée, comparée et tranchée à la main. Quelques dollars et une vingtaine de minutes pour quatre implémentations comparables — la première demande que l'on n'aurait pas confiée à un agent seul.

Le fichier markdown écrit à côté du test, nommé par le critère d'acceptation, qui trace un cycle TDD : la spécification, le test (fichier, classe), l'implémentation (pas TPP, refactoring, fichiers touchés relevés par le périmètre) et les décisions architecturales de l'humain. Dans l'usine, c'est une phase code, au format fixe — jamais rédigée par l'agent.

La clé d'inférence fabriquée pour un seul run, plafonnée en dollars (5 $ par défaut), datée d'expiration et révoquée au démontage. Écrite en 0600 sous adw_data/, poussée dans la boîte par fill : la boîte ne connaît que ce qu'elle peut dépenser, et le pire cas d'un agent qui déraille vaut le plafond, pas votre solde.

Le commit de référence identique reçu par tous les bras d'un best-of-N — la variable de contrôle. Le fan-out refuse un arbre de travail sale : deux commits différents, ce sont deux Plume comparées, et la comparaison des rosters devient du bruit.

Une procédure du skill, rangée dans un fichier à part et lue seulement quand une demande la justifie (« lancer un ADW », « installer »). Le chargement paresseux garde le contexte de l'agent pour la vraie tâche : ~1 500 tokens de plus, uniquement quand ils servent.

La copie d'une fiche de run rapportée depuis la tour par « sync », marquée owner: plume-tower — jamais accompagnée de la clé jetable. Règle de fusion écrite en code : une fiche fermée l'emporte toujours, sinon la copie de la tour fait foi, et une fiche à vous n'est jamais écrasée. Une copie s'observe, se moissonne et se démonte depuis votre poste ; la fiche fermée remonte ensuite à la tour.

Des compteurs tenus par le code à l'intérieur même d'une phase agent — tours, appels d'outils, coût cumulé, boucle — qui arrêtent le nœud pi au premier seuil franchi, sans négociation avec le modèle. Les seuils viennent du roster (bloc « limits ») et voyagent par l'environnement ; le motif remonte au runner par la trace et un rapport de garde, et la reprise repart dans la même session. Le code dispose pendant la phase, plus seulement après.

La frontière entre le code déterministe et l'agent. Le contexte ne la traverse que sous une forme que le code sait valider — l'enveloppe. Chaque chapitre du livre précise où passe la couture dans la pièce du jour.

L'une des deux portes pour faire entrer du travail dans une boîte : au lieu d'une commande (execute — le runner détaché, reproductible, zéro token d'orchestration), un tour de l'orchestrateur en boîte qui choisit l'ADW, formule la demande, lance et rend compte. On échange la garantie « ce qui a tourné est ce que j'ai tapé » contre du jugement — et un best-of-N se lance toujours par commande.

Même entrée, même sortie : gratuit, instantané, reproductible, possédé. Le côté du code dans la tension permanente déterminisme ↔ agence qui structure chaque pièce de l'usine.

Le préflight déterministe de l'usine (adws/doctor.py, recette just doctor) : outillage présent, pièces posées, et — depuis l'annexe A10 — nœud pi vérifié à sec : version épinglée, socle sur disque, modèles du roster réellement dans le registre de pi, batterie du socle verte. Zéro jeton, quelques secondes, un code de retour ; sait aussi rédiger l'ordonnance qui installe l'usine pi ailleurs, en deux couches.

Posture d'un contrôle qui, dans le doute, refuse : une exception dans un handler tool_call bloque l'outil, une règle « demander » sans interface bloque, un dialogue expiré vaut refus. C'est la posture attendue de toute pièce côté code déterministe : l'agent propose, et l'absence de réponse n'est jamais un oui.

Lancer la même demande sur N rosters, chacun dans sa propre boîte, en tenant toutes les autres variables (commit épinglé, demande, ADW, porte d'entrée). Dans l'usine, c'est une boucle déterministe sur les phases du cycle de vie — environ une minute et moins d'un centime par bras avant le travail lui-même.

La ligne qui sépare ce qu'une boîte peut faire de ce qu'elle ne peut pas : ce que la boîte ne peut pas faire, ce sont les clés qu'elle n'a pas — et, depuis la porte du ch. 22, les hôtes qu'elle ne peut pas joindre. Le socket Podman, le compte exe.dev et la clé de gestion restent sur l'hôte ; seule une clé jetable traverse. C'est ce qui garantit un seul niveau d'imbrication, par construction et non par effacement de fichiers.

Une vérification déterministe qui définit « fini » : tests verts, lint propre, fichier présent, JSON valide. Un échec de gate revient à l'agent en enveloppe, dans sa session encore vivante — la correction coûte moins qu'un redémarrage.

Une vérité en plusieurs commandes par contexte — build strict, tests unitaires filtrés, analyseurs — que les gates du chapitre 12 exécutent dans l'ordre, exit 0 par exit 0. Vite d'abord : une à deux minutes par tour de correction ; les vérités lentes (intégration, charge) appartiennent à la CI, avec un humain au bout.

Le régime de l'usine où la boucle orbite sans vous : les gates décident « fini », la trace enregistre, et votre contrôle se déplace vers quatre leviers — le prompt qui lance, la gate qui accepte, la moisson qui rapatrie, le démontage qui détruit. Sortir de la boucle change la forme du contrôle, pas ses mains.

Une copie cohérente de factory.db prise par l'API de sauvegarde de SQLite, convertie en journal classique et remplacée atomiquement. C'est ce que la vitre Grafana lit : le journal WAL, lui, n'est jamais lu depuis un autre système. Quelques millisecondes, zéro token.

L'entrée typée que l'extension factory-inventory.ts dépose au premier tour de chaque session pi : version de pi, modèle, extensions attendues, présentes et manquantes, preuves de provenance. Le runner la lit dans le flux JSON et refuse la phase si elle manque ou déclare un manquant — un nœud sans damage control, sans trace ou sans coupe-circuit ne passe jamais pour un run vert. Coût : zéro jeton.

Ce que la porte écrit à chaque décision — tunnel ouvert vers tel hôte, refus de tel autre — et que podman logs (just sandbox egress) vous rend. Une lecture de l'extérieur, zéro token, qui dit à qui la boîte a parlé pendant un run ; un refus n'est pas un incident, c'est une donnée.

Le moteur sur lequel le port relance une phase — une fois, dans la même session, avec le motif — quand le fournisseur du modèle demandé est en panne (429, 5xx, surcharge, plus de point de terminaison). Décision d'infrastructure, pas de rôle : il vit dans .env à côté de la clé, jamais dans le roster, et ne se déclenche jamais sur un coupe-circuit, une erreur d'outil ou le mur de temps. Le retry de pi relance le même moteur ; le secours en change.

Lire chaque bras d'un best-of-N de l'extérieur — verdict des tests, statut du run, coût réel relevé sur la clé jetable, taille du patch — puis classer : vert d'abord, puis le moins cher, puis le plus rapide. Zéro token, non destructive, rejouable ; elle propose un vainqueur, l'ingénieur dispose.

Le deuxième étage : une session de harnais vivante sur la VM, reprise à chaque tour, qui lance les ADW, les surveille et rend compte d'après la trace. Elle reçoit un brief une seule fois, ne code pas elle-même et ne connaît que la clé jetable de son run. Un tour coûte quelques centimes.

Le premier étage de commandement du hors-site : sur votre machine, il monte, remplit, délègue, observe, moissonne et démonte des boîtes — jamais une phase de l'usine en local. Sa loi : chaque action est une recette just qu'un humain pourrait taper. Il détient le moteur de boîtes (socket Podman ou compte exe.dev) et la clé de gestion, qui ne traversent jamais.

L'application que l'usine travaille — ici Plume, une app d'écriture minimaliste en Bun + TypeScript. Le livre n'enseigne pas le payload ; il enseigne l'usine qui le travaille.

Le code Python qui possède le graphe : séquencement des phases, retries, acceptation, coût. L'agent n'y a jamais accès — il vit à l'intérieur d'une phase, pas au-dessus.

Deux surfaces distinctes : le plan de contrôle gère les boîtes elles-mêmes (créer, exposer, détruire — podman network/run/rm, ou ssh exe.dev), le plan de données agit dedans (charger, provisionner, exécuter — podman exec, ou ssh <vm>). Dans l'usine, les deux restent du code déterministe derrière le port « boîte » ; l'agent n'apparaît que dans la phase execute.

Le second conteneur d'une boîte Podman, seule sortie du réseau interne : un proxy CONNECT qui n'ouvre un tunnel TLS que vers une liste d'hôtes (la passerelle de modèles, PyPI, npm) et refuse tout le reste en le journalisant, plus un relais qui publie Plume sur l'hôte. Refus par défaut : la fermeture ne vient pas du proxy mais de l'absence de route, qui rend la porte obligatoire.

La forme que prend la couture agent → code à partir du chapitre A6 : l'enveloppe traverse par un appel d'outil validé par schéma côté pi, au lieu d'un objet JSON deviné dans la prose. Le schéma est généré depuis le type Python (« envelopes.schema() ») ; la porte garantit la forme, le code garde le verdict (« check() », gates).

La mécanique par laquelle un harnais s'authentifie, rangée sans égard à la marque : une clé au jeton (une variable, révocable et plafonnable par run — la passerelle, ou un fournisseur en direct), un forfait exposé derrière une clé (la clé de l'abonnement, un point d'entrée propre au fournisseur, hors passerelle — un profil ordinaire, mais un quota mensuel à la place d'un prix au jeton), ou une session attachée au poste (un trousseau qui se rafraîchit, rien à provisionner ni à plafonner). Le livre réserve la clé au jeton à tout ce que l'usine lance sans humain.

Le dépôt plume-factory où le lecteur pose, chapitre après chapitre, chaque pièce de son usine. Son état cible vit dans PLAN.md, posé au chapitre 1.

La dépendance d'un système à la présence d'une seule personne : si chaque tour de boucle vous exige, votre attention devient la ressource rare — avant les tokens et avant les machines. Le module 6 existe pour supprimer ce risque sans supprimer le contrôle.

Assigner un étage du model stack à chaque phase d'un ADW selon la nature de son travail — jugement, exécution longue, voie mécanique. Un roster n'est qu'une politique de routage figée en YAML : en changer par l'option --config ne touche aucun script, et les gates restent identiques quelle que soit l'équipe.

La règle d'écriture des skills de l'usine : le skill tient le jugement (quelle demande, quelle porte, quand s'arrêter) et délègue tout le savoir à des recettes just, des scripts et des cookbooks chargés à la demande. Un skill d'une centaine de lignes qui route vaut mieux qu'un manuel que l'agent survole — et il ne dérive pas quand un ADW change de nom.

L'installation de l'usine dans un dépôt par copie d'un manifeste : les ADW, les modules, les rosters, la surface just et les skills — jamais le payload, le runtime ni les secrets. Idempotent : un fichier déjà présent est sauté, et le deuxième stamp sert de contrôle de dérive. Zéro token, moins d'une seconde.

La règle qui accompagne un second hôte : le filet des clés orphelines (ch. 23) raisonne par hôte alors que la liste des clés est celle du compte. Sans copie des fiches de la tour, un reap --yes lancé chez vous révoquerait la clé d'une boîte vivante montée ailleurs. On synchronise d'abord, sur chaque hôte.

Le tableau de bord déclaré dans une table de l'usine (un titre, un type de panneau, une requête SQL, une taille par ligne), rendu en JSON par le code et vérifié par une gate qui exécute chaque requête à sec. L'interface sert à regarder, pas à définir.

Le cycle NAME → RED → GREEN (TPP) → REFACTOR → TRACE tenu par l'usine plutôt que par un prompt : chaque phase agent est suivie d'une phase code qui vérifie sa règle stricte — nom en phrase métier, RED sur une assertion (jamais une compilation), un pas TPP nommé, tests intacts par empreinte, suite verte après refactor — et renvoie tout manquement à l'agent dans la même session. La pause architecturale suspend le run ; la carte d'acceptation est écrite par le code.

Une VM exe.dev persistante qui prend le rôle de poste de pilotage du hors-site : elle détient les deux credentials du chapitre 23 (sa propre clé SSH vers le moteur, la clé de gestion dans son .env) et monte, observe et démonte des boîtes sans qu'aucune machine à vous reste allumée. C'est un hôte, jamais une boîte : aucune phase de l'usine, aucun agent, aucune clé au jeton n'y tourne. Coût : l'abonnement, zéro token.

L'arbitrage permanent entre les trois coins d'un run agentique. L'usine ne le résout jamais en bloc mais phase par phase, dans le roster : la qualité s'achète là où elle décide (plan, review), le coût se comprime là où elle exécute (scout, build, document) — et les gates gagnent les trois à la fois, en code.

Un système où du code déterministe orchestre des agents bornés pour produire du logiciel de façon répétable, observable et bon marché. Le sujet du livre : vous la construisez pièce par pièce dans plume-factory.

La version minimale d'un outil que l'usine accepte, écrite dans le code qui dépend de lui (PI_MIN_VERSION dans harness.py, à côté des noms d'événements que le port lit). Le port refuse une phase dont l'inventaire rapporte un pi plus vieux ; le doctor fait la même comparaison à sec, avant tout run, pour le binaire et pour le SDK. La correction est une mise à jour, jamais un contournement.

La liste des capacités offertes à un agent (read, bash, edit, write…), traduite en drapeaux du harnais. Elle règle l'interface, pas les effets : tant que bash est là, seul le contrôle a posteriori garantit quelque chose.

La première étape d'un best-of-N par clone : le builder lit la spec et les fichiers qu'elle nomme sans rien écrire, et rend une enveloppe. C'est le contexte que tous les bras partagent — payé une fois, cloné N fois.

Un banc d'essai qui rejoue le même ADW, avec la même demande, sur chaque roster du portefeuille, et relève trois chiffres par équipe : verdict des gates, coût, durée. Contrairement à un benchmark public, il mesure le système complet — harnais, enveloppes, gates — sur vos propres flux ; son relevé est daté et se rejoue avant toute décision.

Le mécanisme qui transforme un échec de gate en travail à refaire : le code met le verdict en forme d'enveloppe et le renvoie à l'agent dans sa session vivante, par la même porte qu'un rapport d'agent. La boucle est bornée par le code, et les gates re-tranchent à chaque tour — la reprise coûte quelques milliers de jetons, pas un run entier.

Une modification hors périmètre détectée par l'état des lieux. Ce n'est pas une gate : l'écriture a déjà eu lieu, on ne la corrige pas en re-promptant — elle est annulée et la phase meurt en nommant chaque chemin.

Dix lignes, versionnées dans le roster, que l'usine injecte en tête de l'ask du builder avant la spec : conventions du domaine, dépendances autorisées, ce qu'on ne touche pas, les vérités qu'on ne lance pas ici. Du code, pas du prompt : identique pour tous les moteurs, relu en revue — et renvoyé à chaque tour, donc court. Le savoir long reste dans le dépôt.

L'agent qui implémente la spec, exactement, rien de plus : le plus petit changement qui la satisfait, chaque fichier modifié déclaré dans son enveloppe. Déclaré au roster sur un modèle workhorse avec un thinking élevé, libre dans le repo hors fichiers protégés — et vérifié deux fois après coup : l'état des lieux pour le droit, les gates pour la vérité.

Les trois classes de chemins du damage control : zero-access (ni lire ni écrire — les secrets), read-only (lire oui, modifier non — la machinerie de l'usine et le nœud pi) et no-delete (modifier oui, supprimer ou déplacer non — le runtime, les specs). Chaque cercle vise des outils différents ; sur bash, la détection est textuelle et l'état des lieux du runner reste la garantie.

Une séquence d'étapes fixée dans un fichier, où chaque étape est un sous-agent isolé et où la sortie de l'étape N devient l'entrée ($INPUT) de l'étape N+1. C'est la seule forme d'orchestration multi-agents que l'usine retient côté harnais, parce que le code — le fichier — décide de l'ordre ; sans gate, elle sert à explorer, jamais à livrer.

L'identifiant de session que le port harnais choisit pour pi (--session-id) et que le runner déclare au journal dans un événement phase_session. C'est par cette clé que la trace harnais rejoint les phases du runner — dans une vue calculée à la lecture, car le runner écrit la clé après le retour du harnais.

Une session neuve, copie de la branche courante à sa position, sur laquelle pi bascule en rejouant session_start (garde à zéro, inventaire redéposé). Dans l'usine, N clones d'une même amorce donnent N bras comparables dont le préfixe lu n'est payé qu'une fois.

La règle du port sous profil : les clés que .env a fournies sont retirées de l'environnement du nœud, et seules les variables du profil de l'agent y sont déposées — ce que le runner pose pour la phase et ce qui vient de l'environnement réel passent toujours. Sans profil, l'héritage global du chapitre 15 s'applique. C'est ce qui permet à deux agents d'un même roster de parler à deux fournisseurs sans se détourner l'un l'autre.

Une commande dont le code retour dit si le payload est en bon état — bun test, un linter, un typecheck. Exit 0 = vert, tout le reste = rouge ; les gates la lancent après chaque tentative du builder. Depuis le chapitre 27 elle se déclare dans le bloc payload du roster par défaut, jamais dans un ADW.

Une compaction dont le résumé est fourni par une extension du socle plutôt que par le résumé libre de pi : un bloc [FACTORY] recopié mot pour mot par le code (mission, contrat de la porte typée, dernier mot du runner), puis un récit rédigé par le modèle. Ce que le runner a injecté survit ainsi, à l'identique, à toutes les compactions d'une phase longue — pour une fraction de centime par tour.

L'unité de travail d'un builder sur un vrai projet : un morceau du produit qu'un agent peut lire en entier et vérifier en une commande — un bounded context, un service, un module. Déclaré dans payload.contexts du roster avec son dossier, ses commandes de vérité, les chemins permis au builder et un brief ; un ADW nomme un contexte, jamais un chemin. Un roster sans contexts a un contexte unique, celui du chapitre 27.

Dans la vue d'un run, le regroupement des phases par côté de la couture — un couloir agent, un couloir code — posé sur un axe de temps. Une pure projection de la trace : le couloir vient du kind de la phase, la position et la largeur des horodatages, rien de nouveau n'est stocké.

Le bloc payload du roster par défaut : où vit le produit que l'usine travaille (dir) et quelles commandes disent la vérité sur lui (truth). Un roster qui ne déclare rien en hérite. Changer de produit, c'est changer ce bloc — aucun script.

Repérer qu'un agent répète le même appel d'outil avec les mêmes arguments : chaque appel est haché (outil + arguments triés) et compté dans une fenêtre glissante ; le même haché N fois dans la fenêtre (5 sur 20 par défaut) est une boucle. Coupée dans « tool_call » par « block + terminate », elle ne coûte pas un jeton de plus — là où une boucle non vue brûle des dizaines de tours jusqu'au mur de temps.

L'agent qui rédige, après coup, la mémoire du changement sous app_docs/ : ce qui a changé, où ça vit, comment le vérifier — traçable aux fichiers du run, jamais spéculatif. Un travail de rapport, pas de décision : il tourne sur le modèle léger du roster, et un compte rendu ne s'écrase jamais.

La seule forme sous laquelle le contexte traverse la couture de l'agent vers le code : un objet JSON avec status, summary, artifacts et notes pour l'agent suivant. Un manifeste de déclarations — leur vérité relève des gates.

Le contrat d'enveloppe déclaré une seule fois, dans un type Python d'où dérivent à la fois la demande envoyée à l'agent et la validation de sa réponse. Ajouter un champ met les deux à jour — la demande ne peut plus dériver de la vérification.

Un agent principal sans outils de code qui choisit, à chaque demande, quel spécialiste appeler via un outil de délégation. Le séquencement appartient au modèle, donc il change d'un run à l'autre : l'usine préfère la chaîne, où c'est le fichier qui séquence.

Le relevé de l'état du repo (fichiers modifiés et non suivis) avant et après une phase agent. La comparaison fait foi : apparu, disparu ou réécrit, tout compte — y compris une réversion.

Une donnée typée et horodatée émise par le runner quand quelque chose se produit : run_start, phase_start, phase_ok, phase_fail, run_end. À la différence d'un log — une phrase pour l'humain qui regarde —, un événement se requête, se compte et se joint après coup.

Le fichier JSON, un par boîte, qui est la seule mémoire partagée entre les six phases du cycle de vie d'un sandbox (nom de VM, URL, commit de référence, pid). Écrite avant la VM, jamais commitée : quoi qu'il arrive ensuite, le démontage a une poignée.

Les chemins qu'aucun agent ne modifie sans les nommer explicitement dans son propre périmètre : la machinerie de l'usine, la config, le plan. Un agent ne doit pas pouvoir éditer ce qui juge son travail.

Un script Python qui séquence des phases agent et des phases code pour accomplir un travail de développement : scout, plan, build, review… C'est l'unité d'exécution de l'usine — lancée par uv, pilotée par le runner.

Le programme qui fait tourner l'agent : boucle d'appels d'outils, sessions, accès aux modèles. Le livre en compare deux — pi et Claude Code — derrière un même port.

Remplacer, dans le résultat d'un outil et avant son envoi au fournisseur de modèles, tout ce qui ressemble à un secret (clés « sk-… », variables « *_KEY= », jetons Bearer, blocs PEM) par un marqueur, en journalisant le nombre de motifs masqués — jamais le motif. Vit dans l'intergiciel « tool_result » de pi ; second rempart après damage control, qui juge la commande et non son contenu.

Le harnais sans interface interactive : une commande entre (drapeau -p), une réponse structurée sort. C'est ce qui rend un agent pilotable par du code — et donc industrialisable.

Un outil enregistré par une extension pi dont le résultat porte « terminate: true » : quand tous les outils du lot le sont, pi n'enchaîne pas d'appel LLM et le tour s'arrête. Dans l'usine, « report_phase » est cet outil : l'agent rend son enveloppe en l'appelant, seul et en dernier — zéro jeton de plus une fois la phase finie.

Deux agents à égalité qui s'échangent des messages sans orchestrateur ni hiérarchie, sur la même machine ou à travers un réseau. Utile pour la recherche et la confrontation de modèles hétérogènes ; ce n'est pas une pièce d'usine, car personne ne tient la séquence ni le verdict.

La transmission du travail d'un agent au suivant, par le code : l'enveloppe finale est parsée, conservée, puis injectée dans le prompt du prochain agent. Quelques centaines de jetons transmis, au lieu d'une session partagée qui gonfle.

L'unité de découpage d'un ADW. Deux espèces : la phase agent (un agent propose, facturée au jeton) et la phase code (le code dispose, gratuite et reproductible). Retenter une phase code n'a pas de sens ; une phase agent se retente en session vivante.

L'agent qui transforme une demande en plan que le builder implémente sans poser de questions. C'est le seul poste où le modèle frontier et un thinking élevé se justifient pleinement : le plan porte tout le run. Sa seule écriture autorisée dans le repo est la spec, sous specs/.

Le contrat par lequel les phases, les orchestrateurs et le best-of-N parlent à une boîte — create, exists, exec, upload, url, destroy, names — sans savoir si elle est un conteneur Podman ou une VM exe.dev. Deux adaptateurs derrière ; SANDBOX_BACKEND choisit celui d'une boîte neuve, la fiche de run celui d'une boîte montée. Le pendant, côté infrastructure, du port harnais du ch. 7.

L'unique porte de l'usine vers ses agents, au sens de l'architecture hexagonale : une HarnessRequest entre, un HarnessResult sort, un adaptateur par harnais traduit. À partir du chapitre 7, aucun script n'invoque un harnais directement.

Un bloc du roster (auth:) qui décrit, par nom, ce qu'un agent a le droit d'emporter et par où : le régime (clé, forfait, session), la route (passerelle ou fournisseur direct), les NOMS des variables à injecter — jamais leurs valeurs, qui vivent dans .env —, les hôtes que la porte du module 6 devra ouvrir et l'éventuelle session à monter. Chaque agent en référence un (gateway par défaut) ; le roster le résout et le valide à zéro token, le port route le modèle et injecte les variables dans le nœud.

Ce que rend toute gate : la liste des vérifications faites, chacune avec son verdict et sa note — pas un simple vert/rouge. Une gate verte dit ce qu'elle a vérifié, et un échec transporte sa preuve (chemin manquant, code retour, queue de sortie), de quoi rédiger la correction qui repartira vers l'agent.

La recette qui liste puis révoque les clés jetables dont la fiche de run est fermée ou dont la VM a disparu — à sec par défaut, --yes pour agir. Son seul modèle de sécurité est le préfixe sbx- : une clé personnelle, sans préfixe, n'est jamais considérée. À lancer en début de session, car une clé oubliée dépense jusqu'à son plafond ou son expiration.

Le fichier adws/adw_data/sessions/ledger.jsonl où le port déclare chaque session avant que pi démarre : identifiant, dossier de naissance, modèle, phase, ADW. Il survit à un runner tué net et permet de refuser, avant tout appel, une reprise depuis un autre dossier que celui de la naissance.

Renvoyer à l'agent le motif exact de son échec dans la même session, plutôt que redémarrer à froid. L'agent a encore tout le contexte : la correction coûte quelques milliers de jetons, pas un run entier.

L'agent qui répond à la question que les gates ne savent pas poser : est-ce que ce qui est construit est ce qui était demandé ? Il juge le code sur le disque contre la spec, exigence par exigence, les mains liées (writes vide au roster). Son status dit si la revue a abouti ; le verdict, c'est approved — et un refus arrête le run en rouge, findings nommés.

La feuille de distribution de l'usine : chaque agent y est déclaré en YAML — nom, rôle, modèle, niveau de réflexion, outils, droits d'écriture. Les ADW nomment des agents, jamais des modèles : changer de moteur, c'est une ligne de YAML.

Le squelette qui exécute les phases déclarées : ordre, mesure, retries, verdict. Il ne connaît ni pi ni Claude Code — il séquence des actions et rend un code retour.

L'agent de reconnaissance de l'usine : il repère où vivent les choses dans le repo, en lecture seule, et rend une enveloppe de findings typés. Déclaré au roster sur un modèle léger avec un thinking bas — il rapporte, il ne décide pas — son travail est vérifié après coup par l'état des lieux.

Un fichier touché en toute dernière ligne d'un script de provision, que la phase suivante attend de façon bornée. C'est le seul signal de fin qui reste juste si la provision est lancée en arrière-plan — et une attente bornée transforme une boîte muette en échec lisible plutôt qu'en blocage.

Le fil de conversation d'un agent avec son historique complet. Dans l'usine : une session par phase agent, mémorisée par le code, jamais partagée entre agents.

Les deux couches du nœud pi de l'usine. Le socle regroupe les extensions chargées dans tous les modes et exigées par le runner (damage control, trace, porte typée, coupe-circuit, inventaire) ; le poste, ce qui n'a de sens qu'en interactif (pied de page, chaînes de poche). Le runner vérifie le socle et ne charge jamais le poste.

L'unité de base d'une trace OpenTelemetry : une opération nommée et datée (début, fin), rattachée à une trace et éventuellement à un span parent. Dans l'export de l'usine, un run devient une trace, chaque phase un span enfant — coût et jetons voyagent en attributs.

Le plan d'implémentation écrit par le planner sous specs/ : fichiers à toucher, changements à faire, comment vérifier. C'est l'artefact au plus fort levier de l'usine — quelques milliers de tokens qui gouvernent tout le build, relisibles à coût nul avant de dépenser le moindre token d'implémentation. Une spec ne s'écrase jamais.

Le troisième état d'un run, à côté du vert et du rouge : une phase code lève PhaseHold quand un humain doit parler avant la suite — une guidance architecturale, une approbation. Le runner journalise run_hold, laisse le run ouvert dans la trace (status running, pas de ended_at) et rend le code 3 ; la reprise se fait avec le même adw_id, run_start étant idempotent. Un agent ne suspend jamais l'usine.

Le journal de ce qui se passe à l'intérieur d'une phase, côté harnais : tours, appels d'outils, factures du modèle, compactions — un JSONL par session pi, écrit au fil de l'eau par une extension, puis miroité dans factory.db (table harness_events). Elle complète le journal du runner sans le remplacer : le runner reste la référence des verdicts et des coûts, la trace harnais explique où les jetons sont passés.

La pièce de la salle de contrôle qui enregistre chaque événement d'un run — ouverture, phase, tentative, verdict — au moment où il se produit, jamais en fin de run. Il écrit deux supports dans le même geste : la ligne JSONL (enregistrement brut) et le miroir SQLite (requêtable). Coût : zéro token, quelques millisecondes par événement.

La conversation complète d'une session d'agent : prompts, réponses, appels d'outils. Exhaustif mais long à lire — des dizaines de milliers de tokens sur une phase de build. La méthode de l'usine ne l'ouvre qu'en dernier, sur la seule phase que la trace a désignée.

Le rendu des couloirs de nage phase par phase : chaque phase est une barre placée et dimensionnée sur l'axe de temps du run. Elle montre en un coup d'œil où sont passées les minutes — les blocs massifs du couloir agent — et où rien n'a coûté — les traits fins du couloir code.

Lancer N variantes du même travail en parallèle (modèles ou rosters différents), puis moissonner et comparer pour garder la meilleure. L'aboutissement du module 6 : la variance des agents devient un atout, pas un risque.

Une boîte du hors-site : un environnement créé pour un run et détruit après, sans regret. Par défaut un conteneur Podman rootless sur un réseau interne, fermé par une porte (ch. 22) — une seconde, zéro euro ; en option une VM exe.dev, avec un noyau dédié et un nom d'hôte public. Les deux passent par le même port ; l'usine entière y voyage, la clé jetable et le run.patch en sortent.

Le runtime JavaScript/TypeScript qui sert Plume et lance ses tests (bun test). Côté usine, bun test est une commande connue : une phase code, pas un agent.

Le secret qui authentifie et facture les requêtes vers un fournisseur ou une passerelle. Dans l'usine, elle vit dans .env (jamais commité, gabarit versionné en .env.sample) et seul le port la charge — ni les harnais ni les agents ne la manipulent.

La clé OpenRouter qui fabrique et révoque des clés d'API, sans pouvoir faire d'inférence. Dans l'usine, elle vit dans .env sous OPENROUTER_PROVISIONING_KEY, côté hôte seulement : lue par sandbox_keys.py, jamais affichée, jamais poussée dans une boîte. C'est la seule clé longue durée du système.

La décision qui autorise pi à charger les réglages, skills et extensions d'un dossier (.pi/). Enregistrée par /trust dans ~/.pi/agent/trust.json ; en headless, sans décision, pi suit le réglage global defaultProjectTrust — ask par défaut, qui ignore le projet en silence. Ce n'est pas un bac à sable : une garde au chargement, rien de plus.

L'extension pi de l'usine qui intercepte chaque tool_call avant l'exécution et le bloque — ou demande confirmation quand une interface est là — selon des règles YAML versionnées avec le projet. Le motif du refus revient au modèle comme résultat d'outil, par la même porte qu'un rapport de gate : la correction coûte un tour, pas un run. En headless, toute règle « demander » bloque.

Un point nommé du graphe que pi déroule pour chaque prompt : session_start, before_agent_start, agent_start, puis les tours (turn_start, tool_call, tool_result, turn_end), agent_end et agent_settled. Certains handlers observent seulement, d'autres modifient (context, message_end), un seul bloque : tool_call. Le runner possède le graphe des phases ; pi possède celui des tours.

Service de VM persistantes, adressables en HTTPS et en SSH, dont l'API est SSH : « ssh exe.dev <verbe> » pour créer, lister et détruire (plan de contrôle), « ssh <vm>.exe.xyz » pour agir dans la boîte (plan de données). Dans le livre, c'est l'option échelle du hors-site (SANDBOX_BACKEND=exedev) : une VM par boîte, N boîtes sans toucher à votre machine, derrière le même port que Podman.

Un module TypeScript, auto-découvert sous .pi/extensions/ une fois le projet approuvé, qui exporte une fonction recevant l'ExtensionAPI. Elle s'abonne au cycle de vie d'une session (pi.on), enregistre outils et commandes, et s'exécute dans le process du harnais — jamais dans le modèle. Dans l'usine, c'est la pièce qui rend le nœud pi observable, sûr et transportable, sans déplacer la couture.

L'entrée objet de la liste packages de .pi/settings.json (source, puis extensions, skills, prompts, themes) par laquelle pi ne charge qu'une partie d'un package. C'est ce qui permet d'installer l'usine pi en deux couches : la couche socle (les extensions du nœud, zéro skill) ou la couche poste (tout). Un chemin local s'y résout relativement au dossier .pi/ du dépôt qui l'écrit.

Un fournisseur de modèles fourni par le paquet pi-ai, dont les réponses sont une file scriptée (texte, appel d'outil, motif d'arrêt) au lieu d'un appel réseau. Branché sur le SDK de pi, il permet d'exercer les extensions dans le vrai pipeline — outils réels, événements réels — sans réseau ni jeton, et de reproduire à volonté ce qu'un vrai modèle ne fait qu'à l'occasion (boucler, fuiter un secret).

L'outil de tableaux de bord de l'observabilité. Le chapitre 20 l'évoque comme vitrine du pont OTel / Prometheus ; le chapitre 20bis le monte en local dans un conteneur Podman, branché par une source de données SQLite sur un instantané du journal — une lecture de plus, jamais la source de vérité.

Un multiplexeur de terminal pensé pour les agents : workspaces et panes pilotables par commandes à réponses JSON. Le poste de pilotage de l'usine — on lit les identifiants dans le JSON, jamais depuis le focus.

L'événement « tool_result » de pi, où les extensions s'enchaînent dans l'ordre de chargement et peuvent chacune rendre un correctif partiel (contenu, détails, erreur, usage) du résultat d'un outil avant qu'il n'entre dans le contexte. C'est le seul point du cycle de vie où le contenu est déjà produit et pas encore envoyé : l'usine y masque les secrets.

Un format de fichier où chaque ligne est un objet JSON complet — idéal pour un journal écrit au fil de l'eau : on ajoute une ligne, on ne réécrit jamais le fichier. Dans l'usine, c'est l'enregistrement brut de référence des traces, un fichier par run.

Le lanceur de recettes qui sert de surface de commandes à l'usine : le justfile nomme chaque geste (hello, serve, fleet…). Règle du livre : dès qu'une logique dépasse la ligne, elle va en Python — la recette reste une ligne.

Le mode de pi (pi --mode rpc) où un seul processus reste ouvert et se pilote en JSONL : une commande par ligne sur stdin, une réponse corrélée par id, les événements de session sur stdout jusqu'à agent_settled. L'usine le réserve au best-of-N par clone ; les phases restent un processus par tentative.

Rendre le comportement du système visible de l'extérieur : quelles phases ont tourné, à quel coût, en combien de temps. Le module 5 du livre trace chaque run dans SQLite — on ne pilote pas une usine aveugle.

La passerelle de modèles du livre : un compte, des crédits, une clé (OPENROUTER_API_KEY) — et tous les moteurs du roster, quel que soit leur fournisseur, sur une seule facture. Son registre public est le catalogue que la jauge des moteurs consulte, et l'adaptateur pi du port y route chaque modèle.

Le standard ouvert de l'observabilité : un format commun pour les traces, les métriques et les logs, que tout backend compatible sait recevoir (protocole OTLP, port HTTP 4318 par défaut). L'usine ne s'y instrumente pas : un export après coup traduit le journal SQLite en traces OTLP — le chemin reste usine → SQLite → lecture.

Un dossier avec un package.json portant un manifeste « pi » qui déclare où vivent les extensions, skills, gabarits de prompt et thèmes. « pi install » l'enregistre dans settings.json (« -l » pour le projet), depuis npm, git ou un chemin local. Il transporte des capacités, pas des réglages : le dépôt qui l'installe garde son modèle par défaut et sa compaction. C'est le pendant harnais du stamp du chapitre 27.

Le harnais en ligne de commande que l'usine pilote derrière le port du chapitre 7, à côté de Claude Code. Headless par -p (flux JSONL en --mode json), configurable par deux fichiers JSON (global ~/.pi/agent/settings.json, projet .pi/settings.json) et extensible en TypeScript — c'est l'objet de l'annexe.

La ligne d'état en bas du terminal de pi : jetons, coût, jauge de contexte, modèle et niveau de réflexion. Une extension peut y ajouter un statut (setStatus) ou le remplacer entièrement (setFooter) pour afficher ce que le harnais ignore — le rôle du roster, le budget de session. Hors mode TUI et RPC, ces appels sont des no-op : le headless du runner n'en voit rien.

Moteur de conteneurs sans démon et rootless : chaque commande podman est un processus ordinaire de l'utilisateur, jamais un service root. Le moteur de boîtes par défaut du hors-site : un conteneur par boîte, une seconde pour le monter, zéro euro. Sous macOS et Windows, podman machine pilote une petite VM Linux où tout tourne à l'identique.

Le collecteur de métriques standard : il vient chercher des agrégats exposés en format texte lisible, que Grafana dessine ensuite. L'usine lui expose ses compteurs — runs par verdict, dollars et secondes cumulés par ADW et par phase — depuis le journal, en une commande et zéro token.

La configuration de Grafana par fichiers lus au démarrage — sources de données et fournisseurs de tableaux de bord — à la place des clics. Dans l'usine, ces fichiers sont écrits par le code à chaque montage de la vitre : effacer et relancer redonne la même vitre.

Un réseau Podman créé avec --internal : ses membres se résolvent par leur nom, mais aucune route ne mène dehors. C'est lui qui ferme la boîte — un processus qui ignorerait HTTPS_PROXY n'a nulle part où aller. La porte est membre de ce réseau et du réseau ordinaire ; le conteneur de travail, du réseau interne seulement.

Un environnement isolé et jetable où un agent peut agir sans risque pour votre machine ni vos secrets. Le module 6 du livre monte des VM jetables pour paralléliser l'usine hors-site.

Le vocabulaire standard qui décrit la forme d'un objet JSON : types, champs requis, valeurs autorisées (« enum »), descriptions. Les fournisseurs de modèles l'utilisent pour déclarer les paramètres d'un outil ; pi le compile pour refuser un appel non conforme avant d'exécuter l'outil. Dans l'usine, il est écrit par le runner avant chaque phase, jamais à la main.

Un script Python qui déclare ses dépendances et sa version de Python dans un en-tête commenté. uv le lit et fabrique l'environnement à la volée : le script devient un exécutable portable.

L'API programmatique de pi (createAgentSession, DefaultResourceLoader, ModelRuntime, SessionManager, SettingsManager) qui monte une session complète depuis du code TypeScript, en mémoire si on le souhaite. L'usine s'en sert pour son banc d'essai .pi/tests/ ; le chapitre A9 y revient pour la session vivante (reprise, fork).

Le cycle de vie complet d'un changement logiciel : plan → build → test → review → document. L'usine l'enchaîne en un seul ADW au chapitre 13 — chaque étape étant une phase, agent ou code.

Un paquet d'instructions et de scripts qu'un harnais charge pour acquérir un savoir-faire réutilisable. C'est le format de distribution visé par le livre : au dernier module, l'usine entière s'installera comme un skill.

Gestionnaire et lanceur Python ultra-rapide. Dans l'usine, uv run exécute chaque ADW avec ses dépendances déclarées dans le script — aucune installation préalable, aucun environnement à maintenir.

Le mode de journalisation SQLite qui laisse les lecteurs interroger la base pendant qu'un écrivain écrit. C'est lui qui rend le journal de l'usine lisible à chaud : vous requêtez un run pendant qu'il tourne, sans le gêner.