Préface

Exécuté le 2026-10-15 12:58 UTC+01:00 dans la bibliothèque au commit 93d7a39bd : 1 bloc(s) sur 1 ont tenu leur promesse.

Les blocs ont été exécutés par le runtime de l'ancien langage hôte, version 1.27 ; Haro n'exécute pas encore la bibliothèque. Les binaires du moteur ont été construits dans une copie de ce commit, le plus récent le 2026-10-05 20:27 UTC+01:00 ; 1 changement(s) du moteur commité(s) après cette construction n'y sont pas.

Une question que vous avez déjà

Vous utilisez un outil qui écrit du code. Vous lui demandez une fonction, ou une fonctionnalité entière, et il répond en quelques secondes. Vient alors la question qu'aucun outil ne résout pour vous : ce code doit-il entrer dans mon système ?

Vous avez toujours eu des moyens de répondre. Vous lancez les tests. Le vérificateur de types est d'accord, ou il ne l'est pas. Un collègue relit le changement. Ces moyens ont été faits quand on écrivait le code lentement. Aujourd'hui une seule phrase peut produire mille lignes, et personne n'a le temps de relire mille lignes pour chaque phrase.

Le code est devenu bon marché. La confiance, non. Ce livre revient sans cesse à une phrase, celle sur laquelle repose chaque chapitre : le changement arrive plus vite que la confiance.

L'idée, en deux gestes

D'abord vous déclarez. En texte simple, vous dites ce qu'est une chose : une application (je l'appelle un monde), un langage, un agent d'IA, un produit entier. Ensuite vous gouvernez. De votre déclaration vous obtenez un juge, que j'appelle un tribunal. Un tribunal est un validateur construit à partir de votre déclaration. Il rend un verdict, tenu ou refusé, et la raison, dans les mots de votre déclaration.

Chaque changement passe devant le tribunal avant d'entrer, quel qu'en soit l'auteur : vous, un collègue, un script ou un modèle d'IA. Le modèle peut toujours tout proposer. Il ne peut rien décider. On l'interroge aussi en dernier : tout ce que des règles peuvent décider, les règles le décident d'abord.

Une déclaration, en vrai code

Voici le cas le plus petit. Vous ajoutez à votre système un agent d'IA, un programme qui surveille les niveaux de stock et réapprovisionne. Vous ne commencez pas par son code. Vous commencez par un court fichier texte qui dit ce qu'il est : son nom, la fréquence à laquelle il tourne, ce qu'il peut faire, et si ses actions peuvent être défaites. Ce fichier est une déclaration. Vous le chargez, et le tribunal le lit avant que l'agent puisse jamais tourner. Le fichier de cet agent omet quelque chose. Que dit le tribunal ?

cPia = "pia: 1
name: stock-watcher
kind: pi
reversibility: compensable
schedule:
  timer: 20
skills:
  - name: restock
    does: learn stock level ordered
"
oD = StzAgentDeclarationQ(cPia)
? oD.IsValid()
#--> 0
? oD.CiteFindings()
#--> [pia-coverage @ coverage] an agent must say WHAT IT COVERS. The engine loop refuses to schedule an agent with no coverage statement (law 18), so a file without one could never run and is refused here instead of at the first tick.

Lisez-le en trois parties. Le texte entre les guillemets est la déclaration. La ligne suivante la charge. Ensuite ? imprime une réponse, et la ligne après #--> est ce que le bloc a imprimé quand je l'ai lancé. Le tribunal répond 0 : refusé. Il nomme la règle et donne la raison : un agent doit dire ce qu'il couvre, parce que le moteur ne planifiera pas un agent qui ne le dit pas, donc le fichier est refusé maintenant et non à sa première exécution. Quelques mots du fichier : pia nomme le format du fichier, compensable veut dire que ses effets peuvent être défaits par une action de compensation, et law 18, dans la raison du tribunal, est le numéro que le moteur donne lui-même à sa règle selon laquelle un agent sans couverture n'est jamais planifié.

Vous pourriez écrire ce contrôle dans votre propre CI. Ici personne n'a eu à le faire. Le tribunal des agents est livré avec la bibliothèque, donc la règle est celle de la bibliothèque, et les faits sont les vôtres, dans la déclaration. Un simple assert dans un script de démarrage juge un seul fait. Une déclaration tient dans un seul texte tous les faits sur l'agent, et le même tribunal la juge, qu'elle ait été écrite par une personne, un script ou un modèle d'IA. La règle peut aussi être la vôtre : le chapitre 2 a une règle que vous écrivez en quelques lignes sur deux faits, qu'un acteur est un modèle de langage et qu'il détient un effet, un pouvoir d'agir sur le monde comme envoyer un courrier, et le tribunal trouve la violation dans votre propre graphe d'agents. Cet exemple est petit exprès, et un schéma peut le vérifier aussi. Le livre ne soutient pas qu'un tribunal vérifie plus qu'un schéma. Il soutient qu'un seul tribunal, construit à partir de votre déclaration, se tient devant chaque acteur et donne sa raison. Il ne lit pas mille lignes générées pour les déclarer bonnes : il vérifie qu'un changement tient dans ce que vous avez déclaré, et le chapitre 24 montre un changement essayé sur une copie de votre système avant que rien ne soit validé. Pour une chose à vous, par exemple un langage que vous inventez, le chapitre 12 montre comment faire le tribunal, et dit jusqu'où cela est construit. Le chapitre 1 raconte une deuxième scène, avec un service de courrier, et le chapitre 2 relance ce bloc.

Vous direz que vous avez déjà des tests, des schémas et des contrôles de politique dans votre CI. C'est vrai. Aujourd'hui ces règles vivent à plusieurs endroits : des tests ici, un schéma là, un fichier de politique ailleurs, chacun écrit à la main après le code. Ici vous les énoncez une seule fois, dans la déclaration, et le tribunal en découle. Le chapitre 22 compare honnêtement les deux, et là où le terrain fait mieux, il le dit. Un tribunal juge ce que vous avez déclaré. Il ne peut pas juger ce que vous avez omis, et la limite de chaque chapitre dit où cela s'arrête.

Ce qu'est Softanza

Une plateforme logicielle gouvernée. Vous déclarez ce que vous savez d'un monde, en texte clair ; un tribunal construit à partir de cette déclaration le garde ; et le modèle d'IA, quand il y en a un, vient en dernier. C'est la ligne de la couverture, et chaque chapitre la fait tourner. Matériellement, Softanza est trois choses, et pour chacune je dis jusqu'où elle existe.

• Une bibliothèque que vous appelez depuis du code. Vous écrivez quelques lignes de Haro comme celles ci-dessus, et vous les lancez avec la bibliothèque chargée. La bibliothèque tient les déclarations et les tribunaux qui en sont faits. Sa source est à github.com/mayouni/stzlib, et chaque bloc de code de ce livre a tourné sur un commit nommé de celle-ci. Si votre travail est en Python ou en TypeScript, vous l'utiliseriez aujourd'hui à côté de votre code, non dedans : par une seule porte gouvernée elle peut exécuter du code en six autres langages, Python, NodeJS (JavaScript), R, Julia, Prolog et C, qui avec l'hôte font les sept du chapitre 16.
• Un moteur sous la bibliothèque, écrit en Zig, un langage système. Il fait le calcul réel, une seule fois et en un seul endroit, pour que chaque langage qui lui parle obtienne le même comportement. Il tourne aujourd'hui, et les domaines de la bibliothèque y passent un à un : le chapitre 4 dit lesquels calculent encore dans le langage hôte.
• Un langage, Haro, fait pour tenir les déclarations. Pour l'instant il emploie la syntaxe de sa première facette, si bien que tout le code écrit jusqu'ici tourne sans changement. Son propre exécutable est en développement : il a une charte et un premier essai.

Le chapitre 4 dessine les trois en une seule image.

Où il en est

Softanza n'est pas un projet de recherche, même s'il repose sur une recherche profonde. Des projets réels l'ont façonné : un restaurant, une banque et une organisation, et leurs retours ont façonné sa conception. Des parties de Softanza sont en production. D'autres sont en développement, comme il est normal pour une plateforme neuve et aussi ambitieuse. Chaque chapitre dit laquelle est laquelle.

Ce qu'est ce livre

C'est un livre d'arguments, avec du code qui tourne. Pour chaque question sur la programmation, sur les langages et sur l'intelligence, je fais quatre choses. Je donne la réponse que donne d'ordinaire le terrain. Je donne la réponse que prend Softanza. Je donne la décision que j'ai prise, et ce que j'ai refusé. Et je donne la preuve : le code a tourné, et les tests qui le prouvent sont nommés. La troisième, la décision et ce que j'ai refusé, est la raison d'être de ce livre : le site montre ce qui est, et ce n'est qu'ici que vous trouverez ce qui a été refusé. Je dis aussi ce que le terrain fait déjà bien, pour que vous puissiez comparer.

Il compte sept parties et trente-trois chapitres. Vous n'avez pas besoin de connaître Softanza ni Zig. Il vous faut avoir écrit du code, et avoir ressenti le doute ci-dessus. Le site du projet tient ses preuves, avec leurs démonstrations, et son cours enseigne le même terrain par des exercices. Ce livre tient l'argument.

Chaque chapitre a six courtes portes, vers sa fin. Une porte est une entrée pour un genre de lecteur : le programmeur, l'analyste, le concepteur, le décideur, le formateur et l'agent. L'agent est un programme d'IA, parce que le livre est aussi publié sous forme de données qu'un programme peut lire. Entrez par la porte qui est la vôtre aujourd'hui.

Comment le lire

Lisez d'abord neuf chapitres. Ils portent tout l'argument et peuvent se lire seuls : les quatre de la partie I, les deux derniers, et trois qui énoncent chacun une règle que le livre tient partout. Chapitre 5 : le code doit se lire comme une personne pense. Chapitre 11 : un langage est déclaré et fermé. Chapitre 17 : un programme est programmatique par défaut, ce qui veut dire que les règles et le code décident d'abord, et que le modèle d'IA vient en dernier. Le lecteur a un bouton qui n'affiche que ces neuf. Revenez aux autres quand l'un d'eux vous intéresse.

Chaque chapitre a les mêmes neuf parties, dans le même ordre. L'idée telle que le terrain la tient aujourd'hui. Le premier principe. La forme qu'elle prend dans Softanza, en code. La décision, et ce que j'ai refusé. Le tribunal : les tests nommés qui prouvent l'affirmation du chapitre. Le terrain, et ce qu'il fait mieux. La limite. Les six portes. Un exercice, auquel vous répondez avant de le lancer. Les chapitres 5, 11 et 17 s'ouvrent par une courte section de plus, sur ce que l'ère de l'IA change.

Un nom de plus que vous rencontrerez. Softanza vous pose la question à laquelle vous devez répondre, dans vos propres mots, et refuse de deviner la réponse à votre place. J'appelle cette pratique le wise coding. Le chapitre 18 la fait tourner, registre par registre.

À quoi se fier

Chaque bloc de code de ce livre a été lancé dans la bibliothèque. Sous chaque titre, la page dit quand, à quel commit, et combien de blocs ont tenu leur promesse : combien ont imprimé ce que dit la ligne après #-->. Si un bloc imprime autre chose, la construction échoue, et la page avec elle. Les exercices sont à vous de les lancer.

Deux mots reviennent sur bien des pages. Le dossier est l'ensemble des dépôts, des sessions et des fichiers sur lesquels ce livre a tourné, au commit imprimé sous chaque titre. L'étude est ma propre étude de ce dossier, faite avant la rédaction des chapitres. Quand une page dit que le dossier ne contient pas de réponse, elle parle de ces fichiers, à ce commit.

Quand un chapitre dit ce qui n'est pas fini, il emploie trois mots et aucun autre. Construit : le code existe, un test existe, et un bloc a tourné. Conçu : un document le dit, et rien ne tourne. Absent : j'ai cherché et je n'ai rien trouvé, et je dis jusqu'où j'ai cherché. Le site du projet emploie cinq noms pour les mêmes choses, et le chapitre 3 montre comment ils se ramènent à ces trois-là.

Une remarque de plus. L'exécutable propre de Haro est encore en développement, donc les blocs marqués haro tournent aujourd'hui sur le runtime du langage pour lequel la bibliothèque a d'abord été écrite, version 1.27, et chaque page le dit. L'annexe H, l'histoire du projet, raconte comment on en est arrivé là. Dans le code, les noms propres de la bibliothèque, ses classes, ses fichiers et ses clés, portent encore le nom de ce langage, et le porteront jusqu'à ce que la bibliothèque en soit retirée ; la prose, non.

À propos de ce brouillon

Les chapitres ont été rédigés avec des agents d'IA, à partir des propres fichiers du projet, et chaque bloc de code a été lancé. Chaque page porte son étape en haut : Brouillon, écrite, son code exécuté et jugé, lue par des lecteurs neufs ; En relecture, pendant que je la relis ; Publiée, une fois que je l'approuve. Aujourd'hui, chaque page est un brouillon. Là où les fichiers ne contenaient aucune réponse à une question, la page le dit en une phrase simple et n'en invente pas. L'édition française est une traduction des brouillons anglais, et chaque page française le dit. Cette préface a été écrite après les chapitres, et elle reste inachevée jusqu'à ce que j'écrive la mienne. C'est le premier livre de ma maison d'édition, AYOUNI. Le deuxième, Refinement-Oriented Programming, parle d'une discipline pour le logiciel à l'ère des agents d'IA, racontée à travers une banque.

Le changement arrive plus vite que la confiance

Exécuté le 2026-10-15 12:58 UTC+01:00 dans la bibliothèque au commit 93d7a39bd : 2 bloc(s) sur 2 ont tenu leur promesse.

Les blocs ont été exécutés par le runtime de l'ancien langage hôte, version 1.27 ; Haro n'exécute pas encore la bibliothèque. Les binaires du moteur ont été construits dans une copie de ce commit, le plus récent le 2026-10-05 20:27 UTC+01:00 ; 1 changement(s) du moteur commité(s) après cette construction n'y sont pas.

1. Le concept, tel que le terrain le tient

Demandez à l'industrie ce qui a changé dans la programmation ces dernières années et vous obtiendrez une seule réponse, dite avec enthousiasme ou avec effroi : les machines écrivent le code maintenant.

L'image est familière. Un modèle d'IA propose une fonction, un fichier, une application entière. Une personne la relit, ou non. On ajoute des outils autour du modèle pour le rendre plus sûr : des linters qui lisent ce qu'il a écrit, des tests qu'il génère lui-même, des garde-fous qui attrapent le pire, un second modèle qui juge le premier. Le modèle est au centre. Tout le reste est une clôture bâtie autour de lui après coup.

Je ne crois pas que cette image se trompe sur les faits. Elle se trompe sur l'endroit où se tenir.

2. Le premier principe

Voici la phrase à laquelle je reviens sans cesse, et c'est la plus ancienne phrase de ce livre : le changement arrive plus vite que la confiance.

Le code est devenu bon marché. Mille lignes coûtent une phrase. Ce qui n'est pas devenu bon marché, ce qui est même devenu la chose la plus rare du logiciel, c'est la confiance que ces lignes font ce que leur auteur, humain ou machine, dit qu'elles font. Toutes les équipes que j'ai rencontrées ces deux dernières années ont plus de code qu'elles ne peuvent en relire et moins de confiance qu'avant. Le goulot de notre époque n'est pas l'écriture. C'est l'admission : décider ce qui peut entrer dans un système et y rester.

Aussi la question que pose Softanza n'est pas comment générer mieux ? C'est comment admettre ? Qui juge un changement, par quelle loi, avant qu'il s'exécute, et ce qu'on écrit du verdict pour que quelqu'un puisse le lire plus tard et en répondre.

Lorsque vous placez l'admission au centre, l'image se retourne. Le tribunal est au milieu. Le modèle est un auteur de propositions parmi d'autres, et il vient en dernier, après la personne, après les données, après la formule, après la phrase simple. Rien de ce qu'il dit n'entre dans le monde avant que le tribunal l'ait lu. Ce n'est pas une clôture bâtie autour d'un générateur. C'est un autre bâtiment.

3. La forme Softanza

Laissez-moi vous montrer plutôt que dire, par l'exemple, ce qui a toujours été ma façon préférée d'enseigner.

Une solution déclare qu'elle dépend d'un service de courrier. Pendant que je programme, je lie cette dépendance à un bac à sable : un objet qui capture chaque message et n'envoie rien, pour que mes tests puissent lire ce qui serait parti. Gratuit, hors ligne, déterministe. Puis je déplace la solution en production, le bac à sable toujours lié, comme on le fait à deux heures du matin avant une démonstration.

oReg = new stzServiceRegistry("my-solution")
oReg.Bind(:mail, new stzMailSandbox())
oReg.SetPhase(:emulated)
? oReg.IsSound()
#--> 1
oReg.SetPhase(:production)
? oReg.IsSound()
#--> 0
? oReg.Findings()[1][:message]
#--> still bound to a SANDBOX in a production phase -- a fake must never ship

Le registre ne la déclare pas saine. En phase émulée il répond un ; en production il répond zéro, et la ligne suivante dit pourquoi : un faux ne doit jamais être livré. Le faux est refusé par son nom, et un service déclaré et jamais lié lève une erreur au moment où on le demande, au lieu de ne rien faire en silence. Je n'ai pas eu à me souvenir de le vérifier. La phase a décidé de ce qui revient, et la vérification est imposée, non mémorisée.

C'est toute la philosophie en une petite scène. L'expression est libre : liez ce que vous voulez, aussi longtemps que vous voulez. L'admission est gouvernée : la barrière lit la phase et la liaison, et refuse.

Maintenant une deuxième scène, parce que la première n'a pas de modèle d'IA dedans et que vous attendez le modèle.

Prenons un restaurant pour illustration : un agent d'IA qui connaît son monde propose de passer une commande. Dans Softanza, l'agent ne la passe pas. Il propose un plan. Un atelier répète le plan sur un jumeau du système, une copie qui ne garde aucune référence vers le réel, et enregistre chaque opération qu'il effectuerait. Un tribunal lit la répétition à la lumière des règles que le restaurant a déclarées : qui peut commander, ce qui peut être commandé, ce qu'un fournisseur doit confirmer. Alors seulement un acteur gouverné valide, et la validation est enregistrée avec son acteur et son issue. La garde qui prouve cette séquence, safeworld_narrated, répète dans un jumeau des fichiers, planifie et laisse un acteur valider ; elle compte soixante-seize assertions au moment où j'écris, dont aucune ne parle d'un restaurant, et le site montre une exécution enregistrée du même mécanisme.

Remarquez ce que le modèle a fait et n'a pas fait. Il a proposé. Il n'a pas décidé, pas écrit, pas envoyé. Il était un auteur de propositions à côté des registres de réponse. Trois d'entre eux, une option choisie, une structure de données donnée, une phrase dite, sont construits aujourd'hui et ouverts à la personne avant même que le modèle soit appelé ; deux autres, une formule écrite et un exemple montré, ne sont pas encore construits (chapitre 18). J'appelle cela programmatique par défaut, le modèle en dernier. C'est la phrase sous chaque chapitre de la partie IV.

Et une troisième scène, la plus petite, parce qu'elle montre la même loi au niveau d'une seule ligne. La plateforme est jugée sur l'allure de son code et sur ce qu'il répond :

o1 = new stzList([ "tea", "rice", "tea", "fish", "rice", "tea" ])
? @@( o1.FindAll("tea") )
#--> [ 1, 3, 6 ]
? @@( o1.DuplicatesRemoved() )
#--> [ "tea", "rice", "fish" ]

La question est dite comme elle est pensée : trouver tout, retirer les doublons. Et les deux lignes sous les deux questions ne sont pas mon commentaire. Ce sont des promesses que la bibliothèque a tenues la nuit où ce chapitre a été construit. Si elle cesse de les tenir, cette page échoue. La même loi, l'admission avant la confiance, appliquée à un paragraphe.

5. Le tribunal

Qu'est-ce qui prouve ce chapitre ? Trois choses, et je vous les donne par leur nom pour que vous puissiez les vérifier plutôt que me croire.

Le refus d'un faux en production par le registre de services est une garde, service_registry_narrated, dans le volet système. La suite proposer, répéter, juger et valider de l'agent d'IA est safeworld_narrated, soixante-seize assertions, dans le volet agentique, à côté de governance_crossing_narrated, dans le volet système, pour la traversée elle-même. Les blocs de code de cette page ont été exécutés par l'exécuteur propre du livre à l'intérieur de la bibliothèque la nuit où cette page a été construite, et sa sortie est montrée telle qu'elle est venue.

Trois gardes pour un chapitre de philosophie peuvent sembler peu. Ce sont les trois bonnes, parce que ce sont les trois endroits où la philosophie rencontre un verdict.

6. Le terrain, et où il mène

Je ne ferai pas semblant que le terrain n'a rien. Il a, ces trois dernières années, construit les générateurs de code les plus capables de l'histoire, et je les utilise chaque jour. La réponse de l'industrie au problème de la confiance est un vrai travail : tests générés, robots de revue, moteurs de politiques, bacs à sable pour agents d'IA, sorties structurées, un second modèle pour noter le premier. Là où le terrain mène, et il mène nettement, c'est dans les générateurs eux-mêmes. Softanza ne construit pas les grands générateurs et ne les concurrence pas ; là où il entraîne, il entraîne de petits modèles liés à un seul domaine, dont chaque réponse sera vérifiée par une grammaire. Le terrain mène aussi en échelle : ses outils de revue lisent des volumes de code généré contre lesquels rien dans Softanza n'a été exécuté.

Là où je crois que Softanza se tient seul, c'est dans l'ordre des choses. Le terrain ajoute l'admission à un générateur. Softanza ajoute un générateur à un tribunal. Dans le terrain, un modèle d'IA écrit dans votre langage et des outils le vérifient ensuite ; ici, le modèle ne peut écrire que dans un langage que vous avez déclaré, dont la grammaire est close et dont le tribunal est destiné à naître avec lui, de sorte que, pour les langages dont la grammaire est compilée aujourd'hui, une phrase invalide ne peut pas du tout être prononcée. Dans le terrain, le dialogue avec un système est un prompt ; ici, le système demande, et la réponse peut être un exemple, une formule ou une phrase avant d'être jamais un modèle. Dans le terrain, la trace d'une décision est un journal ; ici, c'est une transcription avec un locuteur et une certitude, dont on répond pour toujours.

Ce sont des affirmations, et chacune a son chapitre et sa garde. Je les liste ici pour que vous sachiez où va l'argument, et pour que vous puissiez me le faire tenir.

7. La limite

• construitle tribunal qui admet ou refuse un changement, pour une personne et pour une machine
• absentune plateforme cliente qui tourne sur le moteur Softanza

La limite honnête de ce chapitre est aussi la limite honnête de toute la plateforme, et je la mets sur la première page à dessein.

Softanza a été utilisé. Une banque à Niamey fait tourner une plateforme d'évaluation dont la construction a façonné Softanza, sous licence, attestée par le guide d'installation que nous avons livré. Un restaurant à Lyon fait tourner une plateforme pour le commerce de quartier dont le propriétaire a fait seul la première démonstration, sur son propre téléphone, avec une application de messagerie comme ligne d'assistance. Une organisation au Niger a son hub conçu. Leurs leçons sont dans le code, par nom de fichier, dans la partie VI.

Mais les plateformes clientes tournent aujourd'hui sur des piles ordinaires. Celle de la banque est une application Python ; celle du restaurant est un ensemble de mondes web d'un seul fichier ; le hub de l'organisation n'est pas construit. Leurs déclarations sont en cours d'écriture comme celles de Softanza elle-même, de sorte que les faire passer sur le moteur Softanza soit un changement de moteur et non de plan. Ce passage est l'étape suivante. Le tribunal est construit, et les plateformes existent ; le prochain jalon est la première d'entre elles tournant sur le moteur. C'est la ligne suivante que ce livre portera, et le chapitre 33 ne parle de rien d'autre.

8. Six portes

9. Exercice

Prenez une fonction qu'un modèle d'IA a écrite pour vous cette semaine. Dessous, écrivez la ligne qu'elle doit imprimer pour une entrée qui vous importe, sous la forme que vous venez de rencontrer :

? YourFunction(the_input)
#--> the line it must print

Exécutez-la. Si la ligne correspond, vous avez votre première promesse. Sinon, vous avez votre premier constat, et vous avez appris sur cette fonction en une minute plus que l'explication du modèle ne vous en a dit. Ne la corrigez pas encore. Le chapitre 2 parle de qui vous êtes quand vous le faites.

L'artisan du logiciel

Exécuté le 2026-10-15 12:58 UTC+01:00 dans la bibliothèque au commit 93d7a39bd : 9 bloc(s) sur 9 ont tenu leur promesse.

Les blocs ont été exécutés par le runtime de l'ancien langage hôte, version 1.27 ; Haro n'exécute pas encore la bibliothèque. Les binaires du moteur ont été construits dans une copie de ce commit, le plus récent le 2026-10-05 20:27 UTC+01:00 ; 1 changement(s) du moteur commité(s) après cette construction n'y sont pas.

Dans ce chapitre, je prends le mot « crafter » au terrain, à son artisanat et à ses deux réponses qui définissent la personne par un outil, le low-code et l'agent de code. Je dis ce que le site entend par lui. Je montre les six portes, chacune avec une ou deux lignes qui s'exécutent, et les trois cas pour lesquels ce livre est écrit : un restaurateur à Lyon, Softibank, une banque à Niamey, une organisation sur le terrain. Je dis ce que j'ai gardé, le programmeur en premier ; ce que j'ai ajouté, l'agent d'IA, avec un pouvoir retenu ; et ce que j'ai refusé, « maker » et « builder ». Le principe est une phrase qui joint celle du site et celle du glossaire : un artisan du logiciel est quiconque déclare ce qu'il sait d'un monde, et possède ce qu'il déclare.

1. Le concept, tel que le terrain le tient

Le terrain a déjà un mot pour les programmeurs qui prennent soin de leur travail : l'artisanat (craftsmanship). Un livre de 2001 a donné son nom à l'idée, et un manifeste de 2009 lui a donné son slogan. Depuis, « software craftsman » désigne un professionnel qui tient son code à un niveau plus élevé que celui que le travail exige. Cela relève de la connaissance générale, non d'une lecture du dossier. C'est un bon mouvement. C'est aussi un mouvement de programmeurs, sur les standards des programmeurs.

Les deux autres réponses du terrain à « qui fait le logiciel, si ce ne sont pas les programmeurs » définissent la personne par un outil. La première est le low-code : des gens du métier qui construisent des applications sur la plateforme visuelle d'un éditeur, le « développeur citoyen » des analystes. La seconde est l'agent de code : un modèle d'IA qui lit des fichiers, les modifie et lance des commandes, piloté en mots simples. Le « vibe coding » est le nom de la pratique qui consiste à garder tout ce qu'il écrit. Les deux réponses ont la même forme. La personne est définie par un outil, et le travail vit là où vit l'outil. Quand l'éditeur change ses prix ou son modèle d'IA, le travail de la personne change avec. Cela aussi relève de la connaissance générale, non d'une lecture du dossier.

La section suivante dit ce que le site entend par ce mot.

2. Le premier principe

Le site donne la définition en deux phrases. Depuis le 8 octobre 2026, elles disent « crafter » ; avant, elles disaient « maker ». Le glossaire dit qu'un artisan du logiciel est quiconque déclare, au moment où il déclare. Le site dit qu'il possède ce qu'il fait. Je garde les deux, en une phrase : un artisan du logiciel est quiconque déclare ce qu'il sait d'un monde, et possède ce qu'il déclare : l'artefact est à lui, en texte brut, et il n'expire pas. La compétence n'entre pas dans la définition. Le mot « artisanat » la suggère, et je garde le mot : la personne est définie par l'acte et par la possession, non par sa compétence de programmation. Je tiens cela pour une vue, non pour un résultat.

3. La forme Softanza

J'ai été le premier artisan du logiciel de Softanza, et pas pour une raison que j'aurais choisie. Ma femme dirige un club de musique où l'on apprend à chanter des chansons classiques arabes. Chaque dimanche matin, elle m'envoie la liste des chansons à préparer, et je cherche leurs paroles. Les paroles trouvées en ligne répètent chaque phrase comme le chanteur l'a interprétée, et elle me rappelle, à chaque fois, d'en supprimer les doublons. J'ai écrit RemoveDuplicates() pour cesser de le faire à la main. Sa famille est-elle toujours dans la bibliothèque, et que dit-elle d'une liste qui contient trois fois « tea » ?

o1 = new stzList([ "tea", "rice", "tea", "fish", "rice", "tea" ])
? o1.ContainsDuplicates()
#--> 1
? o1.NumberOfOccurrence("tea")
#--> 3

La famille répond : la liste contient des doublons (1), et tea apparaît 3 fois.

J'en parle dans un article sur ce sur quoi la bibliothèque a été construite : j'ai introduit ses fonctions quand un vrai problème les demandait, ou quand j'anticipais qu'elles répondraient aux besoins des programmeurs. Celle-ci est née d'un problème : l'artisan du logiciel vient d'abord, et la fonction après.

Depuis 2022, je présente Softanza non par son anatomie, ses modules et ses classes, mais par qui vous êtes et ce que vous essayez de faire. La présentation de 2022 avait cinq publics, chacun avec une recette de trois à cinq étapes. Le 9 octobre 2026, le site avait sept portes, une par sorte d'artisan du logiciel. La septième, pour une équipe qui livre une application, y a été ajoutée ce jour-là, et ce chapitre garde les six avec lesquelles il a été rédigé. Chaque porte dit ce que vous déclarez, ce que vous obtenez, et par où commencer. Voici ce que chacune des six déclare, en une ou deux lignes qui s'exécutent.

Le programmeur déclare l'intention dans une bibliothèque qui se lit comme une phrase. Vous venez de la voir.

L'analyste déclare les données d'un monde, et le moteur calcule la vue. Ici, trois régions du Niger avec la population que le recensement de 2012 a comptée :

o = new stzTable([ [ :region, :population ],
    [ "Agadez", 487620 ], [ "Maradi", 3402094 ], [ "Zinder", 3539764 ] ])
o.Show()
#--> ╭────────┬────────────╮
#    │ Region │ Population │
#    ├────────┼────────────┤
#    │ Agadez │     487620 │
#    │ Maradi │    3402094 │
#    │ Zinder │    3539764 │
#    ╰────────┴────────────╯

Le moteur a dessiné la vue à partir des seules données : Maradi │ 3402094 en est une ligne.

Le concepteur déclare une image comme un programme, et obtient la même image à chaque fois :

? Q("Softanza").BoxedXT([ :AllCorners = :Round ])
#--> ╭──────────╮
#    │ Softanza │
#    ╰──────────╯

L'image est la sortie du programme : un Softanza encadré, aux coins arrondis.

Le décideur déclare ce que chaque acteur du monde peut faire, une personne ou un agent d'IA, et le tribunal l'impose. Un agent est un petit fichier texte. Que dit le tribunal à celui qui ne dit pas ce qu'il couvre ? Chargez-le :

cPia = "pia: 1
name: stock-watcher
kind: pi
reversibility: compensable
schedule:
  timer: 20
skills:
  - name: restock
    does: learn stock level ordered
"
oD = StzAgentDeclarationQ(cPia)
? oD.IsValid()
#--> 0
? oD.CiteFindings()
#--> [pia-coverage @ coverage] an agent must say WHAT IT COVERS. The engine loop refuses to schedule an agent with no coverage statement (law 18), so a file without one could never run and is refused here instead of at the first tick.

Le tribunal l'a refusé ! Sa raison est imprimée : [pia-coverage @ coverage] an agent must say WHAT IT COVERS. Ici « law 18 » est la règle du moteur selon laquelle un agent sans énoncé de couverture n'est jamais planifié, et pia nomme le format du fichier, comme le montre sa première ligne.

Le formateur déclare dans la propre langue de l'apprenant. Une phrase en haoussa s'exécute : elle demande un texte contenant 'hello', passé en capitales. Le moteur compte-t-il les lettres d'un mot arabe plutôt que ses octets, et connaît-il son écriture ?

? NaturallyIn("ha", "Yi rubutu dauke 'hello' Maida shi").Result()
#--> HELLO
? Q("سلام").NumberOfChars()
#--> 4
? Q("مرحبا بالعالم").Script()
#--> arabic

La phrase en haoussa est revenue en HELLO. Le mot arabe compte 4, ses lettres et non ses octets, et son écriture est arabic.

L'agent est le sixième artisan du logiciel, celui que la présentation de 2020 de la plateforme ne pouvait pas dessiner, selon les mots de la vision que j'ai ratifiée. Un agent d'IA se déclare dans le même genre de fichier, et il est le bienvenu, avec une seule chose retenue. Un agent dont l'esprit est un modèle de langage peut proposer ; il ne peut pas détenir d'effet. Qu'arrive-t-il à un fichier qui lui en donne un ?

cLlm = "pia: 1
name: rogue
kind: llm
coverage: proposes a summary
reversibility: reversible
schedule:
  timer: 20
proposes:
  prompt: Summarize {input}
  structure:
    - field: topic
      type: string
skills:
  - name: send
    when: always
    does: propose
    effect: send-email
"
oBad = StzAgentDeclarationQ(cLlm)
? oBad.IsValid()
#--> 0
? oBad.CiteFindings()
#--> [no-llm-effectful @ skills.send.effect] REFUSED: granting 'effectful' to llm actor 'rogue' -- an LLM proposes, only a pi-gate commits (no-llm-effectful, enforced at CONSTRUCTION, not merely audited).

L'acteur llm rogue n'obtient pas son effet ! Le tribunal répond REFUSED, et dit quand : enforced at CONSTRUCTION, not merely audited. Un « pi-gate » est la barrière où un acteur gouverné valide.

Voici maintenant les trois cas pour lesquels ce livre est écrit. Ce ne sont pas des personas. Ce sont des gens et des organisations avec des documents, et la partie VI raconte chacun en entier. Ici, une page chacun.

Un restaurateur à Lyon. Il possède un restaurant de couscous, et le projet est une plateforme pour le commerce de quartier. Les notes du projet le disent sans détour : il n'est pas programmeur. Le projet a commencé par une offre en mai 2024 puis deux années de spécification riche qui n'ont rien produit qu'il puisse utiliser. Ce qui est sorti de cet échec est la règle selon laquelle je travaille depuis. Livrer petit, vite et utile, et laisser les fondations mûrir en parallèle sans jamais bloquer une livraison.

Le 4 juillet 2026, il a répondu à un rapport de cadrage dans ses propres mots et a renversé l'ordre du travail : client d'abord, restaurateur ensuite, fournisseur en dernier. L'architecture du projet a été redessinée en constellation de mondes, à partir de la conception de la bibliothèque, et le premier avenant a été clos le 4 août 2026.

Une constellation est un graphe de mondes. Un monde est une application ; un lien est une relation déclarée entre deux mondes, pour un acte nommé, et rien ne passe sans lui. Le chapitre 23 montre les trois à l'exécution ; ici, ce n'est que la forme que le projet a prise.

Le projet compte onze itérations et une campagne de vingt-deux tests simulés derrière ses règles d'interface. Dans son propre rapport, la vitesse de commande est sa première priorité, non négociable. Et le 19 août, après une journée de tests sur le terrain avec deux téléphones et une application de messagerie, les notes l'appellent le co-architecte du projet.

La première démonstration, le 15 août 2026, a été la sienne seule : la liste de vérification du dossier la prévoit pour le propriétaire seul, avec son propre téléphone et une application de messagerie comme ligne d'assistance. Les mesures qu'il a envoyées par une application de messagerie sont celles du 19 août.

L'un de ses besoins est porté par une loi de la bibliothèque : essayer les paiements avant de payer quiconque pour un compte. Que dit le registre d'un faux service de paiement pendant que vous répétez, et que dit-il quand vous passez au réel ? Exécutez-le. Le registre est nommé une fois, et chaque ligne entre les accolades lui parle : le chapitre 5 appelle cette forme la scène.

oReg = new stzServiceRegistry("restaurant")
oReg {
	Bind(:payments, new stzPaymentsSandbox())
	SetPhase(:emulated)
	? IsSound()
	#--> 1
	SetPhase(:production)
	? IsSound()
	#--> 0
	? Findings()[1][:message]
	#--> still bound to a SANDBOX in a production phase -- a fake must never ship
}

Il répond 1 en phase émulée et 0 en production, et dit pourquoi : still bound to a SANDBOX in a production phase -- a fake must never ship. Un faux en production est refusé !

Une banque à Niamey. Une banque commerciale soumise aux règles de la banque centrale de l'union monétaire ouest-africaine est titulaire d'une licence pour un produit d'évaluation d'organisation que j'ai construit à côté de la bibliothèque. Il est installé sur son propre réseau interne, sous cette licence. Le guide d'installation livré à la banque est le document qui l'atteste. La leçon qu'il a laissée dans la bibliothèque est qu'une organisation peut être jugée par son propre organigramme, selon les règles d'un régulateur. Déclarez un organigramme avec un directeur général et un audit interne qui lui rend compte. Que disent les règles du régulateur à son sujet ?

oOrg = new stzOrgChart("bank")
oOrg {
	AddPositionXTT("ceo", "Chief Executive", [ :department = "executive" ])
	AddPositionXTT("audit", "Internal Audit", [ :department = "audit", :reportsTo = "ceo" ])
	? @@( ValidateBCEAOGovernance() )
	#--> [ [ "status", "fail" ], [ "domain", "BCEAO_governance" ], [ "issuecount", 3 ], [ "issues", [ "BCEAO-001: No Board of Directors found", "BCEAO-002: Audit reports to non-board position", "BCEAO-003: No dedicated Risk Management function" ] ] ]
}

L'organigramme échoue, avec "issuecount", 3 : trois constats pour un organigramme de deux postes ! Chacun est une règle avec un numéro qu'un auditeur peut lire : BCEAO-001: No Board of Directors found est le premier. Le dossier montre la banque comme titulaire d'une licence d'un produit que j'ai construit ; il ne dit pas qui, à la banque, a déclaré quoi que ce soit.

Une organisation sur le terrain. Une organisation qui travaille au Niger, avec un siège à Niamey et des bases sur le terrain, a demandé un hub. Son propre cahier des charges préférait une plateforme low-code construite sur la suite bureautique d'un grand éditeur. Mon offre du 5 août 2026 a été choisie à la place. L'étude de conception liste quatre gains, la possession en tête. L'organisation possède son vocabulaire et ses règles, les change sans programmer, ne paie pas de licence par poste, et peut tout remettre à un programmeur de son propre pays. L'étude de conception a été construite avec ses équipes entre le 22 septembre et le 8 octobre 2026. Deux de ses principes sont ceux du livre en petit : par défaut on travaille hors ligne, et l'agent d'IA propose tandis qu'une personne décide. Cette règle est une donnée que l'organisation attache à son propre modèle de domaine. Ce modèle se juge-t-il lui-même, avec en lui un acteur LLM qui détient un effet ?

oRule = new stzGraphRule("no-llm-effectful")
oRule.SetDomainQ("agentic")
oRule.WhenQ("kind", "equals", "llm_actor")
oRule.WhenQ("capabilities", "contains", "effectful")
oRule.ThenViolationQ("an LLM proposes, only a pi-gate commits")
g = new stzGraph("agents")
g.AddNode("writer")
g.SetNodeProperty("writer", "kind", "llm_actor")
g.SetNodeProperty("writer", "capabilities", [ "inference", "effectful" ])
g.AddRule(oRule)
? g.RulesAreSound()
#--> 0

RulesAreSound() répond 0 : le modèle de domaine trouve son propre writer, un acteur LLM qui détient effectful, en violation de la règle.

Les trois cas sont un restaurateur qui n'est pas programmeur, une banque sous un régulateur et une organisation qui a choisi la possession plutôt qu'un éditeur. Le restaurateur et l'organisation sont des artisans du logiciel selon le dossier ; la banque est titulaire d'une licence d'un produit, et le dossier ne dit pas qui, là-bas, a déclaré quoi que ce soit. Le restaurateur et l'organisation n'ont pas attendu l'industrie du logiciel, et chacun se voit offrir la possession de ce qui est construit pour lui.

5. Le tribunal

agentfile_narrated prouve qu'un agent est un fichier jugé quand il est chargé : un refus par barrière, la couverture manquante parmi eux, et l'agent dont l'esprit est un modèle de langage, qui détient un effet refusé par la même règle que celle qu'emploie le graphe. service_registry_narrated prouve qu'un bac à sable en production est une violation. graphrule_object_narrated prouve la règle comme un objet attaché à un modèle. semantic_resolver_narrated tient le chemin haoussa comme dernier scénario. À ce commit, elle est en développement : son exécution s'arrête après 29 assertions, avant les assertions haoussa, sur une erreur levée par une fonction de découpage de chaînes, et terminer cette exécution est l'étape suivante. La page compte donc ses assertions et ne revendique pas son verdict ; le bloc haoussa a été exécuté seul. 00_orgchart_narrated prouve les postes, les liens hiérarchiques et le suivi des vacances de l'organigramme ; le constat BCEAO imprimé plus haut vient d'un fichier voisin, 14_bceao_governance.ring.

6. Le terrain, et où il mène

Les agents de code mènent en mains. Ils lisent, cherchent, modifient et exécutent déjà. Ce qui leur manque, selon le site lui-même, c'est un moyen de connaître une interface inconnue sans deviner, de juger leur travail selon des règles et des promesses, et de présenter un changement comme une intention qu'une personne peut relire. Les juges de Softanza sont construits ; la porte entre eux et un agent de code est conçue, et la construire est l'étape suivante.

Le low-code mène en base installée et en tout ce qui l'entoure, comme la connaissance générale le tient. L'organisation sur le terrain garde la suite de son éditeur pour ses comptes, ses documents et ses notifications. La plateforme de l'artisan du logiciel se place à côté des outils du terrain, non à leur place.

Les applications de messagerie mènent là où les artisans du logiciel sont déjà, et le dossier du restaurant n'en fait pas encore son médium. L'outil du restaurateur avant le projet était un tableur ; son propre rapport du 4 juillet 2026 le dit. La ligne qui nomme les applications de messagerie est l'intitulé d'une option du formulaire de cadrage, et non sa réponse. Aucune page du site ne nomme ces applications, et aucun médium conversationnel n'est encore une cible de la plateforme. Le chapitre 25 parle de cette direction.

Et la porte du formateur en est à une étape plus précoce que les autres. Les éditions du cours en français, en arabe et en haoussa sont des brouillons qu'un relecteur n'a pas encore lus, et la première institution à l'adopter reste à venir.

La section suivante dit ce qui est construit, ce qui est conçu et ce qui est absent.

7. La limite

• construitle fichier d'agent et son tribunal ; le registre qui refuse un faux en production ; des règles comme données sur un modèle ; les règles d'un régulateur qui jugent un organigramme ; la couche naturelle en haoussa et en arabe
• conçuune garde qui échoue quand une étape d'une page de parcours casse, chaque étape exécutée dans l'ordre ; la porte par laquelle un agent de code demande à la bibliothèque de juger son travail
• absentles plateformes des trois clients qui tournent sur le moteur Softanza ; le propre médium d'un artisan du logiciel, l'application de messagerie sur son téléphone, comme cible

Ce qui est construit : le fichier d'agent et son tribunal ; le registre qui refuse un faux en production ; des règles comme données sur un modèle ; les règles d'un régulateur qui jugent un organigramme ; la couche naturelle en haoussa et en arabe.

Ce qui est conçu : une garde qui échoue quand une étape d'une page de parcours casse, chaque étape exécutée dans l'ordre ; la porte par laquelle un agent de code demande à la bibliothèque de juger son travail.

Ce qui est absent : les plateformes des trois clients qui tournent sur le moteur Softanza. Aujourd'hui la plateforme du restaurant est un ensemble de mondes web, chacun un fichier unique ; celle de la banque est une application Python ; le hub de l'organisation est une conception. Leurs déclarations sont en cours d'écriture comme celles de Softanza. Et le propre médium de l'artisan du logiciel, l'application de messagerie sur son téléphone, n'est pas encore quelque chose auquel un monde puisse être déclaré.

8. Six portes

9. Exercice

Déclarez un agent d'IA pour un monde que vous connaissez : une boutique, une classe, un bureau. Écrivez son fichier : ce qu'il couvre, à quel point ses actes sont réversibles, quand il s'exécute, une compétence. Avant de l'exécuter, écrivez la promesse que vous attendez sous la question ci-dessous. Puis exécutez-le.

? StzAgentDeclarationQ(cYourAgent).IsValid()
#--> 1

Si le tribunal refuse, lisez la règle qu'il cite et changez votre fichier, non le tribunal. Puis faites de votre agent un modèle de langage et donnez-lui un effet, et lisez pourquoi il est refusé. Vous ne trouverez pas le fichier corrigé dans ce livre.

Je vous laisse celui-ci. Prenez le bloc de la règle de graphe de la section 3, celui de l'organisation sur le terrain, et changez une ligne : les capacités de writer deviennent [ "inference" ], sans "effectful". Exécutez-le et lisez la dernière réponse.

oRule = new stzGraphRule("no-llm-effectful")
oRule.SetDomainQ("agentic")
oRule.WhenQ("kind", "equals", "llm_actor")
oRule.WhenQ("capabilities", "contains", "effectful")
oRule.ThenViolationQ("an LLM proposes, only a pi-gate commits")
g = new stzGraph("agents")
g.AddNode("writer")
g.SetNodeProperty("writer", "kind", "llm_actor")
g.SetNodeProperty("writer", "capabilities", [ "inference" ])
g.AddRule(oRule)
? g.RulesAreSound()

Comparez-la ensuite à la réponse imprimée dans la section 3, et dites ce que la règle a lu pour donner chacune. La section 3 montre ses deux conditions. Quand vous saurez le dire, vous saurez quelle ligne du modèle de domaine la règle lit.

Le chapitre 3 est la méthode, depuis les premiers principes, et la phrase à laquelle sa méthode revient est celle-ci : vous déclarez un monde dans un langage fait pour lui, et vous gouvernez la façon dont ce monde change.

La méthode, depuis les premiers principes

Exécuté le 2026-10-15 12:58 UTC+01:00 dans la bibliothèque au commit 93d7a39bd : 5 bloc(s) sur 5 ont tenu leur promesse.

Les blocs ont été exécutés par le runtime de l'ancien langage hôte, version 1.27 ; Haro n'exécute pas encore la bibliothèque. Les binaires du moteur ont été construits dans une copie de ce commit, le plus récent le 2026-10-05 20:27 UTC+01:00 ; 1 changement(s) du moteur commité(s) après cette construction n'y sont pas.

Dans ce chapitre, je montre la méthode que suit chaque chapitre après celui-ci. Je prends « depuis les premiers principes », le slogan du terrain, et je lui donne un sens étroit : un concept, la forme du terrain, une reconception en code qui s'exécute, et un tribunal qui la juge. Je montre le plus petit réexamen que je connaisse, la chaîne vide, puis les deux actes, déclarer et gouverner, chacun en quelques lignes. Je dis ce que j'ai refusé. D'abord une fonction sans besoin, et le code généraliste comme lieu de rencontre entre les personnes et les machines. Ensuite un titre qui regardait en arrière, la grille seule, et une lecture appelée recensement. Toute la méthode revient à une phrase : vous déclarez un monde dans un langage fait pour lui, et vous gouvernez la façon dont ce monde change.

1. Le concept, tel que le terrain le tient

Dans notre industrie, « depuis les premiers principes » est un slogan. Cela veut dire raisonner à partir du bas, non par analogie. Vous l'entendrez dans des conférences et le lirez dans des annonces de lancement, et on vous montrera rarement ce qu'il a produit.

Le terrain a bien une méthode pour les décisions derrière le logiciel, et c'est une bonne méthode. Une équipe écrit une courte fiche pour chaque décision qu'elle prend, composée du contexte, de la décision et des conséquences. Beaucoup d'équipes les appellent des fiches de décision d'architecture, d'après un billet de blog que Michael Nygard a écrit en 2011. Le terrain a aussi une méthode pour prouver ce que fait une fonction : un exemple écrit sous la fonction, que les outils peuvent exécuter comme un test. Python l'offre depuis 2001 avec son module doctest, qui s'exécute quand quelqu'un l'invoque, et Rust exécute par défaut les exemples de sa documentation comme des tests. Et quand le terrain compare un outil à un autre, il dessine une grille : des lignes de fonctions, une colonne par outil, des coches et des croix.

Le terrain a trois formes ; la méthode revient à une seule phrase.

2. Le premier principe

Voici la phrase à laquelle toute la méthode revient : vous déclarez un monde dans un langage fait pour lui, et vous gouvernez la façon dont ce monde change.

Deux actes. Tout le reste de ce livre est l'un d'eux, ou les deux ensemble.

3. La forme Softanza

« Depuis les premiers principes » peut se vérifier. Dans ce livre, cela a un sens étroit. Prenez un concept que tout le monde utilise, écrivez comment le terrain le tient, reconcevez-le, et laissez un code qui porte la reconception et un tribunal qui la juge. La page d'histoire du site s'intitule Depuis les premiers principes, et la bibliothèque est sur GitHub depuis le 12 mars 2022. L'expression n'est pas ici une décoration. C'est un ordre de travail.

Laissez-moi vous montrer le plus petit réexamen que je connaisse. Demandez à Python combien de fois la chaîne vide apparaît dans le mot « text », et il répond cinq : une avant chaque lettre et une à la fin. Demandez-lui si « text » contient la chaîne vide, et il dit oui ; JavaScript dit la même chose. J'ai interrogé Python 3.13 et Node 22, le 8 octobre 2026. C'est une convention d'implémenteurs, non un fait que quiconque dirait à voix haute. Softanza énonce une règle à la place, et la règle a un nom dans la narration qui l'argumente : le vide ne se compte pas, et le vide ne se contient pas. Que répond Softanza aux deux mêmes questions ? Exécutez-le :

? Q("text").Count("")
#--> 0
? Q("text").Contains("")
#--> FALSE

Il répond 0 et FALSE. Deux lignes, et une décision avec laquelle vous pouvez être en désaccord. Voilà à quoi ressemble un réexamen quand il est honnête : assez petit pour être lu, assez explicite pour être refusé.

Une lecture du dossier, faite en octobre 2026, a compté quarante-six concepts de cette sorte, en sept familles. Les deux premières sont les paradigmes, tels que la programmation orientée portée, la programmation de la connaissance et la programmation réactive reconçus, et les moteurs de paradigme, tels que la vérité, les quantificateurs et le temps. Les cinq autres sont les patrons et la réaction ; l'expression et la perception ; les données, le temps et le raisonnement ; le système, la livraison et les opérations ; et la bibliothèque qui se connaît elle-même. Quarante-six est une lecture et non un recensement ; la page de registre du site lui-même, lue le 9 octobre 2026, dit quarante-sept. Chaque concept de la liste a son propre article ou document de conception, et c'était le critère pour entrer dans la liste.

Voyons maintenant les deux actes, chacun en quelques lignes.

Déclarer. Une sorte de valeur est déclarée en une phrase, et chaque verdict à son égard est calculé et s'explique lui-même. Pourquoi -4 ne peut-il pas être un score ?

ConstrainQ("score").ToBeQ(:Number).AndQ().ToBeQ(:Positive).AndQ().ToBeQ(:Even)
? CanQ(42).BeA("score")
#--> TRUE
? CanQ(-4).BeA("score")
#--> FALSE
? Why()
#--> no: -4 is not positive (constraint 2 of 'score')

Remarquez la dernière ligne : no: -4 is not positive (constraint 2 of 'score'). Le verdict nomme la règle qu'il a appliquée, par son numéro ! Un verdict sur une sorte déclarée qui ne peut pas dire pourquoi n'est pas admis dans cette maison.

Gouverner. Une contrainte déclarée, une fois imposée, refuse un changement avant qu'il atterrisse. Ici la chaîne « hello » doit rester en minuscules. La mise à jour vers « HELLO » atterrit-elle ?

oName = new stzString("hello")
oName.EnforceConstraint("keep-lowercase", :Lowercase)
bRefused = FALSE
try
	oName.UpdateWith("HELLO")
catch
	bRefused = TRUE
done
? bRefused
#--> TRUE
? oName.Content()
#--> hello

La mise à jour a été refusée ! L'objet reste comme il était : il répond encore hello. Déclarer une contrainte et l'imposer sont deux actes, et la garde derrière ce bloc vérifie qu'une contrainte seulement déclarée reste passive.

Gouverner a aussi un côté qui fait face à la personne. Le système demande, et il ne vous laisse pas clore un monde qui n'est pas complet. Que dit-il quand vous essayez de conclure quand même ?

oKB = new stzKnowledgeGraph("restaurant")
oKB {
	Know("margherita", "dish")
	Know("tiramisu", "dish")
	AddConversationQ("setup").SetGoal(StzGoalQ().RequireEach("dish", "contains"))
	aQ = AskInXT("setup")
	? aQ[:why]
	#--> every dish needs 'contains'
}
try
	oKB.ConcludeIn("setup", "world")
catch
	? cCatchError
done
#--> Can't conclude: 2 gap(s) remain -- the wise-coding loop is not done. Ask the next question.

Le but a été déclaré : chaque plat doit dire ce qu'il contient. L'écart entre le but et ce qui est connu génère la question, et la question porte sa raison. Conclure alors que deux écarts demeurent est refusé ! La ligne imprimée est Can't conclude: 2 gap(s) remain -- the wise-coding loop is not done. Ask the next question., et ses derniers mots vous disent quoi faire ensuite. Le chapitre 18 parle de cette conversation. Ici il suffit de voir que gouverner n'est pas seulement refuser ; c'est demander.

Encore un réexamen, parce que les moteurs de paradigme font aussi partie de la méthode. La vérité, dans le langage sous Softanza, est une affaire de vide et de non-vide, et une liste de mots compte comme vraie. Softanza garde cette vérité par défaut et vous laisse l'étendre par déclaration. Une fois « wrong » déclaré comme un élément qui rend une liste fausse, une liste qui le contient est-elle encore vraie ?

SetItemsMakingAListFalse([ "false", "wrong", "dangerous" ])
? IsTrue([ "hello", "this", "is", "wrong" ])
#--> TRUE
? IsTrueXT([ "hello", "this", "is", "wrong" ])
#--> FALSE

La réponse de l'hôte est inchangée : TRUE. La réponse étendue lit votre déclaration et dit FALSE ! « La vérité devient une affaire de politique », dit la narration, et la politique est écrite là où vous pouvez la lire.

Voilà donc la méthode, sous la forme que vous rencontrerez dans chaque chapitre après celui-ci. Un concept tel que le terrain le tient. Le seul principe auquel le dossier revient. La reconception, en code qui s'exécute, avec sa promesse sous chaque bloc. La décision, et ce qui a été refusé. Le tribunal qui la prouve, par son nom. Le terrain, et où il mène. La limite, en trois mots d'étape. Le premier, construit, veut dire que le code existe, qu'une garde existe et qu'un bloc a tourné ; c'est le construit du site lui-même. Le deuxième, conçu, couvre ce que le site appelle en construction, spécification et proposition ratifiée. Le troisième, absent, couvre ce que le site appelle nommé, un nom sans rien derrière lui pour l'instant, et ce que personne n'a nommé. Cinq mots du site, trois du livre. Puis six portes, une pour chaque sorte de lecteur, et un exercice.

Et le livre est jugé comme la bibliothèque l'est. Chaque bloc qu'il contient s'est exécuté dans la bibliothèque la nuit où la page a été construite, au commit imprimé en haut de la page. Une page dont les promesses ne sont pas tenues ne se construit pas.

5. Le tribunal

Les trois blocs des deux actes reposent sur deux gardes. modality_narrated prouve qu'une sorte déclarée peut être inspectée, qu'un verdict nomme la contrainte qui a échoué, et qu'une sorte inconnue n'autorise jamais en silence. Elle prouve aussi qu'une contrainte imposée refuse une mauvaise mise à jour avant qu'elle atterrisse, tandis qu'une contrainte déclarée reste passive. wisecoding_narrated prouve la conversation. Elle prouve des écarts calculés à partir du but déclaré, une question qui dit pourquoi elle est posée, des réponses admises, et une loi qui refuse à travers la conversation et atteint une personne. Et elle prouve que conclure avec des écarts ouverts est refusé. Sa sœur, wisecoding_rich_narrated, porte les cas plus riches de la même boucle.

Le réexamen du vide repose sur 612_dealing_in_emptiness_in_softanza.ring, un test de la bibliothèque écrit en scénarios, chaque ligne énonçant le résultat qu'elle attend. Le réexamen de la vérité repose sur sa narration et sur l'exécution de ce livre, et sa garde est l'étape suivante. Le fichier de la bibliothèque qui lui est consacré, 04_truth_in_softanza.ring, fixe la liste des mots faux par affectation et n'appelle jamais la fonction, de sorte qu'il ne prouve pas le bloc.

Le tribunal est nommé ; vient ensuite le terrain, et où il mène.

6. Le terrain, et où il mène

Le terrain mène en adoption. Les fiches de décision sont un standard léger que beaucoup d'équipes utilisent, avec des modèles et des outils autour. L'élément décision de ce livre existe dans ce livre et dans une étude du dossier, et pas encore comme donnée dans la bibliothèque. Les exemples de la documentation peuvent être exécutés par l'outil standard de Python, et Rust les exécute par défaut. Les promesses de Softanza sont jugées par les exécuteurs propres de la maison, qu'aucun outil extérieur ne lit encore. Et le terrain compare par grille, comme les pages du dossier le font aussi ; une grille seule est un début, et c'est pourquoi la section 4 demande la perte à côté du gain.

Là où je pense que Softanza se distingue, c'est en un seul endroit : le réexamen est mené jusqu'au bout. Je tiens cela pour une vue, non pour un résultat. La décision est écrite, la reconception s'exécute, la promesse est jugée à la construction, et le mot d'étape dit jusqu'où chaque pièce est allée. Une fiche de décision ne s'exécute pas. Un exemple ne dit pas ce qui a été refusé. Ici, ils sont un seul objet.

7. La limite

• construitle tribunal derrière chaque bloc de ce chapitre sauf celui de la vérité, et les mots d'étape que le site imprime sur chaque produit
• conçule registre des concepts repensés comme données, avec une garde qui échoue quand un concept n'a pas de preuve
• absentune page qui montre chaque concept repensé avec une preuve exécutée ; un fichier de tests pour le moteur de paradigme de la fusion de sections

Ce qui est construit : le tribunal derrière chaque bloc de ce chapitre sauf celui de la vérité, et les cinq mots d'étape que le site imprime sur chaque produit.

Ce qui est conçu : le registre des concepts repensés comme données, une ligne par concept avec son article, son code, sa garde et son étape. À côté, une garde qui échoue quand un nouveau concept arrive sans ligne. Les deux sont aujourd'hui une spécification.

Ce qui est absent : une page qui montre chaque concept avec une preuve exécutée ; la page de registre du site, lue le 9 octobre 2026, les liste chacun avec ses preuves. Un fichier de tests pour le module du moteur de l'un des moteurs de paradigme, la fusion de sections : il n'en a pas en propre, bien que ses méthodes de fusion s'exécutent dans base/test/string/289_content.ring et max/test/stzListOfPairsTest.ring. Et quelques réexamens où l'article va un pas au-delà du code d'aujourd'hui. L'article sur les quantificateurs demande si toutes vos notes AreGreaterThan la moyenne, et cette méthode s'écrit autrement dans la bibliothèque aujourd'hui. Ses quantificateurs plus conviviaux, certains, la plupart et peu, tirent au hasard, de sorte qu'ils ne portent aucune promesse aujourd'hui. Le registre est une lecture, et une lecture peut manquer un concept qui ne vit que dans un seul article.

Là s'arrête ce chapitre ; six portes suivent, une pour chaque sorte de lecteur.

8. Six portes

9. Exercice

Choisissez un défaut de votre propre langage que vous n'avez jamais questionné : ce que compte la chaîne vide, ce qui compte comme vrai, ce que veut dire « la plupart ». Avant d'exécuter quoi que ce soit, écrivez en une phrase la règle que vous croyez juste. Puis écrivez deux promesses sous la forme que vous avez rencontrée : la ligne que votre langage imprime aujourd'hui, et la ligne que votre règle doit imprimer.

? YourDefault(the_input)
#--> what your language prints today
? YourRule(the_input)
#--> what your declared rule must print

Exécutez les deux. Je ne vous dirai pas quelle règle est juste. Si votre règle et votre langage divergent, vous avez trouvé une décision que quelqu'un a prise pour vous, et vous pouvez maintenant la prendre vous-même.

Je vous laisse celui-ci, volontairement. Reprenez le bloc de la section 3 qui gouverne une chaîne, changez un seul mot, EnforceConstraint pour AddConstraint, et exécutez-le tel qu'il est donné ci-dessous. Je n'en imprime aucune sortie.

oName = new stzString("hello")
oName.AddConstraint("keep-lowercase", :Lowercase)
bRefused = FALSE
try
	oName.UpdateWith("HELLO")
catch
	bRefused = TRUE
done
? bRefused
? oName.Content()

Regardez ce qu'il imprime : si la mise à jour a été refusée, et ce que l'objet contient. Lisez ensuite la section 3, juste après le bloc, et la section 5, sur la garde qui le vérifie : la page dit pourquoi. Quand vous aurez les deux lignes, vous saurez pourquoi une contrainte déclarée n'est pas une contrainte imposée.

Le chapitre 4 dessine la plateforme en une image, sous une seule idée à chaque altitude : rien n'est cru, tout est jugé.

La plateforme en une image

Exécuté le 2026-10-15 12:58 UTC+01:00 dans la bibliothèque au commit 93d7a39bd : 8 bloc(s) sur 8 ont tenu leur promesse.

Les blocs ont été exécutés par le runtime de l'ancien langage hôte, version 1.27 ; Haro n'exécute pas encore la bibliothèque. Les binaires du moteur ont été construits dans une copie de ce commit, le plus récent le 2026-10-05 20:27 UTC+01:00 ; 1 changement(s) du moteur commité(s) après cette construction n'y sont pas.

Dans ce chapitre, je dessine toute la plateforme en une image, lue de bas en haut : le moteur, les couches, les zones, les mondes, les artisans du logiciel, et à côté de chaque étage son tribunal. Je la parcours étage par étage, avec à chaque étage un bloc que vous pouvez exécuter. Puis je dis ce que j'ai refusé en chemin : le calcul dans les faces, un drapeau pour choisir une couche, les mini-applications. L'image se résume en une seule idée à chaque altitude : rien n'est cru, tout est jugé.

1. Le concept, tel que le terrain le tient

Le terrain dessine une plateforme comme une pile de boîtes. Le noyau en bas, un runtime et ses bibliothèques au milieu, les applications au-dessus, et parfois une colonne sur le côté pour la sécurité ou les outils. À l'intérieur d'une même base de code, la même image devient une règle sur les dépendances : une couche interne ne sait rien des couches externes, et les flèches ne pointent que vers l'intérieur. Les trois crates standard de Rust, une pour le métal nu, une pour la mémoire, une pour un système d'exploitation complet, en sont la version la plus nette que je connaisse. Trois profondeurs du même langage, choisies par ce que la cible offre.

Pour les applications, l'image du terrain est un hôte. Une grande application embarque un runtime et fait tourner de petites applications à l'intérieur, qui partagent ses services et son magasin. Dans les deux images, le juge est à l'extérieur : une suite de tests à côté du code, une revue à côté du magasin. Dans les images que je connais, aucune ne dessine le tribunal comme une colonne debout à chaque étage.

Softanza dessine cette colonne, et une seule idée tient toute l'image.

2. Le premier principe

La pile de la plateforme se résume, dans la vision que j'ai ratifiée, en une seule idée à chaque altitude : rien n'est cru, tout est jugé.

3. La forme Softanza

Voici toute la plateforme en une image, lue de bas en haut. Chaque étage repose sur celui qui est dessous, et chaque étage est jugé par un tribunal à côté de lui. Les chiffres qu'elle porte ne sont pas tapés par moi. Le build les lit, quand cette page est faite, dans la bibliothèque et dans la carte des zones du site.

Parcourons-la, étage par étage, avec à chaque étage un bloc que vous pouvez exécuter.

Le moteur. En bas se trouve un moteur écrit en Zig : un ensemble de bibliothèques derrière une interface C, une par domaine, regroupées par la couche qui les charge. Selon la règle de conception du moteur, le moteur fait le calcul ; la bibliothèque au-dessus lui donne un vocabulaire. Un petit exemple rend la division visible. Demandez au langage sous-jacent à Softanza la longueur du mot arabe pour la paix, puis demandez-la au moteur. Que compte chacun ? Exécutez-le :

? len("سلام")
#--> 8
? Q("سلام").NumberOfChars()
#--> 4
? Q("مرحبا بالعالم").Script()
#--> arabic

Le langage compte des octets et répond 8. Le moteur compte des lettres et répond 4, et il connaît l'écriture : arabic. Quatre lettres, pas huit !

Le moteur a aussi sa propre porte, sous chaque classe. Les nombres trop grands pour l'arithmétique de la machine sont additionnés exactement, par le moteur lui-même :

a = StzEngineBigIntFromString("99999999999999999999999999999999")
? StzEngineBigIntToString( StzEngineBigIntAdd(a, StzEngineBigIntFromString("1")) )
#--> 100000000000000000000000000000000

Le moteur répond 100000000000000000000000000000000, la somme exacte.

Les couches. Au-dessus du moteur, la bibliothèque est découpée en trois couches, selon la profondeur de capacité. Le noyau, avec le préfixe stk, est léger et parle directement au moteur, pour les petits appareils et les petits binaires. La base, stz, est la couche riche, où vivent le vocabulaire et ses formes, assez pour la plupart des solutions. Le max, stx, est destiné aux innovations les plus fortes. Une couche se choisit par le fichier qu'un programme charge. Le même verbe veut-il dire le même acte au noyau et à la base ? Exécutez-le :

o1 = new stkList([ "one", "and", "one", "makes", "two", "ones" ])
? o1.FindFirst("one")
#--> 1
o2 = new stzList([ "one", "and", "one", "makes", "two", "ones" ])
? o2.FindFirst("one")
#--> 1

Les deux répondent 1 : le même verbe, le même acte, à deux profondeurs.

Les zones. À travers les couches, la bibliothèque est cartographiée par l'Atlas du site en zones regroupées en bandes, et chaque zone en voies. Chaque voie est notée d'émergente à forte, la plupart avec la ligne qui le prouve. L'Atlas dit ce qui existe, et à quel point c'est bien. Un autre principe de la conception du moteur est qu'un verbe veut dire le même acte sur toute structure qui l'admet. Tient-elle pour une paire, une chaîne et une liste ? Exécutez-le :

? @@( Q("tea rice tea").FindAll("tea") )
#--> [ 1, 10 ]
? @@( Q([ "tea", "rice", "tea" ]).FindAll("tea") )
#--> [ 1, 3 ]

Sur la chaîne, FindAll répond des positions de caractères : [ 1, 10 ]. Sur la liste, il répond des positions d'éléments : [ 1, 3 ]. Le même acte, sur deux structures.

Les mondes. Au-dessus de la bibliothèque, l'unité n'est pas un module mais un monde : une application est un monde vivant de sens, avec ses choses, ses relations et ses règles. Un monde se déclare. Que dit-il de lui-même quand on lui demande de s'expliquer ? Exécutez-le :

oApp = new stzApp("FieldVisits")
oApp {
    AddThingQ(:Account) { Has([ :number, :chapter, :balance ])  IsTrue(:balance, "@ >= 0") }
    AddThingQ(:Client)  { Has([ :code, :name, :city ])  Owns(:Account) }
    AddRelation(:Account, :belongsTo, :Client)
}
oApp.Explain()
#--> WORLD FieldVisits   lives in: memory (not persisted)
#      BEING
#        account (number, chapter, balance)
#            true when balance @ >= 0
#        client (code, name, city)
#      RELATIONS
#        client owns account
#        account belongsto client
oApp.Live()
#--> [FieldVisits] is live -- 2 thing(s), 0 flow(s), 0 reaction(s), 0 goal(s); 0 proposal(s)

Il répond WORLD FieldVisits lives in: memory (not persisted), puis liste son être et ses relations. Live() répond [FieldVisits] is live -- 2 thing(s), 0 flow(s), 0 reaction(s), 0 goal(s); 0 proposal(s). Deux choses, et ni flux, ni réaction, ni but. Le monde dit ce qui a été déclaré, et rien de plus.

Les mondes se composent en constellation. Ici un restaurant et son fournisseur de produits sont deux mondes, et un lien entre eux déclare l'unique traversée permise. Les trois lignes Gov déclarent le risque de la traversée, l'accordent au restaurant et fixent l'autorité du restaurant ; la garde derrière ce bloc montre que sans elles, même la traversée déclarée est refusée. Que devient une traversée qu'aucun lien ne déclare ? Exécutez-le :

oResto = StzAppQ("resto")
oResto.AddThingQ(:dish) { Has([ :name, :price ]) }
oSupplier = StzAppQ("supplier")
oSupplier.AddThingQ(:crate) { Has([ :produce, :qty ]) }
oCon = new stzSuperApp("acme-group")
oCon {
	AddWorld("resto", oResto)
	AddWorld("supplier", oSupplier)
	Bond("resto", "supplier", "order-produce")
	GovDeclareRisk("order-produce", 2)
	GovGrant("resto", "order-produce")
	GovSetAuthority("resto", :Delegated)
	? CallAcross("resto", "supplier", "order-produce")
	#--> 1
	? CallAcross("resto", "supplier", "raid-kitchen")
	#--> 0
	? Why()
	#--> no bond declares 'raid-kitchen' from 'resto' to 'supplier'.
}

La traversée déclarée répond 1. L'autre répond 0, refusée ! La constellation donne sa raison en une ligne : no bond declares 'raid-kitchen' from 'resto' to 'supplier'. Toute autre traversée est refusée avec sa raison.

Le socle commun est le sol partagé d'une constellation, ce sur quoi chacun de ses mondes se tient. Il tient une identité, une session et un magasin. C'est un monde comme les autres, le monde zéro, et non un genre particulier de nœud. Le chapitre 23 le montre et dit jusqu'où le code est allé dans cette direction.

Et une plateforme, stzPlatform dans la figure, est l'enveloppe autour d'une solution : ses parties, les systèmes sur lesquels elles tournent, et l'ordre dans lequel elle est construite, répétée et déployée. Vous déclarez la solution qu'elle porte comme un stzPlatformProfile, et vous la verrez refuser de déployer avant d'être construite au chapitre 33. Voici ce que son planificateur de livraison, stzDelivery, fait des couches, pour le web : une partie d'une solution ne livre que les groupes du moteur dont elle a besoin, et seulement ceux qui appartiennent à Softanza. Le téléphone ci-dessous demande quatre capacités. Combien de groupes du moteur livre-t-il ? Exécutez-le :

oDelivery = new stzDelivery("my-shop")
oDelivery {
	AddSuperApp(:phone, :Android)
	AddBackend(:api, :LinuxServer)
	NeedsIn(:phone, [ :Unicode, :PivotTable, :ConstraintSolver, :Regex ])
	oPlan = Plan()
}
? @@( oPlan.EngineCapsFor(:phone) )
#--> [ "pivottable", "constraintsolver" ]
? @@( StzWasmGroupsFor( oPlan.EngineCapsFor(:phone) ) )
#--> [ "aggregation", "solver" ]

Deux, pas quatre : aggregation et solver ! Le système propre du téléphone gère l'une des deux autres, Unicode, et Softanza livre l'autre, Regex, comme une construction dans le langage propre de la cible.

Les artisans du logiciel. En haut se trouvent les six portes du chapitre 2 : le programmeur, l'analyste, le concepteur, le décideur, le formateur et l'agent. Et une personne travaille à travers chaque étage, du moteur à l'organisation : l'architecte de plateforme. Le dossier nomme ce rôle dans trois de ses documents, et aucun autre rôle ne traverse toutes les bandes de l'Atlas.

Le tribunal. À côté de chaque étage se tient son juge. Le moteur a ses tests et les contrats entre les étages. Les couches ont les gardes narrées. La plupart des voies des zones portent une ligne de preuve. Les mondes ont leurs liens et leurs normes, l'ordre de construction et de déploiement, et le refus d'un faux en production. Les interfaces des artisans du logiciel ont une constitution de verbes et de règles à laquelle chaque élément doit remonter. Et au-dessus de tout cela, le modèle de menaces de la plateforme énumère ses garanties, chacune liée à la garde qui la prouve. Sa propre garde échoue quand une ligne nomme une garde qui n'existe plus.

Les parties II à IV de ce livre sont des repensées, et chacune est une boîte de cette image. La partie V assemble l'image en usage.

5. Le tribunal

00_stzapp_narrated prouve qu'un monde est déclaré et rendu visible. 06_stzsuperapp_narrated prouve la constellation : des mondes qui se joignent, le socle commun comme monde zéro, des traversées barrées par des normes avec le lien nommé comme raison, un monde retiré qui rompt ses liens. full_scope_model_narrated, le terrain d'entente de l'architecte, prouve la solution modélisée d'abord, les portées qui refusent ce qu'une cible interdit, et l'ordre de construction et de déploiement. 01_platform_narrated prouve les devoirs de la plateforme. threat_model_narrated lit le modèle de menaces de la plateforme et échoue quand une garantie nomme une garde qui n'existe plus.

6. Le terrain, et où il mène

Les trois profondeurs de Rust sont imposées par son compilateur et employées chaque jour sur le métal nu. La règle de Softanza est tenue au moteur et aux fichiers d'entrée, et pas encore portée là où la base devrait s'appuyer sur le noyau, comme le montre la section 7.

Les bibliothèques de texte du terrain mènent sur la locale : la propre carte de Softanza nomme la couche de locale des composants internationaux comme l'écart net de ses chaînes, et nomme le pari derrière lui : sa zone de locale laisse ces composants dehors à dessein, sans collation, sans règles de pluriel et sans fuseaux horaires.

À l'échelle de vrais utilisateurs, les hôtes de super-applications du terrain mènent aujourd'hui. Le dossier les nomme comme le modèle qu'il a refusé et ne mesure rien contre eux, alors je n'en mesurerai pas non plus.

Et l'Atlas lui-même imprime ce qui reste à venir pour Softanza. La zone binaire est pour l'instant un plan, et son code livré est l'étape suivante ; le volet de l'extensibilité (greffons, interface de fonctions étrangères, embarqué) est surtout prévu ; la zone du système compte peu de voies notées fortes à ce jour. Je tiens cela pour une vue, non pour un résultat. Une carte qui imprime ses étapes est la seule sorte qui vaille la peine d'être lue.

7. La limite

• construitle moteur et ses bibliothèques ; la couche base ; les mondes, les constellations et les plateformes avec leurs gardes ; le sous-ensemble du moteur qu'une partie livre, pour le web
• conçula couche max chargée par son fichier d'entrée ; la couche base s'appuyant sur la couche noyau ; un chargeur pour un seul domaine de la base ; un tribunal qui vérifie les couches contre leur contrat
• absentun programme entier et son moteur emballés dans un seul fichier ; une plateforme cliente sur le moteur

Je mets maintenant sur l'image les trois mots d'étape, construit, conçu et absent.

Ce qui est construit : le moteur et ses bibliothèques, la couche base, les mondes, les constellations et les plateformes avec leurs gardes, et, pour le web, le sous-ensemble du moteur qu'une partie livre.

Ce qui est conçu, ou construit et inaccessible. Les propres classes de la couche max sont écrites et chargées par aucun fichier d'entrée. Que répond le runtime quand vous en demandez une ? Exécutez-le :

try
	o3 = new stxString("one and one")
catch
	? cCatchError
done
#--> Error (R11) : Error in class name, class not found: stxstring

Le runtime répond : Error in class name, class not found: stxstring. La classe est écrite, et aucun fichier d'entrée ne la charge !

Le contrat des couches dit que la couche base s'appuie sur le noyau, par héritage ou par délégation. Elle ne fait ni l'un ni l'autre pour les domaines communs : les deux partagent le moteur et implémentent deux fois ces domaines. La couche noyau elle-même est en développement face au moteur aujourd'hui. Ses classes de chaîne et de caractère appellent des noms du moteur qu'aucun fichier du moteur n'enregistre, comme le rapporte mon étude du dossier. Le bloc de la section 3 ne montre que des listes. Un chargeur qui amène un domaine de la base sans les autres n'est pas construit. Un tribunal qui lit le contrat des couches contre l'arbre et échoue en cas de dérive est une spécification, proposée dans cette étude. Ce qui est construit, ce sont deux implémentations qui partagent un moteur ; la ligne du contrat selon laquelle la base s'appuie sur le noyau est conçue.

Ce qui est absent : un programme entier et son moteur emballés dans un seul fichier sans aucune dépendance, et une plateforme cliente qui tourne sur le moteur.

8. Six portes

Chacune des six portes lit cette image depuis l'endroit où elle se tient.

9. Exercice

Dessinez votre propre solution comme ce chapitre dessine Softanza : des étages, et un tribunal à côté de chacun. Pour chaque boîte, écrivez le fichier qui la déclare et la garde qui la juge, et mettez dessus un mot d'étape : construit, conçu ou absent.

Puis déclarez-en deux parties avec stzPlatformProfile, donnez le profil à un stzPlatform, et avant d'exécuter quoi que ce soit, écrivez la ligne que vous attendez quand vous lui demandez de déployer avant de construire. Exécutez-le. Une boîte sans tribunal à côté est votre première trouvaille.

Je vous laisse celui-ci. La section 7 dit que les classes de chaîne de la couche noyau sont encore en développement face au moteur, et le bloc de la section 3 ne vous montre que des listes. Prenez le bloc de la section 7 et changez un mot : stxString devient stkString.

try
	o3 = new stkString("one and one")
catch
	? cCatchError
done

Exécutez-le, et lisez ce que répond le runtime. Puis retournez à la section 7 et trouvez quel nom est appelé, et qui aurait dû l'enregistrer. Quand vous l'aurez résolu, vous saurez pourquoi la ligne du contrat des couches selon laquelle la base s'appuie sur le noyau est dite conçue, et non construite.

Le chapitre suivant quitte l'image pour le code écrit à l'intérieur d'elle, et énonce la première loi : le code adhère à la façon dont une personne pense, et le tribunal le juge quel que soit celui qui l'a écrit. Son principe tient en une phrase : ce que vous pensez est ce que vous écrivez.

Loi : le code adhère à la façon dont une personne pense, et le tribunal le juge quel que soit celui qui l'a écrit

Exécuté le 2026-10-15 12:58 UTC+01:00 dans la bibliothèque au commit 93d7a39bd : 9 bloc(s) sur 9 ont tenu leur promesse.

Les blocs ont été exécutés par le runtime de l'ancien langage hôte, version 1.27 ; Haro n'exécute pas encore la bibliothèque. Les binaires du moteur ont été construits dans une copie de ce commit, le plus récent le 2026-10-05 20:27 UTC+01:00 ; 1 changement(s) du moteur commité(s) après cette construction n'y sont pas.

Dans ce chapitre, je prends les deux choses que le terrain appelle style de code et je pose la question qu'il ne pose pas : si une ligne suit l'ordre dans lequel celui qui l'a écrite a raisonné. J'exécute l'exemple fondateur dans la forme la plus proche qui s'exécute encore, puis le modèle mental sur une liste, les formes du verbe, le paramètre nommé, la scène et l'historique d'une chaîne. Une promesse se tient sous chaque question. Je dis ce que j'ai laissé aller, l'implémentation propre de la bibliothèque, et ce que j'ai refusé de laisser aller, le style du code écrit avec elle. Je montre le tribunal qui existe aujourd'hui, sur les propres classes de la bibliothèque, et celui qui n'est que conçu. La devise n'a pas changé depuis 2020 : ce que vous pensez est ce que vous écrivez.

Ce que l'âge de l'IA change ici

Pendant des années, la plupart du code écrit avec Softanza l'a été d'une seule main, et cette main était la mienne. Le style de la bibliothèque était ma façon d'écrire. Puis les machines sont arrivées, et aujourd'hui la plupart du code d'ici est écrit par des modèles d'IA, comme la conception du volet de l'intelligence dit que c'est le cas partout, en une phrase : la plupart de la programmation d'aujourd'hui est faite par des agents et des modèles de langage, pas par des humains.

Cela change ce qu'est un style. Un style qui vit dans les habitudes d'une seule personne meurt quand cette personne cesse d'écrire chaque ligne. Il doit devenir quelque chose à quoi l'on peut tenir une machine, et quelque chose qu'une machine peut vérifier, sinon il s'amenuise. Dans cette maison, il s'est amenuisé, et je vous montrerai où. Alors ce mouvement du livre, La programmation repensée, s'ouvre sur une loi qui a deux moitiés. La seconde existe à cause de l'âge : le code adhère à la façon dont une personne pense, et le tribunal le juge quel que soit celui qui l'a écrit. Par le tribunal, j'entends la machine qui juge un code selon les règles de la maison ; aujourd'hui elle ne juge que les propres classes de la bibliothèque, et la section 5 dit comment.

Il y a une dépendance à dire à voix haute. Ce livre suit l'ordre de sa couverture, du familier au nouveau : la programmation, puis les langages, puis l'intelligence. La logique propre du dossier va dans l'autre sens. Le premier acte est de déclarer un langage ; la programmation se passe à l'intérieur d'un langage déclaré ; l'intelligence est gouvernée par les deux. Les formes du vocabulaire sont déjà déclarées dans un prototype de Haro, comme le note l'entrée du 3 octobre 2026 de sa charte. L'usage que ce chapitre décrit, la scène, la chaîne, le paramètre nommé, la promesse sous chaque ligne, est destiné à être déclaré aussi. Lisez donc cette loi en sachant que la partie III la soutient.

1. Le concept, tel que le terrain le tient

Dans notre industrie, le « style de code » veut dire deux choses, et aucune ne concerne la façon dont une personne pense. La première est la mise en page et le nommage, imposés par des machines : le guide de style de Python depuis 2001, le formateur de Go depuis 2009, et les formateurs que tout projet moderne exécute avant un commit. Ils règlent les disputes sur les espaces et les majuscules, et ils y sont bons. La seconde est l'interface fluide : des méthodes chaînées de sorte qu'une ligne se lise presque comme une phrase.

L'âge du code généré a ajouté une troisième pratique : vérifier après. Un modèle écrit, les tests et les linters lisent ce qu'il a écrit, et le modèle réessaie s'ils se plaignent. La ligne elle-même est jugée sur sa forme et son résultat. Savoir si elle suit l'ordre dans lequel celui qui l'a écrite raisonnait est une question pour laquelle je ne connais aucun outil.

2. Le premier principe

Ma devise pour cela n'a pas changé depuis 2020 : ce que vous pensez est ce que vous écrivez.

La section 3 montre la devise à l'œuvre.

3. La forme Softanza

La diapositive fondatrice mettait toute l'idée sur une page. Sur la gauche, les quatre étapes de la pensée d'une personne : je prends le mot « softanza » ; je le mets en majuscules ; j'obtiens ses caractères ; je les joins avec une espace. Sur la droite, les mêmes quatre étapes en une ligne de code, comme si le texte de gauche avait été collé et exécuté.

Cette ligne exacte ne s'exécute plus. Son troisième maillon, une méthode qui transformait les caractères en une liste de chaînes en une seule étape, n'est pas dans la bibliothèque aujourd'hui. Il ne survit que dans des fichiers archivés et dans un échantillon de travail, sous la forme CharsQRT. Je vous le dis d'abord parce qu'un chapitre de loi qui cache son propre exemple fondateur ne mériterait pas votre confiance. Quelle est la forme la plus proche qui s'exécute, avec les quatre étapes toujours visibles, et qu'offre la bibliothèque comme verbe dédié ? Exécutez les deux :

? StzListOfStringsQ( StzStringQ("softanza").UppercaseQ().Chars() ).ConcatenatedUsing(" ")
#--> S O F T A N Z A
? StzStringQ("softanza").UppercaseQ().Spacified()
#--> S O F T A N Z A

Les deux formes impriment S O F T A N Z A. L'idée est intacte ; le maillon fluide a été perdu. Une demande part vers la bibliothèque pour le rétablir.

Le modèle mental est la même idée au niveau d'un problème. Vous dites le problème en mots simples. Vous choisissez l'objet qui tient les données. Puis vous demandez, dans l'ordre : contient-il ce qui m'importe, combien, où ? Ensuite vous agissez sur ces positions, ou vous appelez le verbe qui le fait pour vous. Prenez une liste qui contient des chaînes vides. En contient-elle, combien, et où ? Exécutez :

o1 = new stzList([ "A", "", "B", "", "", "C" ])
? o1.ContainsEmptyStrings()
#--> TRUE
? o1.CountEmptyStrings()
#--> 3
? @@( o1.FindEmptyStrings() )
#--> [ 2, 4, 5 ]
o1.ReplaceEmptyStrings(:With = "~")
? @@( o1.Content() )
#--> [ "A", "~", "B", "~", "~", "C" ]

La liste répond TRUE, puis 3, puis [ 2, 4, 5 ], et après l'acte elle se lit [ "A", "~", "B", "~", "~", "C" ]. Contenir, compter, trouver, agir. Chaque ligne est une étape de pensée, et les noms sont les mots que vous emploieriez pour la dire.

La forme du verbe dit ce qui arrive à l'objet. Que fait chaque forme à l'objet ? Exécutez-les sur une même chaîne :

o1 = new stzString("HAxxRxO")
? o1.Removed("x")
#--> HARO
? o1.Content()
#--> HAxxRxO
o1.Remove("x")
? o1.Content()
#--> HARO
? Q("haxxrxo").RemoveQ("x").UppercaseQ().Spacified()
#--> H A R O

Removed a imprimé HARO, et l'objet se lisait encore HAxxRxO ! Remove a ensuite agi sur lui, et Content() a lu HARO. La chaîne avec Q s'est terminée sur H A R O. Par convention de la bibliothèque, le participe passé vous donne une copie changée et laisse l'objet tranquille. Le verbe simple agit sur l'objet. Le verbe avec Q agit et rend l'objet, pour que l'étape suivante puisse suivre.

Faut-il retenir quel argument vient en second ? Un paramètre peut être nommé, et le nom se lit comme de l'anglais :

? Q("I love Haro").Replaced("love", :With = "♥")
#--> I ♥ Haro
o2 = new stzList([ "tea", "rice", "fish" ])
o2.SwapItems(:AtPositions = 1, :And = 3)
? @@( o2.Content() )
#--> [ "fish", "rice", "tea" ]

Le texte imprime I ♥ Haro et la liste [ "fish", "rice", "tea" ]. Les noms :With, :AtPositions et :And disent quel argument est lequel.

Comment plusieurs questions sur une même chose se lisent-elles comme une liste ? Elles sont posées à l'intérieur de sa scène, un bloc d'accolades autour de l'objet. L'objet est nommé une seule fois :

Q("haro php HARO ruby Haro") {
	? NumberOfOccurrence(:Of = "haro")
	#--> 1
	? NumberOfOccurrenceCS(:Of = "haro", :CS = FALSE)
	#--> 3
	? @@( FindAllCS("haro", FALSE) )
	#--> [ 1, 10, 20 ]
}

La scène répond 1, puis 3, puis [ 1, 10, 20 ]. Le même mot a compté 1, puis 3 dès que :CS = FALSE a été dit ! L'objet a été nommé une seule fois, et les trois questions se lisent comme une liste.

Les étapes de la pensée peuvent-elles être relues ? Un objet élevé avec son historique garde le résultat de chaque étape de sa chaîne :

? @@( Qh(12500).AddQ(500).RetrieveQ(1500).DivideByQ(500).MultiplyByQ(2).History() )
#--> [ 12500, 13000, 11500, 23, 46 ]

L'exécution a imprimé [ 12500, 13000, 11500, 23, 46 ]. Cinq valeurs, la valeur de départ comprise, et la chaîne se termine à 46 ! L'article qui a raconté cela le premier promettait quatre valeurs, sans la première, et une valeur finale courte d'une unité, 45. La garde derrière le bloc énonce la règle d'aujourd'hui, sur une chaîne de texte : la valeur initiale, puis le résultat de chaque étape. Le livre prend la réponse de l'exécution, pas celle de l'article.

Les mêmes pas peuvent s'écrire comme une scène, la forme que je tiens pour la base du style : l'objet est nommé une fois, et chaque ligne entre les accolades lui parle.

# A number object that keeps its history
QH(12500) {
	# Inside the braces, each line speaks to the object
	Add(500)
	Retrieve(1500)
	DivideBy(500)
	MultiplyBy(2)

	# Its history, as one expressive value
	? @@( History() )
	#--> [ 12500, 13000, 11500, 23, 46 ]
}

La chaîne le dit en une phrase, la scène le dit en pas. Le livre emploie les deux : la phrase quand la pensée est une, la scène quand elle est une procédure. La forme classique nomme l'objet à chaque ligne, et beaucoup de lecteurs pensent ainsi :

o1 = new stzNumber(12500)
KeepHistory()

o1.Add(500)
o1.Retrieve(1500)
o1.DivideBy(500)
o1.MultiplyBy(2)

? @@( o1.History() )
#--> [ 12500, 13000, 11500, 23, 46 ]
KeepHistoryOFF()

Trois formes, une réponse. Une quatrième est la phrase presque naturelle, Naturally("..."), que le chapitre 13 fait tourner sur du texte ; sur un nombre elle répond Unsupported object type à ce commit, et c'est son étape suivante.

Un mot sur @@(). Sur l'ancien langage hôte, ? imprime une liste un élément par ligne ; @@() demande sa forme expressive, [ 12500, 13000, 11500, 23, 46 ], celle qu'une personne écrit. J'ai demandé que Haro imprime cette forme par défaut ; alors @@() quittera les exemples.

Remarquez la ligne sous chaque question. Ce n'est pas un commentaire. C'est une promesse, ce que la ligne doit imprimer. Dans cette maison, elle est la forme d'un exemple depuis le premier jour : une courte histoire, quelques questions, et les réponses écrites dessous. C'est la première moitié de la loi, rendue visible : le code suit l'ordre de la pensée, et chaque étape dit ce qu'elle attend.

Maintenant la seconde moitié. Une règle qu'une personne doit retenir est du folklore. La bibliothèque transforme ses règles de maison en validateurs, pour qu'une personne ou un agent d'IA puisse vérifier une classe avant qu'elle n'atterrisse. Les règles sont quatorze, et la section 5 les compte ; cinq d'entre elles lisent le graphe du code, la structure que la bibliothèque construit à partir du texte d'une classe. Ici une classe enfreint la convention de la maison selon laquelle un verbe finissant en Q rend l'objet. Cette règle a besoin des instructions de retour, que le graphe ne modélise pas, et elle s'exécute donc comme un passage sur le texte. Que dit le tribunal de la classe ? Exécutez :

cCode = "class Basket" + nl + "def Add(x)" + nl + "	return x" + nl + "def AddQ(x)" + nl + "	return 42" + nl
? StzCodeIsClean(cCode)
#--> FALSE
? StzCheckCode(cCode)[1][:rule]
#--> q-returns-object

Le tribunal répond FALSE, et nomme la règle : q-returns-object. Il n'a pas demandé qui avait écrit la classe ! C'est toute la seconde moitié. Et la promesse sous chaque question est lue elle aussi par une machine : l'exécuteur de la bibliothèque juge une promesse comme une affirmation sur ce que la ligne a imprimé. La plus ancienne forme d'exemple de la maison est aussi sa plus récente forme de test.

Les chapitres de cette partie prouvent la loi, chacun d'un côté. Le chapitre 6 raconte le modèle mental et les quatre métaphores qui remplacent les boucles : marcher, vérifier, produire, exécuter. Le chapitre 7 raconte le style d'écriture comme quatorze règles qui lui sont propres, et non les quatorze règles de la maison du tribunal que vous venez de voir, et les sept buts de conception comme sa moitié architecturale. Le chapitre 8 raconte les formes que peut prendre le nom d'une fonction, la forme profonde parmi elles, et la portée nommée dans le verbe. Le chapitre 9 raconte les motifs de pensée : la machine qui réagit à ce qu'elle reconnaît, la programmation réactive en mots simples, et la ligne de temps et la grille. Le chapitre 10 raconte comment la programmation devient raffinement.

5. Le tribunal

coderule_narrated prouve qu'une règle de la maison est une règle sur le graphe du code et que les constats sortent sur du code planté. Elle prouve que le code propre passe, et que les règles de la maison de la bibliothèque sont quatorze. testoor_promises_narrated prouve que la promesse est jugée par une machine dans la forme propre à la maison. Chaque règle est plantée dans les deux sens : le mensonge qu'elle doit attraper, et la vérité qu'elle ne doit pas accuser. 05_containsemptystrings est les étapes du modèle mental sur la même liste, un bloc classique gardé comme une garde. 466_keeping_the_history_of_updates_of_a_softanza_objec prouve l'historique d'une chaîne.

La section 6 met le tribunal à côté du terrain.

6. Le terrain, et où il mène

Le terrain mène sur l'application des règles. La plupart des langages courants ont un formateur et un linter, et la plupart des projets les exécutent avant un commit ou en intégration continue ; c'est une connaissance générale, non une étude du dossier. Le tribunal qui jugerait le style d'un programme écrit avec Softanza est une spécification ; celui qui existe juge les propres classes de la bibliothèque.

Le terrain mène en portée et en gens. Il y a un marché du travail pour ses outils et aucun encore pour celui-ci, et les générateurs du terrain sont les plus grands qui existent.

Le terrain mène aussi, aujourd'hui, sur les propres pages de Softanza. L'étude qui a mesuré le dossier a trouvé que les blocs de code du site ne portent ni paramètre nommé ni scène : un dialecte réduit de la bibliothèque, montré à chaque visiteur. Un agent d'IA qui apprendrait du site apprendrait ce dialecte. Je n'ai pas mesuré de nouveau les blocs du site. Un style qui n'est pas montré n'est pas appris.

Là où je pense que Softanza se distingue, c'est dans ce à quoi le style est lié. Un formateur juge la forme d'une ligne ; une interface fluide rend une ligne agréable. Ici la ligne est liée à une étape de pensée, et la forme du verbe est un contrat sur l'objet. La promesse sous la ligne est l'exemple, le test et la documentation à la fois.

7. La limite

• construitles formes du vocabulaire dans des milliers de noms de méthodes ; les règles de la maison comme un tribunal sur le propre code de la bibliothèque ; la promesse lue par une machine dans la forme propre à la maison
• conçuun tribunal du style pour le code qu'un programmeur ou un agent d'IA écrit ; la grammaire d'écriture déclarée en Haro, pour qu'un modèle d'IA ne puisse écrire que dans elle
• absenttoute machine qui juge aujourd'hui le style d'un programme écrit avec la bibliothèque

Ce qui est construit : les formes du vocabulaire, dans des milliers de noms de méthodes ; les règles de la maison comme un tribunal sur le propre code de la bibliothèque ; la promesse jugée par une machine.

Ce qui est conçu : un tribunal du style pour le code qu'un programmeur ou un agent d'IA écrit avec la bibliothèque. Il lirait un argument positionnel là où un argument nommé existe, une question sans promesse, une chaîne sur une ligne au-delà de deux étapes. Et la grammaire d'écriture déclarée en Haro, pour que la sortie d'un modèle d'IA y soit tenue avant d'être écrite.

Ce qui est absent : toute machine qui juge, aujourd'hui, le style d'un programme écrit avec la bibliothèque. La chaîne de la diapositive fondatrice ne s'exécute pas telle qu'écrite. Dans ce livre, la discipline porte le nom de sa devise : ce que vous pensez est ce que vous écrivez.

8. Six portes

9. Exercice

Prenez la liste [ "tea", "", "rice", "", "fish", "" ]. Écrivez dans l'ordre les questions du modèle mental, une ligne chacune : contient-elle des chaînes vides, combien, où. Puis un acte, avec un paramètre nommé. Sous chaque question, écrivez la ligne qu'elle doit imprimer, avant d'exécuter quoi que ce soit.

Exécutez. Puis demandez à un agent d'IA de résoudre le même problème, et jugez sa réponse avec deux questions seulement : chaque ligne suit-elle une étape de pensée, et chaque question porte-t-elle sa promesse.

Je vous laisse celui-ci, exprès. La classe Basket de la section 3 échoue devant le tribunal parce que AddQ renvoie 42. Changez cette seule valeur en This et exécutez de nouveau la question :

cCode = "class Basket" + nl + "def Add(x)" + nl + "	return x" + nl + "def AddQ(x)" + nl + "	return This" + nl
? StzCodeIsClean(cCode)

Ne vous arrêtez pas à la réponse du tribunal. Demandez-vous si la classe, telle qu'elle est, suit la façon dont une personne pense, et ce que le tribunal a lu pour vous répondre. Je ne vous donne pas le verdict : la section 6 dit quel tribunal existe, et la section 7 dit ce qu'il ne lit pas. Quand vous aurez tranché, vous saurez pourquoi un tribunal qui laisse passer une classe n'a pas encore jugé le style d'un programme écrit avec la bibliothèque.

Le chapitre suivant est le modèle mental, et les métaphores. Là où vous écririez une boucle, il vous demande de nommer plutôt le mouvement que vous faites : marcher, vérifier, produire ou exécuter.

Le modèle mental, et les métaphores

Exécuté le 2026-10-15 12:58 UTC+01:00 dans la bibliothèque au commit 93d7a39bd : 7 bloc(s) sur 7 ont tenu leur promesse.

Les blocs ont été exécutés par le runtime de l'ancien langage hôte, version 1.27 ; Haro n'exécute pas encore la bibliothèque. Les binaires du moteur ont été construits dans une copie de ce commit, le plus récent le 2026-10-05 20:27 UTC+01:00 ; 1 changement(s) du moteur commité(s) après cette construction n'y sont pas.

Dans ce chapitre, je prends les sept étapes du modèle mental, dont le chapitre 5 a exécuté les quatre du milieu sur une liste, et je les exécute sur une chaîne, dans le même ordre. Puis j'en viens à la boucle, l'endroit où les étapes se répètent, et aux quatre métaphores que la bibliothèque vous donne à la place : le marcheur, le vérificateur, le producteur et l'exécutant. Je montre la condition que les quatre portent à l'intérieur d'un argument, la condition W que le moteur lit comme des données, et son jumeau WF, qui exécute du code hôte. Je dis pourquoi j'ai fait des métaphores un but de conception, pourquoi j'ai remplacé eval par un langage que le moteur possède, et où le code des articles sur lesquels ce chapitre repose n'est pas encore exécutable à ce commit. Le principe sous tout cela est celui du chapitre : quand vous écririez une boucle, nommez le mouvement que vous faites, marcher, vérifier, produire ou exécuter.

1. Le concept, tel que le terrain le tient

Le terrain a un seul outil pour répéter une chose, la boucle, et une famille de cousins qui la cachent : l'itérateur, la compréhension, le flux avec son map, filter et reduce, la lambda qui porte une condition. Ce sont de bons outils, et ils partagent tous une habitude. Ils sont écrits dans le langage du mouvement de la machine : un index qui commence à zéro, un compteur qu'on incrémente, une variable qui accumule. Une personne qui lit la boucle doit retrouver la question qu'elle pose.

Le terrain a aussi un vocabulaire de métaphores pour la programmation, mais il les garde dans la documentation. Le code reste une boucle.

2. Le premier principe

Dites le problème en mots simples, posez les mêmes questions dans le même ordre à n'importe quel objet, et quand vous écririez une boucle, nommez le mouvement que vous faites : marcher, vérifier, produire ou exécuter. La page Craft du site le dit, telle que je l'ai lue le 9 octobre 2026 : « Une boucle cache quel mouvement elle fait. Softanza nomme les quatre mouvements, et une tâche est décomposée en eux à la place. » Cette phrase est celle du site, non la mienne ; la phrase ci-dessus est le principe de ce chapitre.

3. La forme Softanza

Le modèle mental compte sept étapes, et ce sont celles dans l'ordre desquelles une personne demande. Définir le problème en termes naturels et en prendre les mots-clés. Choisir l'objet qui tient les données. Demander s'il contient ce qui vous importe. Demander combien. Demander où. Agir sur ces positions, ou appeler le verbe qui le fait. Et la septième : célébrer, et recommencer. Au chapitre 5, vous avez exécuté ces étapes sur une liste de chaînes vides. Elles n'appartiennent pas à la liste. Tiennent-elles sur une chaîne ? Les voici, dans le même ordre :

Q("You and you") {
	? ContainsCS("YOU", FALSE)
	#--> TRUE
	? NumberOfOccurrenceCS("YOU", FALSE)
	#--> 2
	? FindNthCS(2, "YOU", FALSE)
	#--> 9
	ReplaceSection(9, 11, :With = "Me")
	? Content()
	#--> You and Me
}

Contenir imprime TRUE, compter imprime 2, trouver imprime 9, et agir laisse You and Me, avec le même suffixe qui dit si la casse compte. Les trois questions que vous posez à une chaîne sont les trois que vous avez posées à une liste.

Quand les étapes se répètent, la boucle apparaît, et c'est là que la bibliothèque vous donne quatre métaphores à la place. Chacune nomme un mouvement.

Le Marcheur se déplace le long d'une route. Un marcheur est une carte de tout son voyage, construite à sa création. Il garde les positions qu'il visitera, les positions qu'il sautera, où il se tient et ce qui reste. Que sait-il avant de faire un pas ? Demandez-le-lui :

Wk(1, 10, 2) {
	? @@( Walkables() )
	#--> [ 1, 3, 5, 7, 9 ]
	? @@( Unwalkables() )
	#--> [ 2, 4, 6, 8, 10 ]
	? @@( Walk() )
	#--> [ 1, 3 ]
	? CurrentPosition()
	#--> 3
	? @@( RemainingWalkables() )
	#--> [ 5, 7, 9 ]
}

Walk() est un pas, et il imprime le chemin du mouvement, de là où il se tenait à là où il a atterri : [ 1, 3 ]. Une boucle ne garde pas son itinéraire comme une valeur qu'on peut interroger. Un marcheur le fait, avant de bouger. Que fait-il au bord de la route ? Au-delà de la fin, quand la marche est en cours, il s'arrête en silence. Avant le début, il refuse :

oWalker = Wk(1, 10, 3)
? @@( oWalker.WalkNSteps(10) )
#--> [ 1, 4, 7, 10 ]
? @@( oWalker.Walk() )
#--> [ 10 ]
oWalker = Wk(1, 10, 3)
try
	oWalker.WalkBackward()
catch
	? cCatchError
done
#--> Can't walk backward! Already at the beginning of walkable positions.

Demandez dix pas à une marche qui en compte quatre et vous obtenez les quatre : [ 1, 4, 7, 10 ]. Marchez encore et il imprime [ 10 ], la position où il se tient, sans erreur. Demandez-lui de marcher en arrière depuis le début et il refuse ! Ses propres mots : Can't walk backward! Already at the beginning of walkable positions. L'article soutient que cela reflète notre façon de marcher dans le monde physique. On s'arrête quand on heurte un mur derrière soi, et c'est une erreur. Quand la route devant finit, on s'arrête en silence.

Le Vérificateur demande oui ou non. Tous, n'importe lequel, ou où, avec la condition écrite comme une chaîne, la condition W, W pour where :

Q([ "A", 5, "B", "C" ]) {
	? CheckW('{ isString(@item) and IsUppercase(@item) }')
	#--> FALSE
	? ContainsW('{ isNumber(@item) }')
	#--> TRUE
	? @@( FindW('{ isNumber(@item) }') )
	#--> [ 2 ]
}

Un élément échoue au test, donc CheckW imprime FALSE ; un nombre est dans la liste, donc ContainsW imprime TRUE ; et FindW dit où, [ 2 ].

Le Producteur produit des données neuves à partir des anciennes, et laisse les anciennes tranquilles. L'Exécutant est son pendant : il change les éléments là où la condition tient. Lequel des deux touche la liste ? Mettez-les côte à côte sur la même liste et regardez :

o1 = new stzYielder([ 1, -2, 3, -4, 5 ])
o1 {
	? @@( Filter(:IsPositive) )
	#--> [ 1, 3, 5 ]
	? @@( Map(:Abs) )
	#--> [ 1, 2, 3, 4, 5 ]
	? Reduce(:Sum)
	#--> 3
}
Q([ 1, "haro", 3, "python", 5, "ruby" ]) {
	? @@( YieldW('isString(@item)', 'upper(@item)') )
	#--> [ "HARO", "PYTHON", "RUBY" ]
	? @@( Content() )
	#--> [ 1, "haro", 3, "python", 5, "ruby" ]
	PerformW('isString(@item)', 'upper(@item)')
	? @@( Content() )
	#--> [ 1, "HARO", 3, "PYTHON", 5, "RUBY" ]
}

Regardez les deux sorties de Content(), avant et après l'appel à PerformW. Le producteur a rendu [ "HARO", "PYTHON", "RUBY" ]. La liste n'a pas été touchée ! L'exécutant a changé la liste : [ 1, "HARO", 3, "PYTHON", 5, "RUBY" ]. Le verbe vous dit lequel, si bien qu'une conception peut dire « cette étape ne fait que lire » et le penser.

Maintenant ce que les quatre partagent : une condition voyage à l'intérieur d'un argument. C'est une petite chaîne, gardée dans une variable si vous voulez. Elle se place au même endroit pour find, pour items et pour contains. Et elle a un jumeau qui prend une vraie fonction :

cCond = '{ @item > 5 }'
Q([ 3, 8, 5, 12, 1, 9 ]) {
	? @@( FindW(cCond) )
	#--> [ 2, 4, 6 ]
	? @@( ItemsW(cCond) )
	#--> [ 8, 12, 9 ]
	? ContainsW(cCond)
	#--> TRUE
	? @@( FindWF( func x { return x > 5 } ) )
	#--> [ 2, 4, 6 ]
}

Les deux s'accordent : FindW avec la chaîne et FindWF avec la fonction impriment tous deux [ 2, 4, 6 ]. ItemsW rend les éléments eux-mêmes, [ 8, 12, 9 ].

La forme en chaîne est la condition W ; la forme en fonction est WF. Elles se ressemblent, et la différence compte. Le moteur lit une condition W comme des données, dans un petit langage à lui : des littéraux, @item, l'arithmétique, les comparaisons, et une courte liste de fonctions. Il ne peut pas appeler votre code. Alors que devient une condition qui essaie ? Elle n'est pas exécutée :

o1 = new stzList([ 3, 8, 5, 12, 1, 9 ])
? @@( o1.FindW('{ @item > 5 and print("hacked") }') )
#--> [ ]
? @@( W('{ @item > 5 }') )
#--> [ "where", "{ @item > 5 }" ]

Rien n'a été imprimé ! Les positions sont revenues vides, [ ], et W() montre la condition pour ce qu'elle est, des données : [ "where", "{ @item > 5 }" ]. Une condition W peut être stockée, montrée à une personne et approuvée avant de s'exécuter, parce qu'elle ne peut pas s'échapper. Le jumeau WF exécute du code hôte, et la table propre de la bibliothèque dit qu'il n'est pas sûr avec une entrée à laquelle vous ne faites pas confiance.

Le code de l'article « Bridging Minds and Code » ne s'exécute pas à ce commit, comme le dit la section 7.

Les trois modèles de cet article, le sémantique, le mental et celui de l'expression, sont une seule idée en trois endroits. Le modèle sémantique est le monde du programme comme connaissance : une pomme est un fruit. Le modèle mental est ce que vous venez de faire : créer un objet, y stocker des données, y trouver des choses, agir sur les positions. Le modèle d'expression est le code qui le dit : choisir l'objet, taper le nom de l'action, continuer le flux d'actions, convertir le résultat en un autre objet. Continuer ainsi jusqu'à la réponse finale. Alors je les raconte en mots.

La section suivante donne la décision, et ce que j'ai refusé.

5. Le tribunal

Les quatre métaphores n'ont pas de garde unique. Le producteur en a une narrée, 00_yielder_narrated : quatre opérations map, trois opérations filter et une somme. Le marcheur a 597_walker_basics, des marcheurs nommés et ce qu'ils ont parcouru, et 495_walking_until_and_until_before, une marche qui s'arrête sur une condition, y compris l'élément qui l'arrête, ou non ; toutes deux testent les marcheurs nommés et les marches de la liste, par StzListQ, non le marcheur Wk des blocs ci-dessus. Le vérificateur a 611_checkw, qui dit qu'une vérification est fausse quand un seul élément échoue. L'exécutant a 621_perform, qui dit qu'il change la liste en place. 483_w_and_wf_forms_in_conditional_code prouve qu'une condition W écrite avec des mots de curseur comme @NextNumber et la même écrite avec de l'arithmétique d'index brute comme This[@i+1] donnent les mêmes positions.

Aucune des gardes nommées ici ne couvre Walkables, WalkNSteps ni WalkBackward ; ces lignes reposent sur les exécutions gardées pour ce chapitre.

Ensuite, ce que le terrain fait mieux que le marcheur.

6. Le terrain, et où il mène

Le terrain mène en paresse. Un générateur produit l'élément suivant à la demande et peut être sans fin. Le marcheur construit une carte de tout son voyage à l'instant où il est fait. C'est un gain pour la prévoyance : vous pouvez demander quelles positions il sautera avant qu'il bouge. C'est une perte pour un grand parcours, ou un parcours sans fin.

Le terrain mène en ouverture. Une lambda porte n'importe quelle logique. Le langage W est borné exprès, et le prix de la borne est le second chemin, WF, qui a toute la puissance de l'hôte et il est fait pour une entrée à laquelle on fait confiance. Il y a aussi un coût plus discret que j'ai mesuré une fois, sur un cas : une condition qui appelle quelque chose que le langage ne connaît pas donne une liste vide et aucune erreur.

Le terrain mène en portée et en outillage. Les itérateurs et les compréhensions sont dans tous les langages courants, avec le soutien des éditeurs, la vérification des types et une littérature. Ces quatre métaphores existent dans une seule bibliothèque.

Et je n'imprimerai pas la comparaison que fait la bibliothèque elle-même des marcheurs avec les boucles et les itérateurs. Sa table a treize lignes, toutes en faveur du marcheur, aucune exécutée. Une table vaut d'être imprimée quand ses lignes ont été exécutées et qu'une perte figure à côté des gains ; pour celle-ci, c'est l'étape suivante.

Ensuite, la limite, dans les mots d'étape construit, conçu et absent.

7. La limite

• construitle marcheur à une dimension, le vérificateur, le producteur et l'exécutant sur les listes ; le langage de condition compilé par le moteur, avec son jumeau en code hôte
• conçules quatre métaphores comme modules natifs du moteur (seul le producteur en est un) ; un marcheur sur toute structure indexée
• absentdu code exécutable pour les trois modèles de l'article « Bridging Minds and Code » ; la table des bords de la narration du marcheur telle qu'écrite

Ce qui est construit : le marcheur à une dimension, dans la couche max, et les marches sur les listes ; le vérificateur comme CheckW, ContainsW et FindW ; le producteur comme une classe adossée au moteur, et comme YieldW ; l'exécutant comme PerformW ; et le langage de condition W compilé par le moteur.

Ce qui est conçu : les métaphores comme modules natifs du moteur. La conception du moteur marque les quatre comme prévus ; seul le producteur a un fichier de moteur. Et un marcheur qui ne porte plus du tout sur les listes mais sur toute structure indexée.

Six choses sont absentes, ou restent à aligner sur leurs articles, à ce commit, d'après mes exécutions.

• La table de l'article sur la marche au bord et la bibliothèque diffèrent dans deux cas ; les aligner est l'étape suivante. Un pas unique plus grand que l'intervalle lève une erreur là où la table promet le silence, et un chemin de directions mêlées lève une erreur là où elle promet l'acceptation. Les deux principes tiennent dans les cas montrés plus haut. Le livre énonce le principe et n'imprime que les cas qui s'exécutent ; la table n'est pas imprimée.
• Le code de l'article « Beyond Loops » diffère par endroits. L'historique d'un marcheur est une liste de marches ; une marche en arrière ne prend plus d'argument ; la direction s'imprime « backward » là où l'article dit « reverse ». L'exécution de l'article par le site a gardé dix blocs sur dix-huit.
• Les trois modèles de « Bridging Minds and Code » : aucun de ses codes ne s'exécute tel qu'écrit ; dans l'exécution du site, douze blocs ont levé une erreur et un a différé. Alors je les ai racontés en mots.
• Le getter EmptyStrings() de l'article du modèle mental est absent.
• Sur la classe dédiée du vérificateur, ContainsW est en développement : il lève une erreur aujourd'hui. La marche en arrière avec condition du marcheur de chaînes est absente.
• Et « pas d'eval » est encore en route vers le reste. Le résolveur quasi naturel, l'autre direction du chapitre 13, évalue encore du code hôte. Il en va de même de StringsW et de ItemsWhere sur la liste, et de ContainsW sur la classe dédiée du vérificateur : chacun appelle encore eval sur une chaîne de condition. Ce que j'ai dit plus haut, que le moteur lit une condition W et ne peut pas l'exécuter comme du code, vaut pour le chemin du moteur ; pour ces trois, c'est l'étape suivante.

Viennent ensuite les six portes, du programmeur à l'agent.

8. Six portes

9. Exercice

Prenez la liste [ 4, 9, 12, 7, 20, 3 ]. Quatre phrases sont données. Une : sont-ils tous au-dessus de 2 ? Deux : donnez-moi, comme une nouvelle liste, ceux au-dessus de 8, doublés. Trois : rendez négatifs ceux au-dessus de 8, dans la liste elle-même. Quatre : quelles positions sont 2, 4 et 6 ?

Pour chacune, dites d'abord quel mouvement c'est, marcher, vérifier, produire ou exécuter, et écrivez sous la ligne que vous allez écrire ce que vous attendez qu'elle imprime. Puis écrivez la ligne, avec la condition comme une chaîne partout où il y a une condition, et exécutez-la. Après la deuxième et la troisième, imprimez de nouveau la liste. Dites, avant de regarder, dans laquelle des deux la liste a changé.

Je vous laisse celui-ci, exprès. Voici le bloc de la section 3 avec un seul changement : la liste est celle de l'exercice, et je n'imprime rien dessous.

o1 = new stzList([ 4, 9, 12, 7, 20, 3 ])
? @@( o1.FindW('{ @item > 5 and print("hacked") }') )

Exécutez-le. La condition commence par demander si un élément est au-dessus de 5. Regardez ce qui revient, et ce qui ne revient pas, et dites pourquoi avant de retourner aux sections. La section 3 dit ce que le moteur fait d'une condition qui appelle du code ; la section 6 dit ce que cela coûte, et la section 8 dit ce qu'un agent d'IA doit en faire. Quand vous l'aurez résolu, vous saurez pourquoi une réponse vide n'est pas encore la preuve que rien n'a correspondu.

Le chapitre suivant passe au style d'écriture, et aux sept buts. Son principe tient en une phrase : ce que vous pensez est ce que vous écrivez.

Le style d'écriture, et les sept buts

Exécuté le 2026-10-15 12:58 UTC+01:00 dans la bibliothèque au commit 93d7a39bd : 9 bloc(s) sur 9 ont tenu leur promesse.

Les blocs ont été exécutés par le runtime de l'ancien langage hôte, version 1.27 ; Haro n'exécute pas encore la bibliothèque. Les binaires du moteur ont été construits dans une copie de ce commit, le plus récent le 2026-10-05 20:27 UTC+01:00 ; 1 changement(s) du moteur commité(s) après cette construction n'y sont pas.

Dans ce chapitre, je prends le reste du style d'écriture, comme une grammaire de quatorze règles. J'imprime l'état où chaque règle se trouve au commit sur lequel ce livre s'exécute, un bloc là où elle s'exécute et une limite là où elle ne s'exécute pas. Sous la grammaire je mets les sept buts, j'en montre trois dans des blocs et je laisse à l'étude les quatre que je n'ai pas exécutés. J'imprime le tribunal de la maison, les quatorze règles que la bibliothèque tient sur son propre code. Je dis ce qu'il ne lit pas : le code d'un programme écrit avec la bibliothèque. Le principe est celui du chapitre 5, et je ne l'argumente pas de nouveau : ce que vous pensez est ce que vous écrivez.

1. Le concept, tel que le terrain le tient

Le mot style veut dire deux choses dans le terrain, et je dois dire laquelle j'entends.

Le premier est le style comme mise en page, imposé par un outil. Le guide de style de Python date de 2001, le formateur de Go de 2009, et tout projet exécute un linter avant un commit. Ils jugent la forme d'une ligne : espaces, majuscules, longueur, noms inutilisés. Ils y sont bons, et ils tournent par défaut. Ils ne disent rien de savoir si une ligne suit l'ordre dans lequel son auteur raisonnait.

Le second est le petit langage à l'intérieur du langage. Les programmeurs écrivent déjà de petits langages dans des chaînes, et personne n'appelle cela un style : une expression régulière, un texte SQL, une chaîne de format telle que "%5.2f". Chacun est une notation séparée, avec son propre outil, apprise à part.

Pour les buts, le terrain dit attributs de qualité. La norme ISO de qualité logicielle, de 2011, en liste huit, et les méthodes d'architecture les classent avant qu'un système soit dessiné ; c'est une connaissance générale, non une étude du dossier. Les sept buts de ce chapitre sont une autre liste, choisie pour un autre usage. Ils ne disent pas ce qu'un produit promet à ses utilisateurs. Ils disent ce qu'une fonctionnalité doit servir pour être admise dans une seule bibliothèque.

2. Le premier principe

Ce que vous pensez est ce que vous écrivez. C'est la phrase du chapitre 5, tirée du schéma de 2020, et je ne l'argumente pas de nouveau. Le chapitre 5 a pris cinq règles du style. Ce chapitre prend le reste, comme une grammaire, puis les buts sous lesquels la grammaire a été conçue.

Pour les buts, le point est le mien, et non une citation datée. Une architecture logicielle orientée par les buts est la seule façon pour un architecte de maîtriser un projet de cette taille. Je tiens cela pour une vue, non pour un résultat. Ce qui la soutient sur cette page est un seul cas : la matrice de 2022 a servi de squelette à un architecte pour environ trois cent mille lignes écrites à la main (section 6).

3. La forme Softanza

Mon étude du dossier a écrit le style en quatorze règles, à partir de la lecture du code. Ce sont des lectures du code, énoncées comme des règles, et non une norme que quelqu'un a signée. Les voici avec l'état où chacune se trouve au commit sur lequel ce livre s'exécute. Je mets la table d'abord parce qu'elle montre quelles règles portent un bloc et lesquelles portent une limite.

La règle 11 d'abord, parce que c'est la plus étrange. Le langage hôte compte en entiers et coupe les décimales. Que garde un intervalle écrit à l'intérieur d'une chaîne ? Les commentaires ci-dessous parlent avant le code, dans la voix du maître, ce qui est la règle 14. Exécutez-le :

# The host's own range counts in integers: the decimals are cut. Softanza reads
# a small language inside a string, and keeps the decimals, the numbered words,
# and the letters of any script:
? @@( 1.02 : 3.08 )
#--> [ 1, 2, 3 ]
? @@( L("1.02:1.05") )
#--> [ 1.02, 1.03, 1.04, 1.05 ]
? @@( L('"♥1" : "♥3"') )
#--> [ "♥1", "♥2", "♥3" ]
? @@( L(' "ا" : "ج" ') )
#--> [ "ا", "ب", "ة", "ت", "ث", "ج" ]

L'hôte répond [ 1, 2, 3 ] à 1.02 : 3.08 et coupe les décimales. La chaîne répond [ 1.02, 1.03, 1.04, 1.05 ], et les deux bornes arabes donnent six lettres ! Softanza lit un petit langage d'intervalles à l'intérieur de la chaîne et garde les décimales, les mots numérotés et les lettres de n'importe quelle écriture. Le langage d'intervalles est un argument comme un autre. Donne-t-il les remplacements pour chaque occurrence, dans l'ordre, et la forme étendue reboucle-t-elle la palette quand les occurrences la dépassent en nombre ?

o1 = new stzString("haro php ruby haro python haro")
o1.ReplaceByMany("haro", L('"♥1" : "♥3"'))
? o1.Content()
#--> ♥1 php ruby ♥2 python ♥3
o2 = new stzString("haro php ruby haro python haro ruby haro")
o2.ReplaceByManyXT("haro", L('"♥1" : "♥3"'))
? o2.Content()
#--> ♥1 php ruby ♥2 python ♥3 ruby ♥1

La forme étendue a rebouclé la palette, et ♥1 est revenu à la fin !

Une liste peut aussi être portée comme une chaîne dans sa forme courte, reconnue, convertie entre les formes et réévaluée :

? StzStringQ('1:3').IsListInString()
#--> TRUE
? @@( StzStringQ('[1,2,3]').ToListInShortForm() )
#--> "1 : 3"
? @@( StzStringQ(' "A":"C" ').ToList() )
#--> [ "A", "B", "C" ]

Règle 10 : le code voyage à l'intérieur d'un argument comme une petite chaîne avec un espace réservé, @char pour les caractères d'une chaîne et @item pour les éléments d'une liste. Le chapitre 6 a montré l'emplacement sur une liste. Ici il est sur une chaîne, où il trouve et retire par une règle et non par une boucle :

Q("SOooooFTAaaannnNZA") {
	? @@( FindW('{ Q(@char).IsUppercase() }') )
	#--> [ 1, 2, 7, 8, 9, 16, 17, 18 ]
	RemoveW('{ Q(@char).IsLowercase() }')
	? Content()
	#--> SOFTANZA
}

Le diaporama de 2022 écrit le même appel avec un emplacement nommé, :Where = '...', et cette forme lève une erreur sur une chaîne à ce commit. Je ne la montre pas. Le même diaporama met un @ à la fin du nom d'un paramètre, :With@, pour marquer que sa valeur est du code à évaluer. Cette forme est retirée. L'en-tête d'une garde le dit : les formes fondées sur eval sont retirées. Le diaporama lui-même marque la forme « TODO ». Le code voyage maintenant dans l'emplacement comme une chaîne bornée que le moteur évalue, ou comme une fonction.

Règle 8 : le même acte peut se dire en deux ordres de mots, avec le nom du conteneur, ou avec le côté épelé de quatre façons, gauche ou début, droite ou fin ; deux des quatre s'exécutent ci-dessous. Chaque paire est un seul acte, avec deux définitions. La propre narration de la bibliothèque appelle la première avec deux arguments et elle lève less number of parameters ; les gardes passent la position de départ, et le bloc aussi :

o1 = new stzList([ 1, 2, "♥", 4, 5, "♥", "♥" ])
? o1.FindNthNext(2, "♥", :StartingAt = 1)
#--> 6
? o1.FindNextNth(2, "♥", :StartingAt = 1)
#--> 6
? Q("---haro").NumberOfOccurrenceOfCharLeftSide("-")
#--> 3
? Q("---haro").HowManyOccurrenceOfCharStartSide("-")
#--> 3
o2 = new stzList([ "C", "B", "A" ])
o2.SwapItems(:AtPositions = 1, :And = 3)
? @@( o2.Content() )
#--> [ "A", "B", "C" ]

Le diaporama promettait davantage. Une famille de cinq noms en CharsRemoved, pour retirer des caractères aux bouts, est nommée dans le diaporama. Deux sont définis, LeadingCharsRemoved et TrailingCharsRemoved. Trois ne le sont pas : LeadingAndTrailingCharsRemoved, TrailingAndLeadingCharsRemoved et RepeatedCharsRemoved. RemoveLeadingAndTrailingChars est défini, et n'est pas l'un des cinq.

Règle 9 : la précision plutôt que la généralité. Le nom précis dit ce qui est compté. Les caractères d'une chaîne sont comptés par NumberOfChars, et Size() est la longueur en octets de l'hôte. Les deux verbes de liste du même bloc montrent la règle sur une liste : le nom précis, ContainsBoth ou ContainsAll, dit ce qui est demandé. Les deux réponses diffèrent-elles sur un mot arabe ? Exécutez-le :

? Q("سلام").NumberOfChars()
#--> 4
? Q("سلام").NumberOfBytes()
#--> 8
? Q("سلام").Size()
#--> 8
o1 = new stzList([ "tea", "rice", "fish", "salt" ])
? o1.ContainsBoth("tea", "fish")
#--> TRUE
? o1.ContainsAll([ "tea", "oil" ])
#--> FALSE

L'exécution répond 4 à l'un et 8 à l'autre. Le mot a quatre lettres ! La propre ligne de documentation de la bibliothèque pour NumberOfChars liste size parmi ses mots alternatifs. L'exécution montre que Size() ne veut pas dire cela. Je le liste parmi les demandes.

Règle 7 : un préfixe viz montre la réponse sous le mot, et le suffixe XT ajoute les positions comme des nombres ; le chapitre 8 exécute le bloc, parmi les formes d'un nom.

La narration et le diaporama écrivent vizFindAll sur une chaîne. Il n'y existe pas à ce commit : mon exécution a répondu Calling Method without definition: vizfindall. vizFind existe. Une liste a son propre VizFindAll.

Les buts

Sous la grammaire il y a sept buts, écrits dans le diaporama de 2022 comme une matrice de trente-trois fonctionnalités, que la section 4 compte. Mon étude les lit comme le squelette architectural de la bibliothèque : une fonctionnalité qui n'en sert aucun est refusée, et un but sans fonctionnalité est un écart. Le résumé de l'étude est la lecture d'une session et non un texte de la bibliothèque, et aucun document de la bibliothèque n'énonce la règle en ces mots. Le plus proche est le document de conception du moteur : le moteur doit permettre les sept.

Je ne listerai pas les sept comme une table de slogans. Voici ce qui s'exécute de trois d'entre eux.

Flexibilité : l'ordre des paramètres nommés est libre. Deux appels, avec les paramètres dans deux ordres, sont-ils le même appel ?

o1 = new stzString("----@@--@@-------@@----@@---")
o1.ReplaceNextNthOccurrence(2, :Of = "@@", :StartingAt = 12, :With = "##")
? o1.Content()
#--> ----@@--@@-------@@----##---
o2 = new stzString("----@@--@@-------@@----@@---")
o2.ReplaceNextNthOccurrence(2, :With = "##", :StartingAt = 12, :Of = "@@")
? o2.Content()
#--> ----@@--@@-------@@----##---

Les deux ordres impriment ----@@--@@-------@@----##--- ! C'est l'ordre libre des paramètres nommés ; l'autre ordre libre du diaporama, un nombre et une chaîne permutés dans leurs positions, est celui du chapitre 8, et il ne s'exécute pas. Une tension doit être dite avec. La conception de Haro refuse les paramètres à ordre libre comme grammaire, et la bibliothèque les garde. Deux faits sont vrais aujourd'hui. Le bloc ci-dessus les exécute, donc ils sont dans la bibliothèque. La grammaire à laquelle une machine est tenue les laisse de côté, par le principe de Haro. Que la bibliothèque les garde au-delà de cette grammaire ou les retire, c'est une décision que le dossier ne tient pas. Je ne la prends pas ici. Ils sont gardés, et ils ne sont pas de la grammaire.

Cohérence : un vocabulaire à travers une chaîne et une liste. Le même verbe répond-il sur les deux ?

? @@( StzStringQ("hello").FindAllCS("L", :CaseSensitive = 0) )
#--> [ 3, 4 ]
? @@( StzListOfStringsQ([ "h", "e", "l", "l", "o" ]).FindAllCS("L", :CaseSensitive = 0) )
#--> [ 3, 4 ]
? Q("").IsEmpty()
#--> TRUE
? Q([]).IsEmpty()
#--> TRUE

La perte à côté, du même groupe de diapositives : le conseil du diaporama d'employer le mot-clé Item avec tout type énumérable ne tient pas. NumberOfItems() sur une chaîne lève une erreur dans mon exécution : Calling Method without definition: numberofitems. Sur une liste il répond.

Maniabilité : un échec qui dit où, quoi, pourquoi, et que faire. La bibliothèque lève une erreur en quatre champs. Je n'imprime pas son message, parce que, dans mon exécution, sa première ligne portait un numéro de ligne de la bibliothèque, et un numéro de ligne n'est pas une promesse.

Les quatre autres buts (l'expressivité, la fiabilité, les métaphores humaines et les abstractions pratiques) je les laisse aux tables de l'étude. Je ne les ai pas exécutés pour ce chapitre, et je ne décrirai pas d'après le diaporama ce que je n'ai pas exécuté.

Vient ensuite la décision, et ce que j'ai refusé.

5. Le tribunal

coderule_narrated prouve qu'une règle de la maison est une règle sur le graphe du code ; que le code planté est trouvé par son nom ; que le code propre passe ; et que la bibliothèque en liste quatorze. testoor_promises_narrated prouve que la promesse #--> est jugée comme l'affirmation d'un arrêt : tenue, divergente, non atteinte ou non jugée. 602_l_function et 59_use_of_the_l_small_function prouvent le langage d'intervalles. 527_identifying_lists_inside_a_string prouve les listes hébergées dans des chaînes. 48_replacebymany prouve que les remplacements se font dans l'ordre. 483_w_and_wf_forms_in_conditional_code prouve la condition dans une chaîne, en deux écritures du même balayage. 28_numberofoccurrenceofcharleftside prouve les noms alternatifs en arabe comme en latin, et porte une note disant que la promesse de l'archive était fausse et que l'implémentation fait autorité. 646_content prouve les paramètres nommés. 972_narration_viz-finding_a_recurring_substring prouve la visite viz.

Voici le tribunal de la maison lui-même, les quatorze règles de la bibliothèque et non les quatorze du style. La coïncidence numérique est une coïncidence. Que répond-il à une faute d'orthographe plantée, et à une écriture plantée sur une constante ? Exécutez-le :

? @@( StzCodeRuleNames() )
#--> [ "no-len-method", "q-returns-object", "no-aggressive-verbs", "engine-first", "q-has-plain-twin", "no-case-collision", "dead-knob", "setter-resets-on-reject", "setter-only-moves-one-way", "misspelled-name", "library-prints", "empty-method-body", "writes-a-mutable-constant", "value-called-as-function" ]
cOne = "class Inbox" + nl + "def Recieve(x)" + nl + "	return x" + nl
? StzCheckCode(cOne)[1][:rule]
#--> misspelled_name
? StzCodeIsClean(cOne)
#--> TRUE
cTwo = "class Inbox" + nl + "def Count()" + nl + "	nl = 3" + nl + "	return nl" + nl
? StzCheckCode(cTwo)[1][:rule]
#--> writes_a_mutable_constant
? StzCodeIsClean(cTwo)
#--> FALSE

La faute d'orthographe est trouvée par son nom, misspelled_name, et le code reste propre, TRUE, parce que c'est un avertissement. L'écriture sur une constante est trouvée par son nom, writes_a_mutable_constant, et le code est refusé, FALSE, parce que c'est une erreur. Le tribunal a refusé l'écriture sur une constante !

Un détail d'orthographe, pour l'annexe B : la liste des noms emploie des traits d'union, et le constat de huit des quatorze revient avec des soulignés. Le bloc le montre : la liste imprime misspelled-name, et le constat imprime misspelled_name.

Ce que le tribunal ne lit pas, c'est le code d'un programme écrit avec la bibliothèque. Les quatorze règles de la maison sont des règles du propre code de la bibliothèque ; une règle d'écriture pour le code écrit avec elle est conçue (section 7).

6. Le terrain, et où il mène

Le terrain mène en application par défaut. Un formateur s'exécute à chaque commit. Pour le code qu'un programmeur écrit avec Softanza, le tribunal qui appliquerait le style est conçu et pas encore construit, et le chapitre 5 le dit.

Le terrain mène en ayant ses buts quelque part où un lecteur regarde d'abord. Les sept buts sont dans un document de conception et dans des balises qu'aucun tribunal ne lit, et les notes de fonctionnement du dépôt propre de la bibliothèque n'en nomment aucun. Le récit d'un lecteur IA de la bibliothèque dit que soixante documents de paradigme pourraient aisément être soixante idées déconnectées. L'étude y lit un signe que la discipline est dans le code et écrite nulle part où un lecteur regarderait d'abord. C'est un document de session, et non un témoin indépendant.

Le site a montré un jour un dialecte réduit : ses blocs n'avaient ni paramètre nommé ni scène. Il a depuis mis les quatorze règles sur sa page Craft et les règles comme données. Je n'ai pas remesuré les blocs du site après cela.

Là où je pense que le style se distingue, c'est que chaque règle sert une étape de pensée, et que chaque étape a une forme écrite. La forme du verbe est un contrat sur l'objet. Et la promesse sous la ligne est l'exemple, le test et la documentation à la fois. La matrice de 2022 a servi de squelette à un architecte pour environ trois cent mille lignes écrites à la main, selon le compte de mon étude.

La limite, à la section suivante, dit ce qui est construit, ce qui est conçu et ce qui est absent.

7. La limite

• construitles quatorze règles de la maison de la bibliothèque comme un tribunal sur son propre code ; la promesse jugée comme une affirmation ; les petits langages des intervalles, des listes et des conditions dans des chaînes ; l'emplacement du code ; le préfixe viz ; les alternatives et les paramètres nommés dans n'importe quel ordre, en partie
• conçuun tribunal qui juge le style d'un programme écrit avec la bibliothèque ; un tribunal qui lit les buts ; la grammaire d'écriture déclarée en Haro ; la forme classique d'un bloc de test comme forme unique
• absenttoute machine qui juge le style du code que vous écrivez aujourd'hui ; l'écriture dans n'importe quelle langue humaine du nom d'une fonction ; la phrase quasi naturelle telle que le diaporama l'écrivait ; le code fondé sur eval sur le nom d'un paramètre

Ce qui est construit : les quatorze règles de la maison de la bibliothèque comme un tribunal sur son propre code, exécutées dans le bloc ci-dessus. Aussi construits : la promesse jugée par une machine ; les petits langages, l'emplacement, le préfixe. Et les fonctionnalités qui s'exécutent (CS, XT et viz, les paramètres nommés, le même verbe sur une chaîne et une liste ; ZZ s'exécute au chapitre 8).

Ce qui est conçu :

• Un tribunal qui juge le style d'un programme écrit avec la bibliothèque. C'est une spécification dans l'étude : les quatorze règles comme règles de la maison sur le graphe d'un extrait. Ses exemples sont un argument positionnel là où un argument nommé existe, ou une ligne imprimée sans promesse. Je l'ai cherché dans la bibliothèque : il n'est pas encore construit, c'est l'étape suivante.
• Un tribunal qui lit les buts. Il lirait les balises. À venir.
• La forme classique du bloc de test comme forme unique des nouveaux blocs. Le jugement de l'étude est que le retour « n'est pas une réécriture » mais une décision. La forme classique est la forme unique des nouveaux blocs, et les blocs convertis restent tels qu'ils sont. Le README de l'arbre de tests dit encore de la forme classique qu'elle est la surface de test faisant autorité. Je n'ai trouvé aucune décision qui en fasse la forme unique : cela reste une décision, et le chapitre 5 la nomme.
• La grammaire d'écriture déclarée en Haro. La moitié vocabulaire existe : les formes des noms de la bibliothèque sont des données en Haro, et le relevé de la session est de 584 orthographes livrées sur 595 qui concordent. La moitié usage, la scène, la chaîne, l'emplacement du code et la promesse, n'est pas déclarée.
• La discipline déclarée une fois. En partie faite sur le site, comme données, ce qui est la source de la page et non un tribunal.

Ce qui est absent :

• Toute machine qui juge, aujourd'hui, le style d'un programme écrit avec la bibliothèque ; à côté, le tribunal de la maison juge le propre code de la bibliothèque.
• Les règles 12 et 13 comme formes qui s'exécutent. Dans mes exécutions, les exemples quasi naturels du diaporama ne s'exécutaient pas tels qu'écrits, ni une fonction nommée en chinois ou en français.
• Le @ sur le nom d'un paramètre comme forme qui fonctionne.
• La forme à accolades du langage d'intervalles, L('{ "♥1" : "♥6" }'), qui lève une erreur, et les intervalles qui changent de largeur, comme day8 : day11, qui lèvent aussi une erreur, avec une erreur de variable non initialisée de l'hôte. Le constructeur de liste à partir d'une chaîne en lève une aussi. Ces trois constats viennent de mes exécutions ; aucun bloc de ce chapitre ne les garde.
• La pile d'appels visualisée, et les décorateurs de cache et de journal, qui existent comme noms dans des commentaires.

8. Six portes

9. Exercice

Écrivez, avant d'exécuter quoi que ce soit, la ligne dont chaque tâche a besoin et la promesse dessous :

1. À partir d'une chaîne, la liste [ "♥7", "♥8", "♥9" ].
2. La chaîne "haro php haro" avec les deux haro numérotés ♥1 et ♥2, en un seul appel qui emploie le petit langage de la tâche 1.
3. La liste [ "C", "B", "A" ] ordonnée en échangeant les premier et troisième éléments, avec les positions nommées.
4. Le nombre de caractères de "سلام", avec le nom qui dit ce qui est compté.
5. Une supposition : qu'imprime L("day8 : day11") ?

# 1.
# 2.
# 3.
# 4.
# 5.

Exécutez-le. Pour la cinquième, vous aviez le droit de vous tromper, et vous vous êtes probablement trompé : l'intervalle change de largeur, alors L confie son texte à l'hôte pour l'évaluer, l'hôte lit day8 comme une variable, et il lève une erreur, Using uninitialized variable: day8. C'est la limite du petit langage, apprise en étant surpris une fois. Ne changez pas votre promesse pour qu'elle corresponde à la sortie. Expliquez d'abord la sortie.

Je vous laisse celui-ci. Le premier appel du bloc de la règle 8, son départ nommé retiré, a deux arguments. Rien d'autre ne change :

o1 = new stzList([ 1, 2, "♥", 4, 5, "♥", "♥" ])
? o1.FindNthNext(2, "♥")

Exécutez celui-ci et lisez ce qui revient. Puis réparez l'appel. La section 3 dit d'où vient cette forme d'appel et ce que font les gardes à la place. Quand il sera réparé, vous saurez pourquoi un appel que la narration même de la bibliothèque écrit lève une erreur, et ce que les gardes passent qu'il ne passe pas.

Le chapitre 8 prend le nom d'une fonction en entier, comme une expression linguistique, puis la portée : ce nom est une phrase, et ses préfixes, ses suffixes et ses paramètres sont une grammaire que la bibliothèque peut lire.

Les fonctions comme expressions linguistiques, et la portée

Exécuté le 2026-10-15 12:58 UTC+01:00 dans la bibliothèque au commit 93d7a39bd : 13 bloc(s) sur 13 ont tenu leur promesse.

Les blocs ont été exécutés par le runtime de l'ancien langage hôte, version 1.27 ; Haro n'exécute pas encore la bibliothèque. Les binaires du moteur ont été construits dans une copie de ce commit, le plus récent le 2026-10-05 20:27 UTC+01:00 ; 1 changement(s) du moteur commité(s) après cette construction n'y sont pas.

Dans ce chapitre, je lis le nom d'une fonction comme la bibliothèque le lit : une phrase dont les préfixes, les suffixes et les paramètres sont une grammaire. Je parcours les formes d'un nom qui tournent, et je compte les cinq qui ne tournent pas. Puis je passe à la portée : le même verbe, trois verdicts, avec le cadre dans le verbe et non dans un drapeau posé plus tôt. Je dis ce que la conception de Haro garde des formes, ce qu'elle refuse, et ce que le tribunal prouve. Le principe est celui-ci : le nom d'une fonction est une phrase, et ses préfixes, ses suffixes et ses paramètres sont une grammaire que la bibliothèque peut lire.

1. Le concept, tel que le terrain le tient

Sur le terrain, le nom d'une fonction est une étiquette. Il suit une convention, camel case ou snake case, et il vous dit à peu près ce que fait la fonction ; les détails sont dans la signature et la documentation. Un nom ne porte pas de grammaire. Les outils voisins ne parlent que de structure. Python et Swift offrent l'argument nommé, pour qu'un appel puisse dire quel paramètre est lequel. L'interface fluide enchaîne les appels pour qu'une ligne se lise comme une phrase, et la surcharge donne à un seul nom plusieurs signatures.

Et quand le terrain veut qu'une fonction se comporte autrement dans un autre contexte, il change son sens par un drapeau posé ailleurs. Le drapeau est un mode, une locale, une variable d'environnement. Le nom de la fonction ne vous dit pas dans quel cadre elle va s'exécuter.

2. Le premier principe

Le nom d'une fonction est une phrase, et ses préfixes, ses suffixes et ses paramètres sont une grammaire que la bibliothèque peut lire. L'article qui a le premier avancé cette thèse dit, dans les mots que cite l'étude de ses racines, qu'elle a été obtenue « without machine learning or NLP systems ». Elle l'a été par des conventions de nommage qui encodent le sens, un ordre des paramètres qui épouse la parole, des formes souples et des valeurs par défaut intelligentes.

3. La forme Softanza

Regardez un nom comme la bibliothèque le regarde. FindNextSTCS : trouver le suivant, à partir d'une position de départ, avec un drapeau de casse. RemoveManyCS : retirer, plusieurs choses, un drapeau de casse. Chaque suffixe est petit et ne veut dire qu'une chose, et, dans ces noms, l'ordre des suffixes est l'ordre des paramètres. Ici le premier nom trouve. Que laisse le second quand il retire toutes les occurrences de trois lettres, quelle que soit leur casse ? Exécutez-le :

o1 = new stzString("123456789HARO")
? o1.FindNextSTCS("haro", 5, FALSE)
#--> 10
o2 = new stzString("SOOooooFFfffTANNnnnZA")
o2.RemoveManyCS([ "o", "f", "n" ], FALSE)
? o2.Content()
#--> STAZA

L'article promettait SOFTANZA sur la deuxième ligne. L'exécution imprime STAZA ! Le code a raison et l'article a tort : un retrait qui ne se soucie pas de la casse retire aussi les majuscules. J'imprime l'exécution.

La bibliothèque se contente-t-elle de suivre cette grammaire, ou la lit-elle ? Son analyseur de noms, _StzParseName, est un assistant interne que nulle garde ne couvre ; je l'appelle en premier ci-dessous, pour la lecture brute. La voie publique est ExplainMethod, qui explique une méthode dans ces termes :

? @@( _StzParseName("FindNextSTCS") )
#--> [ "find next", [ "case-sensitive", "from-position", "active" ] ]
? @@( _StzParseName("RemoveManyCS") )
#--> [ "remove", [ "case-sensitive", "plural", "active" ] ]
? StzSelfDocQ("stzString").ExplainMethod("RemoveMany")
#--> RemoveMany -- Remove every occurrence of each given substring (mutating).
#-->   (plural form -- applies the operation to many items at once)
#-->   reads as: remove -- over many values at once

Elle la lit. Voilà la thèse rendue mécanique : la grammaire est dans le code et pas seulement dans l'article. La ligne imprimée reads as: remove -- over many values at once est la lecture que l'analyseur fait de RemoveMany. L'analyseur décode les préfixes et les suffixes, les mots « except » et « is not », et la voix : un nom qui finit en ed est passif.

Je vais maintenant parcourir les formes. Le chapitre 5 en a montré quatre : l'active, la passive, la fluide et le paramètre nommé. Voici les autres, celles qui tournent.

Z et ZZ disent si une position arrive comme un nombre ou comme une section. Un suffixe, et la réponse change de forme :

o1 = new stzString("haro php haro ruby haro")
? @@( o1.FindZ("haro") )
#--> [ 1, 10, 20 ]
? @@( o1.FindZZ("haro") )
#--> [ [ 1, 4 ], [ 10, 13 ], [ 20, 23 ] ]
o2 = new stzString("SOFTANZA")
? @@( o2.FirstHalfZ() )
#--> [ "SOFT", 1 ]
? @@( o2.FirstHalfZZ() )
#--> [ "SOFT", [ 1, 4 ] ]

Le préfixe viz change la sorte de réponse : un dessin. La position est montrée sous le texte, et une option peut la numéroter :

o1 = new stzString("fjharoljharodjharog")
? o1.vizFind("haro")
#--> fjharoljharodjharog
#--> --^-----^-----^----
? o1.vizFindXT("haro", [ :Numbered = TRUE ])
#--> fjharoljharodjharog
#--> --^-----^-----^----
#-->   3     9     15

Le pluriel étend un verbe à plusieurs choses sans boucle, et la forme d'exception ne garde que ce que vous nommez. L'exemple de l'article pour la seconde, RemoveNonLettersExcept, n'existe pas. La forme existe, sous d'autres noms :

Q("__H~~~AR***O__") {
	? @@( FindMany([ "~", "*" ]) )
	#--> [ 4, 5, 6, 9, 10, 11 ]
	RemoveMany([ "_", "~", "*" ])
	? Content()
	#--> HARO
}
o2 = new stzString("--Haro--&__Softanza__")
o2.RemoveAllExcept([ "Haro", "&", "Softanza" ])
? o2.Content()
#--> Haro&Softanza

Le négatif est un mot dans le nom, pas un NOT autour de l'appel :

? Q("*").IsNotLetter()
#--> TRUE
o3 = new stzList([ "H", "A", "R", "O" ])
? o3.IsNotAString()
#--> TRUE
? o3.DoesNotContain("♥")
#--> TRUE

La forme profonde répond par un chemin, une liste d'indices qui va aussi profond que les données, et la même famille remplace et retire à cette profondeur, avec :By pour emplacement nommé là où le Replaced du chapitre 5 disait :With ; les verbes profonds acceptent les deux :

Q([ "you", "other", [ "other", "you", [ "you" ], "other" ], "other", "you" ]) {
	? @@( DeepFind("you") )
	#--> [ [ 1 ], [ 3, 2 ], [ 3, 3, 1 ], [ 5 ] ]
	DeepReplace("you", :By = "♥")
	? @@( Content() )
	#--> [ "♥", "other", [ "other", "♥", [ "♥" ], "other" ], "other", "♥" ]
}

La forme immuable, QC, exécute toute la chaîne sur une copie. Après cette chaîne, que contient l'original ?

o1 = new stzString("haxxrxo")
? o1.RemoveQC("x").UppercaseQ().Spacified()
#--> H A R O
? o1.Content()
#--> haxxrxo

La chaîne a imprimé H A R O, et l'original contient encore haxxrxo !

La forme mal orthographiée est acceptée, avec une note sur ce qui la soutient. Une faute d'orthographe dans un nom fonctionne :

? Q("   Haro ").WithoutSapces()
#--> Haro

L'article dit que la bibliothèque reconnaît et corrige les fautes de frappe mineures, et que l'intelligence réside dans la bibliothèque elle-même. Le code montre comment la forme fonctionne : WithoutSapces fonctionne parce que cette orthographe a été écrite à la main comme un alias. Une autre faute, WithoutSpces, échoue. La forme est donc réelle, et dans ce que j'ai suivi c'est une liste d'alias déclarés ; le moteur de correction que décrit l'article ne fait pas partie de ce que j'ai suivi. Je n'ai pas suivi tous les fichiers qui parlent de correction ; un message de la classe objet ne fait que suggérer un nom, avec « Did you mean ».

Voici maintenant la moitié du chapitre qui concerne la portée. Le même défaut apparaît partout en programmation : un comportement gouverné par un cadre invisible. Je tiens cela pour une vue, non pour un résultat ; ce qui la soutient ici, ce sont trois instances : les verbes de l'expression régulière, le système et le placement d'un déploiement. Une fonction fait une chose ici et une autre là, et rien dans son nom ne dit dans quel cadre elle se trouve. La réponse, en cinq gestes, est le paradigme que j'appelle la programmation orientée portée. Quatre viennent d'abord. Nommer le cadre caché. En faire un petit ensemble fermé de portées nommées. Choisir la portée à l'endroit de l'appel, dans le verbe, et pas dans un drapeau posé plus tôt. Et donner à la bibliothèque la portée pour raisonner, une prise sémantique et pas un commentaire.

Il est né dans les expressions régulières, où le cadre est la part du texte qu'un motif doit couvrir. Le même motif, le même texte, trois verbes : que répond chacun ?

cText = "First: Line1" + nl + "Second: Line2" + nl + "Third: Line3"
o1 = new stzRegex("^Second:.*$")
o1 {
	? Match(cText)
	#--> FALSE
	? MatchFirst(cText)
	#--> FALSE
	? MatchLine(cText)
	#--> TRUE
}

Match répond FALSE : il demande si le motif couvre la valeur entière. MatchFirst répond FALSE aussi : il demande si le motif apparaît quelque part, avec les ancres de ligne désactivées. MatchLine répond TRUE : il fait que ^ et $ s'accrochent à chaque ligne. Le cadre est dans le verbe. Il y a aussi une portée de mot, qui fournit les limites de mot pour que vous ne les écriviez pas. Elle réécrit pour de bon le motif de son objet, c'est pourquoi la deuxième instance est un nouvel objet avec le même motif. Le même motif répond-il pareil sous MatchFirst et sous MatchWord ?

o2 = new stzRegex("pre\w+")
? o2.MatchFirst("compress")
#--> TRUE
o3 = new stzRegex("pre\w+")
? o3.MatchWord("compress")
#--> FALSE

Le même motif répond TRUE sous MatchFirst et FALSE sous MatchWord !

La deuxième instance est le système. Le code d'une fonctionnalité s'écrit dans une portée nommée, et le même verbe reçoit un verdict différent dans chacune. La portée peut faire se comporter un portable comme un appareil qu'il n'a pas, ou refuser ce que la cible interdit. Ici, une solution avec un backend sur un serveur Linux et un firmware sur une petite carte. Que répond chaque système quand on lui demande le même verbe, Spawn ? Exécutez-le :

oSol = new stzPlatformProfile("my-iot-product")
oSol {
	DevelopedOn(:Windows)
	WithServer(:backend, :LinuxServer)
	WithApp(:firmware, :ESP32)
	oBack = App(:backend).System()
	oFirm = App(:firmware).System()
}
? oBack.Spawn("worker")
#--> native
? oFirm.ReadPin(4)
#--> rehearsed
try
	oFirm.Spawn("worker")
catch
	? cCatchError
done
#--> scope 'esp32' (espidf) forbids 'process' -- spawn 'worker'. This target has no such capability.

Le même verbe, Spawn, a deux verdicts ! Le serveur répond native ; la carte répond scope 'esp32' (espidf) forbids 'process'. C'est la portée qui décide, pas l'opération. Et le portable n'a pas de broche à lire, alors la portée répond rehearsed. C'est le cinquième geste : quand les capacités d'une portée diffèrent de celles de l'hôte, la bibliothèque comble l'écart, dans les deux sens. Deux systèmes déclarés peuvent être comparés comme des données, avec un ensemble fermé de capacités :

oEsp = DeclareSystem("esp32-firmware")
oEsp.SetOSName(:rtos)
oEsp.SetCapabilityList([ :gpio, :network, :clock, :threads ])
oBox = DeclareSystem("laptop")
oBox.SetOSName(:windows)
oBox.SetCapabilityList([ :filesystem, :process, :network, :clock, :threads ])
? @@( oBox.Forbids(oEsp) )
#--> [ "filesystem", "process" ]
? @@( oBox.Requires(oEsp) )
#--> [ "gpio" ]

L'exécution a imprimé [ "filesystem", "process" ] pour ce que le portable peut faire et que la carte ne peut pas, et [ "gpio" ] pour ce dont la carte a besoin et que le portable n'a pas. C'est la deuxième instance. La troisième est le déploiement : la cible est le cadre, et la portée décide de ne pas livrer ce que la cible fait déjà bien ; le chapitre 4 en a montré le plan. La quatrième est la concurrence, et c'est un plan.

La conception vient ensuite, avec ce que Haro garde de ces formes et ce qu'il refuse.

5. Le tribunal

00_regex_narrated prouve les verbes Match et MatchFirst : Match ancre, MatchFirst cherche, Z rend les positions et ne les imprime pas. Elle n'affirme rien pour MatchLine et MatchWord : les blocs plus haut les montrent, et seuls des blocs classiques, qui ne sont pas des gardes, les couvrent. 972_narration_viz-finding_a_recurring_substring prouve la réponse dessinée. full_scope_model_narrated prouve la portée du système, avec ses trois verdicts. system_scope_model_narrated prouve l'ensemble fermé de capacités ; l'une de ses assertions est une limite de temps, et la section 7 dit ce qu'une sonde en a montré. delivery_narrated prouve le plan de placement.

Où le terrain fait mieux vient ensuite.

6. Le terrain, et où il mène

Le terrain mène en convention. Un nom qui est une étiquette est plus facile à enseigner et plus facile à taper. La grammaire de ce chapitre doit s'apprendre, et certaines de ses formes sont rarement utilisées.

Le terrain mène en garantie. Les arguments nommés de Python sont vérifiés à l'appel, et les étiquettes de Swift par le compilateur, pour chaque fonction, dès le premier jour. Les formes d'ici sont jugées par le prototype de Haro, sur les noms et non sur les corps, et par l'analyseur propre de la bibliothèque, et seulement dans les noms qui les suivent.

Sur la portée, le terrain mène en maturité. La pratique la plus proche est le contexte explicite : l'habitude de Go de passer un contexte à chaque appel, un objet de locale qui porte un cadre. Elles sont plus anciennes et plus largement employées. Ce que ce paradigme ajoute, c'est que le cadre fait partie d'un petit ensemble fermé, choisi dans le verbe, et que la bibliothèque peut raisonner avec lui.

Enfin, la limite, avec ce qui est construit, ce qui est conçu et ce qui est absent.

7. La limite

• construitquatorze des vingt-deux formes, certaines avec d'autres exemples que ceux de l'article, et trois autres sous une autre forme ; la bibliothèque qui lit un nom comme une phrase ; la portée dans les verbes de l'expression régulière, dans le système et dans le placement d'un déploiement
• conçules formes déclarées une fois comme données et générées, en Haro ; le paradigme de portée pour le temps, les unités, la mémoire et le style
• absentcinq formes : partielle, future, libre, par défaut et multilingue ; la concurrence comme portée : un plan sans code

Ce qui est construit : quatorze des vingt-deux formes d'un nom tournent, certaines avec d'autres exemples que ceux de l'article, et trois autres tournent sous une autre forme. La bibliothèque lit un nom comme une phrase. Et la portée tourne dans les verbes de l'expression régulière, dans le système et dans le placement d'un déploiement. L'article compte vingt-trois sections : les vingt-deux formes d'un nom, et « small functions », qui sont des fonctions et non une forme de nom. Le nombre du livre est vingt-deux, les formes d'un nom.

Ce qui est conçu : les formes de Haro comme données, avec des familles générées ; et le paradigme de portée pour le temps, les unités, la mémoire et le style, comme lignes d'un tableau.

Ce qui est absent, et la page doit dire chacune avec ce qui existe à côté :

• Partielle, @Removed, n'est que dans l'archive : l'appel n'est pas défini.
• Future, BeforeQ, a été écourtée exprès, comme je l'ai dit.
• Libre, le suffixe qui laisse un appel donner ses paramètres dans n'importe quel ordre et n'importe quel sous-ensemble : il n'y en a aucune définition hors de l'archive. L'analyseur propre de la bibliothèque connaît le nom FX et pas FF. Les deux narrations qui la racontent emploient deux noms, et le code n'a ni l'un ni l'autre.
• Par défaut, dftRange et infRange : non définis ; le commentaire de la bibliothèque appelle la forme informante pas encore construite.
• Multilingue, une méthode nommée en français ou en arabe : absente de la bibliothèque vivante. Les noms existent dans l'archive. Ce qui s'en approche le plus aujourd'hui, ce sont les paquets de langue du chapitre 11.
• Les trois qui tournent sous une autre forme. La forme d'exception existe, mais l'exemple de l'article n'existe pas. L'ordre libre, au sens de l'article, un nombre et une chaîne permutés dans leurs positions, ne fonctionne que pour le premier ordre : dans ma sonde du 8 octobre, l'appel permuté a terminé le programme avec un statut de un et n'a rien imprimé. L'ordre libre des paramètres nommés est autre chose, et le chapitre 7 l'exécute. Et la forme d'énoncé est à moitié en place : la moitié « All » fonctionne, et la moitié « No » est l'étape suivante. Le propre test classique de la bibliothèque promet vrai sur deux de ses quatre lignes « No », et l'exécution imprime faux sur les quatre.

Du côté de la portée : les verbes de l'expression régulière diffèrent du tableau du document de conception de la portée en deux endroits. MatchLine laisse un point traverser une ligne, là où le tableau dit qu'il reste dans une seule, et MatchOneSegment, que le tableau propose pour le cas paresseux, n'est pas défini. La portée du système est construite, et le document de conception l'appelle encore conçue : le dossier se contredit lui-même. Le document de conception de la portée, version 1.2 du 16 août 2026, est cité ici comme le texte du document. Le dossier ne dit pas qui l'a écrit, et je ne l'imprime pas comme mien. Le document de fondation du système, du 20 juillet 2026, dit que la fondation est implémentée. Lors d'une exécution de sonde sous charge, que les données du livre ne gardent pas, 61 des 62 assertions de sa garde narrée ont passé, et la seule assertion qui n'a pas tenu était une limite de temps. Je dis ce que le code fait : la portée du système est construite, avec ce résultat imprimé à côté, et le mot « conçue » du document de conception est celui du document, périmé. Et la concurrence est un plan du dossier sans code : le mot Concurrently n'a aucune définition.

8. Six portes

9. Exercice

Prenez un verbe d'une bibliothèque que vous utilisez et qui se comporte autrement dans deux cadres : un mode, une locale, une cible. Dites en une phrase quel est le cadre caché. Puis écrivez, comme vous voudriez qu'ils soient, deux noms pour le même acte dans les deux cadres, avec le cadre dans le verbe. Avant de rien exécuter dans Softanza, prenez Match et MatchLine sur un texte de trois lignes et écrivez ce que chacun imprime pour un motif qui s'ancre au début.

Exécutez-le. Si vos deux noms ne diffèrent que par un drapeau, vous n'avez pas encore déplacé le cadre dans le verbe.

Je vous laisse celui-ci, exprès. À la section 3, l'article promettait SOFTANZA à partir d'un retrait, et l'exécution a imprimé STAZA. Voici ce bloc avec un seul changement, le dernier argument de l'appel :

o2 = new stzString("SOOooooFFfffTANNnnnZA")
o2.RemoveManyCS([ "o", "f", "n" ], TRUE)
? o2.Content()

Exécutez-le. Mettez ce qu'il imprime à côté de ce que l'article promettait et à côté de ce que la première exécution a imprimé. La section 3 dit pourquoi la première exécution n'a pas donné la ligne de l'article ; je n'imprime pas ce que celui-ci donne. Quand vous l'aurez résolu, vous saurez ce que le drapeau de casse décide dans un retrait, et s'il suffit à lui seul à tenir la promesse de l'article.

Le chapitre 9 passe aux motifs de pensée. Il présente le Softanzuter, une représentation computationnelle d'une machine pensante. Il est fondé sur un ou plusieurs Regexuters, qui reconnaissent des motifs de pensée et y réagissent. Avec lui viennent Reaxis et les moteurs.

Les motifs de pensée : le Softanzuter, Reaxis et les moteurs

Exécuté le 2026-10-15 12:58 UTC+01:00 dans la bibliothèque au commit 93d7a39bd : 8 bloc(s) sur 8 ont tenu leur promesse.

Les blocs ont été exécutés par le runtime de l'ancien langage hôte, version 1.27 ; Haro n'exécute pas encore la bibliothèque. Les binaires du moteur ont été construits dans une copie de ce commit, le plus récent le 2026-10-05 20:27 UTC+01:00 ; 1 changement(s) du moteur commité(s) après cette construction n'y sont pas.

Dans ce chapitre, je prends tour à tour les trois sujets du titre : le Softanzuter, Reaxis et les moteurs, dont la ligne de temps et la grille tournent ici. Le Regexuter lie un motif à du code qui se déclenche et se souvient de son pourquoi ; Reaxis est de la programmation réactive au vocabulaire repensé. Je gravis l'échelle que dessine l'architecture, quatre échelons, et au troisième je lance le bloc qui échoue à enchaîner plutôt que de revendiquer un échelon qui n'est pas construit. Je dis ce que j'ai refusé : l'expression régulière comme simple façon de lire du texte, les mots du terrain pour la programmation réactive, les quatre frères, et la cascade. Tout sert une seule phrase : un Softanzuter est une représentation computationnelle d'une machine pensante, fondée sur un ou plusieurs Regexuters, qui lui permet de reconnaître des motifs de pensée et d'y réagir.

1. Le concept, tel que le terrain le tient

Le terrain a trois outils pour faire réagir un programme. Les expressions régulières reconnaissent une forme dans un texte, et rien de plus : elles disent « cela correspond », et elles s'arrêtent. La programmation réactive, la famille des observables, des abonnés et des ordonnanceurs que Rx a rendue populaire, laisse les données circuler dans un programme au fil du temps. Son vocabulaire vient de la plomberie, de la téléphonie et de l'édition : tuyaux, contre-pression, sources chaudes et froides. Et les moteurs de règles, les systèmes de production du terrain avec leur chaînage avant, déclenchent des règles quand des faits apparaissent, et continuent de déclencher tant que de nouveaux faits apparaissent ; c'est une connaissance générale, et les moteurs de règles du terrain sont plus anciens et plus mûrs que tout ce qui est dans ce chapitre.

Chaque outil est séparé. Une expression régulière ne déclenche pas de calcul, un flux réactif ne reconnaît pas de motif, et un moteur de règles n'a pas de vocabulaire qu'une personne emploierait pour dire une pensée. Je tiens cela pour une vue, non pour un résultat.

La section suivante donne la seule phrase par laquelle je réponds.

2. Le premier principe

J'ai donné à ce paradigme une seule phrase, et tout ce qui suit tente de la rendre mécanique : un Softanzuter est une représentation computationnelle d'une machine pensante, fondée sur un ou plusieurs Regexuters, qui lui permet de reconnaître des motifs de pensée et d'y réagir.

La section suivante montre jusqu'où la bibliothèque l'a rendue mécanique.

3. La forme Softanza

L'architecture la dessine comme une échelle à quatre échelons, chacun ajoutant une chose.

Le premier échelon est le motif. Vous le verrez au chapitre 15 : une forme dans un milieu, une chaîne, une liste, un nombre, qui peut dire « cela correspond, et voici comment », et rien de plus. Le deuxième échelon donne une réaction à un motif : le Regexuter, un arc réflexe. Vous liez un motif à du code, vous traitez un texte, et le code se déclenche à chaque correspondance. Un Regexuter réagit, et il se souvient de ce qu'il a fait. Ici il masque les secrets d'une phrase. Que dit l'état qu'il garde sur chacun : ce qu'il a trouvé, ce qu'il a calculé, où, et quel déclencheur s'est déclenché ?

rxu() {
	Trigger(:SensitiveData = "(password|secret|key):\s*(\w+)")
	@C(:When = :SensitiveData, :Do = '{ @value = "REDACTED-" + len(@value) }')
	Process("User credentials: password: abc123 secret: def456")
	? @@( Results() )
	#--> [ "REDACTED-16", "REDACTED-14" ]
	? @@( Positions() )
	#--> [ 19, 36 ]
	? State()[1][:matchedvalue]
	#--> password: abc123
	? State()[1][:computedvalue]
	#--> REDACTED-16
	? @@( State()[2][:dependson] )
	#--> [ "sensitivedata" ]
}

L'état est une provenance : chaque réaction qui change une valeur garde son pourquoi. La dernière ligne, [ "sensitivedata" ], est aussi une limite honnête, et j'y reviendrai : ce que le Regexuter enregistre comme dépendance n'est aujourd'hui que son propre déclencheur.

Voici maintenant le troisième échelon, celui dont parle la définition. Ce sont plusieurs Regexuters, sur des milieux différents, partageant un seul état, de sorte que ce qu'une faculté écrit est un milieu sur lequel une autre faculté peut chercher des correspondances. Une pensée est une entrée d'état avec sa provenance, et une pensée stabilisée est un état où plus rien ne se déclenche. Cet échelon n'est pas construit, et le bloc montre comment je le sais. Le second déclencheur ci-dessous est écrit pour les nombres de trois chiffres ou plus. Le premier déclencheur transforme le 7 en 700, qui en est un. Si la machine pensait en cascades, le second se déclencherait-il sur le résultat du premier ? Exécutez-le :

rxu() {
	Trigger(:Number = "\d+")
	Trigger(:Big = "\d{3,}")
	@C(:When = :Number, :Do = '{ @value = @number(@value) * 100 }')
	@C(:When = :Big, :Do = '{ @value = "BIG" }')
	Process("Found 7 items")
	? @@( Matches() )
	#--> [ "7" ]
	? @@( Results() )
	#--> [ 700 ]
	? @@( Triggers() )
	#--> [ "number" ]
}

Il ne l'a pas fait : les résultats disent [ 700 ], les déclencheurs qui se sont déclenchés disent [ "number" ]. BIG n'apparaît nulle part ! Chaque déclencheur est confronté une seule fois au texte d'origine, et ce qu'un déclencheur écrit n'est pas offert aux autres. C'est toute la différence entre le deuxième échelon et le troisième.

La cascade tourne un échelon plus haut, au quatrième, l'agent d'IA : la machine pensante dotée d'un corps dans un monde, et d'un but. Son esprit est fait de compétences, chacune avec une condition et une action, qui s'enchaînent. La deuxième compétence se déclenche sur le fait que la première a écrit. Pursue() renvoie combien de déclenchements de compétences ont été vérifiés, et continue jusqu'à ce que le monde cesse de changer, ou vingt tours au plus. Que répond-il quand on le redemande ?

oAgent = new stzPIAgent("cook")
oAgent.MemoryQ().Learn("order", "state", "placed")
s1 = new stzAgentSkill("cook")
s1.SetWhen(func oM { return oM.Fact("order", "state", "placed") })
s1.SetDoes(func oM { oM.Forget("order","state","placed") oM.Learn("order","state","cooking") return 1 })
s2 = new stzAgentSkill("serve")
s2.SetWhen(func oM { return oM.Fact("order", "state", "cooking") })
s2.SetDoes(func oM { oM.Forget("order","state","cooking") oM.Learn("order","state","served") return 1 })
oAgent.AddSkill(s1)
oAgent.AddSkill(s2)
? oAgent.Pursue()
#--> 2
? oAgent.MemoryQ().Fact("order", "state", "served")
#--> TRUE
? oAgent.Pursue()
#--> 0

Il répond 2, puis 0, et entre les deux le fait served dit TRUE. C'est un point fixe. La garde qui le prouve étiquette la scène dans ses propres mots : the cascade to fixpoint (Softanzuter at agent level), soit la cascade jusqu'au point fixe, le Softanzuter au niveau de l'agent. Au chapitre 17, vous verrez un agent de cette même classe refusé à une barrière. Voici son autre face : l'agent qui enchaîne, parce que son esprit est programmatique.

Le mot a donc trois sens dans le dossier, et le lecteur mérite qu'on lui dise lequel est lequel. D'abord, dans ce chapitre, « Softanzuter » est le troisième échelon, la machine pensante de la définition : conçu, pas construit. Ensuite, le moteur a un module du même nom, que le macroplan présente comme le socle des agents d'IA. Ses emplacements ont un état et une boîte aux lettres bornée, et un message envoyé dans une file pleine est refusé, compté et jamais jeté en silence ; l'agent du bloc ci-dessus, stzPIAgent, ne l'appelle jamais. Enfin, la conception d'un moteur universel derrière tout cela, un milieu où n'importe quel langage de motifs devient un calcul, est planifiée.

Reaxis est le deuxième sujet du titre du chapitre, et c'est une idée différente. C'est de la programmation réactive avec un vocabulaire repensé depuis la base. Une chose réactive est un Container, un Stream et une Rfunction : une fonction en attente, qui n'est pas un rappel. Les données circulent dans un flux en mots simples, une transformation, un filtre, ce qu'il faut faire de ce qui passe. Quatre prix entrent, 80, 90, 100 et 120 : lesquels ressortent, et à quelle valeur ?

aSeen = []
Rs = new stzReactiveSystem()
Rs {
	oStream = CreateStream("prices")
	oStream {
		Transform(func price { return price * 1.20 })
		Filter(func price { return price >= 100 })
		OnPassed(func item { aSeen + item })
		FeedMany([ 80, 90, 100, 120 ])
	}
	RunLoop()
}
? @@( aSeen )
#--> [ 108, 120, 144 ]

aSeen dit [ 108, 120, 144 ] : le 80 est devenu 96 et a été écarté par le filtre ; le 90 est devenu 108 et est passé. Trois fonctions sont en attente, et rien de tout cela ne s'appelle un abonné ; l'ancien mot Subscribe survit comme alias de OnPassed.

Reaxis a remplacé la contre-pression par le débordement, un mot qu'on n'a pas besoin d'un schéma pour comprendre. Et il a été audité. Une lecture des quatre stratégies que l'article documentait a trouvé que trois d'entre elles perdaient des données sans en signaler aucune. La stratégie par défaut écartait tout ce qui dépassait la capacité pendant que le compteur affichait zéro. C'est corrigé, et prouvé pour les quatre stratégies. Ici, quatre éléments entrent dans un tampon de deux. Que dit le flux de ce qui s'est passé ?

oRs = new stzReactiveSystem()
oS = oRs.CreateStream("probe")
oS {
	SetOverflowStrategy(BUFFER_REJECT_NEWEST, 2)
	for i = 1 to 4
		Receive(i)
	next
	? OverflowStats()[:currentBuffer]
	#--> 2
	? OverflowStats()[:droppedCount]
	#--> 2
}

Il dit que currentBuffer vaut 2 et que droppedCount vaut 2. Le compteur qui affichait zéro compte désormais !

Et pour ce que le terrain appelle debounce, Reaxis dit ce que cela veut dire : attendre que l'attribut se stabilise. Trois changements en succession rapide : combien de réactions, une fois que la valeur a cessé de changer pendant cinquante millisecondes ?

nSettled = 0
oRs4 = new stzReactive()
oX = oRs4.ReactiveObject()
oX.WaitForAttributeToSettle("query", 50, func(attr, oldV, newV) { nSettled++ })
oX.SetAttribute("query", "s")
oX.SetAttribute("query", "so")
oX.SetAttribute("query", "sof")
oX { ProcessPendingReactions() }
oRs4.RunLoop()
? nSettled
#--> 1
oRs4.Stop()

Une seule réaction. nSettled dit 1.

Le troisième sujet du chapitre, ce sont les moteurs, les petits paradigmes que la bibliothèque a repensés un par un. Le chapitre 3 vous a donné la vérité et le vide. En voici deux de plus, exécutés ici. Le temps est un espace de travail, pas un nombre. Une ligne de temps tient des plages et calcule les vides et les chevauchements. Que dit-elle du vide entre deux phases, et que fait-elle d'un point qui tomberait dans une région bloquée ?

oTl = new stzTimeLine("2024-01-01 00:00:00", "2024-12-31 23:59:59")
oTl {
	AddSpan("PHASE1", "2024-01-01 00:00:00", "2024-02-15 23:59:59")
	AddSpan("PHASE2", "2024-03-01 00:00:00", "2024-04-15 23:59:59")
	? len(Gaps())
	#--> 1
	? Gaps()[1][:after]
	#--> PHASE1
	? Gaps()[1][:before]
	#--> PHASE2
	? HasOverlaps()
	#--> FALSE
	AddSpan("PHASE2B", "2024-04-01 00:00:00", "2024-05-15 23:59:59")
	? HasOverlaps()
	#--> TRUE
}
oB = new stzTimeLine("2024-01-01", "2024-12-31")
oB {
	AddBlockedSpan("MAINTENANCE", "2024-06-15 09:00:00", "2024-06-15 17:00:00")
	AddPoint("EVENT1", "2024-06-15 08:00:00")
	try
		AddPoint("EVENT2", "2024-06-15 12:00:00")
	catch
		? cCatchError
	done
	#--> Point 'EVENT2' falls within a blocked span or blocked point
}

Le vide est nommé par ce qu'il sépare, PHASE1 et PHASE2. La plage bloquée a refusé EVENT2 ! Le refus porte sa raison : Point 'EVENT2' falls within a blocked span or blocked point.

Et une grille a un curseur qui sait où il est : la position est une colonne et une ligne, et se déplacer au-delà d'un bord reste au bord. Deux pas vers le bas et trois vers la droite, puis trois de plus vers la droite : où est le curseur ?

StzGridQ([ 5, 5 ]) {
	MoveDown()
	MoveDown()
	MoveRight()
	MoveRight()
	MoveRight()
	? @@( CurrentPosition() )
	#--> [ 4, 3 ]
	MoveRight()
	MoveRight()
	MoveRight()
	? @@( CurrentPosition() )
	#--> [ 5, 3 ]
}

En [ 4, 3 ], puis en [ 5, 3 ]. Trois pas de plus vers la droite ont gagné une colonne, et le curseur est resté au bord !

5. Le tribunal

Le Regexuter et le Listexuter ont des tests classiques, et aucune garde narrée. Les huit tests classiques du Regexuter ont tourné sans erreur : le journal du dossier dit PASS 8 ERR 0. Rien n'y vérifie ce qu'ils impriment. Cinq des sept tests du Listexuter échouent à leur propre sortie attendue, et deux ne promettent rien. La cascade de l'agent est prouvée par piagent_narrated, scène cinq. Reaxis a beaucoup de gardes. 00_overflow_narrated prouve les quatre stratégies de débordement et le cas qui ne perd rien ; 60_reaxis_on_reactor_narrated prouve un minuteur à coup unique, le minuteur répété, le HTTP non bloquant et l'attribut qui se stabilise sur la boucle du moteur. La ligne de temps a test_timeline_regression, qui couvre la construction, la durée, l'ajout de points et le déplacement des bornes, mais ni les vides, ni les chevauchements, ni les plages bloquées. La grille a 00_grid_narrated, et les opérations profondes 01_deeplist_narrated.

La section suivante place ce dossier à côté de celui du terrain.

6. Le terrain, et où il mène

Les moteurs de règles du terrain mènent. Ils sont plus anciens et plus mûrs que le Regexuter, ils s'enchaînent jusqu'à un point fixe, et les algorithmes qui les portent ont des décennies. Ce que je revendique n'est pas un moteur de règles. C'est le côté condition : des règles qui sont des phrases des langages de motifs, sur les deux milieux qui ont une machine réagissante construite, le texte pour le Regexuter et les listes pour le Listexuter. L'état garde, pour chaque déclenchement qui change une valeur, son pourquoi. L'architecture même de la bibliothèque appelle le Regexuter un moteur de règles à chaînage avant naissant, et je n'en dirai pas plus.

Les bibliothèques réactives du terrain mènent en portée. Rx existe dans la plupart des langages courants, avec un grand nombre d'opérateurs ; c'est une connaissance générale. Reaxis est une bibliothèque sur une boucle d'événements. Le module propre du moteur pour cela est une petite table de règles sur des sous-chaînes : le modèle Container, Stream et Rfunction vit dans la bibliothèque, sur la boucle d'événements du moteur.

Je n'imprimerai pas la comparaison par étoiles avec les outils du terrain que porte l'article de la bibliothèque sur les objets réactifs. Elle n'est ni datée ni sourcée.

La section suivante dit où tout cela s'arrête.

7. La limite

• construitle Regexuter et le Listexuter, qui réagissent avec un état qui se souvient ; Reaxis, la programmation réactive en mots simples, sur la boucle d'événements du moteur ; la ligne de temps, la grille et les opérations profondes ; l'agent d'IA dont les compétences s'enchaînent jusqu'à un point fixe
• conçule Softanzuter proprement dit, plusieurs facultés partageant un seul état et s'enchaînant jusqu'à ce qu'il se stabilise ; le moteur universel derrière lui ; ses quatre frères, analyseur, génétique, linguistique et quantique
• absentune chaîne de dépendance qui relie un déclencheur à un autre ; un verbe de fusion de sections que l'article présente comme son point central

Ce qui est construit : le Regexuter et le Listexuter ; Reaxis sur la boucle d'événements du moteur ; la ligne de temps, la grille et les opérations profondes ; l'agent d'IA dont les compétences s'enchaînent.

Ce qui est conçu : le troisième échelon, plusieurs facultés sur un état partagé, s'enchaînant jusqu'à ce qu'il se stabilise. Le moteur universel pour cela est planifié. Les quatre frères sont une vision. Le macroplan marque le module du moteur comme fait, et le tableau d'architecture le marque comme planifié : le même nom pour deux choses. Ce tableau marque comme planifié tout module de sa cinquième couche, y compris ceux qui ont du code source, et il est donc périmé sur ce point. Le milieu universel est planifié dans le document de conception du moteur.

Ce qui est absent ou cassé à ce commit :

• La chaîne de dépendance n'en est pas une. Chaque entrée d'état ne dépend que de son propre déclencheur, de sorte que la chaîne enregistre quel déclencheur était actif et jamais un lien entre deux. Demander la chaîne fait déborder la pile : l'exécution se termine par Error (R4) : Stack Overflow. Aucun test ne l'appelle.
• Cinq des sept tests classiques du Listexuter échouent à leur propre sortie attendue, et deux ne promettent rien. Le journal d'erreurs de ce dossier note, dans le sixième fichier, Error (C8) : Parentheses ')' is missing.
• Une liste imbriquée qui correspond en entier est signalée deux fois.
• Le minuteur répété de l'article prend trois arguments et la bibliothèque en prend deux ; la forme avec unités est RunEveryXT.
• Deux des verbes de chemin de l'article sur les listes profondes, ItemAtPath et ItemsAtPaths, vivent sur une sous-classe, stzDeepList, et pas sur une liste ordinaire ; Paths() est sur une liste ordinaire.
• L'article sur la fusion de sections présente comme son point central un verbe général qui n'existe pas. Les deux qui existent, fusionner ce qui se chevauche et fusionner ce qui est inclus, tournent. La fusion de sections n'a pas de fichier de test à elle.
• Il n'y a pas de module natif du moteur pour le modèle Container, Stream et Rfunction : il tourne dans la bibliothèque, et le module réactif propre du moteur est une petite table de règles sur des sous-chaînes. La garde de la ligne de temps ne vérifie ni vide, ni chevauchement, ni plage bloquée ; dans les fichiers classiques de la ligne de temps, sept échouent à leur sortie attendue et dix-huit ne promettent rien. Le navigateur de grille adossé au moteur, stzGridNav, n'a aucun test.

8. Six portes

9. Exercice

Écrivez un Regexuter avec deux déclencheurs, un pour les nombres et un pour les nombres de trois chiffres ou plus, avec du code qui transforme un nombre en son triple. Avant de l'exécuter, écrivez sous chaque question ce que vous attendez : quelles sont les correspondances, quels sont les résultats, et si le second déclencheur se déclenche sur le résultat du premier. Exécutez-le. Si le second déclencheur se déclenche, vous avez trouvé quelque chose que je n'ai pas trouvé.

Puis dites en une phrase ce qu'il faudrait changer dans la machine pour qu'il se déclenche, et à quel échelon de l'échelle ce changement appartient.

Je vous laisse celui-ci. Reprenez le deuxième bloc de la section 3 et écrivez ses deux lignes Trigger dans l'autre ordre, celui des trois chiffres d'abord :

rxu() {
	Trigger(:Big = "\d{3,}")
	Trigger(:Number = "\d+")
	@C(:When = :Number, :Do = '{ @value = @number(@value) * 100 }')
	@C(:When = :Big, :Do = '{ @value = "BIG" }')
	Process("Found 7 items")
	? @@( Matches() )
	? @@( Results() )
	? @@( Triggers() )
}

Avant de l'exécuter, écrivez si l'ordre change ce que contiennent Results() et Triggers(). Je n'imprime pas la sortie de cette version et je ne vous donne pas la réponse : la section 3 dit contre quoi chaque déclencheur est comparé, et la section 4 dit ce que j'ai refusé d'affirmer. Quand vous saurez dire pourquoi, vous saurez ce qui sépare le deuxième échelon du troisième.

Le chapitre 10 passe de la machine qui pense au code qui change. Son titre est La programmation devient raffinement, et il tient à un seul principe : cessez de vouloir gouverner l'intelligence, et gouvernez le changement.

La programmation devient raffinement

Exécuté le 2026-10-15 12:58 UTC+01:00 dans la bibliothèque au commit 93d7a39bd : 9 bloc(s) sur 9 ont tenu leur promesse.

Les blocs ont été exécutés par le runtime de l'ancien langage hôte, version 1.27 ; Haro n'exécute pas encore la bibliothèque. Les binaires du moteur ont été construits dans une copie de ce commit, le plus récent le 2026-10-05 20:27 UTC+01:00 ; 1 changement(s) du moteur commité(s) après cette construction n'y sont pas.

Dans ce chapitre, je dis ce que j'entends par raffiner plutôt que programmer. C'est un changement apporté à du code déclaré modifiable, proposé sous une forme typée, jugé par une barrière, enregistré comme un pas, et réversible. J'exécute la forme que la bibliothèque lui donne : le point de raffinement, la proposition, la barrière, la cascade, le plancher de confiance et le retour en arrière. Et j'imprime la barrière telle qu'elle est, cinq contrôles et non les quatre de ma conception. Je dis où le terrain mène et où la barrière s'arrête. Le principe est la phrase que j'ai écrite sur la quatrième de couverture de mon livre précédent, Refinement-Oriented Programming : cessez de vouloir gouverner l'intelligence, et gouvernez le changement.

1. Le concept, tel que le terrain le tient

Le terrain a un nom pour changer une infrastructure avec une répétition : planifier, puis appliquer. Un outil calcule ce qui changerait, le montre, et ne l'applique que lorsque vous le dites. Terraform a rendu le schéma familier, et les contrôleurs d'admission du terrain appliquent la même idée à une requête avant qu'un cluster l'accepte. Plus récemment, le terrain a un nom pour une façon de travailler avec des agents d'IA qui écrivent du code : les spécifications d'abord, et l'agent remplit. Tout cela est une connaissance générale, pas une étude du dossier.

Ce que ces pratiques partagent, c'est l'endroit où elles se tiennent. Le plan et le contrôle d'admission portent sur l'infrastructure et sur les requêtes. Pour le code lui-même, une bonne part de la réponse du terrain à un changement reste un diff, un correctif de texte, et la relecture d'une personne. Cela marchait tant que chaque changement avait derrière lui une personne à qui poser la question. C'est un instrument faible quand la plupart des changements arrivent d'agents, en volume ; je tiens cela pour une vue, non pour un résultat.

À cet instrument faible, j'oppose une seule phrase.

2. Le premier principe

J'ai écrit la phrase sur la quatrième de couverture de mon livre précédent, Refinement-Oriented Programming, et je n'en ai pas trouvé de meilleure : cessez de vouloir gouverner l'intelligence, et gouvernez le changement. L'en-tête de la bibliothèque dit la même chose sous la forme d'un type : un changement est une proposition typée, pas un diff.

Le reste du chapitre exécute cette phrase.

3. La forme Softanza

La pratique a changé de nom dans ma vie. Je disais que je programmais. Je dis maintenant de plus en plus que je raffine, et je veux dire par là quelque chose d'exact. Un raffinement est un changement apporté à du code qui a été déclaré modifiable, proposé sous une forme typée, jugé par une barrière, enregistré comme un pas, et réversible. Mon livre précédent, Refinement-Oriented Programming, raconte la discipline à travers l'histoire de Softibank, une banque devant la lettre d'un régulateur. Ce chapitre dit ce que la bibliothèque en porte.

Il commence par déclarer où le code peut changer. Un point de raffinement est un bouton nommé, écrit dans le source sous forme de balise, avec son genre, sa valeur et ses bornes, et le code qui le porte est interrogé dans sa scène, la forme du chapitre 5 :

cSrc = 'vat_rate = <R:PARAM name="vat" value="0.20" min="0" max="0.25">' + nl +
       'sort_by  = <R:ALGO name="sort" value="quick" options="quick|merge|heap">'
o = new stzRefinableCode(cSrc)
o {
	? NumberOfPoints()
	#--> 2
	? @@( RefinementPoints() )
	#--> [ [ "vat", "param", "0.20" ], [ "sort", "algo", "quick" ] ]
	? KindOf("vat")
	#--> param
}

Un changement est alors une proposition. Elle nomme un point et une valeur ; si elle franchit la barrière, elle prend effet et est enregistrée comme un seul pas :

o {
	r = Refine("vat").To("0.22")
	? r[:admitted]
	#--> 1
	? ValueOf("vat")
	#--> 0.22
	? NumberOfSteps()
	#--> 1
}

L'admission s'imprime en 1 et 0, non en TRUE et FALSE : c'est ainsi que ce verbe répond, et j'imprime l'exécution. Et que change une proposition qui ne franchit pas la barrière, et que dit la barrière ? Exécutez-le :

o {
	r2 = Refine("vat").To("0.99")
	? r2[:admitted]
	#--> 0
	? r2[:why]
	#--> constraint: 0.99 above max 0.25
	? ValueOf("vat")
	#--> 0.22
	? Refine("sort").To("bubble")[:why]
	#--> constraint: 'bubble' not in options quick|merge|heap
	? Refine("ghost").To("1")[:why]
	#--> structural: no refinement point 'ghost'
	? NumberOfSteps()
	#--> 1
}

Trois refus, et la ligne de temps n'a pas grandi d'un pas ! Le commentaire de la bibliothèque en fait une de ses lois : une proposition rejetée ne finit jamais modifiée. Chaque refus nomme d'abord son étape, constraint deux fois et structural une fois, comme dans structural: no refinement point 'ghost', pour qu'une personne, ou un agent, puisse corriger la proposition sans lire un diff.

La cascade est ce que vous lisez à la place du diff. Avant le changement, demandez ce qu'il atteint. Il y a deux cascades, et elles sont séparées. Pour un point, c'est la ligne où il se trouve et les autres points de cette même ligne :

cPrice = 'price = <R:PARAM name="vat" value="0.20" min="0" max="0.30"> * <R:PARAM name="margin" value="1.1" min="1" max="2">' + nl +
         'floor = <R:PARAM name="floor" value="0.10" min="0" max="0.30">'
oc = new stzRefinableCode(cPrice)
oc {
	aC = Cascade("vat")
	? aC[:lines][1]
	#--> 1
	? @@( aC[:alsoTouches] )
	#--> [ "margin" ]
	? Cascade("floor")[:lines][1]
	#--> 2
	? len(Cascade("floor")[:alsoTouches])
	#--> 0
}

vat se trouve ligne 1 et touche aussi [ "margin" ] ; floor se trouve ligne 2, seul.

Pour une classe, la cascade est une propriété de la structure du code : qui en descend et qui hérite d'une méthode. La bibliothèque la calcule à partir du graphe de code, et elle peut analyser un texte sans toucher un fichier :

cCls = 'class Tariff' + nl +
       '	def Rate()' + nl +
       '		return 0.20' + nl +
       'class Invoice from Tariff' + nl +
       '	def Total()' + nl +
       '		return 1' + nl +
       'class Receipt from Invoice' + nl +
       '	def Print()' + nl +
       '		return 1' + nl +
       'class Quote from Tariff' + nl +
       '	def Rate()' + nl +
       '		return 0.18' + nl
g0 = new stzRingCodeGraph("")
g0 {
	ScanSource(cCls, "world.ring")
	BuildGraph()
	? @@( Cascade("Tariff")[:descendants] )
	#--> [ "Invoice", "Quote", "Receipt" ]
	? Cascade("Tariff")[:blastRadius]
	#--> 3
	? @@( ImpactOf("Rate")[:inheritedBy] )
	#--> [ "Invoice", "Receipt" ]
}

Changez le taux du tarif et trois classes sont dans le rayon d'impact. Deux d'entre elles héritent de la méthode, et ImpactOf les nomme : [ "Invoice", "Receipt" ]. La troisième, Quote, la redéfinit, de sorte qu'elle la possède et ne fait pas que l'hériter. C'est la différence que trace ImpactOf.

Comment un changement atteint-il ses dépendants ? Par une règle qui couvre plusieurs points, jugée sur l'état que le changement produirait. Si la règle échoue, la valeur est remise :

d = new stzRefinableCode(cPrice)
d {
	DeclareDerivation("vat-above-floor",
		func oCode { return ring_number(oCode.ValueOf("vat")) >= ring_number(oCode.ValueOf("floor")) },
		"vat must not drop below floor")
	? Refine("vat").To("0.30")[:admitted]
	#--> 1
	r3 = Refine("vat").To("0.05")
	? r3[:admitted]
	#--> 0
	? r3[:why]
	#--> derivation: rule 'vat-above-floor' violated -- vat must not drop below floor
	? ValueOf("vat")
	#--> 0.30
}

La règle a refusé le changement et s'est nommée : derivation: rule 'vat-above-floor' violated -- vat must not drop below floor. La valeur est toujours 0.30.

Et qui l'a proposé ? Chaque proposition porte son origine, et un point peut fixer un plancher de confiance qui refuse une origine inférieure, sans refuser une personne. Qu'arrive-t-il à une proposition venue d'un modèle de langage quand le plancher du point exige une origine de confiance ? Exécutez-le :

d {
	TrustFloor("vat", :trusted)
	r4 = Refine("vat").As(:llm).To("0.25")
	? r4[:admitted]
	#--> 0
	? r4[:why]
	#--> trust: posture :llm below the required floor for 'vat'
	? ValueOf("vat")
	#--> 0.30
	? Refine("vat").As(:trusted).To("0.25")[:admitted]
	#--> 1
	? PostureOf(NumberOfSteps())
	#--> trusted
}

La proposition du modèle a été refusée : trust: posture :llm below the required floor for 'vat'. Le point a gardé 0.30 ! La même proposition, venue d'une origine de confiance, a été admise, et le pas enregistre trusted.

Et qui peut tourner quel bouton ? C'est déclaré lui aussi : une permission, et un niveau d'autorité contre un niveau de risque. Prenez un acteur délégué et un bouton du troisième niveau. Exécutez-le :

gv = new stzRefinableCode(cPrice)
gv {
	SetGovernedBy(new stzGovernance("release-ops"))
	SetActor("release-bot")
	SetRiskFor("vat", 3)
	SetAllowRefine("vat")
	SetAuthorityLevel(:Delegated)
	r5 = Refine("vat").To("0.22")
	? r5[:admitted]
	#--> 0
	? r5[:why]
	#--> governance: refused: 'release-bot' holds 'delegated' authority (level 2) but 'refine-vat' is risk tier 3 (SHOULD does not cover it)
	? ValueOf("vat")
	#--> 0.20
	SetAuthorityLevel(:Autonomous)
	? Refine("vat").To("0.22")[:admitted]
	#--> 1
	? GovernanceQ().NumberOfDecisions()
	#--> 1
}

L'acteur délégué a été refusé, 'release-bot' holds 'delegated' authority (level 2), et la valeur est restée 0.20. La même proposition a été admise une fois l'acteur escaladé ! La décision est enregistrée : NumberOfDecisions() a imprimé 1.

Enfin, un pas peut-il être repris ? La réversibilité fait partie du modèle de données : chaque pas admis garde sa valeur antérieure. Remontez jusqu'à un point de contrôle nommé, remontez jusqu'à zéro, avancez de nouveau :

t = new stzRefinableCode(cPrice)
t {
	Refine("vat").To("0.21")
	Refine("vat").To("0.22")
	Checkpoint("reviewed")
	Refine("vat").To("0.28")
	? ValueOf("vat")
	#--> 0.28
	RevertToCheckpoint("reviewed")
	? ValueOf("vat")
	#--> 0.22
	? NumberOfSteps()
	#--> 2
	RevertTo(0)
	? ValueOf("vat")
	#--> 0.20
	? CanRevert()
	#--> 0
	Redo()
	? ValueOf("vat")
	#--> 0.21
}

À zéro, CanRevert() a imprimé 0. Un seul Redo(), et la valeur est 0.21, le premier pas de nouveau.

Voilà la barrière sous la forme que la bibliothèque lui donne. Cinq contrôles, dans l'ordre où le code les exécute. La structure de la proposition, puis les contraintes du point, puis la gouvernance, puis la confiance de l'origine, et enfin la dérivation entre les points. Je les ai exécutés plus haut dans l'ordre du récit, non dans celui du code. L'en-tête du fichier appelle cela une barrière à quatre étapes sur une ligne et à cinq sur une autre. Le code numérote ses contrôles 1, 2, 3, 4 et 4b. Le contrôle de confiance a été ajouté aux quatre le 16 juillet 2026, et le compte de la conception n'a pas été changé. Je rapporte ce qui tourne : cinq contrôles.

Derrière la barrière se tiennent des décisions, et ce que j'ai refusé.

5. Le tribunal

refinablecode_narrated prouve le point déclaré, la proposition qui passe, les deux refus qui laissent le source entier (bornes et options), la cascade, le retour en arrière et le fichier sauvegardé. refine_deepening_narrated prouve la ligne de temps avec ses points de contrôle et son rétablissement, et le plancher de confiance. gate_deepening_narrated prouve le refus d'un point inconnu, la dérivation entre les points avec son annulation, et le refus gouverné avec sa filiation.

Vient ensuite le terrain, et où il mène.

6. Le terrain, et où il mène

Le terrain mène en infrastructure, où planifier et appliquer sont la pratique quotidienne de nombreuses équipes et où l'application parle à de vrais fournisseurs ; c'est une connaissance générale, comme dans la section 1. La barrière de Softanza porte sur le changement apporté au code, que le terrain traite par une relecture.

Les outils du terrain mènent en étendue : ils ne sont liés ni à une bibliothèque, ni à un langage, ni à un bouton déclaré. La barrière de Softanza juge ce que le code a déclaré comme point. Un changement apporté à un endroit qui n'a jamais été déclaré n'est pas un raffinement ici ; il est hors de la barrière.

Et sur la confiance, une bonne part de l'approche du terrain est faite pour passer à l'échelle de n'importe quel modèle d'IA. La mienne repose sur une déclaration par point.

Voyons maintenant où la barrière s'arrête.

7. La limite

• construitle point de raffinement déclaré dans le source ; la barrière à cinq contrôles ; la cascade d'un point et d'une classe ; le retour en arrière par pas, par point de contrôle et jusqu'à zéro ; le plancher de confiance et le raffinement gouverné
• conçul'expérience que décrit l'article : demander à un point de s'expliquer, appliquer un plan, un raffinement en une ligne ; la cascade du graphe de code jointe à la barrière ; le siège de raffinement de Haro
• absentun historique sauvegardé : le fichier garde le source et rien de la ligne de temps

Ce qui est construit : le point de raffinement, la barrière avec ses cinq contrôles, la cascade d'un point et d'une classe, le retour en arrière, le plancher de confiance et le raffinement gouverné. Les gardes de la section 5 les couvrent, avec deux exceptions. La cascade d'une classe n'a pas de garde ici, parce que la garde du graphe de code scanne un chemin vivant de l'arbre de travail de la bibliothèque. Et aucune garde n'affirme les autres points d'une ligne.

Ce qui est conçu, et absent de la bibliothèque par son nom : l'expérience que décrit l'article d'origine. La classe que cet article nomme, stzPolyCode, n'est pas dans la bibliothèque à ce commit. Le raffinement en une ligne du document de conception, un point qui s'explique, un plan qui est appliqué, ne sont pas dans la bibliothèque. La cascade du graphe de code et la cascade de la barrière ne sont pas jointes. Et Haro a une barrière dans un spike écrit uniquement dans l'ancien langage hôte, son propre siège de raffinement n'étant pas construit.

Ce qui est construit, et où cela s'arrête : les limites de la barrière telle qu'elle est.

• Elle vérifie les contraintes de trois genres de point, un paramètre, un algorithme et une bibliothèque. Un point d'un autre genre, un bloc de code par exemple, est analysé et passe sans contrôle ; les contrôles pour ces genres sont l'étape suivante.
• Une posture de confiance inconnue se classe comme de confiance : le code lui donne le rang le plus haut. Une proposition venue d'une origine que le code ne connaît pas franchit donc un plancher de confiance.
• Une dérivation est appliquée à titre provisoire et restaurée en cas d'échec. Je dis donc « ne finit jamais modifié », pas « jamais touché ».
• Le fichier sauvegardé contient le source rendu ; l'historique, les postures, la ligne de temps et le rechargement sont absents, et c'est l'étape suivante. La réversibilité vit dans l'objet en cours d'exécution ; la porter dans le fichier est encore à venir. La bibliothèque écrit ce fichier avec le suffixe .zrfn, tel que livré. La charte de Haro, ratifiée le 1er octobre 2026, retient le suffixe .rfn pour la phrase de raffinement de Haro, et laisse .zrfn à l'extraction de la bibliothèque par balises de commentaire, la forme que ce chapitre a exécutée.

8. Six portes

9. Exercice

Prenez deux réglages d'un de vos programmes : un taux et un plafond, par exemple, avec une règle selon laquelle le taux doit rester sous le plafond. Déclarez-les comme des points, avec des bornes, et déclarez la règle qui les couvre. Avant de rien exécuter, écrivez sous chaque proposition si elle est admise et, sinon, à quelle étape elle est refusée. Proposez un changement du taux au-dessus du plafond, et un autre depuis une origine que vous déclarez comme un modèle d'IA, contre un plancher que vous fixez. Puis remontez jusqu'à zéro et avancez d'un pas.

Exécutez-le. Si vous vous êtes trompé sur l'étape, vous avez trouvé un endroit où votre propre barrière est en désaccord avec votre propre attente.

Je vous laisse celui-ci. La section 7 dit ce que la barrière fait d'une origine que le code ne connaît pas, et le bloc de confiance de la section 3 est celui à exécuter. Ses premières lignes sont ci-dessous, et d est l'objet de ce bloc, alors exécutez d'abord la section 3 ; changez une seule chose, et remplacez :llm par un nom de votre choix, que le code n'a jamais appris.

d.TrustFloor("vat", :trusted)
r4 = d.Refine("vat").As(:yourorigin).To("0.25")
? r4[:admitted]

Exécutez-le, et lisez ce que fait la barrière en regard de ce que dit la section 7. Je ne vous dirai pas si la barrière a raison. Quand vous aurez tranché, vous saurez ce que le plancher de confiance fait d'une origine qu'il n'a jamais rencontrée.

Le chapitre suivant énonce une loi : un langage est déclaré et fermé, et ce qui le parle, une personne ou un modèle, est jugé par lui. Ici, la chose jugée était un changement ; là, c'est ce qui parle.

Loi : un langage est déclaré et fermé, et ce qui le parle, personne ou modèle, est jugé par lui

Exécuté le 2026-10-15 12:58 UTC+01:00 dans la bibliothèque au commit 93d7a39bd : 11 bloc(s) sur 11 ont tenu leur promesse.

Les blocs ont été exécutés par le runtime de l'ancien langage hôte, version 1.27 ; Haro n'exécute pas encore la bibliothèque. Les binaires du moteur ont été construits dans une copie de ce commit, le plus récent le 2026-10-05 20:27 UTC+01:00 ; 1 changement(s) du moteur commité(s) après cette construction n'y sont pas.

Dans ce chapitre, j'énonce la loi de la partie III et je la fais tourner. Je commence par une phrase qui tourne parce que chaque mot est dans un dictionnaire que la bibliothèque possède, en anglais, en hausa, en français et en arabe. Je montre ce qu'elle dit d'un mot qu'elle ne connaît pas. Puis je déclare la forme d'une réponse comme un schéma, je juge des réponses contre lui, et je montre la seule chose qu'une grammaire ne peut pas tuer : une réponse fausse dans la bonne forme. Je dis quelles gardes le prouvent, où le terrain est en avance, et où la couche naturelle n'est pas encore fermée, ce que la loi énonce. La loi elle-même tient en une phrase : un langage est déclaré et fermé, et ce qui le parle, une personne ou un modèle, est jugé par lui.

Ce que l'âge de l'IA change ici

Dans la partie II, l'âge a changé qui écrit le code. Ici, il change qui prononce la phrase. Une phrase d'un langage avait autrefois une personne derrière elle, quelqu'un à qui l'on pouvait demander ce qu'il voulait dire. Aujourd'hui l'auteur d'une phrase peut être un modèle d'IA, à qui l'on ne peut rien demander, et qui écrira une phrase fluide qu'elle soit vraie ou non.

La grammaire doit donc être fermée, et le tribunal, la partie qui accepte ou refuse une phrase selon sa grammaire, doit la lire. Un langage dont les phrases peuvent contenir n'importe quoi ne peut rien refuser, et un tribunal ne peut pas juger une phrase qu'il ne peut pas lire. La vision de la plateforme met tout le mouvement en une ligne, que j'ai ratifiée : les humains et les machines se rencontrent dans des langages déclarés, petits, fermés et jugés, pas dans du code généraliste.

C'est aussi là que l'ordre du livre se retourne. La couverture va du familier au nouveau : la programmation, les langages, l'intelligence. La logique du dossier va dans l'autre sens. Le premier acte est de déclarer un langage. La programmation, la discipline de la partie II, se passe à l'intérieur de langages déclarés : les formes du vocabulaire sont déjà une déclaration en Haro, dans un spike, une courte expérience écrite pour essayer une conception, hors de la bibliothèque. L'intelligence, partie IV, est gouvernée par les deux : un modèle est tenu à une grammaire déclarée avant de parler, et sa phrase est jugée après. Le livre garde l'ordre de la couverture, donc ce chapitre est au milieu ; dans l'ordre du dossier, il viendrait en premier.

1. Le concept, tel que le terrain le tient

Pour un programmeur qui travaille, un langage est un hôte généraliste, Python, JavaScript, Java. Un « langage de domaine » est d'ordinaire une bibliothèque dont les appels se lisent comme des phrases, alors que le fichier autour peut contenir n'importe quel code de l'hôte. L'étude que le domaine de projets a faite du terrain, écrite en août 2026, nomme ce qui est arrivé à ces conceptions. Les langages internes sont morts d'ouverture, parce qu'un fichier de construction n'est déclaratif que jusqu'au jour où quelqu'un y écrit du code arbitraire. Les ateliers de langage sont morts du poids de leurs outils. Et elle nomme les langages qui ont gagné : SQL, les expressions régulières, Make, HTML et CSS, les langages de configuration. Son verdict est qu'ils ont gagné parce qu'ils sont fermés.

L'ère des modèles a ajouté une pratique : quand un modèle d'IA écrit, ou bien l'on vérifie ce qu'il a écrit, ou bien l'on contraint sa sortie pendant qu'il écrit, avec une grammaire ou un schéma. L'implémentation de référence de l'échantillonnage contraint par une grammaire est un projet ouvert, et le dossier le dit là où il emploie le même algorithme. Et dans le langage commun du terrain aujourd'hui, « programmer en langage naturel » veut dire une seule chose : donner une consigne à un modèle.

2. Le premier principe

Un langage est déclaré et fermé, et ce qui le parle, une personne ou un modèle, est jugé par lui.

3. La forme Softanza

Une phrase peut-elle tourner sans qu'un modèle d'IA devine ce qu'elle veut dire ? Elle le peut, quand chaque mot est dans un dictionnaire que la bibliothèque possède :

Naturally("
    Make a string with 'hello niger' inside
    Spacify it and uppercase it
    @Box it while the box@ is rounded
    Display it on the screen
")
#--> ╭───────────────────────╮
#    │ H E L L O   N I G E R │
#    ╰───────────────────────╯

Quatre lignes d'anglais sont devenues une boîte arrondie autour de majuscules espacées.

Le dictionnaire est fait de données, indexées par des sens, pas par des mots anglais. Le même sens peut-il donc être dit dans une autre langue en ajoutant un bloc de données, pas de code ? Voici une même instruction en anglais, en hausa, en français et en arabe. La phrase en hausa est celle de la narration, et celle en français vient de la garde de la bibliothèque avec ses données changées. J'ai composé celle en arabe à partir du vocabulaire de la bibliothèque. Aucun locuteur natif n'a lu le hausa ni l'arabe pour autant que le dossier le montre :

? Naturally("Create a string with 'hello' and uppercase it").Result()
#--> HELLO
? NaturallyIn("hausa", "Yi rubutu dauke 'hello' Maida shi").Result()
#--> HELLO
? NaturallyIn("fr", "Crée une chaine avec 'hello' et mets la en majuscules").Result()
#--> HELLO
? NaturallyIn("ar", "أنشئ نصا بـ 'hello' ثم كبّره").Result()
#--> HELLO

Quatre langues, un seul sens, et HELLO quatre fois.

Et un programme redit ce qu'il a compris, dans sa propre langue. Une personne qui lit l'arabe peut vérifier la lecture que la machine fait de sa phrase sans lire une ligne de code.

o1 = NaturallyIn("ar", "أنشئ قائمة بـ [ 5, 3, 5 ] ثم أزل تكراراتها")
? @@( o1.Result() )
#--> [ 5, 3 ]
? o1.Understood()
#--> أنشئ قائمة بـ [ 5, 3, 5 ] -> أزل التكرارات

Le programme a redit أنشئ قائمة بـ [ 5, 3, 5 ] -> أزل التكرارات : la liste reçue, et la suppression des doublons.

Voici maintenant ce que la bibliothèque fait par règle : dire ce qu'elle n'a pas compris. Que fait-elle d'un verbe qu'elle ne connaît pas ? Écrivez-en un de travers et exécutez :

o1 = Naturally("Create a string with 'softanza' Uppercse it")
? o1.Result()
#--> softanza
? @@( o1.Unresolved() )
#--> [ [ "Uppercse", "uppercase" ] ]
? o1.UnderstoodAll()
#--> 0

Le verbe mal orthographié n'est pas deviné. Unresolved() répond [ [ "Uppercse", "uppercase" ] ], le mot rencontré à côté du mot que la bibliothèque pense que vous vouliez, et UnderstoodAll() répond 0 : le programme admet qu'il n'a pas tout compris. C'est le mode permissif : un mot inconnu est sauté et signalé. Un agent d'IA reçoit le mode strict, qui refuse, et un monde, une liste déclarée d'opérations permises, peut limiter ses phrases à cette liste :

try
	NaturallyStrict("Create a string with 'x' Fooify it")
catch
	? cCatchError
done
#--> Strict natural mode: not understood: 'Fooify' (did you mean 'boxify'?)
try
	NaturallyStrictIn("en", "Create a list with [ 3, 1 ] Reverse it", [ "METHOD_REMOVEDUPLICATES" ])
catch
	? cCatchError
done
#--> Operation not permitted in this world: METHOD_REVERSE

Le mode strict refuse 'Fooify' et nomme tout de même le mot le plus proche : did you mean 'boxify'?. Dans ce monde, une phrase qui renverse une liste est refusée ! Le refus nomme l'opération : Operation not permitted in this world: METHOD_REVERSE.

L'autre direction du code naturel dans Softanza est la chaîne quasi naturelle, où la personne est l'analyseur et où la chaîne se lit comme une phrase. Quand elle répond non, dit-elle pourquoi ?

? IsQ().TheQ().LengthQ().OfQ("softanza").LessThanQ().TheQ().LengthQ().Of("Haro")
#--> 0
? Why()
#--> no: 8 is not less than 4

La chaîne a répondu 0, et Why() a donné la raison : no: 8 is not less than 4. Un verdict dit pourquoi.

Voici maintenant la loi à son plus tranchant : un modèle d'IA. La bibliothèque déclare la forme d'une réponse comme un schéma. Que devient un schéma qui nomme un type que la bibliothèque n'a pas ? Il est jugé quand il est déclaré, avant qu'aucun modèle soit appelé :

try
	StzOutputSchemaQ([ [ :field = "x", :type = :colour ] ])
catch
	? cCatchError
done
#--> stzOutputSchema: unknown field type 'colour' (use string|number|boolean|oneof|list|structure).

Le refus nomme le type inconnu, 'colour', et liste les six qu'il accepte : (use string|number|boolean|oneof|list|structure). Le schéma a été refusé avant qu'aucun modèle soit appelé ! Un schéma correct est un petit langage fermé. Le tribunal juge n'importe quelle réponse contre lui, quel qu'en soit l'auteur. Et le schéma émet sa grammaire, pour qu'un modèle puisse y être tenu pendant qu'il écrit :

StzOutputSchemaQ([
	[ :field = "name", :type = :string ],
	[ :field = "age",  :type = :number, :must = [ [ ">=", 0 ], [ "<=", 130 ] ] ],
	[ :field = "mood", :type = :oneof,  :choices = [ "positive", "negative" ] ]
]) {
	? Accepts("name: Hadiza" + nl + "age: 41" + nl + "mood: positive")
	#--> 1
	? Accepts("name: Hadiza" + nl + "age: 41" + nl + "mood: angry")
	#--> 0
	? Accepts("name: Hadiza" + nl + "age: 900000" + nl + "mood: positive")
	#--> 0
	? Accepts("name: Hadiza" + nl + "age: 62" + nl + "mood: positive")
	#--> 1
	? ToGBNF()
	#--> root ::= name-line age-line mood-line
	#    name-line ::= "name: " text "\n"
	#    age-line ::= "age: " number "\n"
	#    mood-line ::= "mood: " ("positive" | "negative") "\n"
	#    text ::= [^\n]+
	#    number ::= "-"? [0-9]+ ("." [0-9]+)?
	#    boolean ::= ("yes" | "no" | "true" | "false")
}

Regardez les quatre verdicts. La première réponse a imprimé 1. La deuxième, avec mood: angry, et la troisième, avec age: 900000, ont imprimé 0 : le tribunal les a refusées. La quatrième a imprimé 1 de nouveau. Hadiza a quarante et un ans dans la première réponse et soixante-deux dans la quatrième, et le tribunal accepte les deux ! Une grammaire tue les phrases mal formées, pas les phrases fausses. Le dossier le dit en cinq mots (dans l'original anglais) : structure tue l'informe, pas le faux. Ce livre dit la même chose : la vérité d'une réponse n'est pas l'affaire de la grammaire. Le dossier dit que la vérité demande la réversibilité, un auditeur et un Principal, la personne qui tranche. Une grammaire est la barrière, pas le juge de tout. La grammaire imprime aussi une règle boolean qu'aucun champ de ce schéma n'emploie.

Un gabarit est aussi un contrat. Une phrase avec un trou non rempli est refusée avant de tourner :

try
	NaturallyWith("Create a string with {#1} and {#2} it", [ "x" ])
catch
	? cCatchError
done
#--> Unfilled template hole! The narration still contains a {#n} slot with no value for it.

Et les motifs sont de petits langages à part entière, mais pas encore fermés : le chapitre 15 montre les classes de motifs acceptant sans se plaindre un mot qu'elles ne connaissent pas. La forme d'une liste est déclarée, pas écrite comme une boucle :

? Lx("[@N, @S]").Match([42, "hello"])
#--> 1
? Lx("[@N, @S]").Match(["hello", 42])
#--> 0
? Lx("[@N, [@N2], @N]").Match([1, [2, 3], 4])
#--> 1
? Lx("[@N, [@N2], @N]").Match([1, [2], 4])
#--> 0

Deux formes ont correspondu, deux non, et aucune boucle n'a été écrite.

Les chapitres de cette partie prouvent la loi de cinq côtés. Le chapitre 12 raconte un langage déclaré : la forge (la machinerie qui produit l'analyseur, le tribunal, l'imprimeur et la grammaire d'un langage à partir de sa seule déclaration), la grammaire fermée sans échappée vers l'hôte, et le tribunal né avec la grammaire. Il raconte aussi la grammaire émise pour qu'un modèle ne puisse dire que des phrases valides, et les parties qu'une déclaration produit. Le chapitre 13 raconte les deux directions du code naturel, la machine comme analyseur et la personne comme analyseur, dans une seule discipline. Le chapitre 14 raconte la programmation par la connaissance, un fichier qui est un système. Le chapitre 15 raconte les langages de motifs, l'expression régulière élevée aux listes, aux nombres, aux tables, aux matrices, au temps et aux graphes. Le chapitre 16 raconte les sept langages que Softanza atteint par une seule porte gouvernée, et pourquoi une porte n'est pas une facette.

5. Le tribunal

multilingual_pack_narrated prouve les langues comme données : les paquets, les programmes en français et en arabe, un paquet ajouté à l'exécution, et le programme qui se paraphrase dans sa propre langue. semantic_resolver_narrated prouve le mot inconnu avec sa suggestion, le mode strict, et la liste d'autorisation sous laquelle tout ce qui est hors liste est grammaticalement impossible. Son exécution n'atteint pas encore sa fin à ce commit. Je l'ai exécutée deux fois le 8 octobre 2026, pour le chapitre 13, et chaque fois elle s'est arrêtée sur une erreur levée par une fonction de découpage de chaîne, avant sa dernière assertion. La page compte donc ses assertions et ne revendique pas son verdict. literate_templates_narrated prouve qu'un gabarit est un contrat. question_narrated prouve qu'un verdict par oui ou non enregistre son pourquoi. structuredoutput_narrated prouve le tribunal de la sortie structurée, y compris le mensonge qu'il laisse passer. schema_grammar_narrated prouve le compilateur de grammaire, et constrained_decoding_narrated l'échantillonneur qui y tient un modèle.

Sept gardes prouvent la loi ; la section suivante dit où le terrain est en avance.

6. Le terrain, et où il mène

Le terrain mène en outils. Les ateliers de langage restent en avance sur les axes auxquels la conception du domaine de projets a délibérément renoncé : l'outillage projectionnel (des éditeurs qui comprennent un langage pendant que vous tapez), l'intégration aux IDE, la profondeur macro-théorique. L'étude du domaine de projets le dit dans ses propres mots : c'est un pari, et il est nommé comme tel.

Le terrain a construit le décodage contraint le premier. L'échantillonneur de Softanza suit l'algorithme de l'implémentation de référence et n'embarque rien. Mesurées sur un seul petit modèle de cent trente-cinq millions de paramètres, sur dix consignes, les réponses étaient valides du premier coup deux fois sur dix quand on les vérifiait après coup. Tenu à la grammaire, le modèle était valide dix fois sur dix. C'est un seul petit modèle et dix consignes, et rien dans le dossier n'en mesure un grand.

Et l'âge coupe dans les deux sens. Le code généré rend aussi bon marché la fabrication négligente de langages. C'est pourquoi le tribunal n'est pas un accessoire d'un langage déclaré. Il en est le cœur. C'est mon point de vue.

7. La limite

• construitle vocabulaire de la couche naturelle comme données en cinq langues, avec ses refus ; le tribunal de la sortie structurée, son compilateur de grammaire et son échantillonneur ; les langages de motifs, qui acceptent un mot qu'ils ne connaissent pas
• conçula forge qui produit l'analyseur, le tribunal et la grammaire d'un langage à partir de sa seule déclaration ; une grammaire émise pour chaque langage déclaré ; le style d'écriture comme grammaire déclarée
• absentune couche naturelle fermée jusqu'au fond : une forme de liste atteint encore le code de l'hôte ; des classes de motifs qui refusent un mot qu'elles ne connaissent pas ; la lettre ɗ du hausa standard dans le paquet hausa

Ce qui est construit : la couche naturelle, son vocabulaire comme données en cinq langues, l'anglais, le hausa, le français, l'arabe et le turc, et ses refus. Construits aussi : le tribunal de la sortie structurée avec son compilateur de grammaire et son échantillonneur, et les langages de motifs. Ceux-ci acceptent aujourd'hui un mot qu'ils ne connaissent pas ; les fermer est à venir.

Ce qui est conçu : la forge qui produirait, à partir de la seule déclaration d'un langage, son analyseur, son tribunal, son imprimeur (la partie qui réécrit une phrase) et sa grammaire pour un modèle. La forge est construite hors de la bibliothèque et conçue pour la bibliothèque : une première esquisse en a été construite hors de la bibliothèque en octobre 2026. La bibliothèque ne peut pas encore l'exécuter. Le texte de la vision dit que la forge n'a pas encore forgé (fabriqué les parties d'un langage à partir de sa déclaration). L'esquisse a depuis forgé des tribunaux et des grammaires pour plusieurs langages, jugés par les propres fixtures de ces langages, et la vision ne l'a pas rattrapée. Le chapitre 12 la raconte avec ses limites. Une grammaire pour chaque langage déclaré est conçue et à venir.

Ce qui est absent, et la loi l'énonce. La couche naturelle n'est pas fermée jusqu'au fond. Une forme, une liste écrite entre crochets, est encore remise à l'hôte pour être évaluée. Une fonction de l'hôte à l'intérieur des crochets s'exécute-t-elle ? Essayez-en une :

? @@( Naturally("Create a list with [ upper('x'), 1 ] and remove its duplicates").Result() )
#--> [ "X", 1 ]

La fonction upper n'est pas un mot du dictionnaire naturel, et la liste est revenue [ "X", 1 ]. Elle s'est exécutée quand même ! Le dossier connaît déjà cette échappée et a acheminé sa réparation. Tant que la réparation n'est pas arrivée, « la couche naturelle est un langage fermé » est vrai de ses mots et pas de ses listes, et ce livre le dira.

Et le paquet hausa ne lit pas encore la lettre ɗ, qu'emploie l'orthographe standard du hausa. Le paquet la stocke dans un encodage qui ne la porte pas encore. Quand je l'ai sondé le 8 octobre 2026 sur l'instantané précédant ce commit, une phrase écrite avec cette lettre n'était pas lue, et le paquet ne le signalait pas. Le hausa de ce chapitre est écrit sans le crochet, comme le paquet le lit aujourd'hui. Le dossier ne tient aucune lecture des phrases du paquet par un locuteur du hausa. Les phrases en langue étrangère imprimées dans ce chapitre viennent de la narration et des gardes de la bibliothèque, ou sont composées à partir de son vocabulaire. Aucun locuteur natif ne les a lues pour autant que le dossier le montre.

Voilà les limites ; la section suivante ouvre six portes sur elles.

8. Six portes

9. Exercice

Déclarez, avec StzOutputSchemaQ, un enregistrement de trois champs tiré d'un domaine que vous connaissez : une demande de prêt, par exemple, avec un montant dans une fourchette, une devise tirée d'une liste fermée, et un objet en texte libre. Avant de rien exécuter, écrivez trois réponses qu'un modèle d'IA pourrait donner : une que le tribunal doit accepter, une qu'il doit refuser à cause de sa forme, et une qu'il acceptera bien qu'elle soit fausse. Sous chacune, écrivez votre prédiction comme une promesse.

Exécutez-le. La troisième réponse est la leçon de ce chapitre. Écrivez, en une phrase, qui dans votre domaine doit la juger, puisque la grammaire ne le peut pas.

Je vous laisse celui-ci. La section 7 dit qu'une liste écrite entre crochets est encore remise à l'hôte, et la section 4 dit pourquoi un langage doit refuser toute forme qui atteint le code de l'hôte. Exécutez le bloc de la section 7 avec un seul changement, une autre fonction de l'hôte à l'intérieur des crochets :

? @@( Naturally("Create a list with [ lower('X'), 1 ] and remove its duplicates").Result() )

Regardez ce que la bibliothèque fait de la fonction, et dites en une phrase ce qu'aurait fait une couche naturelle fermée. Quand vous l'aurez fait, vous saurez pourquoi « la couche naturelle est un langage fermé » est vrai de ses mots et pas encore de ses listes.

Le chapitre 12 est Un langage, déclaré. Son principe : déclarer un langage est aussi facile que déclarer une variable.

Un langage, déclaré

Exécuté le 2026-10-15 12:59 UTC+01:00 dans la bibliothèque au commit 93d7a39bd : 8 bloc(s) sur 8 ont tenu leur promesse.

Les blocs ont été exécutés par le runtime de l'ancien langage hôte, version 1.27 ; Haro n'exécute pas encore la bibliothèque. Les binaires du moteur ont été construits dans une copie de ce commit, le plus récent le 2026-10-05 20:27 UTC+01:00 ; 1 changement(s) du moteur commité(s) après cette construction n'y sont pas.

Dans ce chapitre, je prends une seule déclaration de la commande d'un restaurant et je la donne à trois lecteurs : une personne, un modèle d'IA et le tribunal. Je laisse la même déclaration produire une grammaire, et je montre où la grammaire et le tribunal s'accordent et où ils se séparent. Puis je quitte la bibliothèque pour la forge. C'est la machinerie qui transforme la seule déclaration d'un langage en son tribunal et sa grammaire, et je dis ce qu'elle a forgé et ce qu'elle n'a pas forgé. J'ai décidé que Haro est la langue des langues, et j'ai refusé une forme d'échappatoire ouverte. Le principe est une règle de Haro : déclarer un langage est aussi facile que déclarer une variable.

1. Le concept, tel que le terrain le tient

Deux familles d'outils permettent de déclarer un langage sur le terrain. La première est l'atelier de langages et le générateur d'analyseurs : JetBrains MPS, Xtext, Spoofax, et le #lang de Racket vous donnent de quoi définir un langage avec sa grammaire, son éditeur et ses vérifications. L'étude de terrain du domaine de projets lui-même, d'août 2026, dit pourquoi ils n'ont pas gagné. Ils dépendaient d'un écosystème, et les langages de Racket vivent et meurent à l'intérieur de Racket.

La seconde est le DSL interne : une bibliothèque dont les appels se lisent comme des phrases, alors que le fichier peut encore contenir n'importe quel code hôte. La même étude a la phrase que je retiens : la fermeture est le produit, et un DSL interne qui ne peut pas refuser du code hôte arbitraire est une API qui porte le costume d'un langage. Son groupe témoin, ce sont les langages fermés qui ont gagné : SQL, regex, Make, HTML et CSS, HCL, GraphQL, Markdown, CUE.

Pour la grammaire qu'un modèle doit respecter, le dossier nomme un seul outil : l'échantillonneur de grammaire d'une bibliothèque d'inférence locale bien connue, que la machine de la bibliothèque suit pour son encodage des éléments et son algorithme. Rien n'en est repris. C'est une connaissance générale, pas une étude du dossier, que les fournisseurs de modèles proposent des modes de sortie structurée qui prennent un schéma JSON, et que des bibliothèques ouvertes transforment un schéma ou une expression régulière en masque sur les jetons du modèle.

Le chapitre 11 a dit ce qu'est un langage fermé, et ce qui a été perdu quand le terrain l'a laissé ouvert. Je le tiens pour acquis. Ce chapitre dit ce qui est nouveau : ce qui produit un langage fermé.

2. Le premier principe

Déclarer un langage est aussi facile que déclarer une variable.

C'est l'intitulé d'une règle de Haro, tranchée le 1er octobre 2026, et le noyau de la vision dit la même chose : l'époque rend la déclaration d'un langage aussi facile que celle d'une variable. L'autre moitié du chapitre a sa phrase, tirée de la doctrine de totalité de l'alphabet, ratifiée le 27 septembre : la malformation meurt à l'échantillonneur, la fausseté meurt au tribunal, et la non-terminaison est inexprimable.

Et celle que je dois porter à côté de chaque gain, tirée du contrat de la bibliothèque pour la sortie structurée : la structure tue la malformation, et non la fausseté.

3. La forme Softanza

Prenons une déclaration de ce à quoi doit ressembler la commande d'un restaurant. Elle a trois champs : un plat pris dans un menu fermé, une quantité entre 1 et 12, et une note facultative. Un seul texte est lu par trois lecteurs. Une personne lit une description. Un modèle lit une clause pour son prompt. Et le tribunal lit le même texte et juge une réponse. Que répond-il à un plat nommé pizza et à quarante portions ? Exécutez-le :

oO = StzOutputSchemaQ([
	[ :field = "dish",     :type = :oneof,  :choices = [ "margherita", "tiramisu" ] ],
	[ :field = "quantity", :type = :number, :must = [ [ ">=", 1 ], [ "<=", 12 ] ] ],
	[ :field = "note",     :type = :string, :optional = 1 ]
])
oO {
	? Describe()
	#--> schema 'output' -- 3 field(s)
	#      dish : oneof (margherita | tiramisu) [required]
	#      quantity : number [required], must be at least '1', must be at most '12'
	#      note : string [optional]
	? PromptClause()
	#--> Answer with ONLY this structure, one field per line, nothing before it and nothing after it:
	#
	#    dish: <one of: margherita | tiramisu>
	#    quantity: <number>
	#    note: <text>
	aV = Verify([ :dish = "pizza", :quantity = 40 ])
	? aV[:ok]
	#--> 0
	? aV[:findings][1][:message]
	#--> field 'dish' is a closed enumeration (margherita | tiramisu) and the model answered 'pizza'.
	? aV[:findings][2][:message]
	#--> field 'quantity' must be at most '12', and the model answered '40'.
}

Le tribunal répond dans les mots de la déclaration : field 'dish' is a closed enumeration (margherita | tiramisu) and the model answered 'pizza'. Maintenant la même déclaration produit une grammaire. Le tribunal et la grammaire naissent d'un seul texte, et ils s'accordent sur la forme. Ils se séparent sur une valeur. Quarante portions ont la bonne forme : lequel des deux les laisse passer, et la bibliothèque dit-elle ce que la grammaire a laissé tomber ? Exécutez-le :

cG = oO.ToGBNF()
cGood  = "dish: margherita" + nl + "quantity: 2" + nl + "note: no basil" + nl
cBand  = "dish: margherita" + nl + "quantity: 40" + nl + "note: no basil" + nl
cShape = "dish: margherita" + nl + "quantity: many" + nl + "note: no basil" + nl
? StzGrammarAccepts(cG, cGood)
#--> 1
? oO.Accepts(cGood)
#--> 1
? StzGrammarAccepts(cG, cBand)
#--> 1
? oO.Accepts(cBand)
#--> 0
? StzGrammarAccepts(cG, cShape)
#--> 0
? oO.Accepts(cShape)
#--> 0
? len(StzFind("lessequal", oO.UnenforcedByGrammar())) > 0
#--> 1

La deuxième paire est l'enjeu du chapitre : la grammaire répond 1 et le tribunal répond 0 ! Je n'imprime pas la liste de ce que la grammaire a laissé tomber : son texte porte, à un endroit, l'ancien nom du tribunal, et ce nom appartient à l'histoire de l'annexe H. Je vérifie que la liste nomme la borne de l'intervalle.

On ne demande pas au modèle d'IA d'être prudent. L'échantillonneur demande à la grammaire, à chaque jeton candidat, si elle pourrait continuer. Ainsi un mot qui n'est pas au menu n'est pas refusé après avoir été dit. Peut-il seulement commencer ?

? StzGrammarCouldContinue(cG, "dish: t")
#--> 1
? StzGrammarCouldContinue(cG, "dish: p")
#--> 0
? StzGrammarCouldContinue(cG, "dish: margherita" + nl + "quantity: 2")
#--> 1
? StzGrammarCouldContinue(cG, "dish: margherita" + nl + "quantity: <")
#--> 0

Il ne le peut pas : dish: p répond 0. La dernière ligne est un échec que la mesure de la section 5 a trouvé dans un petit modèle : le substitut <number> répété là où doit se trouver un nombre. Et un jeton n'est pas un octet. Un morceau peut être valide comme préfixe et invalide comme complétion, et la machine reçoit le morceau entier. Que répond-elle à yesterday, qui commence comme yes ?

cY = 'root ::= "yes" "\n"'
? StzGrammarCouldContinue(cY, "y")
#--> 1
? StzGrammarCouldContinue(cY, "ye")
#--> 1
? StzGrammarCouldContinue(cY, "yesterday")
#--> 0

y et ye répondent 1, et yesterday répond 0 !

Ce que la machine ne tiendra pas, elle le refuse en le nommant. Un langage fermé refuse ce qu'il ne peut pas porter, et n'approxime jamais. Une règle récursive à gauche est refusée par un code, de même qu'une règle citée et jamais définie. Une structure imbriquée est refusée par la grammaire. Le tribunal la lit-il quand même ?

? left(StzGrammarRefusal('root ::= tail' + nl + 'tail ::= tail "x" | "x"'), 7)
#--> GBNF-M7
? left(StzGrammarRefusal('root ::= greeting'), 7)
#--> GBNF-M4
? StzGrammarRefusal(cG) = ""
#--> 1
StzOutputSchemaQ([
	[ :field = "title",  :type = :string ],
	[ :field = "author", :type = :structure, :fields = [ [ :field = "name", :type = :string ] ] ]
]) {
	? IsExpressibleAsGrammar()
	#--> 0
	try
		ToGBNF()
	catch
		? len(StzFind("GBNF-F5", cCatchError)) > 0
	done
	#--> 1
	? ParseOutput('{ "title":"T", "author":{"name":"Ada"} }')[:ok]
	#--> 1
}

Le texte du refus de la structure imbriquée porte lui aussi l'ancien nom du tribunal, donc je n'imprime que les codes. La dernière ligne est l'enjeu : le tribunal lit ce que la grammaire refuse d'écrire.

Le langage de déclaration est lui-même fermé. Une faute de frappe dans la loi est refusée au moment où la loi est déclarée. Le contrat de la bibliothèque dit pourquoi. Une clé comme :requird = 0 laisserait un champ obligatoire sans un mot, et c'est la classe de faute de frappe qu'un tribunal ne doit pas tolérer dans sa propre loi. Que répond le tribunal à une telle clé ?

try
	StzOutputSchemaQ([ [ :field = "x", :type = :string, :requird = 0 ] ])
catch
	? cCatchError
done
#--> stzOutputSchema: unknown key ':requird' in field #1 (use :field, :name, :type, :required, :optional, :choices, :oneof, :of, :fields, :must, :note, :description).

La faute de frappe a été refusée sur-le-champ, et le message liste les clés permises !

Et une fonction hôte n'est pas un mot du langage fermé des conditions. Il y a deux façons de dire une condition, le langage fermé et la porte d'une fonction. Une racine carrée est un mot du langage d'expressions du moteur, et un sinus n'en est pas un. Que répond la forme textuelle au sinus, et que répond la forme fonction, qui exécute du code hôte ?

StzListQ([ 4, 7, 10, 3, 8 ]) {
	? @@( FindW('{ sqrt(@item) < 3 }') )
	#--> [ 1, 2, 4, 5 ]
	? @@( FindW('{ sin(@item) < 2 }') )
	#--> [ ]
	? @@( FindWF( func x { return sin(x) < 2 } ) )
	#--> [ 1, 2, 3, 4, 5 ]
}

Ce que j'ai vu, et que la narration ne dit pas : le refus est silencieux et entier. La forme textuelle a imprimé [ ] et la forme fonction a imprimé [ 1, 2, 3, 4, 5 ] : rien de l'une, tout de l'autre. Une condition dont la branche gauche est vraie et dont la droite porte un sinus a imprimé [ ]. Une condition qui appelle une fonction de moi ne l'a jamais appelée. Une erreur de syntaxe a aussi imprimé [ ]. Le langage est fermé, et il refuse sans un mot. La couche naturelle du chapitre 11 dit pourquoi elle refuse, et celle-ci ne le dit pas.

La forge, hors de la bibliothèque

Un langage déclaré une fois devrait donner son tribunal, sa bouche, sa voix et ses lecteurs. C'est la forge, et c'est là que l'étude de ce livre rencontre sa propre limite : la forge n'est pas dans la bibliothèque.

Je dirai ce que le dossier contient, et ce que j'ai observé le 8 octobre 2026 sur le runtime plus ancien, l'oracle. Le dossier est une charte et un spike dans un autre dépôt, en pur code du noyau qui tourne sur l'oracle. La forge lit une déclaration et écrit deux fichiers, un programme de tribunal et une grammaire. Les échelons du spike, entre le 1er et le 4 octobre 2026, ont forgé des tribunaux et des grammaires pour le langage machine du domaine de projets et pour un langage de flotte déclaré par-dessus. Ils ont fait de même pour le langage d'expressions et pour quatre lettres de plus de l'alphabet, la famille de langages déclarés de la vision, chacun connu par une lettre. Chacun a été jugé sur les cas propres du langage préexistant. Ces cas étaient sans adaptation pour le langage d'expressions (W) et pour Z, réexprimés pour F et A, et, pour Q, les réponses propres de l'ancien langage, relevées. Dans l'ordre : 117 sur 120 pour le langage machine, les trois restants étant les sortes du fichier de flotte. Puis 32 sur 32 pour le langage de flotte, 29 sur 29 pour W, 16 sur 16 pour Z, 25 sur 25 pour Q, 26 sur 26 pour F et 35 sur 35 pour A. C'est la méthode du chapitre 3, déclarer puis gouverner, appliquée à la forge elle-même.

J'ai fait tourner la forge sur un petit langage que j'ai écrit pour ce livre, la commande d'une table dans les mots de la salle à manger. C'est un exemple, écrit pour le livre et exécuté une fois, hors de la bibliothèque :

DEFINE LANGUAGE order AS ( VERSION "0.2", GRAMMAR "0.2", COURT "none", EXTENSION ".order" )
  RATIONALE "A table's order, in the words of the dining room"
DEFINE MENU dishes AS ( WORDS [margherita, tiramisu, chianti],
  MESSAGE "the kitchen cooks margherita, tiramisu or chianti" ) RATIONALE "The kitchen's closed menu"
DEFINE RANGE portions AS ( MIN 1, MAX 12,
  MESSAGE "{value} portions is not an order: one to twelve" ) RATIONALE "A table orders between one and twelve"
DEFINE DECLARATION line AS ( VERB "ORDER", SEATS [dish: dishes, quantity: portions, note: text?] )
  RATIONALE "One line of an order: what, how many, and a word for the kitchen"
DEFINE REFUSAL unknown_verb AS ( MESSAGE "The dining room speaks only of orders." )
  RATIONALE "The closure speaks when an alien verb arrives"

La forge a imprimé qu'elle avait forgé une sorte et un refus, en une fraction de seconde d'horloge, et a écrit un tribunal d'environ 2,6 kilooctets. Que répond ce tribunal à un plat hors du menu, à quarante portions et à un verbe étranger ? Il a refusé les trois, dans les mots propres de la déclaration :

DISH pizza          ->  order (line 2): the kitchen cooks margherita, tiramisu or chianti, not 'pizza'
QUANTITY 40         ->  order (line 3): 40 portions is not an order: one to twelve
DROP TABLE orders   ->  order (line 1): Unknown verb 'DROP': The dining room speaks only of orders.

Les refus sont les mots propres de la déclaration, écrits à côté de la grammaire. Même DROP TABLE orders a été refusé dans les mots de la salle à manger ! C'est toute la preuve du langage order : il a été exécuté une fois, hors de la bibliothèque, et ce n'est pas une déclaration du dossier.

Trois observations de plus, chacune une limite.

Le méta-tribunal refuse l'échappatoire. La déclaration du langage des déclarations liste les opérateurs et les opérandes qu'elle peut employer. Une déclaration qui listait eval parmi ses opérateurs, dans une fixture épinglée le 29 août 2026, a été refusée : eval n'est pas dans le menu fermé des opérateurs, une échappatoire est inexprimable, non interdite. Un appel hôte parmi les opérandes a été refusé de la même façon.

La grammaire de la forge ne tient que la forme. Un siège de menu ressort comme un identifiant général, donc la grammaire forgée laisse passer pizza. Le compilateur de schémas de la bibliothèque, dans les blocs ci-dessus, ferme le même menu en une alternance. Sur le langage machine du domaine de projets, la grammaire forgée accepte une référence pendante que le tribunal refuse. Le dossier nomme une différence entre la bouche et le tribunal, la part qu'une grammaire hors contexte ne peut pas dire : les noms en double, les références pendantes. Je n'ai trouvé aucun enregistrement qui énonce le manque du menu comme un manque.

La vision n'a pas rattrapé. Le texte de la vision, daté entre le 27 septembre et le 5 octobre 2026, dit que la forge n'a pas forgé. Le fichier des principes, daté du 1er octobre 2026, dit que la forge n'existe pas. Le même dépôt a construit le spike le même jour et forgé pour plusieurs langages. La phrase vraie a donc deux côtés. La forge a forgé des tribunaux et des grammaires pour plusieurs langages, hors de la bibliothèque, et elle n'a pas forgé la liste complète que le principe promet. Et le texte de la vision n'a pas été mis à jour. Dans les mots d'étape du livre, la forge est construite hors de la bibliothèque et conçue pour la bibliothèque, et la limite du chapitre 11 le dit de même.

Les parties d'un langage déclaré

La charte liste ce que la forge produit à partir d'une déclaration, ses parties, et je donne à chacune un mot d'étape :

Le mot facette a deux sens dans ce livre, et je définis ici celui de cette partie. Une facette est une seconde syntaxe de Haro, pour un programmeur d'un autre langage : une autre graphie de la grammaire unique, et jamais un runtime. C'est la dernière ligne du tableau, et le chapitre 16 la raconte. L'autre sens est un onglet du ruban de l'environnement, une phase d'une vie, celui du chapitre 26.

5. Le tribunal

structuredoutput_narrated prouve qu'une déclaration est jugée quand elle est déclarée, avec un type inconnu, une clé inconnue et un menu vide refusés. Elle prouve que deux formes de transmission sont lues et que rien n'est deviné, qu'il n'y a pas de crédit partiel, que l'imbrication fonctionne, et qu'une nouvelle tentative tient dans un seul budget. Dans sa dixième scène, elle prouve qu'un mensonge est laissé passer exprès. schema_grammar_narrated prouve que la déclaration se compile en grammaire, et qu'une énumération fermée devient une alternance fermée. Elle prouve que l'optionnel et l'arité des listes sont traités, que les contraintes non imposées sont listées par champ et par opérateur, et qu'une structure imbriquée est refusée avec un code nommé. constrained_decoding_narrated prouve que la machine parcourt une grammaire octet par octet, qu'un préfixe n'est pas un tout, et que yesterday est refusé. Elle prouve que le substitut écrit par le modèle ne peut pas être atteint, que les refus sont nommés, que la structure n'est pas la vérité, et qu'une grammaire sur une session en flux est refusée. Ses deux scènes qui demandent un modèle génératif le disent. 483_w_and_wf_forms_in_conditional_code prouve que les deux formes d'une condition donnent les mêmes positions. Elle n'affirme pas le refus du langage fermé, et aucune garde ne l'affirme.

Aucune garde de la bibliothèque ne teste une forge, puisqu'il n'y en a pas. La garde de la forge est à l'extérieur : le spike passe vingt-trois étapes en 367,5 secondes le 4 octobre 2026, d'après son propre fichier. Je ne l'ai pas lancé. Et la première exécution du méta-tribunal lui-même fut de vingt-huit sur vingt-huit le 29 août 2026. Le lecteur de gardes du livre ne résout que les gardes de l'arbre de tests de la bibliothèque, donc celles-ci ne peuvent pas être nommées dans le front matter.

Le premier essai est valide dans deux cas sur dix quand on vérifie après coup, et dans dix sur dix quand il est contraint. Ce chiffre est un nombre dans un commentaire de ces gardes. On ne peut pas le reprendre ici : les scènes réelles demandent un fichier de modèle génératif, et l'instantané ne contient, dans son dossier des modèles, qu'un fichier de somme de contrôle. Le chapitre 11 porte le chiffre, et j'y renvoie.

6. Le terrain, et où il mène

Les ateliers de langages mènent sur l'outillage. L'étude de terrain le dit elle-même : ils restent supérieurs sur les axes que la conception abandonne délibérément, l'outillage projectionnel, l'intégration à l'éditeur et la profondeur des macros. Et le pari que ces axes sont les mauvais est nommé comme un pari.

Le code généré rend bon marché aussi la fabrication indisciplinée de langages, et c'est pourquoi le tribunal est le cœur et non un accessoire.

Le décodage contraint : le terrain l'a construit le premier, et l'implémentation de référence est celle d'une autre bibliothèque. Ce que le dossier ajoute, c'est l'appariement : une grammaire et un tribunal issus d'une seule déclaration, et la liste de ce que la grammaire a laissé tomber.

Une grammaire sur-approxime un tribunal. Les noms en double, les références pendantes et la cohérence d'un menu ne sont pas hors contexte. Je l'ai observé dans les deux sens plus haut : une plage que la grammaire ne peut pas porter, et une référence qu'elle ne peut pas porter.

Le code qu'une forge émet doit être lu par quelqu'un. Le style de famille dont hérite chaque langage déclaré a un test de réussite : apprendre le deuxième langage devrait prendre une soirée, parce que c'est le premier langage avec d'autres verbes. C'est une exigence de conception et non une mesure. Aucun apprenant n'a été chronométré dans le dossier que j'ai lu.

La limite vient ensuite, au bord d'un second langage fermé.

7. La limite

• construitdans la bibliothèque : une déclaration jugée au moment où elle est déclarée ; un tribunal et une grammaire issus d'une seule déclaration, avec la liste de ce que la grammaire a laissé tomber ; une machine à grammaire qui parcourt les octets et refuse en nommant ; une description pour une personne et un prompt pour un modèle d'IA à partir du même texte. Hors de la bibliothèque : une forge qui transforme une déclaration en tribunal et en grammaire, exécutée sur les propres langages du domaine de projets
• conçula forge à l'intérieur de la bibliothèque ; sa liste complète de produits issus d'une seule déclaration (imprimeur, graphe de connaissance, porte naturelle, narration, runtime, un seul binaire statique) ; les projections d'un langage vers une application
• absentla grammaire de la forge pour un mot de menu ; une garde qui affirme le refus d'une fonction hôte dans une condition ; le chiffre deux sur dix contre dix sur dix, qui demande un fichier de modèle que l'instantané ne contient pas

La bibliothèque a deux langages de formules fermés, et ils se comportent différemment au bord. Un lecteur qui croit que le langage fermé des conditions, celui du chapitre 11 et de la condition ci-dessus, couvre toutes les formules se trompera à table. La colonne calculée d'un tableau retombe, d'après son propre en-tête, sur le chemin d'évaluation classique quand le moteur ne peut pas compiler une formule. Le mot sin que la condition a refusé s'exécute-t-il ici ?

o1 = new stzTableAggregator([
	[ :A, [ 0, 1, 4 ] ],
	[ :B, [ 2, 4, 20 ] ]
])
o1.AddCalculatedCol(:SINE, 'sin(@(:A))')
? @@( o1.Col(:SINE) )
#--> [ 0, 0.84, -0.76 ]

Le sinus que la condition a refusé, le tableau l'a calculé, et il a imprimé [ 0, 0.84, -0.76 ] ! J'ai aussi vu, et je ne le montre pas, une seconde chose. Sur une autre table d'essai, avec A égal à 1, 3 et 10 et B égal à 2, 4 et 20, j'ai écrit une formule @(:A) + HostBonus(@(:B)). La fonction de moi qui s'y trouve multiplie par mille. La formule a imprimé [ 2001, 4003, 20010 ] : une fonction hôte définie par l'utilisateur s'est exécutée de l'intérieur d'une chaîne de formule. Et une formule qui nomme une fonction qui n'existe pas a levé l'erreur propre de l'hôte. Le second langage fermé est donc ouvert à son bord. Aucune garde n'affirme l'un ou l'autre comportement.

Ce qui est construit : dans la bibliothèque, une déclaration jugée quand elle est déclarée ; un tribunal et une grammaire issus d'elle ; la liste de ce que la grammaire a laissé tomber. Une machine à grammaire qui dit qu'elle est contrainte ; un prompt et une description issus du même texte. Le build compte 151 assertions dans trois gardes narrées. Deux petits langages fermés de conditions, avec des limites. Les langues de la couche naturelle comme données.

Ce qui est construit, mais hors de la bibliothèque : une forge d'une déclaration vers un tribunal et une grammaire, dans le dépôt de la charte de Haro.

Ce qui est conçu : la forge qui produit, à partir d'une seule déclaration, l'analyseur, le tribunal, l'imprimeur, la grammaire, le graphe de connaissance, la grammaire de requête, la porte naturelle, la narration, le runtime et un binaire statique. D'après ma lecture de la charte, le spike a montré le tribunal, la grammaire, un runtime qui parcourt la déclaration, une grammaire de requête, une narration et le tribunal de la lettre naturelle. Je n'ai pas trouvé montré un imprimeur pour les phrases déclarées, un graphe de connaissance forgé à partir d'une déclaration, ni le binaire statique unique par langage. La bibliothèque qui a une forge : rien en elle ne déclare ni ne forge un langage. Une grammaire pour chaque langage déclaré livrée dans la bibliothèque : promise dans le noyau, non livrée. Et les projections : le monde rendu à une application, un serveur, une page, un appareil.

Ce qui est absent : la grammaire de la forge pour un mot de menu, que j'ai vue ne tenir que la forme, plus haut, et le chiffre de deux sur dix contre dix sur dix, repris. Et tout enregistrement que la forge tourne sur le runtime de Haro. Au moment où la vision a été écrite, le langage n'existait pas ; les exécutions de la charte sont sur le runtime plus ancien et sur l'oracle.

Les six portes suivent, du programmeur à l'agent.

8. Six portes

9. Exercice

Écrivez, à la main, une grammaire pour une ligne de commande de déjeuner : dish: puis l'un de deux plats de votre choix, puis un saut de ligne. Avant de rien exécuter, écrivez vos prédictions comme des promesses :

cG = 'root ::= ...'     # your grammar here
? StzGrammarAccepts(cG, "dish: <your first dish>" + nl)
#--> ?
? StzGrammarAccepts(cG, "dish: <a dish not on your menu>" + nl)
#--> ?
? StzGrammarCouldContinue(cG, "dish: <the first letters of your first dish>")
#--> ?
? StzGrammarAccepts(cG, "dish: <the first letters of your first dish>")
#--> ?
? StzGrammarRefusal(cG) = ""
#--> ?

Ajoutez ensuite un nombre à la ligne, quantity: et des chiffres, et écrivez une sixième prédiction : votre grammaire accepte-t-elle quantity: 4000 ? Exécutez-la. La leçon est la troisième, la quatrième et la sixième. La machine sait déjà qu'un préfixe pourrait continuer et n'est pas encore une phrase, et elle ne peut pas savoir que le nombre est trop grand. Notez, en une phrase, qui dans votre restaurant doit refuser quarante portions, puisque la grammaire ne le peut pas.

Je vous laisse celui-ci. La section 3 termine sa série de conditions sur un refus sans un mot, et la section 4 dit pourquoi le calcul reste hors de la surface qui déclare. Prenez les deux lignes qui posent à la liste la même question sous les deux formes, et changez une seule chose : écrivez un autre nombre à la place du 2, le même dans les deux lignes. Je n'imprime rien dessous.

o = new stzList([ 4, 7, 10, 3, 8 ])
? @@( o.FindW('{ sin(@item) < 2 }') )
? @@( o.FindWF( func x { return sin(x) < 2 } ) )

Exécutez-les pour plusieurs nombres. Cherchez un nombre pour lequel les deux formes impriment la même chose, et dites si l'impression seule vous apprend laquelle des deux a refusé et laquelle a répondu. Quand vous l'aurez fait, vous saurez ce que coûte un langage fermé qui refuse sans un mot.

Le chapitre suivant passe à la phrase naturelle, dans deux directions et sous une seule discipline. Une phrase s'exécute parce que chacun de ses mots est dans un dictionnaire que la bibliothèque possède, et ce que la bibliothèque ne connaît pas, elle le refuse, avec la raison.

Naturel, et exécutable : deux directions, une seule discipline

Exécuté le 2026-10-15 12:59 UTC+01:00 dans la bibliothèque au commit 93d7a39bd : 17 bloc(s) sur 17 ont tenu leur promesse.

Les blocs ont été exécutés par le runtime de l'ancien langage hôte, version 1.27 ; Haro n'exécute pas encore la bibliothèque. Les binaires du moteur ont été construits dans une copie de ce commit, le plus récent le 2026-10-05 20:27 UTC+01:00 ; 1 changement(s) du moteur commité(s) après cette construction n'y sont pas.

Dans ce chapitre, je fais tourner les deux directions du langage naturel dans la bibliothèque : la chaîne, où vous êtes l'analyseur, et la phrase, où c'est la bibliothèque. J'imprime les refus des deux côtés, cinq paquets de langue comme données et un sixième ajouté à l'exécution, et le compte de ce que chaque paquet sait dire. Je dis ce que j'ai refusé, les marqueurs de référence et la chaîne non grammaticale entre autres, et où le tribunal propre du dictionnaire échoue à ce commit. Le principe tient en une phrase. Une phrase s'exécute parce que chacun de ses mots est dans un dictionnaire que la bibliothèque possède, et ce que la bibliothèque ne connaît pas, elle le refuse, avec la raison.

1. Le concept, tel que le terrain le tient

Dans le langage courant du terrain, « programmer en langage naturel » veut dire une seule chose : demander du code à un modèle d'IA, ou lui demander de faire la tâche, dans un prompt. Les outils sont des assistants de discussion et des compléteurs de code, d'un usage large depuis 2021 environ. Ce sur quoi la phrase s'exécute, c'est la conjecture du modèle. La même phrase peut donner un code différent d'un jour à l'autre, le modèle a besoin d'un réseau ou d'un runtime local, et une personne lit le résultat pour savoir ce qui a été compris. Le chapitre 11 l'a dit, et j'y renvoie.

Des pratiques plus anciennes existent, et le dossier les nomme. Inform 7, un langage dont les programmes sont des phrases anglaises, compilées d'un bloc, avec un modèle du monde et un moyen de dire il d'une phrase à l'autre. AppleScript, proche de l'anglais et difficile à écrire, parce que sa naturalité était en surface et non dans un modèle sémantique. Les langages naturels contrôlés, dont le dispositif le plus fort, dit le commentaire de la bibliothèque elle-même, est de montrer ce qui peut être dit ensuite. Une lecture de session du 30 août 2026 est qu'Inform 7 est un compilateur de texte entier avec contexte référentiel, et non un répartiteur de commandes. Les dates sont une connaissance générale, pas une étude du dossier.

Aucun d'eux n'est ce que le dossier revendique. La revendication est le contraire du prompt : une phrase s'exécute parce que chacun de ses mots est dans un lexique fermé, défini comme données, associé à un verbe que la bibliothèque documente. Tout le reste est refusé avec la raison. Et elle a deux directions, que la revue de conception de la bibliothèque met en tableau. Dans la première, la machine est l'analyseur. Dans la seconde, c'est l'humain.

2. Le premier principe

Une phrase s'exécute parce que chacun de ses mots est dans un dictionnaire que la bibliothèque possède. Ce que la bibliothèque ne connaît pas, elle le refuse, avec la raison.

Mon étude du dossier, et le chapeau de la page du site du 8 octobre 2026, le disent. Pour la seconde direction, la thèse de la revue de conception : dans le langage quasi naturel, l'humain est l'analyseur. Et la devise plus ancienne, que le chapitre 5 porte : ce que vous pensez est ce que vous écrivez.

3. La forme Softanza

Je commence par la seconde direction, parce qu'elle est la plus ancienne.

L'humain est l'analyseur

Une chaîne quasi naturelle est une phrase dont chaque maillon est un vrai appel. La phrase est « le mot haro est un mot latin en minuscules, d'une longueur de 4 lettres et avec seulement 2 voyelles ». Quand elle est fausse, que dit la chaîne ? Exécutez-la :

? TheWordQ("haro").IsAQ([ :Lowercase, :Latin, :Word ]).WithQ().ALengthQ().OfQ(4).UnitQ(:Letters).AndQ().OnlyQ(2).VowelNB()
#--> TRUE
? TheWordQ("haro").IsAQ([ :Lowercase, :Latin, :Word ]).WithQ().ALengthQ().OfQ(4).UnitQ(:Letters).AndQ().OnlyQ(1).VowelNB()
#--> FALSE
? Why()
#--> no: expected exactly 1, found 2

La chaîne répond no: expected exactly 1, found 2. Les mots de degré sont des dispositifs, et la raison est conservée. Le bloc la lit avec le Why() de la console ; la chaîne garde aussi le sien, WhyCheckFailed(), que je n'appelle pas ici :

? Q("AnnIE").AtLeast(2).VowelNB()
#--> TRUE
? Q("AnnIE").AtMost(2).VowelNB()
#--> FALSE
? Why()
#--> no: expected atmost 2, found 3

La chaîne refuse ce que son sujet ne peut pas faire. Elle parle le même lexique que la direction de la machine : un mot français fonctionne dans une chaîne. Et un mot mal orthographié est refusé avec le mot le plus proche. C'est « un lexique, deux directions » en trois lignes :

try
	Q(5).VowelNB()
catch
	? cCatchError
done
#--> NNL: a stznumber cannot count 'numberofvowels' -- and neither can the chain subject.
? Q("haro").IsAQ(:String).IfSoQ("majuscule").Content()
#--> HARO
try
	Q("haro").IsAQ(:String).IfSo("uppercse")
catch
	? cCatchError
done
#--> NNL: this stzstring does not understand 'uppercse'. Did you mean 'uppercase'?

Une chaîne se ramifie sur sa propre vérité, et un ordinal est un mot :

? Q("haro").IsAQ(:String).IfSoQ(:Uppercase).OtherwiseQ(:Reverse).Content()
#--> HARO
? Q("hello").IsAQ(:Number).IfSoQ(:Reverse).OtherwiseQ(:Uppercase).Content()
#--> HELLO
? Q("hello brave world").TheNth(2, :Words)
#--> brave

Les questions fonctionnent de la même manière. Un mot de force, le premier mot de la question (What, HowMany et Is dans le bloc ci-dessous), ouvre un cadre, un mot et une méthode. Une question de confirmation se termine par « or not ». Que garde la session quand l'une répond oui et l'autre non ? Elle garde chaque réponse et les replie, comme une narration :

? @@( WhatQ().TheQ().VowelsQ().OfQ("AnnIE").Is() )
#--> [ "A", "I", "E" ]
? HowManyQ().WordsQ().Of("hello brave world")
#--> 3
ClearAnswers()
? IsQ().TheQ().LengthQ().OfQ("Haro").TheSameAsQ().TheQ().LengthQ().OfQ("Ruby").OrNot()
#--> 1
? Why()
#--> yes: 4 is the same as 4
? IsQ().TheQ().LengthQ().OfQ("Haro").TheSameAsQ().TheQ().LengthQ().OfQ("softanza").OrNot()
#--> 0
? Why()
#--> no: 4 is not the same as 8
? @@( AnswersSoFar() )
#--> [ 1, 0 ]
? AllYesSoFar()
#--> FALSE
? AnyYesSoFar()
#--> TRUE

La session a gardé [ 1, 0 ] et l'a repliée : tout oui vaut FALSE, au moins un oui vaut TRUE.

La machine est l'analyseur

Maintenant l'autre direction. La phrase est une chaîne de caractères, et la bibliothèque la lit. Le même verdict peut venir d'une narration de questions et d'une chaîne de vérité. Avec quelle certitude la chaîne de vérité répond-elle, et pourquoi ? Exécutez-la :

oT = Naturally("Create a string with 'haro' Is it lowercase ? Does it contain 'r' ?")
? @@( oT.Answers() )
#--> [ 1, 1 ]
? oT.AllYes()
#--> TRUE
? oT.Understood()
#--> create a string with haro -> ask: is lowercase -> ask: contains
TruthOf("haro") {
	IsA(:Lowercase)
	AndIsA(:Latin)
	AndContaining("r")
	? Holds()
	#--> TRUE
}
? Why()
#--> yes: "haro" is lowercase and is latin and containing "r"
? Certainty()
#--> 1
? Evidentially()
#--> certainly

Elle répond certainly, et dit pourquoi : yes: "haro" is lowercase and is latin and containing "r".

Le paragraphe entier est compilé en code avant que rien ne s'exécute, et le code est lisible. C'est le compte rendu même de la bibliothèque sur la raison d'être de la couche :

o1 = Naturally("Create a string with 'test.data' Replace '.' with '_' Uppercase it")
? o1.Result()
#--> TEST_DATA
? o1.Code()
#--> oStr = StzStringQ("test.data")
#    oStr.Replace(".", "_")
#    oStr.Uppercase()
#    @result = oStr.Content()

Le même sens en haoussa aboutit-il au même code ? Le haoussa est écrit ici sans la lettre crochetée, comme le paquet la lit aujourd'hui, pour une raison que donne le chapitre 11. Exécutez, et chaque programme redit ce qu'il a compris, dans ses propres mots :

oE = Naturally("Make a string with 'hello niger' inside Spacify it and uppercase it")
oH = NaturallyIn("hausa", "Yi rubutu da dauke 'hello niger' a ciki Raba shi kuma maida shi")
? oE.Code() = oH.Code()
#--> TRUE
? oH.Understood()
#--> yi rubutu dauke hello niger -> raba -> maida
? oE.Understood()
#--> create a string with hello niger -> spacify -> uppercase

La comparaison répond TRUE : un seul code pour deux langues !

Le dictionnaire de phrases n'est pas le seul vocabulaire. Où va un mot qu'il ne tient pas ? Il est cherché dans le vocabulaire propre de la bibliothèque, ici les balises de documentation du verbe de mise en majuscules. Une valeur entre guillemets est une donnée, et jamais un verbe. Un mot inconnu en position de valeur reste un littéral :

? Naturally("Create a string with 'softanza' Capitals it").Result()
#--> SOFTANZA
? Naturally("Create a string with 'capitals' Uppercase it").Result()
#--> CAPITALS
? Naturally("Create a string with 'a-sep-b' Replace sep with '_'").Result()
#--> a-_-b

La troisième ligne est aussi une limite : elle a imprimé a-_-b. Le mot sep n'était dans aucun dictionnaire, et il a servi de texte à remplacer. Un mot qu'elle ne connaît pas est un littéral.

Cinq langues comme données. Le dictionnaire est indexé par sens, et le mot de chaque langue aboutit à un seul identifiant. Un mot français, un mot arabe et un mot turc aboutissent-ils au même ? Exécutez :

? StzResolveSemanticInLang("fr", "doublons")
#--> METHOD_REMOVEDUPLICATES
? StzResolveSemanticInLang("ar", "تكرارات")
#--> METHOD_REMOVEDUPLICATES
? StzResolveSemanticInLang("tr", "tekrarları")
#--> METHOD_REMOVEDUPLICATES
? StzResolveSemantic("removeduplicates")
#--> METHOD_REMOVEDUPLICATES

Les langues suivent leur propre grammaire, et ce ne sont pas des traductions mot à mot. Le turc met le verbe en dernier, avec les paramètres avant lui. L'arabe, avec ses marques de voyelles et sa lettre doublée, est dépouillé par le paquet ; le suffixe du verbe est le « le » masculin pour un texte. Le français élide :

? NaturallyIn("tr", "'a.b' ile bir metin oluştur '.' yerine '_' koy").Result()
#--> a_b
? NaturallyIn("tr", "'haro' ile bir metin oluştur ve tersine çevir").Result()
#--> orah
? NaturallyIn("ar", "أنشئ نصا بـ 'haro' ثم اقلبه").Result()
#--> orah
? NaturallyIn("ar", "أنشئ نصًا بـ 'haro' ثمّ اقلِبْه").Result()
#--> orah
? NaturallyIn("ar", "أنشئ نصا بـ 'haro' ثم اقلبه").Understood()
#--> أنشئ سلسلة بـ haro -> اعكس
? NaturallyIn("fr", "Crée une chaine avec 'haro' et mets la à l'envers").Result()
#--> orah

Trois langues, trois grammaires, une seule réponse : orah. L'arabe redit ce qu'il a compris, dans ses propres mots : أنشئ سلسلة بـ haro -> اعكس.

Aucun lecteur natif n'a lu ces phrases. Elles sont calquées sur celles de la garde, avec « haro » à la place du mot d'essai de la garde, et l'inversion turque d'une chaîne de caractères est la variante du livre de l'inversion de liste de la garde. Je ne sais pas qu'un locuteur les ait lues. Le dossier ne tient aucune lecture, par un locuteur, des phrases arabes, turques, françaises ou swahilies, comme il n'en tient aucune pour le haoussa du chapitre 11. Elles sont imprimées comme des phrases calquées sur celles de la bibliothèque, non lues.

Une langue peut-elle être un bloc de données ? Voici le swahili, ajouté à l'exécution, dans les mots propres de la garde :

StzAddNaturalLanguage([
	:code = "sw",
	:name = "swahili",
	:script = "latin",
	:ignored_words = [ "na", "ya", "kwa", "hii" ],
	:semantic_mappings = [
		[:natural = "unda",   :semantic = "CREATE_OBJECT"],
		[:natural = "orodha", :semantic = "OBJECT_LIST"],
		[:natural = "na",     :semantic = "VALUE_INDICATOR"],
		[:natural = "panga",  :semantic = "METHOD_SORT"]
	],
	:phrases = [
		[:semantic = "METHOD_REMOVEDUPLICATES", :words = "ondoa nakala, futa nakala"]
	]
])
? StzHasLanguagePack("sw")
#--> TRUE
osw = NaturallyIn("sw", "Unda orodha na [ 9, 4, 9 ] ondoa nakala")
? @@( osw.Result() )
#--> [ 9, 4 ]
? osw.Understood()
#--> unda orodha na [ 9, 4, 9 ] -> ondoa nakala

Quatre correspondances, une locution, et la sixième langue répond [ 9, 4 ] !

Le code naturel est aussi une donnée. Les blocs délimités d'un document s'exécutent, et un gabarit se remplit :

cDoc = "This tutorial explains deduplication." + nl +
	"#<" + nl +
	"Create a list with [ 3, 1, 3 ] and remove its duplicates" + nl +
	"#>" + nl +
	"The end."
? len( StzNaturalBlocks(cDoc) )
#--> 1
? @@( NaturallyFromDoc(cDoc)[1].Result() )
#--> [ 3, 1 ]
cT = "Create a list with {#1} and remove its duplicates"
? @@( NaturallyWith(cT, [ [ 5, 3, 5 ] ]).Result() )
#--> [ 5, 3 ]
? @@( NaturallyWith(cT, [ [ 9, 9, 4 ] ]).Result() )
#--> [ 9, 4 ]

Ce que les paquets savent dire. Combien chaque paquet sait-il dire ? La bibliothèque a une fonction pour cela, et aucune garde n'imprime ses chiffres. Je compte par rapport à vingt-cinq sens de référence, qui sont les sens structurels et chaque méthode et modificateur que nomme un paquet livré. Ce ne sont pas les milliers de verbes que la bibliothèque a fait croître :

for cLang in [ "en", "ha", "fr", "ar", "tr" ]
	aC = StzPackCoverage(cLang)
	? cLang + " " + aC[:covered] + " of " + aC[:total]
next
#--> en 23 of 25
#    ha 9 of 25
#    fr 25 of 25
#    ar 16 of 25
#    tr 10 of 25
? StzHasNeuralModel()
#--> FALSE

Le paquet haoussa parle neuf des vingt-cinq sens : ha 9 of 25 ! Et aucun modèle n'est chargé. La couche a un secours facultatif par plongement, quand rien de lexical n'a été trouvé et qu'un modèle est chargé. À ce commit aucun ne l'est, et aucun n'est nécessaire. Je dis donc « aucun modèle n'est chargé », et non « ne touche jamais un modèle ».

Du schéma de 2020 aux trois ères

La bibliothèque nomme trois ères, dans un document de conception du 10 juillet 2026. La première est le langage quasi naturel, le premier paradigme. La deuxième est la programmation naturelle : abaisser le langage vers le code, avec du texte libre, et un objet par bloc. La troisième, de 2026, est un lexique partagé par l'exécution et la documentation, des paquets multilingues avec morphologie, et Understood(). J'appelle la troisième le lexique partagé. Le titre même de la vision pour elle emploie un mot que ce livre n'emploie pas.

Voici les dates, telles que le dossier les donne. Mon schéma stratégique porte les années 2020 à 2025, partagé le 13 septembre 2026 ; sa bande Narrations se lit « langage naturel exécutable ». Le diaporama de 2022 a été exporté le 20 septembre 2022, et sa diapositive 2 dit d'exprimer la pensée dans un langage naturel exécutable. Le dépôt de la bibliothèque commence le 12 mars 2022, et son historique ne peut pas dater 2020 ni 2021. Les fichiers quasi naturels et le moteur à son chemin actuel ont été commités pour la première fois entre le 16 et le 19 septembre 2025. Le 30 octobre 2025, les langues sont devenues de la configuration. Le 2 novembre 2025, l'entrée par chaîne de caractères a remplacé la capture par accolades. Le 9 juillet 2026, le lexique a été unifié à partir des balises de documentation. Le 10 juillet 2026, les deux documents de conception ont été écrits, et l'audit de quinze exemples canoniques a trouvé que quatre tournaient, et que deux d'entre eux répondaient correctement. La page phare du site est du 8 octobre 2026. Les dates git viennent du dépôt propre de la bibliothèque, que l'instantané n'a pas ; je les y ai vérifiées le 9 octobre 2026, et les commits cités sont des ancêtres de l'épinglage.

La plus ancienne diapositive que le dossier date est donc la diapositive fondatrice du diaporama de 2022, exporté le 20 septembre 2022. L'année 2020 est la première année de mon schéma stratégique, partagé le 13 septembre 2026 ; le dossier ne tient aucune diapositive de 2020.

Vient maintenant la décision, et ce que j'ai refusé.

5. Le tribunal

nnl_narrated prouve la phrase phare, la surface générée de noms, les mots de degré, le mode conditionnel, la référence ordinale, le refus qui rend compte de lui-même, la doctrine de grammaticalité, le contexte sur la chaîne, et le temps du discours. multilingual_pack_narrated prouve les paquets comme données, des programmes en français, en arabe et en turc qui s'exécutent, le retrait d'affixes vérifié, une langue ajoutée à l'exécution, et Understood() rendu dans la langue du programme. question_narrated prouve les cadres de question et qu'un cadre sans aspect est refusé. literate_templates_narrated, les documents et les gabarits. truthchain_narrated et interrogative_narrated, les verdicts repliés.

semantic_resolver_narrated est la garde qui devrait protéger le dictionnaire, et à ce commit elle échoue. Je l'ai lancée deux fois le 8 octobre 2026 et, chaque fois, elle s'est arrêtée sur une erreur : trois assertions ont échoué, et l'exécution s'est terminée après la vingt-neuvième. Dans cette exécution, le mot « caps », que la garde affirme, s'est résolu en une méthode pour les bornes, et « mirrored » ne s'est résolu en rien. La raison est celle de la conception elle-même : le vocabulaire est lu dans les balises de documentation de la bibliothèque, plus dix-sept opérations écrites à la main, portées par réflexion à environ trois mille. Une modification de la documentation change donc le sens d'un mot. La bibliothèque refuse honnêtement dans le second cas : dans cette exécution, Unresolved() a nommé le mot et UnderstoodAll() a imprimé 0. Le tribunal du dictionnaire a échoué sur le dictionnaire, et le chapitre 11, le chapitre 22 et le chapitre 2 nomment cette garde.

J'ai lancé une fois chacune les autres gardes nommées ci-dessus le 8 octobre 2026, et dans cette exécution elles ont passé toutes leurs assertions ; les données propres du livre n'en tiennent que les décomptes. Les appels d'assertion écrits dans les sept gardes nommées ci-dessus totalisent 269.

6. Le terrain, et où il mène

Le terrain mène en largeur de formulation. Un modèle d'IA accepte n'importe quelle formulation dans n'importe quelle langue, et le dictionnaire accepte ce que les paquets nomment. Mesuré plus haut : le paquet haoussa couvre neuf des vingt-cinq sens, le turc dix, l'arabe seize, l'anglais vingt-trois (les deux qui lui manquent, l'anglais les atteint par le vocabulaire développé par réflexion), le français vingt-cinq. Et la couche de phrases n'agit que sur trois classes : les chaînes de caractères, les listes et les nombres. Les objets du domaine d'un client n'en font pas partie ; le domaine passe par le graphe de connaissance.

Le terrain mène en sémantique de programme entier. Inform 7 compile un monde entier. Ici un programme est une suite d'opérations sur un objet vivant.

Le terrain mène sur l'éditeur. Dans mon exécution, la fonction de suggestion a répondu neuf suites possibles pour une phrase à moitié écrite, et le code attribue au terrain des langages contrôlés l'idée. Il n'y a pas ici d'éditeur qui les montre pendant que vous tapez.

Et il y a une perte du côté de la bibliothèque elle-même. Understood() imprime les verbes et non leurs arguments : le bloc de la section 3 imprime contains et non le « r » demandé. Dans mon exécution, Replace s'est imprimé replace, et Add 3 to it s'est imprimé add alors que le résultat était 8. Un lecteur qui vérifie la lecture de la machine ne voit pas de 3. Cela nuance l'affirmation du chapitre 11 selon laquelle une personne peut vérifier ce que la machine a compris.

Là où est le gain, avec la perte à côté : la même phrase donne la même réponse, avec une raison, dans la langue de l'utilisateur, et conçue pour s'exécuter hors ligne, ce qu'aucune garde ne mesure. La perte est que la langue de l'utilisateur doit être dans un paquet, et qu'un mot extérieur est un littéral ou un refus. Le dossier dit que le cas gagnant est le travail réglementé ou souverain : une instruction qui s'exécute localement et peut être auditée au mot près.

La section suivante dit où le chapitre s'arrête.

7. La limite

• construitles deux directions : des chaînes où l'humain est l'analyseur, et des phrases où c'est la machine ; cinq paquets de langue comme données et un sixième ajouté à l'exécution ; des refus avec raisons des deux côtés ; des cadres de question ; une chaîne de vérité mince ; du code naturel comme données dans les documents et les gabarits
• conçuune grammaire qui tient un modèle d'IA au lexique ; une garde qui vérifie qu'aucun socket ne s'ouvre pendant une exécution naturelle ; le plan émis comme une chaîne ; les exemples des articles épinglés comme fixtures
• absenttoute machine qui juge la grammaire d'une chaîne ; l'ajami, le zarma et le peul ; une couche naturelle fermée jusqu'en bas ; un dictionnaire protégé de la dérive de la documentation dont il est lu ; les promesses des anciens articles, dont plusieurs ne tournent pas

Une chaîne non grammaticale s'exécute. La seconde chaîne ci-dessous se lit « which a length of 4 », ce qui n'est pas de l'anglais. Quelque chose la juge-t-il ? Exécutez les deux :

? TheWordQ("haro").IsAQ(:Word).WhichQ().HasQ().ALengthQ().Of(4)
#--> TRUE
? TheWordQ("haro").IsAQ(:Word).WhichQ().ALengthQ().Of(4)
#--> TRUE

Les deux répondent TRUE : rien n'a jugé la seconde ! La doctrine est que relire une chaîne, c'est la lire à voix haute comme de l'anglais. C'est le travail de l'humain.

Le descripteur d'une chaîne atteint-il le code hôte ? Oui. IsAXT construit une chaîne de caractères et l'évalue, de sorte qu'une fonction définie par le programme et nommée dans la chaîne a imprimé host code ran. C'est le résidu que l'étude du dossier et le chapitre 6 nomment :

? Q("haro").IsAXT([ "String('x') and HostRan() and @isString" ])
#--> host code ran
#    TRUE

func HostRan()
	? "host code ran"
	return 1

Et un mot de l'ancienne ère est signalé, et jamais deviné. Le mode permissif exécute quand même le reste, et le mode strict refuse. La suggestion offerte, addn, est mauvaise :

o = Naturally("Create a string with 'softanza' Spacify it and_ Uppercase it")
? o.Result()
#--> S O F T A N Z A
? o.UnderstoodAll()
#--> FALSE
? @@( o.Unresolved() )
#--> [ [ "and_", "addn" ] ]
try
	NaturallyStrict("Create a string with 'softanza' Spacify it and_ Uppercase it")
catch
	? cCatchError
done
#--> Strict natural mode: not understood: 'and_' (did you mean 'addn'?)

Plusieurs chaînes des anciens articles ne tournent plus. La phrase de l'article sur le pont qui porte IsAMQ demande un marqueur que j'ai retiré par ma décision du 10 juillet 2026. Plusieurs chaînes de l'article quasi naturel ne tournent pas à ce commit : InLowercase() lève une erreur faute d'objet ; LettersNB, BeforeQ et TheirQ().FirstCharQ() ne sont pas définis ; et la forme à accolades Naturally() { ... } lève une erreur pour trop peu de paramètres. La chaîne de l'article sur le pont avec ReplaceLowercaseCharsQ n'est pas définie non plus. J'ai lancé douze chaînes de l'article quasi naturel le 8 octobre 2026, et huit fonctionnent. Dans cette exécution, le paragraphe de l'article sur le pont tournait encore en mode permissif, et imprimait deux boîtes imbriquées autour de « NOTHING SOFTANZA » au lieu de la seule qu'il promet. La machine l'a dit, puisque UnderstoodAll() vaut faux et que le mot non résolu est nommé (le bloc ci-dessus montre les deux), mais un lecteur doit le demander.

Ce qui est construit : les deux directions ; cinq paquets comme données et un sixième à l'exécution ; des refus avec raisons des deux côtés ; les cadres de question, la chaîne de vérité mince, le registre évidentiel ; le code naturel comme données. Le dossier contient treize fichiers et environ douze mille lignes dans douze classes, d'après wc et grep le 8 octobre 2026.

Ce qui est conçu : le plan d'une narration émis comme une chaîne exécutable, de sorte que les chaînes gagnent Understood() gratuitement. Une grammaire émise pour le lexique naturel, de sorte qu'un modèle d'IA ne puisse produire que des phrases que la couche exécute : j'ai cherché dans le dossier, et aucun émetteur de grammaire ne le touche. Une garde qui échoue si un socket s'ouvre pendant une exécution naturelle, qui n'existe pas. Un chiffre de couverture par paquet imprimé par une garde. Et les exemples des articles épinglés comme fixtures.

Ce qui est absent : le haoussa en écriture ajami, le zarma et le peul. Une couche naturelle fermée jusqu'en bas : une liste simple dans une phrase naturelle atteint le code hôte, ce que le chapitre 11 imprime, et un descripteur atteint le code hôte, ci-dessus. Toute machine qui juge la grammaire d'une chaîne. La lettre haoussa standard, que le paquet stocke brisée. Un dictionnaire protégé de la dérive. Le dossier ne tient pas non plus de récit, ni de date, de mon plaidoyer auprès du projet de l'ancien langage hôte pour que la programmation naturelle devienne une préoccupation première, ni une phrase de moi sur ce ton dont le livre puisse citer la source. Il ne tient qu'un mémo privé du 30 août 2026, qui donne mon jugement sur la forme naturelle livrée par ce langage. Le mémo est marqué privé : le livre ne le cite pas et ne m'attribue aucune expression tirée de lui.

8. Six portes

9. Exercice

Prenez une phrase que vous dites d'un mot de votre propre langue : qu'il est en minuscules, qu'il a une longueur donnée, et un nombre donné de voyelles. Écrivez-la deux fois avant de rien exécuter. D'abord comme une chaîne quasi naturelle, où vous êtes l'analyseur. Ensuite comme une phrase Naturally, où c'est la bibliothèque. Sous chacune, écrivez la ligne que vous vous attendez à voir imprimée.

# 1. as a chain, where you are the parser:
# 2. as a Naturally sentence, where the library is:

Exécutez ensuite les deux. Puis changez un mot de la chaîne, et un mot de la phrase, en un mot que le dictionnaire ne tient pas. Quelle direction vous l'a dit ? Laquelle avez-vous dû vous le dire vous-même ? Dans une direction la machine vous le dit, et dans l'autre vous devez vous le dire vous-même. Si une promesse se rompt, ne la changez pas : expliquez d'abord la sortie.

Je vous laisse celui-ci. La section 7 montre une chaîne qui se lit « which a length of 4 », et rien ne l'a refusée. Exécutez-la, lisez-la à voix haute comme de l'anglais, et écrivez dessous la ligne que vous voudriez voir la bibliothèque imprimer pour la refuser, avec la raison qu'elle donnerait.

# the chain of section 7 that nothing judged:
? TheWordQ("haro").IsAQ(:Word).WhichQ().ALengthQ().Of(4)
# the line you would have the library print to refuse it, with its reason:

Quand vous aurez écrit cette ligne, vous saurez pourquoi je tiens la chaîne non grammaticale pour une vue et non pour un résultat, et qui la page dit qu'il faut pour la juger (sections 4 et 7).

Le chapitre suivant porte sur la programmation de la connaissance, où les mots de domaine de l'analyste ont été envoyés. Son principe est qu'un système est un fichier, et qu'y ajouter une ligne fait que le système sait davantage, sans rien coder ni entraîner. Ici une phrase demande, et ne déclare jamais.

La programmation de la connaissance

Exécuté le 2026-10-15 12:59 UTC+01:00 dans la bibliothèque au commit 93d7a39bd : 13 bloc(s) sur 13 ont tenu leur promesse.

Les blocs ont été exécutés par le runtime de l'ancien langage hôte, version 1.27 ; Haro n'exécute pas encore la bibliothèque. Les binaires du moteur ont été construits dans une copie de ce commit, le plus récent le 2026-10-05 20:27 UTC+01:00 ; 1 changement(s) du moteur commité(s) après cette construction n'y sont pas.

Dans ce chapitre, je prends les trois pratiques du terrain qui se rencontrent dans cette idée : la pile sémantique, la base de données de graphes de propriétés et les règles sur des faits. Je mets à côté d'elles un système qui est un fichier texte brut. J'exécute ce fichier : deux faits, une loi et une preuve avec ses étapes, puis une clinique en mode strict, où une rumeur refusée est gardée et nommée. J'écris le fichier, je le relis et je le montre à l'échelle, d'un catalogue de cours à la mémoire d'un agent d'IA. Je dis ce que j'ai décidé, qu'une entreprise se décrit dans un seul fichier et que le fichier est le programme. Je dis ce que j'ai refusé : un monde parallèle, une contradiction résolue en silence, la récupération. J'imprime la limite, un fichier qui à ce commit n'a pas de règles. Elle se tient à côté du principe : un système est un fichier, et y ajouter une ligne fait que le système sait davantage, sans rien coder ni entraîner.

1. Le concept, tel que le terrain le tient

Trois pratiques du terrain se rencontrent dans cette idée, et aucune n'est la même qu'elle.

La première est la pile sémantique : RDF, OWL et SPARQL. Un fait est un triplet de sujet, de prédicat et d'objet, écrit dans un vocabulaire partagé. Une ontologie dit quelles classes et quelles propriétés existent et ce qui en découle, et un raisonneur en dérive les conséquences. Ce sont des recommandations du W3C, de 2014, 2009 et 2013. Ce que le terrain demande à l'auteur d'une base de connaissance, c'est un langage d'ontologie à lui, un magasin et un langage de requête. Ils se tiennent d'ordinaire à côté de l'application et non dedans.

La deuxième est la base de données de graphes de propriétés, avec son langage de requête. Le dossier a une comparaison qui met de telles bases face à cette bibliothèque. C'est un texte qu'un modèle d'IA a écrit, gardé dans le dossier de la bibliothèque, et il reconnaît au terrain l'échelle, la persistance et les transactions.

La troisième est les règles sur des faits, en Prolog et en Datalog. Des faits et des règles dans un seul programme, une requête par résolution. Le dossier ne nomme que Prolog, comme un langage à rejoindre, et non à reconstruire.

Une quatrième pratique se tient derrière le contraste, et le document de conception ne la nomme que pour la refuser. C'est la récupération, un tas de fragments de documents cherchés par similarité ; cette description est une connaissance générale, pas une étude du dossier.

Ainsi, sur le terrain, la connaissance vit dans un magasin et sa logique dans un raisonneur, tous deux à côté du programme. Ici la connaissance est un fichier texte brut que le programme charge.

2. Le premier principe

Un système est un fichier. Y ajouter une ligne fait que le système sait davantage, sans rien coder ni entraîner.

Deux phrases du dossier le portent. La définition, dans le document de conception écrit à partir de ma directive du 13 juillet 2026 : l'intelligence est la capacité de calcul de dériver une connaissance nouvelle à partir d'une connaissance existante. Et ce que la vision de 2026 en garde : ajouter un fait augmente l'intelligence du système, sans changement de code et sans entraînement. Le chapitre 17 s'ouvre sur la première, et je m'ouvre ici sur la seconde. Le document de conception du 13 juillet 2026 le dit déjà, presque dans les mêmes mots, et le chapitre garde son ouverture.

Voyons maintenant la forme elle-même, un texte et ce qu'il fait quand on l'exécute.

3. La forme Softanza

Voici un système comme un texte. Deux faits : la farine est faite de mil, et le couscous de farine. Le couscous est-il fait de mil ? Demandez-le au graphe, puis ajoutez une ligne au fichier, une loi disant que fait de est transitif, et demandez de nouveau :

cFacts = 'knowledge "coop"' + nl + nl + "facts" + nl +
         "    flour | made-from | millet" + nl + "    couscous | made-from | flour" + nl
oA = new stzKnowledgeGraph("coop")
oA.ImportKnow(cFacts)
? oA.Prove([ "couscous", "made-from", "millet" ])[:narration]
#--> not derivable: no recorded fact or lawful chain gives 'couscous' made-from 'millet'
oB = new stzKnowledgeGraph("coop")
oB.ImportKnow(cFacts + nl + "ontology" + nl + "    made-from | transitive" + nl)
? oB.Prove([ "couscous", "made-from", "millet" ])[:narration]
#--> proved: couscous made-from flour made-from millet

Sans la loi, le graphe répond not derivable ; avec elle, proved: couscous made-from flour made-from millet. Le texte est le programme. Les deux mêmes faits, une ligne en plus, une capacité différente. Le bloc ne touche pas le disque : ImportKnow prend un texte, et prend un chemin quand la chaîne de caractères finit par l'extension du fichier.

Maintenant ajoutons un fait au graphe qui a la loi, et rien d'autre. Que répondent les deux graphes à la question plus longue ? Exécutez-le :

oB.KnowRelation("porridge", "made-from", "couscous")
? oB.Prove([ "porridge", "made-from", "millet" ])[:narration]
#--> proved: porridge made-from couscous made-from flour made-from millet
? oA.Prove([ "porridge", "made-from", "millet" ])[:narration]
#--> not derivable: no recorded fact or lawful chain gives 'porridge' made-from 'millet'

Le graphe qui a la loi prouve la chaîne plus longue et en écrit les étapes : proved: porridge made-from couscous made-from flour made-from millet. Le graphe sans la loi, qui n'a de plus jamais reçu le fait, répond toujours not derivable: no recorded fact or lawful chain gives 'porridge' made-from 'millet', et je veux que vous remarquiez que ce non a deux causes, nommées dans sa propre ligne : aucun fait enregistré, et aucune chaîne que la loi permette. Un refus est aussi certain qu'une preuve, sur ce qui est enregistré et déclaré : le graphe dit « non dérivable », pas « faux ». Le commentaire de la bibliothèque sur Prove le dit : a certain no is still certain.

La même croissance atteint le modèle de langage de domaine du chapitre 19. Rien n'est entraîné. Mais un modèle forgé à partir d'un graphe, dans le mot du chapitre 19, est un instantané. Le modèle apprend-il le fait nouveau quand le graphe l'apprend ? Exécutez-le :

oKB = new stzKnowledgeGraph("coop")
oKB.Know("couscous", "dish")
oKB.KnowRelation("couscous", "contains", "semolina")
oDLM = StzDlmQ(oKB)
? oDLM.Ask("what is millet?")
#--> That is outside the 'coop' domain (I know 1 entities and 1 relations).
oKB.Know("millet", "grain")
oKB.KnowRelation("couscous", "contains", "millet")
? oDLM.Ask("what is millet?")
#--> That is outside the 'coop' domain (I know 1 entities and 1 relations).
oDLM = StzDlmQ(oKB)
? oDLM.Ask("what is millet?")
#--> Millet is a grain.
? oDLM.Ask("couscous contains what?")
#--> Couscous contains semolina and millet.

Il ne l'apprend pas. La seconde réponse est l'ancien modèle qui refuse encore, That is outside the 'coop' domain, et seul le modèle forgé de nouveau répond Millet is a grain.

Le fichier que la bibliothèque écrit. Une clinique. Une relation déclarée unique, et un graphe en mode strict, où chaque fait a besoin de sa provenance. Que fait-il d'un fait sans source, d'un fait qui en a une, et d'un second, qui le contredit, venu d'une rumeur ? Et qu'écrit-il ensuite sur le disque ? Exécutez-le :

StzKnowledgeGraphQ("clinic") {
	ConstrainRelation("treated-by", :Unique)
	EnableStrictMode()
	try
		AddFact("fatou", "treated-by", "dr-diallo")
	catch
		? cCatchError
	done
	#--> Strict mode: every fact needs provenance -- use AddFactXT(s, p, o, [ :source = ..., :confidence = ... ]).
	AddFactXT("fatou", "treated-by", "dr-diallo", [ :source = "registry", :confidence = 0.95 ])
	? AddFactXT("fatou", "treated-by", "dr-sani", [ :source = "rumour", :confidence = 0.2 ])
	#--> 0
	WriteToKnowFile("clinic")
}
? read("clinic.zknw")
#--> knowledge "clinic"
#
#    facts
#        fatou | treated-by | dr-diallo
#
#    provenance
#        fatou | treated-by | dr-diallo | source | text | registry
#        fatou | treated-by | dr-diallo | confidence | number | 0.95
#
#    contradictions
#        fatou | treated-by | dr-diallo | dr-sani | rumour
#
#    ontology
#        treated-by | unique

Le fait nu est refusé avec la phrase propre de la bibliothèque, Strict mode: every fact needs provenance. Le fait avec sa source et sa confiance est admis. La rumeur est refusée, 0, et le refus est gardé ! C'est ce que la bibliothèque écrit, un en-tête et jusqu'à quatre sections. Elles viennent dans cet ordre : les faits, la provenance quand un fait en porte, les contradictions quand l'une a été refusée, et l'ontologie quand une loi a été déclarée. Une ligne par enregistrement, les champs séparés par une barre. Une barre ou un saut de ligne à l'intérieur d'une valeur est échappé. La rumeur refusée est dans le fichier, nommée, et jamais résolue. Le commentaire du code sur la liste des contradictions le dit : named, NEVER silently resolved.

Le fichier se relit-il dans un graphe strict, avec la loi, la source de chaque fait et le refus à l'intérieur ? Chargez-le :

StzKnowledgeGraphQ("clinic") {
	EnableStrictMode()
	aR = ImportKnow("clinic.zknw")
	? aR[:merged]
	#--> 1
	? @@( MetaOfFact("fatou", "treated-by", "dr-diallo") )
	#--> [ [ "source", "registry" ], [ "confidence", 0.95 ] ]
	? len(Contradictions())
	#--> 1
	? RelationHasLaw("treated-by", "unique")
	#--> 1
}
remove("clinic.zknw")
? fexists("clinic.zknw")
#--> 0

Oui : un fait fusionné, la source et la confiance revenues, [ [ "source", "registry" ], [ "confidence", 0.95 ] ], une contradiction, et la loi. Un fichier de ce genre a été écrit un jour sans sa provenance. L'export n'écrivait que les triplets nus, de sorte que la connaissance relue depuis le disque ne disait plus d'où elle venait. Un graphe strict ne pouvait pas charger son propre export. La correction, ce sont les deux sections ci-dessus. La garde qui la prouve est nommée à la section 5.

Une loi qui se déclenche quand un fait est ajouté. Sur le monde par défaut de la bibliothèque, celui qui est derrière le sucre syntaxique du langage naturel, une loi symétrique dérive le fait inverse au moment où le premier est ajouté, sans appel à une étape de dérivation. Personne n'a écrit qu'Ibrahim est marié à Amina. Le monde par défaut le sait-il ?

StzConstrainRelation("married-to", :Symmetric)
StzKnowRelation("amina", "married-to", "ibrahim")
? DefaultKnowledgeGraph().Query([ "ibrahim", "married-to", "amina" ])
#--> 1

Il répond 1. Le fait inverse est là, et personne ne l'a écrit ! C'est le seul endroit où une loi déclarée se déclenche à l'ajout qu'une exécution de ce livre montre, et c'est le monde par défaut. La classe de graphe a aussi un interrupteur, EnableAutoDerive, qui lance les règles de dérivation après chaque arête ajoutée ; il est éteint par défaut, et je ne l'ai pas exécuté. Je montre la même loi sur un graphe d'instance à la section 7, où cela ne fonctionne pas.

Un système à l'échelle. Le programme d'éducation de la bibliothèque est un fichier de connaissance. Son catalogue, program.zknw, dit comment s'appelle le programme et quels cours et quelles langues il a. Quel est son nom, et quelles langues porte-t-il ? Demandez-le-lui :

oP = StzProgramQ("../../education/program")
? oP.Id()
#--> softanza-education
? @@( oP.Languages() )
#--> [ "en", "fr", "ar", "ha" ]

Il s'appelle softanza-education, et il a quatre langues. Ajouter un cours, c'est y ajouter une ligne, et la garde vérifie que chaque cours déclaré est un dossier et que chaque dossier est déclaré. Dans le module d'éducation, l'instantané tient quatre-vingt-dix-neuf fichiers de connaissance, comptés avec find le 8 octobre 2026. Ce sont des cours, des exercices, des mondes et des compétences, un monde de projet pour un apprenant, et les surcouches qu'une institution pose sur le noyau. La mémoire d'un agent est aussi un graphe de connaissance, sauvegardé par le même format, avec la provenance.

Voilà la forme. Voyons maintenant ce que j'ai décidé, et ce que j'ai refusé.

5. Le tribunal

knowledge_integration_narrated prouve que le monde répond à WhatIs, que le graphe a grandi à côté, et que la loi vit dans l'ontologie. Elle prouve que Prove narre d'abord la loi puis les maillons de la chaîne, avec une certitude de 1, et refuse ce qu'il ne peut pas prouver. Elle prouve que le fichier fait l'aller-retour. Elle prouve qu'une loi symétrique dérive l'arête inverse quand l'étape de dérivation est appliquée après l'ajout d'un fait par le graphe. Enfin, elle prouve que le mode strict admet un fait muni de provenance, refuse un fait nu, et refuse et enregistre une contradiction d'unicité.

provenance_survives_save_narrated prouve que la source et la confiance d'un fait survivent à une sauvegarde, qu'un graphe strict charge son propre export, et qu'une contradiction refusée survit. Elle prouve qu'une barre ou un saut de ligne dans une valeur est une donnée, et qu'un ancien fichier sans provenance se charge encore. Elle prouve que la mémoire d'un agent enregistre qui a appris un fait, et quand.

program_narrated prouve que le programme compte ses cours, et que chaque cours déclaré est un dossier et chaque dossier est déclaré. Elle prouve que les textes se lisent de la même façon depuis un checkout avec d'autres fins de ligne.

Voilà ce que prouvent les gardes. Ce que le terrain fait mieux vient ensuite.

6. Le terrain, et où il mène

La comparaison de graphes du dossier dit elle-même où les solutions traditionnelles gagnent : les systèmes à grande échelle qui ont besoin de stockage et de traitement distribués, et les applications où la performance est critique. Son tableau place Softanza à l'échelle de l'entreprise, de quelques centaines à quelques milliers de nœuds, dans un seul processus. C'est le résumé honnête de la perte : le terrain mène en échelle, en persistance, en transactions et en outillage. La ligne de la comparaison sur la persistance est antérieure au fichier ; le graphe de connaissance en écrit un maintenant.

Le terrain mène en normes et en portée, en connaissance générale. Une base de connaissance en RDF peut être partagée avec n'importe quel outil qui lit les formats du W3C, reliée à des vocabulaires publics et interrogée à travers des magasins. D'après le dossier, un fichier de connaissance est lu par cette bibliothèque et par rien d'autre. Un raisonneur pour un langage d'ontologie riche fait ce que trois lois et une déclaration de classe ne font pas. Le terrain mène en expressivité des règles : Prolog et Datalog dérivent des faits nouveaux à partir de règles arbitraires. Ici, dans les exécutions que j'ai gardées, une seule sorte de loi dérive un fait, et seulement sur le monde par défaut. Le terrain mène en requêtes à plusieurs étapes, puisque SPARQL et Cypher joignent des motifs. Et en relations multiples entre deux choses.

Voici où je pense que cela se distingue, avec les limites mesurées à côté. La connaissance est un fichier texte qu'une personne peut lire, modifier, comparer et livrer avec le programme. Chaque réponse est prouvable avec ses étapes, et un non est aussi certain qu'un oui. Ce qu'un fait affirme voyage avec sa source et ses refus. Et le même format porte un cours, le projet d'un apprenant et la mémoire d'un agent. Rien de cela n'a besoin d'un magasin, d'un serveur, d'un modèle d'IA ni d'un entraînement.

Les pertes sont imprimées. La limite du chapitre vient ensuite, avec ses exécutions.

7. La limite

• construitun système comme un fichier texte brut de faits, avec des lois (unique, transitive, symétrique) et la source de chaque fait ; Prove avec ses étapes, un non aussi certain qu'un oui ; le mode strict ; le fichier écrit, relu et livré, d'un catalogue de cours à la mémoire d'un agent d'IA
• conçudes règles dans le fichier ; la dérivation sur n'importe quel graphe ; une requête qui joint ; plusieurs relations entre deux choses ; l'héritage de classes ; la validation au chargement
• absentle dialogue fondateur de 2022, qui ne tourne pas ; Explain sur un graphe de connaissance ; la section des règles du fichier, que l'analyseur écarte

La limite de ce chapitre est celle que ma directive, à la section 4, porte déjà : entités, relations, une ontologie, règles. Le fichier à ce commit n'a pas de règles. Voici le fichier avec une section de règles. Qu'en fait l'analyseur ?

cRules = 'knowledge "pairs"' + nl + nl + "facts" + nl + "    margherita | pairs-with | chianti" + nl + nl +
         "rules" + nl + "    pairs-with | symmetric" + nl
oRul = new stzKnowledgeGraph("pairs")
aM = oRul.ImportKnow(cRules)
? aM[:merged]
#--> 1
? len(oRul.Ontology())
#--> 0

Le fichier fusionne, 1, et l'ontologie est vide, 0. L'analyseur reconnaît l'en-tête rules, et n'a de gestionnaire pour aucune des lignes qui le suivent. Elles sont écartées : l'ontologie en tient 0, et aucun refus ne revient. La même loi sous l'en-tête ontology donne une ontologie de longueur 1. Les règles vivent ailleurs, comme données dans une règle attachée à un graphe, ce qui est le sujet des chapitres 29 et 30, et dans un fichier séparé qui nomme des fonctions de règle. Dans ce fichier il y a des faits et des lois. J'imprime « faits et lois », et j'envoie les règles à ces deux chapitres. Le fichier unique qui contient des règles, que promet la conception, n'est pas là, et cette section imprime ce manque comme la limite du chapitre.

La loi n'est pas non plus dérivée sur un graphe d'instance. Prenons la même loi symétrique et le même fait que sur le monde par défaut. L'inverse y est-il ?

StzKnowledgeGraphQ("pairs") {
	ConstrainRelation("pairs-with", :Symmetric)
	KnowRelation("margherita", "pairs-with", "chianti")
	? RelationHasLaw("pairs-with", "symmetric")
	#--> 1
	? Query([ "chianti", "pairs-with", "margherita" ])
	#--> 0
}

La loi est enregistrée, 1, et l'arête inverse n'y est pas, 0 ! L'en-tête de la classe le dit : only :unique and :transitive are acted on here ; la symétrie est seulement enregistrée. Quatre autres limites, chacune avec son exécution.

Une seule relation entre deux choses. Le graphe stocke une arête par paire de nœuds. Admet-il une seconde relation entre les deux mêmes entités, amina et bread ? Exécutez-le :

oShop = new stzKnowledgeGraph("shop")
oShop.KnowRelation("amina", "sells", "bread")
aV = oShop.Admit("amina", "buys", "bread", [ :source = "till" ])
? aV[:admitted]
#--> 0
? aV[:why]
#--> Can't add fact: 'amina' and 'bread' already carry the edge 'sells' (stzGraph stores one edge per node pair).

La seconde relation est refusée, 0, avec la phrase propre de la bibliothèque, Can't add fact: 'amina' and 'bread' already carry the edge 'sells' (stzGraph stores one edge per node pair). Un modèle de connaissance qui ne peut pas tenir vend et achète entre les deux mêmes entités est une vraie limite. Le code le dit : known limitation, revisit with multi-edge support.

Une question à deux étapes ne répond qu'à sa première étape. QueryPath suit-il son second motif, et le prédicat d'une requête peut-il être une variable ? Exécutez-le :

StzKnowledgeGraphQ("coop2") {
	KnowRelation("amina", "sells", "couscous")
	KnowRelation("couscous", "made-from", "flour")
	? @@( QueryPath([ [ "amina", "sells", "?p" ], [ "?p", "made-from", "?m" ] ]) )
	#--> [ "couscous" ]
	? @@( Query([ "amina", "?p", "?o" ]) )
	#--> [ ]
}

Le chemin répond [ "couscous" ], la première étape et rien de plus : QueryPath ignore le reste de ses motifs, donc ce n'est pas encore une requête à plusieurs étapes. Le prédicat variable répond [ ].

Une ligne qui n'est pas un fait. Quatre lignes, dont trois ne sont pas des faits : deux champs, quatre champs, et aucune barre. Que refuse l'analyseur ?

cBad = 'knowledge "t"' + nl + nl + "facts" + nl + "    a | likes | b" + nl + "    c | likes" + nl +
       "    d | likes | e | f" + nl + "    g likes h" + nl
oT = new stzKnowledgeGraph("t")
aBad = oT.ImportKnow(cBad)
? aBad[:merged]
#--> 1
? @@(aBad[:refused])
#--> [ ]

Rien. Le fichier fusionne, 1, et la liste des refus est [ ] ; l'analyseur se tait et les trois lignes disparaissent ! Le document de conception promet que le fichier est « validé au chargement ». À ce commit l'analyseur ne garde qu'une ligne ayant exactement trois champs.

Le dialogue fondateur de 2022. La narration raconte la programmation de la connaissance par un dialogue : une pomme comme fruit et comme entreprise, un propriétaire, des relations demandées comme des questions. À ce commit sa première ligne ne tourne pas. Le texte, que je montre et ne lance pas, est @Q("Apple").IsA(:Fruit). Le 8 octobre 2026 il s'est arrêté sur Calling Function without definition: @isfruit ; je n'ai pas gardé cette exécution comme bloc. La classe de chaîne de caractères lit le prédicat comme du langage naturel et cherche une fonction de ce nom. Deux autres formes s'arrêtent ailleurs. Les lignes de promesse de la narration sont périmées. La forme la plus proche qui tourne garde le sens. Le monde connaît-il un nom à deux significations ?

StzKnow(:Apple, :Company)
StzKnow(:Apple, :Fruit)
? @@( WhatIs(:Apple) )
#--> [ "company", "fruit" ]

Il connaît les deux : [ "company", "fruit" ].

L'étude du dossier dit déjà que le dialogue a été gardé en marge, et que le centre s'est déplacé vers le fichier. Le chapitre garde le fichier comme ouverture, et le dialogue de 2022 reste en marge.

Ce qui est conçu : des règles dans le fichier ; la dérivation sur n'importe quel graphe ; une requête à plusieurs étapes ; plusieurs relations entre deux choses ; l'héritage de classes. DefineClass écrit un fait, et aucun héritage n'en découle. Le plus proche qui a tourné, dans un essai antérieur dont je n'ai pas gardé l'exécution, est de déclarer is-a transitif et d'énoncer la classe comme un fait de cette relation. Et l'hygiène de la connaissance de la conception au-delà de la provenance, les requêtes bornées, les graphes à portée et la révision avec retour arrière, n'a aucune méthode de ce nom.

Ce qui est absent ou cassé : Explain() sur un graphe de connaissance, qui appelle ApplyInference, une fonction définie nulle part. Et ValidateOntology(), qui renvoie 1 quel que soit le contenu de l'ontologie, comme son propre commentaire le dit, known defect.

Une note sur l'histoire du document de conception. Son amendement du 22 août 2026 dit qu'aucun fichier de connaissance n'existe nulle part dans l'arbre, et que c'est de l'hygiène et non un manque. À ce commit ce n'est plus vrai : il y en a quatre-vingt-dix-neuf, tous dans le module d'éducation.

Voilà la limite, imprimée. Voyons maintenant les six portes.

8. Six portes

9. Exercice

Voici un monde avec deux faits, et une question à laquelle il ne peut pas encore répondre. Votre promesse est la ligne qui prouve que la classe 3b fait partie du primaire, avec la chaîne écrite en entier. Changez le monde, et non la question.

cWorld = 'knowledge "school"' + nl + nl + "facts" + nl +
         "    class-3b | part-of | grade-3" + nl +
         "    grade-3 | part-of | primary" + nl
oW = new stzKnowledgeGraph("school")
oW.ImportKnow(cWorld)
? oW.Prove([ "class-3b", "part-of", "primary" ])[:narration]
# this prints a refusal. Your promise: the line proving that class-3b is part of primary,
# with the chain written out. Change the world, not the question.

Exécutez-le et voyez ce qui s'imprime. Si vous changez la question pour demander au sujet du grade 3, il prouvera quelque chose, et ce ne sera pas la ligne que vous avez promise. Puis posez la question inverse, si le primaire fait partie de la classe 3b, une fois que votre monde a sa loi, et voyez si la loi ajoute un fait dans le mauvais sens. Je ne vous dis pas la ligne à ajouter.

Je vous laisse celui-ci. La section 7 lance un fichier de quatre lignes, dont trois ne sont pas des faits, et imprime ce que l'analyseur en dit. Voici ce fichier de nouveau, avec un seul changement : il interroge aussi le graphe sur trois des lignes, et je n'imprime aucune des réponses.

cBad = 'knowledge "t"' + nl + nl + "facts" + nl + "    a | likes | b" + nl + "    c | likes" + nl +
       "    d | likes | e | f" + nl + "    g likes h" + nl
oT = new stzKnowledgeGraph("t")
aBad = oT.ImportKnow(cBad)
? aBad[:merged]
? @@(aBad[:refused])
? oT.Query([ "a", "likes", "b" ])
? oT.Query([ "d", "likes", "e" ])
? oT.Query([ "g", "likes", "h" ])

Lancez-le. Lisez merged, lisez refused, lisez les trois requêtes, et trouvez quelles lignes le graphe détient et ce que l'analyseur vous a dit des autres. Posez la promesse du document de conception, un fichier « validé au chargement », section 4, à côté de ce que vous trouvez ; la section 7 dit ce que l'analyseur garde. Je ne vous donne pas la réponse, et je n'ai pas corrigé l'analyseur. Quand vous l'aurez, vous saurez pourquoi un fichier qui fusionne n'est pas un fichier qui a été validé.

Le chapitre suivant porte sur les langages de motifs : un motif est une règle sur la forme des données, écrite comme des données, et la même habitude sert tous les genres de données. Ici, une loi sur une relation était une ligne dans un fichier ; là, la règle porte sur la forme des données elles-mêmes.

Les langages de motifs

Exécuté le 2026-10-15 12:59 UTC+01:00 dans la bibliothèque au commit 93d7a39bd : 13 bloc(s) sur 13 ont tenu leur promesse.

Les blocs ont été exécutés par le runtime de l'ancien langage hôte, version 1.27 ; Haro n'exécute pas encore la bibliothèque. Les binaires du moteur ont été construits dans une copie de ce commit, le plus récent le 2026-10-05 20:27 UTC+01:00 ; 1 changement(s) du moteur commité(s) après cette construction n'y sont pas.

Dans ce chapitre, je pars de l'expression régulière, ce qu'un motif est pour un programmeur qui travaille, et je porte son habitude aux données qui ne sont pas du texte : listes, nombres, tableaux, matrices, temps et graphes. Je fais le même petit geste dans chaque support, un constructeur, un motif dans une chaîne de caractères, Match, et je vous montre tout de suite que la grammaire n'est pas tout à fait une. Je dis ce que les gardes prouvent et là où la famille est encore en développement, et je garde sa seule tension pour la limite : un mot que le langage ne connaît pas n'est pas encore refusé. Le principe est celui-ci : un motif est une règle sur la forme des données, écrite comme des données, et la même habitude sert tous les genres de données.

1. Le concept, tel que le terrain le tient

Pour un programmeur qui travaille, un motif est une expression régulière : une notation compacte de la forme d'une chaîne de caractères, remise à un moteur qui dit si le texte lui correspond, et où. Les moteurs sont anciens et bien connus. Celui qui est sous cette bibliothèque est PCRE2, et le site le mesure contre deux autres.

Pour les données qui ne sont pas du texte, le terrain emploie d'autres outils, un par support et aucun partagé. La mise en correspondance structurelle de motifs dans les langages de la famille ML, en Rust, et depuis Python 3.10 en Python. Les vérifications de schéma pour les listes et les enregistrements. Les bibliothèques de qualité des données pour les tableaux. La reconnaissance de motifs de lignes en SQL, et les moteurs de flux, pour les séquences dans le temps. Et les langages de requête de graphes, dont le cœur est un motif de chemin. C'est une connaissance générale, bien établie ; le dossier ne contient aucune étude datée d'aucun d'eux, et je n'en invente aucune.

L'étude de terrain du domaine de projets lui-même, d'août 2026, donne le profil des petits langages qui ont survécu. Ce profil est une grammaire fermée, une question de domaine, du texte brut, une surface minuscule, une spécification avec une suite de conformité, des décennies de stabilité. Un langage de motifs est exactement cela. Une question, ces données correspondent-elles, en quelques caractères. Ce que le terrain n'offre pas, c'est la même notation d'un support à l'autre.

Vient ensuite le premier principe.

2. Le premier principe

Un motif est une règle sur la forme des données, écrite comme des données. La même habitude sert tous les genres de données.

La phrase à laquelle reviennent les articles de la bibliothèque, dans chaque support, est celle de l'article sur les nombres : au lieu d'indiquer à la machine comment tester une condition, vous énoncez ce que vous voulez dire. Mon étude du dossier, qui n'est pas l'étude de terrain ci-dessus, porte aussi une phrase de moi, « pour la première fois dans l'histoire de l'informatique ». Je ne l'ai trouvée dans aucun texte de la bibliothèque, donc le site ne la revendique pas. Je la garde ici comme ce que j'ai dit, et je n'affirme que ce qui est mesuré : une seule grammaire en forme de regex pour sept genres de données dans une seule bibliothèque, le texte et six qui ne sont pas du texte, avec la même habitude de petite fonction. Et je vais vous montrer tout de suite que la grammaire n'est pas tout à fait une.

3. La forme Softanza

Un motif appelé par son nom est un catalogue fermé. La bibliothèque a un fichier de données de motifs nommés. Que dit-elle quand vous demandez un nom qu'elle ne tient pas ? Exécutez-le :

? rx(pat(:isoDate)).Match("2023-12-25")
#--> 1
? rx(pat(:isoDate)).Match("25/12/2023")
#--> 0
? rx(pat(:isoDate)).Explain()
#--> Matches ISO 8601 date format (YYYY-MM-DD)
try
	pat(:banana)
catch
	? cCatchError
done
#--> The pattern name you provided does not exist in stzRegexData file.

Elle refuse, et dit pourquoi : The pattern name you provided does not exist in stzRegexData file.

Un motif peut aussi répondre à la valeur à moitié écrite, ce que veut un formulaire pendant que la personne tape :

StzRegexQ("^\d{3}-\d{2}-\d{4}$") {
	? MatchAsYouType("123-45")
	#--> 1
	? MatchAsYouType("abc")
	#--> 0
	? IsPartialMatch("123-45")
	#--> 1
	? IsPartialMatch("123-45-6789")
	#--> 0
}

Voici maintenant le geste qui donne son titre au chapitre. Prenons une liste. Son motif s'écrit entre crochets, et les comptes, l'imbrication et la négation sont écrits, non bouclés. @N représente un nombre, @S une chaîne de caractères, + un ou plus, @N1-3 un à trois, et @! le non. [@N1-3, @S] accepte-t-il quatre nombres avant la chaîne de caractères ? Le deuxième appel répond :

? Lx("[@N+, @S]").Match([1, 2, 3, "end"])
#--> 1
? Lx("[@N1-3, @S]").Match([1, 2, 3, 4, "end"])
#--> 0
? Lx("[@S, [@N+]]").Match(["tea", [1, 2, 3]])
#--> 1
? Lx("[@S, [@N+]]").Match(["tea", ["x"]])
#--> 0
? Lx("[@!N, @N]").Match(["a", 1])
#--> 1
? Lx("[@!N, @N]").Match([1, 1])
#--> 0

Non : le deuxième appel imprime 0, car quatre nombres sont un de trop. Chaque appel ici utilise un objet neuf, pour une raison que donne la section 7. Le chapitre 11 a montré quatre appels du même langage, et je ne les répète pas.

Les nombres ont des propriétés, et une propriété est du sens, non de la procédure. Quels nombres entre 1 et 500 sont parfaits ? La dernière ligne fait passer un motif d'un test à une recherche :

? Nx("{@Property(Even) & @Property(Prime)}").Match(2)
#--> 1
? Nx("{@Property(Even) & @Property(Prime)}").Match(4)
#--> 0
? Nx("{@Digit(:unique)+}").Match(1234)
#--> 1
? Nx("{@Digit(:unique)+}").Match(1223)
#--> 0
? Nx("{@Relation(Mod:5=0)}").Match(10)
#--> 1
? @@( Nx("{@Property(Perfect)}").MatchingNumbersBetween(1, 500) )
#--> [ 6, 28, 496 ]

Trois nombres répondent, et aucune boucle n'a été écrite.

Les tableaux : une règle de qualité des données est une phrase du langage. La personne qui possède les données peut la lire. Niamey apparaît deux fois, donc les villes ne sont pas uniques, et la négation de cela est vraie :

oT = new stzTable([
	[ :ID, :NAME, :AGE, :CITY ],
	[ 1, "Ali", 28, "Niamey" ],
	[ 2, "Sara", 32, "Paris" ],
	[ 3, "Omar", 41, "Niamey" ],
	[ 4, "Awa", 25, "Dakar" ]
])
? Tbx("{cols(4) & unique(id) & avgcol(age:>30)}").Match(oT)
#--> 1
? Tbx("{cols(4) & unique(city)}").Match(oT)
#--> 0
? Tbx("{@!unique(city)}").Match(oT)
#--> 1
? Tbx("{sorted(id) & numeric(age) & alphabetic(name)}").Match(oT)
#--> 1

Un motif est une donnée, donc les motifs se composent : on en construit un à partir de motifs.

oA = new stzTablex("{cols(4)}")
oB = new stzTablex("{rows(4)}")
oAnd = oA.And_(oB)
? oAnd.Pattern()
#--> {cols(4) & rows(4)}
? oAnd.Match(oT)
#--> 1
? oA.Not_().Pattern()
#--> {@!cols(4)}
? oA.Not_().Match(oT)
#--> 0

Une matrice : un concept, carrée et symétrique, tient en une ligne.

? Mx("{shape(square) & property(symmetric)}").Match([ [1,2,3], [2,4,5], [3,5,6] ])
#--> 1
? Mx("{shape(square) & property(symmetric)}").Match([ [1,2,3], [4,5,6], [7,8,9] ])
#--> 0
? Mx("{size(2x3)}").Match([ [1,2,3], [4,5,6] ])
#--> 1
? Mx("{property(identity)}").Match([ [1,0], [0,1] ])
#--> 1

Le temps, dans la part qui s'exécute, écrit ici avec la classe plutôt qu'avec sa petite fonction Tmx. Une durée doit satisfaire une règle : d'une à deux heures, sur un pas d'un quart d'heure. Laquelle de trois durées convient : quatre-vingt-dix minutes, quatre-vingts minutes ou trois heures ?

oTm = new stzTimex("{@Duration(1h..2h:15min)}")
oTm {
	? Match(new stzDuration("1 hour 30 minutes"))
	#--> 1
	? Match(new stzDuration("1 hour 20 minutes"))
	#--> 0
	? Match(new stzDuration("3 hours"))
	#--> 0
}

Seules quatre-vingt-dix minutes conviennent : quatre-vingts sont dans l'intervalle et hors du pas, et trois heures sont dehors.

Un graphe : un motif se lit comme le chemin qu'il cherche. Les étiquettes correspondent sans égard à la casse. Le sens compte-t-il ? La deuxième ligne répond :

g = new stzGraph("Order")
g {
	AddNodeXT(:a, "Placed")
	AddNodeXT(:b, "Cooking")
	AddNodeXT(:c, "Served")
	AddEdgeXT(:a, :b, "starts")
	AddEdgeXT(:b, :c, "finishes")
}
? (new stzGraphex("{@Node(placed) -> @Edge(starts) -> @Node(cooking)}", g)).Match(g)
#--> 1
? (new stzGraphex("{@Node(served) -> @Node(placed)}", g)).Match(g)
#--> 0
? (new stzGraphex("{@Node(placed) -> @!Node(refunded)}", g)).Match(g)
#--> 1

Oui : le chemin de served à placed ne trouve rien, et la ligne imprime 0.

Enfin, l'habitude. Le motif est une donnée dans chaque langage, et un langage qui expose ses jetons peut être relu par une personne et par un agent d'IA. Cinq des six qui ne sont pas du texte le font ; en voici trois :

? len( Lx("[@N, @S]").Tokens() )
#--> 2
? Lx("[@N, @S]").Tokens()[2][:type]
#--> string
? Nx("{@Property(Even) & @Property(Prime)}").Tokens()[1][:type]
#--> conjunction
? len( Mx("{shape(square) & property(symmetric)}").Tokens()[1][:conditions] )
#--> 2

Les graphes n'ont ni Tokens, ni Pattern, ni Explain qui fonctionne à ce commit, et pas de petite fonction non plus. Il n'y a pas de Gx, et il n'y a pas de Tx pour le temps, bien que le tableau de l'étude nomme les deux. Les petites fonctions sont rx, Lx, Nx, Tbx, Mx et Tmx.

5. Le tribunal

00_regex_narrated prouve les ancres et la recherche, les classes, les quantificateurs exacts, les groupes, les quatre types de correspondance, la correspondance partielle pendant la frappe, et les positions comme données. 00_numbrex_narrated prouve premier, parfait, Fibonacci, pair et impair, carré et composé, chacun avec un nombre qui correspond et un qui ne correspond pas. Son en-tête consigne une régression où Match() renvoyait autrefois TRUE pour toute entrée. tablex_narrated prouve l'analyseur, le comptage, l'unicité, le tri, les types, les sommes et les moyennes, les trois connecteurs, les séquences, et la construction de motifs à partir de motifs. Son en-tête nomme la faute qu'il a tuée. L'analyseur découpait avec une position de fin à travers une fonction qui compte, et environ quatre-vingt-dix motifs étaient analysés en un jeton du bon type sans valeur. 00_matrex_narrated prouve la taille exacte, toute taille et la forme carrée. Son en-tête consigne que Match() renvoyait autrefois FALSE pour toute entrée. 00_graphex_narrated prouve qu'un motif se compile en un graphe, les étiquettes présentes et absentes, une séquence comme sous-suite, les règles de casse, la négation, l'alternance, les propriétés numériques, et le cache par signature de graphe.

Notez l'emplacement : la garde des tableaux vit dans le dossier de la regex, et son nom n'a pas de préfixe 00_.

Il n'y a pas de garde narrée pour les listes, le temps ou les constructeurs de regex. Les tribunaux de ceux-ci sont des fichiers classiques sans promesses utilisables. Les tests des listes sont placés après une définition de fonction, de sorte que le langage hôte les lit comme le corps de la fonction et n'en exécute aucun. J'ai lancé une copie avec la fonction déplacée à la fin, et je n'ai pas gardé cette exécution comme bloc. Soixante vérifications se sont exécutées, et deux d'entre elles contredisent l'attente du fichier lui-même. Le fichier classique du temps dit qu'une promesse est TRUE et l'exécution imprime 0, et le dossier central l'a consigné le 1er octobre 2026 comme encore ouvert.

Vient ensuite le terrain, et où il mène.

6. Le terrain, et où il mène

Chaînes de caractères. Le terrain mène en sûreté et en vitesse, et Softanza mène en nommage. La page du site pour ce domaine le dit elle-même : elle est derrière les moteurs modernes en sûreté et en débit, sans JIT et sans moteur de correspondance en temps linéaire. Le contrôle contre le retour arrière catastrophique n'est pas atteignable depuis Haro, bien que le code pour les deux soit déjà compilé dans le binaire. L'en-tête du moteur confirme que le durcissement existe en dessous : une limite de correspondances, une limite de récursion, des plafonds de longueur.

Listes, nombres, temps, graphes. Le terrain a des outils uniques plus anciens et mieux établis. L'étude le dit sans les classer : un outil a des motifs de listes, l'unicité et des intervalles à pas, et trois langages ont la mise en correspondance structurelle. Les langages de requête de graphes existent, et le traitement d'événements existe pour le temps. Ce que le terrain n'a pas, et ce que le dossier revendique, c'est l'habitude unique d'un support à l'autre.

Tableaux. Les bibliothèques de qualité des données mènent en portée et en écosystème. Ici une règle est une phrase que la personne qui possède les données peut lire. La perte est qu'elle ne s'exécute que sur stzTable.

Là où la famille est encore en développement. Les en-têtes de classe impriment leurs limites connues comme des avertissements : pour les matrices et les graphes. C'est rare, et je le dis. Graphes : les quantificateurs sont analysés mais pas encore utilisés par la correspondance. Matrices : des manques connus aujourd'hui, chacun porté comme un avertissement sur sa méthode.

Une date pour le bogue récurrent de la famille. La même cause racine a frappé la famille langage par langage : les analyseurs découpaient avec une position de fin à travers une fonction qui compte. Les nombres et les matrices ont été réparés le 14 juin 2026, les tableaux le 5 octobre, et les graphes dans une correction dont le fichier ne donne pas la date. Le temps le porte encore. C'est la preuve que la famille partage une seule conception et les habitudes d'un seul analyseur ; c'est aussi une raison probable pour laquelle le temps ne correspond pas encore.

Vient ensuite la limite.

7. La limite

• construitdes motifs pour le texte, les nombres et les tableaux, chacun avec une garde ; la même petite habitude d'un support à l'autre (un constructeur, un motif dans une chaîne de caractères, Match, Tokens)
• conçuun seul moteur de motifs partagé par tous les supports ; le motif comme côté condition de la cascade ; le motif écrit à partir d'exemples
• absentle refus d'un mot que le langage de motifs ne connaît pas, dans les six supports qui ne sont pas du texte ; des séquences sur une ligne de temps, dans le temps ; une narration et une petite fonction pour les graphes ; les classes sœurs génétique, linguistique et quantique

Ce qui est construit : les chaînes de caractères, les nombres et les tableaux, chacun avec une garde et une petite fonction. L'habitude partagée.

Ce qui est construit en partie : les listes, les matrices, le temps et les graphes, dans cet ordre.

• Listes : les types, les comptes, l'imbrication, la négation, l'alternance et les ensembles s'exécutent. Les intervalles à pas lèvent une erreur. Dans une exécution que je n'ai pas gardée comme bloc, le drapeau d'unicité a été ignoré, de sorte que [@N2-3{1; 2; 3}U] a accepté [1, 1], bien que la classe ait du code pour une vérification d'unicité. Le joker de l'article, @A, n'est pas un jeton ; le vrai joker est @$. Et un objet réutilisé répond depuis un cache dont la clé est la longueur de la liste et la somme des codes de ses caractères, ce qui ne dépend pas de l'ordre. Un objet neuf répond 0 pour ["hello", 1], et le même objet après [1, "hello"] répond 1.
• Matrices : la taille, la forme, l'élément et trois propriétés s'exécutent. L'en-tête de la classe liste les termes qui acceptent toute matrice : row, col, pattern, determinant et sum. Une matrice de deux par deux est acceptée par {row(99)}.
• Temps : les instants et les durées avec un pas s'exécutent. Dans une exécution que je n'ai pas gardée comme bloc, un intervalle sans pas a levé une erreur. Et les séquences sur une ligne de temps ne s'exécutent pas du tout : voici une ligne de temps avec une réunion, une pause et un déjeuner, et le motif que l'article promet. Correspond-il ?

oTl = new stzTimeLine("2025-10-22", "2025-10-22")
oTl {
	AddInstant("Meeting", "2025-10-22 09:00:00")
	AddSpan("Break", "2025-10-22 10:00:00", "2025-10-22 10:15:00")
	AddInstant("Lunch", "2025-10-22 12:00:00")
}
o1 = new stzTimex("{@Event(Meeting) -> @Duration* -> @Event(Break)}")
? o1.MatchPartial(oTl)
#--> 0
o2 = new stzTimex("{@Event(Lunch)}")
? o2.MatchPartial(oTl)
#--> 0
? @@( o2.Tokens()[1][:label] )
#--> "Lunch)"

L'article promet que le premier est TRUE. Le deuxième montre que même un événement unique que la ligne de temps contient ne correspond pas ! Le troisième montre pourquoi : l'étiquette du jeton est "Lunch)", lue avec sa parenthèse fermante. C'est le bogue partagé ; le réparer dans le temps est l'étape suivante.

• Graphes : les étiquettes dans l'ordre le long d'un chemin, la négation, l'alternance et les propriétés numériques s'exécutent. La flèche signifie plus tard sur un chemin, et non suivant. Les quantificateurs (+, *, ? ou un nombre après un jeton) sont lus et ignorés. Le graphe de la section 3 a trois nœuds ; ici @Node10, un nœud avec le quantificateur dix, est demandé entre eux. Le motif correspond-il ?

? (new stzGraphex("{@Node(placed) -> @Node(served)}", g)).Match(g)
#--> 1
? (new stzGraphex("{@Node(placed) -> @Node10 -> @Node(served)}", g)).Match(g)
#--> 1

Cooking se trouve entre le premier et le dernier, donc la première réponse est le sens de la flèche. La seconde répond 1 aussi ! Le quantificateur est ignoré. Le cache de cette classe est indexé par les comptes de nœuds et d'arêtes et les identifiants de nœuds. Un second graphe avec les mêmes identifiants et d'autres étiquettes est servi depuis le cache, jusqu'à ClearCache() : la réponse peut être périmée.

Le refus que la famille n'a pas encore fait. La loi du chapitre 11 est qu'un langage est déclaré et fermé, avec des refus. Que répond la famille quand on lui demande un mot qu'elle ne connaît pas ? Exécutez-le :

? Nx("{@Banana(3)}").Match(7)
#--> 1
? Nx("{@Banana(3)}").Match(1000003)
#--> 1
? @@( Nx("{@Banana(3)}").Tokens() )
#--> [ ]
? Nx("{@Property(Banana)}").Match(7)
#--> 0

Un motif avec un mot que le langage ne connaît pas correspond à tous les nombres ! Les jetons sont [ ], et rien n'est levé. Les langages des matrices et des tableaux renvoient un jeton ERROR que rien ne lève, et les langages des nombres et du temps renvoient une liste vide. La session de la charte de Haro l'a consigné comme constat, que le dossier central a relayé le 28 septembre 2026 : les six classes de motifs acceptent en silence les jetons inconnus. Je l'ai reproduit à ce commit, et la demande n'est pas close. Un langage fermé qui ne peut pas refuser n'est pas encore la loi du chapitre 11. Le chapitre l'imprime comme un constat du tribunal, et non comme une dette de moi. Je le tiens pour mon point de vue. L'exécution ci-dessus, à ce commit, est ce qui le soutient.

Ce qui est conçu : un seul moteur de motifs partagé par tous les supports. La conception du moteur dit que le moteur à retour arrière, le solveur de contraintes et le compilateur de motifs sont les mêmes dans tous les domaines, et que seul le vocabulaire change. Son étape est planifiée. À ce commit le vocabulaire change et le code aussi. Le fichier propre du moteur nommé pattern est autre chose : les palindromes, les répétitions et les suites arithmétiques et géométriques. Le motif comme côté condition de la cascade, plusieurs facultés qui se déclenchent l'une après l'autre sur un état partagé, est le troisième échelon du chapitre 9, et conçu.

Ce qui est absent : l'induction à partir d'exemples, qui est réservée. Les classes sœurs génétique, linguistique et quantique, qui sont de la vision seulement. L'explication d'un motif sans nom, puisque rx("[a-z]+").Explain() lève une erreur parce que la classe d'analyse n'a jamais été construite. Et tout usage des classes de motifs par le reste de la bibliothèque : en dehors du dossier de la regex, des tests et de la documentation, aucune classe ne prend un motif. stzList, stzNumber, stzTable, stzMatrix et stzGraph n'ont pas de Matches(pattern). Dans la documentation, le cours d'éducation les utilise, dans un chapitre et un exercice dont la réponse est vérifiée en exécutant le programme de l'apprenant, et la galerie a quelques scripts qui les utilisent.

8. Six portes

9. Exercice

Trois petits tableaux sont donnés. Écrivez un seul motif qui n'accepte que le premier. Avant de rien exécuter, écrivez sous chacune des trois lignes imprimées ce que vous attendez et pourquoi.

t1 = new stzTable([ [ :ID, :EMAIL ], [ 1, "ali@x.org" ], [ 2, "sara@x.org" ] ])
t2 = new stzTable([ [ :ID, :EMAIL ], [ 1, "ali@x.org" ], [ 1, "sara@x.org" ] ])
t3 = new stzTable([ [ :ID, :EMAIL ], [ 1, "ali@x.org" ], [ 2, "" ] ])
# write ONE pattern, then print whether it matches t1, t2, t3, on three lines
cPattern = "{ ... }"
? Tbx(cPattern).Match(t1)
? Tbx(cPattern).Match(t2)
? Tbx(cPattern).Match(t3)
#--> 1
#--> 0
#--> 0

Exécutez-le. Une clause rejette le deuxième tableau et une autre rejette le troisième ; laquelle est laquelle ? Et que dirait le motif si l'email était une simple espace ? Je ne réponds pas en premier. Si une promesse se rompt, ne la changez pas : expliquez la sortie.

Je vous laisse celui-ci, exprès, et je le nomme un défaut. Reprenez le bloc des matrices de la section 3 et changez une seule chose dans sa dernière ligne : mettez {row(99)} là où se trouve {property(identity)}, et gardez la matrice.

? Mx("{row(99)}").Match([ [1,0], [0,1] ])

Dites ce que vous attendez avant de l'exécuter, puis exécutez-le. Ne changez pas le motif pour que la sortie vous donne raison : la section 7 dit où la bibliothèque imprime ce défaut, et pourquoi. Quand vous l'aurez trouvé, vous saurez quels termes du langage des matrices acceptent toute matrice.

Le chapitre suivant porte sur sept langages et une porte. Une porte est un runtime et jamais une syntaxe, et la porte est une : elle est la réponse à la question « et le langage X ? ».

Sept langages, une porte

Exécuté le 2026-10-15 12:59 UTC+01:00 dans la bibliothèque au commit 93d7a39bd : 10 bloc(s) sur 10 ont tenu leur promesse.

Les blocs ont été exécutés par le runtime de l'ancien langage hôte, version 1.27 ; Haro n'exécute pas encore la bibliothèque. Les binaires du moteur ont été construits dans une copie de ce commit, le plus récent le 2026-10-05 20:27 UTC+01:00 ; 1 changement(s) du moteur commité(s) après cette construction n'y sont pas.

Dans ce chapitre, je prends les deux leçons du terrain sur l'atteinte d'un autre langage, une évasion ouverte et une frontière sans chemin de sortie, et je place la porte là où elles se rencontrent. J'interroge la porte sur les langages qu'elle connaît, j'y fais passer Python et NodeJS, je lis Python et JavaScript dans un seul graphe de code, et je montre la gouvernance refusant un exécuteur sans posture. Puis je dis ce que j'ai décidé : une seule porte, et pas d'autres intégrations d'hôtes. Et je dis où en est la porte à ce commit : sa gouvernance est conçue, un chemin du retour fermé est absent, et la porte R, en développement, lève une erreur aujourd'hui. Le principe est celui que le chapitre 11 a promis : une facette est une syntaxe d'une grammaire et jamais un runtime, une porte est un runtime et jamais une syntaxe, et la porte est une.

1. Le concept, tel que le terrain le tient

Pour un programmeur qui travaille, atteindre un autre langage depuis celui dans lequel on écrit signifie l'une de deux choses. La première est une interface de fonctions étrangères, un appel dans une bibliothèque partagée. La seconde est un processus enfant, une exécution d'un interpréteur dont on analyse la sortie. Les carnets et les machines virtuelles polyglottes font le même geste avec plus de confort. C'est une connaissance générale ; le dossier ne tient aucune étude datée de ces outils, et le dit lui-même.

L'étude de terrain propre du domaine de projets, d'août 2026, a deux phrases sur ce sujet, et elles tirent en sens opposés. À la sortie, le langage hôte est l'issue de secours, et l'issue de secours est toujours prise. Elle donne deux langages internes morts d'ouverture. À l'entrée, le différenciateur est l'évasion ; un langage que l'on fait doit pouvoir être consommé depuis n'importe quelle pile. Elle donne un langage qui a calé à la frontière de son propre monde.

La leçon du terrain est donc double. Une évasion ouverte détruit un langage fermé. Et un langage sans chemin de sortie meurt à sa propre frontière. Une porte est l'endroit où ces deux leçons se rencontrent.

Il y a une seconde habitude, qui ressemble à la première et n'en est pas une. Les outils qui laissent écrire dans la syntaxe que l'on connaît par-dessus un autre moteur, un transpileur, un second front end pour un seul compilateur, je les appellerai du mot de ce livre, des facettes, que le chapitre 12 définit. La note de conception du domaine de projets à leur sujet est franche sur leur coût. La promesse d'une seconde facette est la lisibilité pour un humain qui connaît l'autre langage, et non le transfert de comportement.

2. Le premier principe

Une facette est une syntaxe d'une grammaire, et jamais un runtime. Une porte est un runtime, et jamais une syntaxe. La porte est une, et elle est la réponse à « et le langage X ? ».

La phrase propre de la vision, ratifiée en session le 28 août 2026, le dit de la porte : du code étranger dans les langages choisis, gouverné, une porte, sans autres intégrations d'hôtes. L'étude du dossier lit la paire en une ligne que je garde : la facette amène le programmeur, et la porte amène l'écosystème. Le chapitre 11 a promis que ce chapitre dirait la différence ; le chapitre 1, qu'il donnerait les sept couches. Voici la différence.

3. La forme Softanza

La liste de la porte est fermée. Les langages étrangers forment un registre, et l'hôte n'y figure pas. Quels langages la porte connaît-elle ? Interrogez-la sur six langages, puis sur l'hôte, sous le nom que les données propres de la bibliothèque lui donnent encore, celui de l'ancien langage hôte, puis sur un langage qui n'a jamais été sur la liste :

oDoor = new stzExterCode(:python)
aNames = [ "c", "nodejs", "julia", "r", "prolog", "python", "ring", "cobol" ]
for cLang in aNames
	? cLang + ": " + oDoor.IsLanguageSupported(cLang)
next
#--> c: 1
#--> nodejs: 1
#--> julia: 1
#--> r: 1
#--> prolog: 1
#--> python: 1
#--> ring: 0
#--> cobol: 0

« Et le langage X ? » a une seule réponse, et pour un langage hors de la liste c'est un refus par son nom :

try
	oNo = new stzExterCode(:cobol)
catch
	? cCatchError
done
#--> Language 'cobol' is not supported

La porte l'a refusé par son nom : Language 'cobol' is not supported !

Maintenant la porte exécute un vrai runtime. Une note sur la machine d'abord. La porte écrit un script, démarre le runtime avec lui et relit un fichier de résultat. L'emplacement par défaut de la bibliothèque pour Python n'est pas celui où cette machine le garde, aussi la porte reçoit-elle la commande nue python, que la machine résout sur son chemin. Node et R se trouvent aux emplacements par défaut de la bibliothèque. Les blocs qui démarrent un runtime sont marqués, dans le lecteur, comme touchant au système, et ils montrent la sortie qui a été enregistrée à la date de la construction.

Que rapporte un appel à Python ? Le résultat revient sous la structure propre de l'hôte, une liste, et l'appel laisse une trace :

cPython = "python"
oPy = new stzExterCode(:python)
oPy {
	SetRuntimePath(cPython)
	SetCode("
res = { 'numbers': [1, 2, 3, 4, 5], 'mean': sum([1, 2, 3, 4, 5]) / 5 }
	")
	Execute()
	? @@( Result() )
	#--> [ [ "numbers", [ 1, 2, 3, 4, 5 ] ], [ "mean", 3 ] ]
	? CallTrace()[1][:language]
	#--> python
	? CallTrace()[1][:mode]
	#--> interpreted
	? isNumber(LastCallDuration())
	#--> 1
}

Le flottant Python 3.0 est revenu sous la forme 3, dans [ "mean", 3 ]. La trace contient aussi une durée. Le bloc imprime seulement 1, la réponse de isNumber, car une durée est une horloge, et une horloge ne se promet pas.

Voilà la raison d'être de tout le volet, en une image. Chaque couche d'une solution est dans le langage qui y est le meilleur, et l'hôte passe les données en texte et les relit en retour. L'article de la bibliothèque énumère les couches : la performance système en C, les systèmes événementiels en NodeJS, le calcul scientifique en Julia, les statistiques en R, le raisonnement logique en Prolog, et l'apprentissage automatique en Python. Il y ajoute le raisonnement d'IA dans un modèle de langage, et l'intégration de la solution dans l'hôte. Voici deux d'entre elles dans un pipeline, Python calculant les moyennes de deux étudiants et NodeJS décidant. Les seuils sont de moi ; les données sont celles de l'article :

aStudents = [ [ "Alice", [ 85, 90, 78 ] ], [ "Bob", [ 72, 65, 70 ] ] ]
oPy2 = new stzExterCode(:python)
oPy2 {
	SetRuntimePath(cPython)
	SetCode("
students = " + @@(aStudents) + "
res = [ [ s[0], round(sum(s[1]) / len(s[1]), 2) ] for s in students ]
	")
	Execute()
	aAverages = Result()
}
? @@(aAverages)
#--> [ [ "Alice", 84.33 ], [ "Bob", 69 ] ]
oNode = new stzExterCode(:nodejs)
oNode {
	SetCode("
const avgs = " + @@(aAverages) + ";
const res = avgs.map(a => [ a[0], a[1] >= 80 ? 'Excellent' : 'Needs work' ]);
	")
	Execute()
	? @@( Result() )
	#--> [ [ "Alice", "Excellent" ], [ "Bob", "Needs work" ] ]
}

Les données entrent en composant la chaîne de code avec l'afficheur de listes propre à l'hôte, puisque les fonctions de conversion de l'article sont absentes (section 7).

Lesquels, ces sept ? Le titre s'engage sur un nombre, et j'ai tranché le 12 octobre 2026 lequel : les six runtimes étrangers du registre ci-dessus et l'hôte, comme les comptent l'article sur le volet et l'article sur la performance. Le modèle de langage n'en fait pas partie, car il n'est pas du tout une porte de ce volet. Les chapitres 17 et 20 font du modèle un proposeur qui ne peut pas valider, alors que les narrations l'exécutent comme un runtime de première classe par une fonction absente. La section 7 imprime cela comme une limite. Le dossier compte autrement ailleurs : sept modules de domaine dont un pour un modèle de langage, sept domaines avec l'hôte comme huitième, les six du registre sans l'hôte, les « 7 langages choisis » de la vision qu'elle n'énumère jamais, et les cinq de la conception du moteur avec COBOL. Le registre ci-dessus est celui qui s'exécute.

Une facette n'est pas une porte. Lire un langage étranger n'est pas non plus l'exécuter. Les deux langages que je nomme comme facettes prévues de Haro sont aussi les deux que la bibliothèque sait déjà lire dans un seul graphe de code. Elle ne les exécute pas et ne les écrit pas. Un seul jeu de questions répond sur les deux :

cPy = "class Animal:" + nl +
      "    def speak(self):" + nl +
      "        return '...'" + nl +
      "" + nl +
      "class Dog(Animal):" + nl +
      "    def speak(self):" + nl +
      "        return 'woof'"
cJs = "class Animal { speak() { return '...' } }" + nl +
      "class Dog extends Animal { speak() { return 'woof' } }"
StzPyCodeGraphFromSourceTS(cPy) {
	? Language()
	#--> python
	? @@( ParentsOf("Dog") )
	#--> [ "Animal" ]
	? @@( OwnersOf("speak") )
	#--> [ "Animal", "Dog" ]
}
StzJsCodeGraphFromSourceTS(cJs) {
	? Language()
	#--> javascript
	? @@( ParentsOf("Dog") )
	#--> [ "Animal" ]
	? @@( OwnersOf("speak") )
	#--> [ "Animal", "Dog" ]
}

C'est un analyseur qui produit un index de classes, de méthodes et d'héritage, et non un graphe de programme capable d'imprimer un programme. C'est une coïncidence de l'ordre du travail, et pas encore une facette. Le dossier tient une seule déclaration de moi sur les facettes. Je l'ai faite en session le 8 octobre 2026, et elle dit qu'un lien doit être fait avec la future vision de Haro et de ses langages à facettes. Dans cette vision, l'ancien langage hôte est déjà là, et Python et JavaScript sont prévus. La charte de Haro sur cette machine parle d'une grammaire et d'un texte. Sa note de conception pour une seconde facette, qui propose et ne tranche rien, recommande des afficheurs lus par des humains avant tout analyseur. Sa propre table énumère les collisions : un lecteur de Python attend une indexation à partir de zéro, et celle de Haro part de un. Le chapitre dit « prévues » seulement avec cette déclaration nommée comme source.

Une porte est gouvernée. La gouvernance a le mot pour le code étranger. external est la posture que la bibliothèque définit comme hors processus. Que répond la gouvernance avant que cette posture soit déclarée, et après ? Interrogez-la :

oGov = new stzGovernance("shop")
oGov {
	? MayExecute("python")
	#--> 0
	? Why()
	#--> refused: 'python' has NO declared trust posture
	DeclarePosture("python", :External)
	? MayExecute("python")
	#--> 1
	? Why()
	#--> allowed: posture 'external' declared
}

Le refus dit pourquoi : refused: 'python' has NO declared trust posture. Un exécuteur sans posture de confiance déclarée ne procède jamais.

Et le jumeau peut répéter un lancement avant qu'il s'exécute, signalé comme un risque. Le chapitre 24 traite du jumeau, et un bloc ici suffit pour dire ce que la porte n'utilise pas :

StzVirtualEnvironmentQ() {
	Spawn("python analyse.py")
	? NumberOfPendingSpawns()
	#--> 1
	oPlan = GenerateUpdatePlan()
}
? oPlan.Narration()
#--> Update plan (1 of 1 operations to commit):
#-->   * 1. spawn process: python analyse.py
? @@( oPlan.Risks() )
#--> [ [ 1, "RUNS an external command (side effects): spawn process: python analyse.py" ] ]

Rien n'y est exécuté, et le plan signale le lancement : RUNS an external command (side effects): spawn process: python analyse.py. Le script nommé n'existe pas.

Vient ensuite ce que j'ai décidé pour la porte, et ce que j'ai refusé.

5. Le tribunal

51_extercode_narrated prouve que le registre connaît Python, R, Julia, Prolog, C et NodeJS, et rejette un nom inconnu. Il prouve que la recherche ignore la casse (testé pour Python) ; que le code posé est le code relu ; et que la fabrique construit et transmet. Le test de fumée qu'il narre dit dans son en-tête : pas d'Execute, par son propre garde-fou. governance_narrated, scène six, prouve qu'une exécution sans posture refuse et qu'une posture déclarée procède et se nomme ; la scène sept, que les postures voyagent par la sauvegarde et le chargement. virtual_environment_twin_narrated prouve qu'un lancement mis en file ne s'exécute pas avant la validation, par un fichier témoin ; qu'une portée refuse ; et que le plan narre et signale le lancement. pycodegraph_narrated et jscodegraph_narrated prouvent les classes, les méthodes, les chaînes d'héritage, les propriétaires, l'impact et la cascade sur des sources Python et sur des sources JavaScript, hors ligne et sans le runtime. Tous deux sautent leurs scènes d'analyse quand le tree-sitter du moteur est absent, et le premier saute aussi celles de l'AST Python quand Python n'est pas sur le chemin.

Je veux être exact sur le tribunal de la porte. Une garde de l'instantané qui exécute un runtime étranger et passe est absente ; ce que tient aujourd'hui le tribunal de la porte, c'est un registre et un test de construction. Le propre relevé d'exécution du répertoire, sous une version plus ancienne du runtime, énumère trente-sept échecs. Plusieurs promesses ne peuvent pas correspondre par construction, parce que les noms de fichiers portent un suffixe aléatoire et les appels une durée.

Le terrain vient ensuite, et où il mène.

6. Le terrain, et où il mène

Le terrain mène en vitesse, et la vitesse est ce pour quoi la porte existe. L'article sur la performance mesure sept runtimes sur trois tâches, et l'hôte arrive dernier dans deux d'entre elles. Je reprends ses réserves, que le chapitre 22 énonce aussi : il n'a ni versions ni dates dans son texte, et il dit que ses temps sont relatifs à un environnement informatique précis. Trier un million d'éléments prend à l'hôte environ trente secondes et à Python environ quatre, dans la table de l'article. Je n'en imprime pas davantage.

Le terrain mène dans les runtimes qu'il peut réellement exécuter. Sur six portes, deux ont tourné sur cette machine, Node et Python ; la porte R a démarré son runtime et levé une erreur ; les trois autres n'avaient aucun runtime à démarrer. L'étude dit que sa description des outils polyglottes du terrain a été écrite d'après le genre et non relue, et je ne revendique aucune comparaison mesurée.

Le terrain mène dans l'écosystème et dans l'usage. La page de comparaison ne parle de Python que comme d'un rival ; pour couvrir ses trente lignes en Python, on assemble numpy, pandas et d'autres. La porte est la façon dont une solution Softanza les prend sans partir. Je tiens cela pour une vue, non pour un résultat : la section 3 montre la porte portant deux runtimes dans un seul pipeline, et rien dans cette page ne fait tourner numpy ou pandas.

La portée du tribunal s'arrête aujourd'hui à la porte : le processus étranger est hors de lui, et le modèle de menace du chapitre 21 met hors de portée le code déjà exécuté dans le processus.

Et le coût d'une facette, dans la table de la note : un lecteur de Python attend une indexation à partir de zéro, et celle de Haro part de un. Le littéral \n est une barre oblique inverse et un n ; deux lettres de casse différente sont une seule variable. « Tout modèle écrit Haro sous la forme qu'il connaît » n'est vrai que des graphies qui sont la minorité.

7. La limite

• construitun registre fermé de six runtimes étrangers et un appel par processus qui rapporte sous forme de listes les résultats de Python et de NodeJS ; les postures de confiance ; la répétition d'un lancement par le jumeau ; un lecteur de Python et de JavaScript vers un seul graphe de code
• conçula porte gouvernée, avec une posture demandée à l'appel ; le pont du moteur et ses trois niveaux ; la bibliothèque de domaines au-dessus de la porte ; Haro portant une syntaxe Python et une syntaxe JavaScript
• absentune porte dont le chemin du retour est fermé ; une porte pour R qui s'exécute ; une exécution réussie d'un runtime étranger dans le tribunal de la bibliothèque ; le modèle d'IA comme porte

Le mot gouverné est une conception. La porte interroge-t-elle la gouvernance avant de s'exécuter ? Voici le bloc qui le montre :

oGov2 = new stzGovernance("shop")
? oGov2.MayExecute("python")
#--> 0
oPy3 = new stzExterCode(:python)
oPy3 {
	SetRuntimePath(cPython)
	SetCode("res = 6 * 7")
	Execute()
	? Result()
	#--> 42
}

La gouvernance a dit non, et la porte s'est exécutée quand même, et a renvoyé 42 ! Rien dans le répertoire de la porte ne mentionne la gouvernance ni la posture. La porte appelle directement le système, et non le jumeau.

Le chemin du retour n'est pas encore fermé. Le fichier de résultat est lu par le propre eval de l'hôte, et une chaîne qui sort du runtime étranger est enveloppée entre apostrophes simples sans échappement. Une chaîne étrangère qui porte une apostrophe et un appel peut-elle atteindre le code de l'hôte ? La fonction utilisée ici est upper, inoffensive exprès :

oPy4 = new stzExterCode(:python)
oPy4.SetRuntimePath(cPython)
oPy4.SetCode(`
res = "x' + upper('y') + 'z"
`)
oPy4.Execute()
? oPy4.Result()
#--> xYz

Le fichier de résultat contenait 'x' + upper('y') + 'z', et Result() l'a évalué. Les données sont devenues un appel, et le bloc a imprimé xYz ! Une simple apostrophe dans des données, it's fine, écrit une chaîne que l'hôte ne peut pas lire, et la méthode imprime l'erreur et renvoie le texte brut. C'est la même classe de limite ouverte que la liste du chapitre 11 dans une phrase naturelle. Je n'ai pas testé la conversion des cinq autres langages.

La porte R est en développement : aujourd'hui elle lève une erreur à chaque appel, parce que son script généré contient un identifiant qui commence par un tiret bas, que R rejette. Je l'ai confirmé avec R sur un fichier d'une ligne. Et la trace enregistre un code de sortie de 0 pour un appel qui a échoué. Le code passe un 0 littéral à l'enregistreur, et l'échec n'est détecté que par l'absence du fichier de résultat :

oStat = new stzExterCode(:R)
oStat {
	SetCode("res <- c(1, 2, 3)")
	bRaised = 0
	try
		Execute()
	catch
		bRaised = 1
	done
	? bRaised
	#--> 1
	? CallTrace()[1][:exitcode]
	#--> 0
}

L'appel a levé une erreur, et la trace garde pourtant 0 ! Le message de R était en français sur cette machine, je ne le promets donc pas. C'est la limite de la porte à ce commit, dans la voix de la liste ouverte du chapitre 11. Les exécutions ci-dessus en sont la preuve. Gouverner la porte est conçu et pas encore construit, et le mot « gouvernée » de la vision reste donc une conception. Le chemin du retour n'est pas encore fermé, puisque les données reviennent par un fichier que l'hôte évalue. Et la porte R, en développement, lève une erreur à chaque appel aujourd'hui.

Ce qui est conçu en plus : le pont polyglotte propre du moteur, que la conception du moteur marque comme prévu. Un module de même nom dans le macroplan, un registre de chaînes, a été marqué fait alors qu'il n'avait aucune source. Puis les trois niveaux pour Python, dont seul le sous-processus externe existe. Puis la bibliothèque de domaines au-dessus de la porte, dont je n'ai trouvé aucune classe dans le code. Et les facettes, une note qui propose et ne tranche rien.

Ce qui est absent : les fonctions de l'article qui font entrer les données, @@R, @@C, XC() et XAI(), qui ne sont définies dans aucun fichier. Des fabriques existent pour Python, R, Julia et Prolog. Les portes C et NodeJS ne sont atteintes que par la classe. Le modèle d'IA n'est pas du tout une porte de ce volet ; la fonction de l'article qui l'exécute dans l'hôte est le contraire de la loi du chapitre 17, et le livre ne l'enseigne pas.

Et une forme de porte que je n'ai pas exécutée : Julia, C et Prolog, pour lesquels aucun runtime n'est installé ici. Et une troisième relation, nommée dans l'étude à côté de la porte : l'adaptateur qui colle une solution trouvée sur internet dans un autre langage et la change un peu. range0, le range de Python comme fonction de l'hôte, a une garde. Le relevé propre du dossier lui compte cinq échecs sur des plages qui devraient être vides et un sur la forme de tranche ':5:-1'. Je n'en ai rien exécuté.

Six lectures de la porte suivent, une pour chacun de ceux qui la rencontrent.

8. Six portes

9. Exercice

Vous construisez une petite solution avec trois tâches : trier un million de nombres, décider lequel de deux étudiants réussit, et vérifier dans un arbre généalogique qui est l'ancêtre de qui. Pour chaque tâche, choisissez dans la liste des couches de la section 3 le langage qui possède sa couche, et écrivez votre raison en une ligne. Puis, sans rien exécuter, écrivez la promesse pour chaque ligne de ce bloc, et exécutez-le :

oDoor = new stzExterCode(:python)
# promise: the door answers "julia" with ...
# promise: the door answers "ring" with ...
# promise: asking for "cobol" raises with the sentence ...
oGov = new stzGovernance("mine")
# promise: oGov.MayExecute("prolog") before any posture is declared gives ...
# promise: after oGov.DeclarePosture("prolog", :External), it gives ...

La dernière promesse est celle qui compte. Si vous appelez maintenant la porte pour Prolog, la gouvernance aura-t-elle été interrogée ? Écrivez oui ou non, et pourquoi. Puis lisez la section 7. Si une promesse se brise, ne la changez pas : expliquez d'abord la sortie.

Je vous laisse celui-ci. La section 7 dit qu'une simple apostrophe dans des données fait écrire au chemin du retour une chaîne que l'hôte ne peut pas lire, et je n'ai imprimé aucune sortie pour elle. Voici le bloc de la section 7 avec un seul changement, it's fine comme chaîne étrangère :

oPy4 = new stzExterCode(:python)
oPy4.SetRuntimePath(cPython)
oPy4.SetCode(`
res = "it's fine"
`)
oPy4.Execute()
? oPy4.Result()

Exécutez-le. Lisez ce que la méthode imprime et ce qu'elle renvoie, et expliquez les deux avant de toucher au bloc ; la page dit pourquoi dans la section 7, là où le chemin du retour n'est pas fermé. Quand vous le pourrez, vous saurez pourquoi un chemin du retour qui évalue ses données n'est pas fermé.

Le chapitre 17 ouvre la partie sur l'intelligence par sa loi : programmatique par défaut, le modèle en dernier, l'admission plutôt que la génération. Un modèle d'IA y est une faculté parmi d'autres, la dernière appelée, et ce qu'il dit est une proposition que le tribunal admet ou refuse.

Loi : programmatique par défaut, le modèle en dernier, l'admission plutôt que la génération

Exécuté le 2026-10-15 12:59 UTC+01:00 dans la bibliothèque au commit 93d7a39bd : 8 bloc(s) sur 8 ont tenu leur promesse.

Les blocs ont été exécutés par le runtime de l'ancien langage hôte, version 1.27 ; Haro n'exécute pas encore la bibliothèque. Les binaires du moteur ont été construits dans une copie de ce commit, le plus récent le 2026-10-05 20:27 UTC+01:00 ; 1 changement(s) du moteur commité(s) après cette construction n'y sont pas.

Dans ce chapitre, j'énonce la loi de la partie IV et je la fais tourner. Je commence par ma définition de l'intelligence et par un modèle de langage de domaine sans aucun neurone, qui répond, dit pourquoi, et refuse ce qu'on ne lui a jamais dit. Puis je montre une conversation qui vous interroge, un fait que personne n'a enregistré prouvé à partir d'une seule loi déclarée, un modèle d'IA tenu à proposer, et un agent dont l'esprit est du code, refusé à la barrière. Je dis ce que j'ai refusé, quelles gardes prouvent chaque bloc, et où le terrain mène. Vient ensuite la limite, imprimée comme l'étape qu'elle est : une question posée avec d'autres mots, et une réponse là où un refus est l'étape suivante. La loi elle-même tient en une phrase : l'esprit est programmatique par défaut, un modèle est une faculté parmi d'autres, la dernière appelée, et ce qu'il dit est une proposition que le tribunal admet ou refuse.

Ce que l'âge de l'IA change ici

Dans les deux mouvements qui précèdent celui-ci, l'âge de l'IA a changé une chose chacun. En programmation, il a changé qui écrit le code. Dans les langages, il a changé qui prononce la phrase. Ici il change tout, parce que ce mouvement porte sur l'intelligence elle-même, et que le terrain emploie désormais le mot surtout pour dire une seule chose : un grand modèle de langage à l'intérieur de votre logiciel.

Alors ce chapitre fait ce que font les deux autres chapitres de loi, et énonce la loi de sa partie avant les preuves. Il dit aussi comment la partie dépend des autres, parce que l'ordre de ce livre va du familier au nouveau. L'intelligence, dans Softanza, est gouvernée par ce qui l'a précédée. Le tribunal qui juge la phrase d'un modèle est le tribunal de la Partie II, qui juge le code quel que soit son auteur. La phrase qu'il juge est une phrase d'un langage fermé, qui est la Partie III. On ne peut mettre un modèle en dernier que parce qu'il y a quelque chose de solide à mettre en premier.

1. Le concept, tel que le terrain le tient

Demandez au terrain ce qui rend une application intelligente et la réponse est un modèle d'IA. Un agent d'IA, au sens du terrain, est un modèle dans une boucle avec des outils, une mémoire et un but. La liste de courses pour en construire un en 2026 est longue. Il faut un projet en Python, un fournisseur de modèle, un framework qui câble la boucle comme un graphe, un magasin de vecteurs pour la mémoire, des outils avec des schémas typés, un service de traçage, et un chapitre de conseils de sécurité. La mémoire est souvent de la récupération : une collection de documents, découpés en morceaux, cherchés par similarité et collés dans le prompt.

La sécurité, dans ce tableau, est une propriété de l'agent. C'est l'alignement, les garde-fous, un prompt qui demande confirmation, une case marquée « humain dans la boucle ». Le terrain a aussi appris à tenir la sortie d'un modèle dans une forme, avec des grammaires qui contraignent ce qu'il peut émettre. Tout cela est un travail sérieux, et une partie est bonne. Tout cela partage une hypothèse : le modèle est l'esprit, et tout le reste est autour de lui.

2. Le premier principe

L'esprit est programmatique par défaut ; un modèle est une faculté parmi d'autres, la dernière appelée, et ce qu'il dit est une proposition que le tribunal admet ou refuse.

3. La forme Softanza

Commençons par ma définition, parce que tout ce qui suit en découle. L'intelligence est la capacité computationnelle de dériver de nouvelles connaissances à partir de connaissances existantes. Rien dans cette phrase n'a besoin d'un modèle.

Voici un modèle de langage de domaine sans aucun neurone, forgé à partir d'un petit graphe de connaissances d'un restaurant. Que répond-il à partir de ce qui a été enregistré, et que dit-il de la coupe du monde de 1998 ? Exécutez-le :

oKB = new stzKnowledgeGraph("restaurant")
oKB {
	Know("margherita", "dish")
	KnowRelation("margherita", "contains", "tomato-sauce")
	KnowRelation("margherita", "contains", "mozzarella")
}
oDLM = StzDlmQ(oKB)
oDLM {
	? Ask("margherita contains what?")
	#--> Margherita contains tomato-sauce and mozzarella.
	? Why()
	#--> recorded fact(s): 'margherita' contains tomato-sauce, mozzarella
	? AskXT("margherita contains what?")[:certainty]
	#--> 1
	? Ask("who won the 1998 world cup?")
	#--> That is outside the 'restaurant' domain (I know 1 entities and 1 relations).
}

Il répond, dit pourquoi (recorded fact(s): 'margherita' contains tomato-sauce, mozzarella), et énonce sa certitude (1). Et quand on lui demande ce qu'il ne sait pas, il ne devine pas. Il refuse, et il vous dit combien son monde est petit : I know 1 entities and 1 relations. Une entité, parce que seule margherita a été déclarée par Know, et une relation, contains : les objets des deux faits ne sont pas comptés comme des entités. Un refus qui nomme sa frontière vaut mieux qu'une réponse fluide qui n'en a pas. C'est mon point de vue.

Voici maintenant la deuxième pièce, celle qui retourne le dialogue habituel. Sur le terrain, vous soumettez un prompt à la machine et gardez ce qui en sort. Ici le système vous interroge. Que demande-t-il, et que se passe-t-il si vous essayez de conclure avant d'avoir répondu ?

StzKnowledgeGraphQ("menu") {
	Know("margherita", "dish")
	Know("tiramisu", "dish")
	AddConversationQ("setup").SetGoal(StzGoalQ().RequireEach("dish", "contains"))
	? AskIn("setup")
	#--> What does 'margherita' have for 'contains'?  (why: every dish needs 'contains')
	try
		ConcludeIn("setup", "menu")
	catch
		? cCatchError
	done
	#--> Can't conclude: 2 gap(s) remain -- the wise-coding loop is not done. Ask the next question.
}

Un but a été déclaré : chaque plat doit dire ce qu'il contient. L'écart entre le but et ce qui est connu a engendré la question, et la question porte sa raison. Le monde ne peut pas être clos tant qu'il est incomplet : Can't conclude: 2 gap(s) remain. Le chapitre 18 montre les cinq façons de répondre : une option d'une liste, une structure de données, une formule, une phrase, ou des exemples. Trois sont câblées ; la formule et les exemples sont absents. Un modèle d'IA, s'il y en a un, vient après toutes, pas en premier.

La troisième pièce est la dérivation, ma définition à l'œuvre. Une loi est déclarée, et un fait que personne n'a enregistré est prouvé :

StzKnowledgeGraphQ("kitchen") {
	ConstrainRelation("contains", :Transitive)
	KnowRelation("margherita", "contains", "tomato-sauce").
	    KnowRelation("tomato-sauce", "contains", "tomato")
	? Prove([ "margherita", "contains", "tomato" ])[:narration]
	#--> proved: margherita contains tomato-sauce contains tomato
	? Prove([ "margherita", "contains", "luigi" ])[:narration]
	#--> not derivable: no recorded fact or lawful chain gives 'margherita' contains 'luigi'
}

De la connaissance nouvelle à partir de la connaissance existante, avec sa chaîne écrite en toutes lettres ! Et un « non » aussi certain que le « oui », parce qu'il est le résultat d'une recherche, pas d'une humeur. La page l'a imprimé ainsi : not derivable: no recorded fact or lawful chain gives 'margherita' contains 'luigi'. Il est certain de ce qui est enregistré et déclaré, pas du monde : il dit not derivable, pas « faux ». Pas de récupération, pas d'entraînement. Ajouter un fait fait que le système sait davantage ; ajouter une loi lui fait raisonner plus loin.

Puis le modèle d'IA. Il est le bienvenu, et il est tenu. Branchez la sortie d'un modèle directement sur un effet, ici l'envoi d'un message. La composition est-elle saine ?

oG = new stzAgentGraph("mailer")
oG {
	AddLLMActor("writer")
	AddEffect("send")
	Proposes("writer", "send")
	? IsSound()
	#--> 0
	? len(Violations())
	#--> 3
}

Elle ne l'est pas : IsSound() a imprimé 0, et elle est refusée avant que rien ne s'exécute ! Trois lois se déclenchent, et len(Violations()) a imprimé 3 : tout effet doit passer une barrière, tout texte libre doit avoir un endroit sûr où atterrir, et tout effet doit laisser un témoin. Que détient un acteur modèle qui puisse agir ? Aucun modèle d'IA n'est chargé dans le bloc qui le demande : la réponse est fixée d'avance, comme un test fixe une réponse golden, afin que la page s'exécute de la même façon chaque nuit. Interrogez-en un :

oF = new stzLLMFunction("sum")
oF {
	SetPrompt("summarize: {input}")
	Budget(2)
	SeedAnswer("hello world", "a greeting")
}
oLLM = new stzLLMAgent("summarizer")
oLLM {
	SetSkillFrom(oF)
	? Propose("hello world")
	#--> a greeting
	? HoldsEffectful()
	#--> 0
}

Rien. Un acteur modèle ne détient aucune capacité à effet ; il propose, et c'est tout son pouvoir. HoldsEffectful() a imprimé 0. Ce que le bloc prouve ne dépend pas du modèle : quoi qu'il dise, il ne détient rien qui puisse agir.

Et l'agent programmatique lui-même a un esprit fait de code. Une compétence est une condition et une action, et elle se déclenche sur ce que l'agent perçoit. La gouvernance soumet l'acte à la barrière avant qu'il ait lieu. Quand le stock est bas et que la compétence veut commander, l'acte passe-t-il ?

oRog = new stzPIAgent("rogue-bot")
oRog.MemoryQ().Learn("stock", "level", "low")
oRog.GovernanceQ().DeclareRisk("order-stock", 2)
oSk = new stzAgentSkill("restock")
oSk.SetWhen(func oM { return oM.Fact("stock", "level", "low") })
oSk.SetDoes(func oM { oM.Learn("stock", "level", "ordered")  return 1 })
oRog.AddGovernedSkill(oSk, "order-stock")
? oRog.Pursue()
#--> 0
? oRog.DecisionLog()[1][:why]
#--> refused: 'rogue-bot' lacks PERMISSION (can) for 'order-stock'

Le stock est bas, la compétence veut commander, et l'agent n'a jamais reçu la permission. Pursue() a imprimé 0 : la gouvernance l'a refusé ! Il ne se passe rien, et le journal dit pourquoi, par son nom : refused: 'rogue-bot' lacks PERMISSION (can) for 'order-stock'. Le monde est comme il était.

Mettez les pièces sur une ligne et vous avez la pile que la vision de la plateforme nomme son Étoile polaire, ratifiée le 27 septembre 2026 : percevoir, décider, réagir, apprendre. Rien de tout cela n'a besoin d'un modèle de langage. C'est une conception, pas un agent assemblé. Dans cette conception, la perception classe le monde dans le graphe de connaissances. Un planificateur décide. Des règles réagissent. L'agent note ses plans et garde le meilleur. Les pièces existent dans la bibliothèque à côté de l'agent, pas encore dedans : l'agent ci-dessus n'en appelle aucune. Un modèle peut se tenir à côté de chaque étape comme une faculté de plus, et aucune ne dépend de lui.

Le chapitre 18 raconte les cinq registres d'une réponse et la conversation qui demande. Le chapitre 19 raconte le modèle de langage de domaine, de son premier échelon, sans neurones, à son second, entraîné sur les faits propres du premier et rien d'autre. Le chapitre 20 raconte l'agent qui ne peut pas vous nuire : il propose, un atelier répète, le tribunal juge, et seul un acteur gouverné valide. Le chapitre 21 raconte le tribunal lui-même. Le chapitre 22 compare tout cela au terrain, et imprime où le terrain mène.

5. Le tribunal

Chaque bloc ci-dessus repose sur une garde. dlm_narrated prouve le modèle de langage de domaine : des réponses avec leur pourquoi, le refus hors du domaine, la complétion tenue aux entités et aux relations du domaine, un lot autonome, et un second échelon entraîné sur son propre corpus. wisecoding_narrated prouve la conversation qui demande et le refus de conclure. knowledge_integration_narrated prouve la dérivation et le « non » certain. agentgraph_narrated prouve qu'un modèle branché directement sur un effet n'est pas sain, que la forme gouvernée l'est, et qu'un acteur modèle propose et ne valide jamais. piagent_narrated prouve l'agent programmatique et son refus à la barrière. ownagentstack_narrated prouve la liste honnête des agents propres de la bibliothèque.

Ces six gardes prouvent ce qui a tourné ; la section suivante dit où le terrain mène.

6. Le terrain, et où il mène

Le terrain mène en portée. Ses frameworks se connectent à des services hébergés de toutes sortes, ses magasins cherchent dans des collections ouvertes de documents, et ses boucles appellent les plus grands modèles disponibles à chaque étape. L'inversion de Softanza, constituer un domaine et en dériver, mène sur un domaine constitué, et sur le web ouvert le terrain mène aujourd'hui. Quand la tâche est un travail de langage ouvert sur une matière que personne ne peut constituer, résumer des documents arbitraires ou faire de la recherche sur le web, la pile du terrain est le bon outil. Le dossier le dit en ces mots.

Le terrain mène sur le marché. Il existe aujourd'hui un marché du travail pour sa pile ; celui de cette pile est à venir.

Le terrain mène sur les modèles d'IA. Le second échelon du modèle de langage de domaine, tel que construit, est un petit modèle neuronal de paires de mots, et la fonderie au-delà du bigramme est conçue (chapitre 19). Softanza ne construit pas les grands générateurs et ne rivalise pas avec eux.

Là où je pense que la loi se distingue, c'est en trois endroits. Une décision ici ne coûte rien, s'exécute hors ligne et donne la même réponse chaque jour, de sorte qu'on peut la tester avec des promesses ordinaires. Un modèle d'IA ici ne peut pas agir, par construction, pas par vigilance. Et la phrase d'un modèle, là où l'on en emploie un, peut être tenue à la grammaire d'un langage déclaré avant d'être émise, au lieu d'être vérifiée puis relancée après.

La section suivante dit où la loi s'arrête.

7. La limite

• construitle premier échelon du modèle de langage de domaine et son second, un petit bigramme ; la conversation qui demande ; la dérivation avec sa preuve ; l'agent programmatique ; la barrière qui refuse un modèle d'IA non gouverné
• conçula cascade de la machine pensante entre les facultés ; la pile de décision, ses pièces à côté de l'agent et pas encore dedans ; l'unité typée de prédiction, une conception du domaine de projets avec cinq étapes de validation et aucune chaîne de celles-ci dans la bibliothèque ; la négociation entre un agent et son relecteur
• absentquatre des cinq agents propres de la bibliothèque, dont l'induction à partir d'exemples

Ce qui est construit : le premier échelon du modèle de langage de domaine et son second, un petit bigramme, la conversation qui demande, la dérivation avec sa preuve, l'agent programmatique, et la barrière qui refuse une composition non gouvernée.

Ce qui est conçu : la machine pensante du chapitre 9, où de nombreuses facultés partagent un état et se déclenchent en cascade jusqu'à ce qu'il se stabilise. La pile de décision qui perçoit, décide, réagit et apprend, dont les pièces existent à côté de l'agent et pas encore dedans. L'unité typée de prédiction, que le chapitre 19 raconte comme une conception du domaine de projets, validée en cinq étapes dans cette conception et enchaînée nulle part dans la bibliothèque. La conversation entre un agent et celui qui relit son plan : le plan atteint désormais l'agent, et la conversation à son sujet pas encore.

Ce qui est absent : quatre des cinq agents propres de la bibliothèque. Combien la bibliothèque en déclare-t-elle, et combien sont câblés ? La liste le dit clairement :

? len(StzOwnAgents())
#--> 5
? StzOwnAgentIsWired("wise-coder")
#--> 1
? StzOwnAgentIsWired("induction")
#--> 0

Le validateur, le classeur, le planificateur et l'agent qui induirait un motif à partir de vos exemples sont déclarés et réservés. Ainsi le cinquième registre d'une réponse, les exemples, attend un agent qui n'existe pas encore.

Et une limite du premier échelon que vous rencontrerez dès que vous reformulerez une question. Il ne reconnaît une relation que par le mot avec lequel elle a été déclarée. Que fait-il quand vous demandez avec d'autres mots ?

? oDLM.Ask("what does margherita contain?")
#--> Margherita is a dish.

Il n'a pas refusé ! Il a imprimé Margherita is a dish. Cette réponse est vraie, et ce n'est pas ce qui était demandé. Par la loi de ce chapitre, la réponse ici est un refus, et ce refus est l'étape suivante. Je l'imprime ici parce qu'une loi se montre par une page qui imprime son étape telle qu'elle est, limite comprise. La demande à la bibliothèque est de refuser une question dont le verbe n'est pas une relation déclarée.

8. Six portes

Voici maintenant l'exercice : un domaine à vous, et les promesses que vous attendez.

9. Exercice

Construisez un domaine à vous avec trois faits : une boutique, une clinique, une classe. Avant d'exécuter quoi que ce soit, écrivez sous chaque ligne la promesse que vous attendez : une question dans le domaine, une hors du domaine. Ajoutez un but selon lequel chaque élément doit avoir une relation, et écrivez la première question que le système vous posera. Puis exécutez-le.

Si une promesse est brisée, ne changez pas la promesse pour qu'elle corresponde à la sortie. Expliquez d'abord la sortie.

Je vous laisse celui-ci, volontairement. La section 7 montre une question à laquelle le premier échelon a répondu alors que la loi veut un refus, et je ne l'ai pas corrigé. Reprenez votre propre domaine et posez de nouveau l'une de vos questions promises avec d'autres mots, et un verbe que vous n'avez pas déclaré comme relation. Regardez ce qui revient et comparez-le à ce que vous avez demandé. Puis dites en une phrase pourquoi il a répondu, et quelles lignes de la section 7 vous le disent.

Quand vous l'aurez résolu, vous saurez pourquoi un premier échelon qui ne reconnaît une relation que par le mot avec lequel elle a été déclarée peut répondre à une question que vous n'avez pas posée.

Le chapitre 18 est Les cinq registres, et les conversations qui demandent. Son principe : une réponse peut venir sous cinq formes, et quelle que soit la forme, elle n'est qu'un candidat, et ce sont les règles du monde qui décident si elle devient connaissance.

Les cinq registres, et les conversations qui demandent

Exécuté le 2026-10-15 12:59 UTC+01:00 dans la bibliothèque au commit 93d7a39bd : 15 bloc(s) sur 15 ont tenu leur promesse.

Les blocs ont été exécutés par le runtime de l'ancien langage hôte, version 1.27 ; Haro n'exécute pas encore la bibliothèque. Les binaires du moteur ont été construits dans une copie de ce commit, le plus récent le 2026-10-05 20:27 UTC+01:00 ; 1 changement(s) du moteur commité(s) après cette construction n'y sont pas.

Dans ce chapitre, je vous montre les cinq formes qu'une réponse peut prendre, une option, une structure de données, une formule, une phrase et des exemples. Puis je montre ce que la porte gouvernée fait de chacune. Je vous dis quelles sont les trois qui s'exécutent et les deux qui ne s'exécutent pas, et ce que devient un refus une fois écrit : il attend une personne, avec son contexte et une durée de vie. Je laisse s'exécuter la conversation où il n'y a personne, et je montre ce qu'une conversation peut et ne peut pas faire en arabe et en haoussa. Quelle que soit la forme, une réponse n'est qu'un candidat, et ce sont les règles du monde qui décident si elle devient connaissance.

1. Le concept, tel que le terrain le tient

Deux pratiques se rencontrent dans l'idée d'une conversation qui demande, et une troisième se tient derrière son dernier registre. Toute cette section est de la connaissance générale, non une étude du dossier.

La première est le remplissage d'emplacements (slot filling). Un cadre de dialogue demande à l'utilisateur les éléments manquants d'un formulaire jusqu'à ce que le formulaire soit plein. Les frameworks du terrain comprennent le texte libre avec des modèles entraînés, parlent sur de nombreux canaux et livrent des connecteurs, et ils demandent au concepteur d'écrire des intentions et des flux dans leur propre langage. Ils prennent la réponse de l'utilisateur pour la réponse et agissent dessus.

La deuxième est le vibe coding, un nom mis en circulation en 2025 : l'humain soumet un prompt, le modèle d'IA produit, l'humain garde ce qui fonctionne.

La troisième est la programmation par l'exemple. Les tableurs remplissent une colonne à partir de deux exemples que vous avez tapés. La recherche appelle cela la synthèse inductive, et l'ère des modèles a fait de l'exemple la façon de piloter un modèle.

2. Le premier principe

Une réponse peut venir sous cinq formes. Quelle que soit la forme, elle n'est qu'un candidat, et ce sont les règles du monde qui décident si elle devient connaissance.

Le document de conception le dit en une phrase que je garde : l'expression est libre, l'admission est gouvernée. Le dossier tient cette phrase, captée à partir de ma directive du 13 juillet 2026. Il ne tient aucune phrase de moi sur le pourquoi de ces cinq registres et pas quatre ou six, ni sur le moment où j'ai opposé le wise coding au vibe coding.

3. La forme Softanza

Le chapitre 17 a montré une conversation qui demande, et qui refuse de conclure tant qu'un écart est ouvert. Ce chapitre porte sur la réponse. Les cinq registres sont cinq formes qu'une réponse peut prendre : une option choisie par son numéro, une structure de données, une formule, une phrase, et des exemples. Je vous montrerai chacun, et je vous dirai ceux qui ne s'exécutent pas.

Le premier registre : une option. Quand le monde connaît déjà des valeurs, comment la question les offre-t-elle ? Exécutez-le :

oKB = new stzKnowledgeGraph("pizzeria")
oKB {
	Know("pizza1", "dish")
	Know("pizza2", "dish")
	Know("pizza3", "dish")
	Know("pizza4", "dish")
	AddConversationQ("frame").SetGoal(StzGoalQ().RequireEach("dish", "topping"))
	AskIn("frame")
	ReplyIn("frame", "cheese")
	AskIn("frame")
	ReplyIn("frame", "olives")
	? AskIn("frame")
	#--> Which 'topping' does 'pizza3' have? (1) cheese  (2) olives -- or answer freely.  (why: every dish needs 'topping')
	? @@(ReplyIn("frame", 2)[:admitted])
	#--> [ "olives" ]
}

La question offre les valeurs connues sous forme de numéros, et 2 a choisi olives.

Que répond la porte à un numéro que personne n'a offert ? Exécutez-le :

oKB {
	? AskIn("frame")
	#--> Which 'topping' does 'pizza4' have? (1) cheese  (2) olives -- or answer freely.  (why: every dish needs 'topping')
	aV = ReplyIn("frame", 99)
	? @@(aV[:admitted])
	#--> [ ]
	? @@(aV[:refused])
	#--> [ [ "(99)", "no such option" ] ]
	? ConversationQ("frame").Checkpoints()[1][:why]
	#--> no option (99) was offered -- 2 option(s) on the table
	? aV[:goalState]
	#--> pursuing
}

La porte l'a refusé, et a dit no such option ! Le point de contrôle dit pourquoi : no option (99) was offered -- 2 option(s) on the table. Une raison, et un compte des options sur la table. Il ne les énumère pas, et la question suivante offre de nouveau les mêmes options : (1) cheese (2) olives. Le refus ne devine jamais une valeur, il arrive à une personne comme un point de contrôle, et le but reste pursuing. Cela compte pour la section 7.

La question est une donnée avant d'être un texte. Elle porte une force, qui est what tant que le monde ne sait rien et which dès qu'il connaît une valeur, et les options. N'importe quel médium peut la rendre :

oKF = new stzKnowledgeGraph("pizzeria2")
oKF {
	Know("p1", "dish")
	Know("p2", "dish")
	AddConversationQ("f").SetGoal(StzGoalQ().RequireEach("dish", "topping"))
	? AskInXT("f")[:force]
	#--> what
	ReplyIn("f", "cheese")
	aQ = AskInXT("f")
	? aQ[:force]
	#--> which
	? @@(aQ[:options])
	#--> [ "cheese" ]
}

Le deuxième registre : une structure de données. Que devient une liste de deux valeurs envoyée comme une seule réponse ? Exécutez-le :

oKD = new stzKnowledgeGraph("desserts")
oKD {
	Know("tiramisu", "dish")
	AddConversationQ("setup").SetGoal(StzGoalQ().RequireEach("dish", "contains"))
	AskIn("setup")
	aV = ReplyIn("setup", [ "mascarpone", "espresso" ])
	? @@(aV[:admitted])
	#--> [ "mascarpone", "espresso" ]
	? aV[:goalState]
	#--> fulfilled
}

Une liste de valeurs est prise comme les valeurs, et chacune passe par la même porte.

Le quatrième registre : une phrase. Je saute le troisième un moment, parce que c'est l'un des deux qui ne s'exécutent pas. Comment une expression de la forme « X and Y » ou « X, Y » est-elle lue ? La conversation tient une transcription où chaque admission est narrée et où l'accomplissement du but est consigné :

oKM = new stzKnowledgeGraph("menu")
oKM {
	Know("margherita", "dish")
	AddConversationQ("setup").SetGoal(StzGoalQ().RequireEach("dish", "contains"))
	AskIn("setup")
	ReplyIn("setup", "tomato-sauce and mozzarella")
	? ConversationQ("setup").Transcript()
	#--> SOFTANZA: Goal adopted -- this conversation is now accountable for it.
	#--> SOFTANZA: What does 'margherita' have for 'contains'?  (why: every dish needs 'contains')
	#--> YOU:      tomato-sauce and mozzarella
	#-->   -> admitted: 'margherita' contains 'tomato-sauce'
	#-->   -> admitted: 'margherita' contains 'mozzarella'
	#--> SOFTANZA: Goal fulfilled: every required slot is filled in 'menu'
}

Elle est lue comme deux valeurs, chacune jugée : la transcription tient admitted: 'margherita' contains 'tomato-sauce' et admitted: 'margherita' contains 'mozzarella'. « Naturel » signifie ici un séparateur sur les virgules et sur le mot anglais « and ». La couche naturelle de la bibliothèque, que j'utiliserai dans un instant, n'est pas appelée par la conversation.

Quand une réponse porte plusieurs valeurs, et que le monde en permet une. Que fait une relation déclarée unique d'une réponse qui porte deux valeurs ? Exécutez-le :

oKS = new stzKnowledgeGraph("staffing")
oKS {
	AddConversationQ("s").SetGoal(StzGoalQ().RequireOne("kitchen3", "led-by"))
	ConstrainRelation("led-by", :Unique)
	AskIn("s")
	aV = ReplyIn("s", "mario and giovanni")
	? @@(aV[:admitted])
	#--> [ "mario" ]
	? @@(aV[:refused])
	#--> [ [ "giovanni", "'kitchen3' already bears 'led-by' (to 'mario'); the relation is :Unique" ] ]
	? len(ConversationQ("s").Checkpoints())
	#--> 1
}

La première valeur a été admise, et la seconde refusée avec la raison de la loi : 'kitchen3' already bears 'led-by' (to 'mario'); the relation is :Unique. Le refus arrive à une personne, comme un seul point de contrôle. Prenez garde à ce que vous lisez là-dedans. Le choix entre Mario et Giovanni a été fait par l'ordre. Il n'a pas été fait par une personne. La conception promet autre chose, et la section 7 dit quoi.

Le troisième registre, la formule. Une formule tapée en réponse est-elle évaluée ? Exécutez-le :

oKP = new stzKnowledgeGraph("shop")
oKP {
	Know("tea", "product")
	AddConversationQ("price").SetGoal(StzGoalQ().RequireEach("product", "price"))
	AskIn("price")
	? @@(ReplyIn("price", "=12*3")[:admitted])
	#--> [ "=12*3" ]
	? Query([ "tea", "price", "?o" ])[1]
	#--> =12*3
}

Elle ne l'est pas. Le prix du thé est maintenant le texte =12*3 ! Je l'ai découvert en l'exécutant, et le code est muet sur un registre de formule. Le dossier liste le travail de wise coding sur les registres 3 et 5 comme en attente, non acheminé.

Le cinquième registre, les exemples. Que fait la porte d'exemples offerts sous forme de paires ? L'agent qui les lirait figure sur la liste, et réservé :

oKX = new stzKnowledgeGraph("phones")
oKX {
	Know("contact1", "contact")
	AddConversationQ("fmt").SetGoal(StzGoalQ().RequireEach("contact", "number-pattern"))
	AskIn("fmt")
	aV = ReplyIn("fmt", [ [ "+216-21-298-374", "valid" ], [ "+33-6-12-34-56-78", "valid" ] ])
	? @@(aV[:admitted])
	#--> [ ]
	? @@(aV[:refused])
	#--> [ ]
	? aV[:goalState]
	#--> pursuing
	? len(ConversationQ("fmt").Checkpoints())
	#--> 0
}
try
	StzOwnAgent("induction")
catch
	? cCatchError
done
#--> Softanza's own agent 'induction' is RESERVED, not wired yet -- refusing rather than returning a stub (LAW 3). See StzOwnAgents().

Ni admis ni refusés : [ ] et [ ], le but toujours pursuing, et pas un seul point de contrôle ! Ce n'est pas le refus que décrit le protocole. C'est le silence. Je tiens le silence pour la pire réponse, comme une vue et non comme un résultat : le lecteur qui a offert les exemples n'est pas informé qu'ils n'ont pas été compris. J'ai trouvé une seconde forme de la même faute, avec les mêmes exemples tapés comme une seule chaîne, jointe par une virgule. L'exercice à la fin de ce chapitre vous la remet.

Ainsi trois des cinq registres sont câblés, l'un d'eux sous sa forme la plus simple, un séparateur. Deux ne le sont pas. Je préfère que vous le rencontriez ici plutôt que sur une page de moi qui aurait dit cinq.

Il reste le refus lui-même, et ce qu'il devient.

Ce qui arrive à un refus

Un refus attend une personne, avec son contexte. Une durée de vie peut être fixée pour qu'un refus périmé quitte la liste vivante sans être supprimé :

oKT = new stzKnowledgeGraph("ttl")
oKT {
	AddConversationQ("t").SetGoal(StzGoalQ().RequireOne("kitchen", "led-by"))
	AskIn("t")
	ReplyIn("t", 7)
	? len(ConversationQ("t").Checkpoints())
	#--> 1
	ConversationQ("t").SetCheckpointTTL(1)
	AskIn("t")
	AskIn("t")
	? len(ConversationQ("t").Checkpoints())
	#--> 0
	? len(ConversationQ("t").AllCheckpoints())
	#--> 1
}

Rien n'est supprimé. L'expiration porte sur ce qui a encore besoin d'une personne, et la trace d'audit garde tout. Chaque appel ici est enchaîné depuis ConversationQ, parce qu'une copie conservée ne ferait silencieusement rien : le commentaire de la garde l'explique.

Une conversation est responsable d'un seul but, et elle s'achève en accomplissant le but ou en le révoquant au dossier. Une conversation révoquée ne demande rien et ne peut pas conclure :

oKG = new stzKnowledgeGraph("lifecycle")
oKG {
	Know("d1", "dish")
	Know("d2", "dish")
	AddConversationQ("s1").SetGoal(StzGoalQ().RequireEach("dish", "sauce"))
	AddConversationQ("s2").SetGoal(StzGoalQ().RequireEach("dish", "garnish"))
	? ConversationQ("s1").GoalState()
	#--> pursuing
	AskIn("s1")
	ReplyIn("s1", "pesto")
	AskIn("s1")
	ReplyIn("s1", "pesto")
	? ConversationQ("s1").GoalState()
	#--> fulfilled
	? ConversationQ("s1").GoalWhy()
	#--> every required slot is filled in 'lifecycle'
	AskIn("s2")
	ConversationQ("s2").RevokeGoal("out of scope tonight")
	? ConversationQ("s2").GoalState()
	#--> revoked
	? ConversationQ("s2").GoalWhy()
	#--> out of scope tonight
	? len(OpenConversations())
	#--> 0
}

Programmatique par défaut : la conversation où il n'y a personne

La loi du chapitre 17 dit que les conversations ont lieu d'abord dans le code. Voici la conversation sans personne et sans modèle. Un agent d'IA de la bibliothèque demande, une source de réponses (une simple fonction) répond, et chaque réponse passe par la même porte. Là où la source n'a pas de réponse, l'agent invente-t-il ? Exécutez-le :

oKW = new stzKnowledgeGraph("menu")
oKW.Know("margherita", "dish")
oKW.Know("tiramisu", "dish")
answers = [ [ "margherita", "tomato-sauce" ], [ "tiramisu", "mascarpone" ] ]
aR = StzOwnAgent("wise-coder").PursueGoal(StzGoalQ().RequireEach("dish", "contains"), oKW, func subj, rel {
	for a in answers
		if a[1] = subj
			return a[2]
		ok
	next
	return ""
})
? aR[:filled]
#--> 1
? aR[:asked]
#--> 2
? aR[:why]
#--> goal filled in 2 question(s), governed admission throughout
oKV = new stzKnowledgeGraph("desserts")
oKV.Know("panna-cotta", "dish")
aR2 = StzOwnAgent("wise-coder").PursueGoal(StzGoalQ().RequireEach("dish", "contains"), oKV, func subj, rel { return "" })
? aR2[:filled]
#--> 0
? aR2[:why]
#--> stopped: no answer for 'panna-cotta' / 'contains' -- gap left for a human

Il n'invente pas. Il s'arrête, dit stopped: no answer for 'panna-cotta' / 'contains' -- gap left for a human, et laisse l'écart à une personne. Des cinq agents propres de la bibliothèque, c'est celui qui est câblé. Les quatre autres sont réservés, et en demander un lève une erreur, comme l'a imprimé le bloc du cinquième registre : RESERVED, not wired yet -- refusing rather than returning a stub. Ce n'est jamais un bouchon.

En arabe, et en haoussa

Les chapitres 2 et 11 ont montré la couche naturelle en haoussa. Voici ce que la conversation peut et ne peut pas faire avec les langues, dit en trois blocs, parce que les trois sont différents.

Premièrement, les données. Les noms, les valeurs et les listes en écriture arabe passent la barrière exactement comme les latins. Les mots autour d'eux, le cadre de la question, restent en anglais :

oKA = new stzKnowledgeGraph("مطعم")
oKA {
	Know("بيتزا", "dish")
	AddConversationQ("c").SetGoal(StzGoalQ().RequireEach("dish", "contains"))
	? AskIn("c")
	#--> What does 'بيتزا' have for 'contains'?  (why: every dish needs 'contains')
	aV = ReplyIn("c", [ "جبن", "طماطم" ])
	? @@(aV[:admitted])
	#--> [ "جبن", "طماطم" ]
	? aV[:goalState]
	#--> fulfilled
}

Les valeurs arabes ont passé la barrière, et le but se lit fulfilled.

Deuxièmement, le candidat. Une phrase en haoussa peut produire une valeur dans la couche naturelle, et la valeur, envoyée comme réponse, passe par la même porte. Les deux étapes sont celles de l'appelant : la conversation n'appelle pas elle-même la couche naturelle. C'est le principe du chapitre en petit, puisque l'expression est libre et l'admission gouvernée. Le graphe replie la casse de la valeur, de sorte que le JIBINI imprimé est admis comme 'jibini' :

oKH = new stzKnowledgeGraph("menu")
oKH {
	Know("pizza", "dish")
	AddConversationQ("c").SetGoal(StzGoalQ().RequireEach("dish", "contains"))
	AskIn("c")
}
cCandidate = NaturallyIn("ha", "Yi rubutu dauke 'jibini' Maida shi").Result()
? cCandidate
#--> JIBINI
aV = oKH.ReplyIn("c", cCandidate)
? aV[:narration]
#--> admitted: 'pizza' contains 'jibini'

Troisièmement, la question dans la langue de l'apprenant. Le tuteur est un consommateur de la conversation : il utilise l'écart que la conversation nomme, et il choisit les mots pour le dire en quatre langues. Les phrases sont des gabarits. Le commentaire du code dit lui-même que les formulations en français, en arabe et en haoussa sont un brouillon en attente d'un relecteur natif. Lisez les trois ci-dessous comme des brouillons, et non comme un texte relu :

oEx = StzProgramQ("../../education/program").CourseQ("elementary-introduction").ExerciseQ("ex-01-01")
oEx {
	? GapText("finds", "en")
	#--> Where are the repeated items? Which line of your program asks for their positions? (why: the mental model finds before it applies)
	? GapText("finds", "fr")
	#--> Où sont les éléments répétés ? Quelle ligne de votre programme demande leurs positions ? (pourquoi : le modèle mental trouve avant d'agir)
	? GapText("finds", "ar")
	#--> أين العناصر المكررة؟ أيّ سطر في برنامجك يسأل عن مواضعها؟ (لماذا: النموذج الذهني يبحث قبل أن يطبّق)
	? GapText("finds", "ha")
	#--> Ina abubuwan da aka maimaita? Wane layi a shirinka yake tambayar wurarensu? (dalili: tsarin tunani yana nemo kafin ya aiwatar)
}

Ainsi la bibliothèque ne peut pas demander en arabe ou en haoussa par AskIn. Ce qu'elle peut faire, c'est tenir les données dans n'importe quelle écriture, prendre un candidat calculé dans n'importe quel paquet de langue, et laisser le tuteur dire l'écart en quatre langues. Une valeur qui contient un espace lève une erreur pour le moment (la section 7 donne la preuve). Et le séparateur ne connaît que la virgule et le mot anglais « and » : les connecteurs « et » en français, « da » en haoussa et « و » en arabe ne sont pas des connecteurs. Les trois phrases ci-dessus sont celles de la bibliothèque, imprimées telles quelles, et le code les appelle un brouillon en attente d'un relecteur natif. Je n'ai écrit moi-même aucune phrase en arabe ou en haoussa.

Un modèle d'IA est une fluidité, jamais l'esprit

Sans modèle, que dit une conversation de sa propre fluidité ? Exécutez-le :

oKF2 = new stzKnowledgeGraph("fluency-space")
oKF2 {
	AddConversation("f")
	? ConversationQ("f").Fluency()
	#--> plain
	ConversationQ("f").SetFluency(:neural)
	? ConversationQ("f").Fluency()
	#--> neural
	? ConversationQ("f").IsFluencyNeural()
	#--> 0
}

plain : elle reste sur son plancher déterministe et le dit. Le mot « neural » peut être posé, et Fluency() le répète, mais IsFluencyNeural() répond 0 ! Le mot n'est revendiqué que lorsqu'un modèle est là.

5. Le tribunal

wisecoding_narrated prouve que l'écart est calculé à partir de l'espace, et que la question est menée par le système, nomme son sujet et dit pourquoi il demande. Elle prouve que « X and Y » et une structure de données sont admis. Elle prouve qu'une loi d'unicité refuse par la conversation et que le refus atteint un point de contrôle. Elle prouve enfin que conclure avec un écart ouvert est refusé. wisecoding_rich_narrated prouve le but suivi jusqu'à accompli ou révoqué, le cadre, et les options numérotées. Elle prouve le refus d'un numéro que personne n'a offert, la durée de vie d'un point de contrôle, et la fluidité qui n'est revendiquée qu'avec un modèle. ownagentstack_narrated prouve la liste de cinq, le wise coder câblé, l'agent réservé qui lève une erreur, et l'écart laissé à une personne. tutor_gaps_narrated prouve la question d'écart de l'exercice dans chaque langue, et qu'une étape sans question dans une langue est rouge, jamais une autre langue. Elle écrit des répertoires, aussi le livre la compte et ne l'exécute pas ; le bloc du tuteur ci-dessus ne fait que lire le cours.

Trois des gardes impriment leur propre total et se terminent en appelant pf(), qui imprime le temps et la version du runtime puis arrête l'exécution par une levée d'erreur. C'est leur façon de finir. tutor_gaps_narrated se termine par Summary(), qui imprime le total et un état, et ne lève pas d'erreur.

Ce que le terrain fait mieux, et où le dossier se distingue, vient ensuite.

6. Le terrain, et où il mène

Le terrain mène en compréhension. Un cadre de dialogue, tel que le terrain le tient, lit le texte libre avec des modèles entraînés, parle sur de nombreux canaux et livre des connecteurs. Le dossier dit ce qui manque à Softanza, dans son propre compte : le mot « WhatsApp » n'apparaît dans aucun fichier de code ni aucun document de conception de la bibliothèque. La conversation demande un emplacement à la fois, sur un graphe que l'utilisateur doit d'abord avoir déclaré, et elle ne comprend pas une réponse ouverte.

Le terrain mène sur les exemples. La programmation par l'exemple est, telle que le terrain la tient, livrée dans les tableurs aujourd'hui. Softanza n'a aucune induction, et le dossier le dit : rien n'induit encore. Une recherche de « induce », « from examples » et « infer » dans le répertoire des expressions régulières ne trouve rien.

Le terrain est honnête sur les coûts, et le dossier aussi. Plusieurs candidats est le cas normal quand on demande une règle à partir d'exemples. Un motif induit de trois exemples les surapprend. Le remède que nomme le dossier est la question qui distingue deux candidats. Et l'index qui porterait les exemples est, selon les mots de l'étude, aussi propre que les étiquettes des méthodes, dans lesquelles l'étude compte environ quatre-vingt-cinq fautes d'orthographe.

Voici où je pense que le dossier se distingue. Chaque réponse, sous quelque forme que ce soit, est jugée par les lois du monde avant de compter, avec la raison. La session garde une transcription et un point de contrôle qu'une personne peut lire. La réponse du terrain est un prompt, et l'humain garde ce qui sort.

La limite vient ensuite, et elle nomme ce qui est construit, ce qui est conçu et ce qui est absent.

7. La limite

• construitle but, l'écart et la question avec sa raison ; une réponse sous forme d'option, de structure de données ou de phrase découpée sur les virgules et sur le mot « and » ; la porte gouvernée avec ses refus ; le point de contrôle avec sa durée de vie ; le but accompli ou révoqué ; un agent d'IA câblé qui s'arrête là où il devrait inventer
• conçuplusieurs lectures d'une même réponse, énumérées pour que la personne choisisse ; les alternatives les plus proches nommées après un refus ; l'exemple réécrit comme promesse
• absentle registre de la formule ; le registre de l'exemple ; une conversation dont la question est formulée en arabe, en haoussa ou en français ; une valeur qui contient un espace

Ce qui est construit : le but, l'écart, la question avec sa raison, le cadre ; le premier registre, le deuxième, et le quatrième sous la forme d'un séparateur ; la porte gouvernée avec ses refus. Et le point de contrôle et sa durée de vie ; le but accompli ou révoqué ; la transcription ; un agent câblé ; la phrase d'écart du tuteur en quatre langues.

Ce qui est conçu : la branche plusieurs acceptables telle que la conception l'écrit. Le protocole dit que lorsque plusieurs lectures d'une réponse sont acceptables, le système les énumère et la personne choisit. Ce qui est construit, ce sont deux choses différentes. Les valeurs déjà connues deviennent des options numérotées dans la question, avant la réponse. Et une réponse qui porte plusieurs valeurs voit chacune jugée à part, la première étant gardée sous une loi d'unicité. Aucune étape ne présente des lectures concurrentes d'une même réponse. Et la branche aucune acceptable telle qu'écrite : la raison est construite, et les alternatives acceptables les plus proches ne le sont pas. Le refus énonce une raison, et pour un numéro, combien d'options étaient sur la table. Et l'exemple réécrit comme promesse : la page du site by example, lue le 9 octobre 2026, l'appelle une règle de la conception, non construite. Les deux pages du site à ce sujet, wise et by example, disent « avec les alternatives les plus proches » et « la personne choisit ». Les deux pages promettent plus que le code. Le code câble trois registres sur cinq. Le dossier nomme la formule et les exemples comme en attente, non acheminés, et pour ce chapitre ils sont absents.

Ce qui est absent : le registre de la formule ; le registre de l'exemple, et l'agent d'induction derrière lui ; une conversation formulée en arabe, en haoussa ou en français ; et une valeur avec un espace. Lors de mon exécution du 8 octobre 2026, sur la version de la bibliothèque que ce livre exécute, ReplyIn a levé une erreur sur chaque valeur contenant un espace que j'ai essayée. L'erreur était une variable non initialisée. Les trois étaient « tomato sauce », « fromage et tomate », « jibini da tumatir ». Appelée directement, la porte a renvoyé correctement le refus. Aucun bloc de ce livre n'enregistre l'un ou l'autre résultat, de sorte que l'exécution du livre ne les montre pas. La conversation aurait dû refuser avec la raison et écrire un point de contrôle, et elle ne le fait pas. C'est une demande à la bibliothèque, et l'exercice ci-dessous n'emploie pas de valeur avec un espace.

8. Six portes

9. Exercice

Choisissez un petit monde à vous, une boutique, une classe, une clinique, avec quatre entités d'un même type et un but selon lequel chacune a besoin d'une relation. Avant d'exécuter quoi que ce soit, écrivez sous chacune des cinq réponses ci-dessous le verdict que vous attendez : admis, refusé avec une raison, ou ni l'un ni l'autre.

1. un mot simple ;
2. un numéro qui choisit une valeur que la première réponse a fait connaître ;
3. un numéro que personne n'a offert ;
4. deux valeurs à la fois, pour une relation que vous avez déclarée unique ;
5. une liste de deux paires d'exemples.

Puis exécutez-le. Une réponse admise épuise la question : appelez de nouveau AskIn avant la réponse suivante. Si une promesse se brise, ne changez pas la promesse : expliquez d'abord la sortie.

oWorld = new stzKnowledgeGraph("my-world")
oWorld.Know("item1", "thing")
oWorld.Know("item2", "thing")
oWorld.AddConversationQ("mine").SetGoal(StzGoalQ().RequireEach("thing", "colour"))
oWorld.AskIn("mine")
# your five replies here, each with the verdict you expect

La cinquième réponse produit du silence aujourd'hui, et c'est la leçon de l'exercice. Si la bibliothèque la transforme plus tard en refus, la réponse attendue change. Exécutez-le à la date et au commit indiqués au pied de la page.

Je vous laisse celui-ci. Prenez le bloc du cinquième registre de la section 3 et changez une seule chose : envoyez les deux numéros de téléphone comme une seule chaîne, jointe par une virgule, et non comme deux paires.

oKX = new stzKnowledgeGraph("phones")
oKX.Know("contact1", "contact")
oKX.AddConversationQ("fmt").SetGoal(StzGoalQ().RequireEach("contact", "number-pattern"))
oKX.AskIn("fmt")
aV = oKX.ReplyIn("fmt", "+216-21-298-374,+33-6-12-34-56-78")
? @@(aV[:admitted])
? aV[:goalState]

Exécutez-le, puis lisez ce qui a été admis et ce que dit le but, et décidez si c'est ce que vous vouliez remettre à la porte en fait d'exemples. La section 4, dans son dernier refus, et la section 7, dans le registre des exemples absent, disent pourquoi j'y vois une faute. Quand vous saurez dire pourquoi, vous saurez ce que la porte a fait de vos exemples, et pourquoi ce n'est pas de l'induction.

C'est ce que j'appelle le wise coding. La plateforme pose la question à laquelle vous devez répondre, dans le registre que vous choisissez, et refuse de deviner la réponse à votre place : l'expression est libre, l'admission est gouvernée. Le chapitre 17 a énoncé la loi. Ce chapitre a fait tourner ses cinq registres, et montré où le cinquième reste encore muet.

Le chapitre suivant porte sur le modèle de langage de domaine. Là, la prochaine chose que dit le modèle est une unité vérifiable de votre monde, un fait que vos règles admettent ou refusent, et jamais un jeton.

Le modèle de langage de domaine

Exécuté le 2026-10-15 12:59 UTC+01:00 dans la bibliothèque au commit 93d7a39bd : 7 bloc(s) sur 7 ont tenu leur promesse.

Les blocs ont été exécutés par le runtime de l'ancien langage hôte, version 1.27 ; Haro n'exécute pas encore la bibliothèque. Les binaires du moteur ont été construits dans une copie de ce commit, le plus récent le 2026-10-05 20:27 UTC+01:00 ; 1 changement(s) du moteur commité(s) après cette construction n'y sont pas.

Dans ce chapitre, je forge un modèle de langage de domaine à partir d'une base de connaissances, et personne n'écrit son texte d'entraînement : chaque phrase est un fait enregistré. Il a deux échelons. Le premier répond à partir de ces faits et n'a aucun neurone. Le second, un petit modèle neuronal, est fluide dans la grammaire du domaine et se trompe sur les faits. Je montre la grammaire qui refuse une phrase malformée et le graphe qui refuse une phrase fausse. Je dis quelles pièces la bibliothèque contient et lesquelles le lecteur doit encore composer. Le principe est celui-ci : la prochaine chose que dit le modèle est une unité vérifiable de votre monde, un fait que vos règles admettent ou refusent, jamais un jeton.

1. Le concept, tel que le terrain le tient

Un modèle de langage prédit le jeton suivant. Un jeton est un fragment de texte sans type, sans rôle et sans contrainte : il peut être la fin d'un mot, un espace, un crochet. Tout ce qu'un modèle dit est construit en choisissant des jetons l'un après l'autre. Tout ce qui rend le résultat utile, que ce soit une phrase valide, qu'elle soit vraie, qu'elle respecte un schéma, est vérifié après coup ou imposé de l'extérieur.

Le terrain a fait fonctionner cela avec trois outils. On adapte un modèle d'IA général à un domaine en l'entraînant davantage sur les documents du domaine. On lui donne les documents pertinents au moment de la question, récupérés par similarité. Et on contraint son décodage avec une grammaire, de sorte qu'il ne puisse pas produire une phrase malformée, comme l'a montré le chapitre 11. Tous trois gardent la même unité : le jeton.

La section suivante nomme la seule chose que je change : l'unité.

2. Le premier principe

La prochaine chose que dit le modèle est une unité vérifiable de votre monde, un fait que vos règles admettent ou refusent, jamais un jeton.

Dans la conception la barrière est la même pour tous les modèles de ce genre : les générations sont des propositions, et le graphe et ses règles décident de l'admission.

La section 3 montre la forme qu'il prend, et l'exécute.

3. La forme Softanza

Je l'appelle un modèle de langage de domaine, et il a deux échelons. Le premier n'a aucun neurone et a été montré au chapitre 17 : il répond à partir de faits enregistrés, dit pourquoi, et refuse hors de son domaine. Le second est un petit modèle neuronal, facultatif, qui lui donne de la fluidité. Dans la conception, les deux échelons aboutissent à la même barrière ; ici, la barrière est l'Admit du dernier bloc de cette section, appelé à la main.

D'où vient le texte d'entraînement ? Construisez une petite base de connaissances, rendez-la, et lisez le corpus et le vocabulaire qu'elle donne.

oKB = new stzKnowledgeGraph("restaurant")
oKB {
	Know("margherita", "dish")
	Know("tiramisu", "dish")
	Know("chianti", "wine")
	KnowRelation("margherita", "contains", "tomato-sauce")
	KnowRelation("margherita", "contains", "mozzarella")
	KnowRelation("margherita", "pairs-with", "chianti")
}
oDLM = StzDlmQ(oKB)
oDLM {
	? @@( GenerateCorpus() )
	#--> [ "margherita is a dish.", "tiramisu is a dish.", "chianti is a wine.", "margherita contains tomato-sauce.", "margherita contains mozzarella.", "margherita pairs-with chianti." ]
	? @@( Tokenizer() )
	#--> [ "<unk>", "margherita", "tiramisu", "chianti", "dish", "wine", "contains", "pairs-with", "is", "a", "tomato-sauce", "mozzarella" ]
	? @@( Tokenize("margherita contains something-new") )
	#--> [ 2, 7, 1 ]
}

Personne n'a écrit ce corpus : chacune de ses six phrases est un fait de la base de connaissances, rendu. Le vocabulaire est fermé, chaque mot que le domaine contient avec une première entrée pour l'inconnu. Douze entrées, et something-new, un mot hors du domaine, est envoyé sur la première : [ 2, 7, 1 ]. « Correct par construction » vaut ici dans le seul sens que le code lui donne : chaque phrase est un fait enregistré. Cela ne vaut pas encore dans le sens que la conception visait ; la section 7 dit où.

La complétion est contrainte au domaine. Qu'offre le modèle après une entité qui porte des faits, après une relation, après un fragment, et après un mot que le domaine ne contient pas ? Exécutez-le :

oDLM {
	? @@( Complete("margherita") )
	#--> [ "contains", "pairs-with" ]
	? @@( Complete("contains") )
	#--> [ "tomato-sauce", "mozzarella" ]
	? @@( Complete("tira") )
	#--> [ "tiramisu" ]
	? @@( Complete("pizza") )
	#--> [ ]
}

Après une entité qui porte des faits, ses relations : [ "contains", "pairs-with" ]. Après une relation, seulement ses objets : [ "tomato-sauce", "mozzarella" ]. Un fragment se complète en entités, et un mot que le domaine ne contient pas se complète en rien : [ ]. La garde qui le prouve l'appelle « the grammar spirit ». C'est une consultation dans les faits, non un décodage sous une grammaire compilée. Et elle voit un mot, pas la phrase jusque-là : Complete("contains") renvoie les objets de chaque fait contains, quel que soit son sujet.

La grammaire elle-même peut être dérivée de la base de connaissances, et ici le lecteur de ce livre doit écrire la dérivation. Il n'y a dans la bibliothèque aucun appel qui transforme une base de connaissances en grammaire, et la conception en fait la tâche du premier échelon. Mais les pièces se composent. Le vocabulaire du domaine devient les choix d'un schéma du chapitre 11, le schéma se compile en grammaire, et la grammaire n'a aucun chemin pour un mot hors du domaine. Les trois règles qu'elle imprime en dernier, pour le texte, le nombre et le booléen, sont celles que le compilateur émet toujours, et aucun champ ici ne les emploie :

aLex = oDLM.Lexicon()
acObjects = []
for aFact in oKB.Facts()
	if aFact[2] != "is-a" and find(acObjects, aFact[3]) = 0
		acObjects + aFact[3]
	ok
next
oS = StzOutputSchemaQ([
	[ :field = "subject",  :type = :oneof, :choices = aLex[:entities] ],
	[ :field = "relation", :type = :oneof, :choices = aLex[:relations] ],
	[ :field = "object",   :type = :oneof, :choices = acObjects ]
])
? oS.ToGBNF()
#--> root ::= subject-line relation-line object-line
#    subject-line ::= "subject: " ("margherita" | "tiramisu" | "chianti") "\n"
#    relation-line ::= "relation: " ("contains" | "pairs-with") "\n"
#    object-line ::= "object: " ("tomato-sauce" | "mozzarella" | "chianti") "\n"
#    text ::= [^\n]+
#    number ::= "-"? [0-9]+ ("." [0-9]+)?
#    boolean ::= ("yes" | "no" | "true" | "false")
cGood = "subject: margherita" + nl + "relation: contains" + nl + "object: mozzarella" + nl
cOut  = "subject: pizza" + nl + "relation: contains" + nl + "object: mozzarella" + nl
cLie  = "subject: tiramisu" + nl + "relation: contains" + nl + "object: mozzarella" + nl
? oS.Accepts(cGood)
#--> 1
? oS.Accepts(cOut)
#--> 0
? oS.Accepts(cLie)
#--> 1
? oDLM.Ask("tiramisu contains what?")
#--> I hold no 'contains' knowledge about 'tiramisu'.

Regardez ensemble les quatre dernières lignes. La grammaire accepte le mensonge ! Il a la bonne forme, et chaque mot est dans le domaine. Interrogé sur ce que contient un tiramisu, le modèle répond : I hold no 'contains' knowledge about 'tiramisu'. Une grammaire est une barrière pour la forme ; la vérité appartient au graphe.

Un modèle de langage de domaine est un fichier qui voyage. Il est sauvegardé en texte simple, lisible et comparable par diff, sans binaire et sans poids. Un second modèle qui n'a jamais lu la base de connaissances peut-il répondre à partir de lui, et exécuter ses propres tests ? Sauvegardez-le, relisez-le, et chargez-le :

oDLM {
	AddGolden("what is margherita", "Margherita is a dish.")
	AddGolden("what is the weather today?",
		"That is outside the 'restaurant' domain (I know 3 entities and 2 relations).")
	cFile = Save("probe_dlm")
}
? cFile
#--> probe_dlm.zdlm
? read(cFile)
#--> dlm "restaurant"
#    entities
#        margherita | dish
#        tiramisu | dish
#        chianti | wine
#    relations
#        contains
#        pairs-with
#    facts
#        margherita | contains | tomato-sauce
#        margherita | contains | mozzarella
#        margherita | pairs-with | chianti
#    laws
#    goldens
#        what is margherita | Margherita is a dish.
#        what is the weather today? | That is outside the 'restaurant' domain (I know 3 entities and 2 relations).
oShipped = StzDlmQ("")
oShipped {
	LoadFrom(cFile)
	? Ask("what is tiramisu")
	#--> Tiramisu is a dish.
	? @@( RunGoldens() )
	#--> [ [ "total", 2 ], [ "passed", 2 ], [ "failed", [ ] ] ]
}
remove(cFile)
? fexists(cFile)
#--> 0

Le second modèle répond : Tiramisu is a dish. Le refus voyage avec le lot comme test golden, et le modèle qui n'a jamais lu le graphe le passe aussi ! La section des lois est vide parce qu'aucune loi n'a été déclarée avant que le modèle soit forgé ; déclarez qu'une relation est unique, forgez de nouveau, et la ligne apparaît.

Maintenant le second échelon. C'est un petit modèle neuronal entraîné sur le corpus que vous avez vu, sans enseignant, et il peut être exporté comme fichier de modèle. Quelle est sa taille, et apprend-il ?

oDLM {
	TrainNeuralRung(500)
	? NeuralWhy()
	#--> neural bigram rung: 15 pairs over a 12-word vocab; trained 500 epoch(s), lr 0.50: loss 2.57 -> 0.70
	? NextToken("is")
	#--> a
	? NextTokenConfidence("is")
	#--> 1.00
	cGguf = ExportNeuralGguf("probe_bigram")
}
? cGguf
#--> probe_bigram.gguf
? StzEngineNeuralGgufInspect(cGguf)
#--> 2
remove(cGguf)

Il est petit : une seule couche qui prédit le mot suivant à partir du précédent, 15 pairs over a 12-word vocab. Et il apprend : loss 2.57 -> 0.70. La bibliothèque inspecte le fichier exporté et imprime 2, les deux tenseurs qu'il contient, un poids et un biais. Je ne prétends pas qu'un autre runtime le charge comme générateur de texte. Il s'entraîne en une fraction de seconde, hors ligne, et donne les mêmes nombres à chaque exécution.

Que dit un modèle neuronal comme celui-ci ? Il est fluide dans la grammaire du domaine, et il se trompe sur les faits. C'est la raison de la barrière :

aCorpus = oDLM.GenerateCorpus()
for cSeed in [ "tiramisu", "chianti", "margherita" ]
	cSaid = oDLM.NeuralGenerate(cSeed, 3)
	? cSaid + "  ->  " + ( find(aCorpus, cSaid + ".") > 0 )
next
#--> tiramisu is a wine  ->  0
#    chianti is a wine  ->  1
#    margherita contains mozzarella is  ->  0

« Tiramisu is a wine » est faux, parce que le tiramisu est un plat. « Chianti is a wine » est vrai. Et « margherita contains mozzarella is » est une phrase qui n'en finit pas, parce que le bigramme n'a aucun mot qui termine une phrase. Le test contre le corpus est une barrière grossière, et il refuserait un fait vrai que personne n'a enregistré. La vraie barrière est le graphe et ses lois. Que répond le graphe quand la fausse phrase lui est proposée comme un fait ? Déclarez la loi, puis proposez :

oKB {
	ConstrainRelation("is-a", :Unique)
	aVerdict = Admit("tiramisu", "is-a", "wine", [ :source = "rung 2" ])
	? aVerdict[:admitted]
	#--> 0
	? aVerdict[:why]
	#--> 'tiramisu' already bears 'is-a' (to 'dish'); the relation is :Unique
	? @@( Contradictions() )
	#--> [ [ [ "subject", "tiramisu" ], [ "relation", "is-a" ], [ "existing", "dish" ], [ "attempted", "wine" ], [ "source", "rung 2" ] ] ]
	? Admit("pizza", "is-a", "dish", [ :source = "rung 2" ])[:why]
	#--> admitted: 'pizza' is-a 'dish'
}