Versions 4.45.0

Ce document dit ce qui est PRÉVU, par ordre de priorité. Il complète les deux autres : CHANTIERS.md porte ce qui est ouvert et connu comme défaut ; VERSION.md raconte ce qui est fait. Ici : ce qu'on a décidé de faire, et qu'on n'a pas commencé.

⚠ Un projet qui démarre sort d'ici et devient un point de CHANTIERS.md. Un projet abandonné sort aussi, avec sa raison — les listes qui ne font que grandir cessent d'être lues.

Comment lire les priorités

⚠ Un projet ne passe en ✅ qu'une fois CONSTATÉ fermé, jamais dès qu'il est corrigé — et il reste ici quelque temps plutôt que de disparaître : ce qui l'a rendu nécessaire vaut souvent mieux que ce qui l'a réglé.

---

🔴 Traduire le site — plusieurs langues, au choix du visiteur

Demandé le 02/09/2026. Détecter la langue du visiteur, et lui laisser en changer par un menu.

Ce que la mesure dit : 26 367 mots de texte visible, sur 50 fichiers — 15 757 pour le site public, 10 528 pour le panel. Soit quatorze jours de traduction humaine par langue, ou environ 3 € de traduction automatique — mais surtout, tout est à refaire à chaque modification d'une page.

Trois décisions à prendre avant d'écrire une ligne :

• ⚠⚠ Le pays n'est pas la langue. Détecter par l'adresse IP demande une base GeoIP à tenir à jour et se trompe souvent — Belgique, Suisse, Canada, ou simplement quelqu'un en déplacement. L'en-tête Accept-Language, que le navigateur envoie déjà, dit la langue que la personne a choisie. Le menu déroulant reste, pour ceux qui veulent autre chose.
• ⚠⚠ La charte (1 882 mots) et le règlement (1 492 mots) ne seront PAS traduits automatiquement. C'est ce que les gens acceptent en se connectant : deux versions qui ne disent pas exactement la même chose posent la question de savoir laquelle fait foi.
• ⚠ Le panel s'adresse à l'exploitant, pas aux visiteurs. Ses 10 528 mots doublent le travail pour une seule personne.

Le découpage proposé, du plus utile au moins :

📌 Le vrai chantier n'est pas la traduction, c'est l'extraction. Les phrases sont aujourd'hui écrites dans le HTML des pages ; il faut les remplacer par des appels à une fonction de traduction. Mécanique, mais 50 fichiers.

Prochain pas : une maquette sur l'accueil seul, pour voir ce que ça donne avant de s'engager sur les 49 autres pages.

---

🔴 Éprouver le site sur tous les navigateurs

Demandé le 02/09/2026. Le site est du HTML et du CSS standard, donc a priori portable — mais « a priori » ne vaut rien tant que ce n'est pas mesuré.

Ce qu'il faut regarder, par ordre de risque :

• Safari (macOS et iOS) — le plus susceptible de diverger. Le WebSocket du chat, et les propriétés CSS récentes comme color-mix(), employée dans la feuille du client.
• Firefox — moteur différent de Chrome ; les écarts y sont rares mais réels.
• Chrome et Edge — même moteur, déjà éprouvés de fait.

⚠ Le chat est le point sensible : il ouvre une connexion permanente, et c'est là que les navigateurs se distinguent le plus.

---

⏸️ macOS — en attente d'un moyen de tester

Ouvert le 31/08/2026. La configuration est écrite et prête dans electron-builder.yml, avec les deux architectures et les raisons de chaque choix. Il ne manque que la machine.

Trois obstacles, et le troisième est le vrai :

1. electron-builder ne peut pas produire de .dmg depuis Windows — hdiutil n'existe que sur macOS.
2. Une machine virtuelle sur PC ne construit et n'éprouve que l'architecture x64 : tous les Mac vendus depuis 2020 sont en arm64.
3. ⚠⚠ Sans signature Apple, le paquet s'annonce « endommagé » au premier lancement — pas « non signé ». Quelqu'un qui ne connaît pas macOS en conclut que le logiciel est corrompu, referme, et n'écrit jamais pour le dire. La mise à jour automatique ne fonctionne pas non plus.

📌 Le blocage n'est pas technique mais une décision : un compte développeur Apple, à 99 $/an. Sans lui, mieux vaut annoncer « macOS : à venir » qu'un paquet qui fait peur.

Les chemins possibles, si la décision est prise : GitHub Actions (matériel Apple, légal, et il signe si on lui fournit le certificat), un Mac d'occasion, ou un service de location.

---

✅ Le site installable sur téléphone — fait le 03/09/2026

Demandé après avoir écarté une application native : le panel est déjà responsive, une application de magasin aurait coûté 99 $/an et un Mac, aurait été rejetée par Apple comme simple habillage d'un site, et aurait mis chaque correctif derrière 24 à 48 h de revue.

Constaté sur Android : icône sur l'écran d'accueil, ouverture en application, réaction au mode avion. Deux manques sont apparus à l'usage — les tailles d'icônes, et un bouton pour fermer, qui n'existait pas en mode plein écran.

⚠ Ce qui reste ouvert : le panel n'a toujours pas été mesuré sur un écran de téléphone, et les voies (b), (c) et (d) de MOBILE.md restent non engagées.

---

✅ La mise à jour sous Linux — corrigée le 03/09/2026, publiée en 0.6.10

Ouvert et fermé le même jour. Le client choisit désormais son paquet dans la clé plateformes : l'installateur sous Windows, le .deb confié au gestionnaire de paquets du bureau, l'AppImage déposée avec son chemin. Le format se reconnaît à la variable APPIMAGE qu'exporte le runtime AppImage.

⚠ Ce qui reste vrai, et qui ne se répare pas : les postes Linux déjà installés en 0.6.9 ne recevront pas ce correctif tout seuls — pour le recevoir il faudrait réussir une mise à jour, c'est-à-dire précisément ce qui ne marchait pas. Les notes de la 0.6.10 le disent, et renvoient à la page Télécharger pour le passage manuel, une seule fois.

📌 La leçon, elle, ne se referme pas : deux listes des mêmes choses à deux endroits, dont une seule est dérivée. La clé plateformes existait depuis le 31/08 et personne ne la lisait ; tous les constats étaient verts des deux côtés, parce qu'ils mesuraient ce qui est annoncé, jamais ce qui aurait dû l'être.

---

🟠 Windows ARM64

Une ligne de configuration, coût quasi nul. Peu de demande aujourd'hui — à faire en même temps qu'une autre passe sur les paquets.

---

🟠 Un paquet RPM pour Fedora

L'AppImage couvre déjà Fedora et toute autre distribution. Un .rpm apporterait l'entrée de menu et la désinstallation propre, comme le .deb pour Debian.

⚠ Non fait à dessein : personne dans ce projet n'a de Fedora pour le constater, et un paquet qu'on ne peut pas essayer est un paquet dont on ne sait rien.

---

🟢 Le nom de la distribution dans le client

Le client affiche « Linux » sans dire laquelle. process.platform ne connaît que « linux » ; la distribution se lit dans /etc/os-release, côté processus principal.

⚠ Écrire « Debian » sur une Fedora serait faux une fois sur deux — et c'est la première chose que lit quelqu'un qui signale un défaut. D'où « Linux » tout court en attendant.

---

🟢 La partyline dans OverScript

Demandé le 02/09/2026, et suspendu à une question de doctrine plutôt qu'à du code : la partyline donne l'interpréteur Tcl du bot, en telnet clair. La doctrine du projet — citée dans irix-botnet.tcl — veut que ces mots de passe ne soient jamais posés automatiquement.

📌 La question a été posée à l'exploitant ; elle attend une réponse.

📌 Ce qui est PRÉVU et pas encore commencé vit dans AVENIR.md, par ordre de priorité — traduction du site, compatibilité des navigateurs, macOS. Ici : ce qui est ouvert et connu comme défaut. Un projet qui démarre passe de l'un à l'autre.

Ce document dit ce qui N'EST PAS fait. VERSION.md raconte ce qui l'est ; ROADMAP.md porte le plan de route par phases. Ici : les défauts encore ouverts, les travaux en attente, et les endroits où le projet résiste — avec, pour chacun, ce qu'il faudrait pour le fermer.

⚠ Un point n'est retiré d'ici qu'après avoir été CONSTATÉ fermé, jamais après avoir été corrigé. Cinq points de ce carnet se sont révélés périmés le 07/08/2026 : le défaut annoncé n'existait plus, ou pas comme il était décrit. Une décision d'exploitation attendait sur l'un d'eux depuis trois semaines, pour rien.

⚠⚠ NE JAMAIS LIRE CE PRÉAMBULE POUR CONNAÎTRE L'ÉTAT. Il a porté pendant des semaines un journal de revues successives, et il était entièrement périmé au 16/08/2026 : il annonçait le point 18 ouvert alors que ce même fichier le déclare clos depuis le 15/08 à 19:06:20, une section rouge « vide » puis « ne portant qu'un seul point » alors qu'elle en portait plusieurs, et que le point 9 ne devait pas s'ouvrir alors qu'il l'est sur décision de SerVuS. Le récit des revues a donc été retiré : c'est exactement le genre d'affirmation d'état en français qu'aucun banc n'attrape, et le seul remède est de dériver la liste des titres ### .

⚠ Comment lire ce document — l'état se DÉRIVE, il ne se lit pas

Le tri au 23/08/2026 (soir), dérivé des titres ### — à refaire, jamais à recopier :

⚠⚠ CE TABLEAU PORTAIT DES COMPTES, ET ILS ONT MENTI — RETIRÉS LE 24/08/2026. Il annonçait « 6 🟡 » en y comptant le 42 et le 26, tous deux fermés la veille ; il décrivait le 43 comme « il manque la pose sur un /etc écrivable » quand son propre corps dit qu'il ne peut se fermer ni ici, ni ailleurs ; et il affirmait « 🔴 rien n'est corrigé — 0 » alors que le 45 est ouvert et que rien n'en est porté au dépôt. Les 45, 46 et 47, ouverts depuis, n'y figuraient pas du tout.

C'est le travers que ce document reproche ailleurs à ROADMAP.md et à PRET-ROBOT.md, qui ont retiré les leurs pour la même raison : un chiffre écrit à la main ne survit pas à la séance qui l'écrit.

L'état se DÉRIVE, il ne se lit pas — les titres portent le marqueur, et eux seuls font foi :

grep -n '^### [0-9]' Markdown/CHANTIERS.md | grep -v '✅'   # ce qui n'est pas fermé
grep -c '^### [0-9]' Markdown/CHANTIERS.md                  # le total

⚠ Et un marqueur de titre ment aussi : le 26 a porté 🟡 pendant une journée alors que son corps, deux lignes plus bas, le déclarait fermé. Ouvrir le point et lire son encadré « Pour fermer » reste le seul contrôle sûr.

⚠⚠ Le 21/08, les points 42 et 43 sont passés de 🔴 à 🟡 — mais le 42 a d'abord été RETOURNÉ par la mesure, dans les deux sens : il sur-disait sur la gravité (ces flags gardent la partyline, pas les commandes du bot, et le mot de passe reste exigé) et sous-disait sur la portée (c'est le code qui fabriquait le masque ouvert, et il le refait chez chaque tiers). Le détail est en tête du point. Le registre donne une piste, jamais un diagnostic — une fois de plus.

⚠ Le 20/08 a fermé trois points (39, 40, 41) et en a ouvert trois (41→43, 42, 43). Ce n'est pas un échec : aucun des trois nouveaux n'a été trouvé par une relecture. Le 42 parce qu'un utilisateur s'est fait expulser, le 41 et le 43 en installant une unité à la main. Le registre ne grossit pas parce qu'on écrit mal ; il grossit parce qu'on fait marcher les choses.

⚠ Le 20/08, le point 40 est passé de « rien n'est corrigé » à « constaté fermé » en une séance — et ce n'est pas le correctif qui l'a fait avancer, c'est l'essai. Installer la veille était un geste ; l'éprouver en coupant le service deux fois au lieu d'une a trouvé un défaut que trois bancs verts ne voyaient pas. Le second essai est celui qui trouve ce qui ne se réarme pas.

⚠ Et deux points ont été ouverts dans le même mouvement, 41 et 42 — tous deux trouvés non par une relecture, mais en faisant marcher les choses : l'un en installant une unité à la main, l'autre parce qu'un utilisateur s'est fait expulser. Le registre ne grossit pas parce qu'on écrit mal ; il grossit parce qu'on regarde.

⚠ Le 🟡 n'est pas un demi-✅, c'est un piège nommé. Les quatre défauts du 16/08 étaient tous dans cet état sans le savoir : corrigés ici, absents de ce qui est distribué, et un banc vert par-dessus. Un point n'y reste que le temps de prendre le constat qui manque.

⚠⚠ CE DOCUMENT DIT L'INVERSE DE CE QU'IL ANNONCE. La très grande majorité de ses lignes décrit ce qui EST fait, et non ce qui reste. Les deux plus gros blocs du fichier sont l'un et l'autre clos. ⚠ Aucun compte de lignes n'est écrit ici : celui qui y figurait annonçait 4 092 lignes pour un fichier qui en portait 4 678, et il se périmait à chaque séance — wc -l le donne exactement. Extraire les points fermés réduirait le document des deux tiers. C'est une décision de SerVuS, et elle est en attente — ⚠ trois choses casseraient mécaniquement (Web/site/versions.php, DISTRIB_RACINE_SITE, la liste en dur de test-markdown.php), et ~25 fichiers renvoient à des numéros de point qui se périmeraient sans un seul banc rouge.

⚠ Rangement contre convention : les points 22, 23 (clos) sont restés sous « Défauts ouverts », et 27, 29 (clos) sous « Travaux à effectuer », alors que 18, 19, 20 et 21 ont bien été déplacés après constat. Le document applique sa propre règle de façon inégale — se fier au marqueur du titre, pas à la section qui le contient.

Le 15 — la veille de Windows gèle WSL, trois scans horaires perdus sans un mot — a été tranché par l'option (c) : l'assumer, SerVuS ayant délégué l'arbitrage. Le gel n'est pas corrigé et ne le sera pas ; il est borné, et c'est ce qui rend la décision tenable : il coûte un retard, jamais une donnée. ⚠ La discipline qui rend ce coût acceptable ne repose plus sur la vigilance — chaque bind time déclare son rattrapage sur une ligne # RATTRAPAGE:, et test-bindtime.tcl rougit sur un bind ajouté sans elle. Deux confirmations mensongères ont été attrapées en l'écrivant, dont un banc qui gardait la porte en regardant la serrure.

⚠ Deux fausses pistes ont été suivies avant d'y arriver — le journal accusé d'être mort alors qu'il acceptait l'écriture, puis une fuite de descripteurs supposée sur 8 fichiers ouverts. ⚠ Le point 1 a été trouvé en contradiction avec lui-même : classé « défaut ouvert », sa ligne « Pour fermer » déclarait qu'il est clos côté code. Il n'a PAS été déplacé sur cette seule lecture — un point ne sort d'ici que CONSTATÉ fermé. Il l'a été ensuite : mesuré en production le 14/08, cinq jours après sa fermeture, les trois gardes d'amorce_ok en place, son banc vert à 15 vérifications, antimot=oui en warn sur quatre salons et les 17 mots du filtre présents. Alors seulement il a rejoint les travaux, et ses trois avertissements ont été portés dans « Les endroits où ça résiste » — ils valent indépendamment de lui. La section 🔴 ne porte donc plus que de vrais défauts actifs.

⚠⚠ LE COMPTE QUI SUIVAIT ICI — « elle n'en porte plus qu'un seul, le 15 » — A ÉTÉ RETIRÉ LE 25/08/2026, PÉRIMÉ. Le 15 a été tranché depuis (option (c), l'assumer, voir plus bas), et la section rouge porte autre chose. C'est très exactement le travers que ce préambule dénonce quatre paragraphes plus haut, et il l'avait recommis. Ce que porte la section 🔴 se DÉRIVE — les titres ### entre ## 🔴 Défauts ouverts et la section suivante, filtrés sur l'absence de ✅ — et ne se lit jamais ici.

Revue du 13 août 2026 — points 2 et 11 mesurés avant d'y travailler, et les deux mentaient. Le 2 se contredisait dans sa propre page : son titre réclamait une bascule de charge que sa ligne « Pour fermer » déclare écrite et constatée depuis la veille. Le 11 présentait trois pistes comme si aucune n'avait été prise, alors que la troisième tournait en service depuis le 12/08. ⚠ Ni l'un ni l'autre n'était une péremption par le temps — les deux étaient faux le jour où ils ont été écrits.

Revue précédente : 12 août 2026, séance entière — points 2, 3, 5, 6, 7 et 8 revus et trois fermés par constat (3, 6, 8). La précédente datait du 11 août ; celle du 9 août (4.16.0) avait eu une seconde passe le même jour où un sixième point périmé est tombé : l'historique de modération, qui existait déjà et affichait déjà.

Seconde passe du 12/08, en fin de séance : le point 12 est né — la console d'IriX, écrite le 07/08 et jamais employée jusque-là, faute d'un masque au userfile ; elle est close, les trois commandes constatées en service. Le point 2 a été retourné : le botnet, écarté le 09/08, est repris — ses trois objections sont gardées, deux restent vraies. Et le point 13 est ouvert : l'IPv6 est un chemin d'entrée réel que trois documents déclaraient inexistant, périmés sans bruit par le passage de WSL en mode miroir.

⚠ Le journal accusait un innocent depuis le 27/07. Les trois erreurs SQL de chaque démarrage — Access denied for user 'servus' — ne venaient ni de la base ni des droits MySQL, mais d'un appel placé 12 000 lignes trop tôt dans irix-register.tcl, et qui faisait DOUBLON avec l'appel légitime. 171 occurrences, aucune conséquence, et une fausse piste à chaque lecture du journal. Fermé et constaté le 12/08 — voir « Un appel au niveau du fichier s'exécute AVANT la configuration ».

⚠ Le 12/08, ce carnet a été pris en flagrant délit d'affirmation fausse — et pas périmée par le temps, cette fois : fausse le jour où elle a été écrite. Le point 2 disait des deux compteurs de charge « elles sont d'accord aujourd'hui ». Elles ne l'étaient pas : le banc de croisement que ce même paragraphe réclamait les a trouvées en désaccord sur la casse dès sa première passe. Une affirmation d'état écrite sans être mesurée est fausse par défaut, même sous la plume de celui qui réclame la mesure.

⚠ La revue du 11/08 a trouvé trois écarts, et aucun n'était une régression — tous les trois disaient un état vrai le jour où il avait été écrit, et faux le lendemain : autolimit remis à non (il a été coché à 19h25 le soir même, par le panel), chat_hist à 7 lignes (il y en a 30), et trois cases de ROADMAP.md annonçant des manques comblés depuis. Ce carnet ne se périme pas par erreur, il se périme par le temps. La seule parade est de mesurer le point sur lequel on travaille, au moment où l'on y travaille.

📌 Le point 9 n'est pas de la même nature que les autres. Ce n'est pas un défaut ouvert mais un chantier — le découpage du projet en quatre éditions, demandé le 11/08/2026 « pour quand tout sera stable ». Il vit dans Markdown/EDITIONS.md.

⚠⚠ LA SUITE DE CE PARAGRAPHE — « et il ne doit pas s'ouvrir tant que les huit premiers sont là » — A ÉTÉ RETIRÉE LE 25/08/2026, PÉRIMÉE. Le point 9 est OUVERT depuis le 14/08/2026, sur décision de SerVuS : ses phases 1 et 2 sont faites. Ce préambule le disait déjà dans son avertissement d'ouverture, tout en affirmant le contraire ici — il se contredisait d'un bout à l'autre de lui-même. ⚠ Et le point 48 dépend du 9, ce qui rendait la phrase retirée doublement trompeuse. L'état du 9 se lit dans son propre point, jamais ici.

---

🔴 Défauts ouverts

74. ✅ HUIT FORMES DE LIGNE DE RÉSUMÉ — tranché le 04/09/2026 : l'outil apprend, les bancs ne bougent pas

Ce que c'est. Chaque banc Tcl annonce son résultat à sa façon. Relevé en voulant mesurer trente bancs d'un coup :

TOUT PASSE — 24 vérifications.
TOUT PASSE — 88 vérifications, dont 14 mutations attrapées.
15 réussites, 0 échecs
1 ÉCHEC(S) sur 14 vérifications.
── 23 constat(s) tenu(s), 0 échec(s) ──
── 14 constat(s), 0 échec(s) ──
── 44 constats, 0 échec(s) ──
constats : 32 ok, 0 en échec
TOUT VERT — 32 constats

🔴 CE POINT ANNONÇAIT SEPT FORMES. IL Y EN A HUIT — la dernière, TOUT VERT, est celle de test-webexpire.tcl, et elle a été ratée au comptage du matin même, deux heures plus tôt. 📌 Compter ne suffit pas : le compte lui-même est une mesure, et il se rate. Le releveur qui l'a trouvée ne l'a pas trouvée en lisant — il l'a trouvée en rendant ? sur un banc, parce qu'il distingue « zéro » de « pas lu ».

⚠ Ce n'est pas une question de goût. Tools/bancs.sh s'en tire — il lit le code de sortie, pas la ligne. Mais tout outil qui veut lire un résultat doit connaître les sept formes, et celui qui n'en connaît que deux rend « aucune ligne de résumé » pour onze bancs qui passent très bien. 📌 Une mesure qui ne reconnaît pas ce qu'elle voit rend « rien », et rien ressemble à tout va bien — le motif du jour, rencontré ici pour la quatrième fois.

⚠⚠ Le piège est pire qu'il n'en a l'air. Un banc dont le format change — parce qu'on l'a réécrit — sort silencieusement du champ de tout outil qui l'échantillonnait. Rien ne le signale : l'outil dit simplement une chose de moins.

✅ TRANCHÉ le 04/09/2026 — c'est l'OUTIL qui apprend, pas les 57 bancs qui changent

🔴 On n'uniformise pas. Tools/bancs.sh lit le code de sortie, pas la ligne : il n'a jamais eu de problème avec ces huit formes. Le besoin d'une forme unique était celui de l'outil qui lit — donc c'est l'outil qui apprend. Réécrire cinquante-sept bancs qui marchent pour satisfaire un lecteur, c'est prendre le risque du côté où il n'y en avait pas.

Tools/bilan-constats.sh connaît les huit formes et répond à une question que le projet n'avait jamais posée : combien de constats le gardent ? — un chiffre que « 149 bancs » cache, puisqu'un banc de 4 constats et un banc de 196 y pèsent pareil.

⚠⚠ Il distingue « zéro » de « pas lu ». Un banc dont le résumé lui échappe n'est pas compté comme vide : il est nommé, et le total est alors annoncé comme un plancher, pas comme un compte. C'est exactement ce qui a fait trouver la huitième forme.

⚠ Le plancher du plancher : sous vingt bancs lus, l'outil s'arrête — un chemin qui a bougé rendrait sinon « 0 constat » avec un code de sortie 0, et ce silence passerait pour une bonne nouvelle.

📌 Un banc NEUF emploie la forme la plus explicite — ── N constat(s), M échec(s) ── — parce qu'elle porte les deux nombres dans tous les cas. La discipline vaut pour ce qu'on écrit, pas pour ce qui existe.

73. ✅ RIEN NE VÉRIFIAIT QUE LES SCRIPTS D'IriX SE CHARGENT — 04/09/2026

Ce que c'est. Cent quarante-huit bancs éprouvaient le contenu des scripts d'IriX. Pas un seul ne vérifiait qu'ils peuvent être lus par Tcl de bout en bout.

⚠⚠ Et ce n'est pas un manque théorique. Le 26/08/2026, une procédure inexistante appelée au chargement a coupé le serveur à la 89ᵉ seconde. Rien ne l'avait signalé : Tcl n'a pas de bash -n, info complete ne voit que l'équilibrage des accolades, et tous les bancs extraient des procédures une par une — ce qui n'exécute jamais le corps du script. C'est de là que vient le contrôle manuel « à ~90 s après redémarrage », qui n'est pas un banc mais une habitude.

Ce qui l'a fait écrire aujourd'hui : deux modifications du code d'IriX — les binds du point 66, le retrait des quatre procédures du point 56 — qui ne seraient éprouvées qu'au redémarrage, et un redémarrage raté coupe le bot. Écrire un correctif qu'on ne peut pas éprouver avant de le mettre en service demande d'abord un moyen de l'éprouver.

Ce que fait IriX/tests/test-chargement.tcl : il bouchonne la soixantaine de commandes qu'Eggdrop fournit et que tclsh n'a pas — bind, putserv, chanlist… — puis il source le point d'entrée, qui entraîne tous les autres. 231 binds sont posés, et deux constats les lisent :

• ⚠⚠ chaque bind pointe-t-il sur une procédure qui existe ? Eggdrop accepte un bind vers une procédure absente sans un mot : il ne s'en plaint qu'au moment où l'événement arrive, donc en service, devant des gens ;
• les binds ajoutés le jour même sont-ils vraiment posés, et les quatre verbes retirés ne reviennent-ils pas ? Les voir dans le fichier ne prouve pas qu'ils survivent au source.

⚠ Ce que ce banc ne fait PAS. Ce n'est pas un vrai démarrage : les bouchons rendent des valeurs vides là où Eggdrop rendrait des données, donc une branche qui dépend d'un serveur réel ne s'exécute pas. Il attrape ce qui casse à la lecture — syntaxe fautive, procédure appelée avant d'exister, source vers un fichier absent. C'est précisément la famille qui coupe un démarrage, et c'est tout ce qu'il promet.

Mutation : 6 blessures sur 6 vues, dont le défaut du 26/08 lui-même — une procédure inexistante appelée au chargement — qui fait tomber 7 constats sur 12.

72. ✅ HUIT ANCRES DE MUTATION AVAIENT DÉRIVÉ, ET NEUF FRAPPAIENT À CÔTÉ — FERMÉ le 04/09/2026

Ce que c'est. bancs/mutation.js (OverScript) blesse le code pour vérifier qu'un banc rougit. Huit de ses ancres ne s'appliquaient plus, et quatre autres s'appliquaient à la mauvaise occurrence. Douze gardes n'étaient donc éprouvées par rien.

⚠ La cause n'est pas celle qu'on croit. Ce n'était pas une refonte de code : c'est le commit des accents (51ca514, 03/09 13:31) qui a réécrit téléchargement, refusée, délai dans les sources et dans neuf bancs — mais pas dans mutation.js, écrit 2 h 21 plus tôt. Huit accents, aucune structure touchée.

🔴🔴 ET LES QUATRE AUTRES SONT PIRES QUE LES HUIT. Une ancre dérivée est nommée par blessures-restantes.js. Une ancre présente plusieurs fois ne l'est pas : String.replace frappe la première occurrence, la mutation s'applique, un banc rougit, et tout paraît en ordre — pendant que la garde annoncée n'est mesurée par personne. Deux mutations étaient un doublon octet pour octet, et la GARDE 2 de l'identification automatique n'était éprouvée par rien.

Ce qui ferme le point : les huit ancres rendues à leur orthographe, les quatre rallongées pour viser leur cible, et deux mutations ajoutées pour des gardes qui n'en avaient aucune (la vérification HTTPS du journal des versions, et le durcissement de la fenêtre de démarrage). 263 blessures, aucune dérivée.

✅ Le contrôle d'unicité est posé — 04/09/2026, l'après-midi même

⚠⚠ Il existait, et il ne se posait JAMAIS la question. Le test « cette ancre est-elle unique ? » vivait sous le continue de la branche « la blessure n'est pas en place ». Sur un source intact — le cas de toutes les campagnes — l'outil retournait avant de l'atteindre, et annonçait « Source intact : 263 blessure(s) ». Une garde écrite, jamais appelée : le motif du jour, pour la troisième fois.

📌 L'ambiguïté d'une ancre n'est pas un fait sur l'état du fichier, c'est un défaut de la blessure. Elle se pose donc avant tout le reste, et sans regarder si le source est blessé.

Cinq ancres étaient ambiguës, et l'une d'elles frappait franchement à côté : « la déconnexion oublie les fenêtres privées » visait if (t.type === 'serveur') continue;, qui existe deux fois dans app.js — et replace() touchait celle d'une boucle d'affichage, pas celle de la déconnexion. La blessure abîmait du code juste, laissait intacte la garde qu'elle prétendait éprouver, et était comptée comme réussie.

⚠ Trois listes, pas une. Le premier jet mettait 21 blessures dans le même sac sous le titre « elles ne mesurent pas ce qu'elles annoncent ». C'était faux pour seize d'entre elles : leur vers contient leur de, donc elles se posent très bien — c'est la détection après coup qui est aveugle, pas la mesure. Un outil qui accuse juste et faux ensemble s'apprend à être ignoré en entier.

Deux ajouts d'outillage, tombés du même travail :

• un filtre — node bancs/mutation.js "<motif>" — parce qu'éprouver cinq ancres réécrites demandait d'en rejouer 263, soit des heures. Le remède pris jusque-là était un script jetable dans le scratchpad, qui meurt avec la séance en emportant sa règle ;
• le plancher que ce filtre a révélé : un motif ne correspondant à rien donnait « 0 blessures, 0 trou(s) » puis « Le banc sent chacune des blessures », et une sortie 0. Zéro mesure, et l'outil annonçait la victoire. ⚠ Le cas n'arrive pas qu'avec un filtre mal tapé : un CIBLES vide ou un chemin qui a bougé donnent le même silence.

71. ✅ DEUX CLÉS QUE RIEN NE LIT DANS LE MODÈLE D'IDENTITÉ — 04/09/2026

Config/identity.json.example déclarait netadmin_vhost et admin_vhost. Tools/identite-config.sh lit irc.oper_vhost et irc.user_vhost. Un exploitant tiers aurait rempli deux champs sans aucun effet, et ses vhosts n'auraient jamais été posés.

🔴🔴 ET LE SILENCE EST TOTAL, C'EST LÀ TOUT LE DÉFAUT. identite-config.sh teste [ -n "$OPER_VHOST" ] avant d'agir : une clé absente ne lève rien, ne dit rien. Le contrôle passe — simplement il ne contrôle plus rien. C'est la forme la plus coûteuse du défaut de famille de ce projet : juste ici, muet ailleurs.

⚠ Ce fichier est le seul fichier d'identité qu'un tiers voit. Il le copie, le remplit, et son réseau en dérive son nom, son domaine, ses adresses et ses vhosts.

📌 Même famille que le point 70, qui se ferme d'ailleurs en s'appuyant sur ce modèle — et l'on a découvert le lendemain que deux de ses clés ne servaient à personne.

Ce qui ferme le point : Web/tests/test-identite-modele.php, 14 constats. Il compare les deux fichiers structurellement — aucune liste écrite à la main, elle est dérivée d'identity.json — et croise avec le code : chaque clé que lire cherche dans l'outil doit exister dans le modèle. Sans ce second contrôle, les deux fichiers pourraient concorder parfaitement… sur des clés que plus personne ne lit. Mutation : 5 blessures, 5 issues attendues, la première étant le défaut réel remis en place.

⚠ Ce que le banc ne garde pas : que identite-config.sh DISE quelque chose quand une clé manque. Il continue de sauter en silence — voir le point 72 pour la même famille de silence.

70. ✅ UNE CONSTANTE POSÉE DANS LE SEUL FICHIER QUI NE VOYAGE PAS — 03/09/2026

Le lien Facebook demandé par SerVuS lisait RESEAU_FACEBOOK, que j'avais déclarée dans Web/inc/config.php. Le dépôt exclut ce fichier — il porte les mots de passe. La constante existait donc sur le poste de développement et nulle part ailleurs : ?p=contact a rendu « Uncaught Error: Undefined constant » en production, tronquée à 10 Ko au lieu de 22.

⚠⚠ Et le banc était VERT pendant ce temps. Ses 28 constats lisaient des fichiers, et sur cette machine le fichier était bon. Lire le code ne dit rien de ce qui sort.

⚠ Une seconde faute, plus grave, dans le même correctif : après avoir déplacé la constante dans identity.php (versionné), j'y ai mis notre adresse comme valeur de repli. Toute installation tierce aurait affiché la page Facebook d'Overtchat au pied de chacune de ses pages, sans que rien ne le lui dise. Le commentaire d'à côté affirmait pourtant qu'un exploitant « y met la sienne ». La question n'est pas « peut-on la changer ? » mais « que fait-elle quand personne ne la change ? »

Ce qui ferme le point : la valeur vit dans Config/identity.json (clé social.facebook), le repli du code est la chaîne vide, le modèle identity.json.example la porte vide, et Markdown/RESEAU.md la documente. Le banc test-lien-facebook.php (45 constats) demande les pages au serveur au lieu de lire des fichiers, et refuse tout repli non vide.

69. ✅ UN KICK QUI N'A JAMAIS ÉTÉ ENREGISTRÉ — 03/09/2026

À 15:18:04, un !k servus tapé depuis un téléphone a produit event_type = « kick servus (Expulsé par SerVuS) » : 32 caractères pour un varchar(30). MySQL est en mode strict — il ne tronque pas, il refuse. L'expulsion a eu lieu sur le réseau et n'a jamais été enregistrée. C'est l'alerte « Écriture SQL refusée » que SerVuS a vue.

⚠ 35 des 57 appels à log_chanadmin composaient ce champ avec une variable — say $msg, mode $text, ban $mask, les trois verdicts de l'IA. Et dans evt_record, raw était la seule valeur bornée : la seule dont la colonne soit un TEXT, donc la seule qui n'en avait pas besoin. Six colonnes sur sept écrivaient sans garde.

Ce qui ferme le point : ::soc::sql_col taille chaque valeur à sa colonne au point d'écriture. Banc IriX/tests/test-events-longueurs.tcl (32 constats), qui croise les longueurs du CREATE TABLE et les nombres du code — changer l'un sans l'autre fait rougir. Mutation : 8 blessures, 8 issues attendues.

⚠ Ce que le banc n'attrape pas : il lit le CREATE TABLE, pas le schéma réel du serveur. Une colonne modifiée à la main en production le laisserait vert.

68. ✅ LE SITE DEVIENT INSTALLABLE — PWA, demandée et FERMÉE le 03/09/2026

Décidée après avoir écarté une application native : le panel est déjà responsive, une application de magasin aurait coûté 99 $/an et un Mac, aurait été rejetée par Apple comme simple habillage d'un site (règle 4.2), et aurait mis chaque correctif derrière 24 à 48 h de revue.

Constaté par SerVuS sur son téléphone : icône sur l'écran d'accueil, ouverture en application, réaction au mode avion. Deux manques sont apparus à l'usage et ont été corrigés dans la foulée : les tailles d'icônes déclarées explicitement, et un bouton « Quitter » — rien ne permettait de fermer une application en display: standalone.

⚠⚠ Ce que les bancs NE PEUVENT PAS mesurer, et c'est écrit en tête de test-pwa.php : ni l'enregistrement réel du service worker, ni le hors-ligne. Le navigateur d'essai de cette machine les refuse tous — un service worker vide y échoue aussi, mesuré exprès pour distinguer le code du contexte. Tout cela a été constaté à la main, par SerVuS, à travers une page de diagnostic écrite pour l'occasion puis retirée.

📌 Voir Markdown/MOBILE.md, dont l'affirmation centrale — « ce document ne décrit rien qui existe » — était devenue fausse et a été corrigée le même jour.

67. ✅ CHAQUE ANOMALIE MONTRE SA PAGE — demandé et FERMÉ le 03/09/2026

Demandé par SerVuS : « faudra générer des pages comme le 404 qui reste au format Service-Overtchat, pour toutes les pages qui tournent en erreur ». Avant, seule la 404 avait la sienne. Un refus d'accès au panel rendait une ligne noire sur fond blanc, un fichier de téléchargement absent rendait seize octets (Fichier inconnu.), et un export de base qui échouait affichait le message de l'exception PDO — avec le SQL et des chemins de fichiers.

Trois familles, parce qu'il y a trois situations :

⚠⚠ Les outils gardent leur réponse sobre. ?p=dl est atteint par un lien sur lequel on clique et par curl depuis l'installateur : le choix se fait sur l'en-tête Accept (site_accepte_html()), jamais sur une devinette. Un navigateur reçoit la page, curl ses onze octets — exactement comme avant.

⚠ Deux pages Apache, et la duplication de leur style est VOULUE : elles s'affichent quand le site est absent, donc une feuille commune serait servie par le serveur qu'elles remplacent.

🔴 Le défaut le plus intéressant est venu de la règle 5, et il ne se voyait pas : l'installateur ne posait que maintenance.html. Une installation tierce aurait eu ses ErrorDocument 500/502/504 pointant sur un fichier absent, et personne ne l'aurait su avant sa première panne. La règle porte désormais un motif *.html, et la désinstallation aussi.

⚠ Ce qui n'est PAS constaté : la 502 réelle. Il faudrait couper le site pour la voir. Ce qui est constaté : les pages existent, sont autonomes, diffèrent, et la conf les branche — 39 constats dans Web/tests/test-pages-erreur.php, 10 blessures de mutation, toutes vues.

---

66. ✅ La limite qui ne redescendait pas — CONSTATÉE FERMÉE le 04/09/2026 en service · 🟡 le bruit de démarrage reste

Ouvert sur une observation de SerVuS : « pas un peu bizarre tout ça ? », devant la séquence de modes et de sujets qui suit un redémarrage. Rien n'est cassé — mais trois choses méritent d'être sues, et une seule est un vrai défaut.

Ce qui n'en est pas un. Les deux « IriX » de l'affichage sont deux identités : 003AAAAAA le service ULine, 10AAAAAAC le bot Eggdrop connecté en client. Le +tn reposé ne vient d'aucun script d'IriX — tous trient les lettres (lsort) et produiraient +nt ; c'est Eggdrop lui-même qui réapplique son chanmode +tn d'IriX.chan. Et le +l est une limite dynamique, présents + 2 (IriX-sql.tcl:11906), vérifiée en direct : 4 → 5 à une arrivée, 5 → 4 au départ.

⚠ Le vrai défaut, mesuré : la limite ne suit PAS un QUIT

IriX-binds.tcl:230-242 lie join, part, nick, kick — aucun bind sign. Mesuré par contraste, dans le même essai :

⚠ Le sens est permissif : la limite reste trop haute, donc personne n'est refusé à tort. Mais sur un réseau où l'on part surtout en fermant son client, elle dérive vers le haut et ne redescend qu'au prochain JOIN ou PART. À la longue, +l ne protège plus de rien — un garde-fou qui ne serre jamais est un garde-fou décoratif.

✅ PORTÉ le 04/09/2026 — il reste à RECHARGER IriX

bind sign et un second bind kick rappellent désormais ::soc::auto::do_autolimit, avec le même after 500 que le JOIN et le PART.

⚠ Le délai n'est pas un détail : Eggdrop met chanlist à jour après avoir appelé le bind. Un recalcul immédiat compterait encore celui qui vient de partir — le défaut d'origine, reproduit par l'autre porte.

⚠⚠ Le KICK avait bien le même trou. bind kick existait, vers ::soc::evt_kick, qui ne touche pas à +l. Un second bind ne remplace pas le premier : Eggdrop appelle les deux, et c'est de les nommer différemment qui le garantit.

📌 Le netsplit ne reçoit RIEN, et c'est délibéré. Eggdrop émet splt quand quelqu'un disparaît par séparation, puis sign s'il n'est pas revenu au bout de wait-split. Recalculer sur splt ferait descendre la limite pour des gens qui reviennent dans la minute, et rejn la remonterait aussitôt : deux MODE diffusés à tous les présents, pour rien. Ceux qui ne reviennent pas sont pris par sign.

Le garde-fou : IriX/tests/test-autolimit-departs.tcl, 17 constats, 6 blessures de mutation sur 6 vues. ⚠ Il n'éprouve pas l'existence des procédures — le défaut du 02/09 n'était pas une procédure manquante, do_autolimit était là et juste, c'est le chemin qui manquait. Il mesure donc qui appelle, d'où, avec quoi : chaque bind pointe sur une procédure, et le corps de cette procédure rappelle bien le recalcul. Un des constats garde une décision plutôt qu'un défaut — l'absence de bind splt : s'il rougit, la question est « a-t-on changé d'avis, et l'a-t-on écrit ? ».

✅ CONSTATÉ EN SERVICE — 04/09/2026, 15:12

IriX a été relancé à 15:04:06 (redémarrage volontaire, NRestarts=0, aucune erreur Tcl dans les cinq endroits, lien S2S remonté à 15:04:44). Le correctif a ensuite été éprouvé sur le réseau en marche, par le protocole même qui avait trouvé le défaut le 02/09 :

La limite suit désormais le départ par QUIT. ⚠ C'était le seul constat qui comptait : le banc dit que les binds sont posés, il ne dit pas qu'ils agissent. Un banc qui mesure la chose ne mesure pas son emploi.

🔴🔴 ET LE PREMIER ESSAI A FAILLI CONCLURE L'INVERSE, SUR UNE MESURE QUI N'AVAIT PAS EU LIEU. Il visait #Csadmin, qui est +i : les deux clients s'y sont fait refuser l'entrée, et le script ne s'en est pas aperçu — il attendait le 366 (fin de la liste des noms), qui n'arrive jamais sur un JOIN refusé, et rendait la main en silence après son délai. Il a lu « limite 3 » sur un salon où personne n'était entré, et allait écrire « le défaut est INTACT ».

📌 Le plancher, désormais : rejoindre() rend vrai seulement si l'entrée est constatée — notre propre JOIN qui nous revient, ou le 366 — et reconnaît les six refus (473 474 475 471 477 448). Sans entrée constatée, l'essai s'arrête au lieu de mesurer. ⚠ C'est le travers de ce dépôt, commis par le script d'essai lui-même, et sur le point qui le dénonce.

🟡 Le bruit de démarrage, à peser

16 TOPIC et 24 MODE en trois minutes après un redémarrage — dont quatre fois le même sujet sur #!Overtchat!. Chacun est diffusé à tous les présents.

⚠ C'est ponctuel : mesuré sur fenêtre calme, zéro TOPIC depuis. Deux boucles font le même travail sur la même donnée — db_topic_check toutes les 30 s et scan_topics toutes les 300 s — mais les deux comparent avant d'envoyer (IriX-sql.tcl:7423, :11836). Quatre envois signifient que la comparaison a échoué quatre fois, ce qui est cohérent avec un bot pas encore op sur un salon +t : le +o IriX n'arrive qu'à 18:43.

📌 À décider : est-ce un coût de démarrage acceptable, ou faut-il retarder la première passe jusqu'à ce que l'op soit acquis ? ⚠ Ne rien changer sans mesurer d'abord si la comparaison échoue encore une fois l'op obtenu — sinon on corrigerait un symptôme.

⚠ Un risque connexe, non mesuré

La marge est de 2 places et le recalcul part 500 ms après l'arrivée, via puthelp, la file la plus lente d'Eggdrop. Trois arrivées simultanées dans cette fenêtre → la troisième prendrait un 471. Non reproduit.

---

65. ✅✅ LES CINQ PSEUDO-CLIENTS ÉTAIENT DÉTRUITS ET RECRÉÉS CHAQUE MINUTE — ouvert et CONSTATÉ FERMÉ le 02/09/2026

Le point de départ était mince : dans IriX_online, host et realname vides pour les cinq services. En cherchant pourquoi, le vrai défaut est apparu.

::soc::online::reconcile compare les UID en base à ceux que la mémoire connaît et supprime la différence — des « fantômes ». ⚠⚠ Mais la liste des vivants venait de user_nick seul. Les pseudo-clients n'y figurent pas : ils n'arrivent par aucun UID entrant, c'est IriX qui les injecte. Ils étaient donc pris pour des fantômes et supprimés, puis réinsérés par le dernier passage de la même procédure.

Mesuré en production, deux lectures à 45 s :

Trois conséquences, et la première est la pire : since MENT — le panel annonce « connecté depuis 10 s » pour des services présents depuis le démarrage. Une ligne présente et fausse est pire qu'une ligne absente : elle a l'air mesurée. C'est la doctrine d'irix-online.tcl, retournée contre lui. Ensuite le ON DUPLICATE KEY UPDATE était inatteignable. Enfin, 5 DELETE et 5 INSERT par minute pour rien.

Second défaut, même procédure : l'INSERT des services s'arrêtait à vhost, alors que register_svc range host et realname dans le MÊME dict. Web/pages/live.php n'affiche le sous-titre que s'il est non vide — les services étaient les seules lignes muettes, quand « Gardien des Salons » attendait dans svc_config.

⚠ Aucun banc n'exerçait cette branche : les deux réparations de septembre ont porté sur flush, jamais sur reconcile. Une réparation s'applique à l'instance, jamais au motif.

CONSTATÉ FERMÉ après rechargement d'IriX à 17:20:09 — since passe de 65 s à 140 s (+75, exact), et les cinq realname sont remplis. Santé : 0 redémarrage, 0 erreur Tcl, 39 lignes de trafic S2S.

IriX/tests/test-online-services.tcl — 13 constats, 7 blessures, 7 rouges. ⚠⚠ Il a payé son écriture au premier lancement : ma première correction ajoutait les UID de services à vivants, et la boucle d'insertion y lisait un user_nick inexistant — « no such variable », hors catch, à chaque cycle. Deux listes séparées : « qui a le droit de rester » n'est pas « qui faut-il inscrire ».

⚠ Et deux blessures sont passées au VERT avant correction, même racine : vhost contient la sous-chaîne host, et le jeu d'essai donnait la même valeur aux deux. Un jeu d'essai où deux champs coïncident ne peut pas les distinguer. Puis j'ai durci un motif qui n'en avait pas besoin, et je l'ai cassé — il faut savoir contre quoi l'on durcit.

---

64. 🟡 REVUE DU SITE — il ne reste qu'une RECOMPILATION — mesuré le 02/09, refermé le 04/09/2026

Demandée par SerVuS. ⚠ Classé par ce qu'un visiteur subit, pas par ce qui est laid.

⚠⚠ Ce qui reste tient en une ligne : HELP_CHANNEL est corrigé dans la source du serveur mais n'a pas d'effet avant une recompilation, et recompiler demande l'accord de SerVuS. Tout le reste de ce point est fermé et constaté — y compris les neuf puces qui sont restées affichées comme ouvertes pendant deux jours après l'avoir cessé.

✅ Corrigé le jour même

• /join #aide envoyait les visiteurs sur un salon qui les refuse. La page Contact donnait ce salon comme « la voie la plus rapide ». Mesuré en production, pas dans les .example : le serveur déclare HELP_CHANNEL "#Help", et seul #Help figure dans les salons ouverts. #aide aurait rendu un 448 Cannot join channel. ⚠ Le .example du dépôt portait encore #aide — il est aligné, avec la raison écrite dedans.
• Le chat niait TROIS fonctions qu'il possède : historique, privés en panneau dédié, reconnexion automatique. Les trois sont dans le chat.js servi par la même page. Une page qui promet moins qu'elle ne fait détourne des visiteurs pour rien.
• Quatre liens morts dans le PIED DE PAGE — donc sur CHAQUE page. « Dépôt GitHub », « Signaler un problème » et « Licence » (deux fois) pointaient vers un dépôt privé, dont toutes les adresses web répondent 404. ⚠⚠ C'était mesuré et écrit dans ce dépôt depuis le 31/07 : la page d'installation avait retiré ses liens pour cette raison exacte, l'accueil avait corrigé son bouton. Une correction appliquée à deux pages sur trois : le défaut de famille du projet.

✅ Corrigé le 02/09/2026 — deuxième passe

Chacun est dérivé, et chacun est éprouvé par un banc que la mutation a fait rougir.

• Les quatre chiffres écrits à la main de l'accueil. « Douze onglets » → count(panel_routes()) (30) ; « environ 11 000 lignes de Tcl » → les lignes de IriX/cmds/*.tcl (31 930, arrondi au millier) ; « 280 vérifications sur neuf campagnes » → le TOTAL= que run-tests.sh déclare (19) ; « une seule commande » → quatre, comme le bloc juste en dessous. ⚠ Une aide site_chiffre_cache() a été posée dans Web/inc/site.php : dériver coûte, et les deux fonctions voisines avaient déjà un cache pour cette raison exacte. Elle prend des témoins de date, sans quoi un compte de lignes resterait périmé après chaque modification du Tcl.
• information_schema interrogée à chaque affichage — passée par la même aide.
• La page « Télécharger » ignorait le client de bureau. Une section dédiée liste les entrées de type client, dérivée du manifeste : aucun système n'est nommé en dur, et le journal des versions en est écarté (c'est un texte, pas un programme). ⚠ Le libellé vient de distrib_inventaire(), pas du manifeste, qui ne le recopie pas — sans quoi la colonne « Système » affichait « OverScript-installateur.exe ». Constaté en RENDANT la page ; le repli ?? $f['nom'] a l'air parfaitement correct dans le code source.
• Deux téléchargements présentés comme différents. La page compare désormais les empreintes et dit ce qu'elle a mesuré. ⚠ Écrire « c'est le même fichier » aurait remplacé une affirmation fausse par une affirmation vraie aujourd'hui : le jour où les deux entrées divergeront, la page mentirait de nouveau.
• La pastille menait à une page qui ne parle pas de mise à jour. ⚠⚠ Et c'est plus retors que décrit : le point 32 avait fait CONVERGER les deux liens vers ?p=statut — la convergence était juste, la cible était fausse, et leur accord l'a rendue invisible deux semaines. Mesuré : update_verdict() n'est appelé que par layout.php et dashboard.php. La pastille vise maintenant ?p=dashboard#maj ; le badge du tableau de bord cesse d'être un lien qui ramène où l'on est.
• Zoom iOS du panel. ⚠⚠ Le commentaire de la feuille ET le banc défendaient le défaut. Tous deux affirmaient « pas de !important ici : ces champs tiennent leurs dimensions de la feuille, pas d'un attribut style ». La prémisse est vraie, la conclusion ne suit pas : le danger était une règle plus spécifique de la même feuille (.mode-param input, 12 px). Le constat de test-vues.php ne dit plus « aucun !important » — il mesure ce qui le rend superflu ou nécessaire.
• Le tableau de 8 colonnes de ?p=statut a son .tbl-wrap.
• Les champs sans label. ⚠ Trois étaient nommés dans ce registre ; les corriger un par un aurait laissé les suivants. Web/tests/test-champs-nommes.php balaie toutes les pages — 44 constats, dont un plancher.
• Les trois comptes du même chiffre dans admin.php, avec Web/tests/test-comptes-services.php (8 constats). ⚠⚠ Le repli ?: 5 était le pire des trois : il fabriquait un dénominateur quand la liste est vide, et « 0 / 5 » se lit « cinq attendus, aucun n'est là » — une panne — alors que la vraie phrase était « la liste n'a pas pu être lue ».

⚠⚠ UN POINT DE CE REGISTRE DISAIT FAUX. Il annonçait : « .raison.info n'existe pas : une raison de niveau inconnu s'affiche avec une puce invisible ». Mesuré dans Web/site/compatibilite.php : .raison::before porte déjà background: var(--dim). Tout niveau inconnu rend une puce grise, et rien n'est invisible. Aucun code n'a été touché.

✅ Corrigé le 02/09/2026 — troisième passe

• Le nom du service était gravé 21 fois dans 13 fichiers — le registre disait « onze pages », mesuré : 13 fichiers, 21 occurrences vivantes. Une aide nick_service_nom() rend le nom seul, et site.php la charge pour toutes les pages. ⚠⚠ chat.php se contredisait à deux endroits, pas un. ⚠ Le pire cas n'était pas une page mais le corps d'un courriel de réinitialisation, qu'on ne peut plus corriger après l'envoi. Banc Web/tests/test-nom-du-service.php.
• La table des cinq services de cmd_services() dérive de svc_config. ⚠⚠ Les deux concordaient parfaitement — c'est exactement ce qui rend le défaut durable : une table recopiée qui dit vrai ne se remarque pas. Banc Web/tests/test-cmd-services.php.
• Les salons d'accueil. ⚠⚠ Le registre parlait de « deux salons concurrents » ; la mesure dit autre chose. config.example.php est cohérent — il déclare WEBCHAT_CHANS_R pour #membres, qui rend un 477 aux visiteurs anonymes et se joint après identification. Le vrai défaut était un commentaire faux : #accueil était donné pour injoignable alors qu'il répond parfaitement ; #aide, cité dans la même phrase, était bien refusé. Une moitié juste, une moitié fausse. 📌 IriX/tests/essai-salons-webchat.py tranche désormais en le DEMANDANT au serveur.

⚠ Le commentaire fautif vit dans Web/inc/config.php, HORS DÉPÔT (.gitignore:126) : la correction ne voyage pas. C'est config.example.php, lui distribué, qui porte la mesure. Le fichier de production garde son commentaire faux tant que personne ne l'édite sur la machine.

✅ Config/unrealircd/salons.conf — MESURÉ le 02/09/2026 : plus rien ne le lit

Trois chemins indépendants, tous concordants.

Le serveur ne le lit pas. Il tourne depuis /home/servus/overtchatd/, pas depuis le dépôt : overtchatd -f -c /home/servus/overtchatd/conf/overtchat.conf. Cette configuration n'a qu'un include, vers conf/opers.conf, et aucune référence à Config/. Côté code, grep -rn "Config/" sur tout le C et les .conf du serveur rend zéro.

La vraie source est conf/salons-interdits.conf, chargé par la directive banned-channels (src/conf.c:1503, badchans_load()), avec deux listes chaînées — interdictions et exceptions, ces dernières consultées EN PREMIER. Sa zone d'exceptions est régénérée depuis la base par Tools/salons-exceptions.sh --appliquer.

Aucun PHP ne l'ouvre. Les six références sont toutes des commentaires ; aucun file_get_contents ni fopen ne le vise.

⚠⚠ ET IL EST PÉRIMÉ, CE QUI EST PIRE QUE MORT. Il porte 5 exceptions quand la configuration en service en a 7 : #!Bots! et #Help y manquent — or #Help est bien joignable, mesuré. Le consulter pour savoir ce qui est ouvert induit en erreur. Un fichier qu'on ne lit plus mais qui décrit encore est plus trompeur qu'un fichier absent : il a l'air d'une source.

Corrigé : les commentaires de chanreq.php (deux) et demandes.php prescrivaient de poser l'exception « à la main » dans ce fichier — un geste mort. Ils nomment maintenant Tools/salons-exceptions.sh --appliquer. ⚠ Le message AFFICHÉ était déjà juste ; c'est la documentation interne qui mentait, à un développeur qui n'a aucune raison de la vérifier.

⚠ Pourquoi aucun banc ne l'avait vu : test-consignes.php interdit bien ces chemins, mais il retire les commentaires avant de chercher — le remède appliqué partout ailleurs crée ici l'angle mort. Les docblocks lui sont invisibles.

✅ FAIT le 02/09/2026, sur décision de SerVuS : Config/unrealircd/ est retiré du dépôt — les trois fichiers, chacun mesuré sans lecteur. websocket.conf : le WebSocket se déclare en ligne dans la configuration du serveur. ircd.motd : le vrai modèle est Servers/overtchat-hybrid/conf/ircd.motd.tpl, dont Tools/motd-generer.php fabrique le fichier servi. ⚠ Le motif d'exclusion de l'installateur est conservé : une installation d'avant cette version porte encore le dossier.

⚠ Ne PAS confondre avec Components/Serveur/bin/unrealircd/, qui porte les certificats TLS employés par le serveur actuel — les supprimer casserait le TLS.

🟡 CORRIGÉ EN SOURCE le 02/09, il attend une recompilation — le serveur annonce un salon qui refuse

⚠ Le titre disait « NON CORRIGÉ » deux jours de trop. Mesuré le 04/09 : conf.c porte désormais "" comme défaut, avec l'encadré qui explique le choix du vide, et m_misc.c:250 teste if (*feature_str("HELP_CHANNEL") != '\0') avant d'annoncer quoi que ce soit. Le garde-fou est Tools/tests/test-salon-aide.sh. Ce qui reste n'est plus « corriger » mais « recompiler », et cela demande l'accord de SerVuS — c'est le seul reste de ce point.

Ce qui suit décrit l'état d'AVANT le correctif, et le pourquoi.

Servers/overtchat-hybrid/src/conf.c portait alors :

{ "HELP_CHANNEL", FEAT_STR, 0, "#aide", ... }

Le défaut compilé était #aide. La production déclare HELP_CHANNEL "#Help" et n'ouvre que celui-là ; #aide rend un 448, mesuré le 02/09.

⚠⚠ Toute installation neuve qui omet HELP_CHANNEL annonce donc à chaque nouveau venu un salon d'assistance qui le refuse — src/cmd/m_misc.c:250 l'affiche dans « Assistance : … ». C'est exactement le défaut corrigé le matin même sur la page Contact, mais dans le serveur, et il touche les installations qu'on ne voit jamais.

⚠ Non corrigé volontairement : changer une valeur en dur du C n'a d'effet qu'après recompilation, ce qui demande l'accord explicite de SerVuS. Corriger la source sans recompiler aggraverait l'écart binaire/sources que run-tests.sh refuse déjà.

✅ Chiffres écrits à la main — FERMÉ, constaté le 04/09/2026

Les quatre sont dérivés, et trois passent par un cache : $nb_routes, $nb_tcl, $nb_campagnes et $nb_tables viennent tous de site_chiffre_cache(...) (Web/site/accueil.php). ⚠ Les phrases fautives ne subsistent que dans le commentaire d'en-tête, qui raconte le correctif — et c'est ce qui a failli les faire recompter comme un défaut.

Ce que la page annonçait avant, pour mémoire :

✅ LES NEUF POINTS DE CETTE SECTION SONT FERMÉS — constaté le 04/09/2026

⚠⚠ Et ils l'étaient depuis les 2ᵉ et 3ᵉ passes du point, sans que personne le note. Cette liste est restée telle quelle pendant que le code la démentait, ligne par ligne. C'est le défaut que ce registre reproche aux autres documents, commis par le registre lui-même.

🔴🔴 LA PUCE DU ZOOM iOS AVAIT RAISON SUR LE SYMPTÔME ET TORT SUR LA CAUSE, et c'est ce qui l'a maintenue vraie deux semaines de plus. Elle accusait un !important manquant. Il ne manquait pas. Ce qui manquait, mesuré le 04/09 sur les 30 pages du panel à 375 px : le sélecteur de la règle énumérait les types un par un (input[type=text], …), et 26 champs du panel n'ont pas d'attribut type — le navigateur leur donne « text », le sélecteur d'attribut ne les voit pas. 51 champs restaient à 13,3 px, sur 6 pages.

📌 Une cause fausse referme la question : on lit « !important manquant », on constate qu'il est là, et l'on classe la puce comme périmée sans jamais rouvrir le navigateur. Corrigé, et gardé par Web/tests/test-panel-mobile.php, éprouvé par mutation (5 blessures sur 5 le font rougir). Le récit complet est dans MOBILE.md.

✅ La contradiction sur les dépôts est tranchée — 03/09/2026

index.php disait « les dépôts sont privés », installation.php disait « git clone fonctionne en anonyme ». installation.php porte désormais l'aveu : « le dépôt est PRIVÉ… était FAUX », et les deux pages s'accordent.

---

63. 🔨 SVSMODE n'est reflété NULLE PART — mesuré le 02/09/2026, PORTÉ le 02/09/2026

Ce que c'est. Un mode utilisateur posé par un service — le +r de l'identification, un -o retiré à un opérateur — n'atteint aucune table d'IriX. Ni <bot>_online.modes, ni <bot>_users.is_oper.

⚠⚠ Et ce n'est PAS le mécanisme habituel du point 56. SVSMODE est bel et bien DIFFUSÉ sur le lien (sendto_server, m_service.c:189) — le dispatcher S2S le reçoit. Mais il n'a aucune branche pour lui : la ligne tombe dans le default, qui écrit « CMD: SVSMODE (ignoré) ».

📌 Le piège est dans le serveur, et il est net : quand un service pose un mode, le démon appelle send_umode_change(…, false) (m_service.c:187), et s_user.c:703-705 ne propage le MODE aux serveurs que si ce drapeau est vrai. Donc le MODE équivalent ne circule pas : SVSMODE est la SEULE trace, et personne ne la lit.

⚠⚠ Ce défaut touche le correctif du point 58 (is_oper, 01/09). refleter_oper suit les branches MODE et UMODE2 ; un -o posé par un service lui échappe entièrement, et la colonne reste à oui jusqu'au départ de la personne.

⚠ Et la table des exceptions du banc d'inventaire dit FAUX à son sujet : test-verbes-atteignables.tcl porte la raison « SVSMODE : services vers serveur ; l'effet revient en MODE ». Mesuré : il ne revient pas. C'est exactement le défaut que ce banc existe pour combattre — une raison raisonnée, jamais mesurée. La corriger fait partie du correctif.

Pour le fermer : une branche SVSMODE - SVS2MODE au dispatcher S2S qui recompose les modes et appelle ::soc::online::on_modes, comme le fait déjà la branche MODE. ⚠ SVS2MODE compte autant que SVSMODE — ils ne diffèrent que par le fait que la personne voit ou non le changement.

Ce qui est PORTÉ, le 02/09/2026 — et ce n'est pas la même chose que fermé :

• la branche SVSMODE - SVS2MODE au dispatcher S2S, qui recompose l'état complet et appelle ::soc::online::on_modes et ::soc::operjoin::sur_modes ;
• une procédure ::soc::ulines::auto::recomposer_umodes, partagée avec la branche MODE qui portait la même boucle en clair — un delta appliqué à deux endroits diverge un jour ;
• la raison fausse de test-verbes-atteignables.tcl corrigée ;
• IriX/tests/test-svsmode.tcl, 24 constats, qui EXÉCUTE la branche au lieu de la relire, et 11 blessures de mutation, 11 rouges.

IriX A RECHARGÉ le 02/09/2026 à 15:20:29, à la demande de SerVuS. Le fichier datait de 14:47:49 : le processus a donc bien lu la version neuve. Redémarrage sain — service actif, zéro redémarrage (pas de boucle d'échec), zéro erreur Tcl dans les quatre sources consultées, lien S2S vivant (16 lignes de trafic sur 90 s, deux EOS, un MODE traité), et IriX_online repeuplée à 8 lignes.

⚠⚠ ET POURTANT CE POINT RESTE OUVERT — pour une raison qui a CHANGÉ. Ce n'était plus « IriX n'a pas rechargé » : c'est que rien n'émet de SVSMODE sur ce réseau. Anope est inactive, et le serveur exclut la source de sa rediffusion (sendto_server(source->from, …)) — les SVS2MODE qu'IriX émet lui-même ne lui reviennent donc jamais. Mesuré après le redémarrage : les seuls verbes tombés dans le default sont les numériques 312, 313, 319, 320 et 378. Aucun SVSMODE, parce qu'aucun n'est arrivé.

📌 Le constat manquant demande un SECOND service lié — c'est exactement ce que test-svsmode.tcl annonce ne pas pouvoir éprouver. ⚠ Le monter n'est pas anodin : le réseau WSL d'essai est en mirrored, et tous les ports de la production sont déjà pris. À décider avec SerVuS, pas seul.

⚠ Un défaut connu subsiste, et il est hors de cette branche : la garde #* protège des SVSMODE de salon, mais la première écriture du banc ne l'éprouvait pas — le cas jouait un salon sans entrée dans user_modes, et le info exists voisin suffisait à tout arrêter. La garde pouvait être retirée sans qu'une ligne rougisse. Trouvé par mutation, corrigé le jour même. Un constat qu'on n'a jamais vu rougir est une intention, pas une garde.

---

62. 🔨 OverScript — dix demandes de SerVuS, le 02/09/2026

⚠⚠ CE POINT EST RESTÉ FIGÉ JUSQU'AU 04/09/2026, alors que six des dix avaient bougé. Il portait encore ses dix lignes en 🔨, sans un mot d'avancement, quatre versions après. C'est exactement ce que ce registre reproche aux autres documents : une affirmation d'état qui vieillit sans que personne la touche.

🔴🔴 ET IL A RECOMMENCÉ LE JOUR MÊME, EN DEUX HEURES. Le tableau a été mesuré à 10:46 ; les cinq chantiers de la 0.6.15 ont été portés entre 11:56 et 13:12, et la ligne (1) est devenue fausse sans que personne y touche. 📌 La leçon n'est pas « il faut être plus attentif » — c'est que tout tableau d'état porte sa date de péremption dans son écriture même. Celui-ci dit désormais quand il a été mesuré, ligne par ligne, plutôt que d'affirmer qu'il est à jour.

⚠ Une seule était un DÉFAUT ; les neuf autres sont des ajouts. Le distinguer change l'ordre : ce qui est cassé passe avant ce qui manque.

✅ LE DÉFAUT — corrigé le 02/09/2026. Dans le fil de discussion, les pseudos qui portent @, % ou + s'affichaient sans leur symbole, alors que la liste des présents les montrait correctement. Deux lectures de la même information qui divergent — le motif que ce projet paie le plus souvent. Le rendu pose désormais msg-signe à côté du pseudo (src/renderer/app.js).

Les neuf ajouts, tels que demandés :

📌 Neuf sur dix ont bougé — mesuré le 04/09 à 15:40, et ce chiffre-ci est le TROISIÈME : six entièrement (1, 2, 3, 4, 6, 9), une à demi (8), une tranchée par un choix de conception à valider (5), une intacte (7).

🔴🔴 ET LA MESURE DE 13:12 ÉTAIT FAUSSE SUR TROIS LIGNES — (1), (3) et (6), déclarées « rien trouvé » ou « à demi » alors que le code était posé depuis le 02/09, dans un commit unique, 93efb25, dont le titre dit « Fermer un reseau, lire les couleurs, deux interrupteurs ». Je n'ai pas cherché le geste, j'ai cherché le mot.

⚠⚠ C'est le travers symétrique de celui que ce point dénonce plus haut. Un tableau d'état peut mentir dans les deux sens : dire fait ce qui ne l'est pas, et dire manquant ce qui existe. Le second coûte plus cher — il fait réécrire ce qui marche, et le doublon masque l'original. 📌 Le remède tient en une ligne : avant d'écrire « rien trouvé », faire un git log -S "<le geste>" sur le fichier. Trente secondes, et le titre du commit répond.

⚠ Ce que la 0.6.15 a apporté n'est PAS dans cette liste : le clic droit sur un pseudo, la fenêtre des nouveautés et l'écriture de la mise en forme sont des demandes du 04/09, arrivées par les rapports du panel. ⚠⚠ Et la barre de mise en forme n'est pas la demande (2) : celle-là décide si l'on VOIT les couleurs des autres, celle-ci de ce qu'on ENVOIE. Les confondre ferait croire le point plus avancé qu'il n'est.

⚠ Ne restent vraiment que (7) et (8), et ce sont les deux plus gros, et le (8) est le seul qui touche à la sécurité — un filtre trop large rendrait le client sourd à des messages légitimes. ⚠⚠ Sa moitié faite est la passive (ne pas répondre, ne pas laisser proliférer) ; sa moitié manquante est l'active (limiter une cadence), et c'est celle qui peut faire taire quelqu'un à tort.

---

61. ✅ Deux numériques s'affichaient bruts À CHAQUE ENTRÉE dans un salon — CONSTATÉ FERMÉ le 01/09/2026 sur Libera.Chat

Ce que c'est. Même famille que le PONG du 31/08 : une réponse du serveur qu'aucune branche ne prend en charge, et qui tombe dans l'affichage tel quel — au milieu du salon.

⚠⚠ Le 470 est le plus coûteux des deux. /join ##chat sur Libera dépose réellement dans ##chat-overflow — constaté. La personne se retrouve dans un salon qu'elle n'a pas demandé et rien ne le lui dit en français. Elle croit être où elle voulait.

Comment ç'a été trouvé — bancs/veille-reelle.js, 20 min sur ##chat, #python, #linux : 26 messages vus, zéro erreur de transport, et 18 lignes brutes toutes arrivées dans les 12 premières secondes. Rien du trafic courant n'échappe au traitement.

📌 Ce que la veille ÉLIMINE compte autant que ce qu'elle trouve : le PONG était un cas isolé, pas la partie visible d'une famille qui déborderait en conversation. Sans cette mesure on aurait pu « corriger » longtemps au hasard.

⚠ Réserve à garder en tête : trafic mince à cette heure (26 messages en 20 min). Une veille en pleine journée éprouverait davantage. Un banc qui n'a pas vu le défaut ne prouve pas son absence.

⚠ Le harnais avait lui-même deux défauts, corrigés depuis : sa colonne de forme affichait la même valeur pour toutes les lignes (elle lisait params, que cette charge ne porte pas) — donc elle ne mesurait rien tout en se lisant comme une mesure ; et il affichait le nom du réseau à l'état pret, émis sur le 001, qui précède le 005 — un null légitime qui faisait soupçonner un défaut inexistant.

✅ CONSTATÉ FERMÉ le 01/09/2026, sur Libera.Chat

Les deux numériques entrent dans FORMES (src/main/irc/numeriques.js). Constaté sur le réseau vivant, pas seulement au banc — c'est la seule preuve qui vaille ici, le défaut n'ayant jamais été visible autrement :

470  type=erreur
     « ##chat vous a renvoye vers ##chat-overflow : vous n etes PAS dans ##chat »
329  type=info
     « ##chat-overflow existe depuis le 19/05/2021 a 14:43 »

📌 Le 470 nomme les DEUX salons, et dans le bon sens. « renvoyé vers ##chat » serait aussi lisible et exactement faux ; un constat garde le sens, pas seulement les noms.

5 constats neufs dans bancs/numeriques.test.js (30 au total), 9 blessures toutes mordantes.

⚠⚠ Deux défauts trouvés en chemin, et aucun des deux n'était celui qu'on cherchait :

1. Un commentaire du dépôt disait l'INVERSE du code, et m'a fait écrire le défaut. L'en-tête de FORMES annonçait « rend un texte — ou null pour tomber sur le repli ». C'est faux : null veut dire ne rien afficher (c'est ainsi que le 318 se tait), et le repli s'obtient par une chaîne vide. Mes deux gabarits rendaient donc null sur une ligne malformée — ils la perdaient en silence, précisément ce que tout ce fichier existe pour empêcher. 📌 L'explication détaillée, vingt lignes plus bas, était juste. Une explication juste enterrée sous un résumé faux ne protège personne.
2. Le 470 prenait le TEXTE du serveur pour un nom de salon. Sur 470 <nous> ##seul :Forwarding to another channel, un simple a[0] && a[1] écrivait « ##seul vous a renvoyé vers Forwarding to another channel » — une phrase bien formée, en français, et entièrement fausse. ⚠ Trouvé par la mutation, sur un cas d'essai que j'avais écrit en croyant tester autre chose. Les deux paramètres doivent être des salons (estSalon), sinon on retombe sur le repli.

60. 🟡 Modération dans OverScript — LE LECTEUR EST POSÉ le 04/09/2026, rien n'est branché

✅ Ce qui existe depuis le 04/09/2026

src/main/moderation.js lit la liste, normalise, et répond à une seule question : ce message contient-il un mot de la liste, et de quelle gravité ? 12 constats, 8 blessures de mutation sur 8 vues.

🔴 Il ne sanctionne personne, et un constat du banc le garde : il lit son propre source et refuse d'y trouver KICK, MODE ou un envoi. Rien n'est branché — le comportement du client est inchangé, et actif_par_defaut reste false.

⚠⚠ ET LE PREMIER RÉFLEXE AURAIT ÉTÉ FAUX. Avant d'écrire une ligne, la question de la règle 5 : par quel mécanisme ce fichier voyage-t-il ? Mesuré — il ne voyage pas. electron-builder.yml porte une liste fermée de ce qui entre dans le paquet, et Config/ n'y figure pas. Un module qui aurait lu Config/moderation-mots.json aurait marché parfaitement dans le dépôt, tous bancs verts, et jamais chez personne.

📌 D'où deux emplacements, le motif d'identity.json.example : la liste de départ voyage sous src/main/moderation-liste.js, engendrée depuis le JSON (Tools/engendrer-liste-moderation.js — dérivée, jamais recopiée) ; la liste de l'utilisateur vit dans son dossier de données, où elle est éditable, le paquet étant en lecture seule.

⚠ Une huitième blessure a d'abord fait un TROU, et la cause était un vrai défaut : le drapeau i de l'expression régulière rendait le .toLowerCase() inutile. Deux gardes pour la même chose, dont l'une masquait l'autre — une garde masquée est une garde qu'on croit éprouvée.

✅ Le branchement est fait — 04/09/2026, publié en 0.6.16

Quatre garde-fous, et chacun porte sa blessure : éteinte par défaut · jamais en privé (on n'y a aucun pouvoir) · jamais ses propres messages · seulement là où l'on porte un grade.

⚠⚠ Ils vivent dans moderation.avisPour, PAS dans le pont — et c'est la seule raison pour laquelle ils sont éprouvés. Le premier jet les gardait au milieu d'un écouteur d'événement de pont.js : rien ne pouvait les mesurer. Sortis dans une fonction qui reçoit des faits, ils portent quatre constats et quatre blessures. Un banc qui mesure la chose ne mesure pas son emploi — et l'emploi, ici, c'est la suite des refus.

⚠ Le signe se DEMANDE à la session (monSigneDans, extrait de _vueSalon), il ne se recalcule pas : deux implémentations de la même règle divergent, et celle-ci a déjà fait afficher « sans grade dans ce salon » à un opérateur. ⚠⚠ Et '' est un signe IRC valide — « présent sans grade » — qu'il faut refuser explicitement : un == null le laisserait passer.

Ce que voit l'utilisateur : un interrupteur « Modération : Off » et, quand il l'allume, une ligne dans le salon concerné — « ⚠ modération — Quidam : « … » (insulte, gravité 2). Rien n'a été envoyé. Pour agir : /mode #salon -v Quidam ».

🔴 AUCUN BOUTON, ET C'EST LA DÉCISION DU POINT. Taper la commande reste un geste, et ce geste est le garde-fou. On découvre ainsi le taux de faux positifs avant de rendre l'action facile. ⚠ Le titre de l'interrupteur dit que rien ne part sans vous, et un constat l'exige : un interrupteur nommé « Modération » se comprend spontanément comme « le script va agir à ma place ».

📌 Ce qui reste à trancher par SerVuS : l'automatique. Il ne se posera utilement qu'après avoir vu ce que la liste repère sur de vraies conversations.

✅ PUBLIÉ en 0.6.16 — constaté depuis l'extérieur le 04/09/2026

Les cinq fichiers déposés à 16:00, le numéro annoncé à 16:02. Les trois paquets sont servis avec une empreinte identique au binaire local (Windows 91,0 Mo · AppImage 129,3 Mo · deb 101,9 Mo), et la section « ## 0.6.16 » figure dans le journal servi.

Web/tests/test-overscript.php, sur la machine qui sert : 52 constats, 0 échec — dont « le numéro annoncé par le site EST celui du binaire construit », « le binaire servi est bien celui que ce latest.yml décrit », et « tout paquet déposé est annoncé dans plateformes ».

⚠ L'installation locale n'a PAS été faite : OverScript vit dans C:\Program Files, et y installer demande une élévation. Un /S lancé sans droits échoue en silence — la version installée est restée en 0.6.15, intacte. Poser une invite UAC sur la machine de SerVuS en son absence n'était pas à faire. 📌 Sans installation, le point 59 ne peut pas être constaté sur l'application empaquetée.

Mesuré : 19 constats sur le module, 13 sur l'interface, 15 blessures de mutation sur 15 vues.

⚠⚠ Ce qui doit être tranché par SerVuS avant tout automatique : une expulsion décidée par une liste de mots frappe une personne réelle sur un faux positif. Le fichier de mots le dit lui-même — « Une expulsion sur un faux positif coûte plus cher que le message qu'elle empêche » — et il énumère ce qu'une liste ne peut pas voir : la citation (« il m'a traité de connard » est un signalement), l'ironie entre gens qui se connaissent, les déformations, et la phrase blessante qui n'emploie aucun de ces mots.

60bis. 🔨 La demande d'origine, telle que formulée — 31/08/2026

Ce qu'il demande. Un service de modération dans le client : repérer les mots incorrects et les insultes, et proposer d'activer le traitement automatique au moment où l'on devient @ sur un salon — pour que le script agisse sans qu'on ait à le faire à la main.

📌 Le moment choisi est le bon. Devenir opérateur est exactement l'instant où la question a un sens : avant, on n'a aucun pouvoir d'agir ; après, on en a un et on ne s'en sert pas toujours. La proposition arrive quand elle est utile, et elle se refuse.

⚠⚠ CE QUI EST TRANCHÉ DÈS MAINTENANT : LA LISTE NE SE RÉCOLTE PAS.

L'idée est venue pendant une veille sur des salons publics de Libera.Chat, et il serait facile d'en tirer un lexique. On ne le fera pas. Ces personnes ne savent pas qu'un client d'essai écoute ; retenir leurs messages pour en dériver quoi que ce soit serait les collecter sans raison ni accord. La veille (bancs/veille-reelle.js) est écrite pour ne garder que des verbes de protocole, et son en-tête dit pourquoi.

La liste appartient donc à l'exploitant : un fichier qu'il ouvre, remplit et corrige. Trois conséquences de forme :

Ce qui reste à trancher, et qui n'est pas technique :

1. ⚠ Que fait le traitement automatique ? Avertir, retirer la voix, expulser, bannir — l'échelle n'est pas la même, et une expulsion automatique sur un faux positif coûte plus cher que le message qu'elle empêche. 📌 Commencer par le degré le plus faible qui serve à quelque chose.
2. ⚠⚠ Un mot n'est pas une intention. Une correspondance simple frappe les citations, les pseudonymes, et les mots contenus dans d'autres. Le projet a déjà payé ce piège côté serveur — voir la modération des messages privés.
3. Qui voit la trace ? Une action automatique sans journal lisible est une action que personne ne peut contester.

⚠ À ne pas confondre avec la modération du SERVEUR (Markdown/, filtre C, annonce) : celle-ci vit dans le CLIENT, ne vaut que pour les salons où l'on est @, et ne protège que soi — un autre client du même salon n'en bénéficie pas. C'est une commodité d'opérateur, pas une politique de réseau.

59. 🔴 LA FENÊTRE UNIQUE N'EST CONSTRUITE QU'À MOITIÉ — mesuré le 31/08/2026, APRÈS publication

Ce que c'est. La 0.5.0 a été publiée en annonçant « plusieurs réseaux dans une seule fenêtre ». C'est faux. L'affichage sait grouper plusieurs réseaux ; rien ne peut en créer un second.

ponts = Map( webContents.id → UN Pont )     ← une fenêtre, une entrée
Pont.session = une seule session            ← remplacée à chaque connexion

Une fenêtre porte donc exactement une connexion. /server -m ouvre une nouvelle fenêtre parce que c'est la seule chose que le client sache faire — nouvelleFenetre() est le seul chemin, et il crée fenêtre + pont ensemble.

⚠⚠ CE QUE LA « PREUVE » PROUVAIT EN RÉALITÉ. J'ai écrit, en fusionnant : « Constaté à la capture : ReseauA/#chez-a et ReseauB/#chez-b, chacun sous sa tête de groupe. » C'était vrai — et sans rapport. bancs/rendu.js fabrique les événements avec des conn inventés : il éprouve le GROUPEMENT, jamais la voie qui produirait deux connexions réelles. 577 constats verts, et pas un seul ne touchait le manque.

📌 C'est le motif du 31/08, à sa pire occurrence : non plus du code mort découvert dans l'existant, mais une fonctionnalité publiée dont la moitié n'existe pas — et une capture d'écran qui donnait l'illusion du contraire. Une preuve qui montre la chose ne montre pas son emploi.

Symptômes rapportés par SerVuS le soir même, tous deux exacts et tous deux inévitables :

Pour le fermer — le travail est dans le processus PRINCIPAL, pas dans l'affichage :

1. ✅ ponts doit associer une fenêtre à plusieurs ponts (ou un pont à plusieurs sessions), et pontDe(ev) choisir lequel — vraisemblablement par l'idConnexion que le rendu porte déjà.
2. ✅ Un canal irc:connecter qui ajoute au lieu de remplacer.
3. ✅ /server -m branché dessus au lieu de nouvelleFenetre.
4. ✅ ⚠⚠ Et un banc qui parte de la commande, pas de l'affichage : /server -m doit produire DEUX sessions vivantes dans une fenêtre. C'est exactement le constat qui manquait.

⚠ Ne pas retirer nouvelleFenetre : deux fenêtres restent légitimes (deux écrans). C'est le défaut par lequel -m passe qui doit changer, pas la possibilité.

✅ LES QUATRE SONT FAITS — 01/09/2026

Les (1) et (2) l'étaient depuis le refactor multi-réseau : Pont.liens est une Map, et la ligne if (this.connexion) this.deconnecter(); a quitté la tête de connecter(). Les (3) et (4) ont été faits ce jour.

⚠⚠ -m A CHANGÉ DE SENS, et c'est une conséquence, pas un choix esthétique. Depuis que valider le panneau AJOUTE un réseau, -m ouvrait une fenêtre pour obtenir ce que la fenêtre courante savait déjà faire — deux lignes « Serveur » dont l'une était la tête locale d'une fenêtre vide. Il pré-remplit désormais le panneau de CETTE fenêtre. La seconde fenêtre n'est pas perdue : elle prend le drapeau -w, servie par nouvelleFenetre inchangée, et un constat la garde — sans lui, cette voie serait devenue morte sans que personne s'en aperçoive.

📌 Le banc part de la commande et va jusqu'au bout : il tape /server -m, vérifie qu'aucune fenêtre n'est demandée, lit le panneau pré-rempli, le valide, et regarde ce qui part. Le constat qui porte le défaut vécu par SerVuS est celui-ci — « et RIEN ne déconnecte le réseau déjà ouvert ». 7 constats neufs dans bancs/rendu.js (269 au total), 6 blessures de mutation toutes mordantes, dont « valider DÉCONNECTE le réseau déjà ouvert » (5 échecs) et « /server -m rouvre une fenêtre » — le défaut d'origine du point.

🔨 Ce qui reste avant de le déclarer CONSTATÉ : le voir sur l'application installée. Le banc charge la vraie page dans une vraie fenêtre Electron, ce qui est beaucoup — mais l'installé porte son propre code, et c'est la leçon de la 0.4.3.

58. 🔨 DEUX COLONNES QUE PERSONNE N'ÉCRIT, ET UN BALAYAGE QUI LES VIDE CHAQUE NUIT — mesuré le 31/08/2026

Ce que c'est. IriX_users.is_oper et IriX_users.away ne peuvent jamais valoir oui. Leurs seuls écrivains sont des procédures du point 56 — celles qui ne s'exécutent pas. Et ::soc::scan::daily les remet à non toutes les nuits, avec en commentaire « sera remis à oui via RAW OPER au prochain rejoin » : il désigne nommément le chemin mort comme sa contrepartie.

📌 C'est une forme neuve du motif du 31/08, et la plus retorse rencontrée jusqu'ici. Ailleurs, une procédure morte laissait simplement un trou. Ici un second mécanisme, bien vivant, entretient le trou — et son commentaire explique pourquoi c'est normal. Un lecteur qui vérifie le balayage le trouve juste : il fait exactement ce qu'il annonce. Le mensonge n'est dans aucune des deux moitiés, il est dans leur raccord.

Ce qui a été mesuré, statique puis en base :

Ce que cela empêche, exactement — ni plus, ni moins :

• ⚠ ::soc::get_grade rend netadmin sur cette seule condition. Ce grade, sommet de l'ordre {user voice operateur admin proprietaire netadmin}, est donc inatteignable par construction. Un opérateur IRC réel redescend sur proprietaire ou admin, et son rang de réseau ne compte pas dans irix-chanaccess.tcl.
• ⚠ !stats annonce toujours « IRCop : 0 », quel que soit le réseau.
• 🟢 Aucune garde n'EXIGE netadmin — vérifié, et Web/inc/commandes.php le notait déjà. Rien n'est donc bloqué : le défaut sous-évalue et sous-compte, il n'interdit rien.
• 🟢 L'absence est partiellement rattrapée pour vhost/ident/ip par les numériques 311/320/338/352/354, qui sont atteignables — mais pas pour is_oper ni away, qui n'ont aucun repêchage par sondage.

Pour le fermer — ⚠ le portage ne consiste PAS à écrire une branche OPER : ce verbe n'existe pas en S2S. Le signal équivalent est +o sur UMODE2 (branche existante) ou MODE, toutes deux déjà branchées. Il faut donc greffer sur une branche vivante, avec traduction UID→pseudo, et accepter que oper_type reste vide — le S2S ne le transporte pas.

⚠⚠ Et ne pas commencer par le balayage. Retirer la remise à zéro sans le repeuplement figerait is_oper sur des valeurs qui ne redescendraient plus jamais : on remplacerait « toujours faux » par « faux et périmé », ce qui est pire. Les deux moitiés se réparent ensemble ou pas du tout.

🔨 LE CODE EST ÉCRIT — 01/09/2026 — il reste à le CONSTATER en service

Fait exactement comme ce point le prescrivait : greffé sur une branche vivante, oper_type laissé vide, et les deux moitiés du même geste.

::soc::online::refleter_oper (dans irix-online.tcl) reporte le +o d'une connexion dans _users.is_oper. ⚠⚠ Elle vise auth_uid, jamais le pseudonyme — la doctrine du 07/08 : sans cela, reprendre le pseudo d'un opérateur qui vient de partir suffirait à hériter de son grade. Et cela écarte la casse au passage, un UID étant opaque là où SQL et Tcl divergent sur les noms.

Cinq points d'emploi, et il en fallait cinq :

⚠ Les (4) et (5) sont le défaut symétrique dont ce point prévenait, et ils se gardent ensemble.

📌 away est traitée à part, et par la négative : elle n'a aucun lecteur, son seul écrivain possible relève du même mécanisme mort, et le point 56 a tranché qu'il ne serait pas porté. Le balayage nocturne cesse de la vider — balayer une colonne que nul n'écrit ni ne lit n'était pas faux, c'était du bruit qui avait l'air d'un entretien. ⚠ La colonne n'est PAS supprimée : une migration destructive pour du bruit serait un mauvais échange.

Banc IriX/tests/test-oper-vivant.tcl — 20 constats, 10 blessures toutes mordantes, dont les cinq emplois et le retour du balayage. ⚠⚠ Une onzième blessure a d'abord été annoncée sans mordre, et elle mérite d'être notée : le constat « le balayage n'écrase plus » cherchait un motif où le backtick n'était pas échappé — il rendait donc 0 dans les DEUX mondes. Le banc porte désormais un plancher sur ses propres motifs : on leur donne à lire un échantillon qui doit matcher.

🔨 Ce qui reste, et je ne peux pas le faire seul : IriX relancé, un opérateur qui se met +o, et !stats qui cesse d'annoncer « IRCop : 0 ». Le code neuf n'agit qu'au prochain démarrage.

57. ✅ LA DISTRIBUTION CONNAÎT CINQ PAQUETS — ouvert le 31/08/2026, ÉLARGI le 02–03/09

Constaté en service, pas seulement au banc : un paquet déposé dans Web/.run/ fait apparaître son bloc sur la page et sa clé dans la réponse JSON, /dl/<clé> le sert, et son retrait fait tout redisparaître. Éprouvé dans les deux sens le jour même.

📌 L'inventaire porte désormais CINQ entrées de type client : Windows, les deux macOS (encore inertes, aucun .dmg n'ayant été construit) et les deux Linux, publiés le 02/09. Le manifeste ne liste que ce qui existe, et la page s'allume d'elle-même. La procédure de dépôt — cinq copies — est dans Markdown/WEB.md.

⚠⚠ Ce qui a guidé le chantier : ne pas casser les clients DÉJÀ INSTALLÉS. Un client ≤ 0.6.9 lit fichier/sha256/taille à plat, sans notion de plateforme — les faire varier ferait télécharger un .deb à un Windows, c'est-à-dire casserait le mécanisme même qui sert à mettre les clients à jour. Ces trois champs continuent donc de décrire Windows.

🔴 ET CE N'ÉTAIT PAS FINI, CONTRAIREMENT À CE QUE CE POINT A DIT DU 31/08 AU 03/09. Le site avait sa clé plateformes ; le client ne la lisait pas, et le site n'y mettait pas Linux. Le 02/09, les deux paquets Linux étaient publiés, téléchargeables — et un poste Linux qui demandait une mise à jour recevait quatre-vingt-dix mégaoctets d'installateur .exe, puis un refus. Fermé le 03/09 par la 0.6.10 du client.

⚠⚠ Trois listes recopiées, découvertes le même jour, chacune par une porte différente : la clé plateformes de site_overscript_public(), la liste $systemes de versions-overscript.php, et le libellé du paquet Windows qui ne nommait pas son système sous une colonne « Système ». Chaque fois, les constats existants étaient verts : ils parcouraient ce qui est annoncé, jamais ce qui aurait dû l'être. Les trois dérivent maintenant de distrib_inventaire().

📌 Gardé par test-overscript.php — le compte n'est pas écrit ici, il monte à chaque chantier ; php Web/tests/test-overscript.php le dit.

⚠ Aucune détection du système du visiteur : le site ne lit l'User-Agent nulle part, cet en-tête ment de plus en plus, et deviner mal cacherait à quelqu'un le fichier dont il a besoin. On montre ce qui existe, il choisit.

🟡 Ce qui reste, et ne dépend plus de moi : qu'un .dmg soit construit sur un Mac. Et la décision du compte développeur Apple, sans lequel chaque personne contourne Gatekeeper à la main.

<details><summary>L'état d'avant, gardé pour mémoire</summary>

57 (état d'origine). 🔨 LA DISTRIBUTION NE CONNAÎT QU'UNE SEULE PLATEFORME

Ce que c'est. Une version d'essai d'OverScript part vers un Mac, et le site n'a nulle part où la mettre. Il sert un seul binaire, sous un nom sans plateforme, et latest.yml n'en décrit qu'un.

⚠ Le verrou n'est pas la construction du paquet — elle est prête et éprouvée (dmg + zip, x64 et arm64, bancs/paquet-mac.test.js). C'est la distribution. Même avec un .dmg en main demain, il n'y aurait ni où le déposer, ni comment l'annoncer, ni comment le client saurait lequel prendre.

Ce qu'il faudrait pour le fermer, les fichiers étant déjà repérés :

⚠⚠ La compatibilité est le point délicat. Le client 0.4.6 attend fichier, sha256 et taille au singulier. Changer leur forme casserait tous les clients installés — c'est-à-dire le mécanisme même qui sert à les mettre à jour. 📌 Il faut donc AJOUTER une section par plateforme en gardant les champs actuels, et non les remplacer.

⚠ Web/.run/overscript-latest.yml est lu par le banc mais absent de l'inventaire : il n'est donc pas servi. À décider en même temps.

🔴 Et une décision qui appartient à SerVuS : sans compte développeur Apple (payant, annuel), chaque personne devra contourner Gatekeeper à la main au premier lancement. C'est écrit dans Dev/OverScript/MACOS.md, et présenté comme attendu — mais cela reste un frein à toute distribution large.

</details>

56. 🔨 UNE TRENTAINE DE PROCÉDURES QUI NE S'EXÉCUTENT JAMAIS — mesuré le 31/08/2026

Ce que c'est. En réparant on_SERVER ce matin, on a trouvé que le défaut n'était pas isolé : c'est un motif, et il touche une trentaine de procédures d'IriX. Deux mécanismes distincts, qui se cumulent.

⚠⚠ Mécanisme 1 — bind raw écoute la connexion CLIENTE

IriX-binds.tcl lie 42 verbes à ::soc::raw::dispatch. Or bind raw d'Eggdrop n'écoute que le flux de la connexion cliente du bot. Une trentaine de ces verbes sont strictement serveur-à-serveur ou client→serveur : un client n'en reçoit jamais.

Les plus coûteuses, parce qu'elles écrivent en base ou ferment des sessions — donc leur mort est silencieuse :

📌 LE MOTIF, énoncé une bonne fois — il est revenu CINQ fois

Chacun de ces défauts a la même forme, et aucun n'est une faute de codage :

Le code est juste. C'est son EMPLOI qui manque — et quelque chose donne l'illusion que ça marche.

on_SERVER (colonnes vides), TOPIC (sujet périmé sur le site), track_burst (cinq colonnes vides, rattrapées par reconcile), le 421 (deux journaux au lieu d'un), le client OverScript qui écoutait le mauvais numérique. ⚠⚠ Et à chaque fois un banc existait et restait VERT : il mesurait la chose, jamais son emploi.

📌 D'où la règle qui en sort, et qui vaut pour tout banc neuf : un banc qui éprouve une procédure doit AUSSI éprouver qu'on l'appelle — depuis où, et avec quels arguments. Les deux bancs posés aujourd'hui le font, et leurs blessures de câblage mordent.

⚠ Corollaire, appris le 31/08 : une réparation s'applique à l'instance, jamais au motif. Le piège du burst avait été trouvé et réparé pour les salons des mois plus tôt ; personne n'avait demandé quels autres verbes étaient logés à la même enseigne. Trois l'étaient.

⚠⚠ Mécanisme 2 — le burst est lu par une boucle BLOQUANTE

La lecture du burst se fait dans une boucle qui avale tout avant de poser le fileevent. Tout verbe qui n'arrive que pendant le burst n'atteint donc jamais le dispatcher S2S — même s'il y a une branche. C'est ce qui avait été trouvé pour le burst de salon, réparé pour lui seul.

✅ SID est traité depuis le 31/08 — il cumulait les deux mécanismes (aucune branche et arrivée pendant le burst), et c'est lui qui annonce tous les serveurs derrière le pair.

✅ TOPIC est traité depuis le 31/08 — IriX/tests/test-topic-s2s.tcl, 41 constats, dix blessures de mutation toutes mordantes. C'était le seul des trois à alimenter une vue : le site affiche <bot>_channels.topic (Web/pages/salons.php), et cette colonne n'était écrite que par bind raw TOPIC, donc pour les seuls salons où le bot siège. Ailleurs, le sujet restait faux indéfiniment. ⚠⚠ Les deux formes du verbe ne se distinguent pas par expression régulière — le troisième champ est le poseur au burst et le sujet en service, et « rendez-vous samedi 20 » satisfait le motif long : on compte les paramètres comme IRC les compte, au premier " :", comme le daemon lui-même (parc >= 5).

⛔ AWAY ne sera pas porté, et c'est une décision, pas un oubli. Mesuré le 31/08 : personne ne lit <bot>_users.away ni away_msg — ni le Tcl, ni le PHP, nulle part dans le dépôt. Le serveur tient son propre état et répond lui-même RPL_AWAY (src/cmd/m_query.c). Porter le verbe remplirait deux colonnes que rien n'affiche. ⚠ Si un jour une vue les lit, ce point se rouvre — et c'est alors le même travail que pour TOPIC.

⛔ Les MODE #salon +b du burst non plus. Le daemon les émet bien (s_serv.c, juste avant le TOPIC du burst), et aucun des deux lecteurs ne les voit — c'est exact. Mais ils annoncent des bans préexistants, pas un changement : les enregistrer fabriquerait un événement par ban à chaque montée de lien. Et <bot>_bans n'est pas un reflet du serveur, c'est la liste des bans permanents du bot (newban/delban). Aucune vue n'est donc périmée. ⚠ C'est la différence de nature avec TOPIC, et c'est elle qui tranche — pas la difficulté technique, qui serait la même.

✅ ⚠⚠ DEUX BANCS SONT VERTS SUR DU CODE MORT — LES DEUX SONT REPOINTÉS (02/09/2026)

test-sessions.tcl exécutait on_WEBIRC et constatait que son SQL est correct — un SQL qui ne s'exécuterait jamais. test-auth.tcl gardait la révocation dans on_SVSNICK/on_SVSKILL/on_KILL, révocation que ce chemin ne déclencherait jamais. C'était la confirmation mensongère à l'état pur, et ces deux bancs sont à relire avant de toucher au code.

📌 La couverture a été MESURÉE le 31/08 — et la bonne question n'était pas celle-là

La question utile n'est pas « ces procédures sont-elles mortes ? » (elles le sont) mais « le travail qu'elles prétendent faire est-il fait ailleurs, et INTÉGRALEMENT ? ».

⚠ Cette phrase a annoncé « quatre verdicts » en n'en listant que trois, du 31/08 au 01/09 — et le quatrième manquant était le seul « PAS COUVERT » de tout le point. Un compte écrit à la main au-dessus d'une liste finit toujours par mentir sur elle : on ne les énumère plus. Réponse :

• ✅ on_WEBIRC — COUVERT, et RETIRÉE le 02/09. online::on_uid → session_open écrit déjà ip, et c'est la vraie : encode_ip lit sockhost, où adopter_ip_relayee a posé le X-Forwarded-For validé du webchat. online::flush la repose même sur les sessions incomplètes. ⚠ Le SQL mort ne pourrait d'ailleurs rien toucher : il exige socket_id=0, que plus aucun appelant ne produit. Seul résidu : la ligne d'événement WEBIRC, du journal pur.
• ✅ 🟡 on_SVSKILL et on_KILL — PARTIELLEMENT couverts — PORTÉS le 31/08/2026 à 19:10 (ed5456c), et ce verdict est resté périmé un jour et demi. ::soc::ulines::auto::on_kill_s2s vit sur le dispatcher S2S ; banc IriX/tests/test-kill-s2s.tcl, 27 constats. L'écart décrit ci-dessous — event_type bloqué à 'quit', quit_msg vide, tueur introuvable — est comblé. ⚠⚠ CE VERDICT M'A FAIT REFAIRE LE TRAVAIL le 01/09. J'ai lu « il reste à porter » dans ce registre, et j'ai réécrit on_kill_s2s à côté de celui qui existait déjà — plus une branche KILL - SVSKILL en double qui, en Tcl, aurait masqué la branche existante et supprimé la détection de nos propres pseudo-clients tués (mark_ghost). Défait sans dommage. 📌 Le commit ed5456c avait porté le verbe et écrit son banc — sans toucher au registre. Un point corrigé dans le code et laissé ouvert ici ne coûte pas rien : il coûte le travail d'un autre jour. C'est la contrepartie exacte de la règle « un point ne sort qu'après avoir été CONSTATÉ fermé » : elle vaut pour la sortie, jamais pour le silence.
• ✅ Et la dépendance cachée est désormais GARDÉE DU CÔTÉ QUI ÉMET — Servers/overtchat-hybrid/tests/test-kill-quit.py, 10 constats, 19ᵉ campagne du lanceur. test-kill-s2s.tcl savait dire que rien ne gardait FLAGS_KILLED ; il ne pouvait pas être ce gardien, étant du mauvais côté du fil.
• ✅ on_SQUIT — LE VERDICT QUI MANQUAIT, mesuré le 01/09/2026 : il était PAS COUVERT. <bot>_servers.online n'avait que deux écrivains de la valeur 'non' — on_SQUIT, morte, et ::soc::evt_quit, vivante mais qui ne reconnaît un départ de serveur qu'à un message de QUIT portant deux noms de serveur : la signature d'un netsplit. ⚠⚠ Un délink PROPRE — l'arrêt volontaire d'un service, exactement le scénario Anope — n'en produit aucun. La table gardait donc online='oui' indéfiniment, et SERVERS comme MAP comptaient un serveur mort comme vivant. 📌 Et le lien VOYAIT ce SQUIT : la branche du dispatcher le lisait, décidait s'il nous visait, et le jetait après un putlog. Porté : ::soc::srv::offline_cible, appelée depuis cette branche, du côté « ce n'est pas nous ». ⚠ Elle vise servername ou numeric_id — un SQUIT désigne sa cible par l'un ou l'autre, et srv::offline ne connaissait que le nom : appelée avec un SID, elle n'aurait rien trouvé et rien dit. Banc IriX/tests/test-squit.tcl étendu (12 → 20 vérifications), 6 blessures toutes mordantes.
• ✅ on_CHGHOST, on_CHGIDENT, on_CHGNAME — PORTÉS le 01/09/2026, et avec eux le point dur décrit plus bas. ::soc::ulines::auto::on_chghost_s2s vit sur le dispatcher S2S ; ces trois verbes tombaient jusque-là dans default, c'est-à-dire dans un putlog (ignoré). ⚠⚠ Mesuré dans le code du serveur : ce sont les SEULS qu'il émette pour un changement d'identité — :<UID-src> CHGHOST|CHGIDENT <UID-cible> <valeur> et CHGNAME avec un trailing. SETHOST, SETIDENT, SETNAME, VHOST, VIDENT ne partent NULLE PART sur le lien ; ils figurent pourtant dans _raw_cmds. Les lister ne coûte rien et n'apporte rien ; croire qu'on les traite coûte cher. ⚠⚠ ET LE CLOAKING (+x) NE PASSERA JAMAIS PAR LÀ : poser +x n'émet aucun CHGHOST, seul MODE <uid> :+x circule, et chaque serveur recalcule le masque de son côté. IriX ne peut pas apprendre un hôte masqué par le lien — propriété du protocole, à savoir avant d'aller chercher pourquoi une colonne « ne suit pas ». 📌 Un défaut du serveur, trouvé en mesurant : m_oper.c:170 émet CHGHOST <username> <hôte> — premier paramètre l'ident, pas la cible, contrairement à ses trois voisins et à son propre ms_chghost. Une telle ligne ne désigne aucun UID connu : elle est refusée et dite au journal, jamais appliquée à quelqu'un au hasard. Un constat le garde. Banc IriX/tests/test-online-maj.tcl, 34 constats, 15 blessures toutes mordantes.
• 🟡 on_CHGHOST, on_CHGIDENT, on_VHOST — PARTIELLEMENT couverts, mesuré le 01/09/2026. Les sondages par numériques (311/320/352/354) écrivent bien _users.vhost/.ident et _sessions.vhost/.ident. ⚠ Trois réserves : la portée se limite aux salons du bot (le WHO horaire boucle sur [channels] sous botonchan), la latence va jusqu'à une heure, et les lignes _events de type CHGHOST/CHGIDENT/VHOST sont perdues — ces trois evt_record n'ont aucun autre appelant. ✅ ET LE POINT DUR QUE PERSONNE N'AVAIT NOMMÉ — RÉPARÉ le 01/09. <bot>_online n'avait qu'un seul écrivain de vhost, host, ident et realname : la branche d'insertion d'online::flush, alimentée uniquement à l'introduction du client. La branche de mise à jour partielle était câblée sur deux colonnes en dur — foreach col {nick modes}. Un changement d'hôte laissait donc la valeur figée pour toute la durée de la connexion, et c'est la table que le panel montre en direct. ⚠⚠ C'est plus retors qu'une procédure morte : le mécanisme MARCHAIT, sur deux colonnes sur neuf. La ligne existait et paraissait tenue à jour. Une ligne présente et périmée est pire qu'une ligne absente : elle a l'air mesurée. Même piège que les cinq colonnes vides du burst. 📌 Les deux moitiés ont été faites ensemble, et il le fallait : élargir la liste sans écrivain aurait ajouté une capacité morte de plus — le défaut même que ce point recense —, et poser l'écrivain sans élargir la liste n'aurait rien écrit. online::on_hote est le producteur, la liste passe à {nick modes ident host vhost realname}. ⚠ Pas socket_id, ip ni is_svc : ils n'ont pas à changer pendant une connexion, et une mise à jour partielle qui les porterait déplacerait une ligne d'un lien à l'autre. ⚠ flush n'avait AUCUN banc — les deux qui nommaient ::soc::online:: la doublaient au lieu de l'exécuter. L'écrivain de la table du direct n'était éprouvé nulle part.
• ⛔ on_SVSNICK — NE SE PORTERA PAS, et ce n'est pas un renoncement. Mesuré le 01/09/2026 dans le code du serveur : m_service.c:82 fait sendto_one(target, …), pas sendto_server. Le SVSNICK est ROUTÉ vers le serveur qui héberge la cible, jamais DIFFUSÉ. Un ULine en feuille — c'est notre cas — ne se trouve sur ce chemin que s'il héberge lui-même la cible, ce qui n'arrive pas. Aucune branche de dispatcher ne le recevrait jamais. Ce qui circule ensuite est un NICK ordinaire, émis par le serveur du client : à le lire, un renommage imposé est indiscernable d'un changement de pseudo volontaire. ✅ La trace s'écrit donc à l'ÉMISSION, dans nickguard::enforce — le seul instant où l'information « ce renommage a été imposé, et par nous » existe quelque part. evt_record SVSNICK y est posé après l'émission (une trace écrite avant décrirait ce qui n'a pas eu lieu si le lien tombait entre les deux). ⚠ Le journal du service ne remplace pas l'événement : Web/pages/activite.php lit _events, pas svc_log — deux destinations, deux publics. Banc test-nickguard-exempt.tcl étendu (12 → 18 constats), 5 blessures toutes mordantes. 📌 Un verbe qu'on ne peut pas recevoir n'a pas de « chemin vivant » à trouver : la question cesse d'être « où le brancher » et devient « où l'information naît-elle ».

⚠⚠ ET LA DÉPENDANCE CACHÉE (gardée depuis le 01/09 — voir plus bas) : toute cette couverture tient à ce que overtchat-hybrid émette KILL et QUIT pour la même victime. Il pose bien FLAGS_KILLED (m_oper.c, m_service.c) mais ne le lit nulle part — pas de IsKilled dans l'arbre — là où le hybrid d'origine s'en sert pour supprimer le QUIT. 📌 Si quelqu'un « corrigeait » cet oubli, les sessions des tués resteraient ouvertes indéfiniment et l'auth survivrait au kill partout hors des salons du bot. C'est le premier banc à écrire ici — avant toute suppression de code mort.

✅ CE BANC EST ÉCRIT — 01/09/2026, et l'étape 0 est franchie

Servers/overtchat-hybrid/tests/test-kill-quit.py, 10 constats, inscrit au lanceur (19ᵉ campagne). Le comportement redouté est mesuré, pas supposé : un KILL produit bien un KILL et un QUIT sur le lien, et le QUIT porte « Killed ».

⚠⚠ Le point d'observation est un pair S2S BRUT, et il devait l'être. Un témoin client n'aurait rien prouvé : un serveur voisin qui reçoit un KILL fait sortir la victime de ses salons et émet un QUIT local à ses membres. Un client aurait donc vu un QUIT même si aucun n'avait traversé le lien — le banc serait passé par une autre porte que celle qu'il prétend garder.

Mutation : le « correctif » lui-même — lire FLAGS_KILLED dans exit_client_from pour supprimer le QUIT redondant, recompiler, relancer. Le banc rougit. ⚠ La restauration recompile aussi : laisser le binaire blessé ferait mentir les dix-huit autres campagnes, en vert et en silence.

⚠⚠ ET LA MUTATION A TROUVÉ QUE LE BANC MENTAIT. Au premier essai, le constat capital — « ET LE QUIT AUSSI » — est resté VERT sur un serveur qui supprimait le QUIT : le filtre cherchait \bQUIT\b n'importe où dans la ligne, et la raison du kill que j'avais écrite était « essai de la dependance KILL/QUIT ». La ligne de KILL se comptait donc comme sa propre preuve. Un autre constat a rougi à sa place, ce qui aurait envoyé chercher au mauvais endroit. 📌 Savoir QUEL constat rougit importe autant que de le voir rougir. Le banc lit désormais le verbe en tête de ligne, et porte un plancher qui lui redonne les deux lignes qui l'avaient trompé.

✅ LE PORTAGE (1) EST FINI — 01/09/2026. Tous les verbes dont le travail comptait ont trouvé leur chemin vivant, ou ont reçu un verdict écrit :

⚠ Les raisons de test-verbes-atteignables.tcl ont été mises en accord avec le code le 01/09 : elles décrivaient l'état d'avant les portages, et une raison périmée dans une table d'exceptions est exactement ce qui a fait refaire un portage déjà fait ce jour-là.

✅ L'ÉTAPE (2) EST FAITE — 02/09/2026

Huit procédures et douze verbes sont partis ENSEMBLE — on_KILL, on_SVSKILL, on_SVSNICK, on_CHGHOST, on_CHGIDENT, on_CHGNAME, on_VHOST, on_SQUIT, plus leurs branches du switch de ::soc::raw::dispatch et leurs entrées de _raw_cmds. IriX-sql.tcl perd 133 lignes.

⚠ Aucun compte n'est écrit ici. La première version de ce paragraphe annonçait « 69 mots à 57, et 32 à 20 » — justes à la minute où ils ont été tapés, faux au commit SUIVANT, qui retirait on_WEBIRC. Le banc d'inventaire affiche les deux nombres à chaque passage : tclsh IriX/tests/test-verbes-atteignables.tcl.

⚠ Le préalable a été traité EN PREMIER, et c'était le bon ordre. test-auth.tcl exigeait que on_SVSNICK, on_SVSKILL et on_KILL — mortes — appellent evt_deauth_nick : un constat vert sur du code mort. Il vise désormais on_kill_s2s, et trois constats neufs exigent que les trois noms aient quitté le fichier — la suppression et sa garde posées dans le même geste. ⛔ SVSNICK a quitté cette liste avec sa raison : un renommage ne coupe pas la connexion.

⚠⚠ ET LA MUTATION A TROUVÉ QUE LE CONSTAT REPOINTÉ NE GARDAIT RIEN. Il cherchait la chaîne evt_deauth_nick dans le corps de la procédure — donc il était satisfait par un commentaire qui la nomme, et par la garde if {[llength [info commands ::soc::evt_deauth_nick]]}, qui teste l'existence sans jamais appeler. Retirer la seule ligne d'appel de on_kill_s2s laissait le banc entièrement vert. Le motif exige maintenant le nom suivi d'un argument, commentaires retirés, avec deux planchers qui lui donnent à lire l'appel et la garde. 📌 Chercher un texte prouve qu'on l'a écrit, jamais qu'il AGIT — et ce banc-là gardait la révocation d'identification.

✅ on_WEBIRC est partie elle aussi — même journée, même ordre. Elle était doublement morte, et c'est ce qui la rendait exemplaire :

1. WEBIRC est envoyé par une passerelle AU SERVEUR à l'inscription. La connexion cliente du bot ne le reçoit jamais.
2. ⚠⚠ Et son SQL visait WHERE … socket_id=0. Mesuré : le seul appelant vivant de session_open lui passe $id, l'identifiant du lien — jamais 0. Même exécutée, la requête n'aurait touché aucune ligne.

⚠ test-sessions.tcl l'appelait en trois endroits et constatait « écrit bien dans les sessions » — sur un db_exec doublé. Un banc qui appelle lui-même une procédure que rien n'appelle mesure sa propre main. Les trois appels sont retirés ; un constat exige désormais son absence, avec un plancher qui prouve que le source a bien été lu.

📌 Rien n'est perdu : online::on_uid ouvre déjà la session avec l'adresse, et le filet « aucune écriture de session sans lien » la gardait déjà. On retire une promesse, pas un service.

⚠⚠ CETTE LISTE EN OUBLIAIT TROIS — remesuré le 04/09/2026. Elle annonçait « les douze procédures mortes restantes » ; il y en a quinze. Les trois absentes sont on_OPER, on_AWAY et on_SERVER — et ce sont précisément les seules dont le travail a déjà trouvé une place, donc les seules immédiatement retirables selon la règle du point.

⚠ Deux pièges avant de retirer quoi que ce soit. ::soc::user::set_oper et ::soc::user::set_away n'ont qu'un seul appelant chacune — on_OPER et on_AWAY : les retirer sans elles laisse deux procédures orphelines. Et SAJOIN/SAPART réutilisent on_SVSJOIN/on_SVSPART : retirer une de ces procédures impose de retirer deux verbes.

📌 Le frein n'est pas un banc — aucun n'exécute ni n'exige l'une des quinze. C'est le triplet : la procédure, sa branche du switch, son verbe dans _raw_cmds, et son entrée dans INATTEIGNABLES. En retirer trois sur quatre fait rougir test-verbes-atteignables.tcl, ce qui est exactement ce qu'on lui demande.

✅✅ L'ÉTAPE (2) EST TERMINÉE — les QUINZE sont retirées, 04/09/2026

Les onze dernières ont reçu leur verdict à la lecture, une par une, et c'est le même : leur travail est soit vide, soit une trace, soit déjà fait par une procédure vivante.

📌 Le cas le plus instructif est on_NETINFO : elle posait ::soc::network_name, une variable que trois endroits lisent. Si elle en avait été le seul écrivain, la retirer aurait cassé le nom du réseau. Elle ne l'était pas — on_005 fait le même travail sur un chemin vivant. La question n'est jamais « cette procédure fait-elle quelque chose », c'est « quelqu'un d'autre le fait-il déjà ».

Après retrait : _raw_cmds passe de 52 à 39 verbes liés, et INATTEIGNABLES de 15 à deux — GLOBOPS et LOCOPS, qui partagent on_GLOBOPS, vivante parce que WALLOPS l'atteint.

⚠⚠ Et le geste a failli couper le bot, DEUX FOIS

🔴 Une trace insérée au milieu d'un commentaire. Le script mémorisait l'indice de la première procédure retirée, puis coupait dix autres morceaux avant de s'en servir : l'indice avait bougé, la trace s'est glissée dans un commentaire existant, et la fin de celui-ci s'est retrouvée sans # — donc exécutée. invalid command name "::soc::online::refleter_oper"`.

📌 C'est test-chargement.tcl — le point 73, écrit le matin même — qui l'a attrapé, et lui seul : le défaut du 26/08 reproduit à l'identique, une procédure inexistante appelée au chargement. Les autres bancs extraient des procédures ; aucun n'exécute le corps du script.

⚠ Un nettoyage d'espaces sur tout un fichier. Pour retirer treize mots, la première version a réécrit 152 lignes sur 300 de IriX-binds.tcl — toute l'indentation écrasée, diff ingérable. Un nettoyage se borne à la zone qu'on modifie, sinon il fabrique un dégât plus grand que celui qu'il corrige.

✅ LES QUATRE ÉLIGIBLES SONT RETIRÉES — 04/09/2026

on_SVSMODE, on_OPER, on_SERVER et on_AWAY sont parties avec les quatre côtés de leur triplet chacune. Il reste onze procédures mortes, celles qui n'ont toujours ni portage ni verdict.

Sont parties avec elles :

• ::soc::user::set_oper et ::soc::user::set_away — elles n'avaient qu'un appelant chacune, précisément on_OPER et on_AWAY. Les laisser aurait fait deux procédures orphelines à la place de deux mortes ;
• le réglage track_away, qui n'avait plus aucun lecteur. ⚠ Un réglage proposé à l'exploitant et qui ne commande rien est un mensonge d'interface. track_oper et track_chghost restent : le premier est lu par on_GLOBOPS (vivante par WALLOPS), le second par on_chghost_s2s sur le chemin S2S.

⚠⚠ ET J'AI FAILLI REFAIRE LE PIÈGE DU switch. Le premier jet laissait à la place des quatre branches un commentaire expliquant leur départ. En Tcl, un # dans un switch n'est pas un commentaire : c'est un MOTIF — il devient une paire avec le mot suivant et décale tout le reste. C'est le défaut qui avait coupé le serveur à 89 secondes. Attrapé avant la première mesure, parce que la règle était écrite ; les explications sont donc au-dessus des procédures, jamais dans le switch.

Le garde-fou : test-verbes-atteignables.tcl, 14 constats, 5 blessures de mutation sur 5 vues — et ce qu'elles éprouvent n'est pas « les quatre sont parties », c'est que le banc refuse un triplet incomplet : un verbe relié sans branche, une branche orpheline, un nom fantôme resté dans INATTEIGNABLES, une raison réduite à un mot posé pour le faire taire.

📌 Campagne complète après retrait : 148 bancs, 1 échec, le même qu'avant — celui du binaire du serveur, non construit sur le clone Windows. ⚠ Trois commentaires de bancs décrivaient ces procédures au présent : remis au passé, avec la date du retrait. Un commentaire juste hier est un mensonge aujourd'hui, et rien ne le lit. 📌 Piège relevé au passage : on_GLOBOPS est VIVANTE. Deux de ses trois verbes sont inatteignables, mais le troisième — WALLOPS — est atteignable. Compter les verbes morts d'une procédure ne dit pas qu'elle est morte.

⚠ Contradiction interne corrigée en passant : l'étape 3 ci-dessous réclamait un banc d'inventaire déclaré POSÉ quinze lignes plus haut (test-verbes-atteignables.tcl). C'est l'étape 0 — ce banc-ci — qui manquait, pas la 3.

Les résidus mesurés au passage

• ✅ on_006 retiré le 31/08 — une branche du switch appelant une procédure vide, pour un numérique absent de _raw_cmds donc jamais reçu. Deux mensonges superposés, sans décision à prendre : le corps ne faisait rien.
• ✅ 421 : le doublon est TRANCHÉ le 31/08. raw::on_421 a été retiré. ⚠⚠ La raison qui faisait garder les deux — « retirer l'un OU l'autre perd quelque chose : le nom de la commande d'un côté, l'entrée d'événement de l'autre » — était fausse. Elle avait été raisonnée, jamais mesurée. on_numeric enregistre le texte entier du numérique, « <botnick> <commande> :Unknown command », nom compris. Il suffisait de l'exécuter une fois pour le voir : c'est désormais un constat du banc, gardé pour que la perte se voie si quelqu'un allège on_numeric. 📌 Une exception nommée coûte DEUX vérifications, pas une : qu'elle soit admise, et que sa raison soit encore vraie. Celle-ci a tenu des semaines.
• ✅ track_burst : REBRANCHÉE le 31/08, pas supprimée. Elle était bien inatteignable — son seul appel, dans on_read, exige un état que le fileevent ne connaît jamais. ⚠⚠ Mais la supprimer aurait été une faute : la boucle bloquante refaisait une partie seulement de son travail. Elle posait le pseudo (track_user) et jamais online::on_uid, qui renseigne ident, host, vhost, ip et realname dans <bot>_online. Les personnes déjà connectées au montage du lien arrivaient donc au panel avec cinq colonnes vides — et NICK comme QUIT du burst étaient perdus, si bien qu'un partant restait « en ligne » pour toujours. ⚠⚠ Ce qui rendait ce défaut invisible : online::reconcile les rattrape au scan suivant et les inscrit « avec ce qu'on a ». La ligne existait, elle avait l'air mesurée. Une ligne présente et creuse est pire qu'une ligne absente. Banc : IriX/tests/test-burst-clients.tcl, 22 constats, sept blessures toutes mordantes, dont l'ordre LINKED → fileevent.

• 🟡 extraire est fragile, et la copie est dans TRENTE bancs — pas six. (Chiffre remesuré le 04/09/2026 : trente copies, dont vingt-trois encore en version positionnelle. « Six » datait du jour où la question s'est posée, et n'a jamais été recompté.) Cette procédure — celle qui sort une proc du fichier sans sourcer les 13 000 lignes — cherche les accolades par position : premier {, premier }, puis premier {. Cela ne tient que si la signature n'a qu'un seul argument par défaut. track_burst en a deux ({label ""} {en_burst 0}) et l'extraction part du milieu de la signature. ⚠ Le symptôme est bruyant — « missing close-brace » —, donc ce n'est pas un mensonge silencieux ; mais la version appariée existe désormais dans test-burst-clients.tcl et les autres copies restent à aligner.

⚠⚠ ET CE N'EST PAS UN « ALIGNEMENT » — mesuré le 04/09/2026. Le mot suppose des copies identiques à remplacer d'un geste. Les vingt-quatre versions positionnelles portent en fait quinze empreintes distinctes : chaque banc a adapté la sienne. Aucune ne partage lire_source ni apparier — chacune rouvre le fichier elle-même.

📌 Le remède n'est donc pas de recopier la bonne version vingt-quatre fois — ce serait aggraver ce qu'on corrige. C'est un module auxiliaire (IriX/tests/_extraire.tcl, sur le modèle de _edition-lire.tcl, que le glob test-*.tcl de bancs.sh ne ramasse pas), et chaque banc qui le source.

⚠ Le chantier demande de lancer chaque banc AVANT et APRÈS et de comparer sa ligne de résumé : quinze variantes veut dire quinze comportements possiblement différents, et un banc qui passerait de « 22 constats » à « 21 » sans qu'on le voie serait pire que la fragilité qu'on corrige. Non entrepris pour cette raison — pas par manque de temps, mais parce que le geste est plus gros que ce que ce point annonçait.

📌 Le symptôme, lui, reste bruyant (« missing close-brace ») : ce n'est pas un mensonge silencieux, et rien ne presse.

✅ Le banc d'inventaire est POSÉ — 31/08/2026

IriX/tests/test-verbes-atteignables.tcl, 9 constats, six blessures de mutation toutes mordantes. Il n'exige pas qu'on supprime les trente procédures mortes ; il exige qu'aucun verbe ne soit lié sans avoir été classé — atteignable, ou inatteignable avec sa raison écrite.

⚠ Il n'empêche pas les trente qui existent. Il empêche le trente-et-unième. La question « un client reçoit-il ce verbe ? » est exactement celle que personne ne s'était posée.

📌 Il dérive la liste du fichier au lieu de la recopier, refuse une raison de moins de 25 caractères, refuse qu'un nom survive dans la liste après avoir quitté les binds, et croise les branches du switch avec ce qui est réellement lié — c'est ce dernier constat qui a trouvé on_006.

⛔ Pour fermer — et pourquoi ce n'est PAS « supprimer le code mort »

⚠⚠ Retirer ces procédures AVANT d'avoir porté leur travail transformerait un code mort en fonctionnalité DÉFINITIVEMENT ABSENTE. Le trou existe déjà ; l'effacer le rendrait invisible.

✅ C'est pourquoi le portage a précédé la suppression, et non l'inverse. Le 02/09, huit procédures sont parties AVEC leurs douze verbes — on_KILL, on_SVSKILL, on_SVSNICK, on_CHGHOST, on_CHGIDENT, on_CHGNAME, on_VHOST, on_SQUIT — chacune après que son travail eut trouvé un chemin vivant ou reçu un verdict écrit. ✅ on_WEBIRC a suivi le même jour, une fois test-sessions.tcl repointé — voir plus bas.

L'ordre qui tient :

1. Porter le travail utile vers ::soc::ulines::auto::dispatch, un verbe à la fois, avec son banc — comme cela a été fait pour SERVER puis SID.
2. Puis seulement retirer la procédure morte et son verbe de _raw_cmds — les deux ensemble : laisser la proc sans bind reproduit exactement le mensonge.
3. Un banc d'inventaire qui exige que chaque verbe de _raw_cmds soit soit connu-atteignable, soit nommé avec sa raison — le motif des exclusions nommées déjà employé ailleurs. C'est lui qui empêchera d'en rajouter un trentième sans s'en apercevoir.

⚠ Ne pas commencer par (2). Et ⚠ test-branche-morte.tcl ne peut pas attraper ceci : son en-tête le dit lui-même — « il ne lit pas si la procédure est appelée ».

55. 🔨 Le panneau du salon par GRADE — LE CODE EST ÉCRIT, il reste à le CONSTATER — DEMANDÉ par SerVuS le 28/08/2026

Ce qu'il demande : dans OverScript, que les cases du panneau de gestion se débloquent selon le grade — un IRCop agit sans être @, seuls les @ interviennent, seul l'Owner pose +i, et +O est réservé aux IRCop.

⚠⚠ DEUX DE CES RÈGLES N'EXISTAIENT PAS — mesuré dans src/cmd/m_channel.c, et corrigé le 28/08/2026 :

⚠⚠ « SEUL L'OWNER POSE +i » A ÉTÉ ÉCRIT, ESSAYÉ, ET ANNULÉ LE JOUR MÊME. Le fondateur d'un salon reçoit CHFL_CHANOP et rien de plus — +q est réservé aux services, donc aux seuls salons enregistrés. Exiger l'Owner rendait +i impossible sur tout salon ordinaire : plus personne n'aurait pu fermer sa porte, sauf un IRCop passant outre. C'est la campagne test-commandes qui l'a dit, par cinq constats rouges décrivant un usage parfaitement légitime — ouvrir un salon privé et le fermer. Tranché par SerVuS le jour même : le chanop. 📌 Un mode qu'on ne peut pas poser n'est pas une règle sévère, c'est un mode mort.

🔴 Les deux décisions, prises le 28/08/2026 — et TENUES

1. On a changé le SERVEUR, et le client suit. Un grisage côté client seul se contourne avec n'importe quel autre client IRC : la règle n'existerait que pour qui utilise le nôtre.
2. Le serveur ANNONCE le barème en 005, et le client le lit — jeton CHANMODEREQ, dérivé de la table chanmodes[], jamais écrit à la main.

✅ Ce qui est ÉCRIT, et vert au banc

Le serveur (Servers/overtchat-hybrid/, version 4.29.0) :

• +i → CHFL_CHANOPS. +O → champ neuf oper_only, testé avant have & needs. ⚠ L'ordre porte tout le sens : placé après, un chanop serait passé par la branche du statut. ⚠ needs ne pouvait pas l'encoder — il ne parle que de statuts de salon, et 0 y signifie déjà « serveurs seuls ».
• ⚠ La garde vaut dans les DEUX SENS : le propriétaire du salon ne peut pas davantage retirer +O que le poser. Une garde qui ne tiendrait qu'à la pose laisserait n'importe qui rouvrir un salon réservé, ce qui revient au même.
• chanmode_req_token() dérive le jeton. Forme réelle, lue sur une vraie connexion : q:qa,o:klLjJntispRMCNSTzQVKcDuoh,h:beImv,*:O,!:rPdA. ⚠ 63 octets, et le tampon des jetons de isupport_build() en tenait 64 — un snprintf qui déborde tronque en silence, et le client aurait lu un barème amputé de ses derniers modes. Porté à 96.
• Documenté dans Servers/overtchat-hybrid/PROTOCOL.md, §8.

Le client (dépôt séparé Dev\OverScript) :

• isupport.js lit CHANMODEREQ. ⚠ Absent ⇒ comportement d'avant, sans quoi OverScript cesserait de marcher sur les autres réseaux — aucun ne l'envoie.
• ⚠⚠ session.js sait enfin si l'on est opérateur IRC. Il ne le savait pas : il connaissait tout des grades de salon et rien du grade réseau. Deux sources, le 381 et un MODE sur soi-même — le 381 seul aurait raté quiconque est déjà opérateur en arrivant.
• ⚠ Le barème a dû être nommé dans Session.vue() : regles.brut garde bien les jetons inconnus, mais il ne traverse pas l'IPC.
• modes.js porte la comparaison (autorise), app.js grise — et dit pourquoi, en titre de ligne : un champ éteint sans motif se lit comme une panne du client. ⚠ Aucun barème n'est écrit dans le client.

Les bancs : tests/test-modes-grade.py, 18ᵉ campagne, inscrite au lanceur le jour même — 103 constats. ⚠⚠ Elle ne porte aucune liste de modes : elle lit le jeton, puis éprouve chacune de ses affirmations contre le serveur, au grade du dessous puis au grade annoncé. C'est le seul montage où le jeton ne peut pas mentir. Cinq mutations attrapées, chacune par le constat qui la concerne. Côté client : 498 au npm test, 143 au npm run rendu.

⚠⚠ Ce que ce chantier a appris — quatre fois « un banc ne mesurait pas ce qu'il croyait »

• Une régression introduite en écrivant le grisage : autorise() rendait true dès que le serveur se taisait, si bien qu'un visiteur sans aucun grade voyait tous les champs actifs — l'inverse exact de la veille. C'est un constat de bancs/rendu.js écrit bien avant ce chantier qui l'a dit. La garde de base est désormais explicite, et une blessure la garde.
• Les acteurs muets mouraient en cours de campagne (pingfreq dépassé), et le mode alors examiné paraissait coupable d'un dégât qui ne venait que de la durée de la campagne.
• Le succès était mesuré sur l'ÉCHO, pas sur l'ÉTAT : +O rougissait alors que le serveur l'avait bien posé — l'avis d'outrepassement était arrivé le premier et la fenêtre de lecture s'était refermée dessus. On lit maintenant le 324, et NAMES pour les grades, qui n'y figurent jamais.
• ⚠⚠ Un serveur d'essai d'une mutation précédente avait survécu et tenait le port. Les deux campagnes suivantes ont mesuré son binaire, en annonçant 31 constats rouges qui ne disaient rien de leur propre blessure — et ces chiffres ont failli être écrits ici comme une preuve. La campagne refuse maintenant de démarrer si le port est pris. 📌 Parler au mauvais serveur ne se distingue en rien de marcher.
• ⚠⚠ Et le quatrième a été DIAGNOSTIQUÉ DEUX FOIS À CÔTÉ. La campagne passait lancée seule et rougissait en dix-huitième position, sur les cinq modes de grade. J'ai accusé un délai de lecture, puis un tampon mal vidé ; le vert obtenu entre-temps n'était que de la chance. La cause est le « : » du paramètre final — le 353 s'écrit … #salon :~Chef @Chanop, le premier nom porte le deux-points, et l'extraction le ratait : donc uniquement quand le pseudo cherché était en tête, au hasard de l'ordre des présents. 📌 Une intermittence n'est presque jamais une question de vitesse — c'est un cas particulier qu'on ne rencontre qu'une fois sur deux. Chercher d'abord ce qui VARIE d'une exécution à l'autre.

Trouvés au passage — CORRIGÉS AU DÉPÔT le 30/08/2026, pas encore en service

⚠⚠ Ces correctifs vivent dans le serveur C : ils n'atteindront la production qu'à la recompilation, celle-là même qu'attend le constat du point 55. Ils partiront donc avec lui, dans le même geste — ce qui se décide avant, pas après.

📌 La liste de ce que la recompilation emportera (à relire avant de la lancer) : le barème CHANMODEREQ du point 55 · OPRIV_OVERRIDE désormais lu, avec le resserrage de ClaudeMod · le doublon INVEX retiré · les cinq actes en force désormais annoncés aux opérateurs (4.31.0), et l'annonce qui ne part plus quand +j ou +M refusent l'acte ensuite · OPRIV_SEE_SECRET désormais lu (4.32.0), qui retire au seul grade moderateur la vue des salons cachés et de la clé +k · OPRIV_SEE_REALHOST lu (4.35.0), aux trois sites WHOIS/USERHOST/TRACE — il restreint ircop et moderateur. ⚠ Le if de WHOIS a dû être scindé (il emportait aussi les modes de la cible), et TRACE serait devenu le contournement : son commentaire assumait d'afficher l'hôte réel « puisqu'on l'obtient déjà par WHOIS » — vrai jusqu'au jour où WHOIS se resserre.

⛔ CE QUI N'EST PAS DANS CETTE LISTE, ET NE DOIT PAS Y ENTRER : OPRIV_SVSCMDS. Le brancher serait une panne totale des services — IriX et Anope passent en clients U-linés, sans UMODE_OPER ni bloc oper. Le raisonnement mesuré vit dans Servers/overtchat-hybrid/include/conf.h, à côté du #define. ⚠ chghost et admin sont des bits menteurs (ils gardent une commande qui n'existe pas, ou rien du tout) : leur sort est une décision, pas un correctif. see-realhost se branchera, mais pas d'un seul &&.

• ✅ OPRIV_OVERRIDE n'était lu nulle part. La constante existait (include/conf.h), le mot-clé override était accepté dans les blocs oper (src/conf.c), documenté dans overtchat.conf.example et distribué par grade par Tools/opers-sync.sh — et rien dans le serveur ne le consultait. Tout IRCop passait outre, que le privilège lui ait été accordé ou non ; le retirer d'un bloc oper n'avait aucun effet. Un droit qui paraît réglable et ne l'est pas est pire qu'un droit absent : on croit l'avoir borné. La mesure a montré le trou plus large que le diagnostic initial — il ne s'agissait pas de mode_permitted() seul, mais de huit endroits : oper_passe_outre() de src/channel.c (JOIN et PRIVMSG, donc +b, +i, +k, +l, +m, +J et le mute), plus MODE, KICK ×3, TOPIC et INVITE dans src/cmd/m_channel.c. ⚠⚠ Ce que la correction change pour de vrai, et qu'il faut savoir avant de recompiler : les grades que opers-sync.sh nomme global, ircop et moderateur ne demandent pas override — ils passaient outre quand même, désormais non. C'est exactement ce que ces grades DISENT depuis toujours ; le serveur ne les lisait pas. ClaudeMod est dans ce cas ; ClaudeOps, SerVuS, netadmin (« all ») et admin sont inchangés. 📌 Avant de durcir un droit, mesurer QUI le possède réellement — la même leçon que +i deux jours plus tôt, et cette fois la mesure a montré que le panel voulait déjà ce resserrage. ✅ TRANCHÉ le 30/08/2026 : on GARDE le resserrage, override n'est PAS ajouté au grade moderateur. Les trois raisons, dans l'ordre où elles ont pesé : (a) le coût est asymétrique — opers-sync.sh régénère opers.conf depuis la base et recharge par SIGHUP, donc la décision s'annule à chaud, sans recompiler ni couper le réseau, tandis qu'élargir « en attendant » rendrait le privilège décoratif une seconde fois ; (b) l'intention était déjà écrite dans le grade (« volontairement étroit : de quoi calmer un salon, rien pour couper le réseau ni voir ce qui est caché ») — le serveur ne fait que commencer à lui obéir ; (c) la doctrine tient : un modérateur garde kill et kline, il agit sur les gens dans ce qui est visible, et n'entre pas dans les espaces fermés — cohérent avec le fait qu'il n'a pas see-secret non plus. ⚠ Conséquence assumée : ClaudeMod, le compte de vérification, échouera désormais sur tout contrôle exigeant d'entrer dans un salon fermé. C'est voulu — il faudra passer par ClaudeOps, ce qui rend l'acte visible au lieu de le noyer dans un compte de service. ⚠ Restent hors du correctif, volontairement : OPRIV_SEE_SECRET, lui aussi jamais lu (visibilité des salons +s/+p dans NAMES, LIST et la clé +k) — autre droit, autre décision ; et les gardes badchans et MAXCHANNELSPERUSER, qui ne sont pas des modes de salon. Quatre autres privilèges ne sont lus nulle part non plus : CHGHOST, SEE_REALHOST, ADMIN, SVSCMDS.
• ✅ INVEX était annoncé deux fois dans le 005 (src/ircd.c) : la forme nue en plus d'INVEX=I. La nue est retirée — un client qui range les jetons dans un sac gardait le dernier vu, donc celui sans valeur, et en déduisait la lettre au lieu de la lire. ⚠ Il avait survécu parce qu'aucun banc ne lisait le 005 dans son ENSEMBLE, seulement trois jetons interrogés par leur nom : le constat neuf de harness.py refuse désormais tout doublon.

---

47. ✅ Le chat ouvrait un onglet de plus à chaque sortie, et le suivant redemandait le pseudo — CONSTATÉ FERMÉ le 25/08/2026, au navigateur

Signalé par SerVuS le 23/08/2026, en testant le site :

« quand on va sur une autre page … ça ouvre bien un nouvel onglet mais celui-ci si on va sur la page chat ça demande pseudo etc… (à nouveau malgré 1 onglet actif avec le chat de connecté) et on ouvre X onglets à chaque fois »

Deux symptômes, UNE SEULE racine — Web/inc/site.php, dans site_liens_en_onglet() :

$ajout = ' target="_blank"';
if (!preg_match('/\brel\s*=/i', $attrs)) { $ajout .= ' rel="noopener"'; }

• (A) les onglets s'accumulent : _blank est un nom anonyme. Il ne désigne aucun contexte réutilisable, donc chaque clic crée un onglet neuf. Aucun nom de fenêtre n'est posé sur les sorties — le seul nom du projet, site_chat_onglet(), est réservé à l'onglet du chat.
• (B) le pseudo est redemandé : c'est le même code. Un contexte ouvert avec noopener vit dans un groupe de contextes isolé, et un nom de fenêtre ne se résout que dans son propre groupe. Le script de retour fait window.open('', NOM) pour rebasculer sur le chat, obtient un onglet blanc, le referme, et laisse le lien naviguer — la page chat se recharge à neuf, donc panneau pseudo.

⚠ Rien n'est persisté, et c'est assumé : ni pseudo, ni mot de passe, ni socket. Le seul localStorage est le verrou overtchat:chat-actif, qui ne porte qu'un signe de vie — et il n'est consulté qu'au submit, jamais au chargement. D'où l'ordre absurde vécu par le visiteur : on lui demande son pseudo, puis on lui dit que le chat est déjà ouvert ailleurs.

⚠⚠ CE N'EST PAS UN OUBLI, C'EST UNE RÉGRESSION DE LA 4.19.43 (180412b, « on entre dans le chat sur place, deux onglets au lieu de trois »). Avant, l'onglet du chat était créé par le lien nommé, donc dans le même groupe de contextes : la bascule fonctionnait. Le passage à « le chat s'ouvre sur place » a coupé ce lien de parenté, et personne ne l'a rattrapé.

⚠⚠⚠ ET LE BANC EST RESTÉ VERT, PARCE QU'IL MESURE DU HTML. Web/tests/test-chat-onglet.php exige _blank + noopener (4 constats) et admet lui-même « ce banc ne sait pas exécuter du JavaScript ». Il code donc l'ancienne règle et la protège. C'est le motif « banc dont le monde ne contient pas le défaut » : il faudrait deux onglets et un vrai clic.

✅ CORRIGÉ LE 23/08/2026, en 4.19.50. Les liens internes de la page du chat reçoivent le nom d'un onglet compagnon, site_compagnon_onglet(), dérivé de APP_NAME comme l'est celui du chat. Les liens externes gardent _blank + noopener — leur donner notre nom les mettrait dans notre groupe de contextes.

Le banc a été réécrit en même temps : ses quatre constats codaient l'ancienne règle. Trois constats neufs gardent la moitié qu'il ne fallait pas corriger — un lien externe reste anonyme, un lien en // aussi, et le nom du compagnon doit différer de celui du chat. Trois mutations attrapées : _blank sur les internes (6 échecs), détection d'externalité neutralisée (3 échecs), nom du compagnon rendu égal à _blank (3 échecs). ⚠ Le compte de constats qui figurait ici a été retiré le 25/08/2026 — il annonçait 45 quand le banc en portait déjà 46, et il se périmait à chaque passe. php Web/tests/test-chat-onglet.php le donne.

⚠⚠ ET LE CORRECTIF DE 4.19.50 ÉTAIT INCOMPLET — RATTRAPÉ LE 23/08 EN 4.19.51 (450e4b0). Ce paragraphe s'arrêtait à « corrigé », et c'était sous-dire : deux liens internes de la page du chat portaient _blank ÉCRIT EN DUR — « Charte complète » et « Règlement des salons », dans un <details> de chat.php. La passe de sortie laisse intact tout ce qui porte déjà un target : c'est volontaire, mais cela veut dire qu'un _blank écrit à la main lui échappe entièrement. Le défaut du point 47 leur survivait donc.

⚠⚠⚠ ET LE BANC RÉÉCRIT NE LES VOYAIT PAS NON PLUS. Son constat de rendu ne les atteint pas — ils vivent dans un <details> que le rendu du banc ne produit pas. Ce sont 44 liens sur l'onglet compagnon et 6 en _blank, comptés par un curl sur la production après déploiement, qui les ont trouvés. Un constat de source a été ajouté : aucun gabarit de Web/site/ ne doit écrire target="_blank" sur un href interne. Mutation : remettre _blank en dur sur ?p=charte → 1 échec, et c'est bien le constat de source qui l'attrape, pas celui du rendu. C'est exactement pourquoi il fallait les deux.

⚠⚠ CE QUI MANQUE, ET C'EST PRÉCISÉMENT CE QUI A LAISSÉ PASSER LE DÉFAUT : deux onglets et un vrai clic dans un navigateur. Le banc mesure du HTML rendu — il voit désormais le bon target, mais il ne peut pas voir si la bascule window.open('', NOM) retrouve enfin l'onglet du chat. Ce point reste jaune tant que ce geste n'est pas fait.

⚠ Effet de bord à assumer : l'onglet compagnon sera réutilisé — lire la charte puis le règlement ne laissera plus les deux ouverts.

46. ✅ La touche Tab ne complétait pas les pseudos ni les salons — CONSTATÉ FERMÉ le 25/08/2026, au navigateur

Signalé par SerVuS le 23/08/2026 — « le Tab ne prend plus pour sélectionner Pseudo ou Salon .. ça sélectionne autre chose ». Précisé par lui : dans le champ de message, une fois connecté.

Dans tout client IRC, Tab complète un pseudo ou un #salon en cours de frappe. Dans le webchat, cette complétion n'existe pas : le seul gestionnaire du champ de saisie ne connaît qu'Enter.

el.saisie.addEventListener('keydown', function (ev) {
  if (ev.key === 'Enter' && !ev.shiftKey) { ev.preventDefault(); envoieMessage(); }
});

Tab retombe donc sur le comportement natif du navigateur et le focus saute au bouton Envoyer, adjacent dans le DOM — « ça sélectionne autre chose ».

⚠ C'est un manque, pas une régression : git log -S"'Tab'" sur chat.js ne rend aucun commit. La complétion n'a jamais existé ici ; la comparaison porte sur un client IRC classique.

⚠ Les cinq causes classiques ont toutes été écartées mécaniquement avant d'en arriver là — aucun tabindex positif dans chat.php, aucun gestionnaire qui intercepte Tab, aucun réordonnancement CSS du formulaire, aucun élément focusable invisible, et l'ordre DOM Pseudo → Salon intact aux commits des 22 et 23/08.

✅ ÉCRIT LE 24/08/2026, en 4.19.52. Tab complète le mot sous le curseur : les présents du salon actif, ou les salons quand le mot commence par # ou &. Appuis successifs = cycle. Suffixe : en tête de ligne seulement, ailleurs. Shift+Tab reste le chemin de sortie clavier, et preventDefault() n'est appelé que si une complétion a eu lieu — sinon la touche paraîtrait morte sur un champ vide.

⚠ Deux fonctions PURES, et c'est ce qui rend la chose mesurable : motSousCurseur() et candidatsPour() ne touchent ni au DOM ni à l'état. Le banc neuf Web/tests/test-chat-completion.php les extrait et les fait tourner sous node, comme le font déjà test-chat-mention.php et test-chat-encodage.php.

⚠ Je me trompais en écrivant que « un banc PHP ne verra rien » : les bancs de ce projet savent exécuter du JavaScript. Ce qu'ils ne voient pas, c'est le branchement clavier — que Tab soit intercepté, que le focus ne saute plus au bouton « Envoyer ». La distinction est écrite en tête du banc.

41 constats au vert, trois mutations attrapées : retirer la garde « dièse en tête de mot » (1 échec), rendre la comparaison sensible à la casse (6 échecs), et construire une regex depuis le préfixe — celle-là fait échouer node lui-même, la regex ^[z étant invalide. C'est la démonstration du commentaire que le projet répète depuis toujours : un pseudo contient des caractères qu'une regex interprète.

⚠ Un défaut trouvé dans mon propre code en écrivant les cas du banc : le # était rattaché même précédé d'une lettre, alors que le commentaire affirmait le contraire. « a#b » aurait été pris pour un salon. Corrigé avant que le banc soit écrit, et c'est ce cas que la première mutation garde.

⚠⚠ CE QUI MANQUE : le geste au navigateur. Taper un début de pseudo, presser Tab, voir la complétion se poser et le focus rester dans le champ. Ce point reste jaune tant qu'il n'est pas fait.

⚠ Trouvé au passage, sans rapport avec ce signalement : site.css remonte le bloc « Appeler un opérateur » en tête de colonne par order: -1, alors qu'il est en dernier dans le DOM. La seule commande « dont on a besoin dans l'urgence » est donc atteinte en dernier au clavier — contradiction avec l'intention écrite juste au-dessus. Correctif : déplacer le bloc dans le DOM et retirer le order.

45. ✅ make install d'Eggdrop visait son propre répertoire source, et tcl-tls manquait — CONSTATÉ FERMÉ le 24/08/2026 sur une installation neuve

Trouvé le 23/08/2026 en montant une Ubuntu 24.04 neuve pour les points 26 et 42. Eggdrop compile parfaitement — binaire 1,8 Mo, 18 modules .so — puis l'installation s'arrête net :

You are trying to install into the source directory.
That will not work. Please specify a different install directory with:
    make install DEST="/home/wcc/mybot"
make: *** [Makefile:336: install-start] Error 1
✖ Installation échouée → rollback.

La cause, et elle est structurelle, dans Bootstrap/overtchat-setup.sh :

Eggdrop refuse ce cas par conception, depuis son propre Makefile. Ce n'est donc ni une affaire de distribution, ni de droits, ni d'Ubuntu : cela échouera sur n'importe quelle machine, et le rollback efface les traces derrière lui.

⚠ Conséquence en cascade : sans Eggdrop, l'écran IriX reste verrouillé (« Eggdrop doit être installé d'abord — IriX est un module Tcl qu'Eggdrop héberge »), et avec lui OverOp. L'installateur ne peut donc installer aucun des produits du projet sur une machine neuve.

⚠ Le commentaire juste au-dessus du bloc dit « Constaté sur une installation neuve menée de bout en bout le 29/07/2026 ». Soit le contrôle d'Eggdrop s'est durci depuis — la version retenue est une RC, 1.10.2+RC1, et le script prévient lui-même que c'est « la première chose à remettre en cause » — soit ce chemin n'a plus été repris depuis. À trancher avant de corriger.

Correctif éprouvé le 23/08 (dans une copie d'essai, pas au dépôt) : compiler dans un sous-répertoire et n'installer que dans $dir.

srcdir="${dir}/.src-build"
rm -rf "$srcdir"; mkdir -p "$srcdir" || exit 1
shopt -s dotglob
for f in "$dir"/*; do [[ "$f" == "$srcdir" ]] && continue; mv "$f" "$srcdir"/ || exit 1; done
shopt -u dotglob
cd "$srcdir" || exit 1
./configure && make config && make -j"$(_make_jobs)" && make install DEST="$dir"

Avec lui, l'installation aboutit : eggdrop -> eggdrop-1.10.2 (1 839 648 o), 18 modules, help/, language/, filesys/, et .installed posé. C'est ce qui a permis de fermer le point 26.

⚠⚠ ET IL EN MANQUE UN SECOND, DU MÊME MOTIF : tcl-tls. Mesuré le 23/08 : une fois Eggdrop installé et IriX déployé, le démarrage meurt sur

can't find package tls
    while executing "package require tls"
    (file ".../IriX/cmds/IriX-sql.tcl" line 10)
* FICHIER DE CONFIGURATION NON CHARGÉ

grep -c "tcl-tls" sur overtchat-setup.sh rend 0 : le paquet n'est déclaré nulle part, alors que IriX-sql.tcl l'exige dès sa dixième ligne. La production, elle, porte tcl-tls 1.8.0-2 — posé à la main, ce qui explique que personne ne l'ait vu. Les dépendances déclarées pour IriX sont tcl tcllib mysqltcl default-mysql-client ; il y manque tcl-tls.

✅ LE TROISIÈME ÉCART EST TRANCHÉ ET CORRIGÉ le 24/08/2026, en 4.19.55. default-mysql-client mène à MariaDB sur Debian mais tire MySQL 8 sur Ubuntu, qui entre en conflit avec mariadb-server. Or la famille debian de l'installateur couvre les deux : Ubuntu y est rangé par ID_LIKE. Un exploitant Ubuntu obtenait donc un client MySQL et ne pouvait plus poser le serveur que tout le projet suppose.

SerVuS a tranché : nommer mariadb-client. ⚠ Les quatre autres familles le nommaient déjà explicitement — debian était la seule à passer par un métapaquet ambigu. Mesuré avant de changer : le paquet est déjà installé en production (Debian 13, 1:11.8.6) et disponible sur Ubuntu (1:10.11.14).

⚠ Cinq constats neufs exigent que chaque famille nomme un paquet MariaDB — sans quoi le défaut se reformerait sur une autre distribution. Mutation : remettre le métapaquet → 2 échecs.

✅ CONSTATÉ sur l'Ubuntu le 24/08/2026, en repartant du point de départ fautif — MySQL 8 installé, mariadb-client absent :

IriX  ◐ incomplet
   ↳ mariadb-client                    ← l'écran réclame le bon paquet

Removing default-mysql-client …        ← l'installation retire MySQL 8
Removing mysql-client-8.0 …
Setting up mariadb-client (1:10.11.14-0ubuntu0.24.04.1) …

État final : mysql pointe vers /usr/bin/mariadb, MariaDB 10.11.14, et mysql-client-8.0 n'est plus installé. Le défaut est éteint là où il vivait.

Le point de départ a été rendu mordant : tcl-tls a d'abord été retiré de la machine, et tclsh vérifié incapable de charger tls. Sans cela l'épreuve aurait été creuse — le paquet y avait été posé à la main la veille.

L'installateur téléchargé est bien celui du dépôt : même empreinte fa9bc835…, .src-build présent, tcl-tls cité 9 fois.

⚠ Ce que ce constat n'englobe pas : le troisième écart, default-mysql-client qui tire MySQL 8 sur Ubuntu au lieu de MariaDB. Il est réapparu pendant cette même passe — « Paquets manquants : … mysql-client-8.0 » — et il reste à trancher, pas à corriger.

✅ LES DEUX CORRECTIFS SONT PORTÉS AU DÉPÔT LE 24/08/2026, en 4.19.53. Jusque-là ils n'existaient que dans une copie d'essai — et le commit du 23/08 qui porte le nom de ce point n'avait touché que ce registre. C'est un écart que la mesure a rattrapé : grep -c "tcl-tls" sur l'installateur rendait encore 0.

⚠ Seul le nom Debian/Ubuntu est MESURÉ (tcl-tls). Les quatre autres sont probables ; c'est le repli par capacité qui rattrape une erreur de nom, exactement comme la leçon déjà écrite pour mysqltcl juste au-dessus dans _pkg_present : répondre « présent » sans savoir est le pire des choix.

Le banc Bootstrap/tests/test-deps-eggdrop.sh garde les deux causes — 14 vérifications, trois mutations attrapées : retirer tcl-tls (2 échecs), recompiler dans le répertoire des sources (2 échecs, dont le constat central), retirer le repli par capacité (1 échec).

⚠⚠ ET CE BANC S'EST FAIT PRENDRE EN S'ÉCRIVANT. Son constat sur make install comptait 2 au lieu de 1 : le vrai appel, et l'exemple cité dans le commentaire que le correctif venait de poser juste au-dessus. Un banc qui lit un commentaire au lieu du code croit mesurer ce qu'il ne mesure pas. Un grep -v '^\s*#' suffit, et il est commenté sur place pour que personne ne le retire.

⏪ CE QUI SUIT EST L'ÉTAT D'AVANT LA FERMETURE — PÉRIMÉ, gardé pour la trace. Le critère décrit ci-dessous a été constaté le 24/08/2026 — voir l'encadré ✅ en tête de point. L'installation neuve a bien eu lieu sur l'Ubuntu 24.04, avec l'installateur retéléchargé depuis le site, donc sans le moindre correctif local. ⚠ Ne pas le relire comme du travail à faire. Un encadré « Pour fermer » périmé sous un titre ✅ est exactement ce qui fait rouvrir un point déjà clos, ou croire ouvert ce qui ne l'est plus.

⚠ CE QUI MANQUE : l'installation neuve de bout en bout, sans correctif local — l'installateur retéléchargé depuis le site, Eggdrop qui passe à « installé », IriX qui se déverrouille et démarre. L'Ubuntu-24.04 est en place pour ça. Le troisième écart — default-mysql-client qui tire MySQL 8 sur Ubuntu au lieu de MariaDB — reste à trancher, pas à corriger.

44. ✅ La table d'audit du site gardait des adresses IP sans aucune purge — CONSTATÉ FERMÉ le 23/08/2026

✅✅ CONSTATÉ FERMÉ LE 23/08/2026 À 14:00, de bout en bout, sur la production.

La table ne portait rien de plus de seize jours : la purge aurait été inerte jusqu'en novembre, et l'on n'aurait pas su distinguer « rien à purger » de « refusé en silence ». Une ligne volontairement vieillie de 100 jours a donc été posée, puis le scan attendu. Le journal du robot :

2026-08-23T14:00:00 [INFO] audit: purge — 1 ligne(s) retirée(s), 22 gardée(s)

23 lignes avant, 22 après, la témoin partie et elle seule. Les deux comptages copiés sur ::soc::hist::purger sont ce qui rend ce constat lisible.

⚠⚠ DEUX ERREURS DE MÉTHODE, RATTRAPÉES PAR LE CONSTAT ET PAR RIEN D'AUTRE :

1. L'appel avait atterri dans ::soc::scan::hourly, pas dans le scan quotidien. Le bloc pris pour la fin de l'un était la fin de l'autre — ancrer sur du code sans vérifier dans quelle procédure il vit. Le hasard fait bien les choses : c'est le bon endroit, les purges par ancienneté y sont déjà. Mais je l'ai su en essayant de constater, pas en écrivant.
2. « scan quotidien » rend ZÉRO dans IriX.log et QUATRE dans IriX-sql.log. J'ai failli conclure que le scan ne tournait jamais. La règle des trois journaux a payé, et c'est la première fois qu'elle sert à éviter une conclusion fausse plutôt qu'à trouver une trace.

⚠ Et un piège d'outillage : sudo systemctl restart irix bloque cinq minutes sur une invite de mot de passe, quand la règle NOPASSWD du sudoers exige irix.service, au caractère près. Le nom d'unité doit être écrit exactement comme dans la règle.

⚠ La charte annonce désormais 90 jours, là où elle avouait le manque. Changer la durée dans le code sans la porter à la charte fait rougir test-charte-retention.php, et c'est voulu.

Trouvé en corrigeant la charte, et c'est la charte elle-même qui l'annonce désormais au visiteur : « les traces d'administration du site ne sont pas encore purgées automatiquement ». L'écrire oblige à la poser — c'est pourquoi ce point existe.

IriX_web_audit porte une colonne ip en VARCHAR(45), remplie par audit_log() avec l'adresse entière du visiteur, jamais tronquée. La migration Web/sql/019-web-audit.sql le dit en toutes lettres : « Aucune purge automatique dans cette migration… Si elle grossit, la purge sera une décision d'exploitation. » Cette décision n'a jamais été prise.

⚠ Ce n'est pas une table technique : c'est un journal d'actions d'administration indexé par adresse IP. Toutes les autres données personnelles du projet ont une échéance — sessions 30 jours, événements 90 jours, messages publics 30 jours. Celle-ci est la seule sans fin.

⚠ Le plafond de l'ASV en dépend, et il faut y penser en posant la purge. asv_rate_block() compte les refus par un COUNT(*) sur cette même table, fenêtre d'une heure. Une purge qui effacerait trop court viderait le compteur et libérerait les blocages ; toute échéance largement supérieure à l'heure est sans effet sur lui.

⚠ Deux questions à trancher avant d'écrire :

1. Quelle durée ? 90 jours alignerait sur les événements et les décisions de modération, qui sont la même nature de trace. ⚠ Toute valeur choisie devra être portée à la charte — test-charte-retention.php rougira sinon, et c'est voulu.
2. Qui la lance ? Les autres purges vivent dans le scan quotidien du bot (IriX-sql.tcl), qui ne connaît pas les tables du site. Soit on l'y ajoute, soit le site se purge lui-même — mais il n'a aucun mécanisme périodique aujourd'hui, ce qui ferait de ce point un chantier plus large qu'il n'en a l'air.

43. ✅ Quatre familles de fichiers système n'atteignaient AUCUNE installation tierce — CONSTATÉ FERMÉ le 24/08/2026

✅ LA QUATRIÈME FAMILLE — APACHE — EST ÉCRITE le 21/08/2026, écran « Services système », action 4. Elle pose et n'active RIEN, et c'est la décision qui commande tout le reste : a2ensite sur irix-ssl.conf sans certificat empêche Apache de démarrer, et c'est tout le site qui tombe, pas seulement ce vhost. L'activation reste un geste de l'exploitant, et l'installateur l'écrit à l'écran plutôt que de le faire.

⚠⚠ Et il faut savoir ce que le contrôle NE VOIT PAS. Un vhost posé dans sites-available/ sans a2ensite n'est lu par personne — pas même par apache2ctl configtest, qui n'inclut que sites-enabled/. Le seul fichier de cette famille que le contrôle voie réellement est ports.conf. Croire que le configtest garde les vhosts serait se croire gardé sans l'être.

⚠⚠ ports.conf N'EST PAS À NOUS, et c'est le seul de tout ce chantier dans ce cas : il appartient au paquet Debian, et le poser l'écrase. L'installateur en garde donc l'original — et deux gardes le protègent, parce qu'une seule ne suffisait pas :

1. une seule fois : la pose est ré-exécutable, et une sauvegarde reprise au second passage ne sauvegarderait plus que notre propre fichier ;
2. ⚠ « déjà le nôtre », par comparaison de contenu — trouvé le 21/08 en mesurant la production, où ports.conf avait été posé à la main en juillet. La garde 1 ne couvrait pas ce cas : le premier passage aurait écrit un fichier nommé « avant-overtchat » contenant l'après, et la désinstallation aurait rendu à Apache une configuration qui n'est pas la sienne, en croyant bien faire.

⚠ L'état de départ est mesuré AVANT de toucher à quoi que ce soit. Un configtest déjà rouge avant la pose ne lui est pas imputé : on ne replie que ce qu'on a fait passer du vert au rouge. Sans cela, une configuration cassée par ailleurs enverrait chercher un défaut dans du code juste.

⚠ La table porte des MOTIFS, pas un dossier — les trois destinations l'imposent. Ce qui remplace la dérivation : un fichier de Config/apache/ qu'aucune règle ne réclame est refusé et dit, jamais posé au hasard. Ajouter un vhost irix-*.conf reste couvert tout seul.

Le désinstalleur a été mis en accord : il ne supprime jamais ports.conf — il le restaure, ou dit qu'il ne le peut pas ; il retire maintenance.html et son dossier ; et son rechargement d'Apache, jusque-là inconditionnel, passe désormais par un configtest.

Banc : Bootstrap/tests/test-systeme.sh — 64 constats, il exécute les deux poses sur un faux /etc (élargi à une racine entière, /var/www n'étant pas sous /etc), et sept mutations rougissent, dont les quatre qui comptent : retirer la sauvegarde, retirer l'une ou l'autre de ses deux gardes, activer un vhost, et ignorer l'état de départ.

⚠⚠ Deux constats ont d'abord été écrits FAUX, et la passe de mutation les a trouvés : l'un ne rougissait pour aucune mutation (la clause de contenu masquait la garde « une seule fois », qui n'était plus interrogée du tout), l'autre jouait un scénario qui ne pouvait pas mordre. Un banc neuf sans passe de mutation n'aurait rien gardé, en affichant tout vert.

🟡 Ce qui reste, et c'est un geste de l'exploitant : LE CONSTAT. Aucune des deux poses n'a été lancée sur un /etc écrivable — écrire là exige un mot de passe, sudo -n ne couvrant que systemctl. ⚠ En production, tout est déjà en place et activé (posé à la main en juillet et en août) : la pose y sera donc une re-pose, sans rien à activer. Deux écarts s'y corrigeront au passage — irix-admin.conf et irix-ssl.conf y sont en 755.

⚠⚠ « TOUT EST DÉJÀ EN PLACE » EST FAUX, ET L'INSTALLATEUR LE SAVAIT AVANT CE REGISTRE. Remesuré le 23/08/2026 à 18:15 : trois des quatre familles seulement sont posées, et polkit ne l'est pas du tout — /etc/polkit-1 n'existe pas sur cette machine, ni son rules.d. Config/polkit/10-overtchat-irix.rules vit au dépôt et n'a jamais atteint /etc. Le commentaire de _sys_dest_prete, dans Bootstrap/overtchat-setup.sh, le porte noir sur blanc depuis le 20/08 : « /etc/polkit-1 n'existe pas sur la machine de production — polkit n'y est simplement pas installé ». Le code avait donc raison pendant que ce point disait le contraire.

⚠ Conséquence pour le constat, et elle change le geste : _sys_dest_prete teste la racine du logiciel et saute proprement une famille dont le logiciel est absent. Sur CETTE machine, l'action 3 posera donc sudoers et logrotate, et ne touchera jamais polkit. La pose polkit ne peut pas être constatée ici : il faut une machine où polkit existe.

Marqueur	Mesuré le 23/08
/etc/polkit-1/rules.d/10-overtchat-irix.rules	le répertoire lui-même n'existe pas
/etc/apache2/ports.conf.avant-overtchat	absent — seul ports.conf (22/07 13:10)
/etc/apache2/sites-available/irix-admin.conf	-rwxr-xr-x — 755, 21/07 21:10
/etc/apache2/sites-available/irix-ssl.conf	-rwxr-xr-x — 755, 13/08 20:54
/etc/sudoers.d/overtchat-services	présent, 440, 31/07 13:13 — pose manuelle
/etc/logrotate.d/overtchat	présent, 28/07 21:20 — pose manuelle

⚠ Aucun horodatage sous /etc n'est postérieur au 13/08 pour ces familles : l'installateur n'a jamais tourné contre le vrai /etc. Et le désinstalleur sait retirer un fichier polkit qui n'a jamais existé ici — ce chemin-là non plus n'a jamais été parcouru en vrai.

✅ CONSTATÉ FERMÉ	Le 24/08/2026, sur l'installation neuve de l'Ubuntu 24.04, avec l'archive et l'installateur retéléchargés du site. Les fichiers arrivent, ils sont adaptés, et Apache reste sain.

L'écran compte enfin, là où il affichait 0/0 depuis toujours :

Unités livrées            14
Fichiers système          0 / 3    sudoers · polkit · logrotate
Fichiers Apache           1 / 5    posés inactifs

Et les fichiers posés sont ADAPTÉS — le compte de service visé était root, propriétaire de la racine d'installation :

⚠⚠ Le commentaire est épargné : grep -c servus sur le sudoers posé rend 2 — les deux occurrences qui restent sont dans des commentaires. C'est la preuve que les motifs sont nommés et qu'aucun remplacement global n'est passé.

La garde Apache mord, et elle mord juste : irix-default.conf, irix-ssl.conf et maintenance.html sont IGNORÉS (« modèle NON adapté à cette installation »), tandis qu'irix-admin.conf et ports.conf, qui ne portent aucun marqueur de machine, sont posés. Résultat annoncé par l'installateur : « 2 posé(s), 3 refusé(s) — AUCUN n'est activé », et apache2ctl configtest : toujours vert. L'original du paquet est conservé en ports.conf.avant-overtchat.

⚠ Un faux départ, et il vaut d'être noté : le premier essai a montré le sudoers posé sans substitution. Ce n'était pas le code — l'installateur de l'essai avait été téléchargé avant le push de 4.19.54. Un constat pris sur une copie périmée dit le contraire de la vérité, et rien ne le signale : il faut vérifier la version de ce qu'on éprouve, pas seulement ce qu'on éprouve.

✅ TRANCHÉ ET FAIT LE 24/08/2026, en 4.19.54 — SerVuS a choisi de DISTRIBUER. Ce qui suit reste écrit parce qu'il explique pourquoi le geste a la forme qu'il a.

La livraison passe par l'ARCHIVE, pas par une liste. Les cinq dossiers sont ajoutés au tar de l'archive site, qui s'extrait déjà dans $BASE_DIR — c'est-à-dire là même où _sysd_dir() et le find Config/apache vont chercher.

⚠⚠ POURQUOI PAS UNE LISTE, QUI ÉTAIT LA VOIE ÉVIDENTE : le code qui POSE ces fichiers dérive sa liste du disque, et trois commentaires l'imposent — « LA LISTE EST DÉRIVÉE de Config/systemd/, jamais énumérée ». Énumérer les trente fichiers aurait réintroduit exactement la liste centrale qu'ils interdisent, et un fichier ajouté demain aurait été posé ici et absent chez un tiers, en silence.

⚠ La surveillance de fraîcheur suit, par une seconde constante employée aux deux endroits — le tar et le calcul qui décide de régénérer. Un dossier ajouté au seul tar serait emporté sans jamais être surveillé : c'est le défaut corrigé le 10/08 pour les fichiers de la racine, que le docbloc interdit de recréer.

LA LIVRAISON NE SUFFISAIT PAS, ET C'EST LE POINT LE MOINS ÉVIDENT. _sys_poser faisait un install brut. Posés tels quels, le sudoers et le polkit auraient accordé des droits à « servus », qui n'existe pas chez un tiers. L'installation aurait eu l'air configurée sans l'être — pire que l'état d'avant, où elle annonçait honnêtement 0/0. _sys_substituer() adapte donc les trois familles mécaniques, avec la règle de _sysd_substituer() : des motifs nommés, jamais un remplacement global qui réécrirait les commentaires.

⚠⚠ APACHE EST LIVRÉ MAIS NON ADAPTÉ, et une garde neuve REFUSE de le poser sur une machine dont le compte diffère. irix-ssl.conf porte un ServerName et des chemins de certificats en dur : posé tel quel, il en désigne des absents et Apache refuse de démarrer. Mieux vaut ne rien poser que casser le serveur web de quelqu'un. La garde ne mord que si le compte diffère — ici, la re-pose reste possible.

Éprouvé : test-systeme.sh passe de 62 à 73 vérifications, test-distrib.php reste à 25. Deux mutations, deux attrapées : un remplacement global (pris par le constat qui vérifie qu'un commentaire n'est pas réécrit), et la pose du modèle brut.

⏪ CE QUI SUIT EST L'ÉTAT D'AVANT LA FERMETURE — PÉRIMÉ, gardé pour la trace. Le critère décrit ci-dessous a été constaté le 24/08/2026 — voir l'encadré ✅ en tête de point. Les fichiers arrivent, ils sont adaptés, et Apache reste sain — mesuré sur l'installation neuve avec l'archive et l'installateur retéléchargés du site. ⚠ Le « CE POINT NE PEUT PAS SE FERMER DU TOUT » qui suit date du 23/08 : il a été levé le lendemain, et c'est justement ce qu'il annonçait impossible qui a été constaté. ⚠ Ne pas le relire comme du travail à faire. Un encadré « Pour fermer » périmé sous un titre ✅ est exactement ce qui fait rouvrir un point déjà clos, ou croire ouvert ce qui ne l'est plus.

⚠ CE QUI MANQUE : le constat sur une installation tierce — les fichiers qui arrivent vraiment, et le sudoers posé au nom du bon compte.

⚠ Ces familles restent exclues de la mise à jour. Distribuer permet la première pose ; la re-pose demeure un geste manuel — le code le disait déjà pour systemd.

⚠⚠⚠ ET CE POINT NE PEUT PAS SE FERMER DU TOUT — MESURÉ LE 23/08/2026 SUR UNE UBUNTU 24.04 NEUVE. L'écran « Services système » d'une installation tierce affiche 0/0 sur les quatre familles, et il l'affichera toujours : les fichiers à poser n'arrivent jamais. Quatre voies, quatre fermées.

Voie	Mesuré
l'installateur écrit-il dans Config/{systemd,polkit,sudoers.d,logrotate.d,apache} ?	aucune écriture — que des lectures
le site les distribue-t-il ?	404 sur les cinq essayés, quand overtchat-setup.sh et irix-mandat.tcl rendent 200
l'archive /dl/site les contient-elle ?	non — son Config/ ne porte que identity.json.example et villes.txt
un tiers peut-il cloner le dépôt ?	non — Repository not found : le dépôt est privé

⚠ Le critère « lancer les poses sur un /etc écrivable » n'est donc réalisable que sur une machine qui possède déjà le dépôt — la production. Et là, polkit est absent, donc cette famille-là est sautée. Ni ici, ni ailleurs.

Deux issues, et elles ne se valent pas : distribuer ces fichiers, en les mettant au manifeste comme le reste — et le point redevient réalisable ; ou écrire noir sur blanc que l'installateur suppose un dépôt local, prérequis qui n'est aujourd'hui énoncé nulle part — et alors ce point doit être reformulé, pas fermé.

---

✅ sudoers, polkit et logrotate sont posés par l'installateur (4.19.32), écran « Services système », action 3. Liste dérivée, pose ré-exécutable, et l'ancien /etc/sudoers.d/overtchat-irix retiré — son remplaçant le demandait dans son propre en-tête.

⚠⚠ Le sudoers est CONTRÔLÉ avant d'être posé, jamais après. visudo -c -f sur le fichier source ; s'il ne passe pas, il n'est pas posé — et les deux autres familles le sont quand même, car un refus ne doit pas tout arrêter. C'est la seule pose de ce chantier qui puisse casser autre chose que le projet.

⚠ La table porte des DOSSIERS, pas des fichiers. Ajouter un fichier dans Config/sudoers.d/ est couvert automatiquement ; seul l'ajout d'un dossier destiné à /etc demande d'y toucher, et le banc le dit alors.

Banc : Bootstrap/tests/test-systeme.sh — il exécute la pose sur un faux /etc, et les mutations rougissent : ne rien poser, poser le sudoers en 644 (sudo l'ignorerait en silence), le poser sans le contrôler, perdre une famille, et ignorer le verdict de visudo.

---

L'état d'origine, gardé parce qu'il explique la décision

Sorti du point 41 le 20/08/2026, une fois les unités systemd posées. Le trou était plus large que les unités, et c'est la même forme : Tools/desinstaller.sh:175-181 sait retirer quatre familles de fichiers système que l'installateur ne pose jamais.

⚠ Le plus grave est le premier, et il se lit dans l'unité elle-même (Config/systemd/overtchat-veille.service) : « Sans ce droit, la veille alerte quand même : elle constate et écrit, elle ne peut simplement pas guérir. » Sur une installation neuve, la surveillance qu'on vient de livrer serait donc à moitié infirme, sans que rien ne le dise.

Pour fermer : reprendre le motif déjà éprouvé au point 41 — liste dérivée de Config/, substitution des chemins, pose ré-exécutable, et le banc qui compare les deux sens. ⚠ Trois différences avec les unités, qui ne sont pas des détails :

1. sudoers.d exige visudo -c avant la pose, et un mode 440. Un fichier sudoers invalide peut rendre sudo inutilisable sur toute la machine — c'est la seule pose de ce chantier qui puisse casser autre chose que le projet.
2. Les vhosts Apache demandent un a2ensite et un rechargement, pas une simple copie.
3. polkit ne demande aucun rechargement — son en-tête le dit déjà.

⚠ Et comme pour les unités : la mise à jour n'atteint pas /etc, donc la pose doit être ré-exécutable ou la première sera la dernière.

---

42. ✅ Le compte owner du bot naissait avec un masque sans ident — CONSTATÉ FERMÉ le 23/08/2026, après avoir trouvé que l'enrôlement était cassé

Le userfile, écrit par le premier enrôlement :

SerVuS     - jlmnoptx
--HOSTS ~servus@127.0.0.1
--HOSTS *!*servus@127.0.0.1
--PASS2 $pbkdf2-SHA256$rounds=16000$…

*!*servus@127.0.0.1 — exactement *!*<ident>@<domaine>, la forme que le correctif du 21/08 devait produire. Le ~ du masque brut est bien retiré.

⚠⚠ LES DEUX LIGNES DU CRITÈRE N'ÉTAIENT PAS DANS IriX.log — elles sont dans IriX/cmds/IriX-sql.log, le second journal :

2026-08-23T20:58:20 [INFO] SerVuS promu owner (premier enrôlement)
2026-08-23T20:58:20 [INFO] SerVuS Active HOSTS DCC (*!*servus@127.0.0.1)
2026-08-23T20:58:20 [INFO] reg: enregistrement SQL owner SerVuS!~servus@127.0.0.1 déclenché
2026-08-23T20:58:20 [INFO] reg: owner 'SerVuS' inséré (INSERT)

Un grep sur le seul IriX.log aurait conclu que le constat avait échoué. Le quatrième endroit confirme : IriX_users porte id 1, admin SerVuS, csowner oui, created 2026-08-23 20:58:20, mot de passe haché.

✅ LE DÉFAUT TROUVÉ EN PRENANT CE CONSTAT — CORRIGÉ ET ÉPROUVÉ LE MÊME JOUR. Ce qui suit est le récit de ce qui bloquait, gardé parce qu'il explique pourquoi un point « corrigé » a pu rester faux pendant deux jours.

🔴 LE PREMIER CONSTAT, LE 23/08/2026 À 20:46, NE FERMAIT PAS CE POINT — IL TROUVAIT PIRE. Sur une Ubuntu 24.04 neuve, base vide, userfile absent, le premier /msg IriX pass … rend :

Tcl error [::soc::reg::on_pass]: invalid command name "users"

Aucun masque n'est écrit. Aucun userfile n'est créé. Le compte owner ne naît pas. Le correctif du 21/08 porte donc sur du code qui n'a jamais pu s'exécuter : on_pass meurt à sa première ligne utile, bien avant d'arriver au calcul du masque.

La cause, une ligne, dans IriX/cmds/irix-register.tcl :

proc ::soc::reg::find_owner_on_irc {} {
    set owner "*"
    set users [users]        ;# « users » n'est pas une commande Eggdrop

⚠ Le projet connaît le bon nom et l'écrit partout ailleurs : userlist. IriX-sql.tcl fait même foreach u [userlist n] — exactement ce que cette procédure veut faire. [users] n'apparaît qu'une fois dans tout le dépôt : ici.

⚠⚠⚠ ET LE BANC EST VERT PARCE QU'IL FABRIQUE LA COMMANDE MANQUANTE. IriX/tests/test-register.tcl charge le vrai find_owner_on_irc et le vrai on_pass par extraire — puis, quelques lignes plus haut, définit :

proc users     {}            { return $::userlist }

Le banc a donc créé le monde dans lequel le code est juste. C'est le motif « banc dont le MONDE ne contient pas le défaut », dans sa forme la plus pure : tout le reste du banc est excellent — il éprouve l'ident, le ~, le masque sans domaine, l'intrus, le mot de passe faux — mais rien de tout cela n'est jamais atteint en vrai.

⚠ Pourquoi la production ne l'a jamais vu : son owner existe depuis le début, donc on_pass n'y est jamais appelé. Ce point le disait déjà — « la production ne repassera jamais par ce chemin ». Il fallait une installation neuve pour le voir, et c'est précisément ce qui vient d'être fait.

Correctif appliqué le 23/08/2026 : set users [userlist] dans find_owner_on_irc, et le bouchon du banc renommé users → userlist, sinon il aurait continué de protéger le défaut suivant du même genre.

⚠ Passe de mutation, deux mutations, deux attrapées — sans quoi le vert ne prouvait rien :

Restauré, le banc revient à 24 vérifications au vert.

⚠⚠ LA MESURE A RETOURNÉ CE POINT, et dans les deux sens à la fois. Il sur-disait sur la gravité et sous-disait sur la portée. Ce qui suit est mesuré, pas déduit.

1. Les flags n/o ne gardent AUCUNE commande d'IriX. Recensement fait sur tout IriX/ : matchattr n'apparaît que dans irix-register.tcl, quatre fois, toutes sur l'enrôlement ; aucun bind ne porte de masque de flags — les bind dcc d'IriX-binds.tcl sont tous en -|-, et le fichier dit pourquoi : « la garde reste celle de la commande elle-même ». Les ~60 commandes passent par ::soc::require_grade, qui lit la base et exige auth='oui'. matchban : zéro occurrence.

2. Ce que les flags gardent réellement, c'est la partyline Eggdrop — donc .tcl, .die, .rehash. Le risque n'est pas moindre, il est déplacé : qui l'atteint a l'interpréteur du bot. ⚠ Mais elle n'écoute qu'en 127.0.0.1:3333 (mesuré au socket), et require-p 1 plus un PASS2 en place exigent le mot de passe. Le hostmask est donc un facteur, pas le seul — « les pleins pouvoirs avec un ident deviné » allait trop loin.

3. ⚠⚠ EN REVANCHE, C'EST LE CODE QUI FABRIQUAIT LE MASQUE OUVERT, et il le refera chez chaque tiers. ::soc::reg::on_pass construisait *!*@<domaine> à partir de l'hôte de l'enrôleur. Ici le domaine était celui du réseau local de Windows ; chez un installateur quelconque, ce sera celui de son fournisseur d'accès — des milliers d'abonnés reconnus comme owner du bot.

⚠ Et le chemin est INVISIBLE sur une installation en service : il ne s'exécute qu'au premier enrôlement, tant qu'aucun owner n'existe. Une mesure faite ici aurait conclu « ce code ne tourne plus » — c'est le point 5 des règles, encore : où vit la chose que je viens de corriger ?

✅ CORRIGÉ (4.19.38). Le masque exige désormais l'ident : *!*<ident>@<domaine>, le * de tête absorbant le tilde qu'ajoute un serveur sans identd. ⚠ Un hôte inexploitable ne donne aucun masque et le dit — mieux vaut un owner qu'Eggdrop ne reconnaît pas, il lui reste son mot de passe, qu'un masque ouvert posé « pour que ça marche ».

Banc neuf : IriX/tests/test-register.tcl — 24 constats, il exécute on_pass sur un faux Eggdrop, et quatre mutations rougissent. ⚠ irix-register.tcl n'avait aucun banc, alors qu'il est le seul écrivain du userfile : c'est lui qui crée le handle, pose +nmp et écrit le masque.

⚠⚠ Un constat de ce banc a d'abord été écrit FAUX : string match "*!*@*" pour dire « ce masque est ouvert » — or ce motif absorbe aussi *!*servus@…. Rouge sur du code juste ; écrit dans l'autre sens, il aurait laissé passer le défaut. Le constat lit maintenant la part ident.

✅ ET LE MASQUE DE PRODUCTION EST RETIRÉ — constaté le 21/08/2026 à 17:38. Fait à froid, parce qu'Eggdrop garde son userfile en mémoire et le réécrit à l'arrêt : une édition à chaud aurait été écrasée au premier save. Arrêt, retrait de la ligne, relance — le compte SerVuS ne porte plus que son masque à ident et ses deux -telnet! ; le fichier est resté en 600.

⚠ La restauration était posée dans un trap EXIT AVANT le geste, et le userfile copié de côté. Une coupure oubliée coûte plus cher que le défaut qu'on venait corriger.

Le lien de services est remonté seul, et c'est croisé sur deux sources : ACTIF — présence confirmée côté serveur (WHOIS sourcé, 318) à 17:38:50, SID 003 — celui qu'exige le bloc link, donc le chemin du point 37 a bien été repris —, 5 services en ligne, et l'op obtenu sur #!Bots! et #!Services!. ⚠ Le NEEDOP … tentative 1/3 de 17:38:33 n'est pas une panne : c'est la montée normale, 17 s avant que le lien soit en état d'émettre.

⏪ CE QUI SUIT EST L'ÉTAT D'AVANT LA FERMETURE — PÉRIMÉ, gardé pour la trace. Le critère décrit ci-dessous a été constaté le 23/08/2026 à 20:58:20 — voir l'encadré ✅ en tête de point. Le premier enrôlement a eu lieu sur l'installation neuve : le masque *!*servus@127.0.0.1 est écrit, avec les deux lignes de journal qu'exigeait le critère. ⚠ Ne pas le relire comme du travail à faire. Un encadré « Pour fermer » périmé sous un titre ✅ est exactement ce qui fait rouvrir un point déjà clos, ou croire ouvert ce qui ne l'est plus.

🟡 CE QUI RESTE — un seul constat, et il ne peut pas se prendre ici : voir le masque à ident réellement posé demande un premier enrôlement, donc une installation neuve. C'est le même trou que le point 26. Le banc l'exécute ; la production, elle, ne repassera jamais par ce chemin.

⚠ Ce point est affiché sur le site public. Le masque de production y était écrit en toutes lettres du 20 au 21/08 ; il ne l'est plus ici, mais l'historique du dépôt le porte — et il ne vaut plus rien depuis 17:38.

⚠⚠ ET UNE PISTE À NE PAS ROUVRIR : « adosser les grades à OverNick » ne s'applique pas ici. Les grades applicatifs le sont déjà — c'est le sens du point 1 ci-dessus. Ce qui reste sur hostmask est la partyline, gardée par Eggdrop lui-même, dans son binaire : aucun service d'identification ne peut s'y substituer sans réécrire Eggdrop. Le durcissement possible est celui qui a été fait — exiger l'ident — plus l'écoute locale déjà en place et le mot de passe.

---

Ce qui avait été constaté le 20/08, et qui reste juste

Trouvé le 20/08/2026 en instruisant un kick, et le kick n'était que le symptôme.

Le symptôme. SerVuS, connecté par OverScript et bel et bien passé IRCop (MODE 10AAAAAAK :+osw à 10:14:21), tape /mode #!Overtchat! +o SerVuS. Le serveur accepte. Une seconde plus tard, IriX le kicke : « Abus d'une désynchronisation ». La protection native d'Eggdrop ne regarde qu'une chose — « ce nick a-t-il l'op dans MA liste ? » — et elle ne s'applique pas aux utilisateurs qu'Eggdrop reconnaît. Or il ne le reconnaissait pas : le userfile portait *!Tgl0be@…, un ident supprimé depuis, quand OverScript se connecte en servus. Corrigé le jour même, à froid, en 2 secondes de coupure.

⚠⚠ Le fond, qui reste ouvert. Ce compte porte les flags jlmnoptx — n owner, o global op : les pleins pouvoirs sur le bot. Et ce qui les accorde est un hostmask :

⚠ Le premier cloak est celui de l'IP publique de la Freebox. Ce n'est pas un secret et ce n'est pas personnel : toute connexion venue de la maison le porte, y compris celle d'un visiteur. Ce masque ne protège donc que par l'ident — une chaîne que l'on choisit soi-même à la connexion. Le second ne protège même pas par ça.

⚠ Ce n'est pas une faille exploitable depuis Internet : il faut venir par ce chemin. Ce qui est en cause, c'est que le niveau de garde ne correspond pas à ce qui est gardé.

⚠⚠ La suite a montré que ce paragraphe sur-disait — ces flags n'ouvrent pas « les pleins pouvoirs sur le bot » mais la partyline, qui exige en plus le mot de passe et n'écoute qu'en local. Voir le bloc de mesure en tête du point.

Ce qu'on croyait devoir faire pour fermer — ⚠ et c'est une piste sans issue, mesurée le 21/08 : adosser à OverNick. Les grades applicatifs y sont déjà adossés ; ce qui reste sur hostmask est gardé par Eggdrop dans son binaire, hors d'atteinte d'un service d'identification.

📌 Lien avec le reste : c'est la face « userfile » des deux identités d'IriX — les grades en base d'un côté, les hostmasks Eggdrop de l'autre. Les deux ont divergé sans qu'aucun banc ne le voie, et c'est un utilisateur kické qui l'a signalé.

---

41. ✅ L'installateur ne posait AUCUNE unité systemd — CONSTATÉ FERMÉ le 20/08/2026

⚠⚠ CE CORRECTIF NE PRODUIT RIEN CHEZ UN TIERS — mesuré le 23/08/2026 sur une Ubuntu 24.04 neuve. Poser les unités suppose qu'elles soient là : Config/systemd/ n'arrive dans aucune installation tierce — ni par l'installateur, ni par le site (404), ni par l'archive /dl/site, ni par un clone, le dépôt étant privé. L'écran y annonce « Unités livrées 0 ». Le constat du 20/08 a été pris sur la machine qui possède le dépôt, où la question ne se pose pas.

⚠ C'est le motif le plus coûteux du projet : corrigé là où l'on regarde, pas là où la chose vit — et un banc restait vert. Les quatre mesures sont au point 43.

Constaté en production le 20/08/2026 à 14:16. SerVuS a lancé la pose : 14/14 unités posées, 0 écart avec le dépôt. La ligne # PREREQUIS: est arrivée sur les huit .service, les chemins et le compte de service sont substitués (User=servus, WorkingDirectory=/home/servus/Service-Overtchat), et les six timers tournent — opers toutes les 30 s, veille toutes les 2 min, backup à 04:00. La veille a repassé cinq fois après la repose : rien n'a été perturbé.

⚠⚠ ET LA PREMIÈRE TENTATIVE A ÉCHOUÉ SANS LE DIRE — c'était un message de MOI. Le script d'appoint affichait « ✔ 14 unité(s) posée(s) » même en mode --blanc : le compteur venait de la fonction de l'installateur, et le talon « à blanc » lui répondait « posé » sans rien écrire. Ce sont les dates des fichiers qui l'ont démasqué — /etc datait encore de 08:49. Un message vrai dans son contexte peut mentir hors de lui, et c'est un piège de plus à mettre au compte des constats menteurs. Corrigé par un bandeau explicite.

📌 Ce qui reste n'appartient plus à ce point : les quatre familles de fichiers système hors systemd — sudoers, logrotate, polkit, vhosts Apache — que le désinstalleur sait retirer et que l'installateur ne pose toujours pas. C'est le point 43.

---

L'état d'avant, gardé parce qu'il explique la décision

✅ La pose est écrite et éprouvée, le même jour. SerVuS a tranché : poser les quatorze, n'activer que ce dont le prérequis est vérifiable sur place. C'est fait — _sysd_poser, _sysd_activer et l'écran _panel_systemd (étape 6 de l'assistant), plus la convention # PREREQUIS: portée par chaque .service.

⚠ Aucune liste centrale n'a été écrite, et c'était la difficulté du point : une table « unité → condition » se périmerait au premier ajout. La liste est dérivée de Config/systemd/, et la condition vit avec l'unité — le motif de # RATTRAPAGE:, transposé.

⚠ L'écran est RÉ-EXÉCUTABLE, et ce n'est pas un confort : la mise à jour n'atteint jamais /etc/systemd/system/, donc sans lui la première pose serait la dernière.

🟡 Ce qui manque pour fermer, et c'est un geste que je ne peux pas faire : lancer la pose pour de vrai, sur une machine où /etc/systemd/system/ est écrivable. Bootstrap/tests/test-systemd-pose.sh exécute les fonctions sur un faux /etc — 23 constats, six mutations qui rougissent — mais un bac à sable n'est pas une installation.

⚠⚠ Et la passe de mutation a trouvé un trou dans ce banc-là aussi. Retirer la substitution des chemins hors racine le laissait VERT : toutes mes unités d'essai avaient leurs chemins sous la racine du projet, si bien que je mesurais une substitution qui se faisait déjà toute seule. C'est exactement le piège d'overop@.service, qui porte /home/servus/IriX/eggdrop. Une unité d'essai portant un tel chemin a été ajoutée ; la mutation rougit désormais.

Reste aussi, et ce n'est pas couvert : les quatre familles de fichiers système hors systemd (sudoers, logrotate, polkit, vhosts Apache), toujours désinstallables et jamais posées.

---

L'état d'origine, gardé parce qu'il explique la décision

Trouvé le 20/08/2026 en installant la veille du point 40 : il a fallu écrire la commande à la main, et c'est en cherchant pourquoi que le trou est apparu. Il est bien plus large que la veille.

Mesuré, pas déduit :

⚠⚠ On sait donc DÉSINSTALLER des unités qu'on ne sait pas INSTALLER. Et le désinstalleur, lui, est irréprochable : il dérive son inventaire de Config/systemd/ au lieu de l'énumérer (Tools/desinstaller.sh:161-166), avec le commentaire qui dit pourquoi — « une liste écrite à la main oublie ce qu'on ajoute ensuite ». C'est exactement le geste qui manque en face.

⚠ C'est la règle « où vit la chose » dans sa forme la plus pure : ici tout marche, parce que les unités ont été posées à la main, une par une, au fil des mois. Sur une installation neuve, le dépôt porte quatorze unités et /etc/systemd/system/ n'en reçoit aucune — l'état exact de cette machine à 08:48 le 20/08. Les sauvegardes ne tourneraient pas, les opérateurs du panel ne s'appliqueraient pas, les robots ne se poseraient pas, et la veille ne veillerait pas.

⚠ Et rien ne le signale. La campagne complète est au vert — 90 bancs, 4409 constats — parce qu'aucun banc ne compare Config/systemd/ à ce que l'installateur pose. C'est le motif des quatre défauts du 16/08, et le quatrième banc vert qui ne garde rien.

⚠⚠ Et en l'instruisant, le trou s'est révélé plus large sur trois points — chacun mesuré

a) Ce ne sont pas que les unités : QUATRE familles de fichiers système sont dans le même cas. Tools/desinstaller.sh:175-181 sait retirer /etc/sudoers.d/overtchat-services, /etc/logrotate.d/overtchat, /etc/polkit-1/rules.d/10-overtchat-irix.rules et les vhosts /etc/apache2/sites-available/irix-*.conf. L'installateur n'en pose aucun. Or la veille du point 40 ne peut relancer IriX que grâce à la ligne sudoers — sur une installation neuve, elle constaterait sans jamais pouvoir guérir.

b) ⚠⚠ UNE UNITÉ CORRIGÉE N'ATTEINT AUCUNE INSTALLATION EXISTANTE — PAR AUCUN CHEMIN. Mesuré : WATCHED_EXTENSIONS=( "sh" "json" "conf" "tcl" ) (Bootstrap/overtchat-setup.sh:265) — ni .service ni .timer. Le scan de mise à jour ne les ramasse donc jamais, et l'exclusion de la ligne 8584 est une ceinture sur une bretelle qui n'existe pas. Conséquence : Config/systemd/* n'est même pas téléchargé par la mise à jour, et de toute façon toute la machinerie opère sur $BASE_DIR, jamais sur /etc. La première pose est donc la dernière. Cela impose, quelle que soit l'option retenue, un point d'entrée ré-exécutable — sans lui, une correction d'unité est indiffusable.

c) Trois unités citées par le désinstalleur n'existent NULLE PART au dépôt. Vérifié par find : irix.service, overtchat-web.service et unrealircd.service sont introuvables ; seul overtchatd.service existe, et hors Config/systemd/ (Servers/overtchat-hybrid/contrib/). Une pose « dérivée de Config/systemd/ » ne les couvrira donc pas, et le commentaire desinstaller.sh:168-169 — « sont posées par l'installateur » — restera faux.

⏪ CE QUI SUIT EST L'ÉTAT D'AVANT LA FERMETURE — PÉRIMÉ, gardé pour la trace. Le critère décrit ci-dessous a été tenu le 20/08/2026 — voir le constat en tête de point. La décision A/B posée ici a été tranchée par SerVuS, et le code livré : 14/14 unités posées, constatées en production à 14:16. ⚠ Ne pas le relire comme du travail à faire. Un encadré « Pour fermer » périmé sous un titre ✅ est exactement ce qui fait rouvrir un point déjà clos.

Pour fermer — ⚠ il y a une décision avant le code, et elle tient en une phrase : sur une installation neuve, quel doit être l'état de /etc/systemd/system/ à la sortie de l'installateur ?

⚠ Dans les deux cas, sans discussion : la liste est dérivée de Config/systemd/, jamais énumérée ; les chemins et le compte sont substitués sur le modèle déjà livré et éprouvé de Servers/overtchat-hybrid/contrib/install-service.sh:141-145 (⚠ qui vise ^User=servus$ nommément, et non un s/servus/…/g global qui réécrirait commentaires et chemins déjà traités) ; overop@.service est traité à part — c'est un template, jamais enable sans instance ; et l'activation ne vise que le .timer pour les sept unités oneshot, dont les [Install] les feraient sinon tourner au démarrage en plus du timer.

⚠ Le sed livré ne couvre pas tout : overop@.service porte /home/servus/overop-%i et /home/servus/IriX/eggdrop, deux chemins sans Service-Overtchat dedans.

⚠ Et adosser un banc qui compare les deux sens (dépôt → posé, posé → dépôt), sans quoi ce point se rouvrira seul au prochain ajout — c'est très exactement ce qui vient de se produire avec la veille.

---

40. ✅ L'alerte du bot se taisait EXACTEMENT quand il fallait qu'elle parle — CONSTATÉ FERMÉ le 20/08/2026

Les trois gestes sont constatés, chacun sur une source indépendante. Ouvert le 19/08, fermé le 20/08 : la veille extérieure est installée et relance pour de vrai ; le rangement automatique fait qu'une panne qui revient reparle ; et le filet horaire poste ce que le cycle ordinaire n'a pas posté. Le détail de chaque constat est plus bas, à sa place.

⚠⚠ Ce que ce point aura appris, et qui vaut au-delà de lui : COUPER LE SERVICE DEUX FOIS. Le premier essai a tout validé — détection, base, courriel accepté par le relais, relance. Le second, cinq minutes plus tard, n'a rien produit : c'est lui qui a trouvé le défaut, et trois bancs verts ne le voyaient pas. Le premier essai éprouve le chemin ; le second éprouve le retour à l'état initial, qui est la moitié qu'on n'écrit jamais.

Sorti du point 38, dont il était le deuxième reliquat. La cause des dix millions de minuteurs est corrigée et constatée ; ce défaut-ci ne l'est pas, et il ne dépend pas d'elle.

⚠⚠ ::soc::alerte::cycle_courriels est armé par un utimer. Quand les minuteurs manquent — saturation, ou n'importe quelle autre cause future —, la ligne d'alerte part bien au journal et en base, mais le courriel ne part jamais. C'est ce qui a rendu les pannes des 18 et 19/08 totalement muettes : cinq heures, puis trois heures et demie, sans que personne soit prévenu.

⚠ Ce n'est pas réparable de l'intérieur. Une alerte portée par le mécanisme qu'elle doit surveiller partage sa maladie. Le seul porteur interne qui survivrait est un bind time (déclenché par l'horloge, pas par la file des minuteurs) — et tout nouveau bind time doit déclarer sa ligne # RATTRAPAGE:, contrôlée par IriX/tests/test-bindtime.tcl.

Ce qui EXISTE déjà, et qu'il ne faut pas réécrire (4.19.18) :

• Tools/veille-irix.php — une sonde qui vit hors du bot, lancée par systemd. Elle ne lit que des signaux qu'un bot malade ne peut pas simuler : le contenu de la queue du journal, la mémoire du processus, un journal figé, et un journal qui enfle au-delà du plafond. ⚠ Les quatre menteurs mesurés pendant les pannes sont écartés, et le fichier dit pourquoi : systemctl is-active (dit running sur un bot étouffé), connected en base (est resté oui 35 min après la mort du lien), la taille du journal (il grossissait de 1,5 Go… d'erreurs), le socket en écoute (survit au gel).
• Config/systemd/overtchat-veille.{service,timer} — sonde toutes les 2 min, relance au plus une fois par heure. ⚠ SuccessExitStatus=0 1 : une anomalie détectée n'est pas un échec de la veille, c'est son travail.
• Éprouvée sur quatre cas (sain, saturation, journal figé, processus absent).

✅ LA JOURNÉE DU 20/08/2026 — les trois gestes, et ce que l'essai a trouvé

1. ✅ INSTALLÉE — constaté le 20/08/2026 à 08:49:33. enabled + active, lien timers.target.wants en place, premier passage à 08:49:33 (ExecMainStatus=0 : IriX allait bien). ⚠ Le sed de l'en-tête n'a pas été appliqué, et c'est correct : la racine de prod est littéralement /home/servus/Service-Overtchat. ⚠ overtchat-veille.service reste disabled volontairement, comme motd et backup — c'est le timer qui déclenche.

2. ✅ ELLE ALERTE POUR DE VRAI — constaté deux fois, dont une sans aucune main humaine.

⚠ Délai réel de bout en bout : 81 s entre la coupure et la relance. Sur une saturation qui met 77 à 102 min à s'installer, c'est très largement dans les clous.

⚠⚠ ET L'ESSAI A TROUVÉ UN DÉFAUT QUE TROIS BANCS VERTS NE VOYAIENT PAS. En coupant IriX deux fois au lieu d'une : la première panne a produit un courriel, la seconde rien du tout. La ligne restait ouverte avec son mail_at posé, et les requêtes d'envoi ne retiennent que mail_at IS NULL — une cause devenait donc muette pour toujours, jusqu'à un acquittement humain. Les pannes des 18 et 19/08 étaient précisément des pannes répétées : seule la première aurait parlé. Corrigé en 4.19.27 (alerte_ranger_disparues(), adossée à alerte_acquitter()), et constaté en production à 09:15→09:21 : deux pannes, deux courriels, deux rangements automatiques par=veille. Second écart trouvé au passage : le code de sortie 2 n'avait jamais été rendu, alors que l'en-tête du fichier et le .service l'annonçaient tous les deux.

📌 La leçon, et elle vaut au-delà de ce point : couper le service DEUX fois au lieu d'une. Le premier essai valide le chemin ; c'est le second qui trouve ce qui ne se réarme pas.

3. Le sort de l'alerte interne — tranché et livré en 4.19.28. Voir plus bas.

---

Ce qu'il fallait pour fermer :

1. ⚠⚠ L'INSTALLER — c'est un geste de l'exploitant. Écrire dans /etc/systemd/system/ exige un mot de passe ; sudo -n ne couvre que start/stop/restart sur trois unités. La procédure est en tête du .service. SerVuS a donné son accord le 19/08/2026 (avec relance automatique) ; le geste a été fait le 20/08 à 08:49:33.
2. Constater qu'elle alerte pour de vrai — provoquer l'anomalie et voir le courriel arriver. ⚠ Ne pas se contenter du code de sortie de Tools/alerte-courriel.php : il rend 0 aussi quand l'alerte était déjà envoyée ou déjà rangée. ⚠⚠ CETTE PHRASE ÉTAIT FAUSSE, et elle a failli fausser un constat. Elle annonçait un limiteur à « 2 courriels par heure et par adresse » qui étranglerait une sonde bavarde en silence. Il n'y en a aucun sur ce chemin. Mesuré le 20/08/2026 : contact_rate_block() vit dans Web/inc/contact.php et n'est appelée que par le formulaire de contact public ; smtp_send() ne porte aucun plafond, et Tools/alerte-courriel.php l'appelle directement. Le seul bornage des alertes est le LIMIT 3 par passage et le regroupement d'une cause ouverte en une seule ligne. ⚠ Sans cette vérification, un essai qui n'aurait rien reçu aurait été mis sur le compte du limiteur, et le vrai défaut serait resté caché — c'est précisément ce qui a failli arriver le 20/08.
3. Décider du sort de l'alerte interne. Tant qu'elle reste sous utimer, elle continuera de se taire dans le seul cas qui compte. Soit on la porte sur un bind time, soit on assume que la veille extérieure est le seul chemin d'alerte fiable — et alors il faut l'écrire, parce que le code laisse aujourd'hui croire le contraire.

✅ TRANCHÉ PAR SerVuS LE 20/08/2026 : les deux à la fois, et c'est livré en 4.19.28. La veille extérieure est écrite comme le chemin fiable, et un filet horaire est posé côté bot — ::soc::alerte::rattrapage_courriels, liée par un bind time à "05 * * * *" dans IriX-binds.tcl.

⚠ Les deux porteurs couvrent deux pannes qui n'ont rien à voir, d'où le refus de choisir : un gel de Windows DÉCALE un utimer (rien n'est perdu) mais PERD un bind time — c'est le point 15, et c'est pourquoi le cycle principal reste sur utimer ; une saturation de la file des minuteurs, elle, tue le utimer pour de bon, et seule l'horloge y survit.

⚠ Le filet ne pose aucun minuteur et ne se réarme pas : un filet qui dépendrait de ce qu'il rattrape ne rattraperait rien. Il est recevable en forme « RATTRAPAGE: aucun — ASSUMÉ » parce qu'il est idempotent — il vide une file dont le critère est mail_at IS NULL, donc un tour manqué n'est pas un travail perdu.

⚠ Il DIT au journal quand il a réellement rattrapé quelque chose, et se tait sinon. Un filet muet serait invérifiable — le défaut même de ce point, un étage plus haut.

⚠⚠ IriX/tests/test-alerte.tcl:326 EXIGEAIT l'absence de tout bind time : le banc interdisait littéralement ce correctif. Il a été retourné, et pas seulement supprimé — le bind vit dans IriX-binds.tcl, que ce banc ne lisait pas. Le retirer aurait laissé le banc vert sans plus rien garder ; poser le bind ailleurs l'aurait laissé vert pour une mauvaise raison. Il lit désormais les deux fichiers et ancre la procédure ici, sa liaison là-bas.

⚠ Le constat « le filet ne pose aucun minuteur » cherche un appel, pas un mot — début de ligne ou juste après une accolade, ce qui couvre le catch { utimer … } par lequel on le contournerait. Éprouvé dans les deux sens.

⚠ test-bindtime.tcl a rougi tout seul en cours de route, sur un bloc de commentaire trop long : la convention exige la ligne # RATTRAPAGE: dans les 15 lignes au-dessus du bind, contiguë. C'est une garde qui mord pour de vrai.

⚠ Le bind est posé AVANT que la procédure existe — IriX-binds.tcl est sourcé ligne 39, irix-alerte.tcl ligne 670. Sans conséquence (Eggdrop résout au déclenchement), et le démarrage de 09:38:32 le confirme sans une erreur ; c'est le motif des deux autres bind time. ⚠ Mais un renommage ne se verrait qu'une fois par heure, dans le journal d'Eggdrop seul — c'est ce que garde la mutation « proc renommée » du banc.

✅ LE BIND EST CONSTATÉ EN SERVICE — 20/08/2026 à 10:05:00, dans journalctl -u irix :

   10:05:00  triggering bind ::soc::alerte::rattrapage_courriels
   10:05:00  triggered  bind ::soc::alerte::rattrapage_courriels, user 0.103ms sys 0.109ms

Trois choses d'un coup, et c'était le maillon le plus risqué : le bind est enregistré, il est déclenché par l'horloge, et la procédure s'exécute sans erreur — donc sa signature à cinq arguments est bonne et le bind ne pointe pas dans le vide.

✅ ET IL POSTE — CONSTATÉ le 20/08/2026 à 11:05:00. Au premier essai, à 10:05, la file était vide : le filet n'avait rien à faire et s'est tu, comme prévu. Repris à 11:05 avec la fenêtre calculée juste :

   11:04:30  alerte id=17 posée, mail_at=NULL
   11:05:00  triggering bind ::soc::alerte::rattrapage_courriels
   11:05:00  SOC ALERTE: filet horaire — 1 courriel(s) rattrapé(s), le cycle ordinaire n'avait pas suivi
   11:05:00  [INFO]  alerte : courriel #17 — Envoyée à service.overtchat@free.fr
   11:05:01  postfix: status=sent (250 2.0.0 Ok: queued as B9476B00573)

⚠ La preuve est DIRECTE, et c'est pour cela que le filet parle : la ligne « filet horaire — N courriel(s) rattrapé(s) » n'est écrite que par rattrapage_courriels, par personne d'autre. Un filet muet aurait laissé la question ouverte — on aurait vu un courriel partir sans pouvoir dire lequel des deux chemins l'avait envoyé.

⚠ Et la course a été rendue déterministe : le cycle ordinaire passe à :55, le filet à hh:05:00, l'alerte a été posée à 11:04:30 — entre les deux.

⚠⚠ ET LA RAISON VAUT PLUS QUE LE CONSTAT MANQUÉ. La fenêtre d'essai avait été calculée fausse de 22 secondes. Le cycle ordinaire ne passe pas là où je l'avais déduit : demarrer_courriels est appelée dans un after 15000 après db_init, pas au démarrage du bot — le pas tombe donc à :55, et 09:38:55 + 5×300 s = 10:03:55 exactement. L'alerte d'essai, posée à 10:03:50, a été prise par le cycle ordinaire cinq secondes plus tard.

⚠⚠ ET LA TRACE ÉTAIT DANS LE TROISIÈME JOURNAL. IriX/runtime/IriX.log ne montrait rien ; la ligne « alerte : courriel #16 — Envoyée à … » vit dans IriX/cmds/IriX-sql.log. En ne regardant que le premier, on conclut « aucun envoi » et on accuse le mauvais mécanisme. C'est la règle des trois journaux, prise en défaut le jour même où on l'applique.

La méthode, pour refaire l'essai : le cycle ordinaire passe à :55 ; le filet tire à hh:05:00. Poser l'alerte d'essai entre hh:03:56 et hh:04:59 — le filet la prend, et le cycle ordinaire ne repasse que quatre minutes après lui. ⚠ Sans ce calcul, on constate le cycle ordinaire en croyant constater le filet : un vert authentique, pour la mauvaise raison.

39. ✅ La référence d'intégrité vivait dans /tmp — CONSTATÉ FERMÉ le 20/08/2026

Constaté en production le 20/08/2026 à 13:46, l'installateur lancé par SerVuS : Runtime/state.json créé, en 600, portant .install=true, la langue et le nom du projet. /tmp/.service-overtchat.json n'existe plus. Le fichier est ignoré par git (.gitignore:55), l'arbre du clone de production est propre, et les cinq services tournent.

⚠ Les six empreintes sont à AUCUNE, et c'est le comportement voulu : le fichier vient de naître, et la vérification refuse désormais au lieu d'adopter l'état en place. Les poser est un geste délibéré — entrée 13 du menu, grade 80, confirmation en toutes lettres. C'est le pendant assumé du refus, ajouté en 4.19.31 parce que la migration a rendu le manque concret en une minute : plus rien n'était vérifiable, et rien ne permettait de repartir.

🟢 REMESURÉ LE 21/08/2026, et la mesure corrige un détail qui compte : ce ne sont plus six empreintes absentes mais cinq — services, servers, access, eggdrop, irix. La sixième, overop, s'est reposée toute seule le 20/08 à 14:57, quand Config/overop.json a été réécrit : _sha256_store est appelée à chaque écriture de configuration.

⚠ Donc « rien ne les repose tout seul » est faux, et le nuancer évite une fausse alerte : une empreinte reparaît dès qu'on règle le fichier correspondant depuis le panel. Le geste de l'entrée 13 sert à poser les cinq autres d'un coup, sans avoir à toucher à cinq réglages pour rien.

Le reste du constat tient : fichier en 600, gitignoré (.gitignore:55), /tmp ne porte plus ni .service-overtchat.json ni son jumeau, et la clé bootstrap — celle qui n'a aucun appelant — est bien restée à null, sans que personne l'ait ré-enregistrée au passage.

🟡 CORRIGÉ LE 20/08/2026 — reste à le CONSTATER sur une installation

INIT_BASE vaut désormais $BASE_DIR/Runtime/state.json, en 600, déclaré sous BASE_DIR (il l'était 110 lignes trop haut, là où la variable n'existe pas encore). mkdir -p posé sur les deux chemins de démarrage — ⚠ dont le chemin CLI/cron, qui n'appelle jamais _create_folders : c'est le piège le plus discret, la dépendance étant circulaire puisque _create_folders dérive ses chemins de ce fichier même.

⚠⚠ LA MESURE A RETOURNÉ LE POINT. Ce fichier n'est pas un fichier d'empreintes : il porte .install — la mémoire que l'installation a eu lieu —, .folders et ses 18 chemins, la langue, le nom du projet, les 32 modules Tcl à déployer. Sa perte ne cassait donc pas seulement l'intégrité : elle faisait croire à l'installateur qu'il n'avait jamais tourné. La « voie étroite » envisagée plus bas — ne sortir que les six clés — n'avait donc pas de sens : elle aurait créé deux sources de vérité pour un même état.

⚠ Runtime/ et non Config/ : le chemin Runtime/state.json était déjà réservé dans _upd_exclu pour un fichier qui n'existait nulle part. Une des deux listes était faite d'avance ; .gitignore a été complété dans le même commit.

Les trois défauts logiques ont été corrigés DANS LE MÊME GESTE, et il le fallait : un fichier persistant les aurait figés au lieu de les révéler — le mécanisme aurait paru sain parce qu'il ne se réinitialisait plus. Une référence absente est refusée ; le code de retour n'est plus avalé (2 corrompu, 1 sans référence, 0 sinon) ; la clé overop est enfin vérifiée.

Banc neuf : Bootstrap/tests/test-empreintes.sh — 17 constats, il exécute les trois fonctions, et quatre mutations rougissent. ⚠ Ne pas le confondre avec test-integrite.sh, qui éprouve le manifeste distribué : la confusion a déjà trompé une lecture de SECURITY.md.

⚠ Trou dormant fermé au passage : Config/overop.json n'était dans aucune des deux listes.

Pour fermer : lancer l'installateur sur cette machine et constater que Runtime/state.json est créé, en 600, et que l'option 9 dénonce un fichier altéré au lieu de l'adopter.

---

L'état d'origine, gardé parce qu'il explique la correction

Constaté le 19/08/2026 en remesurant SECURITY.md. Le panel d'administration propose « Vérifier l'intégrité SHA256 » (option 9). Il compare les fichiers de configuration à des empreintes relevées à l'installation. Ces empreintes vivent dans /tmp.

⚠⚠ CE N'EST PAS UN RISQUE THÉORIQUE : LE FICHIER EST ABSENT EN CE MOMENT.

Deux effaceurs cumulés, tous deux mesurés. Sous WSL la fenêtre est plus COURTE qu'ailleurs : la VM redémarre à chaque fermeture de session Windows et sur arrêt d'inactivité.

⚠⚠ LE PIRE N'EST PAS LA PERTE, C'EST CE QUE FAIT LA PASSE SUIVANTE. Quand la référence manque, _sha256_verify affiche « Pas de hash référence — enregistrement… » et enregistre l'état en place, quel qu'il soit. Elle adopte donc une éventuelle altération au lieu de la dénoncer, et le passage d'après la déclarera saine. Une détection qui ne détecte pas est pire que pas de détection : elle rassure.

⚠ Et cela ne remonte à personne : la fonction rend 1 dans ce cas, mais _integrity_check_all avale le code par || true. Rien ne s'accumule, rien n'alerte, rien ne distingue à l'œil un ré-enregistrement en masse d'un contrôle réussi.

Trois défauts voisins, mesurés au passage — à traiter ici ou à acter à part :

1. La clé overop est écrite et morte. Trois fonctions enregistrent consciencieusement l'empreinte de Config/overop.json ; rien ne la relit jamais. _integrity_check_all ne vérifie que cinq clés.
2. Le panel lui-même n'est jamais vérifié. L'option 9 contrôle des fichiers de configuration, jamais le code qui les contrôle. La clé par défaut bootstrap n'a aucun appelant.
3. ⚠⚠ AUCUN BANC ne couvre _sha256_store, _sha256_verify ni _integrity_check_all. ⚠ Ne pas se fier au nom de Bootstrap/tests/test-integrite.sh : il éprouve l'AUTRE mécanisme, celui du manifeste distribué. Les deux n'ont rien à voir, et les confondre a déjà trompé la lecture de SECURITY.md.

Ce qu'il faut pour fermer — dans cet ordre :

1. Sortir la référence de /tmp. ⚠ Décision à prendre : Config/ est l'emplacement cohérent (voisin d'update_state.json, gitignoré, exclu de la mise à jour, sauvegardé) ; Runtime/ est défendable car Runtime/state.json est déjà prévu dans _upd_exclu sans exister. ⚠ Une voie plus étroite existe : ne sortir que les six clés d'empreinte et laisser le reste de la configuration d'exécution où il est — moins de surface, moins de casse.
2. ⚠⚠ Inscrire le nouveau chemin dans LES DEUX listes — _upd_exclu et .gitignore. Le commentaire de _upd_exclu raconte déjà cette régression exacte pour Config/travaux.json : un fichier d'état non exclu entre dans la liste surveillée, donne un 404 permanent, un rapport rouge en continu et un courriel d'alerte à chaque passage. Côté git, un fichier non suivi que le prochain commit voudrait créer fait échouer merge --ff-only et laisse le déploiement en arrière.
3. Créer le répertoire parent avant la copie dans main : le gabarit est copié avant _create_folders. Sans cela, premier lancement en échec — une panne de démarrage, pas d'intégrité.
4. ⚠⚠ NE PAS migrer silencieusement depuis /tmp. La référence est déjà perdue ; et si l'on en trouvait une, rien ne dirait qu'elle décrit un état sain — elle a pu être ré-enregistrée après un redémarrage. Migrer donnerait à des empreintes suspectes l'apparence d'une référence durable. Ré-enregistrer, et le dire.
5. Distinguer « référence absente » de « vérification réussie » autrement que par un code de retour qu'un || true avale.
6. Écrire le banc qui manque : enregistrer, vérifier OK, altérer, vérifier INVALIDE, supprimer la référence, constater que la passe suivante ne fait qu'enregistrer. Ce dernier cas est le défaut de ce point : un banc qui ne l'éprouve pas ne garde rien.

⚠ Effet de bord à assumer : sous BASE_DIR, le fichier entre dans la sauvegarde. Restaurer une archive ancienne restaurera des empreintes anciennes, et toute configuration légitimement modifiée depuis criera « HASH INVALIDE ». C'est un coût réel du déplacement, pas une objection.

38. ✅ IriX fabriquait dix millions de minuteurs et s'étouffait — CONSTATÉ FERMÉ le 19/08/2026 sur 3 h 15 de marche

⚠⚠ LA CAUSE ÉCRITE ICI JUSQU'AU 19/08 ÉTAIT FAUSSE, ET ELLE ENVOYAIT CHERCHER AU MAUVAIS ENDROIT. Ce point accusait le gel de WSL : « le gel empêche les minuteurs déjà posés d'arriver à terme ; ils s'empilent ; au dégel la limite est franchie ». Un gel ne fabrique pas de minuteurs — il les retarde.

Ce que le binaire dit (Eggdrop 1.10.2, lu au désassemblage) : add_timer ne contrôle aucun nombre de minuteurs vivants. Il formate le nom timer<N> avec snprintf(buf, 8, …), soit sept chiffres au plus, à partir d'un compteur global jamais remis à zéro. Au dix-millionième identifiant émis depuis le démarrage, tout utimer est refusé. llength [utimers] peut valoir 9 et l'armement échouer quand même.

Ce que les archives disent — trois épisodes, pas un :

⚠ Le troisième n'avait jamais été vu. Il a commencé 1 h 17 après le redémarrage du 18/08 16:41 et ne s'est arrêté qu'à l'extinction de la machine (TERMINATE SIGNAL), pas par une guérison. ⚠ Et dans les deux épisodes datables, l'échec commence au même identifiant, timer5000228 — deux mesures indépendantes sur le même plafond.

La vraie cause, deux fautes qui se cachaient l'une l'autre, toutes deux dans ::soc::auth (IriX/cmds/IriX-sql.tcl) :

1. schedule_scan armait par utimer et tuait par killtimer. ⚠⚠ Ce sont deux files distinctes dans Eggdrop : tcl_killtimer cherche dans la liste à la minute, tcl_killutimer dans celle à la seconde. Un identifiant rendu par utimer n'y est jamais trouvé ; l'erreur mourait dans le catch et le minuteur précédent restait armé.
2. scan replanifiait après avoir appelé scan_pass sous catch, alors que scan_pass replanifiait déjà sur ses quatre chemins.

→ deux minuteurs posés par tour, aucun retiré : doublement toutes les 60 s.

⚠⚠ ET LE COMMENTAIRE DU CODE AFFIRMAIT LE CONTRAIRE. Il disait « le double réarmement est SANS DANGER, schedule_scan tue le minuteur précédent ». Écrit le 17/08 à 18:04, la veille de la panne. C'est le piège connu du projet — lire le commentaire du correctif au lieu du code — et il a coûté le réseau deux fois.

Corrigé le 19/08 (4.19.17) : les dix killtimer posés sur des utimer sont devenus des killutimer (aucune procédure stop du bot n'arrêtait quoi que ce soit), les quatre réarmements de scan_pass sont retirés — le réarmement appartient à scan, et à lui seul —, et le commentaire menteur est remplacé par le récit des faits. ⚠ Robots/overop/overop.tcl est correct : il apparie timer avec killtimer. Ne pas le « corriger ».

Gardé par IriX/tests/test-minuteurs.tcl, qui dérive les deux règles du code. ⚠ Sa première version ne lisait aucun cycle et affirmait pourtant que tout allait bien : c'est son garde-fou « des cycles ont bien été lus » qui l'a dit. Un détecteur qui ne détecte rien a l'allure d'un projet sain.

✅ LE CONSTAT, PRIS LE 19/08/2026 — 3 h 15 de marche

Veille lancée à 11:41:47, quarante relevés toutes les cinq minutes jusqu'à 15:01.

À comparer à la session malade : +161 Mo en 31 minutes.

⚠ Les deux fenêtres de saturation sont franchies, et largement. Les épisodes des 18 et 19/08 saturaient à 77 et 102 minutes ; la veille a tenu 195 minutes, soit deux fois et demie la première. ⚠ Et la platitude n'est pas un argument à elle seule — la croissance était exponentielle, donc plate au début : c'est la durée qui tranche, pas la pente.

Ce qui a fermé le point, dans l'ordre : la cause corrigée (4.19.17 — killutimer à dix endroits, et le réarmement rendu unique), le plafond de taille des journaux (4.19.19), puis ce constat.

⚠⚠ CE QUI RESTE N'EST PAS DANS CE POINT — il est devenu le point 40. L'alerte du bot passe elle-même par un utimer : elle se tait exactement quand il faudrait qu'elle parle. La veille extérieure qui répond à ce défaut est écrite et éprouvée, mais pas installée. C'est un défaut distinct, qui ne dépend pas de la fuite corrigée ici.

⚠ Remède immédiat, éprouvé deux fois : sudo -n /usr/bin/systemctl restart irix.service — RSS 183 Mo → 21,7 Mo le 19/08, lien actif en une seconde. ⚠⚠ Nommer l'unité avec .service, sans quoi sudo réclame un mot de passe et envoie chercher un problème de droits inexistant.

37. ✅ Après une rupture de lien, IriX choisissait un SID que le serveur refuse — CONSTATÉ FERMÉ le 24/08/2026, echec_burst compris

Les quatre traces du critère, toutes relevées :

L'alerte, en base — IriX_alertes id 18 :

cle      : burst:Overtchat:refus du serveur      ← le format exact du critère
niveau   : crit          source : uline
sujet    : Le lien « Overtchat » n'aboutit pas — le réseau est sans services
compte   : 2             ← elle a levé DEUX fois, ~6 échecs

⚠ source='uline' : c'est la première de tout le registre. Les quatorze alertes antérieures venaient de essai, veille, logrot et botnet — cette source-là n'avait jamais servi.

La remise en état, vérifiée : SID=003 | active | connected=oui | retry=0 | last_error vide, « 5 service(s) en ligne » à 17:55:15, et le lien porte de nouveau du trafic (BOTSTAT, PING/PONG).

Et le SERVEUR le dit aussi — deuxième source, indépendante du bot. journalctl -u overtchatd :

17:52:45 → 17:54:45  WARN   Lien refusé pour IriX.overtchat.fr : SID 002 annoncé, 003 attendu   (×6)
17:55:15             NOTICE Lien établi avec IriX.overtchat.fr (SID 003) [ULine]
17:55:15             INFO   Burst : 1 serveurs, 5 clients, 6 salons — Synchronisation terminée

⚠ C'est le serveur qui nomme la valeur attendue. Le bot dit « refus du serveur » sans savoir pourquoi ; seul ce journal-là porte « 003 attendu ». Il n'est pas dans les trois que ce projet croise d'habitude — c'est un cinquième endroit, et il faut y penser pour tout ce qui touche au lien.

⚠⚠ UN PIÈGE ÉVITÉ SANS LE SAVOIR, ET IL FAUT L'ÉCRIRE. Le faux SID doit être de forme valide — 002, 007, 0ZZ. Un SID de forme invalide (ZZZ, vide, NULL) ne serait pas envoyé au serveur : connect_socket appellerait next_free_sid et écraserait la valeur en base, faisant perdre l'original. Et le premier SID libre qu'il choisirait serait justement 002. Qui refait cet essai avec une valeur fantaisiste perd le 003 de la base, et doit aller le rechercher dans overtchat.conf — où c'est le serveur qui l'impose, link IriX.overtchat.fr { sid "003"; … }.

⚠⚠⚠ CE QUE LE CRITÈRE NE DISAIT PAS, ET QU'IL FAUT AJOUTER : L'ESSAI ENVOIE UN VRAI COURRIEL. Il annonçait « coupe les services ~90 s » — c'est vrai, mais incomplet. À 17:56:23, l'alerte a déclenché un courriel réellement expédié :

IriX_mail_log id 24 · dest service.overtchat@free.fr · statut ok
sujet : [Alerte] uline — Le lien « Overtchat » n'aboutit pas — le réseau est sans services
postfix : status=sent, relay=smtp.free.fr[212.27.48.4], 250 2.0.0 Ok

⚠ J'ai acquitté l'alerte seize secondes trop tard. Je croyais l'envoi calé sur le rattrapage horaire (bind time "05 * * * *") : c'est faux, ce balayage n'est qu'un filet, l'envoi normal part bien plus vite. Qui refait cet essai doit acquitter l'alerte AVANT qu'elle ne lève, ou accepter qu'un courriel d'alerte critique parte pour de bon.

Constaté en production le 17/08/2026, en vérifiant le réseau après un gel de WSL. Le réseau est resté sans aucun service pendant 1 h 45, sans qu'une seule alerte parte.

L'enchaînement, lu au journal :

⚠ Le serveur a raison de refuser : son bloc link IriX.overtchat.fr déclare sid "003" (et link services.overtchat.fr déclare 005). C'est IriX qui s'attribue un SID au lieu de reprendre celui que sa configuration impose.

⚠⚠ ET RIEN NE LE SIGNALE. Le refus est propre, côté serveur : pas d'exception, pas de socket cassée, pas d'erreur Tcl. IriX_ulines_sockets porte connected = non et le réseau tourne sans services — OverTchat, OverHub, OverNick, OverBot et OverWeb absents — pendant que tout le reste a l'air normal. C'est une panne totale d'un sous-système, silencieuse.

⚠ Second verrou, qui a empêché la réparation douce : corriger le SID en base n'a pas suffi. socket_state était resté à connecting, et cet état bloque toute nouvelle tentative — le lien ne repart pas tant qu'il n'est pas remis à zéro. C'est le motif exact du verrou topic_running du point 36 : un verrou posé qu'un chemin d'échec ne rend jamais. Il a fallu redémarrer le bot.

Réparé le 17/08 à 20:16 : server_sid remis à 003, redémarrage d'IriX, lien active, cinq services en ligne, reflet reconstruit.

⚠ Ne pas conclure trop vite que le gel de WSL est la cause : il n'a été que le déclencheur. N'importe quelle rupture — redémarrage du serveur, coupure réseau, SQUIT — mène au même état.

---

🔁 IL S'EST REPRODUIT LE SOIR MÊME — et ce que la seconde fois a appris

17/08/2026, 20:35:14. Deux heures après la première réparation, à l'ouverture de la séance suivante. Même enchaînement, aux mêmes minutes près :

⚠⚠ CE QUE LA PREMIÈRE ANALYSE AVAIT MANQUÉ, ET QUI CHANGE TOUT : le code ÉCRASE server_sid EN BASE. Deux relevés à trente secondes d'écart le prouvent — 003 à 20:35:0x, 002 à 20:35:44. Ce n'est pas seulement que la valeur configurée est ignorée : elle est détruite. Voilà pourquoi « corriger le SID en base n'a pas suffi » — la correction ne survivait pas à la tentative suivante.

⚠ Et la seconde fois, socket_state valait disconnected, pas connecting. Le remettre à disconnected n'a rien relancé non plus. Le vrai verrou est en MÉMOIRE, pas en base : sock_connected($id) restait à 1 sur un descripteur fermé, et c'est lui que le balayage interroge pour décider de rejouer l'auto-connect. La base disait une chose, la mémoire l'inverse, et les deux se protégeaient l'une l'autre. Seul un redémarrage du bot vide la mémoire.

✅ Les trois correctifs, livrés en 4.19.15

1. Le SID de la configuration est transmis. ::soc::ulines::auto::reconnect_by_id ne lisait pas server_sid et appelait connect_socket avec huit arguments au lieu de neuf — le neuvième, optionnel, retombait sur sa valeur vide. ⚠ Les trois autres appelants le passaient depuis toujours ; seul ce chemin-ci l'oubliait, et c'est celui qu'emprunte toute rupture de lien.
2. Les verrous sont rendus. Les quatre sorties d'échec de la phase de burst passent par une sortie commune, ::soc::ulines::auto::echec_burst, qui rend sock_connected, sock_handles et sock_state, pose l'état et le motif en base, et journalise. ⚠ Rendre le drapeau ne force aucune reconnexion : il rétablit la garde du balayage dans son état vrai, et le cycle d'auto-connect qui existe déjà reprend son travail toutes les 30 s. On ne touche pas à la garde, on cesse de lui mentir.
3. Un refus du serveur alerte. ⚠ alerte::echec et non alerte::erreur, contrairement à ce que ce point demandait : un serveur qui redémarre refuse pendant quelques secondes, et c'est normal. Le seuil de trois vaut désormais 90 s, parce que le rejeu existe depuis le correctif n°2 — sans lui, le compteur serait resté à 1 pour toujours, et le raisonnement d'origine était juste.

⚠ Correctif de sûreté associé : next_free_sid comptait le SID de la ligne qu'on est en train de connecter parmi les identifiants « déjà pris », et en cherchait donc un autre. Elle s'exclut maintenant elle-même. La lecture des SID des AUTRES liens reste entière — c'est la garde anti-collision, et deux liens partageant un SID font accepter le SERVER puis rejeter en silence tous les UID.

⚠ Le journal disait trop peu : « SID auto-attribué : 002 » n'indiquait pas quelle valeur venait d'être écrasée. La ligne avait l'air d'une attribution normale sur un lien neuf. Elle distingue maintenant « aucun SID en base » de « SID invalide — REMPLACÉ ».

Le banc : IriX/tests/test-uline-reconnexion.tcl, 28 constats, ramassé par Tools/bancs.sh. ⚠ Il dérive les appelants de connect_socket au lieu de les énumérer — une liste écrite à la main aurait laissé passer exactement celui qui manquait.

⚠⚠ LA PASSE DE MUTATION A PRIS CE BANC EN DÉFAUT DEUX FOIS, et les deux mensonges sont instructifs :

• « server_sid ne figure plus dans le SELECT » passait au vert, parce que le commentaire écrit juste au-dessus de la requête contient le mot. Le banc lisait son propre plaidoyer et le prenait pour une preuve.
• « l'exclusion n'est plus appliquée » passait au vert aussi : le constat cherchait la chaîne id != dans le texte. Une exclusion calculée puis jamais utilisée laisse la chaîne en place. Chercher un texte prouve qu'on l'a écrit, jamais qu'il agit.

Les deux sont désormais des constats de comportement : le code est extrait de la source et exécuté. Neuf mutations éprouvées, huit détectées.

🧪 PREMIER CONSTAT EN PRODUCTION — 17/08/2026 à 21:19, rupture PROVOQUÉE

Avec l'accord de SerVuS, un seul essai : arrêt du serveur IRC, avis de travaux ouvert avant le geste et refermé par un trap EXIT posé avant.

✅ Ce que l'essai PROUVE : le lien remonte seul après une rupture réelle, sans redémarrage du bot (le processus a survécu, mesuré par son etime), et server_sid vaut toujours 003 — l'écrasement a cessé.

⚠⚠ CE QU'IL NE PROUVE PAS, ET IL FAUT LE DIRE : il n'a PAS emprunté le chemin corrigé. Le serveur a fermé par EOF, pas par ERROR. Or reconnect_by_id — la procédure qui oubliait le SID — n'est armée que par la branche ERROR de on_read. C'est scan_pass §2 qui a rattrapé, et celui-là a toujours lu server_sid. Ce scénario-ci fonctionnait donc probablement déjà avant le correctif.

⚠ C'est le piège « le banc n'emprunte que la branche saine », refait en réel, sur la production. Trois bancs de lien du dépôt tombent déjà dedans en passant le SID explicitement. Un essai réel n'en est pas exempt : il faut choisir sa rupture, pas seulement en provoquer une.

🧪 SECOND CONSTAT — 18/08/2026, rupture NATURELLE par Ping timeout

Aucun geste, aucun essai provoqué. Le lien est tombé vingt fois dans la journée, et quinze de ces ruptures portent un timer drift à la même seconde — le gel de WSL du point 15. Ces ruptures-là ferment par ERROR, pas par EOF : c'est la branche qui arme reconnect_by_id, celle que le premier essai n'avait pas empruntée.

✅ Ce que ça prouve : sur la branche ERROR, reconnect_by_id lit server_sid en base et le transmet. Treize reconnexions par ce chemin dans la journée, toutes avec SID configuré=003, et server_sid vaut toujours 003 en base après les vingt ruptures. Le constat qui manquait est pris.

⚠⚠ LE CONSTAT NÉGATIF QU'IL NE FAUT PAS PRENDRE — la cible n'existe plus. Chercher SID auto-attribué au journal ne prouve rien : ce message a été retiré du code par le correctif lui-même, remplacé par « aucun SID en base — attribué » et « SID « X » INVALIDE pour le dialecte — REMPLACÉ par Y ». Son absence était donc acquise d'avance. Ce sont ces deux motifs-là qu'il faut chercher — zéro occurrence le 18/08. La preuve qui porte reste la positive : SID configuré=003 écrit treize fois.

⚠ CE QUE L'ÉPISODE A RÉVÉLÉ EN PLUS : les deux chemins courent une course. reconnect_by_id est armé à 30 s par la branche ERROR, et scan_pass repasse dans le même intervalle. Cinq fois sur vingt, scan_pass a gagné (« auto-connect déclenché par scan ») et reconnect_by_id s'est effacé derrière sa garde — « [id=1] déjà reconnecté, ignoré ». Rien n'est cassé : les deux passent 003, et le doublon est correctement rejeté. Mais le chemin emprunté n'est pas déterministe — il faut lire le journal pour savoir lequel a agi, et c'est précisément ce qui avait rendu le premier essai illisible.

⏪ CE QUI SUIT EST L'ÉTAT D'AVANT LA FERMETURE — PÉRIMÉ, gardé pour la trace. Le critère décrit ci-dessous a été tenu le 24/08/2026 — voir le constat en tête de point. Le second item — voir echec_burst agir et l'alerte partir — a été pris entre 17:52:45 et 17:55:24 sur la production, avec ses quatre traces. ⚠ Ne pas le relire comme du travail à faire. Un encadré « Pour fermer » périmé sous un titre ✅ est exactement ce qui fait rouvrir un point déjà clos.

Pour fermer — il reste un constat :

1. ✅ Une rupture qui produit un ERROR, pas un EOF — PRIS le 18/08/2026, voir le second constat ci-dessus. Vingt ruptures naturelles, treize passages par reconnect_by_id, SID configuré=003 à chaque fois.
2. Voir echec_burst agir et l'alerte partir. Un SID volontairement faux en base ferait refuser le lien : socket_state='error', last_error renseigné, rejeu toutes les 30 s, alerte au troisième. ⚠ Coupe les services ~90 s — demander l'accord, et poser la remise à 003 dans un trap EXIT AVANT.

⚠ Ce banc ne voit pas une clause SQL qui vide le résultat — mesuré : un WHERE 1=0 ajouté à la requête de next_free_sid le laisse entièrement vert. Son talon de base n'est pas MySQL et ne le sera pas. C'est écrit dans le banc lui-même, pour que personne ne lise ce vert comme une preuve qu'il ne donne pas.

36. ✅ Six boucles pouvaient encore s'arrêter en silence — fermé le 17/08/2026

Les six sont traitées, et un banc les garde. IriX/tests/test-boucles.tcl dérive les mécanismes auto-réarmés et exige qu'aucun appel ne précède le réarmement hors d'un catch. ⚠ Il a rougi sur quatre d'entre elles avant tout correctif — le gardien d'abord, comme le reste de la journée.

⚠ Sa première version n'en voyait que DEUX sur treize : la plupart des boucles ne posent pas leur propre minuteur, elles appellent un planificateur. La table « planificateur → cible » est désormais dérivée du code, pas énumérée — elle ne se périmera pas au premier ajout.

⚠ auto::pub_send a demandé un traitement différent, et le correctif habituel y aurait créé un défaut VISIBLE : son réarmement est conditionnel à dessein — un salon quitté, ou dont la publication est éteinte, ne doit pas se replanifier. Seul ce qui suit les gardes est protégé. Exception assumée : si la lecture du réglage échoue, on ne sait pas s'il faut s'arrêter, et « je ne sais pas » ne vaut pas arrêt définitif — on réessaie.

⚠ Deux bancs ont rougi (test-bindtime.tcl, test-auth.tcl) : scinder une procédure déplace ce qu'ils cherchent. Les deux exigent maintenant la chaîne entière — l'enveloppe appelle le travail, et le réarmement est dans l'enveloppe.

⚠ Ce que le banc n'attrape pas, écrit dans son en-tête : db_topic_check passe par un timer_id stocké et lui échappe ; elle a été corrigée à la main. Il ne suit pas non plus les appels en profondeur.

36bis. ✅ (historique) Le recensement qui a mené au point 36 — CONSTATÉ FERMÉ le 30/08/2026, et il annonçait FAUX dans les deux sens

⚠⚠ Ce que la mesure du 30/08/2026 a trouvé — le point était périmé

Les six boucles annoncées « restantes » sont TOUTES traitées, et depuis le 17/08 : chacune porte en commentaire la mention datée de son correctif. L'inventaire dérivé du code donne treize mécanismes auto-réarmés, treize protégés, zéro non protégé. C'est le point 36, marqué fermé, qui décrivait le code réel ; c'est ce point-ci, laissé « historique », qui a continué d'annoncer six chantiers ouverts pendant treize jours. 📌 Un point « historique » n'est pas un point inoffensif : il se lit comme les autres, et personne ne pense à le remesurer.

⚠ Deux boucles ne sont nommées dans AUCUNE de ses deux listes — ia::scan_inbox et ulines::auto::scan, noyées dans le « treize ». Elles étaient protégées avant le 17/08 ; le lecteur du registre ne pouvait pas savoir qu'elles existaient.

⚠⚠ Mais il SOUS-disait aussi, et c'est là qu'étaient les vrais défauts

Son affirmation « chatalerte::schedule est le seul planificateur qui ne tue pas son minuteur précédent » est fausse. Ils étaient trois, et ce sont exactement les trois qui posent par after — la file de Tcl, sur laquelle ni killtimer ni killutimer n'ont la moindre prise :

Planificateur	Ce qui manquait	Amorçages
chatalerte::schedule	aucun tueur, aucune garde	1
raw_log_purge_schedule	aucun tueur, aucune garde	2 — db_init et start_system
topic_schedule	une garde, défaite par le rechargement	1

⚠ Le mécanisme d'accumulation est complet et mesuré : system_ready et topic_started vivent dans IriX-src.conf, que tout .rehash re-source et remet à vide. La garde d'amorçage rouvre donc, une seconde chaîne démarre, et l'ancienne n'est pas annulée — personne n'a son identifiant. Pour chatalerte, deux chaînes qui se croisent annoncent deux fois la même alerte, annoncee='oui' n'étant écrit qu'après l'envoi. Un .restart, lui, repart d'un interpréteur neuf et n'accumule rien.

⚠ Et deux killutimer étaient inopérants sans le dire — irix-oper.tcl et modes_du_bot passaient un nom de procédure là où un identifiant de minuteur est attendu. L'appel levait, le catch avalait, le minuteur survivait. Un catch autour d'un appel faux le rend indistinguable d'un appel juste.

Ce qui a été fait, et pourquoi ainsi

::soc::after_remplacer — une seule procédure, qui balaie la file réelle avant de poser. ⚠ Elle ne garde pas d'identifiant en variable, et c'est la leçon déjà payée par rehash_schedule : une variable vit dans IriX-src.conf, que le rechargement réinitialise — l'identifiant est perdu et le minuteur devient orphelin. La file, elle, ne ment pas. ⚠ Les deux killutimer inopérants prennent le balayage en ligne : ils s'exécutent au CHARGEMENT du fichier, avant que cette procédure n'existe.

⚠⚠ Le banc, et le trou qu'il avait

Aucun banc ne gardait la règle « un planificateur retire avant de poser », et test-minuteurs.tcl ignorait entièrement la file after : sa liste de planificateurs exige un crochet devant timer. Les trois fautifs lui étaient donc invisibles — et à test-boucles.tcl aussi, qui garde le défaut symétrique (une boucle ne doit pas MOURIR ; celles-ci se MULTIPLIAIENT).

⚠ La règle neuve est étroite, et ça s'est mesuré avant de l'écrire. « Toute procédure qui pose un after doit retirer » dénonçait onze procédures justes — on_join, on_part, evt_quit, les sockets des ULines — qui posent un délai à un coup, lequel n'a rien à retirer. On ne garde donc que l'auto-réarmement. 📌 Un banc qui accuse onze innocents pour deux coupables finit ignoré, et c'est le coupable qui gagne.

⚠⚠ Et la règle a été VERTE À VIDE à sa première exécution : en corrigeant les trois planificateurs, on leur avait retiré le after littéral qu'elle cherchait — elle ne voyait plus aucune boucle. C'est le plancher qui l'a dit, pas le constat. 📌 Une règle écrite sur la FORME fautive meurt avec elle ; il faut qu'elle reconnaisse aussi la forme CORRIGÉE.

Pour fermer

✅ Constaté fermé le 30/08/2026. Les treize boucles sont protégées (mesuré, pas lu) ; les trois planificateurs sans tueur sont corrigés ; les deux killutimer inopérants aussi ; la règle « retire avant de poser » est gardée par test-minuteurs.tcl, cinq mutations rejouées et toutes attrapées. ⚠ Rien n'est en service : IriX charge ces fichiers au démarrage — il faut un .rehash ou un redémarrage, donc l'accord de SerVuS. 📌 Un .rehash suffit et se répare seul : le code neuf balaiera les chaînes anciennes au premier cycle.

Le recensement d'origine, tel qu'il était écrit

Mesuré le 17/08/2026, en dérivant tous les mécanismes auto-réarmés de IriX/cmds/. Treize boucles se replanifient elles-mêmes ; le danger est qu'un réarmement manqué les arrête définitivement — rien ne casse, tout se fige, et le panel continue d'afficher le dernier état comme s'il était frais.

Traité ce jour : botnet::cycle (les deux chemins + l'armement), alerte::cycle_courriels et son armement, ia::bridge::scan (la modération automatique), admin::scan (la boucle-mère, qui porte une dizaine de sous-systèmes).

Restent six, toutes de la même forme — réarmement en dernière instruction, hors de tout catch :

⚠ Un défaut distinct, à ne pas confondre : chatalerte::schedule est le seul planificateur du dépôt qui ne tue pas son minuteur précédent. Un second amorçage crée donc une boucle parallèle, et les annonces partent en double — exactement ce que rehash_schedule documente et évite ailleurs.

Pour fermer : appliquer le motif désormais employé quatre fois — le travail dans une procédure à part, appelée sous catch, et le réarmement après, donc toujours atteint. ⚠ Et faire suivre les bancs : découper une procédure déplace ce qu'ils cherchent — test-bindtime.tcl a rougi pour cette raison, et il exige maintenant la chaîne entière (l'enveloppe appelle le travail, et le réarmement est dans l'enveloppe, pas dans le travail).

⚠ Les bind time ne courent PAS ce risque et n'ont pas à être traités : Eggdrop les rappelle depuis sa propre table. Leur mode de panne est l'inverse — un passage manqué n'est jamais rejoué — et il est déjà couvert par la discipline des lignes # RATTRAPAGE:.

35. 🟡 La file d'installation des robots n'avait aucun producteur — BRANCHÉE le 23/08/2026, UN ROBOT EST NÉ le 25/08, et il est né INFIRME

Le 25/08/2026 — le robot est né, la chaîne marche, et elle a montré deux trous

✅ SerVuS a cliqué, et la chaîne entière a fonctionné. Demande #2 déposée à 18:45:25, traitée à 18:46:38 : répertoire choisi, port telnet déduit du disque (3345, les quatre autres occupant 3341-3344), Eggdrop lancé sous une unité transitoire, statut installing écrit. Ce que ce point attendait — « voir un robot en naître » — est constaté.

⚠⚠ MAIS IL EST NÉ SANS SALON GARDIEN ET SANS NOM DE BOTNET. set botnet-nick et channel add #!Bots! avaient été posés à la main sur overop-h/-q/-s/-t le 15/08, et reportés dans aucun des deux écrivains du overop.conf. OverOp-A est le premier robot né du modèle seul : il est arrivé vivant, connecté, et invisible du parc — ::soc::botreg::salons_attendus compte par le salon gardien. ➜ Corrigé dans les deux écrivains, avec six constats de non-divergence dans test-botpool.php. Le robot a été retiré.

⚠⚠ ET LA FENÊTRE DU hello EST RESTÉE OUVERTE 45 MINUTES SUR UN RÉSEAU PUBLIC. Le robot attendait /msg OverOp-A hello, qui n'est jamais venu. Pendant tout ce temps, le premier venu qui tapait ce mot devenait propriétaire — et la ligne insérée dans le userfile ne se défait pas en restaurant une sauvegarde.

⚠⚠ CE N'EST PAS UNE HYPOTHÈSE : C'EST DÉJÀ ARRIVÉ TROIS FOIS. Mesuré le 25/08 — OverOp-H appartenait à ClaudeEssai, OverOp-Q et OverOp-S à ClaudeTest. Le handle SerVuS n'existait dans aucun des trois userfiles. ⚠ set owner "SerVuS" y figurait pourtant : cette ligne est inerte — Eggdrop y désigne des propriétaires parmi les handles existants, il n'en crée jamais.

✅ Parc nettoyé le 25/08, sur décision de SerVuS : OverOp-H, -Q, -S et -A retirés — unités, dossiers, IriX_botreg_pooshy, IriX_botnet, la file. Restent IriX et OverOp-T, le seul robot qui appartienne vraiment à SerVuS. ⚠ IriX_botreg était vide : aucun prêt n'a été cassé. Sauvegarde complète prise avant, dans /home/servus/sauvegarde-robots-*.

⚠ Reste, et il faudra arrêter IriX à froid : l'entrée OverOp-H en +b dans IriX/runtime/IriX.user, avec son --PASS2 en clair. À grouper avec le chantier des secrets botnet aléatoires.

⚠⚠ RENVERSEMENT DE DOCTRINE, DÉCIDÉ PAR SERVUS LE 25/08/2026 — le hello s'automatisera. Le projet écrivait le contraire à quatre endroits : Tools/overop-pool.php (« LE HELLO NE S'AUTOMATISE PAS, et c'est voulu : il désigne un PROPRIÉTAIRE »), PRET-ROBOT.md, IRIX.md, Web/inc/botnet.php.

La raison du renversement, et elle est mesurée : la doctrine protégeait contre « un compte se crée tout seul ». Appliquée, elle a produit trois robots appartenant à des comptes d'essai et une fenêtre de course ouverte trois quarts d'heure sur un réseau public. ⚠ Et ce qui est proposé ne crée aucun compte : il recopie un propriétaire qui existe déjà dans IriX.user, avec son empreinte. Ce n'est pas la même chose.

⚠ La fenêtre ne sera pas raccourcie, elle sera SUPPRIMÉE. Eggdrop n'ouvre hello que tant qu'aucun handle ne porte le flag n (learn-users vaut son défaut, 0). Un userfile écrit avant le premier démarrage ferme la porte dès la première seconde. Faire envoyer le hello par IriX l'aurait seulement raccourcie — et l'aurait laissée dépendre d'IriX étant en ligne.

⚠ Le hash est transférable, c'est vérifié : le modèle charge pbkdf2, « celui que charge déjà IriX sur cette machine ». La ligne SerVuS - jlmnoptx d'IriX.user se recopie telle quelle.

⚠⚠ MAIS LE SECRET DU LIEN BOTNET, LUI, NE PEUT PAS ÊTRE HACHÉ — et ce n'est pas une négligence, c'est le protocole : le défi-réponse d'Eggdrop exige le clair des deux côtés. C'est pourquoi IriX.user porte des --PASS2 en clair. ➜ Le correctif n'est pas de le cacher, mais de le rendre aléatoire et unique par lien — aujourd'hui ce sont deux mots de dictionnaire.

✅✅ (1) L'APPROPRIATION AUTOMATIQUE EST FAITE ET CONSTATÉE — 25/08/2026 à 20:45. Le poseur recopie le propriétaire d'IriX.user dans un userfile neuf avant le premier démarrage. Le journal de la pose réelle :

20:44:59  Demande #2 : OverOp-A (déposée par SerVuS)
20:44:59    propriétaire recopié sans « hello » : SerVuS — 1 salon(s)
20:44:59    userfile présent — le robot a un propriétaire.
20:45:05    déclaré au parc (origine « auto »)
20:45:05  ✅ OverOp-A est sous systemd et actif.
20:45:14  OverOp-A joined #!Bots!
20:45:28  parc : OverOp-A : online

Six secondes, et aucune unité transitoire créée — le cercle que systemd-run -m rompait n'existe plus, donc la pose tient en un seul temps. ⚠ Constaté aussi : un seul handle porte le flag n dans le userfile produit, donc hello refuse dès la première seconde. La fenêtre n'est pas raccourcie, elle n'existe plus.

⚠ Le repli est conservé et il compte : sans propriétaire à recopier — un tiers qui vient d'installer le projet —, botpool_proprietaire() rend null et l'ancien chemin avec hello reprend. C'est la part de la doctrine d'origine qui survit : recopier oui, inventer jamais.

⚠⚠ ET UN DÉFAUT DÉCOUVERT EN ÉPROUVANT — il vaut pour le PANEL aussi. IriX_botreg_pool porte une contrainte d'unicité uk_name : un robot retiré ne peut pas être redemandé sous le même nom, sa ligne close occupant la place. Le dépôt a échoué sur Duplicate entry 'OverOp-A' for key 'uk_name' — et le bouton du panel se heurterait exactement au même refus, sans que rien ne l'explique à l'exploitant. ➜ À traiter avec le morceau (3) : ce que « supprimer un robot » veut dire doit inclure sa ligne de file.

⚠ (3) — la moitié BASE est faite le 26/08/2026, et elle DIT ce qu'elle ne fait pas

Le bouton « Retirer » existe dans « Robots de service — déclaré contre observé », au niveau propriétaire — un cran au-dessus de poser, parce que poser est réversible et retirer ne l'est pas. botpool_retirer() défait les endroits en BASE, dans cet ordre : les mandats passent à fini (ils ne sont jamais effacés — un mandat est la trace de qui a accordé quoi), la présence (opmybot), le pair de botnet (par botnet_remove(), qui porte déjà son refus « le lien est monté »), le parc (pooshy), et enfin la ligne close de la file — celle de uk_name, qui réservait le nom pour toujours. ⚠⚠ LE CHIFFRE EST RETIRÉ le 27/08/2026, et c'est une correction, pas un allègement. Cette phrase annonçait « quatre des sept endroits » — puis en énumérait cinq, dans la même phrase. Le docbloc de la fonction faisait la même chose, et appelait la ligne de file « le septième endroit » d'un total qui en compte huit (cinq en base, trois système). Un compte écrit à la main ne survit pas à la séance qui l'écrit : on énumère, on ne dénombre plus. Un banc exige désormais que chaque table réellement écrite soit nommée dans le docbloc, et qu'aucun compte n'y revienne. ⚠ Les lignes pending et installing sont épargnées : les effacer laisserait l'exécutant poser un robot que plus rien n'attend.

⚠⚠ ET LES TROIS AUTRES SONT NOMMÉS DANS LE MESSAGE, un par un, au lieu d'être tus. C'est le cœur de ce qui a été écrit : un retrait qui se dirait complet refabriquerait exactement le résidu qu'on mesure aujourd'hui.

Ce que la mesure du 26/08 a montré — OverOp-H, retiré à la main le 25/08 : plus d'unité, plus de dossier, mais son entrée +b est toujours dans IriX.user (ligne 2) et un mandat #accueil suspendu (id 14) pointe encore sur lui. Et OverOp-A, né le 25/08, est dans le parc et sur #!Bots! mais n'a aucune ligne dans IriX_botnet — le robot « infirme » du morceau (2), pris sur le fait.

Éprouvé : Web/tests/test-botpool-retrait.php, 34 constats, plus une passe de mutation à la main sur 11 blessures — aucun trou. Les 57 bancs du site restent au vert.

⚠ CE QUI RESTE, et pourquoi ce n'est PAS un oubli :

Endroit	Pourquoi le site ne le fait pas
l'unité overop@<lettre>.service	systemctl stop/disable overop@… n'est pas dans sudo -n — mesuré
le dossier /home/servus/overop-<lettre>	Tools/overop-pool.php pose lui-même la doctrine : « un rm -rf lancé par un service root sur un chemin construit à partir de la base est un risque plus grand que ce qu'il évite »
l'entrée +b d'IriX.user	Eggdrop réécrit son userfile ; toute édition à chaud est perdue sans un mot. Exige d'arrêter IriX

⚠⚠ LA DÉCISION QUI ATTEND SerVuS. Le registre disait « étendre Config/sudoers.d/overtchat-services aux seules unités overop@* ». Le fichier n'a pas été touché, et c'est délibéré : son en-tête pose deux règles écrites que cette extension enfreindrait — « Pas de joker » et « Ni enable, ni disable, ni mask, ni edit : le panel pilote des services, il ne reconfigure pas la machine ». Étendre demande donc de changer une doctrine, pas d'ajouter une ligne.

Si SerVuS le veut, la forme la plus étroite est overop@?.service — un seul caractère, ce qui correspond exactement à la garde botpool_lettre() (OverOp- suivi d'UNE lettre) et refuse overop@ab.service comme overop@../x.service. Sinon, les trois gestes restent ceux de l'exploitant, et le message les donne déjà écrits, prêts à recopier.

✅✅ TRANCHÉ ET BRANCHÉ LE 23/08/2026 : un BOUTON au panel, pas un déclencheur automatique. SerVuS a choisi que le parc ne grandisse jamais sans quelqu'un devant l'écran — ce qui importe, puisque l'exécutant pose de vrais Eggdrop. Grade requis : Admin, le même que décider un prêt.

⚠ Le motif suivi est celui des trois autres files du projet, qui marchent : modq, botreq, chanq. Le demandeur dépose une ligne, l'exécutant vérifie et agit, un statut porte la vérité. botreg_pool était la seule des quatre dont personne ne remplissait la file.

⚠⚠ ET LE MIROIR PHP N'AVAIT QUE DEUX GARDE-FOUS SUR QUATRE — trouvé en branchant, pas en relisant. Il connaissait plafond et echecs, ignorait encours et trop_tot. Personne ne l'avait vu parce qu'il ne servait qu'à AFFICHER un avertissement : une moitié de garde-fou qui n'a jamais rien gardé ne se remarque pas. encours est le plus important pour un bouton — sans lui, deux clics déposent deux lignes et deux robots naissent.

⚠⚠ UN BANC A ATTRAPÉ UNE ERREUR DE MA MAIN : j'avais supposé une colonne nick qui s'appelle name. test-colonnes.php croise chaque colonne citée dans le PHP avec le schéma réel, et il a rougi. Sans lui, la requête aurait levé en production au premier clic, dans un try qui l'aurait avalée en un message poli et faux.

✅ Les trois affirmations d'une chaîne automatique inexistante sont retirées : le tableau de ce cahier, l'en-tête de Tools/overop-pool.php, le commentaire de l'unité systemd, et le texte affiché par la page du panel. ⚠ L'argument de la page — « deux chemins d'écriture donneraient deux façons de poser la même décision » — est conservé, parce qu'il reste juste : la file n'en avait aucun. Le bouton ne crée pas un second chemin, il crée le premier.

⚠ Trois corrections à l'énoncé ci-dessous, mesurées le 23/08 : le §7.6 de PRET-ROBOT.md avait déjà été amendé le 17/08 (le manque était ailleurs) · le comptage est de six occurrences et cinq commits, pas quatre · et places_restantes n'est pas « la mesure qui devrait déclencher » mais un doublon Tcl mort de botreg_places(), bien vivante côté PHP.

État : 31 constats à test-botpool-panel.php, 14 mutations, 14 attrapées — dont la divergence PHP/Tcl dans les deux sens. En 4.19.47.

Trouvé le 17/08/2026 en instruisant la « branche morte » botreg/pool-arrete du point 24. Le défaut est bien plus large que l'alerte qui l'a fait remarquer.

::soc::botreg::demander_robot (IriX/cmds/irix-botreg.tcl) détient les deux seuls INSERT INTO …_botreg_pool de tout le dépôt — et elle n'a aucun appelant en production. Quatre occurrences dans le dépôt entier : sa définition, un commentaire, un banc, et le registre.

⚠⚠ Donc la file du pool n'a aucun producteur. Aucun code, Tcl ou PHP, ne sait y écrire une ligne. Et ce n'est pas un reste d'ancien code : git log -S rend quatre commits, tous en ajout, aucune ligne d'appel supprimée. Elle n'a jamais été appelée, à aucun moment de l'histoire.

La cascade, mesurée :

⚠ Conséquence à retenir : la ligne du pool qui a servi à poser OverOp-T les 10-11/08 n'a pu être écrite qu'à la main — aucun code du dépôt ne sait le faire.

⚠⚠ ET C'EST L'ASYMÉTRIE QUI A TROMPÉ. Le registre a identifié puis comblé la moitié consommatrice le 09/08, et déclaré « la POSE est close ». Personne n'a remarqué que la moitié productrice n'était pas branchée : on a vérifié que le repas serait mangé, jamais qu'il serait cuisiné. C'est le motif « à la jointure » à son échelle la plus large — du code juste des deux côtés, et rien au milieu.

⚠ Et la documentation l'affirme au présent. Markdown/PRET-ROBOT.md §7.6 range « constate le seuil franchi, engendre le nom, dépose une ligne pending » dans la colonne d'IriX, coche l'exécutant comme livré, et ne marque aucun manque du côté demandeur.

1. brancher — un balayage appelle places_restantes puis demander_robot ;
2. rendre le geste explicite — un bouton au panel, qui dépose la ligne ;
3. assumer le manuel — et alors le dire partout, en retirant de PRET-ROBOT.md ce qui décrit une chaîne automatique qui n'existe pas.

⚠ Ne pas brancher sans le banc de bout en bout : le consommateur pose des robots pour de vrai, et un déclencheur trop bavard remplirait le parc.

34. ✅ Une campagne du serveur était ROUGE sans que personne l'entende — fermé le 17/08/2026

Mesuré le 17/08/2026. Servers/overtchat-hybrid/tests/run-tests.sh, campagne 14/17 (test-irix.py, « le vrai code de service se lie au serveur ») : 9 réussites, 13 échecs. Le lien s'établit, le burst se clôt, mais ::soc::ulines::auto::inject_uids lève une erreur Tcl en appelant inject_uid_from_def, et aucun des cinq pseudo-clients n'est injecté (def=0 sql=0). Tout ce qui suit tombe en cascade.

⚠ CE N'EST PAS UNE RÉGRESSION, et c'est ce qui rend le point grave. Vérifié en remettant le s_serv.c du commit précédent et en recompilant : la campagne échoue à l'identique. Le défaut est antérieur, et personne ne sait de quand.

⚠⚠ POURQUOI IL DORMAIT — une neuvième façon pour un banc de mentir. Les huit connues supposent un banc vert à tort. Celui-ci est franchement rouge : il dit la vérité, et personne ne l'entend. Tools/bancs.sh range run-tests.sh parmi les bancs « qui exigent un serveur en face » et le déclare non lancé — alors qu'il n'exige rien d'autre que le binaire, présent. Le lanceur ordinaire annonce donc « 81 bancs au vert » en toute honnêteté, au-dessus d'une campagne rouge qu'il a lui-même écartée.

⚠ Ne pas conclure de la production : les cinq services sont bien présents en service (mesurés dans ${t}_online, is_svc='oui'). Le défaut est donc dans ce que le banc monte, pas nécessairement dans IriX — mais un banc dont on ne sait pas dire s'il accuse le code ou lui-même ne protège rien.

✅ Constaté fermé le 17/08/2026 — et le coupable n'était pas IriX

La cause, lue dans la trace complète : commande inconnue : validchan. C'est une commande d'Eggdrop, et le banc exécute le code d'IriX sous tclsh, qui ne la connaît pas. desarmer_flood_join l'appelle, et cet appel a été ajouté au chemin de repli bien après l'écriture du banc. Le code d'IriX est juste — en service, les cinq services sont bien présents. C'est le banc qui était incomplet.

⚠ La trace n'était lisible nulle part, et c'était le vrai obstacle. Le banc python affichait banc.read()[-1500:] : une tranche de FIN, alors que le nom de la commande manquante est au DÉBUT. Le banc possédait déjà _extrait(), écrit pour ce problème exact — il n'était pas appliqué ici. Le message complet vivait dans irix.out, au fond d'un mkdtemp que personne n'ouvre.

Les trois correctifs, et le troisième est le plus important :

1. irix-link.tcl — talons validchan et channel, avec leur limite écrite : ils ne prouvent rien d'Eggdrop, cette campagne éprouve le protocole.
2. irix-link.tcl + test-irix.py — toute commande sans talon s'annonce désormais sur une ligne MANQUE|, et un constat dédié la nomme au lieu de treize échecs muets. Placé avant le verdict, qu'il explique.
3. ⚠⚠ Tools/bancs.sh — le classement était faux. run-tests.sh était rangé parmi les bancs « qui exigent un serveur en face » : c'est inexact, il démarre les siens. Il n'exige que le binaire compilé. Il a désormais sa propre section et tourne par défaut là où le binaire existe ; là où il manque, il est nommé avec la raison plutôt que compté en échec.

Constaté : Tools/bancs.sh rend 82 bancs au vert (81 + la campagne), et run-tests.sh 17 campagnes, 0 échec. Deux mutations éprouvées : le binaire retiré → « non lancé — binaire absent », sans échec compté ; le talon retiré → le constat « aucune commande d'Eggdrop ne manque à ce banc » rougit en tête.

⚠ Piège rencontré en chemin, et il fait perdre du temps : une campagne interrompue laisse un serveur d'essai orphelin qui garde son port, et fait échouer les campagnes suivantes — l'échec accuse alors le code. Les reconnaître à leur configuration dans /tmp/overtchat-* ; ⚠ jamais un pkill large, la production tourne le même binaire.

⚠ Et une seconde fois le même piège que le 16/08 : lancées depuis /mnt/c, ces campagnes utilisent le build/ du clone Windows — daté du 7 août. Deux campagnes accusaient mes bancs pour un binaire périmé. Une mesure prise au mauvais endroit est fausse.

33. ✅ IriX_sessions.ip mentait sur les visiteurs du webchat — corrigé ET constaté en service le 17/08/2026

Mesuré le 16/08/2026 en base de production. Pour un visiteur du webchat, le serveur IRC voit son adresse réelle et l'écrit dans hostname ; la colonne ip, elle, reçoit 127.0.0.1.

26 lignes portent ce désaccord. Les valeurs distinctes de la colonne sont seulement trois : vide (515, les pseudo-clients de services), 127.0.0.1 (237) et 192.168.1.254 (15) — aucune adresse publique n'y a jamais figuré.

⚠⚠ CE DÉFAUT EN A FABRIQUÉ UN AUTRE, SUR LE PAPIER. Qui mesure le plafond de connexions depuis la base conclut que tous les visiteurs sont sur la boucle locale, donc qu'ils partagent un compteur. C'est exactement ce qu'affirmait le point 28, et c'était faux : le journal du serveur écrit au même instant « Connexion de Paul [webchat@192.168.1.254] … [clients] ». Une colonne fausse ne casse rien de visible — elle fait écrire des diagnostics faux, qui coûtent ensuite des séances entières.

Le module concerné est IriX/cmds/irix-online.tcl (decode_ip, on_uid), qui porte déjà une note sur un défaut voisin de la même colonne dans ${t}_online — la colonne y avait contenu :Sonde.

Pour fermer : trouver qui ÉCRIT la colonne, et non qui la lit — c'est la méthode des cinq portes de l'identification. Puis un banc qui compare, sur une même session, ce que le serveur journalise et ce que la base enregistre. ⚠ Ne pas « corriger » en recopiant hostname dans ip : les deux colonnes ne disent pas la même chose, hostname peut porter un nom résolu ou un masque, et c'est justement ce genre de raccourci qui a produit le défaut.

Ce qui a été trouvé le 17/08/2026 — et ce n'était pas dans IriX

La colonne n'était pas écrite par IriX : elle recopie fidèlement le champ IP de la commande UID. C'est le serveur qui annonçait 127.0.0.1.

adopter_ip_relayee() (Servers/overtchat-hybrid/src/websocket.c) pose l'adresse relayée dans les trois champs textuels — sockhost, realhost, host — et jamais dans conn->ip, la sockaddr figée à l'accept(), qui reste celle du relais. Or encode_ip() (Servers/overtchat-hybrid/src/s_serv.c), seule à produire ce champ, lisait la sockaddr en priorité pour tout client local. D'où le désaccord exact du tableau ci-dessus : l'hôte vrai, l'adresse fausse.

Mesures qui ont tranché, et qui valent mieux qu'une relecture :

sockhost n'est jamais un nom résolu : c'est la forme textuelle de l'adresse, et celle que le serveur tient pour vraie partout ailleurs. Le champ IP de UID était le seul endroit à en dire une autre. Correctif : encode_ip lit sockhost d'abord, conn->ip en repli. Un seul lecteur touché, aucun autre comportement déplacé.

Banc : Servers/overtchat-hybrid/tests/test-forward.py monte désormais un lien de services et lit la commande UID au fil de l'eau (+5 constats, 12 au total). ⚠ Ses sept constats d'origine restaient VERTS sur le code fautif — ils ne lisaient que ce que le serveur dit AU CLIENT (l'hôte du 302), jamais ce qu'il dit aux services. C'était l'angle mort exact. Passe de mutation faite : la garde annulée, deux constats rougissent en rendant 127.0.0.1.

✅ Constaté fermé en production le 17/08/2026 à 10:04:22

Le binaire a été recompilé et mis en service (redémarrage autorisé par SerVuS), puis une connexion de contrôle a emprunté le chemin exact du webchat — 127.0.0.1:8000, TLS, en-tête X-Forwarded-For — sans parler dans aucun salon. Ce qu'IriX a écrit :

Les deux colonnes concordent, et c'est la première adresse non locale que cette colonne ait jamais portée : ses valeurs distinctes passent de trois à quatre, la quatrième ne comptant que cette ligne.

⚠ Effet de bord constaté, et il n'était pas prévu : ${t}_online portait ip et host vides sur ses dix lignes avant le redémarrage — le repli de session_open, qui va y chercher une adresse manquante, ne pouvait donc rien compléter. Le reflet reconstruit les renseigne. Deux mécanismes se réparent d'un seul correctif, ce qui veut aussi dire que le second n'était éprouvé par personne.

⚠ Les 26 lignes déjà en base restent fausses : c'est un historique, on ne le réécrit pas. Elles se lisent avec la date du correctif en tête.

31. ✅ Dix-huit encarts du panel se rendaient NUS — fermé le 17/08/2026

Mesuré le 16/08/2026, en cherchant où afficher l'état de la liste des villes.

Web/inc/layout.php ne lie qu'une seule feuille au panel — app.css, une ligne <link>, aucun @import. Or .note et .stat-card n'y existent pas : elles ne sont déclarées que dans site.css, la feuille du site public.

Les fichiers : Web/pages/alertes.php, botnet.php, chat.php, dashboard.php, eggdrop.php, opers.php, robots.php, et ⚠⚠ Web/inc/alerte.php — le bandeau d'alerte critique affiché sur TOUTES les pages du panel. Un élément dont la classe n'existe pas se rend sans cadre, sans couleur, sans rien qui le distingue du texte courant : l'avertissement le plus grave du panel s'affiche donc comme un paragraphe ordinaire.

⚠⚠ ET SON GARDIEN EST AVEUGLE. Web/tests/test-vues.php existe pour dire « une classe écrite en dur doit exister dans une feuille » — mais il fait foreach (['app.css', 'site.css'] as $f) et concatène les deux avant de chercher. Toute classe déclarée dans l'une passe pour disponible dans l'autre. C'est le défaut que Markdown/WEB.md raconte déjà dans l'autre sens, avec le même angle mort. Même cause pour class="alert error" dans Web/pages/robots.php : .alert.error n'existe pas — seuls ok, err, warn, info —, mais .dot.error fait passer le détecteur au vert.

Pour fermer : rendre le contrôle conscient de la feuille que chaque page charge réellement (le panel app.css, le site site.css), puis reprendre les 21 écritures. ⚠ Le banc doit rougir AVANT la reprise, sinon il ne prouve rien. ⚠ Et ne pas « corriger » en ajoutant site.css au panel : les deux feuilles ont des vocabulaires distincts, et les charger toutes deux ferait entrer dans le panel des règles pensées pour le site public.

✅ Fermé le 17/08/2026 — et le banc a trouvé DEUX défauts de plus

Le banc a été repris d'abord, et il a rougi avant toute correction : 11 classes nues dans 8 fichiers, puis 2 classes composées. Quatre aveuglements distincts ont été levés, pas un :

⚠⚠ Les deux composées étaient inconnues du registre, et l'une n'était pas cosmétique : botnet.php demandait class="form-grid c3" alors que seul .form-grid.c2 est déclaré — la grille se rendait sur une seule colonne. La règle manquante a été ajoutée. robots.php écrivait class="alert error" là où .alert connaît ok, err, warn, info : le frein de capacité s'affichait sans sa couleur, comme une information banale.

⚠ La règle du contrôle composé est DÉRIVÉE : une base est « à modificateurs » si la feuille déclare au moins une règle .base.quelquechose, et un jeton employé avec elle doit exister soit en composition, soit déclaré seul. Cette seconde condition est indispensable — sans elle, .error passait pour disponible en s'appuyant sur .dot.error, une pastille de sept pixels sans rapport.

⚠ Un faux positif rencontré et corrigé : retirer la partie PHP d'un attribut laisse des fragments (class="pill st-…" → st-). Un jeton finissant par un tiret n'est pas une classe ; deux pages justes étaient accusées.

Mutation : un encart repassé à .note fait rougir le banc en nommant le fichier. Reprise : 8 fichiers, 21 écritures, plus 3 ternaires qui rendaient une variante vide — un encart sans couleur ne se distingue pas du texte.

32. ✅ ?p=update était un lien mort au tableau de bord — fermé le 17/08/2026

Mesuré le 16/08/2026. Web/pages/dashboard.php propose la version publiée dans un lien href="?p=update". La route update n'est déclarée ni dans panel_routes() ni dans panel_routes_hors_table() de Web/inc/routes.php. Le repli ramène donc au tableau de bord, sans un mot — on clique, la page se recharge, et rien n'indique que la cible n'existe pas.

C'est le défaut exact que l'en-tête de Web/inc/routes.php raconte pour la page « Protection », reparu sur un href que test-routes.php ne lit pas : ce banc croise nav_items(), panel_routes() et les fichiers de pages/, mais aucun banc ne dérive les href="?p=…" écrits dans les pages.

Pour fermer : d'abord trancher ce que ce lien devait ouvrir — la page de mise à jour n'existe pas, il n'est donc pas sûr qu'elle ait jamais été écrite. Puis ajouter au banc la dérivation des href="?p=…", qui aurait attrapé celui-ci et attraperait les suivants.

✅ Fermé le 17/08/2026 — il n'y avait pas de cible à inventer

⚠ Le nom n'était pas libre. ?p=update est servi — par Web/public/index.php, comme point d'appel JSON du site, celui qu'un client interroge pour savoir s'il a du retard. Un banc qui aurait demandé « ce nom existe-t-il quelque part ? » serait resté vert : la seule question utile est « est-ce une route du PANEL ? ».

Et le panel avait déjà tranché. La pastille « vX disponible » de Web/inc/layout.php, en tête de toutes les pages, pointe vers ?p=statut — une route qui existe. Deux endroits du même panel annonçaient la même chose et menaient ailleurs : il n'y avait qu'une divergence à supprimer.

Le banc : Web/tests/test-routes.php dérive désormais les href="?p=…" de toutes les pages du panel et exige que chaque route soit déclarée. ⚠ Son périmètre s'arrête au panel, et il a fallu le mesurer : la première version balayait tout Web/inc/ et accusait dix liens justes — Web/inc/site.php écrit la navigation du site public, dont les routes ne sont pas celles du panel. C'est la même frontière que celle des deux feuilles de style au point 31, rencontrée le même jour dans un autre outil.

Mutation : le lien mort remis, le banc rougit en rendant dashboard.php → ?p=update.

30. ✅ Un prêt SUSPENDU n'expirait jamais — CONSTATÉ FERMÉ le 23/08/2026, sur une trace vieille de six jours

✅✅ CONSTATÉ FERMÉ LE 23/08/2026 — ET LA PREUVE DORMAIT EN BASE DEPUIS LE 17/08. Il n'y avait rien à fabriquer : le prêt d'essai de #membres (OverOp-S) est le cas du critère, et son histoire est écrite au journal des prêts.

⚠ L'ordre des faits est ce qui prouve : le mandat a traversé l'échéance sans bouger tant que l'ancien code tournait, et il s'est terminé au premier balayage horaire suivant le chargement du correctif. État final : etat = fini, motif_fin = échéance atteinte, updated_at = 17/08 18:00:00.

La ligne au journal du robot, qui a survécu à la rotation :

août 17 18:00:00 SOC MANDAT: prêt de #membres terminé (OverOp-S) — échéance atteinte

⚠⚠ PERSONNE N'AVAIT REGARDÉ. Le point est resté 🟡 six jours alors que son critère était rempli — c'est le symétrique du registre qui sur-dit : il sous-disait. Avant d'aller fabriquer une condition, il faut regarder si elle ne s'est pas déjà produite.

⚠⚠ ET LE CONSTAT A TROUVÉ UN AUTRE DÉFAUT — c'est sa valeur ordinaire dans ce projet. Le journal porte DEUX lignes fin pour cette seule fin (ids 15 et 16, même seconde) : terminer journalise, et balayer journalisait aussi pour marquer expire plutôt que ok. Chacune avait raison séparément. Les expirations d'avant le 14/08 — ids 7 et 9 — n'en ont qu'une. Corrigé en 4.19.48 : balayer passe l'issue au lieu de réécrire.

⚠⚠ ET LE BANC BOUCHONNAIT terminer — deux mutations du vrai code le laissaient vert. C'est le défaut de ce point, une seconde fois : il bouchonnait echus, et sa clause WHERE n'était éprouvée par personne. La parade trouvée alors — charger la VRAIE procédure — est désormais appliquée aux deux. 213 vérifications, 6 mutations, 6 attrapées.

La question qui bloquait avait DEUX réponses

« Quand un prêt passe à suspendu, le robot est-il déjà sorti ? » — c'est elle qui décidait si un IN ('actif','suspendu') suffisait. Mesuré :

· suspension AUTOMATIQUE (suspendre_non_servis) — le robot est absent par définition : c'est son absence prolongée qui déclenche la suspension. Le retrait y sera un ordre sans effet, seulement journalisé. · suspension MANUELLE (MANDATOFF) — le robot RESTE ASSIS DANS LE SALON. Contrairement à MANDATFIN juste à côté, ce chemin n'appelle jamais retirer. C'est là que le balayage manquait vraiment.

Le IN suffit donc, et il répare le second cas. ⚠ fin IS NOT NULL est conservé : un prêt suspendu sans échéance n'est toujours pas concerné. ⚠ Ne pas propager ce IN à non_servis ni _reprendre_un, qui filtrent actif à dessein — leur banc le verrouille.

⚠⚠ ET LE BANC REMPLAÇAIT CE QU'IL PRÉTENDAIT GARDER. test-mandat.tcl bouchonnait echus d'un bout à l'autre (proc … echus {} { return $::ECHUS }). Tout ce qui suit son appel était éprouvé — l'ordre des gestes, les échecs, le journal — et sa clause WHERE, par personne. C'est exactement là que vivait le défaut. Le banc charge désormais la vraie procédure et lit la requête qu'elle envoie : les deux états exigés séparément, et la garde fin IS NOT NULL exigée aussi — l'élargir sans elle terminerait tous les prêts perpétuels au premier passage, un défaut bien pire que celui réparé.

⚠ Reste à constater sur un prêt réel arrivé à échéance en étant suspendu.

Trouvé en attendant une péremption réelle, pas en relisant le code. Le prêt d'essai de #membres (OverOp-S) portait fin = 2026-08-16 18:21:03 et l'état suspendu. Quarante minutes après l'échéance, et après un balayage horaire qui a bien tourné à 19:00:00 :

⚠ Et le mécanisme SAIT le faire : IriX_mandat_log porte deux expirations réussies (fin | expire | échéance atteinte, les 07 et 12/08) — sur des mandats actifs. Ce n'est donc pas une fonction morte, c'est une porte qui ne s'ouvre que dans un cas.

La cause, exacte, dans ::soc::mandat::echus (IriX/cmds/irix-mandat.tcl) :

WHERE etat = 'actif' AND fin IS NOT NULL AND fin <= NOW()

Le balayage ne ramasse que les mandats actif. Un mandat suspendu dont l'échéance est passée n'est jamais sélectionné, donc jamais terminé : il reste indéfiniment en base, ni actif, ni fini.

⚠ Le même ordre de contrôles existe dans le verdict d'une demande d'action : suspendu est rendu avant que l'échéance soit examinée. Là c'est juste — qui demande une action veut savoir qu'elle est suspendue. Ici, non : le balayage ne répond à personne, il fait le ménage.

⚠⚠ LE DOUBLON QUE CE CONSTAT A TROUVÉ — CONSTATÉ FERMÉ À SON TOUR LE 23/08/2026 À 18:00:00. En lisant le journal pour fermer ce point, deux lignes fin sont apparues pour une seule fin : ids 15 (ok) et 16 (expire), même salon, même robot, même seconde. terminer journalise depuis le 14/08, et balayer journalisait encore de son côté pour marquer expire plutôt que ok — chacune avait raison séparément. Corrigé en 4.19.48 : balayer passe l'issue à terminer, qui écrit la ligne unique.

Constaté sur un prêt provoqué, pas sur du code relu. OverOp-T prêté à #!Overtchat! le 23/08 à 17:38:51 par la file IriX_botreq (demande #5, traite_par = essai-doublon-23-08), échéance reculée dans le passé, puis laissé au vrai balayage horaire de 18:00:00.

⚠ Ce constat pouvait rougir, et c'est ce qui lui donne sa valeur : le monde contenait déjà le défaut. Les ids 15 et 16 sont la trace de l'ancien code sur exactement ce chemin — échéance atteinte, balayage horaire.

⚠ Il prouve plus que le compte : l'issue expire est bien remontée jusqu'à terminer. Une seule ligne portant ok aurait été un demi-succès — le doublon parti, mais le journal redevenu incapable de distinguer une fin par le temps d'une fin ordonnée par un opérateur.

⚠ Le seul geste artificiel est le recul de fin en base, pour simuler un jour écoulé. echus, balayer et terminer ont tourné par le vrai bind time - "00 * * * *", sans être touchés. Le robot est réellement entré (OverOp-T … joined #!Overtchat!, observé par IriX, pas l'ordre) et réellement sorti (left #!Overtchat! à 18:00:01). L'essai a été nettoyé : #!Overtchat! retiré à froid du chanfile d'OverOp-T, qui a repris son BOTSTAT sur le seul #!Bots! à 18:07:00.

⚠ Ne pas élargir la clause sans regarder terminer et le retrait du robot : le commentaire de balayer dit « la fin n'a pas pu s'écrire : on ne retire SURTOUT pas le robot ». L'inverse — retirer deux fois un robot déjà sorti — n'a pas été mesuré.

22. ✅✅ L'ASV — CONSTATÉ le 16/08/2026 à 16h, et le constat a trouvé une panne totale

Ouvert puis clos le 16/08/2026. Le point demandait d'ouvrir le chat dans un vrai navigateur. C'est fait, sur le site public. Et le premier essai n'a pas validé l'ASV : il a montré que plus personne ne pouvait entrer sur le chat.

⚠⚠ CE POINT EST LA DÉMONSTRATION DE CE QU'IL AFFIRMAIT. Il disait « 65 constats, 14 mutations, rien de tout cela n'est un constat en service ». Il avait raison au-delà de ce qu'il croyait : le navigateur envoyait son jeton anti-CSRF sous le nom csrf, quand le serveur le lit sous _csrf. Réponse 400 à chaque tentative, depuis la 4.18.0. Cinq constats de test-asv.php étaient au vert pendant toute la panne — ils vérifiaient que la route contient les bons appels, pas qu'elle réponde. Corrigé en 4.18.5, avec trois constats qui croisent désormais le nom lu par csrf_check() et ceux employés par chat.js.

Ce qui a été constaté en service, après correctif :

⚠ Le /WHOIS lui-même n'a pas été lu. Le realname composé par le serveur a été constaté à la source, mais personne n'est entré sur le réseau pour le voir affiché à un tiers — la connexion a été délibérément bloquée pendant l'essai. C'est le seul reliquat, et il ne demande qu'un /WHOIS par SerVuS un jour où il se connecte.

⚠ Le contrôle protège le formulaire, pas le port : qui ouvre le WebSocket lui-même, ou se connecte avec mIRC, ne passe pas par là. C'est cohérent avec l'arbitrage « webchat obligatoire, IRC facultatif », et c'est une limite connue.

⚠ L'ASV n'est pas stocké : il vit le temps de la connexion, dans le realname. La modération n'y a donc accès que si la personne publie. Le tableau de la charte le dit ainsi, et il dit vrai.

23. ✅✅ L'alerte critique — CLOSE le 16/08/2026 à 13:13:53, chemin complet parcouru

⚠ CONSTATÉ FERMÉ, et par la seule preuve que ce point acceptait : le chemin entier, d'un échec réel jusqu'à son rangement.

13:03:14  attempt   OverOp-H   « link » demandé par le panel
13:04:14  error     OverOp-H   le lien n'est toujours pas linked 60s plus tard   (echecs=1)
13:06:14  error     OverOp-H                                                     (echecs=2)
13:09:14  error     OverOp-H                                                     (echecs=3)
13:09:14  [CRIT] ALERTE botnet : Le lien vers OverOp-H ne monte pas
          → IriX-sql.log ET IriX.log, ligne #1 en base, bandeau sur le tableau de bord
13:12:16  courriel envoyé à service.overtchat@free.fr
13:13:53  rangée — la ligne reste (compte, mail_at, acquit_par), le bandeau DISPARAÎT

⚠⚠ ET LE CONSTAT A TROUVÉ UN DÉFAUT QUE RIEN N'AURAIT MONTRÉ. Au premier essai, trois « lier » sur OverOp-H ont donné trois attempt, state=unlinked, echecs=0 et aucune alerte : on pouvait cliquer indéfiniment sans que rien ne le signale. La cause était écrite dans le code et jugée close — « le résultat de link ne prouve rien, Eggdrop rend 1 quand il a LANCÉ la tentative » — c'était juste, et incomplet : personne ne regardait ensuite si elle avait abouti. Corrigé en 4.18.3, et c'est ce correctif qui a permis le constat ci-dessus.

Un mécanisme d'alerte ne se vérifie qu'en le faisant échouer pour de vrai.

24. ✅ L'alerte est branchée sur TREIZE points — chaîne constatée de bout en bout le 17/08/2026

Avancé le 17/08/2026 — les boucles qui mouraient en silence

Remesuré : 13 appels, 7 modules, 11 atteignables, 2 morts — les comptes du registre sont exacts et tiennent. ⚠ Une nuance de plus, non écrite : le catch de l'IA (#7, scan-inbox) est atteignable, mais pas par le motif que son propre commentaire annonce — scan_inbox_pass n'appelle que db_sel/db_exec, qui ne lèvent jamais. Le cas d'usage documenté est mort ; seule une erreur Tcl ailleurs l'atteint.

Ce qui a été corrigé — pas un des treize points, mais la famille voisine que ce point signale : les catch nus. Trois réarmements de boucle avalaient leur échec.

Où	Ce que le silence coûtait
irix-botnet.tcl, cycle	l'observation s'arrête pour de bon ; le panel continue d'afficher le dernier état comme s'il était frais
irix-alerte.tcl, cycle_courriels	⚠⚠ plus aucun courriel d'alerte ne part, et rien ne le dit
irix-alerte.tcl, demarrer_courriels	le cycle ne démarre jamais ; l'appelant croyait le mécanisme en marche

⚠ Les deux catch qui précèdent ce réarmement sont, eux, légitimes : ils protègent UN passage, celui qui échoue est perdu et le suivant aura lieu. Le troisième protège la SUITE — s'il échoue, il n'y a pas de suivant. La distinction est ce qui décide, pas la forme du code.

⚠ Le module d'alerte ne s'alerte pas lui-même : bâtir l'alarme sur ce qu'elle doit surveiller ne prouverait rien. Les deux journaux, et rien d'autre. Ailleurs, erreur et non echec : l'événement n'arrive qu'une fois, un seuil de trois répétitions ne serait jamais atteint.

Banc : test-alerte.tcl fait échouer utimer — seule façon d'atteindre cette branche — et exige le journal. ⚠ Il éprouve aussi le cas nominal, sans quoi le constat passerait au vert sur une boucle qui ne se réarme jamais. Mutation faite : le catch nu remis, deux constats rougissent.

Les deux branches mortes, tranchées le 17/08/2026

chanq/file-illisible — RETIRÉE. Le catch entourait un db_sel, qui ne lève jamais. ⚠ Elle était même doublement inatteignable : db_ensure_table, en tête de la même procédure, est elle aussi bâtie sur db_sel et fait sortir avant. Retirée plutôt que rendue vivante, parce que l'alerte existe déjà plus près de la cause : db_sel lève sql/sel:<message> depuis l'intérieur. Lui ajouter un moyen de distinguer « file vide » de « lecture échouée » — que rien dans le projet ne permet aujourd'hui — aurait bâti un second système d'alarme parallèle au premier pour dire la même chose. ⚠ Ce qu'on perd est la granularité, et c'est écrit dans le code : une alerte moins précise qui part vaut mieux qu'une alerte précise qui ne part jamais.

botreg/pool-arrete — CE N'ÉTAIT PAS UNE BRANCHE MORTE. L'instruction a montré que toute la chaîne productrice du pool n'est branchée nulle part. Le sujet dépasse ce point : voir le point 35, ouvert pour cela.

⚠ Le motif est SYSTÉMIQUE, et le recensement du point le sous-estimait : quatre autres endroits répètent le même catch inatteignable autour d'un db_sel — irix-modq.tcl (deux fois, dont une garde db_scalar), IriX-svc.tcl, et ::soc::admin::scan lui-même. Ceux-là ne portent qu'un putlog, donc un silence et non une fausse promesse ; ils restent à nettoyer. ⚠⚠ Et IriX/tests/test-autoconfig-relu.tcl bouchonne db_sel en la faisant lever — un banc qui éprouve un contrat que la vraie procédure n'offre pas.

Banc test-branche-morte.tcl : il dérive le motif sur tout IriX/cmds/ et exige zéro. ⚠ Il s'éprouve lui-même sur un corpus fabriqué — une vraie branche morte trouvée, et trois catch légitimes (exec, socket, sans alerte) laissés tranquilles. Un détecteur qui ne détecte rien a exactement l'allure d'un projet sain.

✅ L'alerte constatée DE BOUT EN BOUT le 17/08/2026

Panne provoquée en production, avec l'accord de SerVuS, et réversible : chmod a-w sur IriX/logs/archives, plus last_rotate remis à NULL. ⚠ La restauration était posée dans un trap EXIT avant le geste — une panne provoquée qu'on oublie de refermer est pire que pas d'essai.

Maillon	Constat
déclenchement	3 échecs de rotation à 30 s d'intervalle : 12:53:11, 12:53:41, 12:54:12
seuil	l'alerte tombe au 3ᵉ, exactement — SOC ALERTE [CRIT] logrot à 12:54:12
journal du bot	IriX.log, la ligne nommant les deux fichiers et la cause (permission denied)
base	IriX_alertes #3, crit, ouverte, compte=1
courriel	parti à 12:58:58 vers service.overtchat@free.fr, IriX_mail_log #18 statut ok
panel	1 critique ouverte → bandeau ; après rangement, 0 → plus de bandeau
rangement	par alerte_acquitter(), le chemin réel du bouton, pas un UPDATE à la main

⚠ Aucune perte : l'échec survient à la copie, donc la troncature n'est jamais atteinte — les journaux gardent tout, et les 28 archives sont intactes. Restauration vérifiée après coup : droits 755, last_rotate revenu à 09:43:31.

⚠ Le délai du courriel est de ~286 s, et c'est normal : le cycle d'envoi passe toutes les 300 s. Une alerte rangée dans cet intervalle ne part pas — c'est voulu, et c'est aussi pourquoi le rangement rapide n'est PAS un moyen fiable de faire taire un essai.

Ce qui n'a pas été provoqué, et pourquoi

Deux familles sur quatre sont constatées en vrai : balayage (logrot, aujourd'hui) et lien (botnet, le 16/08). Les deux autres — uline/socket et mandat/observation-morte — demanderaient de couper un lien en service ou de vider une table de production.

⚠ Et cela n'apprendrait rien de plus sur la chaîne : elle est unique, et elle vient d'être éprouvée bout à bout. Ce qui diffère d'une famille à l'autre est le point d'appel, et ces points-là sont désormais gardés par dérivation : test-branche-morte.tcl exige qu'aucun ne soit enfermé dans un catch inatteignable. Provoquer une panne réelle pour éprouver du code déjà dérivé serait payer cher une information qu'on a.

Ouvert le 16/08/2026 en fermant le 23, et avancé le même jour : de 4 points à 13, de 2 modules appelants à 7.

⚠⚠ CE TITRE DISAIT « DOUZE ». C'ÉTAIT FAUX LE JOUR MÊME OÙ IL A ÉTÉ ÉCRIT — mesuré le 16/08/2026 en dérivant les appels depuis les sources, et trouvé deux fois indépendamment. Il y a 13 appels à ::soc::alerte::echec / ::soc::alerte::erreur dans IriX/cmds/. Celui qui manque à toutes les énumérations est IriX/cmds/irix-chanq.tcl (file-illisible), livré par le même commit que les autres. Ce n'est donc pas une dérive dans le temps : c'est un compte fait à la main, faux dès l'écriture. Le compte de modules (7) est juste, lui, parce qu'il a été dérivé. Un nombre écrit à la main ne survit pas à la séance qui l'écrit.

⚠⚠ ET DEUX DES TREIZE NE PEUVENT PAS SE DÉCLENCHER, mesuré le 16/08 :

• chanq / file-illisible est dans une branche morte. Son catch entoure ::soc::db_sel, qui ne lève jamais — elle attrape l'erreur, la journalise et rend {}. C'est exactement le piège que ce point documente pour db_exec, reproduit avec db_sel dans le commit même qui le documentait.
• botreg / pool-arrete est dans ::soc::botreg::demander_robot, qui n'est appelée nulle part en production — deux occurrences dans tout le dépôt : sa définition, et un banc.

Restent 11 points atteignables, dont 2 constatés (la rotation des journaux ci-dessous, et le lien de botnet du point 23).

✅ Ce qui parle désormais (4.18.4) : le dialecte non implémenté et les SID épuisés (erreur, permanents), la socket qui refuse et le lien fantôme (echec), les trois installations de robot ratées qui arrêtent le service (erreur), le contrôle des prêts qui tourne à vide (erreur), la rotation des journaux qui boucle (echec), le moteur de modération qui tourne à vide (echec).

⚠⚠ ET DEUX ENDROITS OÙ L'ALERTE NE DOIT PAS SE LEVER — ils valent plus que dix branchements. Une alerte qui se lève au mauvais moment apprend à ignorer le bandeau, et l'on perd alors toutes les autres. (1) Une table absente ne lève rien : au premier démarrage elles n'existent pas encore, et sans cette exception toute installation neuve crierait dès sa première minute. (2) L'alerte n'est pas branchée sur set_error, l'entonnoir des sockets, parce qu'il porte aussi « Socket désactivé » — le refus légitime de connecter un lien volontairement coupé.

✅ UN DES HUIT EST CONSTATÉ — la rotation des journaux, le 16/08/2026 à 14:59:23. Panne provoquée volontairement (droits retirés au répertoire d'archives, date de rotation reculée), et tout restauré ensuite :

14:58:23  LOGROT: rotation incomplète — permission denied   (1er échec)
14:58:53  LOGROT: rotation incomplète                       (2e)
14:59:23  LOGROT: rotation incomplète                       (3e)
14:59:23  SOC ALERTE [CRIT] logrot : La rotation des journaux échoue

⚠ Et le comportement d'après compte autant : les échecs de 14:59:53 et 15:00:23 n'ont pas relevé d'alerte. Le compteur repart bien de zéro après avoir levé — sans quoi la déduplication en base aurait masqué le défaut derrière un compteur qui monte.

⚠ Les sept autres ne sont pas constatés : écrits, éprouvés au banc, jamais vus agir.

Le recensement d'origine portait une trentaine de candidats ; les autres restent : le lien fantôme côté mark_ghost est fait, mais pas les échecs de burst, ni les suspensions non écrites, ni les cinq catch nus du balayage horaire (rate_purge, mandat::balayer, bascule_charge, signaler_non_servis, suspendre_non_servis) où une erreur Tcl disparaît sans même un putlog.

⚠⚠ DEUX PIÈGES MESURÉS, à connaître avant de brancher quoi que ce soit :

1. Les catch { ::soc::db_exec … } err ont une branche MORTE. db_exec ne lève jamais : il journalise et rend 0. Une dizaine de sites du dépôt entourent un db_exec d'un catch dont la branche d'erreur est inatteignable — y poser une alerte serait écrire dans du code mort. ⚠ À ne pas confondre avec db_exec lui-même, qui alerte bien, depuis l'intérieur de sa propre branche d'erreur. Ce sont les catch que d'AUTRES procédures posent autour d'un appel à db_exec qui sont morts, parce que db_exec ne lève jamais. La nuance a déjà induit un relecteur en erreur.
2. alerte::echec est INERTE sur ce qui tourne une fois par heure. Sa fenêtre est d'une heure

⏪ CE QUI SUIT EST L'ÉTAT D'AVANT LA FERMETURE — PÉRIMÉ, gardé pour la trace. Le critère décrit ci-dessous a été tenu le 17/08/2026 — voir le constat en tête de point. ⚠ Et le critère lui-même est caduc, pas seulement atteint : deux familles ont été constatées, et il a été assumé de ne pas provoquer les deux autres — un tiers pourrait noyer le bandeau à volonté, et le volume rendrait la page illisible. ⚠ Ne pas le relire comme du travail à faire. Un encadré « Pour fermer » périmé sous un titre ✅ est exactement ce qui fait rouvrir un point déjà clos.

et son seuil de trois : un mécanisme horaire ou quotidien n'atteindra jamais trois. Pour tout ce qui vit dans scan::hourly ou daily, il faut alerte::erreur — ou une clé qui agrège plusieurs cibles dans le même passage.

23. L'état d'avant, gardé pour mémoire

Ouverte le 16/08/2026. ✅ La partie visible est faite en 4.18.2 — bandeau sur toutes les pages, page de lecture, acquittement au niveau op, pastille de menu, courriel par balayage borné. Les trois destinations tranchées par SerVuS sont couvertes.

⚠ Et le point reste ROUGE, parce que rien n'a été constaté. Aucune alerte réelle n'a jamais été levée : le chemin complet — un échec répété, une ligne en base, un bandeau, un courriel, un acquittement — n'a jamais été parcouru une seule fois.

⚠⚠ Un seul appelant. Le module ne couvre que le refus de botnet. Poser l'alerte n'a pas protégé du motif « à la jointure » : il en a créé un de plus. Chaque mécanisme qui échoue en silence aujourd'hui continuera de le faire tant qu'il n'appellera pas ::soc::alerte::echec.

⚠ La page dit elle-même ce qu'elle ne peut pas dire : « une page vide ne veut pas dire que tout va bien ». Sans cet encart, elle deviendrait la nouvelle section 🔴 vide du registre — rassurante et fausse.

---

Aucun autre au 16 août 2026, 11:11:06. Les points 20 et 21 ont été constatés fermés à cette minute — le panel a monté un lien de botnet, ce qu'il n'avait jamais réussi à faire depuis que ce code existe. Ils rejoignent les travaux ci-dessous, où ils gardent tout leur texte.

⚠ Et il faut redire ce que la veille disait déjà deux fois : « ce qui vide cette section, c'est parfois seulement de ne pas avoir regardé ». Le 15/08 elle était vide à 19:06 — six actions du panel étaient déjà mortes à cet instant, et rien ne le disait. Ce n'est pas un banc qui les a trouvées : c'est un utilisateur qui a cliqué.

🟠 Travaux à effectuer

54. ✅ Le site annonçait une version d'OverScript qu'il ne DISTRIBUAIT pas — CONSTATÉ FERMÉ le 26/08/2026

Le circuit, en entier :

⚠⚠ LE NOM SERVI EST STABLE, SANS NUMÉRO. Un nom versionné casserait tous les liens et tous les signets à chaque publication — même leçon que le raccourci du client, qui pointe vers une copie à nom stable plutôt que vers dist/.

⚠ Le journal n'est PAS recopié dans ce dépôt. Une copie suivie par git se périmerait au premier écart entre les deux dépôts — le défaut de famille du projet. La page lit ce qui a réellement été publié, et le dit quand il manque au lieu d'afficher une section vide.

⚠⚠ Deux choses qui ont menti, et une qui ne pouvait pas rougir

1. WEB.md et le CHANGELOG du client affirmaient tous deux que le journal « est publié avec chaque version ». Il ne l'était nulle part : le mot CHANGELOG n'apparaissait ni dans Web/inc/, ni dans Config/overscript.json. Une affirmation d'état en français, dans un fichier qui part chez les utilisateurs. Les deux sont corrigés.

2. Mon premier constat était faux dans l'autre sens : il exigeait le fichier dès que l'inventaire le nommait — or il le nomme toujours, c'est une constante. Il rougissait donc sur tout clone de développement, où le binaire n'a aucune raison d'être. ⚠ Un banc rouge en permanence finit par ne plus être entendu. La condition porte désormais sur le manifeste, qui ne liste que ce qui existe : ce que le site publie doit être là, et être ce qu'il dit.

3. Et md_render rend une LISTE [html, toc], pas un tableau associatif. La première écriture de la page lisait $rendu['html'] : elle aurait affiché « journal indisponible » sans qu'il manque quoi que ce soit.

⚠ Ce que les bancs du site ont attrapé, et qui ne se voyait pas

Deux échecs après la mise en production, tous deux de vrais défauts visuels :

• test-vues-site.php — le bloc .md ne vivait que dans le <style> de versions.php : le journal d'OverScript s'affichait sans aucune mise en forme. Et le sélecteur des deux onglets était défini dans la page OverScript alors qu'il est employé des deux côtés — les boutons de la page générale étaient donc sans style. Les deux blocs vivent maintenant dans site.css.
• test-nav-site.php — versions-overscript.php était vue « inatteignable » : elle est incluse, pas routée. ⚠ Plutôt que de l'ajouter à la liste d'exceptions — qui dit « ne regarde pas » —, le banc relève désormais les inclusions et le vérifie. Avec sa garde : un relevé qui ne trouve rien doit le dire.

---

<details><summary>L'énoncé d'origine du 25/08, gardé parce qu'il explique la décision</summary>

Le canal de mise à jour d'OverScript est branché, et son dernier maillon manque. Demandé par SerVuS le 25/08/2026 : « ajouter un numéro de version sur OverScript pour voir les modifs, mettre un bouton mise à jour, et faire le lien via GitHub avec détection automatique ».

⚠⚠ GITHUB A ÉTÉ ÉCARTÉ SUR MESURE, PAS SUR PRÉFÉRENCE. api.github.com répond 404 en anonyme sur les trois dépôts du projet — y compris Overtchat, où un push venait de réussir. Ils sont privés, et GitHub rend la même chose pour « privé » et pour « inexistant ». Un client installé chez un tiers n'a pas de jeton, et on ne peut pas en embarquer un dans un binaire distribué : il serait lisible par quiconque ouvre le paquet. C'est exactement la raison pour laquelle l'installateur du projet tire déjà ses composants du site. SerVuS a tranché pour le site.

Ce qui est fait et constaté :

⚠⚠ CE QUI MANQUE — ET LE BOUTON MÈNE DONC À UNE PAGE OÙ LE FICHIER N'EST PAS. Mesuré le 25/08/2026 : le mot « OverScript » n'apparaît ni dans distrib_inventaire(), ni sur ?p=telechargement. Le client dira correctement « une version plus récente existe », ouvrira la page de téléchargement du site — et l'utilisateur n'y trouvera rien.

⚠ C'est le défaut de famille du projet, pris à temps : ça marche ici, et rien n'arrive chez le tiers. La différence avec les quatre cas du 16/08 est qu'il est nommé avant d'avoir menti à quelqu'un.

⚠ La procédure de publication est écrite : Markdown/WEB.md, section « Publier une version d'OverScript ». Elle porte le seul geste du circuit qui ne dérive de rien — les deux dépôts étant séparés, le numéro se recopie à la main dans Config/overscript.json.

</details>

53. ✅ Un fichier d'état recopiait le numéro de version, et le contrôle ne le voyait QUE tant qu'il était juste — CONSTATÉ FERMÉ le 26/08/2026

AVANT   state.json  version = 4.19.30      APRÈS   state.json  version = (absente)
        state.default.json  = 4.23.2               state.default.json  = (absente)

Et les trois choses qui comptent, mesurées après :

• l'écran d'accueil affiche 4.23.2, égal au VERSION du dépôt — la dérivation marche ;
• state.json reste valide : la migration n'a emporté que sa cible ;
• test-json.php repasse au vert de lui-même — 18 constats, 0 échec. On n'a rien fait taire.

⚠⚠ Le fichier n'a PAS été purgé à la main, et c'était la condition écrite de ce point : purger aurait éteint le symptôme sans jamais éprouver la migration, et le prochain tiers aurait retrouvé le défaut entier. Sauvegarde avant le geste : /home/servus/sauvegarde-state-20260826-121446.

Campagne complète après coup : 107 bancs au vert, 5009 constats.

Trouvé le 25/08/2026, en posant les empreintes de référence avec SerVuS. test-json.php a rougi sur un constat qui dormait depuis longtemps :

ÉCHEC  aucun JSON ne recopie le numéro du projet
       obtenu : ["Runtime/state.default.json : version"]

Deux fichiers, deux états — et c'est le second qui instruit :

⚠⚠ ET LE BANC NE SIGNALE QUE LE PREMIER. Sa règle est $val === $VERSION : il ne dénonce un numéro recopié que s'il est encore exact. Dès que le chiffre se périme — c'est-à-dire dès qu'il devient un problème — le contrôle se tait.

C'est le motif « garder la porte en regardant la serrure », et sous sa forme la plus retorse : le banc est vert pendant toute la durée où le défaut nuit, et rouge à la seule seconde où il ne nuit pas encore. state.json porte 4.19.30 depuis des semaines sans que rien ne l'ait dit.

⚠ Ce n'est pas un défaut de discipline mais de MÉCANISME : ce dépôt a pour règle qu'un chiffre qui se périme se retire au profit de la commande qui le mesure. Ici, c'est l'installateur qui écrit le numéro, et aucun humain ne le recopie.

⚠ Les deux fichiers sont hors dépôt — ils ne partent chez personne. Le défaut est donc local à chaque installation, ce qui le rend d'autant plus discret : il ne se voit pas dans un diff.

✅ La moitié (2) — le CONTRÔLE — est réparée le 26/08/2026

Le banc dénonçait le fichier qui avait raison et laissait passer celui qui mentait :

La règle retenue, et pourquoi celle-là. Une valeur qui est ou a été un numéro de ce projet — l'historique de VERSION.md la donne. ⚠ Appliquée aux seuls fichiers d'état (Runtime/state*) ; partout ailleurs la règle d'origine tient, l'égalité avec VERSION.

⚠⚠ La première écriture appliquait l'historique PARTOUT, et elle était fausse. Elle a dénoncé Config/servers.json : servers.inspircd.version = 4.11.0 — une vraie version d'InspIRCd, qui se trouve être aussi une des nôtres. La collision est structurelle : rien n'empêche un logiciel tiers de porter un numéro que nous avons porté.

⚠ Elle n'était pas visible depuis le dépôt. Config/servers.json n'est pas suivi par git, et le clone Windows ne déclare même pas inspircd. Il a fallu éprouver le contrôle sur la production pour la voir. Mesurer là où vit la chose mesurée.

La passe de mutation que ce point exigeait est écrite — quatre cas qui cassent la règle exprès, dans les deux sens, et qui appellent la décision que le balayage emploie réellement, pas une copie :

• un numéro périmé dans un fichier d'état → dénoncé ;
• le numéro courant dans un fichier d'état → dénoncé ;
• ⚠ le même numéro périmé dans un fichier de composants → non dénoncé (c'est le fichier qui décide, pas la valeur) ;
• le numéro courant dans Config/ → dénoncé, la garde d'origine tient.

⚠ Le numéro périmé y est dérivé de l'historique, jamais écrit à la main : un numéro en dur se périme, et ce banc parle précisément de numéros périmés. Un cinquième constat refuse que le balayage travaille sur un historique vide — muet ressemble à vert.

test-json.php : 11 → 17 constats.

🟡 La moitié (1) — l'installateur — écrite et éprouvée le 26/08/2026

Trois points de contact, tous mesurés avant d'y toucher :

⚠⚠ LA DÉRIVATION LIT $BASE_DIR/VERSION, PAS $VERSION. $VERSION vient du chemin du script : chez un tiers, l'installateur se télécharge seul, n'a aucun VERSION à côté de lui et retombe sur son repli 4.0.0. Afficher $VERSION aurait remplacé un mensonge par un autre — et par le pire des deux, puisqu'il aurait été juste sur ce poste-ci.

⚠ Un piège qui ne se voit pas : _jq_read ne replie sur N/A que si jq sort en code non nul, or une clé absente fait sortir jq en 0 en imprimant null. Retirer la clé sans toucher la ligne de lecture aurait affiché « null » à l'écran d'accueil.

⚠ Et une erreur prise en écrivant : le gabarit jq est porté par une chaîne à quotes simples, et le script l'écrit noir sur blanc deux lignes plus haut. Un commentaire contenant des apostrophes l'a refermée — bash -n a rougi sur du jq parfaitement valide, quarante lignes plus bas.

Banc neuf : Bootstrap/tests/test-version-etat.sh, 17 vérifications, sur le modèle d'extraction de test-empreintes.sh — l'installateur finit par main "$@" sans garde, donc le sourcer le lancerait. ⚠ Il vérifie que chaque fonction a bien été extraite : sans cela un renommage laisserait un fichier vide et tout passerait au vert.

Passe de mutation — trois blessures, trois rouges :

✅ Le constat, pris le 26/08/2026

⚠ Le banc restera ROUGE tant qu'elle n'est pas faite, et c'est voulu : il dénonce le vrai défaut. Mais un banc rouge en permanence finit par ne plus être entendu — ce projet l'a déjà payé.

Mesuré le 26/08/2026, ce qui lève la précaution « vérifier d'abord qui lit cette clé » :

⚠ Et la cause du gel est nommée : ce n'est pas un oubli d'écriture mais _merge_configs (overtchat-setup.sh:1838), dont la branche else . end conserve toute valeur non nulle et non-objet. state.default.json avance à chaque passage, state.json reste figé à sa première écriture. C'est la sémantique voulue de deep_merge, pas une dérive.

⚠ La fonction écrivaine s'appelle _write_default_config (ligne 1680) — le nom _init_default employé plus haut dans ce point n'existe pas dans le script.

<details><summary>L'énoncé d'origine du 25/08, gardé parce qu'il explique la décision</summary>

</details>

52. ✅ Le parcours d'inscription est à repenser en entier — DEMANDÉ par SerVuS le 25/08/2026, CONSTATÉ FERMÉ le 27/08/2026

Sa demande, dans ses termes : pouvoir réserver un pseudo depuis le site sans être connecté en même temps, puis disposer de 24 h pour venir le confirmer — par IDENTIFY sur IRC, ou depuis le chat, ou par un formulaire à côté du chat qui enverrait la commande au service. Et son constat de départ : « un truc qui n'est pas logique entre Avant de commencer et Créer le compte ». Il a raison, et le défaut est plus large qu'il n'y paraît.

Ce que le parcours fait AUJOURD'HUI — mesuré, pas lu

⚠⚠ Il y a TROIS portes d'inscription, pas une. Toute refonte qui n'en verrait qu'une en casserait deux.

L'incohérence que SerVuS signale, précisément. Le cadre « Avant de commencer » exige que le pseudo soit déjà enregistré sur le réseau. Le bouton, lui, crée immédiatement un compte sans qu'aucune preuve n'ait été faite, dans un état qui n'ouvre rien — et qui confisque le pseudo et l'adresse, tous deux UNIQUE. L'ordre est inversé : le site enregistre d'abord et vérifie peut-être jamais. ⚠ Et la page ne donne aucun moyen de faire le préalable qu'elle exige : pour envoyer REGISTER, il faut être sur IRC — donc au chat, où l'on n'a plus besoin de cette page.

Ce que la mesure a trouvé en plus — et qui décide de la refonte

1. ⚠⚠ Rien ne purge un compte non vérifié. Jamais. Aucun DELETE sur web_users n'existe dans le dépôt — ni PHP, ni Tcl, ni SQL, ni cron. Un compte abandonné garde le pseudo et l'adresse à vie, et reset.php refuse toute récupération tant que irc_verified vaut non : ni entrée, ni sortie, ni libération. Le « délai de 24 h » que SerVuS demande n'a donc pas d'existence — il est à créer, et c'est lui qui rend le reste tenable.
2. ⚠⚠ Les deux portes se contredisent sur les mots de passe. La page promet : « le mot de passe du site est distinct de celui du réseau, ne réutilisez pas le même ». Le chat, lui, envoie REGISTER <p> au service puis poste le même <p> vers ?p=reservation, qui en fait le mot de passe du site. Deux doctrines opposées dans le même site, et aucun code n'arbitre.
3. VERIFY ne vérifie pas l'identification : la branche ne lit ni users.auth ni aucun grade. Ce qui referme la fenêtre en pratique est nickguard — un interrupteur en base, avec 60 s de grâce. Une garde de protocole s'appuie sur un réglage d'exploitation.
4. Deux politiques de mot de passe qui ne se parlent pas : le site impose 12 caractères, le REGISTER d'IRC n'impose aucune longueur. Or la porte du chat fait des deux le même secret.
5. REGISTER renvoie l'utilisateur vers la page Inscription pour y poser son adresse — or cette page n'écrit jamais IriX_users.email, seulement web_users.email. Sans adresse côté réseau, la réservation ne peut jamais expirer. Mesuré en prod : les deux seuls pseudos enregistrés sont sans adresse.
6. Le lien entre les deux mondes est une chaîne comparée avec deux règles de casse : web_users est en utf8mb4_unicode_ci, donc insensible ; le Tcl compare avec la casse ailleurs. C'est le piège connu du projet, posé ici sur le lien qui porte toute la preuve.
7. ⚠ Aucun banc ne couvre le cycle inscription → code → VERIFY → irc_verified. Casser register_store, register_resend ou la branche VERIFY ne ferait rougir personne. ⚠ Et IriX/tests/test-register.tcl ne teste pas l'inscription : il éprouve l'enrôlement de l'owner Eggdrop. Piège de nom.

⚠⚠ LE POINT DE SÉCURITÉ, à trancher AVANT d'écrire quoi que ce soit

SerVuS propose « un formulaire à côté du chat qui envoie la commande au service avec le mot de passe saisi ». Deux implémentations se ressemblent et n'ont rien à voir :

• dans le NAVIGATEUR — le JavaScript du chat envoie IDENTIFY sur le WebSocket, comme n'importe quel client IRC. Le secret ne touche jamais le serveur web ni ses journaux. Le transport est déjà chiffré de bout en bout (webchat_url() rend null hors HTTPS, donc un chat en clair est impossible), et le mécanisme existe déjà sous trois formes ;
• par le SITE — formulaire → POST → PHP → IRC. Le serveur web voit le mot de passe réseau en clair, il peut finir dans un journal, et cela contredit frontalement ce que la page promet. ⚠ C'est ce que fait déjà ?p=reservation, et c'est le défaut n° 2 ci-dessus.

Recommandation : la première. Elle ne coûte presque rien — le chemin est écrit — et elle est la seule qui laisse la promesse de la page intacte.

✅ LA DÉCISION EST PRISE — 27/08/2026

La confirmation passera par le NAVIGATEUR : le JS enverra IDENTIFY sur le WebSocket déjà ouvert, et le mot de passe réseau ne touchera jamais PHP. C'est la seule option qui laisse intacte la promesse affichée sur la page d'inscription. ⚠ Conséquence à assumer : ?p=reservation fait aujourd'hui l'inverse — elle POSTe le mot de passe réseau vers PHP, le compare en base, et s'en sert comme mot de passe du site. C'est le chantier (2).

✅ (1) L'EXPIRATION EST FAITE — 27/08/2026

::soc::webexpire, dans IriX-sql.tcl — aucun fichier neuf, donc aucun manifeste à toucher et aucun risque de chargement. Branchée au scan HORAIRE, pas au quotidien : l'échéance annoncée est 24 h, et un balayage quotidien donnerait de 24 à 48 h selon l'heure d'inscription.

Ce qui manquait vraiment : aucun DELETE sur web_users n'existait dans tout le dépôt. Un compte non vérifié n'a ni entrée ni sortie — auth.php refuse de l'ouvrir, reset.php refuse d'en récupérer le mot de passe — mais il confisque un pseudo et une adresse, tous deux UNIQUE. Et web_tokens n'était purgée par rien.

⚠ La garde de sûreté : irc_verified='non' AND level = 0, reposée à l'identique dans le SELECT et dans le DELETE. Un compte à grade n'est jamais touché.

⚠ La purge est INERTE aujourd'hui — aucun compte non vérifié en base. Sans les deux comptages avant/après, rien ne distinguerait « rien à purger » de « refusé en silence », peut-être pendant des mois. Le banc fabrique donc lui-même les comptes que le monde réel ne contient pas.

⚠ RESTE UN GESTE : le code est en production mais IriX ne l'a pas rechargé. ✅ GESTE FAIT ET CONSTATÉ le 27/08/2026. IriX a redémarré à 11:59:05 — après le commit f51ab05 (11:33) et après l'écriture du fichier (11:58:47) — et le balayage horaire a tourné au premier passage, à 12:00:00 : « 1 inscription(s) jamais confirmée(s) retirée(s) après 24 h, 0 en attente » et « 2 jeton(s) mort(s) retiré(s), 0 gardé(s) ». ⚠ La trace est dans IriX/cmds/IriX-sql.log — ni dans journalctl -u irix, ni dans IriX/runtime/IriX.log.

Éprouvé : IriX/tests/test-webexpire.tcl, 31 constats, 10 blessures sans trou.

⚠⚠ Ce que la mutation a trouvé dans les BANCS — trois trous

Trou	Ce qui le rendait invisible
« la clause est reposée dans le DELETE » restait vert quand on la retirait	le constat cherchait la clause dans tout ce qui était émis, or les deux SELECT COUNT la portent aussi — motif trop large
test-charte-retention.php était complice de son propre motif	son contrôle « aucune purge n'échappe à la charte » énumérait ce que son motif avait su voir, et ce motif ne connaissait que INTERVAL … DAY. Une purge en HOUR lui échappait — la plus grave, la seule qui efface un compte. Le rendre aveugle ne le faisait pas rougir : il le rendait muet
l'unité n'était comparée par personne	INTERVAL 24 HOUR → INTERVAL 24 DAY multipliait le délai par 24, et la charte disait toujours « 24 »

Trois contrôles ajoutés au banc de la charte : le motif accepte HOUR et MINUTE, tout ce que la charte annonce doit être vu par le motif, et tous les DELETE du Tcl sont énumérés sans passer par les durées. ⚠ Ce dernier a trouvé, le jour même, une table que personne n'avait déclarée : auto_pubs. Il passe de 19 à 30 constats.

La charte publique porte les deux lignes correspondantes, écrites en même temps que la purge — pas après.

✅ (2) LA DOCTRINE DES SECRETS EST POSÉE — 27/08/2026

Un seul endroit — Web/inc/doctrine-secrets.php — et les quatre écrivains la suivent.

Deux règles. Le mot de passe du réseau (IriX_users.password, SHA2, posé par le Tcl) et celui du site (web_users.pass_hash, bcrypt) sont distincts, et aucun code ne dérive l'un de l'autre. Et le secret du réseau ne traverse jamais PHP.

Ce qui les défaisait : ?p=reservation recevait le mot de passe réseau en clair dans un POST, le comparait en base, et s'en servait comme mot de passe du site. Une seule porte, les deux règles cassées. Pire : en cas d'échec, le JS rejouait le POST jusqu'à trois fois. Pendant ce temps la page d'inscription promettait, en toutes lettres, que les deux mots de passe étaient distincts.

Ce qui remplace la preuve : une preuve qui se lit au lieu d'un secret qui se transmet — le pseudo est-il identifié, et vient-il de l'être ? Fenêtre de 5 minutes, calculée en SQL : l'heure de la base et celle du serveur web peuvent différer, et c'est la base qui a écrit last_auth.

⚠⚠ Ce que cette preuve ne couvre pas, et c'est écrit dans la doctrine : elle ne relie pas l'identification à cette session. Quelqu'un qui connaîtrait le pseudo et POSTerait dans la fenêtre passerait. Elle reste très supérieure à ce qu'elle remplace, mais ce n'est pas une session — le cran au-dessus est un jeton émis par le bot, et il appartient au (3).

La longueur minimale était décorative. Le site exigeait 12 caractères ; le service Tcl n'imposait rien. La page refusait « azerty », /msg OverNick REGISTER azerty l'acceptait — et la règle la plus faible gagne toujours. Une seule constante désormais, croisée par le banc.

Le chat suit le même parcours : deux champs distincts, un refus explicite si l'on tape le même secret dans les deux, puis REGISTER, IDENTIFY, et enfin le POST du seul secret du site.

⚠ UNE EXCEPTION NOMMÉE reste, et le banc la nomme : Web/inc/ircauth.php dépose le SHA-256 du mot de passe réseau dans _web_authq. Le site voit donc encore ce secret sur ce chemin-là. À traiter au (3).

Éprouvé : Web/tests/test-doctrine-secrets.php, 33 constats, 14 blessures sans trou.

⚠⚠ Un défaut écrit puis rattrapé le même jour — la purge n'aurait JAMAIS rien effacé

La garde de (1) épargnait level = 0. Or les trois portes créent leurs comptes au niveau viewer (10) : aucune ligne n'aurait jamais satisfait la clause.

⚠ Et rien ne l'aurait dit. Aucun compte non vérifié en base, donc « rien à purger » et « clause impossible » rendent le même silence — les deux comptages avant/après comptaient zéro tous les deux. ⚠ Son propre banc était d'accord avec elle : il vérifiait la chaîne level = 0, c'est-à-dire sa propre recopie.

Ce qui l'attrape : confronter la clause à ce que le code d'à côté écrit vraiment. Le banc lit désormais LEVEL_VIEWER et extrait le niveau de chaque INSERT.

✅ (3) LA PAGE SUIT L'ORDRE RÉEL — 27/08/2026

Trois étapes nommées, dans l'ordre vécu, et l'étape 1 donne enfin le moyen de la faire : le chat du site (qui envoie REGISTER puis IDENTIFY sur sa propre connexion), ou la commande pour qui a un client IRC. Le chapeau annonce les trois et prévient, avant toute saisie, que deux mots de passe distincts seront demandés.

⚠ Un défaut introduit puis attrapé avant de sortir : en dérivant la durée du code de sa constante, REG_CODE_TTL s'est retrouvée employée dans une branche et requise dans l'autre. La page aurait levé en fatale — mais seulement après une inscription réussie. C'est pourquoi le banc rend la page : une constante absente est une fatale, pas un texte manquant.

✅ (4) LE CYCLE EST ÉPROUVÉ — 27/08/2026

Web/tests/test-cycle-inscription.php, 34 constats, 6 blessures sans trou.

Il couvre les deux jointures que rien ne mesurait : la casse (le Tcl passe le code en majuscules avant de comparer — une minuscule dans l'alphabet et aucun code ne correspondrait jamais) et les séparateurs (le Tcl retire -, _ et l'espace — si l'alphabet en contenait un, le code serait mutilé). Il compare aussi pour de vrai le SHA2 de MySQL au hash() de PHP, au lieu de croire qu'ils se valent.

Et il rejoue le cycle en base : compte inerte, jeton en empreinte seule, recherche par le chemin du bot sur un code écrit avec un tiret, accès qui s'ouvre, usage unique, ménage vérifié. ⚠ Le monde réel ne contient pas le sujet — la base ne porte que deux comptes, tous deux vérifiés : le banc fabrique les siens.

⚠⚠ Un constat qui n'est PAS une exigence : VERIFY ne lit ni grade ni auth. Le banc le constate au lieu de le corriger, pour que le jour où quelqu'un croit le contraire, une ligne le détrompe. Seul nickguard protège le pseudo, avec 60 s de grâce.

51. ✅ Une campagne interrompue bloquait le banc du serveur POUR TOUJOURS — CONSTATÉ FERMÉ le 25/08/2026

Vécu le 25/08/2026, et c'est ainsi qu'il a été trouvé : ./Tools/bancs.sh annonçait « 1 échec sur 105 » sans dire lequel ni pourquoi. Le banc en cause, run-tests.sh, n'avait aucun défaut — il était empêché de démarrer.

La chaîne, mesurée de bout en bout :

1. Une campagne qui monte de vrais serveurs (test-link.py et ses voisines) est interrompue — délai dépassé, Ctrl+C, processus tué. Son finally Python ne s'exécute pas.
2. Ses overtchatd survivent, détachés, avec une configuration dans /tmp.
3. run-tests.sh s'ouvre sur une garde : pgrep -f build/overtchatd → « Un overtchatd tourne déjà. Arrêtez-le. » La garde est juste et son message dit exactement quoi faire.
4. Mais elle voit désormais les orphelins de l'étape 2. Le banc refuse de démarrer, et refusera à chaque passage, jusqu'à ce qu'un humain fasse le pkill à la main.

⚠⚠ RIEN NE SE RÉARME. Ce n'est pas un échec qui passe : c'est un auto-blocage définitif. Le jour où il s'installe, le projet perd ses 17 campagnes — celles qui éprouvent le vrai binaire sur de vraies sockets — et le lanceur continue d'annoncer un chiffre rassurant juste au-dessus.

⚠⚠⚠ ET LE LANCEUR JETTE LA SEULE CHOSE QUI AURAIT SERVI. Il exécute la campagne ainsi :

if bash "$CAMPAGNE_SERVEUR" >/dev/null 2>&1; then

Le message de la garde — deux lignes, dont la commande exacte du remède — part dans /dev/null. Le lanceur n'affiche que « ÉCHEC (relancer seul pour le détail) ». L'information existait, à une redirection près. C'est la parenté du point 34 : un banc qui dit vrai, et que personne n'entend.

Trois défauts distincts, mesurés le 25/08/2026 :

⚠ Le (c) est bénin en place — 1,4 Mo — mais il grandit sans fin, et c'est lui qui rend le (a) diagnosticable : le nom du répertoire cité par un orphelin dit de quelle campagne il vient.

⚠ Ce que ce point NE dit pas : que la campagne est fragile. Relancée après nettoyage, elle passe 17/17, et quand elle va au bout elle termine bien ses serveurs. Le défaut n'est que dans le chemin d'interruption.

50. ✅ Le bilan public comptait des rubriques qui n'étaient pas celles annoncées — CONSTATÉ FERMÉ le 25/08/2026

Trouvé le 25/08/2026, en relisant VERSION.md. Ce n'est pas un chiffre périmé : c'est une règle fausse, lue par les contributeurs comme par les visiteurs.

Le préambule de VERSION.md présente un tableau de sept rubriques, puis affirme que les nombres du bilan « additionnent les entrées rangées sous les rubriques du tableau ci-dessus », et conclut : « écrire ses changements sous les rubriques est donc ce qui les fait compter ».

⚠⚠ journal_rubriques(), dans Web/inc/journal.php, n'en connaît pas sept. Et l'écart joue dans les deux sens :

Mesuré le 25/08/2026 : VERSION.md porte 55 sections « Erreurs » et 120 « Avertissements ». Ce sont donc 175 sections que le bilan de ?p=versions ignore, alors que le paragraphe juste au-dessus promet au lecteur qu'elles comptent.

⚠⚠⚠ ET UN RENOMMAGE A ACHEVÉ LE MÉCANISME, SANS QUE RIEN NE ROUGISSE. La reconnaissance cherche le mot Vérifié. Or les versions récentes n'écrivent plus « Vérifié » mais « Éprouvé » — mesuré : 9 sections « Éprouvé », toutes récentes, toutes comptées pour zéro. Un mot changé dans un titre a suffi ; aucun banc ne l'a vu, parce qu'aucun banc ne croise les deux listes.

⚠ Le rapport avec le point 49 s'arrête à la page. Le 49 est un défaut de rendu — ce qu'on voit ; celui-ci est un défaut de comptage — ce qu'on additionne. Les deux vivent dans Web/inc/, ils ne se corrigent pas ensemble.

49. ✅ Le convertisseur de la page publique était plus strict que le markdown — CONSTATÉ FERMÉ le 25/08/2026

Trouvé le 25/08/2026 en cherchant autre chose, et il ne se voyait que sur la page servie — jamais dans le fichier source, jamais dans un banc.

md_render(), dans Web/inc/markdown.php, ne reconnaît un titre qu'à cette condition :

if (preg_match('/^(#{1,4})\s+(.*)$/', $line, $m)) {

Le motif est ancré en colonne 0. Un titre indenté ne serait-ce que d'un espace cesse d'être un titre : il tombe en paragraphe, et le visiteur lit ses dièses en clair. C'est arrivé une fois, dans ce carnet même — un #### indenté de deux espaces à l'intérieur d'un élément de liste, corrigé le 25/08 en le passant en gras.

⚠⚠ ET LE CONVERTISSEUR SE CONTREDIT LUI-MÊME. Les citations sont traitées juste au-dessus des titres, et leur motif, lui, tolère l'indentation :

if (preg_match('/^\s*>\s?(.*)$/', $line, $m)) {

Mesuré le 25/08 : Markdown/ROADMAP.md porte 32 citations indentées, et elles se rendent toutes. Une citation indentée passe, un titre indenté non — dans le même fichier, à quelques lignes d'écart. Ce n'est donc pas un choix, c'est un oubli.

⚠ CommonMark tolère 0 à 3 espaces avant un titre ATX. Le convertisseur est plus strict que la norme, et rien ne le dit — ni dans le fichier, ni dans test-markdown.php.

⚠⚠⚠ ET LE TITRE INDENTÉ N'ÉTAIT QUE LA PETITE MOITIÉ — TROUVÉ LE 25/08/2026 EN BALAYANT LE CORPUS ENTIER. Le même convertisseur n'a aucune branche <ol> : il ne connaît pas les listes numérotées. Une liste 1. 2. 3. n'est pas rendue comme une liste — ses items sont FONDUS dans un seul paragraphe, à la suite les uns des autres. Le visiteur lit :

1. poser le mot de passe dans chaque overop.conf — inerte tant qu'on ne reconnecte
pas ; 2. poser les empreintes dans pseudos-proteges.conf ; 3. REHASH du serveur…

Mesuré sur les 27 fichiers .md du dépôt : 231 items, dans 70 blocs, sur 18 fichiers. Et ce ne sont pas des cas latents — 31 de ces blocs sont dans les deux fichiers PUBLICS : 22 dans ce carnet, 9 dans VERSION.md.

⚠ C'est le plus gros défaut de rendu du projet, et il était invisible parce qu'il ne produit aucun caractère parasite : le texte est là, entier, seulement mis à plat. Rien ne rougit, rien ne manque à la lecture du fichier source — il faut regarder la page servie.

⚠⚠ CE DÉFAUT NE SE CORRIGE PAS DANS LES DOCUMENTS. Transformer 231 items numérotés en puces détruirait précisément ce qu'ils portent : un ordre. « D'abord ceci, ensuite cela » n'est pas une énumération. La correction est dans le convertisseur, et nulle part ailleurs.

Deux autres écarts, plus petits, et aucun des deux n'a de cas aujourd'hui :

⚠⚠ POURQUOI CE N'EST PAS CORRIGÉ DANS LA FOULÉE. Élargir le motif change le rendu de tous les documents servis, VERSION.md compris, pour un défaut qui n'a plus aucun cas au moment où ces lignes sont écrites. Cela se tranche ; cela ne se glisse pas dans une passe de carnet. ⚠ Et l'élargissement a un effet de bord à mesurer avant, pas après : une ligne indentée qui commence par un # sans être un titre — un commentaire dans un extrait montré hors bloc clôturé — en deviendrait un.

⚠ Ce que ce point NE demande pas : de refaire le convertisseur. Il porte une question à trancher, et une seule.

48. 🔨 Refaire le panel de l'installateur au format du site, avec un mode auto et un mode manuel — DEMANDÉ par SerVuS le 24/08/2026

Ce n'est pas un défaut : c'est un chantier à ouvrir plus tard, et SerVuS le dit lui-même en le demandant — « je sais que c'est un gros chantier ». Noté ici pour qu'il ne se perde pas, pas pour être entamé.

Ce qui est demandé, en trois morceaux qui peuvent avancer séparément :

1. Un panel qui ressemble au site. overtchat-setup.sh rend aujourd'hui des encadrés Unicode en ANSI — c'est déjà soigné, mais cela ne ressemble pas au site.

🔧 Le socle a été ASSAINI le 28/08/2026 — le chantier reste ouvert

Avant de refaire l'apparence, on a mesuré celle qui existe. La couche de rendu était complète et n'avait pas un seul banc : rien ne touchait _ui_vlen, _ui_pad, la bornure de largeur, ni le repli sans terminal. Le seul banc voisin, test-palette.php, croise les couleurs avec app.css — pas la géométrie.

⚠⚠ Le premier banc écrit a trouvé un cadre qui ne se refermait pas. Une ligne plus longue que le cadre poussait la bordure droite dehors : _ui_pad borne son rembourrage à zéro, donc rien ne repliait le texte. Ce n'est pas un cas d'école — la largeur a pour plancher 64 colonnes, et le sous-titre du bandeau porte version · user@host · chemin d'installation.

⚠⚠ Et un balayage des quinze menus en a trouvé un seul de fautif, mais il en cumulait quatre : le sous-menu « Services optionnels » offrait [0] Retour sans branche, appelait _menu_add sans _menu_has (des clés construites puis jamais consultées), n'avait aucune branche par défaut — un choix invalide ne produisait rien du tout — et s'affichait hors cadre. Plus _irix_choose_mode, seul menu du fichier sans sortie annoncée, alors qu'il décide quels modules le bot chargera.

⚠ Ce qui reste au morceau (1), et la voie est toujours celle tranchée au 25/08 — TUI par défaut, option --web quand PHP est là : (a) trois menus dessinent encore leurs entrées en texte brut hors cadre ✅ FAIT le 30/08/2026 — voir juste en dessous ; (b) l'option --web elle-même, qui ne peut pas être ouverte sans décision — voir ci-dessous.

✅ (a) — les trois menus, repris le 30/08/2026. _eggdrop_grades_menu, _panel_service_detail et _panel_server_detail dessinent désormais dans le cadre (_ui_title/_ui_top/_ui_item/ _ui_bot/_ui_prompt), comme les douze autres. ⚠⚠ La cause n'était PAS celle qu'on cherchait : pas un débordement de largeur — la plus longue entrée tient en 59 colonnes pour un cadre qui en fait au moins 64, et ces heredocs ne portaient ni couleur ni caractère large. Ils n'ouvraient simplement aucun cadre : le bandeau se fermait, et les entrées flottaient dessous. « Hors cadre » était littéral. ⚠ Deux aggravants que le registre ne mentionnait pas : les deux panels de détail appelaient _services_overview / _servers_overview — dont le contrat ÉCRIT exige « un cadre déjà ouvert par l'appelant » — sans en ouvrir un. Ils produisaient donc des bordures │ … │ et un ├───┤ sans toit ni plancher, puis des _kv hérités sans aucune bordure : trois dialectes empilés dans un même écran. ⚠⚠ Et pourquoi test-ui-cadre.sh ne pouvait pas les voir : il filtre sur _menu_add/_menu_gate, que ces trois-là n'emploient pas. Il prouve qu'un cadre ouvert se referme à la même colonne — chez eux l'invariant était vrai et VIDE. Le banc était exact, utile, et muet sur ce défaut. 📌 Ce qu'un banc ne regarde pas ne se voit qu'en changeant la QUESTION, jamais en durcissant la mesure existante. Trois constats neufs, dérivés et non énumérés : tout écran de menu ouvre un cadre · le plancher qui empêche le vert silencieux · plus aucun heredoc de menu. ⚠ Le banc était aussi plus fragile que le code qu'il éprouve : il n'extrayait pas _ui_locale et rougissait (24/36) dans un shell sans LANG UTF-8, ${#s} comptant alors des octets. Il pose désormais sa locale. Un banc qui rougit selon l'environnement apprend à ne plus être cru.

🔴 TROIS DÉCISIONS AVANT TOUT --web, et aucune n'est technique.

1. ⚠⚠ Un php -S lancé par l'installateur tourne en ROOT, et sous Linux tout utilisateur local peut atteindre 127.0.0.1:<port> : il n'y a pas d'isolation de port par utilisateur. C'est une exécution de code arbitraire déguisée en installateur. Un jeton d'URL à usage unique, imprimé sur le terminal, est la seule parade qui n'invente pas un compte que l'exploitant n'a pas encore — car _access_login_gate ne s'applique qu'à partir de la deuxième exécution, et le premier lancement est justement celui où --web servirait.
2. ⚠ Le CSS n'est pas là au moment où il servirait. L'installateur arrive seul, en un fichier ; site.css n'atteint la machine qu'après l'étape 12. Trois issues, toutes coûteuses : l'embarquer dans le script, le télécharger à part, ou n'offrir --web qu'après l'étape 12.
3. ⚠ Et ce serait le MAUVAIS fichier. Le TUI porte la palette d'app.css, pas de site.css — c'est ce que test-palette.php croise déjà, contre ce qu'un commentaire du script raconte. Un --web bâti sur site.css ne ressemblerait pas au panel qu'il remplace.

⚠ Dernier point mesuré, et il pèse : 95 lectures read directes ne passent par aucune abstraction. --auto a résolu le problème en contournant tous les menus ; un mode web ne peut pas contourner, il doit répondre. Sans une couche _ask qui n'existe pas, --web ne serait pas un panel mais un formulaire par-dessus le mode auto — ce qui est peut-être la bonne réponse, mais c'est une décision de conception, pas un détail.

2. ✅ Un mode AUTO et un mode MANUEL — ÉCRIT le 27/08/2026. Auto : site + serveur + services, sans question. Manuel : l'exploitant choisit ce qu'il pose — c'est l'assistant, il existait déjà. Détail au bas de ce point. 3. Selon l'édition dont on dispose — gratuit, payant, développement.

⚠⚠ LE TROISIÈME MORCEAU EST LE POINT 9, PAS UN CHANTIER À PART. « Gratuit / payant / développement » sont les éditions de Markdown/EDITIONS.md, et le point 9 porte déjà leur découpe. Un installateur qui propose des modes « en fonction de la version » suppose que les éditions existent et qu'un binaire sait dire laquelle il est. Cela ne peut donc pas précéder le point 9 — au mieux l'accompagner.

⚠ Ce renvoi a été corrigé le 25/08/2026 : il disait que le point 9 est « à ne pas ouvrir tant que le registre a des points ouverts ». Cette phrase appartient au texte d'origine gardé du point 9, et elle est périmée — le point 9 est ouvert depuis le 14/08/2026 sur décision de SerVuS, ses phases 1 et 2 sont faites. Ce qui tient encore, en revanche, c'est l'ordre entre les phases : la phase 3 est justement l'installateur par mode, et le point 9 explique pourquoi elle ne s'ouvre pas la première.

Les voies possibles pour « au format du site », et ce que chacune coûte

La piste qui tient debout est un compromis : garder le TUI comme chemin par défaut — il marche partout, y compris en SSH sur une machine nue — et offrir une option --web qui, quand PHP est déjà là, lance un php -S 127.0.0.1:<port> servant une interface reprenant site.css. L'installateur sait déjà faire les deux gestes : il pose PHP, et il connaît _site_install.

⚠ Le mode AUTO, lui, ne dépend d'aucune de ces voies : c'est un enchaînement des étapes existantes sans les questions. Il pourrait se faire avant le reste, et il servirait tout de suite — l'installation de bout en bout demande aujourd'hui une quinzaine de réponses, ce qui est aussi ce qui rend son épreuve laborieuse.

✅ (2) LE MODE AUTO EST ÉCRIT — 27/08/2026

--auto enchaîne les six étapes de l'assistant sans poser une seule question : site → serveur IRC → Eggdrop → IriX → unités systemd. Le mode manuel, lui, n'a pas bougé — c'est l'assistant, et il existait déjà.

⚠⚠ LE DANGER N'ÉTAIT PAS QU'IL ÉCHOUE : C'EST QU'IL RÉUSSISSE EN APPARENCE. Un read sans personne devant ne rend pas une réponse — il rend une chaîne vide obtenue par EOF, que plus rien ensuite ne distingue d'une réponse donnée. L'installation se serait poursuivie sous des valeurs que personne n'a choisies, en affichant « configuré ». Le mode auto ne lit donc jamais l'entrée standard : _site_ask rend la valeur prévue et le DIT, sur stderr — jamais sur stdout, qui est la réponse puisque la fonction est appelée dans un $( ).

Les deux pièges trouvés en l'écrivant, et qu'aucune relecture n'aurait donnés :

Ce qui arrête le départ — contrôlé pendant que rien n'est encore écrit : le nom de l'installation (il ne se devine pas et ne se change pas après coup), OVERTCHAT_SQL_PASS, et une élévation sans mot de passe (_as_root passe en sudo -n sous --auto : une invite attendrait sans fin et sans message). Le reste se donne par l'environnement — OVERTCHAT_DOMAINE, _RESEAU, _COURT, _MAIL_FROM, _MAIL_TO, _SERVEUR — et ce qui manque est annoncé au lieu d'être subi.

⚠ Une question de consentement reçoit « non », et une seule : installer une archive dont l'empreinte n'a pas pu être vérifiée. Les autres portent sur ce que l'installation vient faire — --auto est cet accord. Celle-là demande de passer outre un contrôle d'intégrité sur une archive qui s'extrait par-dessus la racine : un accord donné d'avance, par un exploitant absent, n'en est pas un.

⚠ Le défaut de serveur est unrealircd, pas celui du projet. overtchat_ircd n'est distribué par aucun canal — c'est la décision encore ouverte au registre —, donc un mode auto qui le choisirait échouerait chez tout tiers, au milieu de l'installation.

Éprouvé : Bootstrap/tests/test-auto.sh, 42 constats, et une passe de mutation à 16 blessures, sans un seul trou — dont le gel, le secret vide, l'alerte écrite sur la mauvaise sortie, et l'ordre du contrôle avant vol. ⚠ Le constat qui vaut pour la suite est celui de complétude : il compare le nombre de boucles de question de _site_install au nombre de gardes, donc une boucle ajoutée demain sans sa garde fera rougir le banc. ⚠ Le mode a aussi été lancé pour de vrai, dans un HOME détourné : il refuse en nommant les trois manques, sort en code 2, ne crée rien, et le journal de la production est resté intact — mesuré, pas supposé.

⚠⚠ CE QUI N'EST PAS CONSTATÉ, ET QUI RESTE À FAIRE : une installation complète de bout en bout n'a jamais été menée. Le banc éprouve les gardes, pas le parcours — il faudrait une machine nue, une trentaine de minutes, et la compilation d'un serveur IRC. C'est le geste qui manque, et il va sur la machine tierce (Ubuntu-24.04), pas ici : networkingMode=mirrored fait que tous les ports de la production sont déjà pris. ⚠ Le nommer ici plutôt que de cocher le morceau : écrire du code prouve qu'il existe, jamais qu'on peut s'en servir.

29. ✅ Une seule sauvegarde par jour — LIVRÉ et CONSTATÉ le 16/08/2026

Demandé par SerVuS : « en sauvegarde sur mon disque externe (Freebox), génère qu'une sauvegarde par jour ». Mesuré : trois archives le 12/08, deux le 13/08, deux le 15/08.

⚠⚠ ET LE PREMIER DIAGNOSTIC ÉTAIT FAUX — la leçon vaut plus que le correctif. J'ai accusé le rattrapage au démarrage (Persistent=true). Le journal dit le contraire : croisé avec la liste des démarrages, le service a tourné exactement une fois par jour, jamais deux — le 14/08 comme le 15/08, malgré trois démarrages chacun. Les archives surnuméraires venaient d'appels hors systemd, à la main ou par Tools/desinstaller.sh, dont la date de modification coïncide avec l'une d'elles à la seconde près.

⚠ Et le rattrapage n'était pas en cause : aucune sauvegarde n'a jamais eu lieu à 04:00 sur cette machine — les six passages automatiques sont tous des rattrapages. Le retirer n'aurait pas réduit le nombre d'archives : il l'aurait mis à zéro, en silence.

⚠⚠ ET LE PREMIER CORRECTIF AURAIT CASSÉ UNE GARDE. Il appliquait la règle à tous les appels. Tools/desinstaller.sh sauvegarde avant toute suppression et s'arrête si elle échoue : il aurait vu un succès, cru avoir son filet, et supprimé l'installation en s'appuyant sur une archive vieille de plusieurs heures — d'avant justement ce qu'on efface. C'est l'objet que ce script refuse de produire partout ailleurs : une confirmation mensongère.

Le sens retenu : le défaut est « on sauvegarde ». Seule l'unité systemd demande --quotidien. Un appel explicite produit toujours une archive.

Constaté en service : systemctl cat montre l'option chargée, NeedDaemonReload=no, et l'épreuve à blanc — commande exacte de l'unité, une archive du jour déjà présente — s'arrête sans rien produire.

⚠ Le banc test-backup.php rougissait sur du code juste : son motif ancrait --with-db en fin de ligne, donc toute option supplémentaire le faisait tomber. Un banc doit vérifier qu'une option est là, pas qu'elle est la dernière. Corrigé, plus un constat pour --quotidien.

⚠ Reste ouvert : la limite distante est de 30 archives, et la rotation n'a donc jamais rien supprimé sur la Freebox. À une par jour, elle commencera à agir dans trois semaines. Rien à faire pour l'instant, mais c'est la première fois qu'elle tournera pour de vrai — à constater ce jour-là.

25. ✅ Géolocalisation facultative de l'ASV — CONSTATÉ FERMÉ le 25/08/2026, le troisième tiers étant IMPROVOCABLE

✅✅ ÉCRITE ET LIVRÉE EN 4.19.45, et le récit compte plus que le résultat : quatre défauts ont été trouvés en ÉPROUVANT, aucun en relisant.

La première écriture rendait « le lieu le plus proche » — la réponse évidente, et la fausse. Mesurée sur des positions réelles :

⚠⚠ ET LES ARRONDISSEMENTS NE SE DISTINGUENT PAS PAR LEUR TYPE : GeoNames classe « Paris 04 Hôtel-de-Ville » en PPL, exactement comme « Paris ». Seul le nombre d'habitants les sépare — 27 332 contre 2 138 551. C'est ce qui a imposé la règle finale : dans un rayon proche, le plus PEUPLÉ l'emporte ; au-delà, le plus proche.

⚠ Trois corrections successives, chacune après une mesure : écarter les quartiers à l'import · préférer le plus peuplé · reprendre les noms français depuis le jeu de données par langue. ⚠ Les quartiers restent tapables — leur nom est accepté à la saisie, mais une position ne peut jamais les désigner. La liste des noms acceptables et celle des lieux désignables sont deux choses.

Les quatre points durs de l'énoncé d'origine sont traités :

1. Les coordonnées sont ajoutées EN FIN (colonnes 4, 5 et 6 — latitude, longitude, population). Les insérer avant le rang aurait fait de $champs[2] une latitude, et « Paris » serait redevenu « París » au WHOIS.
2. Rien n'est conservé : ni base, ni journal, ni session. ⚠ Et la route est en POST, parce qu'Apache journalise la ligne de requête entière — une position en GET finirait en clair à côté de l'adresse IP, sans purge.
3. La case ne se recouvre pas avec « Afficher mon ASV » : l'une TROUVE la ville, l'autre décide de la MONTRER. Deux gestes, deux cases, jamais cochées par défaut ni l'une ni l'autre.
4. Le refus ne produit aucune erreur : trois messages distincts selon la cause (refusé, indisponible, trop long), la case se décoche, et le formulaire reste pleinement utilisable. ⚠ La question du chiffrement ne se pose pas : sans HTTPS, webchat_url() rend null et ce formulaire n'est pas rendu.

✅ MESURÉ SUR LA PRODUCTION, AU NAVIGATEUR (23/08) : la case existe et n'est pas cochée · Lyon rend « Lyon » · Bruxelles rend « Bruxelles » · Berlin ne rend aucune ville · des coordonnées illisibles rendent 400 · et la même requête en GET est refusée (405), ce qui est la garde qui tient les positions hors des journaux.

⚠ Un gain de bord, qui dépasse la géolocalisation : puisque les noms français deviennent les noms principaux, quelqu'un qui tape « Geneve » voit désormais « Genève » s'afficher, là où il aurait vu « Geneva ».

⚠⚠ SIX CONSTATS DU BANC ÉTAIENT CREUX, et seule la passe de mutation les a vus. Trois cherchaient un mot que la mutation laissait en place — vider GEO_EXCLUS n'efface pas « PPLX » du commentaire au-dessus. Deux reposaient sur des données de fantaisie qui rendaient le même résultat avec et sans la règle. 26 constats, 14 mutations, 13 attrapées — la dernière est documentée comme redondante dans le banc lui-même.

⚠ Ce titre disait « RIEN N'EST ÉCRIT ». C'était vrai le matin du 16/08 et faux le soir. Ce point porte deux moitiés qu'il faut lire séparément : (a) la liste des villes arrive chez un tiers — ✅ tranchée, écrite et livrée en 4.19.2/4.19.3, il ne manque qu'un constat en installation tierce, plus une décision sur l'écrasement à la réinstallation ; (b) la géolocalisation elle-même — 🔴 rien n'est écrit, et c'est ce que le titre visait.

Demandé par SerVuS le 16/08/2026, juste après la fermeture du point 22 : proposer au visiteur, par une case à cocher, jamais par défaut, de laisser le navigateur donner sa position, afin de rapprocher au mieux le lieu réel — ou à défaut de viser la commune la plus proche de la liste.

Le besoin est net : aujourd'hui, une ville mal orthographiée ou absente de Config/villes.txt est refusée sèchement (« Ville inconnue — vérifiez l'orthographe, ou choisissez la commune la plus proche »), et c'est au visiteur de deviner laquelle est la plus proche. La géolocalisation répondrait à sa place.

⚠⚠ AVANT TOUT : LA LISTE DES VILLES N'ARRIVE CHEZ PERSONNE. Mesuré le 16/08/2026, et cela conditionne tout le reste — enrichir un fichier que personne ne reçoit ne changerait rien pour un tiers.

Conséquence sur toute installation tierce : asv_villes_etat() rend absente, donc la garde !== 'absente' de asv_valider() ne se déclenche jamais et le contrôle de ville est désactivé en silence. ⚠⚠ Et il se conjugue au défaut du repli : la route fait asv_ville_trouver(...) ?? trim($saisie['ville']), donc la saisie brute part au realname, publié au /WHOIS de tout le réseau. L'invariant « la ville publiée vient de la liste, jamais de la frappe » — écrit trois fois dans le code — est faux chez tout le monde sauf ici.

✅ TRANCHÉ le 16/08/2026 : la liste part dans l'archive du site. Elle est entrée dans DISTRIB_RACINE_SITE, et non écrite en dur dans la ligne tar — cette liste sert deux fois, à l'archive et au calcul de fraîcheur qui décide de la refabriquer. Un chemin ajouté au seul tar aurait été emporté mais jamais surveillé : un ré-import par Tools/villes-importer.sh n'aurait pas régénéré l'archive, et les installations suivantes auraient reçu l'ancienne liste indéfiniment, sans qu'aucune alerte ne se lève.

⚠ Le chiffre annoncé ici était FAUX : ce paragraphe disait que « l'archive triplerait ». Mesuré : 1,22 → 1,79 Mio, soit +46 %. Les 2,03 Mio de la liste se compriment à 27,7 %, et le tar prend 0,07 s de plus. L'autre voie — faire appeler villes-importer.sh par l'installateur — a été écartée : elle aurait fait dépendre chaque installation de GeoNames au moment où elle tourne, c'est-à-dire déplacé le défaut au lieu de le fermer.

⚠⚠ CE QUI A LAISSÉ CE DÉFAUT VIVRE, et c'est le vrai enseignement. Un banc existait pour l'attraper — le constat « ⚠ tout ce que le site lit hors de Web/ part dans l'archive » de Web/tests/test-distrib.php — et il était vert. Sa dérivation ne cherchait qu'une écriture du chemin, __DIR__ . '/../../…', quand Web/inc/asv.php emploie dirname(__DIR__, 2) . '/Config/villes.txt'. Le gardien de l'invariant était donc aveugle au seul fichier qui lui échappait. Les deux formes sont désormais dérivées, et une passe de mutation l'a éprouvé : en retirant Config/villes.txt de la liste, le constat rougit avec ["Config/villes.txt"], là où il restait vert auparavant.

⚠ /dl/Config/villes.txt rend toujours 404, et il ne faut PAS le corriger : personne ne demande cette URL. Les extensions surveillées par la mise à jour sont sh json conf tcl — un .txt n'y entre jamais, et l'y faire entrer recréerait le 404 permanent avec rapport rouge toutes les six heures. Le fichier arrive par l'archive, qui est dépaquetée sans filtre ni liste blanche par _site_install(), exactement là où asv_villes_fichier() le cherche.

🔴 RESTE À TRANCHER — la réinstallation écrase la liste du tiers. _site_install() extrait sur $BASE_DIR sans exclusion. Un exploitant qui aurait relancé Tools/villes-importer.sh avec d'autres pays verrait sa liste remplacée en silence au prochain passage par le menu 12 — alors que Config/identity.json est protégé par un --exclude et Web/inc/config.php par un test d'existence. C'est une décision d'exploitation, pas un correctif : protéger la liste, c'est aussi empêcher toute mise à jour de la liste.

⚠ Rien n'est écrit, et il faut trancher AVANT d'écrire — quatre points durs, dont deux qui ne sont pas techniques :

1. ✅ LA SOURCE PORTE DÉJÀ LES COORDONNÉES — ce point n'est PAS bloqué. Ce paragraphe affirmait que « la commune la plus proche est incalculable en l'état ». C'est vrai du fichier produit, et faux de la source : Tools/villes-importer.sh télécharge les dumps GeoNames, qui portent 19 colonnes dont $5 = latitude et $6 = longitude. Son awk les lit à chaque ligne et ne les recopie pas — les deux print de filtrer() ne recomposent que trois champs. Les coordonnées traversent donc déjà la machine à chaque import. Aucune source nouvelle, aucune licence nouvelle : GeoNames est en CC BY 4.0, l'attribution est déjà dans l'en-tête du fichier.

⚠ Mais l'ordre des colonnes n'est pas indifférent. asv_villes() lit $champs[0] et $champs[2]. Ajouter en fin (nom⇥pays⇥rang⇥lat⇥lon) ne casse rien. Insérer avant le rang casse tout en silence : $champs[2] deviendrait une latitude, la règle « le nom principal l'emporte sur la variante » cesserait de s'appliquer, et « Paris » redeviendrait « París » au /WHOIS. ⚠⚠ Et aucun banc ne le verrait : test-asv.php fabrique ses listes de fantaisie avec trois colonnes écrites en dur, donc il n'éprouverait plus jamais le format réel tout en restant vert.

⚠ Le fichier passerait de ~2,1 Mo à ~4,3 Mo, relu et réindexé à chaque requête (asv_villes() n'a qu'un cache de processus, aucun cache persistant) — et un blob de cette taille entrerait dans l'historique git à chaque réimport. 2. ⚠ Une position est une donnée personnelle, l'ASV actuel n'en stocke aucune. Le point 22 le dit et c'est vrai : l'ASV vit le temps de la connexion, dans le realname, et rien n'est écrit en base. Une géolocalisation ne doit pas changer cela : la coordonnée sert à choisir un nom de ville, puis disparaît. Si elle devait être conservée, c'est une décision d'exploitation, pas un détail d'implémentation — et la charte devrait le dire. 3. ⚠ La double consigne se recouvre. Il y a déjà une case « Afficher mon ASV aux autres ». Une seconde case (« utiliser ma position ») en fait deux, et elles ne veulent pas dire la même chose : l'une décide qui voit, l'autre décide comment on trouve. Les confondre publierait une position à quelqu'un qui croyait seulement s'épargner une saisie. 4. ⚠ L'API du navigateur exige HTTPS et un geste de l'utilisateur, et elle échoue souvent (refus, minuteur, poste fixe sans GPS). Le formulaire doit donc rester entièrement utilisable sans elle : la géolocalisation est un raccourci, jamais un passage obligé. Et son refus ne doit pas produire un message d'erreur — c'est un choix, pas une panne.

⚠ Le troisième tiers a été éprouvé en BRANCHE, pas sur un vrai poste. En forçant le rappel d'erreur au code 2 (POSITION_UNAVAILABLE), le site rend bien un message différent : « Votre position n'a pas pu être obtenue. Tapez votre ville. » Cela prouve que la branche existe et se distingue — pas qu'un poste sans service de localisation se comporte ainsi. La simulation est assumée et dite.

⚠⚠ RIEN NE GARDAIT CES TROIS MESSAGES, et c'était le vrai trou : les fusionner en un seul texte générique n'aurait cassé aucun banc, et le visiteur qui a REFUSÉ aurait lu qu'une erreur est survenue — alors qu'il a simplement dit non. test-asv-geo.php passe de 26 à 33 constats et les garde.

⚠⚠⚠ ET LE PREMIER DE CES CONSTATS ÉTAIT CREUX — SEULE LA MUTATION L'A MONTRÉ. Écrit comme preg_match('/code === 1/', $chat) sur tout le fichier, il attrapait ev.code === 1006 et ev.code === 1007, des codes de fermeture WebSocket sans aucun rapport. Il serait resté vert alors même que la branche du refus avait disparu — la mutation le prouve, elle ne mordait pas. Le constat cherche désormais dans le voisinage du message, avec une frontière de mot. C'est le motif « motif trop large », attrapé par la seule chose qui l'attrape.

⚠ La troisième source porte sa propre contre-épreuve : la même fonction rend 'Paris' pour (48.86, 2.35) et 'Bruxelles' pour (50.85, 4.35). Elle ne rend donc pas « Lyon » à tout le monde — sans quoi la concordance n'aurait rien prouvé.

⚠ Ce qui rend ce constat solide : aucune des trois ne suffisait seule. Le journal prouve que la permission a été accordée mais pas ce qui s'est affiché ; la fonction prouve ce qu'elle sait rendre mais pas qu'on l'a appelée ; et une phrase seule n'est pas une mesure. Ensemble, elles ferment le premier tiers.

⚠⚠ RESTENT LES DEUX AUTRES TIERS, et ils ne laisseront jamais de trace : un refus de permission ne produit aucune requête, et un poste sans service de localisation non plus. Ceux-là demandent l'écran, et seulement lui.

⚠⚠⚠ UN TIERS DE CE CRITÈRE EST DÉJÀ PRIS, ET LA PREUVE DORMAIT DANS UN JOURNAL QUE PERSONNE N'OUVRE — trouvé le 24/08/2026. Le journal d'accès Apache (/var/log/apache2/irix_ssl_access.log) porte, le 23/08 à 19:49:18 :

192.168.1.254 "POST /index.php?p=asv-ville HTTP/1.1" 200
  referer: …/index.php?p=chat   UA: Chrome/151.0.0.0

⚠ Ce navigateur n'est pas un des miens : mes passes portent Claude/… Electron/… Chrome/148, et on les distingue à l'œil dans le même journal. Celui-ci est un Chrome ordinaire.

Ce que cela prouve mécaniquement : chat.js n'émet ce POST que dans le rappel de succès de navigator.geolocation.getCurrentPosition, lui-même armé par le change de la case. Un navigateur n'appelle ce rappel qu'après qu'un humain a accordé la permission. La case a donc été cochée et la position autorisée. Quatre secondes plus tard, POST ?p=asv puis GET /ws 101 : la personne est entrée dans le chat.

⚠ Ce que le journal ne dit PAS, et il ne faut pas le sur-lire : la route rend 200 aussi bien pour une ville trouvée que pour ville: null, et le corps de la réponse n'est pas journalisé. Le geste est prouvé, son résultat à l'écran ne l'est pas. Une phrase de l'exploitant suffirait à trancher — « le champ Ville s'est-il rempli, et avec quoi ? »

⚠ Les deux autres tiers ne laisseront jamais de trace : un refus de permission ne produit aucune requête, et un poste sans service de localisation non plus. Ceux-là demandent l'écran.

26. ✅ L'intégrité — CONSTATÉ FERMÉ le 23/08/2026 sur une installation tierce, les deux moitiés

Moitié « ça aboutit » — 19:46. Menu IriX, « Synchroniser depuis le dépôt » : chaque module téléchargé et suivi de « empreinte vérifiée », puis « Modules allégés : 31864 → 17564 lignes » et « Sources IriX synchronisées ».

Moitié « c'est refusé » — 19:47. Sans quitter le menu, irix-alerte.tcl est altéré sur la production (une ligne ajoutée), le site sert bien la version altérée (32 266 octets, disque et réseau concordants), et la seconde synchronisation rend :

 • Téléchargement : irix-alerte.tcl
 ✖ Empreinte incorrecte — fichier refusé : IriX/cmds/irix-alerte.tcl
 ✖ Synchronisation incomplète.

⚠ Et il ne refuse que lui : tous les autres modules de la même passe portent « empreinte vérifiée ». C'est la clause du critère — « un contrôle qui refuse tout est aussi inutile qu'un contrôle qui n'a jamais refusé ».

⚠⚠ LA PREUVE N'EST PAS LE MESSAGE, C'EST L'HORODATAGE. Un refus annoncé ne dit pas que le fichier a été épargné. Mesuré sur le disque de l'installation tierce :

Le mv n'a pas eu lieu : la version saine est restée en place, et aucun résidu .part ou .tmp ne traîne. C'est ce que _download annonce — vérifier avant de poser — et c'est désormais constaté, pas lu.

⚠ La production a été remise en état dans la foulée : git checkout --, empreinte revenue à e01db0370e81a76d, git status vide. La fenêtre d'altération a duré moins de deux minutes.

⚠ Ce titre annonçait « l'intégrité promise n'est pas celle qui est faite » : c'est l'état du MATIN du 16/08. Les trois phases ont été écrites le jour même, et le corps du point le dit — « rien à faire côté site ». Ce qui reste n'est pas du code : c'est une installation tierce où un module altéré soit réellement refusé, et où une installation saine aboutisse. Tant que ce constat manque, le point reste ouvert — c'est la règle.

Le site publie tout ce qu'il faut. Presque personne ne le lit. Voilà le chantier en une phrase.

Ce qui est DÉJÀ fait, et qu'il ne faut pas refaire

Mesuré le 16/08/2026 en interrogeant le site, pas en lisant le code :

Donc : rien à faire côté site. Le chantier est entièrement côté installateur.

Ce qui n'est PAS fait

Une seule entrée du manifeste est lue par un client : site, dans _site_install. Les cinquante autres sont calculées, servies, et consultées par personne. Partout ailleurs, le script enregistre l'empreinte de ce qu'il vient de recevoir au lieu de la comparer — _irix_sync_source, _overop_sync_source, _service_verify_sha256, _server_verify_sha256.

⚠⚠ C'est le motif exact que trois commentaires-stèles du script condamnent à propos de safe_encrypt, supprimée le 29/07/2026 parce que son « contrôle d'intégrité » enregistrait le hash du fichier qu'elle venait de télécharger. Le précédent n'a pas été évité : il a été déplacé.

Et _upd_apply_file porte un intertitre « Vérification d'intégrité » qui compare hash_dl à hash_expected — valeur écrite par _upd_check_file en hachant un téléchargement antérieur de la même URL sur le même serveur. ⚠ Pire : la garde est [[ -n "$hash_expected" && … ]], donc quand la valeur manque le contrôle est sauté en silence, sans même un avertissement.

Les trois phases, dans cet ordre

Phase 1 — l'honnêteté. ✅ FAITE le 16/08/2026, et constatée en production. Aucun changement de comportement : uniquement des phrases rendues vraies. Les pages servies ne portent plus aucune des affirmations ci-dessous, et la commande donnée au visiteur a été jouée telle quelle — 468 332 octets téléchargés, shebang correct, et l'empreinte annoncée concorde, donc la vérification manuelle promise est réellement faisable. L'ancienne forme, elle, échoue bien (curl 22).

Phase 2 — vérifier dans _download. C'est le cœur, et il a un point d'accroche unique : _download n'a que trois appelants — le dépouilleur (1 fichier), les modules IriX (git.irix.files, 28), le robot OverOp (2) — soit 31 téléchargements, tous au manifeste. ⚠⚠ Et c'est le seul endroit où le fichier est encore BRUT : voir le piège n° 1 ci-dessous.

⚠ Ce paragraphe a porté « 28 fichiers » pendant vingt minutes, le 16/08/2026 — le compte des seuls modules IriX, pris pour le total. Corrigé en dérivant les repo: du script au lieu de les compter de tête. Dans le point même qui reproche au projet ses chiffres écrits à la main. Le compte se mesure : grep -c 'repo:' sur la section, jamais de mémoire.

Phase 2 — ✅ FAITE le 16/08/2026. _download compare l'empreinte du fichier reçu à celle publiée, et refuse sans poser le fichier en cas d'écart. Éprouvé pour de vrai contre le site : fichier sain accepté, empreinte faussée refusée et fichier absent, fichier hors manifeste posé avec avertissement, site injoignable sans blocage. ⚠ Le banc a trouvé un défaut dans le correctif lui-même dans l'heure : le cache du manifeste était rendu sur le seul critère « non vide », donc un JSON corrompu était accepté pour toute la durée du script.

Phase 3 — ✅ FAITE le 16/08/2026. L'empreinte attendue vient désormais du manifeste, pas d'un téléchargement antérieur. ⚠ Elle n'est interrogée que si l'URL est celle du chemin — le module a un repli qui va chercher certains fichiers ailleurs, et comparer alors accuserait à tort. ⚠ Le repli sur l'ancienne comparaison est conservé (des fichiers surveillés ne sont pas au manifeste) mais nommé pour ce qu'il est au journal. ⚠⚠ Et le silence est rompu : l'absence d'empreinte était tue, elle est maintenant dite.

Ce qui reste pour fermer le point : le constat en vraie installation tierce — un module volontairement altéré sur le site doit être refusé, et la même installation aboutir sans encombre quand rien n'est altéré. Les deux moitiés comptent.

⚠⚠ Les six pièges, tous MESURÉS

1. ⚠⚠ Vérifier APRÈS le dépouillement accuse un fichier sain. Démontré le 16/08 sur irix-alerte.tcl : brut 02846c61… = concorde avec le manifeste ; après passage du dépouilleur 00c70876… = diverge. 19 261 → 6 639 octets, 236 lignes retirées. Et comme le dépouillement dépend de .git.irix.depouiller, de OVERTCHAT_SANS_DEPOUILLE=1 et de la présence de tclsh, trois installations saines produisent trois empreintes différentes. La vérification va dans _download, avant transformation.
2. ✅ Le cache du manifeste ouvrait une fenêtre de refus de cinq minutes après chaque déploiement — corrigé en 4.18.7, après l'avoir provoqué. ⚠ À ne pas rouvrir en « optimisant » ce cache.
3. ⚠ Rendre _upd_apply_file strict bloquerait toute première application. Un fichier légitimement absent en local est classé « mise à jour disponible » : c'est le mécanisme d'installation initiale.
4. ⚠ Le repli Bootstrap/<rel> de _upd_resolve_download_url change le chemin réel sous le chemin demandé — une empreinte indexée sur $rel comparerait deux fichiers différents.
5. ⚠ Le mode hors ligne est un objectif explicite (_find_local_archive), et les composants tiers ne sont pas au manifeste (Servers/ et Builder/ : 0 entrée, mesuré). Une vérification imposée dans _fetch_sources casserait l'installation hors ligne.
6. ⚠ Pas de read dans un chemin non interactif. Le modèle de _site_install (« Installer quand même ? [o/N] ») est bon dans un assistant ; les commandes documentées comme utilisables en cron n'ont pas de terminal.

⚠ Ce qu'il ne faut PAS faire

• ⚠⚠ NE PAS ouvrir la signature (GPG/minisign). Mesuré le 16/08 : aucune paire de clés du projet n'existe (la seule clé du trousseau est celle d'UnrealIRCd, tierce), la sauvegarde chiffre en symétrique, minisign et signify sont absents. Signer demanderait donc de créer et de protéger une clé privée — un nouveau secret permanent, alors que la phrase secrète des sauvegardes a été « le point le plus grave du projet » jusqu'au 15/08. Hors périmètre, et à dire explicitement plutôt qu'à laisser croire.
• ⚠ NE PAS faire consommer X-Content-SHA256 en le présentant comme une vérification. L'en-tête est calculé par le processus qui sert l'octet : il détecte une troncature de transfert, rien d'autre.
• ⚠ NE PAS remonter sur la page publique la phrase de SECURITY.md (« l'empreinte vient du même serveur que le fichier »). Elle est vraie, mais c'est la propriété de toute distribution qui publie un SHA-256 à côté de son téléchargement. La dire là où personne ne la dit ferait conclure que ce projet est moins sûr que les autres, alors qu'il est au même niveau. Le correctif n'est pas d'alarmer sur ce que l'empreinte ne fait pas ; il est de cesser d'affirmer que les composants sont vérifiés.

⏪ CE QUI SUIT EST L'ÉTAT D'AVANT LA FERMETURE — PÉRIMÉ, gardé pour la trace. Le critère décrit ci-dessous a été tenu le 23/08/2026 — voir le constat en tête de point. Les deux moitiés ont été prises sur une Ubuntu 24.04 neuve — c'est exactement le critère que l'encadré ci-dessous réclame, mais il est énoncé 185 lignes plus bas que le constat qui le remplit. ⚠ Ne pas le relire comme du travail à faire. Un encadré « Pour fermer » périmé sous un titre ✅ est exactement ce qui fait rouvrir un point déjà clos.

27. ✅ Le webchat avertit quand on vous cite — LIVRÉ et CONSTATÉ le 16/08/2026

Demandé par SerVuS : avertir la personne quand son pseudo est cité — « soit faire clignoter le salon quand il ne se trouve pas sur la page active, soit faire une notice ».

⚠ Mesuré : la détection de mention n'existe à aucun degré. Zéro occurrence de mention, highlight, Notification, document.title, visibilitychange, focus/blur dans tout Web/. Aucune comparaison entre le contenu d'un message et le pseudo : toutes les comparaisons à monNick portent sur l'auteur ou la cible d'un événement de protocole.

Ce qui existe déjà et sert de base : un compteur nonLus par salon, incrémenté uniquement sur PRIVMSG, rendu en pastille par majSalons(), remis à zéro par activer(). ⚠ Mais il ne distingue pas le bruit d'une mention, et « non actif » y veut dire « pas l'onglet interne affiché » — un visiteur dont le navigateur est minimisé n'a aucun signal.

⚠⚠ Les six pièges mesurés, tous vérifiés dans le code :

1. Aucune notion de frontière de mot n'existe dans chat.js. Le seul motif de recherche est un indexOf nu : repris tel quel, « Al » sonnerait sur salut, alors, canal.
2. La casse : les comparaisons d'identité de traite sont strictes (deP === monNick), alors que le reste du fichier passe par cleDe() (toLowerCase). IRC, lui, est insensible à la casse.
3. L'écho local : envoieMessage appelle lignePane(s,'moi',monNick,…) avec le texte qu'on vient de taper. Une détection posée dans lignePane sonnerait sur nos propres messages où l'on se cite.
4. Les services citent systématiquement le destinataire (« Ce pseudo est enregistré », réponses de WHOIS). Sans garde, l'onglet « Activité serveur » sonnerait à chaque identification.
5. Le rejeu d'historique passe par le même lignePane que le direct, et lignePane horodate avec l'heure courante en ignorant le champ h renvoyé par le site. Un rejeu ferait sonner des mentions vieilles de jours.
6. Le pseudo change (collision 433 → X_, NICK forcé par les services). Une détection qui capture monNick une seule fois cesserait de marcher ; monNick est aussi temporairement faux entre un 433 et le 001 qui le confirme.

⚠ Et le vocabulaire CSS est CLOS (Web/tests/test-vues-site.php). Le fil a huit types (msg, moi, prive, autre, notice, info, err, hist), tous ne changent que la couleur du texte — aucune règle de fond ni de bordure —, et les cinq variables de couleur sont déjà toutes assignées. ⚠⚠ Aucun banc ne couvre ces huit types : test-vues-site.php relève les classes littérales, or lignePane écrit 'chat-ligne ' + type où type est un argument. Une neuvième classe s'ajouterait sans faire rougir personne, et sans style si on oubliait la feuille.

✅ LIVRÉ ET CONSTATÉ le 16/08/2026 (4.19.0), en production. Le constat a été obtenu sans se connecter au réseau public : le WebSocket du navigateur a été remplacé par un faux, piloté à la main, dans lequel de vraies lignes IRC ont été injectées. Le client parcourt ainsi son chemin complet — traite → lignePane → majSalons — sans qu'un octet parte au réseau.

Et la colonne : le salon non regardé porte la classe cite, sa pastille passe en chat-nonlus cite avec l'infobulle « Un message vous cite » ; le salon regardé n'a rien. Les trois gardes tiennent en service, pas seulement au banc.

⚠ Ce qui reste à constater : que le rejeu d'historique ne produise aucune mention. Il ne peut pas en produire par construction — chargeHistorique appelle lignePane directement, en type hist, sans passer par le cas PRIVMSG où vit la détection —, mais cela n'a pas été vu. Le constat demande un compte identifié, l'historique étant réservé.

28. ✅ Le chat se ferme quand on clique ailleurs sur le site — CONSTATÉ FERMÉ le 23/08/2026 par SerVuS

Demandé par SerVuS : ouvrir le chat dans un nouvel onglet du navigateur à la connexion, « car si on clique sur une autre page du site, ça ferme le site — pas cool ». Et, par protection, si un chat est déjà ouvert, une nouvelle tentative de connexion depuis la page Chat doit être bloquée, « pour éviter X connexions, pour éviter le flood en connexion ».

Le défaut est réel et sans détour : le webchat vit dans la page. Toute navigation le détruit, ce qui coupe la connexion IRC.

✅ UN DÉFAUT DÉJÀ PRÉSENT A ÉTÉ TROUVÉ ET CORRIGÉ EN PRÉPARANT CE POINT (16/08/2026) — et il produisait exactement ce que SerVuS veut éviter : deux connexions pour un seul visiteur, sans le moindre geste fautif.

Le réseau coupe. ws.onclose appelle finConnexion(), qui réaffiche le formulaire, puis planifieReconnexion(). Le visiteur voit le formulaire revenu, reclique « Entrer », une socket s'ouvre. Quelques secondes plus tard le recoTimer toujours armé tire à son tour : connecteMoi écrase la référence ws, et la première socket reste ouverte pour toujours, son onclose ne pouvant plus être déclenché par personne.

connecteMoi() coupe désormais les fils de la socket précédente avant de la fermer — sinon son onclose planifierait une reconnexion vers la session qu'on remplace — puis annule la reconnexion en attente, sauf en reprise.

Constaté en production avec un faux WebSocket qui compte les sockets : coupure 1006, reclic sur « Entrer », attente que le recoTimer tire → 3 sockets créées, 2 fermées, une seule vivante.

❌ CE QUI SUIVAIT ÉTAIT FAUX POUR CETTE MACHINE, ET VRAI POUR TOUTES LES AUTRES. Le paragraphe affirmait que set::websocket-proxies est « vide par défaut », donc que tous les visiteurs sont vus comme 127.0.0.1, se partagent un plafond « de 3 à 5 », et que « le quatrième visiteur peut être refusé » — le tout présenté comme une décision d'exploitation à trancher. Mesuré le 16/08/2026 :

⚠⚠ MAIS LE DÉFAUT EXISTE, ET IL EST CHEZ LE TIERS. Le correctif du 03/08 a été appliqué à la production et jamais au modèle distribué : Servers/overtchat-hybrid/conf/overtchat.conf.example ne portait pas la directive, et Bootstrap/overtchat-setup.sh ne la pose jamais (0 occurrence). Or Servers/overtchat-hybrid/contrib/install-service.sh fabrique la configuration d'un tiers en copiant ce modèle. Chez lui, donc :

• aucune adoption d'adresse — tous les visiteurs vus comme 127.0.0.1 ;
• le bloc allow { ip *@*; class clients; } du modèle porte maxperip 5 ;
• le sixième visiteur simultané est refusé, alors qu'il est seul chez lui ;
• et un bannissement par adresse frappe tout le monde ou personne.

✅ CORRIGÉ le 16/08/2026 : la directive est entrée au modèle, avec ce qui la rend sûre écrit à côté. Ce n'est pas un arbitrage entre « adresse partagée » et « CGNAT » : sans elle, tous les visiteurs partagent un compteur, ce qui est strictement pire que le pire cas du CGNAT.

⚠ Ce qui la rend sûre, et qu'il ne faut pas défaire : le bloc listen du port 8000 n'écoute que la boucle locale — dans le modèle comme en production, vérifié identique. Ce n'est pas la liste qui protège, c'est que le port n'est pas publié. Y mettre *, ou une adresse non locale, donnerait à quiconque le pouvoir de s'attribuer n'importe quelle identité et de contourner un bannissement.

⚠ UNE ANOMALIE INVERSE, MESURÉE, RESTE OUVERTE : le webchat échappe totalement au limiteur de rafales. throttle_exempt() dispense 127.0.0.1, et le limiteur s'exécute à l'accept(), avant que l'adresse du visiteur soit connue. Cela ne se corrige donc pas au même endroit, et surtout pas en retirant la boucle locale de la dispense : IriX et les quatre OverOp s'y connectent tous. C'est permissif, non restrictif — l'inverse de ce que ce point annonçait.

🔴 RESTE À TRANCHER — comment le modèle corrigé atteint un tiers. Components/Serveur/lib/overtchat-hybrid-2.0.0.tar.gz porte bien conf/overtchat.conf.example, mais elle est gitignorée, produite à la main par Tools/faire-archive-hybrid.sh, et absente de l'inventaire servi. servers.json porte source_url: null et sources_locales: "Servers/overtchat-hybrid" : l'installateur attend les sources dans le dépôt local. Le correctif atteint donc un tiers qui obtient le dépôt, et pas un tiers qui recevrait cette archive. La régénérer est un geste à part — elle ne se produit pas toute seule et rien ne le rappelle. (Refaite le 17/08 à 10:05, 9 contrôles verts, correspondant au commit du correctif du point 33.)

⚠⚠ ET C'EST PIRE QUE « PAS À JOUR » — MESURÉ LE 17/08/2026. Servers/ n'est distribué par AUCUN canal, l'archive comprise :

Conséquence, et elle change la nature du point : chez un tiers passé par le site, $BASE_DIR/Servers/ n'existe pas, le test Makefile + src/ de overtchat-setup.sh est donc faux, _srv_fetch_sources ne trouve rien et l'installation d'Overtchat-Hybrid échoue — le tiers tourne nécessairement sur un autre IRCd, UnrealIRCd par défaut, seul à porter un source_url externe. Il n'exécute donc pas ce code, et aucun correctif du serveur ne le concerne.

⚠ Une page du site affirmait le contraire au visiteur — Web/site/installation.php lui disait que « son code est livré avec le projet […] et l'installateur le compile sur place », vrai du dépôt et faux de ce que ce site livre. Corrigé le 17/08. La décision reste entière : soit Servers/ entre dans ce qui est distribué, soit on assume qu'Overtchat-Hybrid ne s'installe que depuis le dépôt — mais alors tout ce qui est écrit ailleurs doit le dire, et c'est ce qui manquait.

🔧 Le serveur a été RECOMPILÉ ET REMIS EN SERVICE — 28/08/2026

Sur accord explicite de SerVuS. Ce n'est pas la décision ci-dessus, qui reste entière : c'est la première fois qu'un correctif du serveur C atteint la production dans cette série.

Ce qui a été corrigé : le PROTOCTL annoncé aux serveurs pairs était périmé — il y manquait J (groupe C) et A (groupe D), présents dans la table et dans le 005 envoyé aux clients. Le même serveur disait donc deux choses différentes selon son interlocuteur, et PROTOCOL.md documentait la version fausse. ⚠ Le mode d'échec dormait : aucun second overtchatd n'est lié, et un pair qui reçoit une liste incomplète ne sait pas quelle arité donner à J.

⚠⚠ La leçon était déjà écrite dans le même fichier. chanmode_all_letters() dérive la liste du 004 de la table, avec sa raison en commentaire — « deux modes ajoutés le 28/07/2026 y manquaient ». Elle n'avait jamais été portée aux deux voisines. Une doctrine appliquée à un endroit et pas au voisin : c'est le défaut de famille du projet, et c'en est le quatrième exemple de la journée.

Ce qui a été fait, dans l'ordre : sauvegarde du binaire en service avant le geste, avec la commande de retour arrière écrite ; make clean puis make (34 fichiers, zéro avertissement) ; les 17 campagnes du serveur, qui montent leurs propres serveurs sur build/ et ne peuvent pas atteindre celui qui tourne ; arrêt d'IriX puis du serveur ; pose ; configtest depuis le même répertoire et le même compte que l'unité systemd ; redémarrage.

Constaté à 100 s — le contrôle tardif n'est pas du zèle, ce projet a vu un service mourir à 89 s. NRestarts=0 sur les deux services, empreinte du binaire en service identique à celle compilée, aucune erreur au journal. ⚠⚠ Et le 005 a été LU sur une vraie connexion, pas déduit du source. IriX avait retrouvé son lien ULine et traitait déjà le trafic.

⚠ Ce que cela ne change PAS : Servers/ n'est toujours distribué par aucun canal. La production compile depuis son propre clone ; un tiers, non. La décision ci-dessus reste ouverte, entière.

📌 Ce qui reste à faire sur ce point précis : les trois chaînes sont désormais alignées, pas dérivées. La vraie correction est de les construire depuis la table, comme le 004. Web/tests/test-chanmodes.php empêche la dérive de revenir en silence ; il ne la rend pas impossible.

✅✅ LES TROIS POINTS DURS CI-DESSOUS SONT ÉCRITS DEPUIS LE 16/08/2026, et ce point ne le disait pas. Mesuré le 23/08 : le commit « le chat s ouvre dans son onglet, et refuse d en ouvrir deux » les a tous les trois traités le soir même, et le registre n'a jamais été remis à jour — il a décrit pendant une semaine un état vieux de trente-sept versions. Ce qui suit est donc conservé pour le raisonnement, pas comme état courant :

• (1) l'ouverture d'onglet — résolue par un lien et non par window.open(), pour la raison exacte qu'expose le point : site_nav_cible() pose target="_blank" sur l'entrée « Chat », et un lien n'est jamais bloqué. Aucune page « chat seul » n'a été nécessaire, donc aucun des périls décrits ici.
• (2) le verrou expire — overtchat:chat-actif en localStorage, durée de vie 15 s renouvelée toutes les 5 s. C'est un signe de vie, pas un drapeau : un onglet fermé brutalement libère la place au bout de 15 s.
• (3) la reprise ne se bloque pas elle-même — le verrou est reposé par connecteMoi(), reprise comprise, et n'est consulté qu’à la soumission du formulaire. Une reconnexion automatique renouvelle donc le sien au lieu de s'y heurter.

⚠ Ce verrou est un confort, pas une garde, et le code le dit : localStorage est cloisonné par profil. Deux navigateurs, une fenêtre privée ou deux machines ne se voient pas. Ce qui limite réellement les connexions est ailleurs — maxperip et le plafond ASV par adresse.

⚠⚠ LA MOITIÉ QUI MANQUAIT VRAIMENT, ET QUE CE POINT NE NOMMAIT NULLE PART — corrigée le 23/08/2026. Sortir le chat dans son onglet ne protege que le premier clic. Une fois dans cet onglet, la page affichait l'en-tête et le pied complets du site : barre de navigation, menu replié, quatre groupes du pied, logo, et trois liens du corps — plus de vingt liens ordinaires, dont chacun détruisait le document. Or le document est le seul propriétaire de la socket : ni SharedWorker, ni fenêtre parente, ni relais PHP ne lui survivent. Cliquer « Charte » depuis le chat perdait exactement la conversation que le correctif du 16/08 prétendait sauver.

⚠ L'attribut n'a pas été écrit vingt fois, et c'est le fond du correctif : le pied porte ses liens en dur, la navigation les produit en boucle, chat.php en ajoute trois. Trois écritures valent trois vérités, et le lien ajouté dans six mois n'en connaîtrait aucune. La page du chat relit désormais sa propre sortie en une passe unique — site_liens_en_onglet(), armée par site_header() et rendue par site_footer(). Les ancres, mailto: et ce qui porte déjà un target sont laissés tels quels.

⚠⚠ ET RIEN NE GARDAIT TOUT CELA. test-nav-site.php ne contenait ni _blank ni site_nav_cible : le correctif entier pouvait disparaître d'une ligne sans qu'un seul banc rougisse. test-chat-onglet.php (23/08) rend la page et relit les liens qui en sortent — chercher le mot _blank dans un fichier prouverait qu'on l'a écrit, jamais qu'il agit. Huit mutations essayées, huit attrapées, dont la contre-épreuve qui sépare « la règle ne s'applique nulle part » de « la règle s'applique partout » — les deux étaient vertes sans elle.

✅ MESURÉ DANS UN VRAI NAVIGATEUR, SUR LA PRODUCTION, LE 23/08/2026 — page servie par https://service-overtchat.hd.free.fr/?p=chat, pied de page portant v4.19.39 :

⚠ Et la contre-épreuve, qui est la moitié qui compte : sur ?p=accueil, trois liens seulement sortent en onglet neuf, et ce sont les trois qui mènent au chat. Aucun autre. Une règle qui ne s'applique nulle part et une règle qui s'applique partout auraient toutes deux passé le premier tableau ; seule celle-ci les sépare, et « partout » aurait cassé la navigation du site entier.

✅✅ FERMÉ LE 23/08/2026. QUATRE MODÈLES ONT ÉTÉ ESSAYÉS DANS LA JOURNÉE, et les trois premiers étaient défendables au moment où ils ont été posés. Le récit compte plus que le résultat, parce que chaque passage a été provoqué par une mesure, jamais par une relecture :

⚠⚠ LA LEÇON EST CELLE-CI : le troisième modèle était VERT AU BANC quand il a été livré. Dix-neuf constats, douze mutations attrapées, et il cassait ce qu'il prétendait protéger. Aucun banc ne pouvait le voir : il faut deux onglets et un vrai clic pour qu'un lien nommé navigue sa cible. Ce qui l'a trouvé, c'est SerVuS en s'en servant, un quart d'heure après la livraison.

⚠ Les trois demandes de SerVuS de cette journée ne sont pas indépendantes, et l'ordre compte : la confirmation avant fermeture autorise l'entrée sur place. Sans elle, un retour en arrière depuis le chat détruirait la conversation sans un mot.

⚠ Et un défaut de fond a été trouvé en écrivant la confirmation : beforeunload envoyait le QUIT avant que la question ne soit posée. Répondre « rester » aurait gardé la page sur une connexion déjà close par nous-mêmes — fil affiché, mort, et rien pour le dire. Le QUIT est descendu dans pagehide.

⚠ Un trou de quinze secondes existait aussi : le verrou survit à son onglet le temps de son échéance, et la bascule ouvrait alors une page blanche. Le verrou et l'onglet sont deux choses, et l'un peut mentir sur l'autre.

⚠⚠ Le banc a menti trois fois dans la même séance, et la MUTATION l'a dit les trois fois — jamais la relecture. Deux constats interrogeaient une page produite par la fonction même qu'ils vérifiaient ; un troisième cherchait des lignes qui restent écrites quand on neutralise la condition qui les commande. Un constat doit exiger la CONDITION, pas ses effets — et avoir appris la leçon trois constats plus haut n'a pas suffi à me la rappeler.

État final : 40 constats, 22 mutations essayées, 22 attrapées, en 4.19.43.

✅✅ CONSTATÉ PAR SerVuS LE 23/08/2026, ET SUR PLUSIEURS PAGES — pas seulement celle qu'on lui avait indiquée : « chaque page ouvre bien en onglet pour laisser la page chat ouverte », et « le chat tourne toujours ». C'est la moitié du critère qu'aucune mesure ne remplace — la mesure au navigateur prouvait que la page ne peut plus être déchargée par un lien ; elle ne prouvait pas qu'on avait vu le fil rester en place.

⚠ Et le fait qu'il ait essayé PLUSIEURS pages compte : le correctif ne pose pas l'attribut lien par lien mais en une passe sur la sortie entière. Un constat sur un seul lien n'aurait pas séparé « la passe fonctionne » de « ce lien-là était déjà traité ».

⚠⚠ DEUX MOITIÉS DU CRITÈRE RESTENT, ET LE POINT NE SE FERME PAS SANS ELLES. Ce sont les deux que la protection contre le flood ajoutait à la demande d'origine :

1. la seconde tentative est refusée — un second onglet sur ?p=chat, formulaire rempli, « Entrer » : le message doit renvoyer à l'onglet déjà ouvert ;
2. ⚠ le verrou se libère tout seul — onglet fermé brutalement, ~20 s d'attente, nouvelle entrée : elle doit passer. C'est la plus importante des deux : un verrou sans échéance interdirait toute reconnexion définitivement après un plantage de navigateur — le péril nommé au point dur n°2, dont personne n'a encore vu la parade agir.

⚠ Le code des deux est écrit et lu (overtchat:chat-actif, 15 s renouvelées toutes les 5 s), et cela ne vaut pas constat — c'est la règle de ce registre.

⚠ Ce qui suit décrit l'état d'avant le 16/08, conservé pour le raisonnement :

1. ⚠⚠ L'OUVERTURE D'ONGLET SE HEURTE À L'ARCHITECTURE, et c'est le point le plus dur. Mesuré : la dernière instruction encore synchrone avec le clic est le fetch('?p=asv') lui-même. Tout ce qui suit — y compris connecteMoi() — vit dans un .then, donc hors du geste, où un window.open() est bloqué comme une fenêtre publicitaire.

Et l'on ne peut pas simplement ouvrir avant : à cet instant on ne sait pas encore si le site accepte l'ASV. L'ordre « contrôler d'abord, connecter ensuite » est une décision de sécurité écrite en toutes lettres dans chat.js — « ouvrir d'abord et contrôler ensuite laisserait entrer pendant le temps de la réponse, ce qui viderait le contrôle de son sens ».

⚠ Un simple target="_blank" échapperait au blocage, mais un lien ne transporte pas le formulaire : ni le pseudo, ni l'ASV, ni surtout le mot de passe — le faire voyager dans une URL contredirait frontalement l'invariant du fichier (« le client ne s'identifie jamais tout seul »).

⚠ Et le chemin n'est pas libre : index.php rend 404 sur toute URL autre que / et /index.php, tandis que chat.js fait tous ses appels en relatif (?p=asv, ?p=chat-hist…). Une page « chat seul » doit donc rester un ?p=, et reproduire tout le gabarit — la table el de chat.js déréférence une vingtaine de nœuds sans garde : un gabarit allégé qui en omet un plante au chargement, silencieusement pour le visiteur. 2. ⚠⚠ Le verrou doit EXPIRER. Un onglet fermé brutalement, un navigateur qui plante, et un verrou sans échéance interdit toute reconnexion — définitivement. Il faut un signe de vie renouvelé et une échéance courte, pas un drapeau posé une fois. 3. ⚠ La reconnexion automatique ne doit pas se bloquer elle-même. planifieReconnexion rappelle connecteMoi(…, reprise=true) : si le verrou ne distingue pas une reprise d'une nouvelle connexion, le chat se condamnerait à la première coupure réseau.

⚠ Ce point et le 27 touchent le même fichier (Web/public/assets/chat.js) et la même zone d'état par salon. Les traiter séparément ferait deux fois le même travail de reprise. ⚠⚠ Et chat.js porte un défaut documenté, trouvé dans un vrai navigateur le 09/08/2026, que « aucun banc ne pouvait voir » : toute écriture d'état par salon doit décider explicitement de son sort en reprise, comme le font déjà histCharge, rejoint, presents, modes.

20. ✅✅ Six actions du panel étaient MORTES — CLOS le 16/08/2026 à 11:11:06

⚠ Il reste ici tant que personne n'a vu un bouton faire ce qu'il annonce. Le code est écrit, le banc est vert, les six mutations mordent — et cela ne vaut pas constat. C'est la règle du carnet, et elle a déjà évité trois fermetures creuses.

Signalé par SerVuS le 16/08/2026, depuis la page : « Administration > Botnet, la partie pour lier les eggdrop met : action inconnu ».

Le fait : toute requête POST du panel traverse un portier (Web/public/admin.php:359) — if (!array_key_exists($action, ACTION_LEVELS)) → « Action inconnue. ». Six actions étaient traitées par un case et absentes de cette table. Leur code était donc mort depuis qu'il était écrit.

⚠⚠ LE DÉFAUT ÉTAIT PLUS LARGE QUE LE BOUTON SIGNALÉ, et c'est la leçon. Un seul bouton a été rapporté ; le croisement en a trouvé six. proto n'avait jamais été signalé par personne — on ne change pas de dialecte tous les jours. Un bouton rarement cliqué reste mort sans que rien ne le dise. Ce n'est pas l'usage qui trouve ce genre de trou, c'est un croisement.

⚠ C'est le cinquième trou « à la jointure » du projet — du code juste des deux côtés, et personne pour les relier. Les quatre précédents : le module irix-edition.tcl que rien ne chargeait, le transport de botnet écrit d'un seul côté, test-botschan sur un salon jamais balayé, le scan quotidien qui ne partait pas.

✅ CE QUI EST FAIT, en 4.17.5 — les six entrées, aux niveaux tranchés par SerVuS et non devinés ; et surtout Web/tests/test-panel-actions.php, qui dérive trois listes et n'en énumère aucune : les entrées d'ACTION_LEVELS, les case du switch, et ce que les pages postent réellement. Il les croise dans les trois sens, garde le portier lui-même, et porte trois garde-fous contre le vert-à-vide. 10 constats, 6 mutations, 6 attrapées.

⚠ Ce que le banc NE fait PAS : il ne lit rien de ce que fait une action ni du niveau qui lui est donné. Il constate qu'elle est joignable, rien de plus.

✅ LA MOITIÉ PANEL EST CONSTATÉE — 16/08/2026 à 10:49. SerVuS a cliqué « Lier », le panel a répondu « en attente de traitement », et la table portait action_pending = link à 10:50:11. Le panel pose donc l'action, ce dont il était incapable la veille.

⚠⚠ ET CE CONSTAT A OUVERT LE POINT 21 DANS LA MINUTE. L'action était bien posée, bien lue par le bot… et refusée à chaque cycle. Le trou en cachait un second, comme pour irix-edition.tcl le 15/08. Voir ci-dessous.

⚠ La trace n'est dans AUCUN des trois journaux — elle est en base, dans la table ${t}_botnet_log, celle qu'affiche « Activité du botnet ». J'ai failli conclure au silence en cherchant dans IriX.log, IriX-sql.log et journalctl : les trois étaient muets, et le mécanisme fonctionnait. Compter trois journaux ne suffit pas quand un quatrième endroit existe.

---

21. ✅✅ Le bot REFUSAIT toute action du panel — CLOS le 16/08/2026 à 11:11:06

⚠ CONSTATÉ FERMÉ, et par la seule preuve que ce point acceptait : un lien monté depuis le panel. SerVuS a rechargé IriX depuis le site, puis cliqué « Lier ».

11:08:52  Rehash Eggdrop — OK                        (déclenché depuis le panel)
11:08:53  bind msg 'reload' -> ::soc::cmd_reload     (les modules sont re-sourcés)
11:09:07  BOTNET : boucle d'observation redémarrée
11:10:06  attempt  OverOp-T  « link » demandé par le panel
11:11:06  link     OverOp-T  lien constaté

OverOp-T est passé à linked, zéro échec, et plus un seul refused.

⚠ Le rechargement n'a coûté ni redémarrage ni coupure : le bouton « Recharger IriX » pose le drapeau reload, que ::soc::admin::do_reload consomme par un source IriX-sql.tcl — lequel re-source tous les modules. Les 70 à 95 s d'absence d'un systemctl restart ont été évitées. ⚠ Cette information était déjà dans mes fiches et je ne l'avais pas lue : j'allais proposer un redémarrage.

Trouvé le 16/08/2026 à 10:52, une heure après le point 20, et EN REGARDANT AGIR.

Le fait : ::soc::botnet::traiter_actions sélectionne les lignes dont action_pending n'est pas none, puis soumettait l'enregistrement à action_verdict — dont la garde anti-doublon regarde ce même action_pending. L'action se refusait elle-même, à chaque cycle.

10:49:32  refused  OverOp-H  « une action est déjà programmée : link »
10:50:32  refused  OverOp-H  « une action est déjà programmée : link »

⚠ Aucune action du panel n'a jamais pu aboutir. Le lien monté le 15/08 à 21:30 l'avait été par .link à la main dans la console — le seul chemin qui marchait. Le chemin du panel était mort plus haut, au portier du point 20 : personne ne pouvait donc atteindre ce second défaut.

⚠⚠ DEUX QUESTIONS POSÉES À UNE SEULE PROCÉDURE. « Peut-on POSER cette action ? » et « peut-on EXÉCUTER celle qui est posée ? » n'ont pas la même réponse. La garde anti-doublon est juste pour la première et interdit tout pour la seconde.

⚠⚠ ET LE BANC ÉTAIT VERT DESSUS — c'est ce que ce point apporte de plus utile. test-botnet.tcl vérifiait « une action déjà programmée bloque », et il avait raison. Une règle juste posée à la mauvaise question ne rougit nulle part. Aucun banc, aucune relecture ne l'attrape : seul un geste réel le montre. C'est la meilleure raison connue de cliquer soi-même sur ce qu'on vient d'écrire.

✅ CE QUI EST FAIT, en 4.17.6 — action_verdict prend en_traitement (0 par défaut : aucun appelant existant ne change), qui lève cette seule garde ; traiter_actions l'appelle avec 1. Six constats ajoutés au banc (69 vérifications), tenant les deux sens et éprouvant les trois autres gardes en traitement. 3 mutations, 3 attrapées.

⚠ Le constat le plus utile du lot lit le corps réel de traiter_actions : sans lui, retirer le 1 remettrait le défaut en laissant les cinq autres verts. « Garder la porte en regardant la serrure », déjà payé le 14/08.

⚠⚠ CE POINT A OUVERT LE 22, ET C'EST SA MEILLEURE CONTRIBUTION. SerVuS a cru à une panne alors que le lien montait : il avait cliqué, la page n'avait rien montré de vivant pendant les 60 s du cycle. Une action différée sans retour visible se lit comme une action qui a échoué. Traité en 4.17.8 — voir ci-dessous.

---

⚠ La mise en garde de la veille vaut d'être relue, et elle vient de se vérifier une seconde fois : « ce qui vide cette section, c'est parfois seulement de ne pas avoir regardé ». Elle était vide le 15/08 à 19:06 — six actions du panel étaient déjà mortes à cet instant. Ce n'est pas un banc qui les a trouvées, c'est un utilisateur qui a cliqué.

18. ✅✅ irix-edition.tcl n'était chargé par personne — CLOS le 15/08/2026 à 19:06:20

⚠ CONSTATÉ FERMÉ le 15/08/2026 à 19:06:20, par la ligne que le bot en service a écrite de lui-même dans IriX/cmds/IriX-sql.log :

2026-08-15T19:06:20 [INFO] édition de cette installation : complete

Ouvert le 14/08/2026 à la clôture, corrigé le 15/08 en 4.17.0. Le corps est gardé tel quel : c'est lui qui dit pourquoi le défaut existait et ce qu'il a fallu écarter.

⚠⚠ Le premier redémarrage n'a RIEN prouvé, et il fallait le dire

À 19:03, IriX a été redémarré : PID neuf, lien monté en 5 s, service actif. Et aucun constat. irix-edition.tcl ne journalise rien au chargement — il ne définit que des procédures, comme la règle du projet l'exige. Un module muet ne peut pas prouver qu'il existe.

Les deux voies qui semblaient ouvertes étaient fausses :

✅ La sortie a été d'écrire ce qui manquait vraiment. Le point relevait que ::soc::edition n'était appelée par personne — module joignable et inutilisé. Journaliser l'édition au démarrage est la première question du chantier des éditions, utile en soi, et la preuve vient avec. ::soc::start_system, juste après load_config — donc le journal existe, et surtout pas au niveau du fichier, où l'appel précéderait la configuration.

⚠⚠ L'ABSENCE EST DITE, JAMAIS TUE. Une garde info commands qui sauterait en silence reproduirait le défaut à l'identique : le module pourrait redevenir orphelin sans que rien ne le signale. Les deux branches écrivent une ligne, et celle de l'échec est un WARN qui nomme sa cause et renvoie ici.

📌 La règle qui en sort, et elle dépasse ce point : on n'ajoute pas du code pour se prouver quelque chose ; on rend joignable ce qui manquait, et la preuve vient avec. Si la trace n'avait servi qu'au constat, elle aurait été un décor.

Le fait : IriX/cmds/irix-edition.tcl existait depuis le 14/08 — module juste, éprouvé, croisé par Web/tests/test-edition.php. Aucun source ne le chargeait. irix.conf source IriX-sql.tcl, qui source ses modules un par un ; celui-là n'y figurait pas. ::soc::edition n'existait donc pas dans le bot en service, et un appel aurait rendu « invalid command name » dans un catch, c'est-à-dire en silence.

Mesuré le 14/08 : zéro occurrence de « edition » dans IriX.log. Remesuré le 15/08 : zéro occurrence dans IriX-sql.tcl, et le croisement des 24 modules de cmds/ donne un seul orphelin — celui-là.

⚠⚠ LE TROU EN CACHAIT UN SECOND, trouvé en bouchant le premier. Le module manquait aussi aux deux manifestes de déploiement de Bootstrap/overtchat-setup.sh (git.irix.files et git.irix.modes.sql.modules). Le dépôt aurait marché ; une installation neuve serait morte au chargement, IriX-sql.tcl sourçant sans garde. Personne ne l'aurait vu avant une pose réelle.

⚠ Le hook pre-commit gardait déjà cette règle — et il ne pouvait pas jouer : il s'installe par clone, et il était absent du clone WSL le jour du constat. Une garde qui dépend d'un fichier non versionné n'est pas une garde. C'est pourquoi la règle est passée dans un banc.

⚠ ET AUCUN BANC NE POUVAIT VOIR LE PREMIER. test-edition.php atteint le Tcl par IriX/tests/_edition-lire.tcl, qui source le module lui-même — légitime pour éprouver la lecture, aveugle sur le chargement. Un banc qui source sa cible ne peut jamais dire si le bot, lui, la source. C'est le quatrième trou « à la jointure » du projet : un module juste, un banc vert, et personne pour les relier.

✅ CE QUI EST FAIT, en 4.17.0 — le source (section 6quaterdecies), les deux manifestes, et surtout IriX/tests/test-modules-charges.tcl : il dérive les trois listes et n'en énumère aucune, tient trois croisements (module chargé · source qui vise un fichier présent · module aux deux manifestes) et deux garde-fous contre le vert-à-vide. 8 mutations, 8 attrapées — dont la reproduction du trou lui-même.

⚠ Ce que le banc NE fait PAS : il ne lit rien de ce que fait un module ni de son bon fonctionnement. Il constate qu'il est joignable, rien de plus. Comme test-bindtime.tcl, c'est un point de passage obligé, pas une preuve.

⚠ Le redémarrage a été REPORTÉ délibérément le 15/08 à 18:00, et il faut dire pourquoi : le passage horaire de 19:00 portait la suspension de #membres, le retour d'IriX prend 70 à 95 s, et le prêt d'essai se périmait le 16/08 à 18:21 — il n'y aurait pas eu de seconde occasion. Le code a donc été déployé sans rechargement, comme le scan quotidien l'avait été le 14/08. Même motif, même raison. ✅ Le report a été payant des deux côtés : la suspension est partie à 19:00:00 et a été journalisée, et le redémarrage a suivi six minutes plus tard.

---

19. ✅✅ Le salon gardien #!Bots! — OUVERT ET CLOS le 15/08/2026

Demandé par SerVuS le 15/08/2026 : rassembler sur #!Bots! les Eggdrop qui servent au prêt de robot, les marquer +B, et montrer sur le site le nombre et le nom de ceux qui y sont connectés.

⚠ Consigne de SerVuS, et elle est structurante : les cinq sockets de service n'y vont pas. Ils portent +S et relèvent de la protection des services, qui est celle du serveur. #!Bots! ne concerne que les Eggdrop.

⚠ Le nom porte les DEUX points d'exclamation — #!Bots!, comme #!Overtchat! et #!Services!. La forme à une seule a été écrite d'abord, puis corrigée par SerVuS. Il ne vit qu'à un seul endroit du code, la constante BOTS_CHAN de Web/inc/botreg.php : le changement n'a coûté qu'une ligne et les 27 constats du banc sont restés verts au travers.

📌 LA CARTE DES SALONS — tranchée par SerVuS le 15/08/2026

Rien n'est à fermer : les cinq salons en base ont tous un rôle. ⚠ Deux faits que la mesure a ajoutés et dont aucun document ne parlait : deux prêts actifs (et non un), et une demande de salon en attente dans ${t}_chan_requests.

⚠⚠ POURQUOI « REGISTER » — la suspension du 15/08 en a donné la preuve

La formule de SerVuS dit « +B + register », et le constat de 19:00:00 a montré ce que le second coûte quand il manque. Le WARN nomme lui-même la cause :

prêt : #membres est accordé à OverOp-S, et OverOp-S n'y est PAS. […] un salon
réservé aux pseudonymes identifiés refuse les robots, qui ne le sont pas.

#membres porte +R. OverOp-S ne pouvait pas y entrer — le prêt n'a jamais eu la moindre chance d'être servi, et la suspension automatique, parfaitement juste, a sanctionné un robot qui n'y pouvait rien.

⚠ Ce n'est donc pas un détail de confort : tant que les robots ne sont pas enregistrés, tout salon +R leur est fermé, et un prêt accordé sur un tel salon se suspendra tout seul au bout de 24 h. C'est le point 10 — les pseudonymes des robots sans mot de passe — et on en connaît désormais le coût réel, mesuré, et non plus théorique.

✅ Ce que le serveur sait DÉJÀ faire — et qui n'était pas dans ce carnet

La « validation en réseau robot » existe, elle est en service, et elle est bien conçue :

/home/servus/overtchatd/conf/protection.conf
    services = oui
    robots   = oui
    IriX

⚠ La protection exige DEUX choses, jamais une — et l'en-tête de src/protection.c dit pourquoi : « Le mode +B se pose soi-même : n'importe quel client peut se déclarer robot. En faire un titre d'immunité offrirait au premier venu ce que les opérateurs eux-mêmes n'ont pas. » Il faut donc le mode +B porté ET le pseudonyme dans la liste. Le fichier s'écrit depuis le panel (?p=protection), jamais à la main.

Effets de +B, mesurés dans les sources : la protection ci-dessus (conditionnée à bots_on et à la déclaration), RPL_WHOISSPECIAL « is a bot on this network » au WHOIS, et le drapeau B dans le statut du WHO.

✅ Ce qui est fait — 4.17.0, 890f492 et f49196e

La lecture est en place au panel (?p=robots), et sans créer aucune source : elle lit ${t}_opmybot, que le bot tient déjà. Un second comptage aurait donné deux réponses à « qui est sur #!Bots! » — le défaut de la charge d'un robot, qui vivait à trois endroits (4.16.29 → 4.16.32).

⚠ La consigne « pas de services » est tenue PAR CONSTRUCTION, sans liste de noms. Ni _sync_presence (qui n'inscrit que le bot lui-même) ni _sync_robots (qui balaie botreg_pooshy) ne regarde les pseudo-clients. Une exclusion écrite à la main aurait été une liste de plus à tenir, donc à oublier. test-botschan.php le vérifie.

⚠⚠ UN DÉFAUT COMMIS ET CORRIGÉ DANS L'HEURE, à garder ici. La première version affichait « aucun robot » pour #!Bots!. Vrai sur la lettre, faux sur le fond : _sync_presence ne balaie que les salons de ${t}_channels, donc un #!Bots! absent de cette table n'est jamais regardé — la page l'aurait annoncé désert pour l'éternité, et la panne aurait été invisible. C'est le motif du scan quotidien qui ne partait pas (point 16). La page distingue désormais quatre états : non suivi · aucun robot · périmé · constaté, et « non suivi » est testé en premier — les deux premiers ont zéro occupant, celui qui teste en second ne se voit jamais.

Web/tests/test-botschan.php : 27 constats, 7 mutations toutes attrapées. Son constat le plus utile dérive la condition de suivi du Tcl au lieu de la recopier, et tient dans les deux sens — casser le PHP ou casser le Tcl rougit chacun son constat.

✅✅ EN SERVICE ET CONSTATÉ — 15/08/2026 à 20:11:00

Les cinq Eggdrop siègent sur #!Bots!, la page du panel dit « constaté — 5 robot(s) », et aucun écart n'est signalé.

20:11:00  OverOp-H/Q/S/T joined #!Bots!
20:12:00  BOTSTAT : « 1 salon(s) : #!Bots! »  (« #accueil, #!Bots! » pour H)

⚠⚠ CE QUI BLOQUAIT N'ÉTAIT NI LE ROBOT NI SA CONFIGURATION — les deux étaient justes depuis le début, channel add #!Bots! posé et le salon en -inactive dans leur .chan. Le refus venait du serveur : conf/salons-interdits.conf est fermé par défaut (*:La création de salons est sur demande) et ne portait que six dérogations. #!Bots! n'en faisait pas partie.

⚠ L'asymétrie qui a rendu le défaut MUET : IriX y entrait par SJOIN — un lien de service, qui ne passe pas cette validation — quand les OverOp sont des clients ordinaires. Le salon semblait donc exister et fonctionner, et aucun refus n'était journalisé côté robot. Trois journaux lus, aucun ne portait le mot #!Bots! : c'est cette absence totale de trace, et non un message d'erreur, qui a fini par désigner le serveur.

Corrigé par une septième dérogation !#!Bots!, posée à côté de !#!Services! — son pair, autorisé pour la même raison —, avec sauvegarde, et appliquée par systemctl reload (SIGHUP) : aucune connexion rompue. Le serveur a confirmé : « 1 motif de salon interdit et 11 exceptions ».

⚠ Le mode +B était, lui, déjà bon : les quatre robots le portent (+ixB) depuis leur redémarrage de 20:02:34, appliqué par init-server — c'est-à-dire que la préparation des .conf avait fonctionné du premier coup.

✅ L'exemption du gardien n'a rien masqué — elle a signalé le vrai manque

Quatre lignes error sont apparues à 20:07, et leur libellé est la preuve que l'exemption fonctionnait :

OverOp-H  error  état … : absent de : #!Bots!

« absent de », et non « en trop ». #!Bots! était devenu un salon attendu ; les robots n'y étant pas encore, le mécanisme a signalé qu'ils manquaient — ce qui était vrai. Les lignes ont cessé d'elles-mêmes à leur entrée : zéro après 20:11.

⚠ C'est le meilleur résultat possible, et il valait mieux que celui visé : on craignait un faux « surplus » de 288 lignes par jour et par robot ; on a obtenu un vrai « manquant », qui s'est résolu seul. Une exemption bien placée ne rend pas un mécanisme aveugle, elle lui donne la bonne attente.

✅✅ LES ROBOTS SONT PROTÉGÉS — 15/08/2026 à 20:19:36

INFO  Protection : services oui, robots oui, 5 robot(s) déclaré(s)

Les cinq portent +B et figurent dans protection.conf. protection_effet() le confirme un par un : « Protégé par la garde robots : déclaré ici ET porteur de +B. »

⚠ Écrit SANS accès au panel, mais PAS à la main. Le compte claude existe (niveau 100) et son mot de passe est haché — inutilisable. La sortie n'a pas été d'éditer le fichier, mais d'appeler protection_ecrire(), la fonction que le panel appelle : même composition, même écriture atomique (fichier temporaire puis rename), même validation des pseudonymes. Éditer le fichier aurait créé un second format, donc une seconde vérité — le défaut payé trois fois dans la seule journée du 15/08.

⚠ Le rechargement est resté un geste séparé, comme dans le panel : protection_appliquer() explique pourquoi — « recharger est un acte sur le service en production et on ne le fait pas à l'insu de celui qui a seulement coché une case ». Fait par reload (SIGHUP), et les 11 exceptions de salons sont restées chargées : aucune régression.

⚠ L'état d'avant, gardé pour mémoire — ce bloc était écrit en <details>/<summary> HTML jusqu'au 25/08/2026 ; le rendu du site échappe tout le HTML avant mise en forme, si bien que le visiteur lisait les balises en clair au lieu d'un repli.

⚠ Ce qui reste à trancher, et qui appartient à SerVuS : la section est au panel. Le site public n'a aucune page « robots » — ses 16 routes sont fixées, et son propre code prévient qu'au-delà de onze entrées la barre de menu déborde de son conteneur (site_nav()). Une 17ᵉ page publique, une greffe sur une page existante, ou le panel seul : la question n'est pas tranchée.

---

15. ✅ La veille de Windows gèle WSL — TRANCHÉ le 14/08/2026 : assumé, et tenu par un banc

⚠ DÉCISION D'EXPLOITATION, PAS UNE CORRECTION. Le gel n'est pas corrigé et ne le sera pas : un passage horaire tombant pendant une veille reste perdu. Ce qui a changé, c'est qu'on sait exactement ce qu'il coûte — un retard, jamais une donnée — et que la discipline qui rend ce coût acceptable ne repose plus sur la vigilance. Voir « Ce qui a été tranché » en fin de point.

Le corps ci-dessous est gardé tel quel : c'est lui qui porte la mesure, et les deux fausses pistes qu'il a fallu écarter.

Trouvé le 14/08/2026, en cherchant pourquoi IriX-sql.log s'était tu à 10:00:00.

Le fait : la machine hôte passe en veille moderne (Modern Standby), et WSL gèle avec elle. Un bind time Eggdrop se déclenche quand le processus voit passer la minute :00 — gelé à cet instant précis, le déclenchement est perdu, et Eggdrop ne le rejoue jamais.

Mesuré le 14/08/2026 : les scans horaires de 11:00, 12:00 et 13:00 n'ont pas eu lieu. Ni trace, ni erreur, ni signal — le mécanisme est sain, il n'a simplement pas été appelé.

Veilles et réveils de l'hôte (journal Windows Kernel-Power, ID 506/507) :

10:49:59  entrée en veille
11:30:32  sortie, puis ré-entrée aussitôt
12:22:27  sortie, puis ré-entrée
13:02:21  sortie, puis ré-entrée
13:13:35  sortie

Et les PING du serveur reçus par IriX : 10:49 · 10:55 · 11:30 · 12:22 · 13:13, puis une par minute à nouveau. 140 minutes sur 201 sans une seule ligne au journal. Les deux séries se recouvrent exactement — c'est ce recouvrement qui fait la preuve, aucune des deux ne suffisait.

⚠ uptime ne compte pas le temps gelé. Il annonçait 1h14 quand le bot tournait depuis 3h40 d'horloge murale ; la différence — environ 2h26 — est le gel. dmesg porte le hv_utils: TimeSync de la resynchronisation au réveil. Ne jamais lire uptime comme une durée de service sous WSL.

⚠⚠ Le keepalive n'y peut rien, et il n'est pas en cause. Service-Overtchat - WSL keepalive tournait pendant tout l'épisode — tâche Running, lanceur VBS actif, dernier passage à 13:26. Il maintient la distro vivante quand aucune session n'y est attachée, ce qui est un autre défaut. Rien du côté WSL n'empêche Windows de dormir.

Ce que ça touche : tous les bind time du projet — ::soc::scan::hourly et ::soc::scan::daily (IriX-binds.tcl:220-221). Le scan horaire porte le contrôle des prêts, la purge du plafond botreg et le scan WHO ; le scan quotidien porte la rotation des journaux.

⚠ Deux fausses pistes écartées, et elles menaient loin. Le journal IriX-sql.log a été accusé en premier — il accepte l'écriture : essai direct en ajout concluant, droits et disque bons, aucun attribut immuable. Puis une fuite de descripteurs a été supposée — 8 descripteurs ouverts sur une limite de 1024. Le journal ne se taisait pas : il n'avait plus rien à écrire. ⚠ Un journal muet fait accuser le journal ; c'est son producteur qu'il faut mesurer.

✅ Ce qui ne casse PAS, et il faut le dire : un seuil comparé à l'horloge murale se rattrape tout seul. suspendre_non_servis teste if {$duree < $seuil_min} { continue } (irix-mandat.tcl:1472) — un <, pas un ==. Un passage manqué est donc repris au suivant, avec le bon verdict et un horodatage décalé. C'est ce qui sauve le constat du point 11.

✅ LE CROISEMENT QUE CE POINT RÉCLAMAIT EST FAIT — 14/08/2026. Il demandait de chercher les déclencheurs qui comptent des passages plutôt que du temps, seuls à perdre vraiment des données. Mesuré :

Le projet compare du temps, pas des tours. Le risque que ce point redoutait ne s'est donc pas matérialisé — sauf en un endroit, et un seul : le scan quotidien, qui ne rejouait rien du tout parce qu'il ne partait jamais. C'est le point 16, ouvert et traité le même jour.

⚠ Le gel n'est pas corrigé, et un passage horaire tombant pendant une veille est toujours perdu. Mais il est désormais borné — on sait ce qu'il coûte (des passages, pas des données) et ce qu'il ne coûte pas. C'est ce bornage qui a rendu l'arbitrage possible.

Contre-épreuve du 14/08, qui vaut mieux qu'un raisonnement : passages horaires du jour à 10:00, 14:00 et 15:00, rien à 11, 12 ni 13 — machine gelée. Et entre 14:15 et 15:00, avec la machine éveillée, 46 minutes journalisées sur 46, gel cumulé figé à 2h23. Le mécanisme n'a jamais été en cause ; seule l'absence de la machine l'était.

✅ LA PISTE (b) N'EST PLUS UNE HYPOTHÈSE — elle a tourné le 14/08/2026 à 17:13:47. Le rattrapage du scan quotidien, écrit le jour même, s'est déclenché seul au premier démarrage qui a suivi : 33 secondes après le lancement du service, sans que personne le provoque. Le motif « un utimer qui se réarme + une garde sur le jour calendaire + une mémoire en base » fonctionne en réel, et non plus seulement au banc. Voir le point 16, clos.

⚠ Cela ne ferme pas ce point-ci, et il faut dire pourquoi. Le rattrapage rend un passage quotidien retrouvable ; il ne rend rien au passage horaire, qui reste perdu quand la veille tombe sur la minute :00. Le gel lui-même n'est pas corrigé — il est seulement contourné là où le contournement avait un sens.

Ce qui a été tranché — 14/08/2026, option (c)

SerVuS a délégué l'arbitrage : « fait tes propres choix ». Les trois pistes étaient (a) empêcher la veille de l'hôte, (b) rattraper au réveil comme le fait désormais le scan quotidien, (c) l'assumer.

C'est (c). Et ce n'est pas un renoncement : c'est ce que la mesure soutient.

Ce que (c) exige, en une phrase : tout seuil horaire se compare en < ou >= à l'horloge murale ou à la base, jamais à un compteur de passages. Le croisement montre la règle déjà respectée partout — zéro seuil sur un compteur de passages, 120 comparaisons à l'horloge.

⚠⚠ UNE DISCIPLINE QUI NE REPOSE QUE SUR LA VIGILANCE SE PÉRIME, et ce carnet en a la preuve à chaque page. C'est pourquoi (c) a été outillée le jour même plutôt que simplement décidée :

• la convention vit à côté du code, dans IriX-binds.tcl : chaque bind time porte une ligne # RATTRAPAGE: qui dit soit la procédure qui le rattrape, soit que son absence est ASSUMÉE et pourquoi. Une déclaration posée ailleurs se serait périmée sans qu'on la voie ;
• le banc IriX/tests/test-bindtime.tcl la tient : il dérive les bind time des sources — il n'en énumère aucun — et rougit sur un bind ajouté sans déclaration. 8 constats.

⚠ Ce que ce banc NE fait PAS, et il faut le savoir : il ne lit pas ce que fait la procédure liée. Une ligne « ASSUMÉ » posée sur un bind qui compte des passages le satisfait pleinement. Il constate une déclaration, pas sa véracité — c'est un point de passage obligé, pas une preuve.

⚠ Une mutation a été ratée au premier tour, et elle a corrigé le banc. Le constat « le rattrapage est appelé depuis admin::scan » se contentait de trouver le nom dans le corps : retirer l'appel en laissant la garde if {[llength [info commands …]]} le laissait vert. Or cette garde ne déclenche rien — elle vérifie que la procédure existe. Le banc gardait la porte en regardant la serrure. Corrigé, puis les cinq mutations attrapées.

⚠ Une autre a été attrapée avant elle, et du même genre : l'extraction du corps d'admin::scan par expression régulière rendait 266 146 caractères, soit la moitié du fichier. Le constat passait au vert en cherchant dans presque tout IriX-sql.tcl — vrai pour une mauvaise raison, ce qui est pire que faux. Remplacée par le comptage d'accolades de test-mandat.tcl, repris et non réinventé.

---

16. ✅✅ Le scan quotidien — CLOS le 14/08/2026, il s'est rattrapé tout seul

⚠ CONSTATÉ FERMÉ le 14/08/2026 à 17:13:47, quatre heures après l'avoir écrit — voir le constat en fin de point. Le service a redémarré de lui-même, admin::scan a appelé daily_rattrapage, et le scan quotidien a tourné pour la première fois depuis au moins le 27/07. Le corps du point est gardé tel quel : c'est lui qui dit pourquoi le défaut existait, et ce qu'il a fallu écarter.

Trouvé le 14/08/2026, en faisant le croisement que la ligne « Pour fermer » du point 15 réclamait. Le point 15 disait que le vrai risque était ailleurs ; il était là.

Le fait : ::soc::scan::daily est lié par bind time - "00 00 * * *" (IriX-binds.tcl:221) et s'ouvre sur if {$hour ne "00" || $min ne "00"} { return }. Or le service est arrêté chaque soir vers 21:00 et redémarré vers 09:00. Minuit tombe dans le trou, tous les jours.

2026-08-13T21:00:02  Stopping irix.service
2026-08-14T09:01:43  Started  irix.service

Mesuré le 14/08/2026 — quatre comptages indépendants, tous à zéro :

• 0 ligne journalisée à minuit dans les 14 archives du 31/07 au 14/08 ;
• 0 occurrence de « scan quotidien » dans journalctl, qui remonte au 27/07 ;
• 0 occurrence de « deauth quotidien », que seul daily écrit ;
• heures présentes dans les archives : 08 à 23, jamais 00 à 07.

Ce qui ne s'exécute donc jamais tout seul, chaque ligne vérifiée par la liste de ses appelants :

⚠ Une supposition écartée par la mesure : ia::daily_purge semblait sauvé par un second appel en IriX-sql-IA.tcl:1130. Cette ligne est dans ::soc::ia::pub_purge — la commande manuelle. Le fichier porte bien un utimer (l. 1174), mais il lance promote::evaluate, pas la purge. Compter les appelants ne suffit pas : il faut regarder dans quelle procédure chacun vit.

⚠⚠ Le commentaire de daily avait prévu le défaut sans voir par où il viendrait : « une procédure écrite mais jamais appelée est le défaut le plus discret de ce projet ... elle est ici parce que c'est le seul balayage quotidien ». hist::purger est appelée dans le code. C'est son déclencheur qui ne se déclenche pas. Un appel présent dans la source ne prouve pas un appel exécuté — et aucune relecture ne rattrape cela, seule une trace le fait.

✅ LE REMÈDE EXISTE DÉJÀ DANS CE DÉPÔT, ET IL TOURNE — DEUX FOIS.

• overtchat-backup.timer porte OnCalendar=*-*-* 04:00:00 et Persistent=true. Prévu à 04:00 pendant que la machine dormait, il s'est exécuté à 09:03:11 au réveil le 14/08 — sauvegarde et rotation comprises. Son propre commentaire le dit : « Persistent=true EST L'ESSENTIEL ICI, et pas un détail de confort ».
• irix-logrot.tcl fait la même chose en Tcl : ::soc::logrot::_due {policy last} compare la politique à la dernière exécution, jamais à l'heure courante. Constaté le 14/08 — la ligne « rotation planifiée (daily) » est écrite à 09:02:16, pas à minuit.

⚠ CE QUE LE SOMMEIL NE CASSE PAS — et il fallait le mesurer pour le savoir.

Un trou nocturne fait naturellement soupçonner tout ce qui est planifié. Mesuré le 14/08/2026 : le reste va bien, et chacun pour une raison qu'il faut garder ici, sans quoi on refera l'enquête.

⚠ Le cas de cron.daily a besoin de sa raison, sinon il sera rouvert : sur ses six tâches, quatre sont doublées par un minuteur systemd qui rattrape (apt-compat, dpkg, logrotate, man-db). Des deux autres, apache2 ne fait rien même lorsqu'il tourne — il sort sur [ "$HTCACHECLEAN_MODE" = "cron" ] || exit 0, et le mode est daemon — et aptitude se borne à archiver pkgstates dans /var/backups. Aucune dérive : /var/log à 862 Mo, disque à 2 %.

Le seul dégât du sommeil nocturne est donc ce point-ci, et c'est précisément ce qui le rend traitable : un endroit à corriger, pas une famille.

✅ LA MOITIÉ TECHNIQUE EST ÉCRITE ET DÉPLOYÉE — le 14/08/2026, commit 214cfaf. Le motif de logrot a été transposé, pas réinventé :

Le bind time de minuit est conservé pour le cas nominal ; la garde rend les deux chemins inoffensifs l'un pour l'autre, le second passage d'une même journée ne faisant rien.

⚠ Arbitrage tranché par SerVuS — option (a) : les deux remises à zéro globales entrent dans le rattrapage. Elles supposent que personne n'est connecté, ce qui est vrai à minuit et au réveil de la machine, le bot venant alors de démarrer. L'option inverse — les laisser au seul bind time — les aurait conservées dans leur défaut d'aujourd'hui : ne jamais tourner.

Éprouvé : daily_due juste sur cinq cas (mémoire vide, hier, il y a trois jours, aujourd'hui, mémoire illisible) ; mutation attrapée — remplacer le ne de la comparaison par eq fait échouer deux cas ; les quinze bancs Tcl qui lisent IriX-sql.tcl verts avant comme après, sur un arbre complet. ⚠ Un rouge de test-doublons a d'abord été imputé à tort : il venait d'un bac à sable où manquaient les .sql que ce banc compare — cible inexistante, « attendu » vide.

⚠⚠ DÉPLOYÉ SANS RECHARGEMENT, ET C'ÉTAIT DÉLIBÉRÉ. À 14:43 le fichier était en place, mais IriX tournait encore l'ancien code en mémoire : PID inchangé, zéro trace de rechargement, zéro « scan quotidien » au journal. Recharger sur-le-champ aurait déclenché le scan à une heure choisie au hasard — envois de courriels d'expiration compris.

✅ Et l'attente a payé deux fois. Le rattrapage a pris effet au premier démarrage venu, à 17:13:14, ce qui en fait un constat et non une démonstration (voir en fin de point). Et la précaution s'est révélée sans objet : aucun courriel n'est parti, faute de pseudonyme échu. ⚠ Ne pas en tirer que la précaution était inutile — elle était juste, et son coût était nul : trois heures d'attente pour une machine qui redémarre seule.

⚠⚠ ET LE RATTRAPAGE A RÉVÉLÉ UN DÉFAUT DANS CE QU'IL ALLAIT FAIRE PARTIR. La déauthentification quotidienne a été retirée le 14/08/2026 (5938c53), et non rattrapée.

Elle faisait onchan $nick sur [channels] seulement, et déauthentifiait qui ne s'y trouvait pas — exactement le raisonnement périmé corrigé dans ::soc::auth::scan le 03/08/2026 : un utilisateur identifié qui ne partage aucun salon avec IriX, cas normal de quelqu'un qui discute sur ses propres salons, est parfaitement connecté et se voyait déauthentifié. Le défaut avait survécu ici parce que ce scan ne partait pas — rien ne pouvait le manifester —, et il aurait frappé au premier rattrapage, sur de vrais utilisateurs.

Rien n'est perdu : ::soc::auth::scan fait ce travail toutes les 60 secondes, avec une garde de démarrage (« reset boot ») que le geste retiré n'avait pas, et en consultant le registre du lien en plus des salons du bot. ⚠ Ne pas le réintroduire « pour plus de sûreté » : une seconde autorité sur l'identification est une régression, pas une ceinture — celui des deux verdicts qui divergerait serait le nôtre, puisqu'il en sait moins.

⚠ La leçon dépasse ce point. Rendre joignable un code qui ne tournait pas, c'est réveiller tout ce qu'il contient — y compris ce que personne n'a relu depuis qu'il dort. C'est pour cela que les six gestes ont été repris un par un, et non pas seulement le mécanisme qui les appelle.

✅✅ LE CONSTAT A EU LIEU LE 14/08/2026 À 17:13:47 — CE POINT EST CLOS.

Il n'a pas été provoqué : la machine a redémarré d'elle-même à 17:13:12 (boot -1 clos à 17:12:37, boot 0 ouvert à 17:13:12 — un vrai redémarrage, pas une sortie de veille), le service est parti à 17:13:14, et 33 secondes plus tard le scan tournait. C'était le premier démarrage postérieur au déploiement de 14:43:34 : celui de 09:46 lui était antérieur, le code n'existait pas encore.

2026-08-14T17:13:47 [INFO] scan quotidien démarré
2026-08-14T17:13:47 [INFO] scan quotidien terminé

Les quatre exigences, une par une :

⚠ LA TRACE DE LA PURGE IA N'EST PAS DANS IriX-sql.log. Elle est écrite par putlog, donc dans IriX/runtime/IriX.log :

[14/08 17:13:47] SOC IA: purge quotidienne effectuee

La ligne « Pour fermer » de ce point disait de chercher « dans IriX-sql.log seulement ». C'est faux, et un grep obéissant y aurait conclu que la purge IA n'avait pas tourné. Les deux journaux servent, et ils ne portent pas les mêmes lignes.

✅ Ce que la passe a fait, et ce qu'elle n'avait pas à faire. Ce point redoutait qu'une purge muette depuis le 27/07 « ait beaucoup à faire d'un coup ». Mesuré : elle n'avait presque rien à faire, chaque table étant en deçà de sa rétention.

Contrôle croisé : zéro ligne au-delà de son seuil dans les trois tables datées.

⚠ hist::purger n'a rien retiré, et son SILENCE le prouve — elle ne journalise que si avant ne apres (IriX-sql.tcl:12054). Confirmé par les identifiants : chat_hist va de 1 à 54 sans trou, aucune ligne n'a jamais été supprimée. ⚠ En revanche ia_inbox commence à l'id 10 — des lignes plus anciennes ont bien disparu, mais rien ne dit que c'est cette passe-ci : le corpus a été purgé à la main deux fois selon le point 1. Un trou d'identifiants prouve une suppression, jamais sa date.

✅ AUCUN COURRIEL D'EXPIRATION N'EST PARTI, et c'était le risque assumé au déploiement. nickexpire::balayage a tourné sans rien envoyer : la dernière ligne d'IriX_mail_log date du 05/08, et son origine expiration-pseudo remonte au 05/08 également. Aucun pseudonyme n'était échu — le report du rechargement s'est révélé prudent pour rien, ce qui est le bon sens du terme.

---

1. ✅✅ L'IA peut s'amorcer seule — CLOS le 09/08/2026, RECONSTATÉ le 14/08/2026

Reconstaté le 14/08/2026, cinq jours après la fermeture : les trois gardes d'amorce_ok sont en place, test-ia-amorce.tcl passe ses 15 vérifications, antimot=oui en warn sur quatre salons, mode learn sur les quatre, les 17 mots du filtre présents et ia_tokens à 0 — l'état voulu. Rien n'a régressé ; il n'attend que du trafic réel, ce qui n'est pas un défaut.

Où : IriX-sql-IA.tcl, ::soc::ia::score (l. 417) et la branche d'apprentissage (l. 561-597).

Sans jeton, score rend {0.0 0}. Le score passe sous le seuil, et la branche else n'entraîne que si $sig >= $min_tokens — or $sig vaut 0. Le modèle bayésien ne peut donc jamais s'amorcer par lui-même.

Sa seule amorce : ::soc::ia::train_from_sanction, appelée par check_antimot_bridge (IriX-sql.tcl:11279) quand le filtre de mots sanctionne. Chaîne vérifiée complète le 07/08/2026. Elle part même en mode warn — sanctionner et entraîner sont deux gestes distincts.

Pourquoi rien n'était appris : antimot n'était actif que sur #Csadmin, un salon d'administration où personne ne jure. Activé sur #accueil et #membres le 07/08.

Mesuré le 09/08/2026 — ia_tokens vaut toujours 0, et le blocage a changé de nature :

• les 4 seuls messages jamais captés par l'IA sont sur #!Overtchat! (28/07 et 05/08), tous en score 0 et décision skip — le cercle vicieux, tel quel ;
• or antimot y valait non. Le seul salon qui avait vu du monde n'avait pas le déclencheur. Armé en warn le 09/08 ;
• sur #accueil et #membres, armés le 07/08 : aucun message capté en deux jours. Le journal du bot ne porte que ses propres gestes — topics et modes. Ce n'est pas un défaut de capture : personne n'a parlé.

Le blocage n'est donc plus un réglage, c'est l'absence de trafic. Les quatre salons publics portent maintenant antimot=oui en warn, et les 17 mots du filtre sont de portée globale.

✅ Le cercle vicieux est ROMPU dans le code, le 09/08/2026. analyse sortait par skip sans rien apprendre dès que $sig < $min_tokens — et avec zéro jeton, c'était toujours vrai. La sortie était sans retour.

::soc::ia::amorce_ok ouvre la seule porte défendable : apprendre good sur un message que le filtre déterministe vient de laisser passer. C'est la symétrie exacte de train_from_sanction — le même juge, l'autre verdict. La présomption tient parce que check_antimot_bridge filtre en deux couches et fait return dès qu'un mot interdit est trouvé : tout message qui atteint l'IA a déjà été jugé propre.

Trois conditions, chacune contre un défaut distinct : antimot doit être armé sur le salon (sinon personne n'a jugé, et présumer bon ce que nul n'a regardé revient à inventer un corpus), le mode doit être learn (en review/auto, un modèle ignorant apprendrait en masse pendant qu'il sanctionne), et $sig doit rester sous le seuil. ⚠ Elle s'éteint toute seule dès que le corpus atteint min_tokens : rien à débrancher, donc rien à oublier de débrancher.

Éprouvée par IriX/tests/test-ia-amorce.tcl, 15 constats et 4 mutations — dont la plus importante : retirer la garde antimot fait rougir le banc, ce qui prouve qu'il tient bien la porte par laquelle on inventerait un corpus.

✅ CONSTATÉ EN PRODUCTION le 09/08/2026 : la chaîne entière fonctionne. Sept messages ordinaires envoyés sur #accueil par un client IRC, avec l'accord de SerVuS. ia_inbox 4 → 11, ia_outbox 4 → 11, ia_log 0 → 7, et ia_tokens 0 → 68 au premier passage. Le cercle vicieux est rompu pour de bon : le modèle pose ses jetons dès le premier message ordinaire.

⚠ ET LE PREMIER TRAFIC RÉEL A MONTRÉ UN AUTRE DÉFAUT, plus grave — voir la 4.16.5 : la tokenisation coupait tous les mots accentués en deux. « découvre » donnait couvre, « réseau » donnait seau, « agréable » donnait agr + able. Un modèle de modération francophone bâti sur des moitiés de mots ne peut pas fonctionner. Corrigé, éprouvé, et reconstaté : les jetons sortent désormais entiers — agreable, reseau, redecouvre, francais, traite.

⚠ Le corpus a été PURGÉ après la preuve, deux fois : 68 jetons fragmentés, puis 42 jetons propres. ia_tokens est à 0 et doit y rester jusqu'à de vrais visiteurs. Le modèle ne doit pas apprendre son vocabulaire d'une machine — c'est la règle du carnet, et la preuve ne la lève pas. Les traces restent (ia_inbox, ia_outbox, ia_log) : elles n'entrent dans aucun score.

⚠ NE PAS injecter de jetons d'essai pour « prouver » que ça marche : du vocabulaire inventé fausserait durablement tous les scores futurs.

⚠⚠ ET TOUT ESSAI SUR UN SALON ARMÉ EN APPREND, MÊME SANS LE VOULOIR. Le 10/08/2026, quatre commandes !newban / !delban lancées sur #accueil pour éprouver la chaîne des bans ont fait passer ia_tokens de 0 à 16 — essai, bans, chaine, invalid, inewban, idelban. Personne n'avait injecté quoi que ce soit : amorce_ok apprend good sur tout message que le filtre laisse passer, et une commande en est un.

Le corpus a été purgé, et les traces conservées — ia_inbox, ia_outbox et ia_log n'entrent dans aucun score.

La règle qui en découle : un essai sur un salon où antimot est armé se fait sur #test, ou se termine par une purge. Les quatre salons publics sont armés depuis le 09/08 — il n'y a plus de salon « neutre » parmi eux.

---

2. ✅✅ Étendre le protocole en étoile — CLOS le 15/08/2026, une information a PASSÉ

⚠ CONSTATÉ FERMÉ le 15/08/2026 à 21:38:37, et par la seule preuve que ce point acceptait encore : une information a traversé le lien de botnet, les deux extrémités tracées.

21:38:37  IriX      .tcl ::soc::botnet::ping OverOp-T
21:38:37  OverOp-T  triggering bind ::overop::on_ping
21:38:37  OverOp-T  OVEROP: écho de IriX — répondu
21:38:37  IriX      triggering bind ::soc::botnet::on_pong
21:38:37  journal   observed · OverOp-T · « écho revenu en 0s — le lien porte »

Le lien lui-même est monté depuis 21:29:41 — challenge, réponse, « Relié à OverOp-T », socket ESTAB entre les PID 39327 et 42161 — et le module l'a constaté seul au cycle suivant : « observation — 1 lien(s) monté(s) », state = linked.

⚠⚠ Ce point a failli se fermer sur une preuve creuse, DEUX FOIS

Premier faux départ — le lien monté sans verbes. Le module faisait 802 lignes et rien ne pouvait y circuler : zéro bind bot, zéro putbot. Ce point annonçait trois réglages manquants ; il en manquait un quatrième, plus lourd. Sans lui, un lien monté aurait eu l'air parfaitement sain dans la page — et n'aurait servi à rien. C'est ce constat, fait le 15/08 en mesurant avant d'écrire, qui a durci l'exigence de fermeture : « constater qu'une information PASSE ».

Second faux départ — le transport écrit d'un seul côté. Les verbes posés, le lien monté, l'écho émis… et rien. overop.tcl n'avait aucun bind bot : IriX émettait, le lien portait la ligne, et le robot n'en savait rien. Pas de réponse, pas de trace, pas d'erreur — un silence. Le motif « à la jointure » du projet, refait le jour même où il était corrigé pour irix-edition.tcl.

⚠ Et le banc était vert sur ce transport à moitié écrit, parce qu'il ne lisait que les binds d'IriX. Un transport a DEUX extrémités ; un banc qui n'en regarde qu'une ne garde rien. Le §4bis de test-botnet-echo.tcl croise désormais les deux sources dans les deux sens.

Ce qui a été écrit, et ce qui a été refusé

⚠ Un écho, et rien d'autre. Faire transiter ici les ordres de prêt aurait dupliqué le protocole OverBot, qui les porte déjà par IRC avec UID vérifiable, plafond et corrélation — « lequel a raison ? » à chaque divergence. Ce que le botnet apporte et que l'IRC ne peut pas donner, c'est d'être hors du serveur : si le lien S2S tombe, les bots peuvent encore se parler.

⚠ Un pong ne répond jamais, des deux côtés. ⚠ L'horodatage est celui de l'émetteur, recopié tel quel : une seule horloge mesure. ⚠ Aucune migration : l'écho emploie les valeurs d'ENUM existantes plutôt qu'un ALTER qui pourrait n'être jamais appliqué.

IriX/tests/test-botnet-echo.tcl — 12 mutations, 12 attrapées, dont la reproduction des deux faux départs.

⚠ Les trois réglages, et ce qu'ils ont vraiment coûté

botnet-nick a été posé par script (ce n'est pas un secret) ; .+bot, .chaddr et .chpass ont été faits par l'exploitant, comme la règle l'exige.

⚠⚠ ET J'AI DONNÉ UNE SYNTAXE FAUSSE, qui a coûté deux essais. J'ai écrit .+bot OverOp-T 127.0.0.1:3344 — avec des deux-points. Eggdrop 1.10 attend l'adresse et le port séparés par une espace, et l'aide du bot le dit : chaddr <bot> <address> [[+]bot port[/[+]user port]]. Le userfile a donc enregistré --BOTADDR 127.0.0.1;3333:3333/3333 et le bot a cherché une machine nommée 127.0.0.1;3333. La ligne d'échec le disait en clair — Liaison avec OverOp-T at [127.0.0.1:3344]:3333 — et c'est elle qui a tranché, pas une relecture du code. Lire l'adresse que le bot annonce, jamais celle qu'on croit avoir posée.

---

2. L'historique de ce point — bascule de charge et objections d'origine

⚠⚠ CE POINT SE CONTREDISAIT LUI-MÊME, et pas par péremption — les deux phrases cohabitaient depuis le 12/08. Son titre annonçait « bascule de charge à écrire » quand sa propre ligne « Pour fermer », vingt lignes plus bas, la déclare écrite, éprouvée (32 constats, 9 mutations) et constatée en réel le 12/08 à 14:00:00. Trouvé le 13/08/2026 en mesurant le carnet avant de travailler dessus, et non par une relecture — c'est le seul geste qui attrape ce genre d'erreur.

📌 Ce que la ligne « Pour fermer » ferme, et ce qu'elle NE ferme PAS. Elle ne parle que de la bascule de charge. Le botnet, lui, reste ouvert : les trois réglages qui vivent hors de la base n'ont pas été posés, et rien ne montera sans eux — voir l'avertissement plus bas.

Le canal actuel a été mesuré le 09/08/2026, comme le demandait ce carnet. Il porte trois verbes : REOP montant, JOIN et PART descendants, plus les accusés.

Ce qu'il ne sait pas faire : rien de robot à robot, aucune commande d'administration à distance, aucune partyline commune, aucune bascule de charge.

⚠⚠ LE BOTNET A ÉTÉ ÉCARTÉ LE 09/08/2026, PUIS REPRIS LE 12/08 — les deux par SerVuS. Le carnet garde les deux décisions, et surtout les trois objections d'origine : elles n'ont pas été réfutées, elles ont été traitées une par une, et deux d'entre elles restent vraies.

Ce qui est livré le 12/08/2026 : irix-botnet.tcl (deux tables, une boucle d'observation à 60 s, l'exécution des actions du panel), test-botnet.tcl (50 constats, 8 mutations toutes attrapées), et la page botnet du panel.

⚠ Ce qui change vraiment, et c'est l'essentiel : jusqu'ici la page « Robots Eggdrop » AFFIRMAIT « aucun lien de botnet n'est monté » — en dur, dans le HTML, sans rien mesurer. Elle avait raison, et elle aurait eu tort le jour où un lien serait monté, sans que personne ne le sache. L'état est désormais constaté, et un état périmé y redevient inconnu plutôt que de mentir.

⚠ CE POINT N'EST PAS FERMÉ, et rien ne montera en l'état. Trois choses vivent hors de la base et n'ont PAS été posées : botnet-nick dans les cinq configurations, .+bot/.chaddr sur chaque console, et .chpass — le secret partagé, qu'aucun automatisme ne posera. Déclarer un pair dans la page sans les trois donne un lien qui échoue, et l'échec s'affiche dans l'activité. Ce point ne se fermera qu'après un lien CONSTATÉ monté entre deux bots, pas après le déploiement du code.

✅ LE TRANSPORT EXISTE DEPUIS LE 15/08/2026 — 4.17.2

Deux verbes circulent désormais sur le lien : SOC-PING et SOC-PONG, liés dans IriX-binds.tcl, émis par ::soc::botnet::ping via ::putbot.

⚠ Un écho, et rien d'autre — c'est délibéré. Faire transiter ici les ordres de prêt dupliquerait le protocole OverBot, qui les porte déjà par IRC avec UID vérifiable, plafond et corrélation. Ce que le botnet apporte et que l'IRC ne peut pas donner, c'est d'être hors du serveur : si le lien S2S tombe, les bots peuvent encore se parler. L'écho mesure ce chemin-là.

IriX/tests/test-botnet-echo.tcl : 26 constats, 7 mutations, 7 attrapées — dont « faire répondre on_pong » (la boucle infinie) et « faire passer un BOTCMD par le botnet ».

⚠ botnet-nick est posé dans les cinq configurations — ce n'est pas un secret. Les deux autres réglages manquent toujours : .+bot/.chaddr et surtout .chpass, le secret partagé, que ce projet ne pose jamais par script.

⚠⚠ CE BANC GARDE LA FORME DU TRANSPORT, PAS SON SERVICE, et il l'écrit à chaque passage : aucune ligne n'a circulé. Le point reste donc ouvert — il ne se fermera qu'après avoir vu une information PASSER, comme la section ci-dessous l'exige depuis ce matin.

⚠⚠ CE QUI MANQUAIT — mesuré le 15/08/2026, corrigé le jour même

Ce point annonçait qu'il manquait trois réglages. Il en manque un quatrième, et il est plus lourd : le transport n'a aucun verbe. Dérivé des sources, jamais lu dans un document :

irix-botnet.tcl fait 802 lignes et 19 procédures — elles déclarent les pairs, observent leur état, journalisent les transitions et exécutent les actions du panel. Aucune ne porte de verbe. Le module monte et surveille un tuyau dans lequel rien ne peut passer.

⚠ Ce n'est pas un défaut du module : il fait exactement ce qu'il annonce, et son banc le prouve. C'est le point 2 qui promettait plus que le code ne livre — « la partyline commune et l'administration à distance » supposent un transport, et le transport n'existe pas.

⚠ Ce que ça change pour la fermeture de ce point : « un lien CONSTATÉ monté » ne suffira pas comme preuve. Un lien monté sans verbe est un lien qui ne sert à rien, et il aurait l'air sain dans la page. Il faut constater qu'une information PASSE, pas qu'un socket est ouvert.

✅ En revanche les robots communiquent DÉJÀ, et par un autre chemin — qui marche. Il ne faut pas le confondre avec le botnet, et ce carnet le dit ailleurs sans le rappeler ici :

⚠⚠ Un bind msg sur IriX NE VERRAIT RIEN, et s'y tromper coûterait une journée : IriX n'est pas un client Eggdrop connecté au serveur, c'est un lien de service. Ses deux bind pubm servent au pont antimot/IA, pas au protocole des robots.

📌 Et propager l'AUTHENTIFICATION par le botnet serait une régression, pas un raccourci. La question s'est posée le 15/08 : « auth validé sur un Eggdrop → tous les autres ». Mesuré — overop.tcl:12 le dit lui-même, « IL NE TOUCHE JAMAIS MySQL » —, un OverOp n'a aucune commande utilisateur et aucune notion d'auth : il exécute des ordres, il ne juge rien. L'auth vit en base (${t}_users.auth), écrite par IriX seul, relue par require_grade à chaque décision. Il n'y a donc rien à refaire un par un aujourd'hui.

Le jour où les robots prêtés auront leurs propres commandes, le besoin naîtra — et la réponse n'est toujours pas le botnet : copier l'auth dans quatre robots, c'est quatre révocations à réussir là où il n'y en a qu'une. La désauthentification est déjà différée de 4 s exprès et auth::scan repasse toutes les 60 s. Le canal BOTREQ/BOTRES existe et garde une seule autorité — c'est là qu'un verbe « cette personne est-elle authentifiée ? » doit aller. Voir la règle déjà écrite au point 16 : « une seconde autorité sur l'identification est une régression, pas une ceinture. »

⚠ Le parc, remesuré le 14/08/2026 : quatre robots pour 80 places — OverOp-H, -Q, -S, -T, vingt places chacun, tous online. OverOp-T s'est ajouté le 11/08, posé par l'installation automatique, d'où son origin = auto. ${t}_botreg ne porte toujours aucun enregistrement.

⚠⚠ LA CHARGE ANNONCÉE ICI ÉTAIT PÉRIMÉE DE DEUX JOURS. Ce point disait « un seul salon » et « #membres est fini ». Mesuré le 14/08 : deux mandats actifs.

Le second est le prêt d'essai du point 11, posé le 13/08 pour éprouver la suspension. ⚠ Il se périme seul le 16/08 : la charge repassera à un salon sans que personne n'y touche, et cette ligne redeviendra fausse dans l'autre sens. C'est précisément pourquoi le paragraphe suivant dit de mesurer plutôt que de lire — un chiffre de charge ne survit pas à trois jours dans ce projet.

✅ DEUX CHOSES QUE CE POINT NE DISAIT PAS, constatées le 14/08/2026 :

• la boucle d'observation tourne vraiment. ${t}_botnet.seen_at était à 15:55:41 à l'instant de la mesure — le cycle de 60 s vit, sans qu'aucun lien ne soit monté ;
• un pair est déjà déclaré : OverOp-H sur 127.0.0.1:3341, ajouté le 12/08 par « essai-12/08 », en état unlinked. Il ne monte pas, faute des trois réglages ci-dessous — ce qui est exactement ce que le point annonce.

⚠ ${t}_botnet_log ne porte que 4 lignes, toutes du 12/08, et ce n'est PAS une panne : le module ne journalise que les changements d'état, jamais chaque observation. Un silence y signifie « rien n'a bougé », pas « rien ne tourne ». Confondre les deux ferait rouvrir un point sain — c'est le même piège que le ia_tokens à 0 du point 1, et que le silence de 20:00 au point 11.

⚠ Ces deux chiffres se périment, comme tous ceux qu'on écrit à la main : c'est exactement ce qui est arrivé à « trois robots sur 60 places », vrai le 09/08 et faux deux jours plus tard sans que rien ne le signale. Se mesurent — SELECT COUNT(*), SUM(max_chans) FROM ${t}_botreg_pooshy pour le parc, ${t}_mandat WHERE etat='actif' et ${t}_botreg pour la charge, les deux dédoublonnées comme le fait salons_attendus. Ou, plus court, .bots sur la console d'IriX.

✅ L'état poussé est écrit (09/08/2026, BOTSTAT) : chaque robot annonce toutes les 5 minutes les salons qu'il occupe vraiment, et OverBot journalise l'écart avec ce que la base attribue. Il ne corrige rien — on regarde vivre avant de laisser une machine en corriger une autre.

⚠⚠ « La charge d'un robot » vivait à TROIS endroits, et les trois ne comptaient que la moitié. Mesuré le 11/08/2026, dès que le premier prêt a tourné pour de bon. Un robot sert un salon pour l'une de deux raisons — l'enregistrement OPMYBOT (${t}_botreg) ou le prêt (${t}_mandat) —, et les trois compteurs ne lisaient que la première :

⚠ Le troisième s'est vu en RENDANT la page, pas en lisant le code. Les deux premiers corrigés, ?p=robots annonçait toujours 80 : le compte du site est en PHP et fait sa propre requête. Corriger deux copies sur trois ne corrige rien.

✅ LE BANC DE CROISEMENT EXISTE — Web/tests/test-charge.php, écrit le 12/08/2026. Il croise les deux implémentations restées indépendantes (le Tcl, et le SQL du site — charges compte par salons_attendus et n'en fait pas une troisième) : les deux sources, etat = 'actif', le dédoublonnage, la casse, et les deux chemins d'écriture. Plus un croisement de comportement sur les données réelles, recoupant le SQL avec un compte direct.

⚠⚠ ET CETTE LIGNE DISAIT « ELLES SONT D'ACCORD AUJOURD'HUI ». C'ÉTAIT FAUX. Le banc l'a montré en une passe : elles divergeaient sur la casse. Le NOT IN du site est soumis à la collation utf8mb4_uca1400_ai_ci et ignore la casse ; lsearch -exact la distinguait. Or #Accueil et #accueil sont un seul salon — le serveur ne les sépare pas, et le robot annonce toujours la casse du serveur.

Le même salon prenait donc deux places du parc pour le bot et une seule pour le site ; pire, l'écart se signalait à chaque BOTSTAT pour un robot à sa place — une ligne error toutes les cinq minutes, 288 par jour de prêt. C'est très exactement le défaut corrigé en 4.16.29, retrouvé par une autre porte.

⚠ La porte était ouverte des deux côtés, par le même geste. botreq_deposer et ::soc::mandat::accorder vérifient l'existence du salon par un SELECT channel … WHERE channel = … — comparaison insensible, donc « #Accueil » passe pour « #accueil ». Les deux lisaient la valeur canonique et la jetaient, écrivant la casse saisie. Corrigé aux deux endroits (4.16.40).

⚠ Aucune relecture ne l'aurait montré, et deux bancs verts le couvraient déjà chacun de son côté. C'est le croisement qui l'a trouvé — et c'est pourquoi ce carnet le réclamait.

⚠ Et le dédoublonnage n'est pas un détail : un salon peut être cité par les deux tables — un propriétaire enregistre son robot là où un prêt court déjà. Deux COUNT(*) additionnés le compteraient deux fois.

Mesuré le 09/08/2026 — les écarts valent zéro, et l'attente n'y changera rien. Les trois robots émettent bien leur BOTSTAT toutes les 5 minutes : constaté au journal du lien, trois lignes par cycle, corrélations qui se suivent. Chacun annonce zéro salon. Et ${t}_botreg est vide : la base ne leur en attribue aucun. Deux listes vides ne peuvent pas diverger, et stat_ecart ne journalise que l'écart.

La condition de ce point ne se remplit donc pas toute seule. Il faut d'abord un prêt réel pour que BOTSTAT ait quelque chose à comparer.

✅✅ ET LE PREMIER PRÊT A EU LIEU LE 11/08/2026 À 13h44. OverOp-H sert #accueil, mandat actif, présence constatée. La condition de ce point est donc remplie — les prochains BOTSTAT porteront un salon au lieu de zéro, et l'écart entre ce que la base attribue et ce que les robots servent devient enfin lisible.

⚠⚠ Il a fallu corriger le défaut qui l'empêchait depuis toujours. ::soc::mandat::consommer écrivait le mandat et s'arrêtait là : aucun ordre d'entrée ne partait. installer existait depuis le 05/08, mais son seul appelant était la commande IRCop MANDAT — le chemin du site, celui qu'un propriétaire emprunte vraiment, ne l'appelait jamais. Le panel annonçait un robot accordé, le salon ne voyait rien venir.

⚠ Aucun banc ne pouvait le voir : ils éprouvaient accorder et installer séparément, et toutes deux étaient justes. Le trou était à la jointure. C'est le quatrième du même genre sur ce chantier.

✅✅ LE PREMIER BOTSTAT PORTANT UN SALON A ÉTÉ LU LE 12/08/2026 À 09:56 — c'est ce que ce point attendait depuis le 09/08 :

:10AAAAAAB PRIVMSG 003AAAAAD :BOTSTAT 1 r1786521360-1 OverOp-H #accueil
[09:56:00] OVEROP: état r1786521360-1 poussé — 1 salon(s) : #accueil

Les trois autres robots annoncent zéro salon, OverOp-H annonce le sien. Et le prêt a survécu à un redémarrage complet de la machine : coupée pour la nuit, relancée à 09:51, le robot est entré sur #accueil à 09:51:50 sans que personne y touche.

⚠ L'écart vaut zéro, et le silence est ici une PREUVE, pas une absence — mais il a fallu la faire dire à autre chose qu'au vide. traiter_stat ne journalise que l'écart : rien au journal se lit aussi bien « tout concorde » que « le code ne tourne plus ». La preuve est différentielle et elle est dans ${t}_botreg_log : douze lignes en trop : #accueil, une toutes les cinq minutes du 11/08 13:48 au 14:58, puis plus une seule après le correctif — les BOTSTAT, eux, continuant d'arriver.

⚠ Ne PAS lire seen_at comme cette preuve. Elle est fraîche (09:58:41), mais elle est écrite par le sondage d'OverBot (irix-chanq.tcl), pas par le traitement des états. Chercher qui ÉCRIT la colonne, jamais qui semble la remplir.

✅ LA BASCULE DE CHARGE EST ÉCRITE — 4.16.48, le 12/08/2026. ::soc::mandat::bascule_charge, appelée au passage horaire, juste après le balayage des prêts échus. Les prêts dont le robot est absent depuis 30 minutes passent au robot le moins chargé qui ait de la place.

⚠⚠ La garde qui compte plus que le reste : si AUCUN robot n'est joignable, rien n'est basculé. ${t}_online est vidée par un HUP — au cycle suivant, tout le monde paraît absent, et une bascule naïve les déplacerait tous, sur personne. Quand tout le monde est absent, ce n'est pas eux, c'est nous.

Les autres : l'écriture d'abord et l'ordre ensuite · la base relue après écriture · le robot tombé jamais choisi comme repreneur · aucun PART à un absent · « aucun repreneur » dit, jamais contourné · les opérateurs prévenus.

⚠⚠ Et le banc a attrapé une collision de noms avant tout déploiement : ::soc::mandat::basculer existait déjà (suspension d'un prêt), et une seconde définition du même nom écrase la première sans un mot en Tcl. La commande de suspension aurait cessé de fonctionner en silence. Vérifier qu'un nom de procédure est libre avant de l'écrire.

Éprouvée par IriX/tests/test-bascule.tcl — 32 constats, 9 mutations toutes détectées.

✅✅ CONSTATÉE EN RÉEL LE 12/08/2026 À 14:00:00 — c'est ce que ce point attendait. OverOp-S arrêté à 13:11, seuil de 30 minutes franchi, passage horaire :

14:00:00  bascule : #membres repris par OverOp-H (à la place de OverOp-S, absent)
14:00:00  bascule : 1 repris, 0 sans repreneur, 0 refus
14:00:07  accusé o1786536000-2 de OverOp-H — done (#membres)

Le mandat est réécrit, l'ordre part, le robot accuse, et les opérateurs sont prévenus par un GLOBOPS nominatif. Le choix du repreneur est juste : OverOp-H paraissait le plus chargé, mais le prêt de #accueil est arrivé à échéance à la même seconde, le ramenant à zéro salon — à égalité avec Q et T, l'ordre alphabétique tranche. ⚠ Une prévision faite une minute plus tôt annonçait OverOp-Q : la charge se mesure au moment où la bascule décide, pas avant.

⚠⚠ ET LE SALON N'A PAS ÉTÉ SERVI POUR AUTANT. Une minute après :

14:01:00  écart d'état pour OverOp-H — absent de : #membres

#membres porte +ntR, et les robots portent +ix — ils ne sont identifiés auprès d'aucun service. Le serveur refuse donc leur entrée (ERR_NEEDREGGEDNICK), et channel.c dit en toutes lettres que même un opérateur du réseau n'y échappe pas : +R est une promesse faite aux membres, pas une sanction. Aucun des quatre robots ne peut servir #membres — le défaut n'est pas dans le choix du repreneur, il est plus haut. Voir le point 11.

⚠ Le robot l'a dit lui-même au nettoyage, et c'est la confirmation la plus nette : « je n'étais pas sur #membres — désactivé ».

⚠ Ancien contenu du « pour fermer », gardé pour la mémoire du chantier. ⚠⚠ Ceci était écrit en commentaire HTML — donc censé rester invisible — et le carnet étant rendu en entier sur le site, le visiteur le lisait, balises comprises. Corrigé le 25/08/2026 : ce qui doit être invisible n'a rien à faire dans un fichier publié ; ce qui doit rester se dit en clair.

3. ✅✅ Le webchat — CLOS le 12/08/2026, l'historique s'affiche

⚠ Ce point disait trois manques ; deux étaient faux ou le sont devenus. Mesuré le 09/08/2026, sur un chat.js de 3 000 lignes qui n'a de sommaire que la description qu'on en faisait.

• pas de messages privés — périmé : ils ont leur onglet, leur compteur de non-lus, leur fermeture et leur modération (Web/inc/chatmod.php, migration 014-chat-prive.sql) ;
• ✅ pas de reconnexion automatique — écrite le 09/08/2026, et CONSTATÉE en réel le même jour, dans un vrai navigateur, sur le site public. Coupure à 13:47:01, nouvelle socket à 13:47:03 : les 2 secondes annoncées. Les deux salons ouverts sont retrouvés, et IriX_online a bien vu revenir la connexion sous un UID neuf. ⚠ Sans ré-identification : finConnexion efface le mot de passe exprès, et le garder en mémoire de page pour un confort affaiblirait une précaution existante. Décidé par SerVuS.

⚠ Le constat a trouvé ce qu'aucun banc ne pouvait voir. Le chat écrivait « Rien de ce que vous avez écrit n'est perdu », puis effaçait le fil entier deux secondes plus tard : la reprise passait par le même chemin qu'une connexion neuve. Relevés à 0,3 s (message affiché, bandeau « Nouvelle tentative dans 2 s… ») et à 2,6 s (fil retombé à trois lignes, tout disparu). Corrigé en 4.16.4 — la reprise garde les fils, les onglets et les privés, et ne jette que ce que le serveur va redonner ;

• ✅ l'historique manque — écrit le 09/08/2026, en base et par compte, comme tranché. Trente jours, purgés par le balayage quotidien.

L'obstacle était d'architecture : le webchat parle en WebSocket directement au serveur IRC, le site ne voit passer aucun message. C'est IriX, présent sur les salons, qui écrit (::soc::hist::ecrire, branchée au pubm) ; le site relit sous garde (?p=chat-hist).

⚠ Qui peut relire quoi, et cela se redemande à chaque relecture, jamais à l'écriture : l'identification est exigée partout, même sur un salon public — sans quoi l'historique deviendrait une archive du réseau relisible sans laisser de nom. Sur un salon restreint, être identifié ne suffit pas : il faut y avoir un rôle, sinon le +R ne vaudrait que pour le direct. Si la lecture des modes échoue, le salon est supposé restreint — le défaut prudent refuse.

Constaté en réel le 09/08 : appelée à la main sans session, l'adresse refuse en le disant. 28 constats dans test-chathist.php.

✅ L'ÉCRITURE EST CONSTATÉE le 09/08/2026 : IriX_chat_hist 0 → 7. Sept messages envoyés sur #accueil, sept lignes en base, avec le salon, le pseudonyme, le texte et l'horodatage. ::soc::hist::ecrire fait donc bien son travail — ce n'était plus qu'une question de trafic, comme ce carnet le supposait. Les lignes sont conservées : elles serviront au dernier constat.

✅ Et elles sont trente au 11/08/2026, sans que personne les ait posées : la table a plus que quadruplé toute seule depuis le constat. L'écriture ne tient donc pas qu'à une séance d'essai — elle suit le trafic ordinaire. ⚠ Ne pas recopier « 7 » d'ici : c'était le compte d'un après-midi, pas une propriété du mécanisme.

✅ La garde a été constatée depuis le VRAI chat, le 09/08 : un visiteur non identifié qui rejoint #accueil lit « Identifiez-vous pour relire l'historique de ce salon ». Le webchat appelle donc bien la route et affiche sa réponse — ce n'est pas un texte écrit en dur dans la page.

✅ ET LA LECTURE AUSSI, le même jour, sur la route rendue hors navigateur : sans session, elle refuse ; avec une session de pseudonyme, elle laisse passer et rend les 7 lignes avec leur pseudonyme et leur horodatage. Les quatre cas du verdict ont été éprouvés un par un.

⚠ chanaccess_role() ne rend que trois valeurs — proprietaire, ircop, aucun. Un essai qui lui passe op ou voice éprouve une valeur hors domaine et fait croire à un défaut : j'ai cru un instant qu'un opérateur de salon était refusé à tort sur un salon restreint. Il n'y a pas de défaut ; seuls proprietaire et ircop passent, et c'est ce que le code et ce carnet disent tous les deux.

✅✅ LE DERNIER MAILLON EST TOMBÉ LE 12/08/2026 À 11:20:32 — ce point est CLOS. SerVuS a ouvert le webchat identifié sur #accueil, et le journal du site porte l'appel :

[Wed Aug 12 11:20:32 2026] 127.0.0.1 [200]: GET /?p=chat-hist&c=%23accueil&n=20

200, pas 403 : la garde a laissé passer, ce qui n'arrive qu'à un visiteur identifié — le refus avait été constaté dans l'autre sens le 09/08. Et il y avait de quoi rendre : #accueil porte 18 lignes, la plus ancienne du 09/08, la plus récente du jour même.

⚠ Ce que le 200 prouve, et ce qu'il ne prouve pas. Il prouve que la route a répondu à une session identifiée. Que les lignes se soient bien peintes à l'écran, c'est le rapport de l'exploitant qui le dit — un code HTTP ne voit pas un navigateur. Les deux ensemble suffisent : le webchat appelle la route et affiche sa réponse, ce qui avait déjà été constaté pour le refus.

4. ✅ L'installation automatique — la POSE est close, reste le prêt (point 2)

⚠ « Décidé, pas écrit » était faux à moitié, mesuré le 09/08/2026. Les quatre garde-fous étaient écrits depuis longtemps (::soc::botreg::pool_verdict), la table posée, l'unité overop@.service en service. Ce qui manquait, c'était l'exécutant : personne ne lisait les lignes pending du pool.

✅ Écrit le 09/08/2026 — Tools/overop-pool.php, plus son unité et son timer dans Config/systemd/. Il pose un robot par passage : répertoire, liens vers IriX/, configuration substituée, userfile engendré par -m, puis systemctl enable --now. Ce qui décide est sorti dans Web/inc/botpool.php et éprouvé par 24 constats et 4 mutations — dont douze noms de travers, OverOp-h/../.. compris : ce nom devient un CHEMIN, dans un script qui tourne en root. Retirer les ancres de la forme imposée fait rougir le banc, ce qui prouve qu'il garde bien cette porte-là.

✅ L'unité est installée et le timer est ACTIF — constaté le 09/08/2026 (systemctl is-active overtchat-botpool.timer). Il tourne à vide : ${t}_botreg_pool est vide.

✅ LA POSE RÉELLE A ÉTÉ FAITE le 10/08/2026, autorisée par SerVuS — la première jamais tentée. Elle a révélé TROIS défauts, chacun caché derrière le précédent, et il a fallu quatre passages pour les voir tous. Rien de tout cela ne se lisait dans le code, et les 24 constats étaient verts.

1. L'exécutant exigeait le fichier des utilisateurs juste après -m. Or -m ne le crée pas : il met Eggdrop en attente d'un maître. Le script ne pouvait donc jamais aboutir, et il rendait failed sur une pose parfaitement réussie.
2. Le robot naissait dans le vide. overop.conf désigne tout en relatif ; lancé depuis Web/, Eggdrop ne trouvait pas son script. ⚠ L'unité systemd pose un WorkingDirectory — d'où des robots posés à la main qui marchaient et un robot du pool qui ne démarrait pas.
3. Le robot mourait avec le service qui venait de le poser. Type=oneshot sans KillMode : le groupe entier est tué au retour. « Posé, il attend son hello » et « SIGNING OFF » portent la même seconde au journal.

⚠ Et il doit survivre : eggdrop -n, la forme de systemd, refuse de démarrer sans le fichier des utilisateurs (« USER FILE NOT FOUND! »). Le cercle se referme, et systemd-run le rompt sans toucher à aucune unité installée.

✅ CONSTATÉ : OverOp-T est posé sur le port 3344, il écoute, son unité transitoire est active, et il figure dans ${t}_online — il est sur le réseau. Il attend son hello.

✅✅ LE hello A ÉTÉ DONNÉ LE 11/08/2026 À 11h35, PAR SerVuS — ET LA CHAÎNE A ABOUTI SEULE. Le minuteur est repassé à 11h40 et a fait tout le reste sans qu'on y touche, en six secondes :

11:40:13  userfile trouvé — le hello a eu lieu.
11:40:19  ✅ OverOp-T est sous systemd et actif.

Constaté juste après : overop@t.service active et enabled, l'unité transitoire inactive, le processus relancé sous la forme -n de systemd, la demande du pool passée à done. C'est la première pose de robot du projet qui va d'un bout à l'autre.

⚠⚠ ET ELLE A RÉVÉLÉ LE QUATRIÈME DÉFAUT, qui ne pouvait pas se montrer avant. Le robot était posé, actif, sur le réseau — et ${t}_botreg_pooshy ne le connaissait pas. L'exécutant s'arrêtait à systemctl is-active sans jamais déclarer le robot au parc. Conséquence : ::soc::botreg::charges ne le voyait pas, aucun salon ne pouvait lui être confié, et la demande s'écrivait quand même done. Une pose qui aboutit à un robot inutilisable est une pose qui a échoué.

Corrigé le jour même : l'exécutant déclare désormais le robot avec origin='auto' — une valeur qui existait dans le schéma depuis l'origine sans que personne ne l'écrive. ⚠ Sans rien écraser si la ligne existe déjà : un robot déclaré à la main porte peut-être un max_chans choisi ou un enabled='non' volontaire. OverOp-T, dont la demande était déjà done, a été rattrapé à la main. Le parc annonce quatre robots et 80 places.

⚠ La pile de défauts de ce chantier compte donc QUATRE étages, tous découverts en faisant tourner, aucun en relisant — et le quatrième a attendu trois semaines qu'un hello soit donné.

5. ✅✅ Le lot 3 — CLOS le 12/08/2026, RECONSTATÉ le 14/08/2026

⚠ Ce titre annonçait « les deux derniers droits d'écriture » jusqu'au 14/08/2026, alors que sa propre ligne « Pour fermer » le déclarait FERMÉ — les deux derniers, autolimit et autobans, étant ouverts depuis les 10 et 11/08. Même contradiction que le point 1, trouvée le même jour et par le même geste : mesurer le point avant d'y travailler.

Reconstaté le 14/08/2026 — les cinq réglages du lot existent en base, sont offerts par le panel, et sont en service : autolimit=oui sur quatre salons, autobans=oui sur quatre, automode_user=oui sur deux, automode_chan=+ntR sur #membres. autoop reste à non partout, ce qui est normal : le droit d'écriture est ouvert, la case n'est simplement pas cochée — les deux ne se confondent pas. test-chanreglages.php rend 205 constats, 0 échec.

✅ autoop et automode_user ouverts le 09/08/2026, décidés par SerVuS. Ce qui a fait pencher : les grades par salon ne servaient à rien sans eux. Un propriétaire posait un grade, et il ne se passait rien — automode_user n'étant armé que sur #!Overtchat! et #Csadmin. La page offrait un réglage décoratif. ⚠ chan_access est d'ailleurs vide : personne n'a jamais posé de grade par salon.

⚠ Un défaut réel a été trouvé en chemin : les valeurs par défaut étaient écrites en dur DANS chanreglages_lire(), une seconde liste des mêmes clés. Ouvrir deux réglages sans qu'elle suive faisait disparaître $reg['autoop'] de la page — case vide, et un propriétaire qui croit son auto-op éteint. Le banc était vert : il n'éprouvait pas cette liste-là. Les deux listes sont désormais croisées par test-chanreglages.php (86 constats).

Ce qui reste fermé, et pourquoi :

⚠ « Rien ne dit à quoi ils serviraient » était FAUX, mesuré le 09/08/2026. Le code le dit très bien : les deux sont écrits, câblés et appelés. Ce qui manquait, c'était la mesure, pas la conception. Les 14 colonnes d'auto_config ont été croisées avec leur usage réel — chacune passe par un ::soc::auto::get, aucune n'est décorative. Il n'y a pas de réglage fantôme ici, contrairement à ${t}_commands, qui n'est jamais lue.

✅ automode_chan — ouvert le 09/08/2026, en CASES À COCHER, tranché par SerVuS.

Le danger n'était pas le réglage, c'était la saisie. Le bot envoie la chaîne telle quelle (puthelp "MODE $chan $modes"), sans autre contrôle qu'une longueur de 50 : un seul espace y glisserait +o quelquun, et un propriétaire se donnerait l'op par le robot du réseau. Six cases suppriment ce risque par construction — il n'y a plus de chaîne à saisir.

Les six modes offerts (+n, +t, +m, +s, +R, +C) n'ont aucun paramètre et ne ferment pas le salon. Ceux qui l'enferment (+i, +k, +l) et ceux qui prennent un pseudonyme (+o, +b) restent hors de portée.

✅ +O s'y est ajouté le 10/08/2026 — en SEPTIÈME case, réservée aux opérateurs du réseau. Demandé par SerVuS pour #!Services!. Il est sans paramètre, comme les six autres ; ce qui le met à part, c'est qu'il ferme le salon : un propriétaire ordinaire le rendrait inaccessible à ses membres et à lui-même, sans retour possible.

⚠ Trois pièges traités, et le troisième n'était pas évident : la garde est à l'écriture, pas dans le formulaire (un POST fabriqué porterait O tout aussi bien) · un mode qu'on n'a pas le droit de poser est un mode auquel on ne touche pas — sinon le premier enregistrement d'un propriétaire aurait envoyé -O et défait le mode d'un opérateur · et le verrou ne doit pas se refermer sur celui qui vient de poser le mode.

⚠ Décocher retire vraiment. Le bot n'envoie qu'un seul MODE : écrire +nt après avoir décoché m laisserait le salon modéré pour toujours. La chaîne stockée porte donc les deux — +ntR-msC. Forme éprouvée sur le vrai serveur le 09/08, en IRCop sur un salon d'essai.

⚠ Un salon réglé par un opérateur est verrouillé. Si la chaîne en place porte un mode hors liste, les cases passent en lecture seule et l'écriture refuse en nommant le mode : les enregistrer l'effacerait sans que personne l'ait demandé.

Éprouvé par test-chanreglages.php, 144 constats et 8 mutations. Deux d'entre elles ont trouvé un trou : le verrou des modes d'opérateur était écrit en ligne dans la fonction d'écriture, et le neutraliser laissait le banc vert. Il a été sorti en fonction pure — et un constat vérifie maintenant qu'il est appelé, pas seulement défini.

✅ l'historique de modération — le point était FAUX, mesuré le 09/08/2026. Il visait IriX_modq, qui est bien vide. Mais l'écran ne lit pas cette table. chansanctions_liste() (Web/inc/chanreglages.php) croise IriX_events et IriX_ia_log, et Web/site/salonadmin.php le rend déjà au propriétaire, sous le titre « Ce qui a été sanctionné ici ». Le code sait même dire le vide et pourquoi, quand il n'y a rien.

Constaté en production, page rendue hors navigateur, sans aucune notice PHP : 5 lignes sur #accueil, 5 sur #!Overtchat!, 4 sur #Csadmin, 2 sur #!Services!.

⚠ Ce qui s'affiche est du résidu d'essais — EssaiAuth, TestOwner, Spammeur, Troll. L'écran fonctionne ; le réseau n'a simplement jamais sanctionné personne pour de vrai.

⚠ Quatre KICK y figurent EN DOUBLE, tous antérieurs au 25/07/2026 : deux chemins d'écriture, l'un portant la raison et l'autre non. Le défaut est corrigé depuis — c'est la raison d'être d'irix-modtrace.tcl (25/07). Rien de neuf ne double ; ce sont les lignes déjà écrites qui restent. Les effacer serait un DELETE en production pour du confort d'affichage : non fait.

✅ autolimit OUVERT le 10/08/2026, tranché par SerVuS — et un défaut a dû être fermé avant, trouvé en relisant le code plutôt qu'après coup.

Éteindre le réglage ne retirait jamais le +l : do_autolimit sort aussitôt quand il ne vaut pas oui, et rien n'envoyait le -l. Le salon serait resté plafonné à sa dernière valeur, et il aurait fallu un opérateur pour libérer les places. La case aurait été un piège — c'est le travers déjà corrigé pour automode_chan, retrouvé par l'autre porte.

⚠ Le chemin qui compte est celui du panel, pas celui de !autoset : le site n'écrit qu'en base et ne parle pas au robot. Le retrait part donc de scan_config, à la relecture des 30 s, et l'ancienne valeur ne s'y lit qu'avant de vider le cache.

⚠ La QUATRIÈME liste des mêmes clés a été trouvée en chemin — la requête de chanreglages_lire() énumérait ses colonnes à la main, après la liste close, les libellés et les défauts. Ouvrir un réglage sans qu'elle suive l'aurait rendu invisible : page à la valeur par défaut, base à oui. Elle est désormais dérivée. Croisements ajoutés, 171 constats, 11 mutations toutes détectées.

✅ CONSTATÉ EN PRODUCTION le 10/08/2026, dans les DEUX sens, sur #accueil — un vrai salon, en écrivant en base exactement ce qu'écrit le panel :

12:18:08 [DEBUG] autolimit: #accueil +l 3 (1 users)
12:18:38 [INFO]  autolimit: #accueil -l (reglage eteint)

La limite se pose au cochage, calculée sur les présents, et elle repart au décochage. Aucun refus du serveur.

✅ ET LE PROPRIÉTAIRE L'A COCHÉE POUR DE VRAI, le 10/08/2026 à 19h25 — ce que la ligne « pour fermer » réclamait. Mesuré le 11/08 : autolimit vaut oui sur quatre salons (#!Overtchat!, #accueil, #Csadmin, #membres), tous modifiés entre 19h25 et 19h26, et le journal du bot porte MODE #<salon> +l 3 sur chacun au démarrage de ce matin. Le geste est venu du panel, pas d'un UPDATE de laboratoire : c'est le constat par un vrai propriétaire, sur un vrai navigateur, que ce point attendait.

⚠ Cette section a dit « l'état d'origine (non) a été remis » pendant une nuit, et c'était vrai — à 12h18. Sept heures plus tard, quelqu'un cochait la case, et la phrase devenait fausse sans que personne l'ait touchée. Un état écrit dans un carnet vieillit tout seul : celui-ci n'est resté juste qu'un après-midi.

⚠ Le premier essai portait sur #test et ne prouvait rien : ce salon a une ligne dans auto_config depuis le 07/08 mais n'existe pas sur le réseau — channels n'en porte que cinq. Le serveur répondait 403 :No such channel. Choisir la cible avant de lire le résultat.

⚠ Et l'essai réel a trouvé ce qu'aucun banc n'avait vu : la pose ne partait pas quand le robot n'avait pas encore lu le salon. Sur un cache vide, les deux lectures rendent la même valeur, on lit « oui → oui », et aucune transition n'est détectée. La pose ne regarde donc plus que la nouvelle valeur ; seul le retrait garde la transition.

✅ autobans OUVERT le 11/08/2026, tranché par SerVuS — et ce n'est pas la table vide qui était le vrai obstacle.

Le premier !newban réel a bien été posé ce jour-là. Mais en mesurant avant d'ouvrir la case, un défaut plus grave est tombé : DEUX chemins appliquaient les bans persistants au JOIN, tous deux branchés sur bind join - "*" :

Le réglage ne commandait donc rien : les bans s'appliquaient partout quoi qu'on coche, et deux fois quand la case l'était. Ouvrir la case en l'état aurait offert un bouton décoratif — le travers corrigé deux fois sur ce même écran, pour automode_user puis autolimit.

Le bloc en double est retiré. ⚠ Conséquence assumée et voulue : les bans persistants ne s'appliquent plus que sur les salons où la case est cochée. Elle vaut non partout au 11/08.

⚠⚠ ET UNE GARDE A DÛ ÊTRE POSÉE DANS LE BOT, sans laquelle cette case serait une arme. check_autobans n'exemptait personne : un masque assez large — et *!*@* est écrivable par un !newban d'op — faisait kicker au JOIN quiconque entre, le bot et les opérateurs du réseau compris. ⚠ L'exemption posée le même jour dans le serveur n'y changeait rien : elle dispense du +b, pas du putkick, qui ne demande l'avis de personne. Deux gardes à deux étages, et il fallait les deux.

⚠ Un op de salon n'est pas exempté, et c'est voulu : sanctionner un habitué turbulent est précisément l'usage de ce réglage.

⚠ Décocher n'enlève pas les +b déjà posés, contrairement à autolimit — et là non plus ce n'est pas un oubli. Un +l est un plafond calculé que le bot doit défaire ; un +b est une sanction que quelqu'un a voulue. La page le dit, avec le fait que les bans du réseau (channel = '*') s'appliquent aussi.

Éprouvé par test-chanreglages.php, 205 constats et 8 mutations toutes détectées — dont celle qui garde le défaut inverse, exempter aussi les op de salon.

✅ COCHÉ PAR SerVuS LE 12/08/2026, sur QUATRE salons — #accueil, #membres, #Csadmin et #!Overtchat!, entre 11:23:32 et 11:24:02, depuis le panel. La case commande donc quelque chose pour de bon, sur de vrais salons. #!Services! reste à non.

✅ ET LES GRADES PAR SALON SONT ÉPROUVÉS EN RÉEL, le même jour. ${t}_chan_access était vide depuis sa création : le mécanisme n'avait jamais servi. Un grade op posé pour un compte existant sur #!Overtchat!, le compte entre, et IriX pose le +o tout seul :

:IriX!IriX@… MODE #!Overtchat! +o ClaudeOps

⚠ Le salon doit avoir automode_user armé — il ne l'est que sur #!Overtchat! et #Csadmin. Ailleurs le grade est posable et sans effet, ce que ce carnet annonçait déjà. ⚠ Et il ne vaut que pour un compte authentifié : auth armée juste avant, retirée après. Ligne d'essai supprimée, la table est revenue à zéro.

✅✅ L'AUTRE MOITIÉ EST CONSTATÉE — 12/08/2026, 15:20. Ce point est CLOS.

Un !newban visant ClaudeOps!*@* — ce seul pseudonyme, aucun visiteur possible — posé sur #Csadmin, puis deux entrées sur le salon, une par état du grade. Aucun banc ne pouvait le donner ; un client d'essai le lit très bien.

⚠⚠ LES DEUX PASSES SONT INDISPENSABLES, et la seconde plus que la première. « Je n'ai pas été expulsé » se lit aussi bien « l'exemption tient » que « le ban ne mord pas ». Sans la passe 2, ce constat n'aurait rien valu.

⚠⚠ ET LA PASSE 2 MONTRE EN DIRECT CE QUE CE CARNET ANNONÇAIT SANS L'AVOIR VU. Le serveur a envoyé sa notice dans les deux cas — « un ban vous barrait l'entrée, votre statut d'opérateur du réseau vous en dispense » — et le bot a expulsé quand même. L'exemption du serveur dispense du +b, pas du putkick : deux gardes à deux étages, et c'est celle du bot qui décide.

⚠ Le journal du bot le corrobore, indépendamment du client d'essai — même seconde, même verdict : autobans: ClaudeOps épargné sur #Csadmin — grade réseau, puis autobans: ClaudeOps!*@* appliqué sur ClaudeOps/#Csadmin.

⚠ Ce n'est PAS le statut IRCop du serveur qui exempte, et s'y tromper coûte cher : check_autobans appelle require_grade $nick admin, qui lit ${t}_users — jamais l'état IRC. Un opérateur du réseau sans ligne en base, ou non authentifié, est expulsé comme un visiteur. C'est exactement ce que la passe 2 a produit : ClaudeOps était IRCop sur le serveur tout du long.

Nettoyage constaté : table des bans à zéro, -b retiré du salon, auth désarmée, et ia_tokens toujours à 0 — l'essai n'a rien fait apprendre au modèle.

⚠⚠ !b N'EST PAS !newban, ET LA DIFFÉRENCE EST TOUT L'ENJEU. Essayé le 11/08/2026 sur #!Overtchat! : !b SerVuS a bien posé le MODE +b *!*@… à 11h43:51, retiré à 11h44:37 — la commande marche. Mais ::soc::pub_ban pose un mode et journalise, sans rien écrire en base : c'est un ban de salon, volatil, que le bot ne repose pas. ${t}_bans est restée vide, et autobans reste donc bloqué exactement comme avant l'essai.

Seule ::soc::ban::add — la commande !newban — écrit la ligne persistante avec son échéance, et c'est cette table-là que check_autobans consulte au JOIN. Deux commandes voisines par le nom, deux mécanismes sans rapport.

✅ Et l'essai n'a rien appris à l'IA : ia_tokens est resté à 0, ia_inbox à 13. Contrairement aux !newban du 10/08, qui avaient fait apprendre seize jetons, ces commandes-ci ne sont pas remontées jusqu'au pont. ⚠ Vérifier quand même après coup reste la règle — c'est en mesurant qu'on le sait, pas en le supposant.

⚠ Une vigilance qui n'est pas un défaut : avec autolimit armé sur #accueil, le salon d'accueil du réseau porte en permanence un +l. Il se recalcule à chaque JOIN et chaque PART, donc il ne ferme la porte à personne tant qu'IriX écoute. Mais il ne se recalcule que par IriX : le bot absent, la dernière valeur reste posée. Ce n'est pas une raison de retirer le réglage — c'est une raison de compter le +l d'#accueil parmi ce qu'une panne d'IriX emporte avec elle.

6. ✅✅ Le message d'accueil — CLOS, le minuteur tourne depuis le 12/08/2026

⚠ Un /REHASH lancé depuis IRC échappait à tout. Les deux accroches de overtchatd.service — ExecStartPost au démarrage, ExecReload après un systemctl reload — couvrent les rechargements demandés à systemd, et eux seuls. La commande REHASH tapée par un opérateur dans son client appelle ircd_rehash() (src/cmd/m_oper.c), donc conf_load(), donc msgfilter_load() : les motifs sont relus, le filtre change d'état, et systemd n'en sait rien.

Vider filtre-messages.conf puis /REHASH coupait donc le filtre en laissant le message d'accueil promettre la protection à chaque connexion. C'est le défaut du 02/08/2026, retrouvé par l'autre porte le 09/08.

✅ Écrit le 09/08/2026 — Config/systemd/overtchat-motd.{service,timer}, un passage toutes les 5 minutes. On constate l'état plutôt que d'espérer avoir intercepté tous les événements qui le changent, comme pour overtchat-opers.

Trois choses mesurées avant d'écrire : le générateur est déjà idempotent (il sort sur « déjà à jour » quand le texte composé est celui en place) ; un passage coûte 0,13 s ; et aucun rechargement n'est nécessaire — send_motd() (src/s_user.c) rouvre le fichier à CHAQUE connexion, donc réécrire suffit.

Rattrapage prouvé de bout en bout sur la production : fichier d'accueil remplacé par une ligne d'essai, un passage du générateur, retour à l'empreinte SHA-256 identique, 52 lignes, promesse de filtrage rétablie. Éprouvé aussi par test-motd.php, 43 constats et 6 mutations.

✅✅ INSTALLÉ, ACTIF ET enabled — constaté le 12/08/2026. Le geste demandé ci-dessous a été fait entre-temps : overtchat-motd.timer est active et enabled, et il est passé à 11:13:37. Il figure parmi les cinq minuteurs en service (opers, botpool, motd, chanq-mail, backup).

⚠ Ce point réclamait un geste déjà accompli. C'est le septième point périmé de ce carnet, et il l'était par le temps, pas par erreur : il disait vrai le jour où il a été écrit. Mesurer le point sur lequel on travaille, au moment où l'on y travaille — systemctl is-active répond en une seconde.

7. ✅ LA SAUVEGARDE EXISTE ET SE RESTAURE — constaté le 11/08/2026 à 18h57

Le point le plus grave de ce carnet est fermé, et il l'est par CONSTAT.

Archive	overtchat-Maverick-20260811-185701.tar.gz.gpg, 4,4 Mo
Chiffrement	PGP symmetric key encrypted data — AES 256 bits, salted & iterated, SHA512
Base	dump de 1,2 Mo, 58 tables — le compte exact
Restauration éprouvée	567 fichiers, 14 Mo, dans un répertoire temporaire

⚠ La restauration est la seule preuve qui compte. Le script vérifie lui-même son archive (« intégrité vérifiée ») — cela ne dit pas qu'on saura la rendre. Elle a donc été restaurée pour de vrai, et son contenu recoupé pièce par pièce.

⚠⚠ Et c'est cette restauration qui a trouvé le trou : Servers/overtchat-hybrid/ en était absent — 31 414 lignes de C, le serveur du projet. Le motif */Servers visait les 130 Mo de serveurs tiers décompressés et emportait au passage les 1,2 Mo du seul écrit ici. Corrigé le jour même : les tiers sont désormais dérivés de ce que git ne suit pas, jamais énumérés.

Ce que l'archive ne prend pas, et qui est documenté dans BACKUP.md : /home/servus/overtchatd/ (configuration du serveur en service), /home/servus/overop-{h,q,s,t}/ (les userfiles des robots — trou trouvé le 11/08, il n'était signalé nulle part), les secrets IRCop et la phrase de chiffrement — ces trois derniers volontairement.

✅ ET LE MINUTEUR A TOURNÉ, LE 11/08 À 19:36 — constaté, sans attendre 04:00. Le journal montre que c'est bien systemd qui lance, pas une main :

19:36:19  systemd[1]: Starting overtchat-backup.service…
19:36:20  ✔ Archive : overtchat-Maverick-20260811-193619.tar.gz.gpg (4,4M)
19:36:20  systemd[1]: Finished — status=0/SUCCESS

⚠ La méthode, réutilisable pour tout minuteur trop long à attendre : un override temporaire qui remplace OnCalendar par OnActiveSec, avec AccuracySec=1s et RandomizedDelaySec=0 — les valeurs par défaut (5 min et 2 min) décaleraient le déclenchement de sept minutes, et l'on attendrait sans savoir si c'est raté.

sudo mkdir -p /etc/systemd/system/overtchat-backup.timer.d && printf '[Timer]\nOnCalendar=\nOnActiveSec=15min\nAccuracySec=1s\nRandomizedDelaySec=0\nPersistent=false\n' | sudo tee /etc/systemd/system/overtchat-backup.timer.d/essai.conf && sudo systemctl daemon-reload && sudo systemctl restart overtchat-backup.timer

⚠⚠ À RETIRER APRÈS L'ESSAI, sinon la sauvegarde repart 15 min après chaque démarrage : sudo rm -rf /etc/systemd/system/overtchat-backup.timer.d && sudo systemctl daemon-reload && sudo systemctl restart overtchat-backup.timer

Le texte ci-dessous est celui d'avant les deux gestes, gardé pour ce qu'il apprend.

Mesuré le 11/08/2026, et c'était le point le plus grave de ce carnet. ~/.config/overtchat/backup.pass n'existait pas, ~/Sauvegardes/ ne portait qu'un dump SQL manuel du 25 juillet. Le mécanisme était écrit depuis juillet, documenté sur 230 lignes, et il n'avait jamais tourné une seule fois.

BACKUP.md conseillait un crontab -e et notait deux lignes plus bas que WSL ne démarre pas cron. La consigne se contredisait elle-même : la suivre à la lettre ne sauvegardait rien, et rien ne le disait.

✅ Écrit le 11/08/2026 — Config/systemd/overtchat-backup.{service,timer}, un passage par jour à 4 h, base comprise. ⚠ Persistent=true est l'essentiel : la machine ne tourne pas à 4 h, et sans cette ligne le minuteur ne partirait jamais sans que rien ne le signale.

⚠⚠ Et la première exécution réelle a rendu deux défauts que rien ne laissait voir — l'archive pesait 201 Mo pour 180 Ko annoncés (un motif d'exclusion visait un niveau trop haut et ne matchait rien), et --restore <archive> <cible>, seule façon documentée de restaurer sans risque, mourait sur « Option inconnue ». Le geste qu'on fait le jour où tout a brûlé était impossible. Les deux sont corrigés, éprouvés de bout en bout, et couverts par Web/tests/test-backup.php (42 constats, 9 mutations).

✅✅ ET LE RATTRAPAGE A ÉTÉ CONSTATÉ LE 12/08/2026 — la seule promesse de ce mécanisme qui n'avait jamais été éprouvée. La machine était éteinte à 04:00, l'heure du minuteur. Elle a démarré à 09:51, et :

09:52:57  systemd[1]: Starting overtchat-backup.service…
09:52:59  ✔ Archive : overtchat-Maverick-20260812-095257.tar.gz.gpg (4,4M)
09:52:59  systemd[1]: Finished — status=0/SUCCESS

Une minute et demie après le démarrage, sans aucune intervention. C'est Persistent=true qui fait exactement ce pour quoi cette ligne a été écrite — et la machine ne tournant jamais à 4 h, c'était la seule chose qui séparait ce mécanisme de l'inutilité complète.

⚠ Le contenu a été recoupé, pas seulement l'existence : 640 entrées, dont 175 pour Servers/overtchat-hybrid/ — le trou trouvé la veille est bien refermé dans une archive produite par le minuteur, et non à la main — plus le dump du jour et le chiffrement AES-256 (cipher 9). « Intégrité vérifiée » ne dit toujours pas ce qu'il y a dedans : on regarde dedans.

✅✅ ET LA SAUVEGARDE QUITTE LA MACHINE DEPUIS LE 12/08/2026, 12h10. C'était le trou que ce point ne nommait pas : archives, phrase secrète et projet vivaient tous les trois sur le même disque, sans copie nulle part. Une sauvegarde qui ne quitte pas la machine protège d'une erreur, pas d'une panne.

L'archive part désormais sur le disque USB de la Freebox à chaque passage, et c'est constaté par un contre-constat indépendant du script — on relit le disque distant par un autre chemin :

overtchat-Maverick-20260812-121022.tar.gz.gpg   4 595 840 octets ici, 4 595 840 là-bas

✅ Et la rotation distante suit, constatée le même jour à 12h23 (4.16.46) — garder=30 à distance contre 7 en local, le distant étant la copie de survie. Éprouvée en réel en abaissant garder à 1 le temps d'un passage : « 2 archives, on garde les 1 plus récentes », la vieille est partie, et le reste du disque est intact — Photos, Vidéos, la copie du projet.

⚠⚠ C'est du code qui supprime sur le disque de quelqu'un d'autre, et cinq gardes le tiennent : le motif overtchat-*.tar.gz.gpg et rien d'autre · -type f et -maxdepth 1 · un listage impossible ne supprime rien · aucune archive reconnue ne supprime rien · l'archive du jour est écartée de la liste, jamais seulement sautée dans la boucle.

8. ✅✅ L'exemption des opérateurs — CLOS, éprouvé en réel le 12/08/2026

✅ Écrit le 11/08/2026. Un opérateur du réseau passe désormais outre les sanctions et les barrières d'accès d'un salon — +b, +m, mute, +i, +k, +l, l'attente après expulsion —, mais pas outre les promesses faites aux membres : +z, +R, +M, +O. Et il l'apprend par une notice, à chaque fois : une exemption silencieuse ferait conclure que la restriction ne fonctionne pas.

Campagne tests/test-oper-outrepasse.py — 22 vérifications, 5 mutations. Les seize campagnes du serveur passent contre le binaire compilé avec ce correctif.

✅ DÉPLOYÉ ET CONSTATÉ le 11/08/2026 à 12h50, avec l'accord de SerVuS. Le binaire neuf est en service (overtchatd créé à 12:50:28), et tout est revenu : les huit unités actives, les cinq pseudo-clients réintroduits, les quatre robots présents — dix connectés en base —, et le serveur répond son 001 à une sonde.

⚠ L'ancien binaire est conservé en /home/servus/overtchatd/bin/overtchatd.avant-4.16.24. Un retour arrière tient en deux gestes : mv de l'ancien à la place, puis sudo systemctl restart overtchatd.service.

⚠ Deux pièges pendant la pose, tous deux déjà nommés dans le carnet : on n'écrase pas un binaire en cours d'exécution — copier à côté puis mv, qui est atomique, jamais install qui tronque —, et sudo EXIGE le suffixe .service. Sans lui, la commande a demandé un mot de passe et est restée suspendue, le binaire déjà remplacé et le service pas encore redémarré.

✅✅ CONSTATÉ PAR SerVuS LE 12/08/2026 À 11h18 — ce point est CLOS. Il l'a rapporté, et ${t}_chat_hist le corrobore à la seconde près, indépendamment de son rapport :

11:18:42  SerVuS : !b SerVuS
11:18:43  IriX pose MODE #!Overtchat! +b *!*@aodxl5.olsury.18pt7j.IP
11:18:44  SerVuS : test
11:18:49  SerVuS : je suis banni
11:19:28  SerVuS : je suis passé ircop
11:19:32  SerVuS : je peut parlé

Les messages sont écrits APRÈS la pose du ban qui le visait. C'est le constat que ce point attendait depuis le 11/08, et il ne pouvait venir que d'un vrai opérateur sur le vrai réseau.

⚠ Ce que la trace montre, et ce qu'elle ne montre pas. Elle prouve qu'il a parlé sous un ban. Elle ne distingue pas à elle seule l'exemption d'opérateur d'un +o de salon, qui dispense aussi du +b — c'est le rapport de l'exploitant qui tranche, et sa ligne « je suis passé ircop » puis « je peut parlé » dit l'ordre des choses. La notice, elle, ne se lit que dans son client : elle n'est écrite nulle part en base.

---

14. ✅✅ La nomenclature des grades — CLOSE le 14/08/2026, éprouvée dans les deux sens

Ouvert le 13/08/2026, sur décision de SerVuS d'unifier le vocabulaire vers le sien : Net-admin · Admin · Chef-de-bot · Opérateur · Xop · Helpeur.

📄 Tout est dans Markdown/GRADES.md — les six vocabulaires mesurés, ce que chaque grade peut faire réellement, et la table de correspondance à corriger.

⚠⚠ CE N'EST PAS UN RENOMMAGE. Mesuré : trois des six noms n'ont aucun équivalent dans ce qui décide — Chef-de-bot (rien), Xop (n'existe que dans l'installateur et les commandes Anope, et Anope n'est plus en service), Helpeur (rien du tout). Et deux grades en service ne sont pas nommés dans la liste : owner (le propriétaire d'un salon) et voice.

✅ Un danger annoncé par le carnet a été écarté par la mesure. La clause_exempt du balayage d'expiration — celle qui supprime les comptes non exemptés — lit des colonnes (csowner, csadmin, csop, csvoice), jamais des noms de grades. Un renommage de vocabulaire ne l'atteint pas. ⚠ Ce qui impose en retour : ne pas renommer les colonnes cs*.

⚠ Le carnet disait « cinq vocabulaires ». Il y en a six — celui du panel manquait, et c'est le seul que l'exploitant voie en se connectant. Il disait aussi « coadmin n'existe dans rien de ce qui décide » : vrai du Tcl du bot (zéro occurrence), faux du panel, où LEVEL_COADMIN = 60 décide de ce qu'on peut ouvrir.

⚠⚠ CE POINT S'EST PÉRIMÉ EN UN JOUR, ET IL A FALLU LE MESURER POUR S'EN APERCEVOIR. Il annonçait « la table attend une décision » et « trois lignes vides ». Mesuré le 14/08/2026 : la table était tranchée depuis la veille, il n'y restait qu'une ligne ouverte, et deux des quatre étapes du §5 étaient déjà faites.

L'état réel, au 14/08/2026 :

✅ Le dernier trou de la table était comblé dans les faits. GRADES.md §4 disait d'owner (5) qu'il « reste à nommer » ; or Web/inc/chanaccess.php:77 rend déjà « Propriétaire », et la base décrit Propriétaire du salon. Confirmé par SerVuS le 14/08 — aucun travail technique n'en découle. Les deux affirmations périmées de GRADES.md ont été corrigées le même jour.

⚠ Deux fausses alertes écartées par la mesure, écrites pour ne pas être refaites :

• l'inversion owner/admin entre les deux échelles (owner(5) < admin(6) en base, admin < owner dans require_grade) n'est pas un défaut : GRADES.md §1 la documente — « les deux sont justes, sur deux échelles ». Elle ne paraît suspecte qu'au §4 lu seul ;
• ::soc::xdata ne lit pas le userfile malgré son nom, qui évoque le xtra d'Eggdrop : il fait des requêtes SQL sur ${t}_users. Le userfile ne porte que created comme champ XTRA, vérifié. Aucune migration à froid n'est nécessaire.

✅ L'ÉTAPE 4 EST ÉCRITE — 14/08/2026, commit e24288b. Trois clés renommées, sans accent ni tiret (tranché par SerVuS : ce sont des clés comparées par lsearch, jamais affichées, et une clé accentuée mal saisie donnerait un grade inconnu — que require_grade refuse par défaut) :

⚠ Mon estimation de périmètre, écrite ici même, était trop large : j'annonçais que les 8 cas du switch de ::soc::xdata devaient bouger. Faux. get_grade traduit déjà — les cas s'appellent isop, isvoice, isauth, déjà différents des grades rendus. Seules les valeurs de retour changent. Le vrai périmètre : la liste, six return, dix-neuf appels — tous littéraux, aucun via variable, donc tous repérables.

⚠⚠⚠ UN TROISIÈME DÉBORDEMENT, ET IL EST RESTÉ ROUGE SANS QUE PERSONNE LE VOIE — 14/08/2026, 18:20. Trouvé en passant le lanceur complet : test-commandes.php était le seul échec sur 69 bancs, et il l'était déjà avant la séance. Mesuré sur la prod pour ne pas s'accuser à tort : même rouge, même constat.

Le renommage de e24288b est à mi-chemin dans Web/inc/commandes.php — les commandes ont changé de grade, la table qui les libelle non :

Ce que rend le Tcl, dérivé de la source : netadmin · proprietaire · admin · operateur · voice · user. Trois noms de la page n'y sont plus (ircops, owner, op), et deux noms du Tcl manquent à la page (operateur, proprietaire).

⚠⚠⚠ ET « 66 COMMANDES À RENOMMER » ÉTAIT FAUX — l'erreur était dans ce carnet, pas dans le code. SerVuS a demandé le renommage sur la foi du tableau ci-dessus. Mesuré avant de le faire, le 14/08 à 18:40 : il n'y a rien à renommer dans les commandes. Le seul défaut était que cmd_rangs() ne déclarait pas operateur ni proprietaire.

Ce que la mesure a montré, en lisant les gardes réelles plutôt que les noms :

⚠ Zéro require_grade … netadmin dans tout le projet — les trois occurrences trouvées sont des commentaires, et j'ai failli les compter (le grep initial ne les excluait pas). Le grade netadmin existe dans l'échelle et n'est exigé nulle part.

ircops n'est donc pas un ancien nom de netadmin : c'est le nom d'une autre autorité. Le renommer aurait fait rougir test-grades.php, qui dérive ircops de ces gardes-là — il aurait fallu truquer le banc pour faire passer le renommage. ⚠ Le nom suit l'autorité qui décide, pas l'inverse.

✅ DÉCISION DE SERVUS, 14/08/2026 : « laisse ircops comme ça ». Le choix inverse lui a été proposé avec son coût — vocabulaire uniforme, mais banc et règlement public à reprendre. La question est fermée, et ce paragraphe existe pour qu'on ne la rouvre pas à la prochaine lecture du mot « ircops ».

✅ Corrigé le 14/08/2026 : cmd_rangs() déclare désormais operateur (3) et proprietaire (5), op a disparu — plus aucune commande ne le portait —, et les deux clés qui ne sont pas des grades SQL disent maintenant ce qu'elles sont : ircops « vérifié auprès du serveur, jamais par un grade en base », owner (Eggdrop) « flag n du userfile, sans rapport avec la colonne csowner ». Leur description mentait plus discrètement que le rouge.

⚠ La mutation qui vaut plus que le reste : passer syncowner de owner à proprietaire fait rougir test-grades.php. Le renommage aveugle des 66 aurait donc été arrêté par un banc — mais seulement après l'avoir écrit. Mesurer les gardes coûte dix minutes, défaire un renommage en coûte davantage.

69 bancs au vert, 3874 constats — le rouge qui traînait depuis 15:41 est parti.

⚠ Pourquoi test-grades.php reste vert malgré cela : il croise la documentation affichée avec ce que le code exige, et ces 15 commandes sont cohérentes de ce point de vue. C'est test-commandes.php qui croise le grade employé avec la table des libellés. Deux bancs, deux questions — et seul le second voit ce trou. Un banc vert ne couvre que sa propre question.

⚠⚠ test-grades.php A ATTRAPÉ DEUX DÉBORDEMENTS, et c'est pour cela qu'il existe. Le premier : il croise la documentation affichée sur le site avec ce que le code exige — le renommage du seul Tcl a désaligné 23 commandes. Web/inc/commandes.php a suivi. Le second, plus fin : syncowner annonçait « owner » et je l'avais renommé avec les autres ; sa propre table le dit pourtant — « matchattr $hand n : owner EGGDROP, pas un grade SQL ». Deux mots identiques, deux autorités différentes. Remis en place.

Éprouvé : contrôle croisé (tout ce que get_grade rend existe dans order) · banc dédié à 11 cas dont les trois gardes contre l'erreur · mutation attrapée — remettre op dans order pendant que get_grade rend operateur refuse un opérateur partout · les 15 bancs Tcl verts · test-grades.php 29/0, test-chanaccess 48/0, test-colonnes 7/0, test-panel-account 15/0.

✅ LE REDÉMARRAGE QUE CE POINT ATTENDAIT A EU LIEU — 14/08/2026 à 17:13:14. Le commit e24288b datant de 15:41, les nouvelles clés sont en mémoire depuis. La condition est donc remplie : il ne manque plus que l'essai. ⚠ Et le symptôme annoncé plus bas ne s'est pas produit — require_grade refuse par défaut, donc un désaccord aurait fermé toutes les commandes d'un coup ; le service tourne depuis, sans plainte.

✅ LE ROUGE QUI TRAÎNAIT EST FERMÉ — 14/08/2026, 18:45. cmd_rangs() déclare operateur et proprietaire, op est retiré. ⚠ Aucune commande n'a été renommée : la mesure a montré que les 65 ircops et le owner de syncowner répondent à d'autres autorités que require_grade — voir plus haut. Six mutations attrapées, 69 bancs au vert.

✅✅ L'ESSAI EN SERVICE EST FAIT — 14/08/2026 à 18:43, ET DANS LES DEUX SENS. Une seule connexion, ClaudeOps en TLS sur 6697, sur #accueil :

sans auth   →  IriX NOTICE ClaudeOps :Accès refusé.
avec auth   →  IriX MODE #accueil +o ClaudeOps

Journal du bot : 18:43:37 [INFO] op ClaudeOps/#accueil par ClaudeOps, et ${t}_events porte le MODE +o et la trace mode +o ClaudeOps par ChanAdmin.

⚠ Le premier sens compte autant que le second. Un !op qui marche ne prouve pas que la garde tient — seulement qu'elle n'a pas mordu. C'est le refus sans auth qui montre que require_grade … operateur lit bien le grade, et le succès avec qu'il reconnaît le nouveau nom. auth a été remis à non aussitôt, et la connexion fermée.

⚠ CE QUI N'EST PAS ÉPROUVÉ, ET POURQUOI ON NE VA PAS L'ÉPROUVER : la moitié admin. ClaudeOps porte csop et rien d'autre, par une décision prise le 10/08 — « un accès de vérification n'a pas à pouvoir tout faire ». Lui donner csadmin pour un essai reviendrait à défaire cette décision pour la commodité d'une mesure. Ce qu'on sait à la place : admin est bien dans order ({user voice operateur admin proprietaire netadmin}), et le symptôme qu'annonçait ce point — require_grade refusant par défaut, donc toutes les commandes fermées d'un coup — ne s'est pas produit depuis le redémarrage de 18:30:19.

---

9. 🔨 Les quatre éditions — OUVERT le 14/08/2026, phases 1 et 2 FAITES, la 3 OUVERTE le 01/09 (écrivain posé, pas encore constaté sur machine nue)

Le 17/08/2026 — la phase 2 commence, et le plan mentait sur sept points

✅ Les quatre éditions s'exécutent enfin, dans les trois langages. Web/tests/test-edition.php passe de 19 à 43 constats. Avant ce jour, beta, standard et payante n'avaient jamais tourné nulle part : les trois lecteurs ne voyaient que complete, et le bac à sable du banc n'éprouvait les cas limites que dans un des trois langages — trou qu'il avouait lui-même dans son en-tête. Chaque lecteur est forcé par son propre point d'injection (ROOT, ::soc::script_dir, _edition_racine), sans jamais toucher à la configuration réelle.

⚠⚠ CE QUI RESTAIT DE LA PHASE 2 — REMPLI le 25/08/2026 (le texte d'origine est gardé : il dit la difficulté, et elle était réelle) : « les quatre campagnes passent » ne prouvera rien tant qu'aucune ligne ne se comporte différemment selon l'édition — tous les bancs rendraient le même résultat sous les quatre. ⚠ Le compte qui figurait ici — « 84 » — a été retiré le 24/08/2026 : il en annonçait 84 pour plus de cent. ./Tools/bancs.sh --liste les découvre par glob. Un banc qui ne peut pas rougir ne garde rien. Il faut donc une première différence de comportement, petite et sûre, avec le banc qui l'éprouve sous les quatre. C'est elle qui fera d'edition_au_moins autre chose qu'une fonction jamais appelée.

⚠⚠ ET Markdown/EDITIONS.md DÉCRIVAIT LE MONDE DU 11/08 — sept écarts, corrigés le 17/08. Le document qui pilote ce chantier affirmait :

Ce qu'il disait	Ce qui est
le champ edition n'existe pas (trois fois)	posé le 14/08
la phase 1 est à faire	faite le 14/08
la sauvegarde n'a jamais produit d'archive	close le 11/08 à 18 h 57, le jour même
la phase 0 est bloquante, le point 2 ouvert	point 2 clos le 15/08, phase 0 remplie
quatre autres points bloquants	tous clos
la question 5.5 est « encore ouverte »	✅ tranchée le 14/08 — contradiction avec son propre §5.5
la phase 5 « part de » la fonction sans_secret()	⚠⚠ elle n'existe nulle part dans le dépôt

⚠ Le dernier est le plus grave, et d'une autre nature : une date périmée se corrige en mesurant ; une fonction fantôme fait bâtir sur du vide, et faisait passer la phase 5 pour « largement livrée » alors que sa pièce maîtresse — le filtre qui retire les adresses et les secrets d'un rapport avant envoi — reste entièrement à écrire.

📌 Cette dernière ligne décrit le 17/08 et RIEN D'AUTRE — ne pas la relire comme du travail à faire. Le filtre a été écrit le 27/08/2026 (Web/inc/doctrine-rapport.php), et les deux chemins d'envoi qui lui échappaient encore ont été fermés le 28/08. Voir plus bas, « Phase 5 — les DEUX chemins d'envoi hors du filet sont fermés ».

⚠ La leçon vaut plus que les corrections : un plan qui se trompe sur son propre état ne se suit pas, il s'invente. CHANTIERS.md s'applique déjà la règle de mesurer chaque point au moment où l'on travaille dessus ; EDITIONS.md ne se l'appliquait pas, et six jours ont suffi.

⚠⚠ OUVERT SUR DÉCISION DE SERVUS, contre l'avis écrit ici même. Ce point disait « à ne pas démarrer maintenant » ; la réserve lui a été présentée avec son coût, et il a répondu « tout le chantier des éditions ». C'est sa décision, et elle est prise en connaissance de cause — le paragraphe d'origine est gardé plus bas, il dit pourquoi c'était risqué.

✅ La question 5.5, la dernière ouverte, est tranchée : dix installations au plus. Elle ferme le §6 plus qu'elle ne l'ouvre — la licence MIT impose de vendre le service (voie 1), il n'y a rien à payer pour distribuer, et un serveur de licences est sans objet à cette échelle. ⚠ Un seul point lourd survit : héberger les réseaux des clients est un autre métier, à dix comme à mille.

✅ PHASE 1 FAITE — le socle, et personne qui devine.

⚠ Le champ vit dans config.json pour une raison mesurée : ce fichier est déjà exclu de la surveillance de mise à jour (_upd_exclu), donc l'amont ne l'écrase jamais. C'est un fichier d'état propre à l'installation — exactement ce qu'une édition est.

⚠ Le défaut prudent FERME : champ absent, illisible ou inconnu ⇒ beta, la plus restreinte. Jamais la plus permissive. Et edition_au_moins compare des rangs, jamais des égalités — une édition demandée inconnue rend faux, comme require_grade refuse sur un grade inconnu.

⚠⚠ QUATRE PASSES DE MUTATION, ET DEUX COMMENTAIRES FAUX ÉCRITS EN CHEMIN. Le motif qui lit le champ doit éviter la note _edition, qui cite « beta » et « payante ». J'ai d'abord écrit que les guillemets protégeaient, puis — après une mutation restée verte — que c'était la forme [a-z]*. Les deux sont vrais, et chacun suffit seul : il faut casser les deux gardes ensemble pour que la note soit lue, ce que la quatrième passe a fini par montrer. ⚠ Une mutation qui ne rougit pas ne prouve pas que le code est solide — elle peut aussi dire que la mutation ne mord pas, ou que le cas de test compare deux valeurs identiques. Les deux se sont produits ici.

⚠ Ce que le banc n'attrape pas, et c'est écrit dans son en-tête : son bac à sable n'éprouve que le lecteur bash. Casser les deux gardes du motif Tcl le laisse vert. Le croisement des trois lecteurs limite les dégâts, mais seulement sur la configuration réelle.

✅ LE MODULE TCL EST CHARGÉ — ce paragraphe décrivait un défaut CLOS depuis le 15/08/2026 à 19:06:20 (point 18), et il l'a décrit au présent pendant deux jours. Corrigé le 16/08. Mesuré : IriX-sql.tcl porte bien son source, ::soc::start_system journalise l'édition avec une branche WARN de repli, et test-modules-charges.tcl dérive désormais la liste des source. ⚠ Le renvoi « l. 586-620 » qu'il portait ne désignait déjà plus rien — un numéro de ligne recopié dans une prose. [[renvois-numero-de-ligne]]

⚠⚠ CE QUI ÉTAIT VRAIMENT OUVERT ÉTAIT AILLEURS — constaté le 16/08/2026, REMPLI le 25/08/2026. La phase 1 avait posé une vérité que personne n'interrogeait pour décider : les trois lecteurs n'avaient qu'un appelant d'affichage chacun, et edition_au_moins — la seule fonction capable de conditionner quoi que ce soit — zéro appelant dans les trois langages. Aucune ligne du dépôt ne se comportait différemment selon l'édition. La phase 1 était finie à la lettre de sa condition, et pas en esprit.

✅ PHASE 2 FAITE — la première différence de comportement existe, et elle est en production.

compat_serveurs_edition() appelle edition_au_moins(), et la page des serveurs compatibles n'ouvre pas les mêmes serveurs selon l'édition :

⚠ Ce qu'une édition ferme, la page le DIT : compat_serveurs_fermes() nomme chaque serveur retiré avec l'édition qui l'ouvrirait. Une fonction éteinte se dit, elle ne se cache pas — un serveur qui disparaît sans un mot laisse croire à un oubli ou à une incompatibilité, deux choses fausses. ⚠ Et la production ne change pas : elle vit en complete, et voit les six comme avant.

⚠ Le banc qui l'éprouve sous les quatre éditions : Web/tests/test-edition.php. ⚠⚠ Cette ligne annonçait AUSSI Web/tests/test-compat.php, et c'était FAUX — mesuré le 31/08 : ce banc ne contient pas une seule occurrence du mot « édition » sur ses 302 lignes. EDITIONS.md avait corrigé le 30/08 ; la correction n'était appliquée que dans un des deux documents, et l'autre a continué d'affirmer la même chose un jour de plus. Leur compte n'est pas recopié ici — il se lit en les lançant, et ./Tools/bancs.sh les ramasse.

⚠⚠ MAIS LE LECTEUR BASH RESTE UN LECTEUR MORT, exactement au sens du point 18 — le seul code qui l'appelle est son propre banc, ce que le point 18 a nommé « le chemin aveugle ». C'est précisément le piège de la phase 3, décrit plus bas.

⚠⚠ DEUX CONDITIONS DE BLOCAGE ÉCRITES ICI SONT PÉRIMÉES — corrigé le 16/08/2026 :

• « La Phase 0 n'est toujours pas remplie — le 2 ne l'est pas » : faux. Le point 2 est clos depuis le 15/08 à 21:38:37, et les points 1 à 8 portent tous ✅. La condition littérale est remplie.
• « pour combien d'installations ? », donné comme le blocage principal : tranché le 14/08/2026 — « dix au plus », écrit dans Markdown/EDITIONS.md §5.5, qui conclut « plus rien ne bloque l'écriture ». ⚠ Et ce chiffre ne conditionne que la phase 8 (l'édition payante) : le même document dit qu'il « n'allège que le §6, la partie technique reste entière ».

⚠⚠ MAIS LA RAISON DE NE PAS OUVRIR TIENT TOUJOURS, et elle est désormais MESURÉE plutôt que prédite. L'argument d'origine disait : « quatre éditions, ce sont quatre choses à faire tourner, et trois que personne ne fait tourner tous les jours ». Ce n'est plus une prédiction : sur l'installation réelle, les trois lecteurs ne voient jamais que complete, aucune autre édition n'existe dans aucune exécution, et edition_au_moins n'a jamais été appelée. La fermeture des points 1 à 8 a levé le blocage listé, pas sa raison.

⚠ La phase à ne surtout pas ouvrir en premier est la 3 (l'installateur par mode) : elle brancherait un lecteur mort dans le plus gros fichier du dépôt (12 509 lignes, remesuré le 30/08/2026 — la valeur écrite ici annonçait 10 429, et elle avait pourtant été présentée comme mesurée) et y ajouterait quatre chemins d'installation dont trois ne seraient jamais parcourus.

✅ L'argument « lecteur mort » a été RETIRÉ pour bash le 30/08/2026. Tools/tests/test-edition-sh.sh exerce edition_au_moins() — quatorze comparaisons de rang, cinq mutations attrapées. La fonction n'avait aucun appelant, ni en production ni dans un banc : les seules lignes du dépôt qui la nommaient la livraient sans jamais l'exécuter. ⚠ Cela n'ouvre PAS la phase 3 : les quatre chemins d'installation restent à écrire, et leur condition de fin — « les quatre modes s'installent sur une machine nue » — demande une machine nue, root, et quatre installations réelles. C'est un geste, pas du code. ✅ Et pour le Tcl le 31/08/2026 — IriX/tests/test-edition.tcl, 27 constats. Les trois lecteurs ont désormais chacun leur banc. ⚠ Cela ne rend pas les lecteurs vivants : ::soc::edition_au_moins et edition_au_moins() en bash n'ont toujours aucun appelant en production. Sur les trois, seul le PHP en a un. Ils sont mesurés, pas employés — et c'est la moitié « jamais exécutée » qui a été retirée, pas l'autre. 📌 Les deux constats qui portent ce banc : une édition demandée inconnue refuse, mesurée sur l'installation la plus complète — c'est le défaut de require_grade, où un lsearch rendant -1 comparé par >= ouvre au lieu de refuser, et mesuré ailleurs le constat serait vrai sans rien prouver ; et les deux gardes contre les notes _edition / _bots_chan, qui citent en toutes lettres les valeurs cherchées.

🔨 Phase 3 — L'ÉCRIVAIN EST POSÉ le 01/09/2026, la phase n'est PAS close

⚠ Elle ne se ferme pas ici. Sa définition d'achèvement est « les quatre modes s'installent sur une machine nue » — cela n'a pas été fait. Ce qui suit décrit ce qui EXISTE, pas ce qui est constaté en service.

⚠⚠ ET LA MESURE A CORRIGÉ LE DIAGNOSTIC — dans le sens le plus dur. Le 31/08 j'ai écrit que « toute installation naît complète, et rien ne peut l'en faire sortir ». C'est vrai du clone git, c'est-à-dire de la production. Mesuré le 01/09 sur l'archive réellement servie :

Config/config.json dans /dl/site  →  ABSENT (0 entrée)

Une installation tierce ne recevait donc jamais ce fichier, et rien ne le créait. Les trois lecteurs rendaient beta par défaut prudent — non par choix, mais faute de fichier. Le mécanisme n'avait pas « un seul état atteignable » : il en avait un seul par accident de fourniture, et l'édition ne pouvait pas être posée du tout.

📌 Un diagnostic tiré du dépôt décrit le dépôt. L'artefact servi est une autre chose, et c'est lui que reçoivent les autres.

Ce qui est posé, et mesuré :

⚠⚠ Trois cas, et le troisième est le plus important : option donnée → on pose ; rien et champ absent → défaut prudent ; rien et champ présent → on ne touche à rien. Relancer l'installateur ne redescend pas une installation qui tourne — ce serait éteindre en silence ce qui marchait.

Bancs : Tools/tests/test-edition-sh.sh (53 constats, 8/9 blessures mordantes — la neuvième est déclarée inatteignable dans le banc plutôt que couverte par un constat qui passerait pour une autre raison) et Bootstrap/tests/test-edition-installateur.sh (16 constats, 9/9).

📌 Ces derniers EXTRAIENT _edition_poser du script et la FONT TOURNER sur un bac à sable, avec ses quatre cas. C'est la leçon du 31/08 appliquée à sa propre correction : un banc qui mesure la chose ne mesure pas son emploi.

⚠ Deux gardes de non-descente se masquent l'une l'autre. La mutation l'a montré : blesser l'une ne fait rougir aucun constat, l'autre rattrape. Chacune paraît morte examinée seule — et c'est exactement le raisonnement qui ferait supprimer la survivante. C'est écrit dans le code.

⛔ Ce qui reste pour fermer la phase 3 :

1. Installer sur une machine nue, une fois par édition — l'installation d'essai sert à cela ;
2. constater que Config/config.json y arrive par l'archive, puis que --edition= s'y pose ;
3. et que la campagne de l'édition obtenue passe.

⚠ Rien de tout cela n'est fait. La phase 4 (la montée) reste bloquée derrière.

Juste derrière la phase 3 vient la 6, qui répandrait en 86 endroits une fonction qui n'a jamais tourné — le mode d'échec exact du point 22, où cinq constats restaient verts pendant une panne totale.

✅ Phase 5 — les DEUX chemins d'envoi hors du filet sont fermés, le 28/08/2026

Le 27/08, la doctrine du rapport (Web/inc/doctrine-rapport.php) était écrite mais deux chemins lui échappaient, nommés au banc sans être traités : Bootstrap/overtchat-setup.sh (bash, sendmail -t) et Components/Service/lib/Tcl/Stable/IriX-std.tcl (mutt, dans la bibliothèque distribuée). Les deux portent désormais la doctrine et l'appliquent.

⚠ Les nommer sans les traiter est ce qui a permis de les fermer le lendemain sans les redécouvrir. Un défaut connu et écrit coûte une journée ; un défaut oublié coûte l'accident.

⚠⚠ CE QUE CELA CRÉE, ET C'EST LE VRAI SUJET : la doctrine est écrite TROIS fois. Ni bash ni Tcl ne peuvent appeler le PHP — l'alerte de l'installateur part précisément quand l'installation va mal, et IriX-std.tcl tourne dans un Eggdrop. Or un calcul écrit des deux côtés diverge un jour est une constante mesurée de ce projet.

La parade est Web/tests/corpus-rapport.txt, et il n'y en a pas d'autre. Un seul fichier de cas, lu par les trois bancs — celui de PHP, celui de bash, et le chapitre ajouté à IriX/tests/test-std.tcl. Le jour où une implémentation dérive, son banc rougit sur la ligne exacte. ⚠ Toute correction apportée à l'une des trois commence par une ligne ajoutée au corpus : un cas absent n'est éprouvé nulle part.

⚠⚠ LE CORPUS A PAYÉ DEUX FOIS LE JOUR DE SON ÉCRITURE.

⚠ Le premier est le plus instructif : un motif qui cite un cas sans l'attraper ment mieux qu'un motif qui l'ignore. Le lecteur avait toutes les raisons de croire le cas couvert.

⚠⚠ ET LA PASSE DE MUTATION A TROUVÉ UN CINQUIÈME CONSTAT FAUX, dans un banc écrit le jour même. Le chapitre Tcl « personne ne contourne le filet » rejouait le filtre lui-même sur la matière, puis constatait que le filtre filtre. Le corps de send_mail débranché — set body $body — il restait vert, 65 constats, 0 échec. Il prouvait que la fonction existe, jamais qu'elle sert. Il intercepte désormais ce que mutt reçoit réellement, par le fichier passé derrière le chevron. C'est le travers n°1 du projet, et il se reforme jusque dans le banc écrit pour le garder.

⚠ Par quel mécanisme cela voyage-t-il ? — la question qui a manqué cinq fois, posée et mesurée : overtchat-setup.sh est la première entrée de son propre CORE_WATCHED, donc il se met à jour lui-même ; IriX-std.tcl est écrasé par _irix_sync_source, sans aucune garde « seulement si absent » — le défaut d'install-service.sh n'est pas reproduit ici. Il n'est déployé dans cmds/ qu'en mode std, et c'est juste : c'est le seul mode où ce fichier est chargé, donc le seul où irix:send_mail existe.

✅ Phase 5 — le CODE est complet, le 28/08/2026

Les deux derniers morceaux — la table des niveaux et le plafond des six heures — cachaient chacun un défaut mesurable, là où l'on attendait du travail de documentation.

Le plafond était GLOBAL, et son commentaire mentait sur son propre code. Il disait « 6 h entre deux alertes identiques » ; sujet_court n'entrait nulle part dans la décision. Une mise à jour qui échoue à 03:00 sur un dépôt injoignable faisait taire six heures l'alerte de 04:00 disant que la base a disparu. Il compte désormais par clé, comme irix-alerte.tcl depuis le 16/08.

Et la ligne la plus grave du journal s'affichait EN VERT. ::soc::alerte::lever écrit sa trace par un toupper, ce qui fabrique CRIT — un mot qui n'appartient à aucune des cinq échelles de gravité du projet. La coloration de Web/pages/logs.php ne connaissait que ERROR et WARN ; la ligne tombait donc sur la règle suivante, « contient SOC → vert », posée par la ligne même qui l'avait écrite. Une affirmation qui ment dans le sens rassurant — la forme la plus pure du défaut n°1.

Web/inc/niveaux.php porte la correspondance à un seul endroit, et Web/tests/test-niveaux.php dérive les cinq listes de leurs sources pour exiger qu'elle les connaisse toutes. ⚠ Au passage, EDITIONS.md en oubliait un sixième côté C : LOG_FATAL.

⚠ Ce qui reste, et c'est du GESTE : provoquer un incident pour voir partir le bon niveau — cela envoie un vrai courriel, donc cela revient à SerVuS. Le silence par clé n'a jamais été vu à l'œuvre sur une vraie mise à jour en échec.

Le texte d'origine, gardé — il dit pourquoi c'était risqué

Demandé par SerVuS le 11/08/2026, explicitement « pour quand tout sera stable ». Découper le projet en quatre : Beta (découverte), Standard (novice), Complète, Payante. Plus deux chantiers greffés : le budget et l'hébergement de l'édition payante, et une compatibilité Windows avec un installateur qui règle tout selon le mode choisi.

📄 Tout est dans Markdown/EDITIONS.md — l'inventaire mesuré du projet, les quatre éditions détaillées, cinq questions à trancher avant d'écrire une ligne, la licence, l'hébergement et le portage Windows.

⚠⚠ CE POINT NE DOIT PAS S'OUVRIR TANT QUE LES AUTRES SONT LÀ. Un projet qu'on découpe en quatre multiplie par quatre ce qu'il a de bancal. Les défauts du 11/08 — un compteur faux à trois endroits, un SQUIT qui emportait le mauvais lien, un panel annonçant « non déclaré » pour des services en ligne — ne se sont vus qu'en faisant tourner. Quatre éditions, ce sont quatre choses à faire tourner, et trois que personne ne fait tourner tous les jours.

⚠ Le point le plus dur n'est pas technique : le projet est sous licence MIT, et n'importe qui peut donc retirer une limitation et redistribuer. Une édition payante fondée sur du MIT vend un service, pas un logiciel — ou demande de changer de licence. EDITIONS.md §6.1.

---

10. Les pseudonymes du réseau — la moitié qui demande un mot de passe

Mesuré le 12/08/2026, et le défaut n'était pas celui qu'on croyait. La note de reprise disait « les pseudonymes des robots et services ne sont protégés par rien, pseudos-proteges.conf compte zéro entrée ». C'était vrai, et incomplet : l'autre liste, celle des interdits, comptait bien 80 motifs — dont un qui paraissait couvrir les services et n'en couvrait aucun.

over-* exige un tiret après over. Les services s'appellent OverBot, OverHub, OverNick, OverWeb. Le croisement des motifs avec les pseudonymes réellement en ligne a donné neuf à découvert sur dix — le seul gardé l'étant par une autre ligne.

⚠ Il ne s'est pas vu en relisant le fichier, où la ligne se lit très bien, mais en croisant deux sources : les motifs livrés, et ${t}_online. C'est le même geste que pour les compteurs de charge du point 2, et il trouve le même genre de défaut — une affirmation qui a l'air vraie et ne l'est pas.

✅ Réglé pour les pseudo-clients du lien de services (4.16.49) : ils sont nommés un par un, et une campagne du serveur (test-nickpolicy.c, 7/17) garde désormais le fichier livré. Elle tient les deux sens — services réservés, robots jamais — et deux mutations la font rougir.

✅✅ ET C'EST CONSTATÉ EN SERVICE, le 12/08/2026 à 14:26 — pas seulement écrit. Report en production, rechargement à chaud sans changement de processus (donc aucune connexion rompue), 84 motifs annoncés au lieu de 80, et les trois cas éprouvés par de vraies connexions :

OverBot   → 432 :Erroneous Nickname: Ce pseudonyme est reserve aux services du reseau
OverOp-Q  → 433 (deja pris), et non 432 — le robot garde son nom
Overlord  → accepte

⚠ Les trois comptent, et pas seulement le premier. Sans le troisième, un refus général se lirait comme un succès ; sans le deuxième, on ne saurait pas qu'un robot peut encore se connecter — c'est le sens qu'un motif élargi aurait cassé en silence. Recoupé par le journal du serveur, source indépendante du client d'essai, qui ne porte qu'une ligne : celle du seul refus attendu.

⚠⚠ Pourquoi les deux sens, et pas seulement le premier. Le correctif évident, élargir en over*, casserait les robots de prêt : ce sont des clients, et cette liste s'applique aux clients. Ils ne tomberaient pas franchement — Eggdrop bascule sur son pseudonyme de repli et continue de tourner, le prêt cassé sans une ligne au journal. Un banc qui n'aurait gardé que « les services sont réservés » aurait laissé passer ce correctif-là.

✅ L'ÉTAT ET LA PROCÉDURE, MESURÉS LE 14/08/2026 — pour que le geste soit court et sûr le jour où il se fera.

Les cinq à protéger : IriX, OverOp-H, -Q, -S, -T. ⚠⚠ CETTE LISTE EST PÉRIMÉE — remesurée le 27/08/2026, et fausse DANS LES DEUX SENS. Le parc a été refait le 25/08 : OverOp-H, -Q et -S n'ont plus ni unité, ni dossier — et OverOp-A, qui n'y figurait pas, tourne et est en ligne. La liste juste aujourd'hui compte trois noms : IriX, OverOp-T, OverOp-A. ⚠ Ne pas la recopier telle quelle : c'est une liste de robots, donc elle bougera encore — la mesurer par systemctl list-units 'overop@*' croisé avec ${t}_online, jamais la lire ici. Les pseudo-clients du lien — OverTchat, OverHub, OverNick, OverBot, OverWeb — sont déjà couverts par les motifs depuis la 4.16.49.

⚠ Deux résidus mesurés au passage : OverOp-H garde un compte - b dans IriX.user sans robot derrière, et OverOp-A tourne sans compte dans IriX.user — c'est le « robot infirme » du point 35, morceau (2).

⚠ LE FICHIER INSTALLÉ DOCUMENTE UN CHEMIN QUI N'EXISTE PAS LÀ OÙ IL EST LU. Il indique ./build/overtchatd -H. C'est juste dans les sources — build/overtchatd y est bien, et son empreinte est identique au binaire installé — mais à l'endroit où ce fichier vit, le binaire est /home/servus/overtchatd/bin/overtchatd. Vérifié avant d'accuser : les documents du dépôt, eux, ont raison chez eux.

⚠⚠ L'ORDRE COMPTE, et le point ne le disait pas. « Des deux côtés à la fois » est juste, mais le mot de passe part à la connexion, jamais après : Eggdrop ne le renvoie pas à chaud.

1. poser le mot de passe dans chaque overop.conf / irix.conf — inerte tant qu'on ne reconnecte pas ;
2. poser les empreintes dans pseudos-proteges.conf ;
3. REHASH du serveur — le fichier est relu à chaud, aucun redémarrage ;
4. reconnecter les robots un par un, en vérifiant chacun avant le suivant.

⚠ Le symptôme d'une erreur est silencieux CÔTÉ ROBOT : le serveur renvoie 432 ERR_ERRONEUSNICKNAME, Eggdrop bascule sur son altnick — OverOp-H_, -Q_, -S_, -T_, IriX_ — et continue de tourner, le prêt cassé.

❌ « sans une ligne au journal » était FAUX, mesuré le 16/08 : src/cmd/m_register.c écrit Pseudonyme protégé « %s » refusé à %s dans /home/servus/overtchatd/logs/overtchatd.log. La ligne existe — elle est simplement dans le journal du serveur, pas dans celui du robot. Regarder au mauvais endroit revient à ne pas regarder, et le point ne disait pas où.

⚠⚠ LE VRAI DANGER EST DIFFÉRÉ, ET C'EST CE QUI REND L'ÉTAPE 4 INDISPENSABLE. Appliquer un seul côté ne casse rien sur le moment : nickprotect_allows n'est consulté qu'à la prise du pseudonyme, et une session déjà ouverte n'est jamais réinterrogée. Le REHASH de l'étape 3 est donc parfaitement silencieux sur des robots connectés. Qui s'arrête là constate que « tout va bien » — et la panne dort jusqu'au prochain redémarrage non surveillé. Or le service est arrêté chaque soir vers 21:00 pour ne repartir que vers 09:00 : le désaccord se réveillerait le lendemain matin, sans personne devant l'écran.

✅ CORRIGÉ le 16/08 — un défaut qui aurait fait échouer le geste chez tout tiers. contrib/install-service.sh déposait pseudos-proteges.conf en 640, alors que nickprotect_load() refuse tout fichier portant un bit groupe ou autre (« est lisible au-delà de son propriétaire — non chargé, corrigez avec chmod 600 »). Chez un tiers, la protection ne s'armait donc jamais. Invisible ici (la production est en 0600, posée à la main) et invisible là-bas au début, le fichier livré étant vide : « 0 pseudonyme chargé » paraît normal. Cela aurait mordu le jour où l'exploitant y met ses entrées et constate que rien ne s'applique. ⚠ Le mode 600 ne vaut que pour ce fichier : S_IRWXG n'apparaît que dans src/nickprotect.c, les trois autres politiques n'ont aucun contrôle de droits.

⚠ Ce que le verrou « non automatisable » recouvre vraiment. Seule la saisie du secret l'est — et l'argument juste n'est pas « un script le connaîtrait » mais qu'il le connaîtrait des deux côtés à la fois, en clair dans overop.conf et haché pour pseudos-proteges.conf : un unique point de compromission qui réunit les deux moitiés. En revanche écrire les fichiers, faire le REHASH, reconnecter et VÉRIFIER sont entièrement automatisables — rien de secret n'y transite. Ranger les quatre étapes sous un seul verrou prive le geste de sa partie la plus utile : la vérification après chaque robot, qui est précisément celle que l'humain oublie.

✅ UNE CORRECTION NE POUVAIT PAS ATTEINDRE UNE INSTALLATION — trouvé et réparé le 27/08/2026

⚠⚠ Ce défaut-ci n'est pas dans un fichier : il est dans le mécanisme qui livre les fichiers. Il a été trouvé en remesurant ce point, et il vaut bien au-delà de lui.

Ce qui a été mesuré. Le format d'une empreinte a été corrigé dans le dépôt le 16/08/2026 — quatre champs au lieu de trois. Le 27/08, onze jours plus tard, le fichier réellement posé en production annonçait toujours trois champs. Et le format à trois est accepté en lecture : il vaut une itération au lieu de cent mille, sans le moindre avertissement. Un exploitant qui suit son propre fichier obtient donc une protection cent mille fois moins chère à casser, qui a l'air de fonctionner.

La cause, et elle est mécanique. Servers/overtchat-hybrid/contrib/install-service.sh ne posait les quatre fichiers de politique que s'ils manquaient :

if [ ! -f "$PREFIX/conf/${_pol}.conf" ] && [ -f "$SRC_DIR/conf/${_pol}.example" ]; then

Une installation déjà en place gardait donc, pour toujours, la documentation du jour de sa pose. Ni la production, ni celle d'un tiers, ne pouvait recevoir une correction — jamais.

⚠⚠ ET LE BANC EST RESTÉ VERT ONZE JOURS. test-conf-modele.sh portait déjà un constat « aucun document du serveur n'annonce le format à TROIS champs » — mais il balaie Servers/overtchat-hybrid, c'est-à-dire le dépôt, qui était juste depuis le 16/08. Un banc qui ne lit jamais l'installation ne peut pas voir un défaut de livraison.

Ce qui a été fait.

Éprouvé : test-conf-modele.sh passe de 9 à 15 constats, dont un qui regarde l'installation et non le dépôt — le seul du fichier à le faire. Passe de mutation à 5 blessures, sans trou, dont le retour de l'ancienne condition liée. ⚠⚠ Et le nouveau constat a rougi POUR DE VRAI avant que le geste soit fait : c'est la meilleure épreuve possible, celle qu'on ne peut pas fabriquer.

⚠ Ce que cela ne règle pas : Servers/ n'est distribué par aucun canal — décision encore ouverte au registre. La correction profite donc à la production et à qui clone le dépôt, pas encore à un tiers qui passe par l'installateur.

11. ✅✅ Un robot peut recevoir un salon où il ne peut pas entrer — CLOS le 14/08/2026, la suspension est partie à 18:00

Trouvé le 12/08/2026 par le constat de la bascule (point 2), et le défaut ne lui appartient pas : il est au-dessus, sur tout chemin qui confie un salon à un robot.

Rien ne vérifie que le robot POURRA entrer. Le mandat s'écrit actif, l'ordre part, le robot répond done — et il n'entre jamais. Sur #membres, qui porte +ntR, aucun des quatre robots ne le peut : ils portent +ix et ne sont identifiés auprès d'aucun service.

⚠ Le code le disait déjà, et personne n'en tirait les conséquences. Le commentaire d'::soc::mandat::installer prévient : « ceci rend ok quand l'ORDRE EST PARTI, jamais quand le robot est entré ». C'est exact et honnête. Mais aucun appelant ne regarde ensuite, et un droit accordé sur un salon inaccessible ne se distingue en rien d'un droit qui marche.

Ce que ça coûte, concrètement : le prêt paraît vivant côté base et côté panel, le salon n'a aucun modérateur, et le seul signal est une ligne d'écart au journal toutes les cinq minutes — soit 288 par jour. C'est très exactement le travers déjà corrigé deux fois sur ce chantier, retrouvé par une troisième porte.

✅ LA CAUSE EST ISOLÉE — contre-épreuve du 12/08/2026 à 15:28. Le même ordre, le même robot, sur un salon +nt cette fois :

15:28:14  ordre o1786541294-4 : #accueil activé, entrée en cours
15:28:15  OverOp-H joined #accueil.

Une seconde. La chaîne d'ordre n'a donc jamais été en cause : c'est le +R de #membres qui barrait l'entrée, et rien d'autre. Sans cette contre-épreuve, « le robot n'entre pas » aurait pu s'imputer au protocole, au robot ou à la bascule — trois pistes fausses.

⚠ Et ${t}_botreg_log le dit en différentiel, ce qui vaut mieux qu'un silence : 19 lignes error au total, les trois dernières à 14:01, 14:06 et 14:11 — une par cycle tant que le mandat désignait un salon inaccessible —, puis plus une seule. Le contrôle d'écart fonctionne, il a bien signalé le prêt impossible, et il se tait depuis que le prêt est servi. ⚠ Ne pas compter les lignes de cette table sans filtrer sur result : elle journalise aussi les done, et un COUNT(*) nu fait croire à un écart qui n'existe pas.

⚠ Les trois pistes ne se valent pas :

• refuser à l'octroi ce qu'on ne peut pas tenir — le plus honnête, mais il faut lire les modes du salon au bon moment, et ils changent après ;
• identifier les robots auprès d'OverNick, ce qui leur donnerait +r et lèverait +R — mais c'est un compte et un mot de passe par robot, et cela touche le point 10 ;
• constater après coup et défaire le mandat si le robot n'est pas entré au bout de N minutes — le contrôle d'écart voit déjà tout ce qu'il faut, il n'en tire simplement aucune conséquence.

⚠⚠ CE POINT ÉTAIT PÉRIMÉ DE MOITIÉ, et il présentait les trois pistes comme si aucune n'avait été prise. Mesuré le 13/08/2026 : la troisième — constater après coup — est écrite depuis le 12/08 (4.16.52, commit 813ca9a), et elle tourne en service. ::soc::mandat::non_servis relève les prêts dont le robot n'est pas là, signaler_non_servis prévient le journal et les opérateurs, au passage horaire, après la bascule de charge. La preuve est différentielle :

2026-08-13T17:00:00 [DEBUG] prêts : contrôle passé, tous les prêts actifs sont servis

⚠ Cette ligne n'est ni dans journalctl -u irix ni dans IriX.log — seulement dans IriX-sql.log. Un grep sur le premier journal aurait conclu que le contrôle ne tourne pas. C'est la règle des trois journaux, et elle vient de servir.

✅ LA MOITIÉ QUI MANQUAIT — DÉFAIRE — EST ÉCRITE LE 13/08/2026 (4.16.55). Tranché par SerVuS, qui renverse le choix de la veille : un prêt qu'aucun robot ne sert depuis 24 heures passe en suspendu. L'argument d'alors — un salon réservé par mégarde, corrigé dans l'heure — n'est pas écarté, il vit dans le délai : ce qui survit à vingt-quatre avertissements horaires n'est plus une configuration passagère.

⚠⚠ ET LA COLONNE ÉVIDENTE ÉTAIT LA MAUVAISE. updated_at était là, datée, vieillissante — elle mesure l'âge de la ligne, jamais celui du défaut. Le prêt de #accueil, servi et sans le moindre écart, portait 1582 minutes le jour où ce code a été écrit. Un seuil posé dessus aurait suspendu sur-le-champ un salon inaccessible depuis dix minutes, et épargné un salon mort depuis trois jours. Une colonne absent_depuis porte donc le premier constat d'absence, et rien d'autre.

⚠ Suspendre, jamais terminer : terminer est sans retour, et MANDATON <#salon> rétablit un prêt suspendu en un geste. L'annonce faite aux opérateurs dit comment le rétablir.

✅ LE CONSTAT EST LANCÉ, ET SA PREMIÈRE MOITIÉ EST FAITE. Un prêt d'essai a été accordé sur #membres (+ntR) le 13/08 à 18:21, à OverOp-S — un robot qui ne sert aucun autre salon.

19:00:00 [WARN]  prêt : #membres est accordé à OverOp-S, et OverOp-S n'y est PAS…
19:00:00 [INFO]  prêt : #membres n'est pas servi par OverOp-S — premier constat.
                        Suspension dans 24 h si rien ne change.
19:00:00 [INFO]  prêts : 1 marqué(s) absent(s), 0 revenu(s), 0 suspendu(s)
20:00:00 [WARN]  prêt : #membres est accordé à OverOp-S, et OverOp-S n'y est PAS…
20:00:00 [DEBUG] prêts : contrôle de suspension passé, rien à défaire

⚠⚠ C'EST LE SECOND CONSTAT, celui que ce carnet réclamait, et il est le plus difficile à obtenir : la suspension ne part pas avant le délai. Le passage de 20:00 le prouve — le prêt est toujours signalé absent, et rien n'est défait.

⚠ Et il ne prouverait rien sans la trace de vie de la 4.16.57. Un silence à 20:00 se lirait « le délai tient » exactement comme « le contrôle ne tourne plus ». C'est la ligne contrôle de suspension passé, rien à défaire qui fait la différence — écrite le jour même, après avoir constaté que ce code refaisait le défaut qu'il venait de corriger ailleurs.

✅✅ LA SUSPENSION EST PARTIE — 14/08/2026 à 18:00:00. LE CONSTAT EST COMPLET.

Les trois choses attendues, dans la même seconde :

18:00:00 [WARN] prêt : #membres SUSPENDU — OverOp-S n'y est pas entré depuis 24 h.
                       Le salon était annoncé modéré et ne l'était pas.
18:00:00 [INFO] prêts : 0 marqué(s) absent(s), 0 revenu(s), 1 suspendu(s)

GLOBOPS :[MANDAT] #membres : prêt SUSPENDU — OverOp-S n'y est jamais entré depuis
                  24 h. Le mandat reste ; MANDATON #membres le rétablit une fois
                  le salon accessible.

En base : etat = suspendu, updated_at = 18:00:00. Le mandat n'est pas terminé — c'est toute la décision de ce point, et elle tient : MANDATON le rétablira en un geste.

⚠ L'ÉCHÉANCE A ÉTÉ AVANCÉE D'UNE HEURE, ET IL FAUT LE DIRE. SerVuS a demandé à 17:30 de ne pas attendre 19:00. absent_depuis a été reculé de 19:00:00 à 17:55:00 sur la seule ligne d'essai — le seuil et le code n'ont pas bougé. Le déclenchement est donc resté entièrement automatique, ce qui est la seule chose qui compte pour un constat. ⚠ 17:45 avait été demandé et n'était pas atteignable : le contrôle est porté par un bind time horaire, qui ne part qu'à la minute :00.

✅ absent_depuis est repassé à NULL après la suspension, et c'est voulu : sans cet effacement, un prêt rétabli par MANDATON retomberait suspendu au passage horaire suivant, la vieille date d'absence dépassant toujours le seuil.

⚠⚠ ET LE CONSTAT A MONTRÉ AUTRE CHOSE, que personne ne cherchait : LA SUSPENSION N'A LAISSÉ AUCUNE TRACE EN BASE. ${t}_mandat_log n'a pas bougé — sa dernière ligne date toujours du 12/08. Le geste le plus lourd que ce mécanisme sache faire — retirer ses pouvoirs à un prêt — était invisible de tout ce qui lit la base, donc du panel. Il n'existait que dans deux fichiers de journal et dans un GLOBOPS que personne ne relit.

Corrigé le même jour, à la demande de SerVuS : voir « Le journal des prêts » ci-dessous, et PRET-ROBOT.md §9bis. ⚠ Le correctif n'était pas en service à 18:00 — le bot tournait le code chargé à 17:13 —, ce qui rend ce constat d'autant plus net : on a vu le manque en direct.

---

12. ✅✅ La console d'IriX — CLOSE le 12/08/2026, après cinq jours d'inexistence

Ce point n'a jamais figuré ici, et c'est précisément le défaut. Les trois commandes de console — .bots, .compte, .lien — ont été écrites le 07/08/2026, avec leur banc (18 constats, vert). Personne ne s'est demandé si quelqu'un pouvait les taper. Personne ne le pouvait.

Cinq jours durant, Web/pages/eggdrop.php a annoncé au panel une console qui refusait tout le monde, et test-partyline.tcl est resté vert sans qu'aucune de ces commandes ait servi une fois. C'est le travers de PRET-ROBOT.md en entier : « écrit et éprouvé » n'est pas « en service ».

⚠ DEUX défauts empilés, et le second ne se voyait qu'une fois le premier levé. C'est la forme que prend toujours ce genre de pile — on ne trouve la marche suivante qu'en montant la première.

① L'accès : le socket écoutait, et refusait.

[12/08 16:46:08] Connexion telnet : localhost/49857
[12/08 16:46:08] Telnet refusé : telnet@localhost, aucun accès

SerVuS portait trois --HOSTS au userfile, tous des masques IRC (*!*@Clk-….mshome.net…). Aucun ne couvre une connexion telnet locale, dont le masque est -telnet!telnet@localhost. Les quatre OverOp, eux, portent -telnet!*@* — d'où la différence, et d'où la méthode : comparer ce qui marche à ce qui ne marche pas, plutôt que lire le code de celui qui échoue.

⚠ Ce n'était NI le flag +p, NI require-p, NI le réseau — les trois ont été mesurés et écartés un par un. SerVuS porte jlmnoptx sur IriX comme sur les OverOp ; require-p 1, posé sur IriX seul, était donc satisfait ; et depuis Windows, 127.0.0.1:3341 rendait déjà la bannière d'OverOp-H, WSL tournant en réseau miroir. Un refus au niveau applicatif ressemble beaucoup à un blocage réseau, et se soigne à un tout autre endroit.

Levé à froid — Eggdrop tient son userfile en MÉMOIRE et le réécrit à l'heure ronde, donc une édition à chaud aurait disparu à 18:00 sans un mot. Deux masques ajoutés : -telnet!*@localhost et -telnet!*@127.0.0.1, et non -telnet!*@* : le listen borne déjà l'écoute à la boucle locale, le userfile n'a pas à être plus ouvert que lui.

② Le code : .lien appelait sa voisine au lieu d'Eggdrop.

[12/08 17:41:25] Tcl error [::soc::dcc::lien]: wrong # args: should be "bots hand idx text"

::soc::dcc::lien faisait set lies [bots], voulant la commande Eggdrop du core qui rend la liste des bots liés. Mais depuis le namespace ::soc::dcc, Tcl résout un nom court dans le namespace courant avant le global — et ::soc::dcc::bots existe, c'est la procédure d'à côté. Corrigé en [::bots] : deux caractères.

⚠ Le message d'erreur nomme bots alors qu'on a tapé .lien, et parle d'un nombre d'arguments là où l'appel n'en passe aucun. Il envoie chercher au mauvais endroit.

⚠⚠ ET LE BANC NE POUVAIT PAS L'ATTRAPER. test-partyline.tcl remplace bots par un faux dans son namespace d'essai — il éprouvait donc exactement le chemin qui n'existe pas en service. C'est une quatrième façon de mentir, à ajouter aux trois de la fiche irix-confirmation-mensongere : un doublet de nom entre une procédure et une commande de l'hôte ne se voit qu'en vrai.

Constaté en service, journal à l'appui : #SerVuS# compte (17:41:29), #SerVuS# lien (17:45:38), #SerVuS# bots (17:45:45), après Connecté : SerVuS (telnet@localhost/42212).

⚠ CE QUI RESTE, ET QU'ON NE PRÉTEND PAS FERMÉ :

• ✅✅ Le DCC chat — CONSTATÉ le 12/08/2026 à 19:16:02. Il échouait pour une cause distincte du telnet : le bot annonçait 192.168.1.254, la passerelle par défaut, où rien n'écoute. Le client affichait « Unable to connect » pendant que le journal du bot ne portait aucun refus — parce qu'il n'y en avait pas : la connexion n'arrivait jamais. set nat-ip "127.0.0.1" l'a réglé, et la preuve est au journal :

  19:15:51  CTCP CHAT: from SerVuS (Tgl0be@aodxl5.olsury.18pt7j.IP)
  19:15:53  Connexion telnet : localhost/1024
  19:16:02  Connecté : SerVuS (telnet@localhost/1024)

⚠⚠ ET LES DEUX CORRECTIFS DU JOUR ÉTAIENT NÉCESSAIRES, chacun pour sa moitié. Le masque de la connexion est telnet@localhost — celui ajouté à froid le matin même : un CTCP CHAT n'ouvre pas de port dédié, il fait revenir le client sur le port d'écoute telnet (3333). Sans nat-ip, le client ne trouvait pas le bot ; sans le hostmask, il y serait arrivé pour se faire refuser. Deux pannes superposées sur un même chemin, et corriger l'une seule n'aurait rien montré de l'autre.

⚠ nat-ip vaut 127.0.0.1 : le DCC ne marchera que depuis cette machine. C'est cohérent avec un listen borné à la boucle locale — mais c'est un choix, pas une neutralité.

• Un « Quoi ? Essayez '.help' » sur .bots à 17:38 est resté sans explication. La commande a fonctionné sept minutes plus tard sans qu'on ait rien changé qui la concerne — la correction ne touchait que lien, et la version en production était identique à HEAD (vérifié).

⚠ Recherche ABANDONNÉE, tranché par SerVuS le 12/08/2026. Ce n'est pas une tâche en attente : la commande sert depuis, les trois binds sont posés à chaque rehash, et rien ne laisse penser que l'incident revienne. On l'écrit parce qu'on ne le comprend pas, pas parce qu'on le soupçonne. À rouvrir seulement s'il se reproduit — auquel cas la fenêtre à capturer est celle des secondes qui suivent un .rehash.

• Les quatre OverOp n'ont AUCUN bind dcc, ni en production ni au dépôt. Leur console n'offre que le natif Eggdrop. Ce n'est pas un défaut — ils reçoivent leurs ordres par le protocole OverBot — mais la page du panel l'affirmait, et elle a été corrigée le même jour.

---

13. ⏹️ L'IPv6 est un chemin d'entrée que la documentation niait — CLOS SANS MESURE le 25/08/2026

⏹️ FERMÉ SUR DÉCISION DE SERVUS, LE 25/08/2026 : « je ne pourrai pas le tester ».

⚠⚠ CE POINT N'EST PAS ✅, ET LA DIFFÉRENCE EST TOUT. Un ✅ dirait « constaté sûr ». Ici, rien n'a été mesuré et rien ne le sera : la sonde exigeait une machine extérieure au préfixe /64, et cette condition ne peut pas être réunie. Le marquer ✅ serait exactement le défaut que ce registre traque — une confirmation mensongère.

⚠ CE QUI RESTE VRAI, ET QUI NE S'EFFACE PAS AVEC LE POINT :

• .wslconfig porte toujours networkingMode=mirrored, donc la distribution partage l'IPv6 publique de l'hôte. C'est un fait mesuré, pas une hypothèse.
• Le pare-feu Freebox n'a jamais été éprouvé sur ce chemin. On ne sait pas s'il filtre l'IPv6 entrante — ni dans un sens, ni dans l'autre.
• Les trois documents qui niaient ce chemin (RESEAU.md, WEB.md, PROJET.md) ont bien été corrigés le 12/08 : ce travail-là reste acquis, et c'était le plus utile des deux.

⚠ Ne pas rouvrir ce point pour redemander la sonde. Si la question revient un jour, elle reviendra par un autre chemin : un accès depuis l'extérieur qui existe déjà (un hébergeur, un téléphone hors Wi-Fi domestique), et non par un dispositif à monter pour l'occasion.

Ouvert le 12/08/2026. Ce n'est pas une faille constatée : c'est un chemin réseau que trois documents déclaraient inexistant, et que personne n'a jamais éprouvé.

⚠ Le fait, mesuré : .wslconfig porte networkingMode=mirrored. La distribution partage donc les interfaces de l'hôte, IPv6 publique comprise :

eth2   192.168.1.27/24   2a01:e0a:d83:8c50::2a79:9f0d/128
default via fe80::2266:cfff:fe60:1241 dev eth2

⚠ Ce que trois documents affirmaient, et qui était faux : RESEAU.md décrivait les deux modes sans dire lequel tournait — le lecteur retenait le plus rassurant. WEB.md et PROJET.md justifiaient inet_protocols = ipv4 par « la machine n'a pas de route IPv6 ». Les trois ont été corrigés le jour même. Ces phrases étaient probablement vraies quand WSL tournait en NAT : c'est le passage en mode miroir qui les a périmées, sans que rien ne le signale — le même mécanisme que « trois robots sur 60 places » au point 2.

Ce qui est mesuré, et qui ne suffit pas à conclure :

⚠ En IPv6 il n'y a pas de NAT, donc pas de redirection à franchir. Toute l'analyse d'exposition du projet raisonne sur les redirections de ports — elles ne valent que pour l'IPv4. En IPv6, le pare-feu de la Freebox est seul devant celui de Windows.

✅ REMESURÉ LE 14/08/2026 — rien n'a bougé sur l'essentiel : l'adresse est identique (2a01:e0a:d83:8c50::2a79:9f0d/128), donc la cible de sonde ci-dessous reste valide ; networkingMode=mirrored tient ; le serveur écoute toujours sur * pour 6667 et 6697 tandis que 6900, 8000 et 8080 restent en 127.0.0.1 ; le nom public n'a toujours aucun AAAA (getent ahostsv6 ne rend qu'une IPv4 mappée) ; et le pare-feu Windows n'ouvre bien que 6697, 8443, 8880, profil Any.

⚠⚠ L'INVENTAIRE DES PORTS EXPOSÉS ÉTAIT INCOMPLET. Ce point cite 6667, 6697, la messagerie et 8123. Mesuré le 14/08, onze ports écoutent sur [::] ou *, donc sur l'IPv6 publique :

✅ LES DEUX SONT IDENTIFIÉS — 14/08/2026. Ils viennent du même conteneur : homeassistant (ghcr.io/home-assistant/home-assistant:stable), qui embarque go2rtc pour les flux de caméras.

⚠⚠ ET C'EST network_mode: host QUI LES AMÈNE SUR L'IPv6 PUBLIQUE. Le conteneur ne publie aucun port — docker inspect rend Ports : vide et aucun docker-proxy ne tourne —, il partage directement la pile réseau de l'hôte. Ses ports ne sont donc pas « redirigés » : ils sont ceux de la machine, IPv6 comprise. Un raisonnement en redirections de ports ne les voit pas passer.

⚠ Le contraste vaut d'être noté : dans la même configuration, go2rtc limite son RTSP à 127.0.0.1:18554 et n'expose son API que sur une socket Unix — mais son WebRTC écoute sur :, donc toutes les interfaces. C'est le fonctionnement normal de WebRTC, qui doit être joignable ; sur une machine à IPv6 publique et sans pare-feu mesurable côté distribution, cela se dit.

⚠ Aucun des deux n'est ouvert par le pare-feu Windows, qui reste le seul rempart mesuré.

📌 Le piège qui a coûté le plus de temps ici, et qu'il faut garder : docker ps échouait sur /var/run/docker.sock: no such file or directory, ce qui laissait croire qu'aucun conteneur ne tournait. Le socket est ailleurs — docker.socket porte un override.conf qui le place sur /run/docker-native.sock. Avec DOCKER_HOST=unix:///run/docker-native.sock, tout devient lisible sans le moindre sudo, l'utilisateur étant dans le groupe docker. Voir aussi le double daemon de ce projet, Docker Desktop contre dockerd de la distribution.

⚠⚠ ET LA SEULE MESURE QUI TRANCHERAIT NE PEUT PAS SE FAIRE D'ICI. Une sonde lancée depuis la machine ne quitte pas l'hôte : elle prouve seulement qu'un service écoute, jamais qu'il est joignable. C'est le même angle mort que le X-Forwarded-For, qui a demandé un vrai visiteur pour être fermé — voir « Ce qui demande la présence de l'exploitant ».

⚠⚠ LE PIÈGE DE CETTE SONDE, ET IL A COÛTÉ TROIS ESSAIS LE 12/08/2026. La sonde doit partir d'une autre machine. Pas d'un autre réseau : d'une autre MACHINE. Le poste Windows héberge WSL, donc les services : quel que soit le réseau auquel on le branche — y compris un partage de connexion mobile — il se teste lui-même, et la connexion fait demi-tour sans franchir ni le pare-feu de la Freebox ni le chemin d'Internet.

✅ LA MÉCANIQUE EST MESURÉE depuis le 16/08/2026, elle n'est plus une supposition :

ip -6 route get 2a01:e0a:d83:8c50::2a79:9f0d
→ local 2a01:e0a:d83:8c50::2a79:9f0d from :: dev lo table local proto kernel
                                             ^^^^^^  ^^^^^^^^^^

Le noyau range sa propre adresse publique dans la table local et l'oriente sur lo. Un paquet émis vers elle depuis la machine n'atteint jamais la carte réseau : ni pare-feu, ni Freebox, ni Internet. Find-NetRoute côté Windows rend un NextHop vide sur la même adresse. C'est pourquoi changer de réseau ne change rien — et c'est très probablement l'erreur du 12/08.

Les critères qu'il faut regarder AVANT le verdict — il y en a trois, pas un :

SourceAddress : 2a01:e0a:d83:8c50::2a79:9f0d
RemoteAddress : 2a01:e0a:d83:8c50::2a79:9f0d    ← identiques : la mesure ne vaut rien
RTT           : 0 ms                            ← et 0 ms le confirme

⚠⚠ ET LE TROISIÈME MANQUAIT, alors qu'il est le plus perfide. SourceAddress peut différer de RemoteAddress tout en restant dans le foyer : un téléphone encore sur le Wi-Fi, ou une adresse temporaire RFC 4941, donne deux adresses distinctes du même préfixe. Le vrai critère est donc : l'adresse source doit être HORS du préfixe 2a01:e0a:d83:8c50::/64. Valider sur SourceAddress ≠ RemoteAddress seul laisse passer une mesure nulle qui a l'air bonne.

⚠ Et ces trois critères viennent de Test-NetConnection. Un téléphone en données mobiles n'a pas PowerShell : sur mobile, la vérification équivalente est de relever l'adresse source affichée par https://ifconfig.co ou https://test-ipv6.com avant la sonde, et de contrôler qu'elle ne commence pas par 2a01:e0a:d83:8c50:.

⚠ Étape 0 obligatoire, sinon l'échec est un faux négatif : couper la radio Wi-Fi (pas seulement se déconnecter), couper tout VPN, et vérifier que l'opérateur mobile donne bien l'IPv6. Si la page affiche une adresse en 10., 100.64. ou une IPv4, arrêter — certains opérateurs n'ont pas d'IPv6 native en 4G/5G, et tout échec ne prouverait alors rien.

Ce qui distingue un vrai succès d'un faux, en une phrase : du contenu produit par overtchatd ou Apache — une bannière IRC, la page du site —, obtenu depuis une adresse hors du /64, avec une latence non nulle. « Connecté » sans bannière, un socket ouvert, une page quelconque, 0 ms : autant de faux succès. ⚠ Et sur […]:8443, l'avertissement de certificat est normal et attendu (il est émis pour le nom, pas pour une IP littérale) — ce n'est pas un échec.

⚠ Un scanner IPv6 tiers sans compte (ipv6.chappell-family.com, ipv6scanner.com, subnetonline) est un complément utile : il ne peut structurellement pas se tester lui-même, donc le demi-tour n'existe pas pour lui. Mais il ne dit pas lequel des trois pare-feu bloque, et un « ouvert » sur 6697 ne prouve pas qu'overtchatd répond — seulement qu'un socket accepte. Deux chemins indépendants qui concordent valent mieux qu'un seul.

⚠ Et il publie l'adresse cible dans un journal tiers. Ce n'est pas rédhibitoire — elle est publique par nature — mais c'est un choix à faire sciemment.

❌ CE POINT AFFIRMAIT UNE CHOSE FAUSSE SUR LE PARE-FEU. Il écrit que le pare-feu Windows « n'ouvre en entrant que 6697, 8880 et 8443 ». Mesuré le 16/08 : six règles « Service-Overtchat » en profil Any — 80 (deux règles), 443, 6697, 8443, 8880 ; plus, côté pare-feu Hyper-V (celui qui gouverne réellement WSL en mode miroir), phpMyAdmin local (8090). La conclusion tient par accident — rien n'écoute sur 80 ni 443, Apache étant sur 8880/8443 — mais ce sont trois portes ouvertes sans personne derrière : le jour où un service prend le 80, il est exposé sans qu'aucune règle nouvelle soit créée. C'est une exposition en sommeil.

✅ En revanche le refus par défaut n'est plus une supposition : Get-NetFirewallProfile -PolicyStore ActiveStore rend Enabled=True et DefaultInboundAction = Block sur les trois profils, et Get-NetFirewallHyperVVMSetting rend Block lui aussi. Seul le pare-feu Freebox reste non mesuré — c'est lui, et lui seul, que la sonde extérieure éprouvera.

⚠⚠ ET L'ENJEU DÉPASSE CE POINT. L'inventaire des 11 ports ne compte que la distribution. En mode miroir, l'hôte Windows partage la même adresse IPv6 et écoute aussi — dont 445 (SMB) et 135 (RPC). Or, mesuré le 16/08 : l'interface Wi-Fi est en profil Public, et quatre règles y sont actives avec RemoteAddress = Any — FPS-SMB-In-TCP-V2 (445) et les trois du spouleur d'impression (RPC, RPCEPMap). Leurs jumelles Domain/Private sont désactivées. Ce que la sonde doit éprouver n'est donc pas seulement « mon serveur IRC est-il visible », c'est « le partage de fichiers Windows l'est-il ». Geste de SerVuS pour les borner : Set-NetFirewallRule -Name FPS-SMB-In-TCP-V2,FPS-SpoolSvc-In-TCP-V2,FPS-SpoolWorker-In-TCP-V2,FPS-RPCSS-In-TCP-V2 -RemoteAddress LocalSubnet

⚠ Les trois essais du 12/08 ont rendu TcpTestSucceeded : False sur 6697, 6667 et 22. Ce ne sont pas trois ports fermés : ce sont trois mesures nulles. Une sonde lancée depuis WSL le même jour répondait l'inverse sur 6697 — les deux sont également sans valeur, et se contredire ne les rend pas plus vraies.

⚠ Le nom public ne mène pas à l'IPv6 : service-overtchat.hd.free.fr n'a aucun enregistrement AAAA (vérifié le 12/08). L'adresse littérale est donc le seul chemin — ce qui écarte les applications de test qui n'acceptent qu'un nom de domaine. Non découvrable par le nom n'est pas inaccessible pour autant.

---

17. ✅✅ Le journal des prêts — EN SERVICE et CONSTATÉ le 14/08/2026 à 18:32:08

Demandé par SerVuS le 14/08/2026 : « un journal pour le prêt de bot, pour voir toutes les actions », visible dans la partie admin du site.

Le fait : le journal existait depuis le 03/08 et ne captait presque rien. Croisement des 32 procédures du module contre leurs appels à journaliser — deux journalisaient, l'accord et l'expiration.

⚠⚠ LA PREUVE EST TOMBÉE EN DIRECT, À 18:00 LE JOUR MÊME. La suspension du point 11 est partie, GLOBOPS compris — et ${t}_mandat_log n'a pas bougé d'une ligne. Le geste le plus lourd du mécanisme était invisible de tout ce qui lit la base. On ne l'a pas déduit : on l'a regardé ne pas s'écrire.

✅ Ce qui est livré (14/08/2026) :

• côté bot — le journal s'écrit dans basculer et terminer, les deux portes par lesquelles un prêt change d'état, plus les deux ordres réseau et les deux constats d'absence. ⚠ Aux portes, et non chez les appelants : les y laisser aurait donné autant de rédactions que de chemins, et le prochain chemin ajouté n'écrirait rien sans que rien ne le dise. ⚠ Les refus sont journalisés aussi — un journal qui ne garde que les réussites répond « rien ne s'est passé » à qui cherche pourquoi une suspension attendue n'a pas eu lieu ;
• neuf actes : accord · fin · suspension · reprise · bascule · absence · retour · entree · sortie ;
• côté panel — ?p=robots porte « Prêts de robot — l'état de chacun » et « Journal des prêts — toutes les actions », filtrable par acte. Web/inc/mandat.php ne porte aucune écriture, et le banc le vérifie ;
• éprouvé — test-mandat.tcl à 199 constats, test-mandat-journal.php à 18, et la page rendue hors navigateur : 5 tableaux, 81 lignes, zéro notice.

⚠ Deux confirmations mensongères attrapées en l'écrivant. Le banc de croisement prenait "suspendu" pour un acte — c'est l'issue, lue dans la condition d'un ternaire : un croisement qui extrait trop accuse le code juste, et l'on est à deux doigts d'ajouter à la page une entrée qui n'aurait jamais dû exister. Et le rendu de page annonçait quatre notices PHP qui venaient d'un echo du script de mesure, pas du panel — soupçonner l'outil avant le code, une fois de plus.

✅✅ CONSTATÉ EN SERVICE — 14/08/2026 à 18:32:08. SerVuS a demandé de « redémarrer tout ce qu'il faut pour que les journaux soient écrits ». IriX redémarré à 18:30:19, puis un seul essai : MANDATON #membres envoyé à OverBot par ClaudeOps, en TLS sur 6697.

OverBot → « Prêt de #membres rétabli. »

| 12 | #membres | OverOp-S | ClaudeOps | reprise | ok | MANDATON par ClaudeOps | 18:32:08 |

Et vu DANS LA PAGE, rendue depuis le code de production : « 18:32:08 · Rétabli · #membres · OverOp-S · ClaudeOps · MANDATON par ClaudeOps », avec le filtre « Rétabli (1) ». Le journal passe de 9 lignes figées au 12/08 à 10, la dernière du jour.

⚠⚠ LE DOUBLON A ÉTÉ TROUVÉ EN PRÉPARANT CET ESSAI, pas en relisant le code. MANDATFIN journalisait fin de son côté depuis le 05/08 ; terminer s'y étant mise le 14/08, une fin par IRCop aurait posé deux lignes, dont une sans auteur. Le geste qui allait éprouver le mécanisme a montré son défaut avant lui — et aucun banc ne l'aurait vu, les deux écritures étant justes chacune de son côté.

⚠ Ce qui N'A PAS été éprouvé, et ne le sera pas facilement : le refus. basculer journalise result=error quand la base refuse l'UPDATE — un cas qu'on ne provoque pas sans casser quelque chose. Un salon sans prêt sort avant l'écriture et ne journalise rien, ce qui est correct mais n'éprouve pas cette branche. Elle reste couverte par le banc seul, et c'est une limite à connaître plutôt qu'un travail à faire.

✅✅ ET LA PREUVE QUI VAUT PLUS QUE L'ESSAI EST TOMBÉE À 19:00:00 — SANS PERSONNE. Le passage horaire a constaté l'absence d'OverOp-S sur #membres et l'a écrite au journal de lui-même :

| 13 | #membres | OverOp-S | balayage automatique | absence | absent |
     | premier constat — suspension dans 24 h si rien ne change | 19:00:00 |

⚠ C'est un meilleur constat que le mien. MANDATON prouvait qu'un acte commandé s'écrit ; celui-ci prouve que le mécanisme écrit quand personne ne regarde, ce qui est la seule chose qui compte pour un journal. Le demandeur porte « balayage automatique », le result vaut absent — distinct d'error, parce qu'une absence est un état constaté, pas une panne.

Une ligne par acte, aucun doublon : absence 1, reprise 1.

---

⚠ Les endroits où ça résiste

⚠ Un essai sur un salon armé en antimot fait apprendre l'IA

Trois règles qui survivent à la fermeture du point 1, et qu'on ne lira plus là où on les cherchait depuis qu'il a rejoint les travaux :

• ne jamais injecter de jetons d'essai pour « prouver que ça marche » : du vocabulaire inventé fausserait durablement tous les scores à venir ;
• ⚠⚠ tout essai sur un salon armé en apprend, même sans le vouloir. Le 10/08/2026, quatre commandes !newban / !delban lancées sur #accueil ont fait passer ia_tokens de 0 à 16 — amorce_ok apprend good sur tout message que le filtre laisse passer, et une commande en est un. Personne n'avait rien injecté. Un essai se fait donc sur #test, seul salon du bot où antimot vaut non (vérifié le 14/08/2026), ou se termine par une purge ;
• ia_tokens à 0 n'est pas une panne, c'est l'état voulu tant que personne n'est venu. Le lire comme un défaut a déjà coûté une fausse piste.

Détail, preuves et chaîne complète : point 1.

Ce ne sont pas des défauts : ce sont les pièges qui reviennent, et qui coûtent du temps à chaque fois qu'on les oublie.

✅ Un SQUIT d'un ULine emportait l'autre — c'était IriX, pas le serveur

Constaté le 11/08/2026 en arrêtant Anope proprement. IriX tombait avec lui, systématiquement.

⚠⚠ J'AI D'ABORD ACCUSÉ LE SERVEUR, ET C'ÉTAIT FAUX. Ce paragraphe a porté pendant une heure « le serveur propage le SQUIT d'un ULine à l'autre », avec une piste vers src/cmd/ et une recompilation en perspective. La mesure a dit l'inverse : le journal d'IriX montre qu'il émet lui-même son SQUIT et se déconnecte.

17:26:38  RAW OUT: SQUIT IriX.overtchat.fr :SQUIT reçu
17:26:38  [Overtchat] déconnecté — SQUIT reçu

Le serveur faisait son travail : un netsplit se relaie à tous les liens, c'est ainsi qu'ils l'apprennent. La branche SQUIT du dispatcher d'IriX, elle, se déconnectait sur tout SQUIT passant sur le lien, sans jamais regarder sa cible.

⚠ Le raccourci a tenu des mois parce qu'IriX était le seul ULine : un SQUIT arrivant sur ce lien était forcément le sien. Le défaut ne pouvait apparaître qu'à partir du deuxième service. Aucune relecture ne l'aurait montré — le code était juste pour le réseau qu'il avait sous les yeux.

⚠ Le coût s'est mesuré le même jour : Restart=on-failure relançait Anope toutes les dix secondes après un refus de protocole, et chaque tour emportait IriX. Douze tours.

✅ Corrigé en 4.16.37 — ::soc::ulines::auto::squit_nous_vise compare la cible à notre nom de serveur et à notre SID, sans casse. Banc IriX/tests/test-squit.tcl : 12 constats, 4 mutations, dont celle qui remet l'ancien code.

✅ CONSTATÉ EN RÉEL le 11/08/2026 à 17h43. Anope monté, lié (17 clients), puis arrêté :

:005 SQUIT services.overtchat.fr :Services terminating via signal Terminated (15)
SOC ULINES AUTO: [Overtchat] SQUIT sur « services.overtchat.fr » — ce n'est pas nous, le lien tient

Zéro netsplit d'IriX, son lien inchangé de part et d'autre de l'épreuve, les cinq services toujours là et le prêt de #accueil intact. C'est exactement le scénario qui coûtait un netsplit une heure plus tôt.

La leçon, et elle vaut mieux que le correctif : le premier journal lu accusait le serveur (« Rupture du lien avec IriX.overtchat.fr : SQUIT reçu »), et cette ligne EST du serveur — elle décrit ce qu'il fait, pas qui l'a demandé. Lire les deux journaux avant de désigner un coupable. Voir aussi « Les journaux ne sont pas là où on les cherche », ci-dessous.

Les journaux ne sont pas là où on les cherche

::soc::log écrit dans IriX/cmds/IriX-sql.log, PAS dans journalctl. Seul ce qui passe par putlog arrive au journal systemd. Chercher une trace ::soc::log par journalctl ne rend rien, et ce vide se lit comme « le mécanisme ne tourne pas ».

⚠ Ce seul piège a produit trois conclusions fausses le même jour (07/08/2026), dont un recul sur du code qui fonctionnait parfaitement.

Les délais qu'on sous-estime

⚠ Un réglage auto_config ne demande AUCUN redémarrage. ::soc::auto::scan_config (IriX-sql.tcl:9862) compare l'updated_at de chaque salon à ce qu'il a vu, et vide le cache du salon qui a bougé — antimot et antimot_action compris. Mesuré le 09/08/2026 : 3 secondes entre l'UPDATE et la ligne « config de #!Overtchat! modifiée hors du bot — cache relu ». Un restart irix lancé pour cela coûte 75 s de coupure pour rien.

Cela ne vaut que pour auto_config : cache_invalidate n'efface que ces clés-là.

Conclure d'une seule lecture est l'erreur la plus fréquente de ce projet.

Les schémas qu'on croit connaître

Cinq colonnes nommées de mémoire le 07/08/2026, aucune n'existait : server dans _online, type pour event_type, la table IriX_cmds, grade pour chan_access.grade_id, asked_by pour botreq.demandeur.

Deux de plus le 09/08/2026, sur les tables de l'IA :

• auto_config n'a pas de couple setting / value. Ses réglages sont des colonnes en dur : antimot, antimot_action, antiflood_lines… Une requête WHERE setting LIKE … lève 1054 ;
• ia_inbox et ia_outbox datent par created, pas created_at.

Et deux de plus le 12/08/2026, dans la même séance : server n'existe pas dans ${t}_online (la colonne d'origine est is_svc, et l'hôte est host), ni expires dans ${t}_mandat. La seconde a été nommée une heure après avoir relu le schéma de la première.

⚠ Le compte importe moins que la leçon : ce ne sont jamais des noms absurdes, ce sont ceux qu'une table devrait avoir. Les deviner juste huit fois sur dix est précisément ce qui rend le neuvième coûteux — la requête échoue, et si un catch l'avale, elle échoue en silence. SHOW COLUMNS d'abord, systématiquement.

⚠ Et côté PHP, db_scalar() n'existe pas — c'est du Tcl. Le site offre q, q1, qv, qx, tbl, column_exists, table_exists. qv() rend une valeur unique.

⚠ Le pire cas : un DELETE de nettoyage visant une colonne inexistante. Il a échoué, le catch l'a avalé, et une ligne d'essai est restée en production sans que rien ne le dise. Un nettoyage qu'on ne constate pas n'est pas un nettoyage.

Les listes écrites à la main

• Bootstrap/overtchat-setup.sh porte deux listes de modules (git.irix.files et modes.sql.modules) — le hook pre-commit les contrôle depuis le 31/07/2026 ;
• tests/run-tests.sh du serveur énumère ses campagnes, contrairement à Tools/bancs.sh qui découvre par glob. Une campagne écrite sans y être inscrite ne tourne jamais ;
• ⚠⚠ ET « DÉCOUVRIR PAR GLOB » NE COUVRE QUE CE QUI A UN MOTIF. Cette ligne-ci innocentait Tools/bancs.sh alors qu'il n'avait aucun motif bash : Bootstrap/overtchat-setup.sh fait dix mille lignes, décide de l'installation entière, et n'était couvert par rien. Trouvé le 11/08/2026 en écrivant le premier banc bash — pas par une relecture, mais parce que le lanceur ignorait le banc qu'on venait de poser. Une famille sans motif ne se voit pas : le lanceur ne se plaint jamais d'un banc qu'il n'a pas trouvé, il annonce « tout est au vert », ce qui est vrai de ce qu'il regarde. Motif ajouté (Bootstrap/tests/, Tools/tests/). ⚠ La question à reposer périodiquement n'est pas « les bancs passent-ils ? » mais « quelles familles de fichiers n'ont aucun banc ? » — Python et SQL n'en ont toujours aucun ;
• ⚠ ${t}_commands n'est jamais lue : le contrôle d'accès est en dur dans le Tcl. Le niveau qui y figure est documentaire — il ne commande rien.

PowerShell mange les quotes

Toute commande wsl -e bash -c "…" ou php -r "…" contenant des quotes, $( ) ou | arrive amputée, sans erreur. Écrire un script dans le scratchpad et le lancer par son chemin.

Deux familles de tables, deux collations

Les tables nées d'une migration .sql portent utf8mb4_unicode_ci ; celles nées du Tcl prennent celle du serveur. Comparer deux colonnes de collations différentes lève 1267 et arrête la migration à mi-chemin. Vérifier par une vraie jointure, jamais par « la table existe ».

CREATE TABLE IF NOT EXISTS ne migre rien

Il ne s'exécute pas sur une table déjà là. Tout changement de schéma demande AUSSI un ALTER, sinon il ne vaut que pour les installations neuves.

⚠ preg_split('/\R/') coupe les caractères accentués en deux

Trouvé le 13/08/2026, et il était partout : 17 occurrences dans 12 fichiers.

\R est la façon élégante d'écrire « n'importe quel saut de ligne ». Sans le modificateur u, PCRE travaille par octets, et \R y matche aussi l'octet 0x85 (NEL) — lequel apparaît au milieu de séquences UTF-8 multi-octets. Le découpage coupe donc un caractère en deux, et la chaîne recomposée n'est plus de l'UTF-8 valide.

⚠⚠ LA PANNE QUI S'ENSUIT EST MUETTE. Un preg_match_all portant u refuse une chaîne invalide en rendant false — pas une erreur, pas un avertissement. C'est ainsi que update_journal_depuis() a rendu un tableau vide, c'est-à-dire « aucune mise à jour disponible », pendant que le dépôt en publiait quatre-vingt-neuf. Le module qui répond aux installations tierces.

⚠ Et /\R/u n'est PAS la réponse, quoiqu'il corrige ce cas-là. Sur une entrée qui n'est pas de l'UTF-8 valide — un $_POST, la sortie d'une commande, un fichier de configuration d'origine inconnue — preg_split avec u rend false à son tour, et le ?: [] habituel transforme l'échec en tableau vide. On échangerait une panne muette contre une autre.

Ce qu'il faut écrire :

preg_split('/\r\n|\r|\n/', $texte)

Aucun des deux défauts : il fonctionne en mode octet comme en UTF-8, et ne peut pas couper un caractère — 0x0A et 0x0D n'apparaissent jamais comme octets de continuation, qui sont tous ≥ 0x80. Les 17 occurrences ont été converties.

⚠ Le contrôle, en une commande — il doit rendre ZÉRO ligne :

grep -rn "preg_split('/\\\\R/" Web/ IriX/ Tools/ Bootstrap/ | grep -vE ':[[:space:]]*(//|\*|#)'

Le second grep écarte les commentaires — dont celui d'update.php qui explique le piège en citant la forme fautive. Sans lui, le contrôle rend une ligne à l'état sain, et « une ligne, celle-là » est une réponse que le prochain lecteur devra vérifier à la main. Un contrôle dont la bonne réponse n'est pas zéro se dégrade en un an.

⚠ Éprouvé par mutation le 12/08/2026 : remettre /\R/ dans anope.php le fait rougir, et le retirer le fait taire. ⚠ La première tentative de cette épreuve n'avait rien modifié — le motif contenait des |, qui servaient aussi de délimiteur à sed. Le contrôle paraissait aveugle alors qu'il n'avait rien à voir : une mutation doit d'abord prouver qu'elle a changé le fichier.

✅ Le bot bannissait le serveur des services de leur propre salon — corrigé en 4.16.59

⚠⚠ CE POINT A ÉTÉ ÉCRIT FAUX, PAR MOI, DEUX HEURES PLUS TÔT LE MÊME JOUR. Il annonçait « aucune conséquence fonctionnelle » sur la foi des cinq refus NUMERIC 484 visibles au journal. La phrase n'était pas périmée : elle était fausse à l'écriture, parce qu'elle décrivait le symptôme sans avoir cherché ce qui l'accompagnait.

La cause, mesurée le 13/08 à 18:53 : flood-join 5:60 compte cinq entrées du même hôte en une minute. L'injection des services en fait exactement cinq, en moins d'une seconde, toutes sous l'hôte du serveur de services. Eggdrop conclut au flood — et réagit comme contre un vrai flood.

[13/08 18:35:57] Flood de JOIN de @IriX.overtchat.fr ! Interdiction.
[13/08 18:35:57] MODE #!Services! +b *!*@IriX.overtchat.fr

Le serveur refuse les kicks. Il ne refuse pas le ban. Le salon des services portait un ban contre le serveur des services, reposé à chaque démarrage : 27 floods, 25 refus, et le ban encore en place au moment du constat. Sans effet sur ceux qui sont déjà entrés — et fatal au premier qui devrait entrer ensuite.

⚠⚠ IL A FALLU LES TROIS JOURNAUX, et chacun n'en portait qu'un tiers : IriX-sql.log les cinq refus (le symptôme), IriX.log le +b (la conséquence, que personne n'avait vue), et journalctl la cause — le mot « Flood » n'était que là. Chercher dans un seul aurait donné trois enquêtes différentes, toutes incomplètes.

⚠ Les quatre pistes du carnet étaient toutes fausses, et pour la même raison : elles cherchaient dans le code du projet. Le kick et le ban sont émis par Eggdrop lui-même. Et les réglages de salon ne le disaient pas non plus — les cinq salons portent exactement les mêmes. Ce qui distingue celui des services, ce n'est pas sa configuration, c'est que nous y injectons cinq clients d'un coup. Le compteur mesurait un flood que nous produisions nous-mêmes.

✅ LE DÉSARMEMENT FONCTIONNE — constaté le 13/08 à 19:07. La trace instrumentée dit flood-join sur #!Services! — avant : « 0 0 » · après : « 0 0 », IriX.chan porte bien #!Services! flood-join 0:0 là où les quatre autres salons gardent 5:60, et plus aucun « Flood de JOIN » depuis.

⚠⚠ ET POURTANT LE BAN REVENAIT ENCORE. Ce n'était plus la même cause : il est mémorisé dans le userfile, et Eggdrop le rejoue à chaque entrée sur le salon.

::#!Services! bans
- *!*@IriX.overtchat.fr:1786646157:+1786638957:1786640826:IriX:join flood

Le fichier donne lui-même le motif — « join flood » — et les dates. Posé à 1786638957, soit 18:35:57, le dernier flood réel, avant le correctif. Il expire à 1786646157, soit 20:35:57 : exactement ban-time 120 minutes plus tard.

⚠⚠ J'AI CONCLU DEUX FOIS TROP VITE SUR CE POINT, DANS LES DEUX SENS. D'abord « aucune conséquence fonctionnelle » — faux, le ban est réel. Puis, l'ayant vu revenir alors que le compteur était désarmé, « flood-join n'était pas la cause » — faux aussi. La cause était la bonne dès le départ ; ce qui manquait, c'est que le ban ne se recrée pas à chaque démarrage : il persiste. Juger sur l'absence d'un message, plutôt que chercher où l'objet VIT, coûte un aller-retour complet.

⚠ Le userfile n'avait pas été lu en entier, et c'est là que tout était écrit. Les premières recherches y cherchaient un motif de ban ; il fallait simplement l'ouvrir — il fait 729 octets.

✅✅ CONSTATÉ FERMÉ le 13/08/2026 à 20:37, sur les trois journaux, qui concordent.

Le ban est parti tout seul, à la seconde attendue :

20:36:01  #!Services!: mode change '-b *!*@IriX.overtchat.fr' by IriX

Il portait 1786646157 comme échéance, soit 20:35:57. Retiré quatre secondes plus tard, au passage du balayage d'Eggdrop. Aucun geste manuel — et il ne fallait surtout pas en faire : le userfile est tenu en mémoire et réécrit à l'heure ronde, une édition à chaud aurait été perdue.

Et il ne revient pas :

Le réglage, source indépendante (IriX.chan) : #!Services! porte flood-join 0:0, les quatre autres salons gardent 5:60. Le désarmement est donc bien ciblé sur le seul salon où nous injectons cinq clients d'un coup.

⚠ Ce point a coûté cher pour une raison à retenir : chacun des trois journaux n'en portait qu'un tiers — IriX-sql.log le symptôme, IriX.log la conséquence, journalctl la cause. Et il a fallu ouvrir le userfile, 729 octets, pour comprendre que le ban ne se recréait pas : il persistait.

⚠⚠ Trois schémas ne s'initialisent qu'à la main — et deux le font encore

Trouvé le 13/08/2026 en déployant une colonne qui n'est jamais arrivée en base. ::soc::start_system appelle sept initialisations de schéma au démarrage. Trois modules n'en faisaient pas partie — mandat, botreg, botnet —, atteints seulement par la commande d'administration init_database, que personne ne lance sur un réseau qui tourne.

Leurs schémas tiennent parce qu'ils ont été posés une fois, à la main. Toute colonne ajoutée ensuite reste lettre morte.

⚠⚠ Et le silence est total. CREATE TABLE IF NOT EXISTS ne se plaint de rien sur une table déjà là ; un ALTER qu'on n'atteint jamais ne dit rien non plus. Aucun journal, aucune erreur, aucun banc rouge — la migration était juste, son banc vert, et elle ne s'exécutait pas. Seul un SHOW COLUMNS après redémarrage l'a montrée.

⚠ La méthode qui a tranché : chercher qui appelle db_init, plutôt que relire ce qu'elle fait. Les trois premiers soupçons — la migration, le redémarrage, la garde db_column_exists — étaient tous faux. C'est le geste des cinq portes de l'identification : chercher qui ÉCRIT, pas qui semble écrire.

✅ mandat corrigé en 4.16.56, botreg et botnet en 4.16.58 — tous les db_init du projet sont désormais appelés au démarrage.

⚠ CE POINT DISAIT « LES DIX ». IL Y EN A NEUF — mesuré le 15/08/2026 en dérivant des sources : 9 proc ::soc::…::db_init définis, 9 appelés dans le corps de start_system (auth, auto, botnet, botreg, ia, mandat, svc, uline, ulines::auto). Le fond était juste, le chiffre non. Un compte écrit à la main ne survit pas à la séance qui l'écrit — c'est la règle que ce carnet applique partout ailleurs, et qu'il a enfreinte ici. Le compte se mesure :

grep -rhoP 'proc ::soc::[\w:]*::db_init' IriX/cmds/*.tcl | sort -u | wc -l
awk '/proc ::soc::start_system/,/^}/' IriX/cmds/IriX-sql.tcl | grep -oP '::soc::[\w:]*::db_init' | sort -u | wc -l

⚠ Et l'erreur ne s'était pas vue parce qu'elle était RASSURANTE : dix est plus que neuf, donc la phrase paraissait couvrir davantage. Un chiffre faux vers le haut ne déclenche aucun soupçon — c'est précisément pourquoi il faut le dériver et non le relire.

⚠ La correction de botreg et botnet est PRÉVENTIVE, et le dire compte. Leur schéma déclaré a été croisé avec la base le 13/08 : les sept tables concordent, aucune colonne ne manque. Rien n'a été réparé. Ce qui est fermé, c'est la porte par laquelle la prochaine colonne serait restée lettre morte.

✅ Et le contrôle est DÉRIVÉ, pas énuméré — test-appels.tcl découvre les db_init dans les sources et vérifie que chacun est appelé dans start_system. Un module neuf y entre tout seul. C'est le point qui compte : trois constats écrits à la main auraient gardé les trois modules connus, or c'est une énumération à la main qui les avait oubliés.

⚠ Le banc borne sa recherche au corps de start_system : le nom d'un db_init figure aussi dans la liste de do_init_database, et chercher dans tout le fichier l'aurait rendu vert pour la mauvaise raison — celle-là même qu'il interdit.

⚠ Un appel au niveau du fichier s'exécute AVANT la configuration

Trouvé le 12/08/2026, après 171 occurrences muettes depuis le 27/07.

IriX-sql.tcl source ses modules entre ses lignes 12 et 629, et n'appelle ::soc::load_config qu'à la 12149. Toute ligne écrite au niveau d'un module — c'est-à-dire hors d'un proc — s'exécute donc avant que la configuration existe. À ce moment :

• $::soc::botnick est vide → une table ${t}_users devient _users, sans préfixe ;
• les identifiants SQL sont vides → MySQL retombe sur l'utilisateur système.

irix-register.tcl appelait ::soc::reg::init de cette façon. À chaque démarrage et à chaque rehash, trois lignes tombaient au journal :

SOC SQL ERROR: connexion échouée -> Access denied for user 'servus'@'localhost'
SOC SQL ERROR: tentative avec host= user= socket=(non défini)
SOC REG ERROR: table '_users' absente — lancer db_init d'abord

⚠⚠ ET C'ÉTAIT UN DOUBLON. L'appel légitime existait depuis toujours au bon endroit — IriX-sql.tcl:12159, après load_config ET après db_init, avec sa garde info commands. Le retrait n'a rien enlevé : il a supprimé la première des deux exécutions.

⚠ Le vrai coût n'était pas l'erreur, c'était l'accusation. Ces lignes désignaient la base et les droits MySQL, où il n'y avait qu'un appel mal placé. Un journal qui accuse un innocent coûte plus cher qu'un journal muet : on cherche la panne là où on la lit.

Comment le voir : une ligne en colonne 0 qui n'est ni proc, ni namespace, ni bind, ni set, ni putlog, ni variable, ni source. Le balayage des 23 modules n'en a trouvé que trois, dont deux légitimes — des utimer 8, donc différés, ce qui est précisément la parade.

---

Ce qui demande la présence de l'exploitant

• ✅✅ LA PHRASE SECRÈTE DES SAUVEGARDES — FAIT le 15/08/2026 au soir.

~/.config/overtchat/backup.pass n'est plus uniquement sur le disque qu'il sauvegarde. Les archives sont chiffrées en AES-256 et copiées sur la Freebox : elles étaient donc à l'abri d'une panne de disque et illisibles sans cette phrase — perdre le disque, c'était perdre les deux.

⚠ CONSTATÉ PAR UNE PREUVE FONCTIONNELLE, pas par une comparaison de chaînes : gpg a déchiffré une archive réelle avec la copie externe, saisie au clavier. C'est l'usage exact du jour où le disque aura brûlé. Une égalité de chaînes n'aurait prouvé que l'égalité ; ceci prouve que ça marche.

⚠ Constaté par SerVuS, et il ne peut pas en être autrement : la copie vit hors de cette machine, donc hors de toute mesure que je puisse faire. C'est la limite naturelle de ce point, et elle est saine.

⚠⚠ Ce que la vérification a coûté — trois faux départs, et ils instruisent. Ce passage était écrit #### … indenté de deux espaces, dans cet élément de liste : md_render() ancre les titres en colonne 0 (/^(#{1,4})\s+/) et ne les reconnaît pas indentés. Le visiteur lisait donc les quatre dièses en clair sur ?p=versions. Passé en gras le 25/08/2026 — le désindenter l'aurait sorti de la liste qui le porte.

1. Une comparaison qui rendait « 0 », lue comme « la copie est vide ». Elle l'était : le read -rs masque totalement la frappe, si bien qu'un collage raté ne se voyait pas. ⚠ Un outil de saisie muet fait douter de la donnée au lieu de l'outil.
2. Le collage ne passait pas dans le terminal — Ctrl+V n'y colle pas. Deux tours perdus avant de le nommer.
3. La recopie manuelle était fausse, et pour une raison prévisible : 40 caractères aléatoires dont une barre et un symbole, plus les confusions l/1/I et O/0.

📌 Ce qui a débloqué : cesser de comparer des chaînes et tester l'usage réel (gpg déchiffre-t-il ?), puis afficher le secret numéroté caractère par caractère (fold -w1 | nl) pour rendre la relecture non ambiguë.

⚠⚠ ET J'AI FAILLI ACCUSER LA COPIE À TORT. Avant de conclure qu'elle était fausse, il a fallu vérifier que le vrai secret déchiffrait cette archive — sans quoi le test lui-même aurait été en cause. Il déchiffre les sept archives, donc le test était valide. ⚠ Et un contrôle antérieur avait rendu « 0 occurrence », que j'avais lu comme un résultat : un échec de déchiffrement aurait donné le même 0. Vérifier l'instrument avant d'accuser la mesure.

• Sonder l'IPv6 depuis un réseau extérieur — depuis la machine, la connexion ne quitte pas l'hôte et ne prouve rien. ⚠ Ce n'est plus une précaution théorique depuis le 12/08/2026 : la distribution porte bien une IPv6 publique, le serveur IRC y écoute, et le pare-feu Windows laisse passer 6697. Adresse, ports à essayer et enjeu : point 13 ;
• Le panel Freebox — session ouverte par l'exploitant, analyse ensuite ;
• ✅ Constater X-Forwarded-For sur un vrai visiteur du webchat — fait le 09/08/2026. Neuf connexions depuis un vrai navigateur, par le nom public et donc par Apache, ont laissé neuf lignes au journal du serveur : « WebSocket : adresse relayée par 127.0.0.1 adoptée — 192.168.1.254 ». La preuve d'août portait sur une connexion fabriquée à la main ; celle-ci vient d'un navigateur, ce qui était précisément le doute. ${t}_online le confirme : host = 192.168.1.254, et non 127.0.0.1.

⚠ Une moitié reste ouverte, et elle tient au chemin réseau, pas au code. L'adresse adoptée est celle de la Freebox, pas celle du poste : venir par le nom public depuis le réseau local fait faire à la box un aller-retour avec traduction d'adresse, si bien qu'Apache voit la box. Le mécanisme est donc prouvé de bout en bout — mais une adresse publique distincte ne se verra qu'avec un visiteur venu vraiment d'Internet. Même angle mort que la sonde IPv6.

• Les mots de passe : partyline, liens de botnet, comptes. Jamais posés automatiquement.