Le CORE, la nuit
6 – 10 septembre 2026Chapitre 19 — Le CORE, la nuit
Sources vérifiées :
git log brain + myeline 2026-09-06 → 09-10(268 commits) +workspace/backlog/myeline/vision.mdCommits clés :abadcb4(le CORE sera en Python) ·2b46b4b(le CORE a commencé) ·dd9a727(le cache oublié) ·6536a63(six capacités) ·a5b4c26(le test de la fondation) ·e29e71c(la relecture) ·b349e6f(le pointeur perdu)6 → 10 septembre 2026
Le 6 septembre, le brain a un médecin, des témoins, et une liste de ce qui pourrit en silence. Il lui manque un programme.
Le CORE, c’est ce que Myéline veut séparer de la donnée : six capacités qui font le brain, et rien d’autre. Persistance. Indexation et recherche. Écriture gouvernée. Identité et zones. Traces. BSI — les sessions et leurs verrous. Il faut les écrire. Mais d’abord, dans quelle langue ?
À 20 h 32, le banc mesure ce que le CORE devra égaler — avant qu’une ligne existe (e4cc017). Puis, en six minutes :
ab37347 (20:37) — scribe: etude du langage — Rust ne porte aucune des six capacites du CORE
abadcb4 (20:39) — scribe: le CORE sera en Python — la decision et sa condition de reouverture
2b46b4b (20:43) — scribe: le CORE a commence — la persistance est ecrite et prouvee
Six minutes, mais pas un coup de tête. L’étude est dans la vision de Myéline. Le brain avait du Rust — plus de lignes que de Python, ce qui poussait d’abord dans l’autre sens. Sauf que ce Rust ne portait aucune des six capacités : c’était une surface d’affichage, qui parlait à la base 109 fois en direct, et onze fois seulement par le serveur. Choisir Rust, c’était réécrire la recherche sémantique — la partie la plus spécialisée — pour un gain qui ne comptait pas encore.
Tetardtek tranche : « Python me semble bien pour le core. »
Et le coût est écrit à côté. Un interpréteur embarqué d’une centaine de mégaoctets, contre quelques-uns pour un binaire. Le jour où ce poids comptera, la question se rouvrira — « c’est écrit ici pour qu’on s’en souvienne au lieu de la redécouvrir ».
Quatre jours plus tôt, le brain découvrait une décision redécidée à l’identique, faute de mémoire. Celle-ci porte sa propre condition de réouverture.
Les capacités arrivent une par une. Chacune rapatrie du métier qui vivait ailleurs, et chacune apporte ce qu’elle a coûté d’apprendre.
fc55ac7 (20:51) — core : le BSI, sixieme capacite — 440 lignes de shell dont l'essentiel etait du metier
440 lignes de shell, et dedans, des règles : un identifiant se valide ; le temps se compte en UTC des deux côtés — la leçon du 22 août, maintenant dans le programme.
La recherche, elle, refuse désormais de comparer des vecteurs de tailles différentes. L’ancienne tronquait sans rien dire : une requête de trois dimensions contre un index de 768 rendait un score plausible. Un changement de modèle aurait dégradé la recherche sans un bruit.
À 21 h 02, le banc repasse.
dd9a727 (21:02) — bench : le CORE contre la reference V1, et un cache que j'avais oublie
Le CORE était 40 % plus lent que ce qu’il remplaçait. Un cache n’avait pas été rapatrié. « Une régression silencieuse » — que la relecture n’aurait pas vue, et que le banc a vue tout de suite. Le cache revient, gardé par une empreinte : il ne sert que s’il peut prouver sa fraîcheur.
Minuit passé. La sixième capacité attendait une décision, pas du code : quels chemins forment une zone ? Tetardtek tranche après mesure — invariant et programme, zone kernel ; tout le reste, zone instance (b9b1fe9). Trois minutes plus tard :
6536a63 (00:27) — scribe: MY-105 et MY-106 clos — le CORE porte les six capacites
Et quatre minutes après, une faute, reconnue en la commettant.
0c336ee (00:31) — scribe: un handoff date en heure locale — le motif du rework, commis par moi
Le document de passation porte la date du 7 : l’heure locale avait passé minuit. En UTC, c’était encore le 6. Le contrôle de temps a rougi. « C’est exactement MY-25, MY-51 et MY-52 […] commis en écrivant un document qui les cite. »
À 3 h du matin, le CORE passe le test qu’il s’est donné.
a5b4c26 (03:16) — core : le test de la fondation trouve une frontiere mal placee, et on la corrige
La règle de la vision : retirer n’importe quelle brique doit laisser un système qui démarre. Dès le premier passage, l’indexation tirait la recherche — pas pour chercher, seulement pour l’encodeur. Retirer l’une cassait l’autre, alors qu’elles ne se servent de rien. La frontière est déplacée ; le socle devient les deux ponts vers l’extérieur, la base et le modèle.
Une dizaine de minutes plus tôt, le fork avait tenu de bout en bout : 4f8cf97 (03:06) — sept étapes, aucune ne passait vingt-quatre heures plus tôt.
La nuit
Le 7 au soir, le brain change de terrain. Les jours suivants, il travaille pour une application de jeu — des items numérotés, des pull requests, des écrans. Tetardtek dort. Le brain travaille seul.
Ce qui compte n’est pas ce qu’il construit. C’est ce qu’il apprend à faire avant qu’on le relise.
e29e71c (02:48) — scribe: relecture critique de mon propre travail — un vrai bug trouvé
« Plutôt qu’une 11e feature, une passe sur les risques réels de ~3000 lignes écrites seul. » Quatre trouvailles, dont un vrai bug. Personne ne lui avait demandé de se relire.
Le matin, Tetardtek veut fusionner onze PR dans l’après-midi. Le brain répète d’abord — à blanc, dans un arbre de travail séparé, sans toucher au dépôt ni à l’application qui tourne.
445923c (11:50) — scribe: répétition de merge — l'ordre prévu tombait dans un piège
L’ordre prévu la nuit menait à des conflits imbriqués que personne ne voulait résoudre. Une heure plus tard : f1b408a — scribe: les 14 PR passées — et ce que la répétition à blanc a sauvé.
La nuit suivante, une fausse alerte. Le brain annonce qu’un calcul est « massivement faux ». Il se trompe — et se corrige, mesure à l’appui.
1767f5e (03:23) — scribe: correction — l'XP métier n'est PAS fausse, j'avais cru un commentaire
« Seul le commentaire est périmé — mais il se comporte comme une source, et je l’ai cru au lieu de suivre trois greps. »
Et le 9 à midi, le défaut le plus sournois de la semaine.
b349e6f (12:04) — scribe: les 9 PR mergées — et le pointeur de submodule perdu en route
Un git add -A pendant la remise à jour des branches avait écrasé une référence, sur quatre fusions. « Vicieux parce que invisible : la suite restait au vert. » Les tests interrogeaient une base déjà construite avec le correctif. Seule une reconstruction depuis zéro aurait ramené le bug.
Le brain l’a trouvé quand même. Et c’est là qu’il en est, le 10 septembre : il ne se contente plus de faire. Il se relit, il répète, il se corrige — et il apprend qu’une suite verte n’est pas une preuve.
Décisions clés
- Python, et la condition de réouverture. Mesuré avant de trancher : Rust ne portait aucune des six capacités. Le coût est écrit, et le jour où il comptera aussi.
- Le CORE rapatrie le métier. Le shell devient une porte ; les règles apprises — UTC des deux côtés, identifiants validés — entrent dans le programme.
- Refuser le plausible. Des vecteurs de tailles différentes ne se comparent pas ; un cache ne sert que s’il prouve sa fraîcheur.
- Le test de la fondation. Retirer une brique doit laisser un système qui démarre — sinon la frontière est mal placée, et on la corrige avant d’en poser une autre.
- Se relire seul. Une passe sur les risques avant une feature de plus ; une répétition à blanc avant de fusionner.
- Une suite verte n’est pas une preuve. Surtout quand les tests lisent ce qui a déjà été corrigé.