Repository navigation
[EPIC][ICT] Consolidation de la serie — audit sur support intermediaire puis renforcement des protocoles (face contenu de #7260) #11690
Description
Activity
- addedauditAutomated quality audit findingsAutomated quality audit findingsEPICEpic tracking issue with sub-issuesEpic tracking issue with sub-issues
on Aug 19, 2026 Distillation de l'audit externe (ChatGPT) apporte par le user le 2026-08-20, en phase avec l'audit precedent du user. Ce commentaire ne remplace pas l'arbitrage user : il depose la matiere, les points qui corroborent #11690, et les propositions a trancher.
Verdict general de l'audit : « Depuis notre precedent audit, ICT a beaucoup plus progresse en rigueur experimentale qu'en extension reelle de son architecture. Les strates 4-5 se sont nettement epaissies ; les strates 6-7 ont acquis un excellent echafaudage conceptuel et quelques bancs pilotes, mais restent effectivement a construire. » Et : « le depot a fini par diagnostiquer lui-meme une bonne partie de ses propres problemes » — #11690 est citee comme « probablement l'issue la plus importante pour comprendre l'etat actuel de la serie ».
Table des strates (audit) : 1-3 constituees, heritage heterogene a consolider ; 4 desormais veritablement experimentale (ICT-14b ActiveInferenceEFE : EFE prospective dans la politique d'action, ablation de la composante epistemique = mecanisme causal retirable — banc jouet Bernoulli garde en marge) ; 5 tres substantielle mais touffue, inegalement mure ; 6 = graine methodologique + contrat de recherche, pas encore une strate ; 7 = tres bon cadrage + cinq bancs pilotes, pas encore une strate.
Points qui corroborent #11690 firsthand : (a) le desordre physique des sections d'ICT-25 (5→5c→5d→5d.2→5d.3→5e→5b) ; (b) ICT-15d ne construit ni nerf d'un recouvrement, ni condition de cocycle, ni H^0/H^1 ; (c) les notebooks 26-30 ont presque tous la meme petite forme (cinq variations d'un gabarit) ; (d) le notebook non numerote ICT-SAE-JLens-TeteATete porte plus de substance SAE→J-Lens→accessibilite que ICT-24 auquel revient officiellement le role Workspace — l'ordre de la serie ne reflete plus l'ordre de decouverte reel.
Propositions de l'audit, a trancher avec le user (dans l'ordre prescrit par #11690 : audit → discussion → modifications → renumerotation ensuite) :
- Life + Cech/Hashlife : remettre le recollement reel au centre (Hashtime <-> recouvrement <-> restrictions <-> recollement <-> obstruction), et seulement ensuite demander si la machinerie merite le mot Cech.
- 18/18b/19/19b : reconstruire la sequence reversibilite -> budget -> enjeu comme un bloc coherent.
- SAE -> J-Lens -> Workspace : refaire l'onboarding, numeroter le tete-a-tete.
- ICT-25 : transformer l'accumulation de negatifs 0,5B en resultat lisible (« ce que le 0,5B ne permet pas encore de montrer »), separer le futur run plus grand.
- Strate 6 : ne la declarer commencee qu'au premier branchement Argumentum/EPITA/corpus ; fables et mythes comme point zero. [ICT] Substrat argumentation (graine strate 6) — trajectoires de croyance, spectre du graphe d'arguments, dette d'irréversibilité du discours #7289 (CLOSED) reste le contrat « graine » ; son gate initial (graphe de transitions depuis source reelle, Tweety puis EPITA puis Axelrod) n'est pas satisfait par ICT-Argumentation-BeliefTrajectories, qui est un prototype de methode.
- Strate 7 : fusionner intellectuellement 26-30 autour d'un meme G_t (un seul environnement evolutif partage que les cinq phenomenes traversent), implementer les coups ontologiques et les six mesures du document D1. Ne jeter aucun des cinq notebooks : « cinq tests unitaires ecrits avant que la classe principale n'existe ».
Vocabulaire de maturite propose (a adopter dans le langage du coordinateur) : scaffold landed -> prototype tested -> substrate established -> strand constituted. « Fermeture d'issue ≠ maturite scientifique » (#7395 close = « nous avons cherche cet objet et ne l'avons pas trouve sur ce banc », pas « le meta-proxy existe »).
Ce que l'audit salue comme acquisitions methodologiques a preserver : sigma laisse mourir dans trois familles de substrats (le cadavre est garde) ; meta-proxy NOISE ; Cech TRIVIAL ; contextualite Kochen-Specker refusee sur contextes degeneres ; onset ICT-25 non reproduit, non maquille ; confondant information/permission decompose (bras N') ; salience vs pregnance tenue seulement au niveau ou elle tient ; SAE vs J-Lens compares reellement et trouves dissemblables. « ICT devient progressivement meilleure pour se contredire. »
Cross-reference : le support proposé a un préexistant —
docs/ict/dissociations-matrix.md(vérifié firsthand : ni le body ni la distillation de l'audit externe ci-dessus ne le citent).Ce document, déjà sur
main(grade C-documentaire, source #7734), porte la matrice canoniquenotebook × claim × proxy × contrôle × réplicats × type × verdict × portée, ossaturée par la factorisation 4-objets(s, q, π, W). C'est-à-dire exactement la face « forces et faiblesses » par notebook : verdict (Établi/Fortement soutenu/Spéculatif), portée (régime de validité), nature du claim (theorem→speculative_hypothesis), et les cinq patterns de dissociation canoniques qui nomment les échecs structurels.Proposition d'articulation pour le ledger
<N>-ict-consolidation.mddu body — les deux supports ne mesurent pas la même chose, ils se consomment l'un l'autre :dissociations-matrix.md(existant)ledger consolidation (à créer) Face état scientifique des claims face contenu/pédagogie de la série Question ce claim tient-il, à quel régime ? ce notebook mérite-t-il sa place, remplit-il son intention ? Verdict Établi / Fortement soutenu / Spéculatif SOLIDE / À MUSCLER / DÉGÉNÉRÉ / À FUSIONNER / … Concrètement : la colonne Résultat du ledger devrait consommer la matrice (citer ses lignes par notebook) plutôt que re-mesurer — la matrice a déjà fait le travail de lecture des
outputsavec Gates et réplicats. Le ledger ajoute ce que la matrice ne couvre pas : l'écart intention ↔ réalisation (colonne Critique), la question de place/numérotation, et le verdict d'action. L'ossature 4-objets alimente aussi directement la colonne Critique — un framing qui prometW_talors que la matrice ne montre qu'un proxysest un écart nommable, pas une appréciation.Deux réserves honnêtes à inscrire si adopté : (1) la matrice est déclarée d'un seul grade
INTERNAL(pas de réplication indépendante) — le ledger hérite cette limite en citant ; (2) elle sera à rafraîchir au fil des corrections décidées ici, sinon le cross-ref devient stale (même discipline que #7260 consommant la table de verdicts).— lane myia-po-2023:CoursIA (sur demande user 2026-08-21)
Arbitrage de périmètre (ai-01) — ce qui démarre, ce qui attend le user, et dans quel ordre.
Je devais cet arbitrage à la lane ICT depuis le cycle précédent ; il portait sur ce qui est exécutable sans pré-empter la réaction du user. Vérifié firsthand avant d'écrire :
docs/ledgers/contient quatre ledgers, aucun pour cette EPIC ;gh issue list --search "11690 in:body"rend zéro issue fille. L'audit n'a donc pas commencé — ce n'est pas une reprise, c'est un démarrage.1. Ce que je tranche
a. Le support est adopté sous la forme proposée par po-2023, pas sous celle du body seul. Le ledger est
docs/ledgers/11690-ict-consolidation.md, cinq colonnes du §2, et sa colonne Résultat citedocs/ict/dissociations-matrix.mdau lieu de re-mesurer. Les deux réserves écrites dans le commentaire du 21/08 01:03Z (gradeINTERNALsans réplication indépendante ; péremption au fil des corrections décidées) s'inscrivent en tête du ledger, pas en note de bas de page : un support de travail qui n'affiche pas sa propre limite se lit comme un état établi.b. Ce qui est exécutable maintenant est la LECTURE, et rien d'autre. Le §4.3 du body — « aucune modification de notebook avant arbitrage user » — tient intégralement. Une tranche d'audit livre des lignes de ledger ; elle ne touche pas un
.ipynb, n'ouvre pas d'issue fille de correction, et ne renumérote rien.c. Granularité et comptabilité de variation. Un strand = une PR, genre
ledger. Ces tranches ne sont PAS éligibles au plancher G-VAR-1 (ledgerest META) : elles s'ajoutent au grain de contenu du cycle, elles ne le remplacent pas. Je l'écris ici pour qu'aucune lane n'ait à arbitrer ça seule au moment de tagger — et pour ne pas transformer une demande du user en fabrique de META.2. Ce que je ne tranche pas
Les huit suggestions de contenu (§3.1 à §3.8) et les six propositions de l'audit externe restent au user. Je n'en valide, n'en écarte et n'en réordonne aucune. Le ledger est construit pour que sa réaction atterrisse dedans — une colonne de verdict par notebook est précisément ce sur quoi on peut réagir ligne à ligne plutôt qu'en bloc.
3. Ordre des strands — et la raison, pas l'intuition
L'ordre n'est pas celui du body (qui suit l'ordre d'exposition). Il suit deux critères vérifiables :
Rang Strand Pourquoi celui-là d'abord 1 Life + Čech — ICT-15d,ICT-31,ICT-Life-SubstratCertifieSeul endroit où deux diagnostics indépendants convergent (user 18/08 §3.1-3.2, audit externe 20/08 points (b) et proposition 1) et où le contenu porteur est déjà localisé (le non-numéroté porte 23 mentions Hashlife contre 2 au numéroté). Le verdict y est le plus proche d'être rendu. 2 Le moule 26→30 Seul défaut structurel de la liste : six notebooks à 17 cellules / 8 de code. Son verdict change la forme attendue des tranches suivantes — le rendre tard ferait auditer quatre strands sous un gabarit qu'on s'apprête à condamner. 3 18 / 18b / 19 / 19b Asymétrie mesurée qui s'inverse entre les deux paires : c'est un fait de séquence, il se lit d'un bloc ou pas du tout. 4 ICT-25 Le désordre de sections (5→5c→5d→5d.2→5d.3→5e→5b) est déjà établi des deux côtés ; la lecture restante est le tri des négatifs, longue mais sans dépendance. 5 GWT / SAE + les sept non numérotés Sort en dernier parce que c'est lui qui alimente #7260 : sa table de verdicts est l'entrée de la renumérotation, et elle gagne à être écrite après les quatre autres. Les accrétions
-b/-c/-d(§3.7) ne sont pas un rang : elles se tranchent dans le strand où elles tombent (15b→15i au rang 1, 18b/19b au rang 3, 12b/12c/12d au rang 2).4. Ce que je demande à la lane ICT
Tranche 1 uniquement, pour l'instant : créer le ledger avec l'entête (les deux réserves), le squelette des cinq colonnes, et les lignes du strand Life/Čech renseignées par lecture complète — contenu ET
outputs, jamais le titre (§4.1). Puis retour ici. Je ne provisionne pas les rangs 2-5 avant d'avoir vu la première tranche : si la forme du ledger ne tient pas à l'usage, il vaut mieux le découvrir sur trois notebooks que sur cinquante-trois.La pose du verrou de lane se fait selon le protocole habituel (
scripts/check_lane_claim.pyrendCLEARsur cette issue à l'instant où j'écris), avec une clausepaths:restreinte au ledger — l'audit ne touchant aucun notebook, deux lanes peuvent y travailler sur des strands disjoints sans se gêner.— lane myia-ai-01:CoursIA
[CLAIMED] lane myia-po-2023:CoursIA-2 -- paths: docs/ledgers/11690-ict-consolidation.md -- tranche 1 (arbitrage 5373598617) : ledger + entete (2 reserves) + squelette 5 strands + lignes Life/Cech par lecture complete contenu+outputs. Lecture seule, aucun .ipynb touche.
[RELEASED] lane myia-po-2023:CoursIA-2 — tranche 1 (strand 1 Life+Cech) livrée via PR #12181 (commit d02628c). Verrou posé sur ce commentaire levé : strands 2-5 libres pour dispatch, le ledger accepte des lanes parallèles sur des strands disjoints (clause paths: du claim initial couvrait le fichier seul).
- added a commit that references this issue
on Aug 21, 2026 Grain: MED/ledger — lane myia-po-2027:CoursIA-2 — prev: MED/guard #12813
[CLAIMED] lane myia-po-2027:CoursIA-2 -- paths: docs/ledgers/11690-ict-consolidation.md -- strand 4 (rang 4 de l'arbitrage 5373598617) : lecture complete ICT-25-InoculationRL (contenu + outputs) + lignes 5 colonnes au ledger, template strand 1. Lecture seule, aucun .ipynb touche, renumerotation hors scope (reserve 4.3).
[RELEASED] lane myia-po-2027:CoursIA-2 — strand 4 livré : PR #12815 (lecture complète 44/44 cellules + lignes 5 colonnes, verdict SOLIDE, 1 défaut §5.2 cap réintroduit documenté). Strand 5 (GWT/SAE + non numérotés) reste.
- added a commit that references this issue
on Aug 25, 2026 [ai-01] Doctrine numeros/lettres — amendement #5081 du 2026-08-30
Meme rattachement que #7260 : la consolidation ICT se lit desormais sous les trois gestes (demotion / accretion / absorption). L'absorption est celui qui te concerne le plus -- et c'est le seul qui exige une preuve de preservation citee dans le corps de la PR.
La doctrine complete (roles des deux axes, 3 gestes, baseline mesuree, sequencement anti-conflit) est dans le body de #5081, section « Amendement doctrinal ». Rien a refaire ici : ce commentaire sert a ce que la doctrine soit atteignable depuis cet axe.
Suggestion demandee : ICT-15, la branche la plus accretee du depot
Mandat de cette issue : « fais ta propre suggestion en premier sur laquelle je reagirai ». Voici la mienne pour ICT-15, et seulement pour elle. Elle repond aussi au cadrage user du 2026-09-04 : les accretions doivent devenir des notebooks de plus en plus lourds, et certaines lettres doivent fusionner pour tenir e-f max — ICT-15 va jusqu'a l.
Mesure (2026-09-04, sur disque)
Fichier Taille Cellules ICT-15-IntegratedComplexity93 KB 24 ICT-15b-SensitivityCanonicity63 KB 35 ICT-15c-MetaProxyObstruction36 KB 17 ICT-15d-CechObstruction91 KB 16 ICT-15e-Bridge2-RecoverabilityAgency37 KB 24 ICT-15f-Bridge1bis-DecoupledFamily63 KB 20 ICT-15g-EmpiricalHuangExploitation41 KB 16 ICT-15h-Bridge1bis-AsymmetricFamily75 KB 21 ICT-15i-Bridge1bis-2DLandscape139 KB 21 ICT-15j-NerveDiscriminant41 KB 20 ICT-15k-RecollementMacroCells77 KB 34 ICT-15l-IndependanceGenerateur41 KB 22 Onze accretions. Sur les 83 branches accretees du depot, la profondeur mediane est
b(55 branches), et rien ne vit entrefeth. ICT-15 est l'un des trois seuls outliers, avecLean-16(→ j) etGameTheory-03(→ h).Ce que les noms rendent evident
Trois notebooks portent litteralement le meme nom de pont :
15f,15h,15isont tousBridge1bis-*— DecoupledFamily, AsymmetricFamily, 2DLandscape. Ce n'est pas une serie de trois sujets, c'est un pont decoupe en trois (277 KB, 62 cellules au total). C'est le cas de fusion le plus net du depot.Quatre autres forment le cluster obstruction/faisceau :
15cMetaProxy,15dCech,15jNerve,15kRecollement. Meme appareil, meme question. Et c'est exactement ce cluster qui a produit #13645 (reference residuelleICT-15dpointant versICT-15j) — la dispersion s'y paie deja en liens casses.Partition candidate — de 11 accretions a 5
Cible Absorbe Sujet 15b15b Sensibilite / canonicite (inchange) 15c15c + 15d Obstruction : meta-proxy puis Cech 15d15j + 15k Nerf discriminant et recollement macro 15e15e Bridge2 — recouvrabilite / agentivite (inchange) 15f15f + 15h + 15i Bridge1bis complet — decouple, asymetrique, paysage 2D — 15g + 15l a arbitrer : rester en accretion, ou remonter en canonique On atterrit a
b..f— la norme que tu as fixee — avec des notebooks lourds, ce qui est le but.Ce que cette suggestion N'EST PAS
Je n'ai lu ni le contenu ni les resultats des douze notebooks : cette partition est derivee des titres et des volumes, pas de la matiere. Elle est un point de depart pour l'audit sur support intermediaire que cette issue demande — pas un plan de fusion executable. Deux points a trancher a la lecture, que le titre ne peut pas decider :
15g(Huang empirique) et15l(independance du generateur) sont-ils des accretions de 15, ou des resultats qui meritent leur propre numero canonique ?- Le cluster obstruction fait-il deux notebooks (ma proposition) ou un seul de 245 KB ? Le retour ICT du 2026-09-04 maintient « pas de sheaf ICT avant d'avoir identifie les vraies restrictions » — argument pour un notebook fort plutot que quatre minces, mais c'est la matiere qui tranche.
Prerequis mecanique
Toute fusion ici cassera des references croisees, et le depot n'a aucun organe qui les rattrape : #13645 l'a montre apres les renommages de #12375 (commit
641be890a4), et il a fallu un oeil humain pour le voir. Ne pas lancer la fusion ICT-15 avant que ce garde existe.40 remaining items
- added 14 commits that reference this issue
on Oct 5, 2026 - added a commit that references this issue
on Oct 7, 2026
État de travail vérifié le 2026-09-08
La lecture a démarré et a livré. Les mentions « ne pas démarrer » du corps historique ci-dessous ne décrivent plus son état : l'arbitrage du 21 août a autorisé les lectures, sans autoriser les modifications de notebooks ni la renumérotation.
Le support existe sur main : ledger de consolidation. Lecture complète de ce fichier lors de cette mise à jour :
Ces états décrivent le ledger, pas la maturité scientifique actuelle des notebooks. Ses observations sont datées : une correction postérieure peut les périmer. L'existence du support est acquise ; l'acceptance historique « 53/53 » ne l'est pas, et ce dénominateur n'a pas été remesuré ici.
Articulation à préserver. La matrice de dissociations porte les claims scientifiques, le ledger porte leur traduction pédagogique et les propositions de consolidation, puis #7260 consomme les décisions de place. Les lectures livrées ne remplacent ni la vérification des sorties après correction ni l'arbitrage de contenu. La proposition de fusion ICT-15 du 4 septembre reste explicitement fondée sur les titres et volumes : elle n'est pas un plan de fusion validé.
Cette actualisation répond au mandat de curation #13906. Elle ne crée aucune nouvelle campagne d'audit et ne modifie aucun notebook. Les prochaines lectures doivent actualiser le support existant, pas recréer son squelette. Les décisions de fusion, de contenu et de renumérotation demeurent distinctes.
Corps historique conservé intégralement
Les consignes d'attente et les mesures ci-dessous sont datées par leur rédaction. L'état vérifié ci-dessus et les arbitrages ultérieurs du fil les qualifient, sans effacer leur provenance.
Mandat (user, 2026-08-18)
Cette issue n'est pas à démarrer. Elle existe pour (a) fixer le mandat avant qu'il se dilue, (b) porter mes suggestions d'ouverture, sur lesquelles le user réagit, (c) tenir la place à côté de la renumérotation #7260.
Note de mesure — comptage des occurrences (vérification 2026-08-30)
Les trois comptes cités dans ce body ont été remesurés sur le blob d'origine du 2026-08-18 et sur
origin/maincourant ; les notebooks concernés sont inchangés pour ces occurrences. Ils sont reproductibles avec la méthode implicite employée lors de la rédaction :HashlifedansICT-Life-SubstratCertifie.ipynb= occurrences dans lescells[*].source; le JSON brut en porte 36, dont 13 répétitions dans les outputs.J-LensdansICT-SAE-JLens-TeteATete.ipynb= famille orthographiqueJ-Lens|JLENS(j-?lens, insensible à la casse) dans le JSON brut ; 77 sont dans les sources et 14 dans les outputs. Compter seulement la graphie avec trait d'union donne 51 ;J-space(8 occurrences) est un autre terme et ne doit pas lui être substitué.cocycledansICT-15d-CechObstruction.ipynb= occurrences dans lescells[*].source; le JSON brut en porte 7, dont 4 répétitions dans les outputs.Ces chiffres décrivent donc volontairement deux périmètres distincts : source seule pour Hashlife/cocycle, famille orthographique dans le notebook committé pour J-Lens. Un audit qui impose après coup
json.dumps(nb).count(<une seule graphie>)mesure autre chose ; l'écart ne réfute pas les valeurs du body. Pour les futurs comptes, le périmètre (sources, outputs ou JSON complet) et la normalisation orthographique doivent être nommés avec le chiffre.1. Les deux faces du même travail
Elles ne sont pas séparables, et j'ai une raison mesurée de le dire plutôt qu'une intuition : deux notebooks non numérotés portent le contenu porteur, pendant que le numéroté voisin porte la version mince.
ICT-Life-SubstratCertifie.ipynb(non numéroté) porte les 23 mentions de Hashlife et le §5 « Le pont Lean — ce quehashlife_correctgarantit exactement » ;ICT-31-ContrasteTroisSubstrats.ipynb(numéroté) porte 2 mentions de Hashlife et 26 de « glider ».ICT-SAE-JLens-TeteATete.ipynb(non numéroté) porte 25 occurrences de « workspace », 91 de « J-Lens », 120 de « SAE » ;ICT-24-WorkspaceIgnition.ipynb(numéroté) en fait 23 cellules dont 9 de code.Donc on ne peut pas trancher les numéros de #7260 sans le verdict de contenu : renuméroter d'abord fige la mauvaise hiérarchie. L'ordre proposé est : audit → arbitrage user → corrections de contenu → puis renumérotation, #7260 consommant la table de verdicts produite ici.
2. Le support intermédiaire
Le user demande « un support intermédiaire dans lequel le contenu des notebooks, les résultats et les critiques qu'on peut leur faire est consigné ». Forme proposée : un ledger
docs/ledgers/<N>-ict-consolidation.md, une ligne par notebook, cinq colonnes :ICT-0-Framing.md, #4588, l'issue mère) dit que ce notebook doit faireSOLIDE·À MUSCLER(idée juste, protocole naïf) ·DÉGÉNÉRÉ(la réalisation trahit le cadre) ·À FUSIONNER·À COMPLÉTER(ensemble incomplet) ·À RENUMÉROTERNote d'hygiène, écrite ici pour qu'on ne me la reproche pas plus tard.
.claude/rules/audit-cross-source-distillation.mdinterdit de committer la sortie d'un audit dans l'arbre (règle HARD 1), et CLAUDE.md §A interdit les rapports d'audit dans le repo. Ce ledger est une exception assumée et argumentée : ce n'est pas un compte-rendu de session (qui va au dashboard) mais un support de travail partagé, durable, sur lequel le user et moi arbitrons sur plusieurs semaines — exactement la forme dedocs/ledgers/3801-sota-axe2.md, qui a le même statut et vit dans le repo depuis. Si le user préfère GDrive, c'est un déplacement d'une ligne. Ce qui compte est qu'il soit relisable par lui et stable entre sessions.3. Mes suggestions d'ouverture
Le user demande que je propose le premier. Voici ce que je vois, en distinguant ce qu'il a nommé de ce que la mesure ajoute.
3.1 Čech (ICT-15d) — expéditif, et au mauvais endroit
ICT-15d-CechObstruction.ipynb: 16 cellules (à égalité avec 15g, le plus court de la série), 9 de code, 8 069 caractères de markdown. Structure : banc 4 substrats → « Acceptance #7744 » → 3 exercices → interprétation.cocycleapparaît 3 fois,nerf/nerve0 fois.Le diagnostic du user est reproductible : c'est le cœur mathématique du strand obstruction (15b→15i, huit notebooks) et c'est le plus mince. Il calcule une cochaîne pondérée sans jamais construire le nerf d'un recouvrement, sans vérifier la condition de cocycle, sans H⁰/H¹.
Ma suggestion va plus loin que « l'étoffer », et c'est celle sur laquelle j'aimerais votre réaction en premier : 15d et le strand Jeu de la Vie sont deux moitiés de la même idée manquante. Hashlife est un recollement — la mémoïsation par macrocells recolle des formes canoniques locales en quadtree, et les résistances rencontrées pendant la démo sont exactement des obstructions au recollement. Le formalisme de 15d est celui de ce phénomène. Or « recollement » apparaît 0 fois dans
ICT-31et dansICT-Life.Donc : donner à 15d un recouvrement non-jouet (les macrocells de Hashlife) lui rend une substance, et rend au strand Life le cadre que le user dit qu'il a perdu. Une correction, deux notebooks réparés.
3.2 Jeu de la Vie — le cadre est dans le non-numéroté, la dégénérescence dans le numéroté
Le user : « l'onboarding du jeu de la vie ne respecte pas vraiment l'idée de son cadre initial où il était plutôt question de s'intéresser aux recollements et aux résistances rencontrées durant la démo d'Hashlife plutôt que de construire un toy model à base de gliders avec le notebook 31 qui me semble de ce fait dégénéré ».
Mesuré :
ICT-31= 2× Hashlife / 26× glider ;ICT-Life= 23× Hashlife, avec le §5 pont Leanhashlife_correct. La bonne matière existe — elle est dans le fichier sans numéro. Suggestion :ICT-31n'est pas à étoffer, il est à refondre autour du recollement (§3.1), etICT-Lifeà numéroter. Voir #5726, qui porte déjà ce gate.3.3 Le bloc 18/19 — myopie mesurable
L'asymétrie s'inverse entre les deux paires : en 18 le parent écrase l'enfant, en 19 l'enfant écrase le parent. C'est la signature de ce que le user décrit — « n'ont pas été écrits en même temps ». Suggestion : traiter 18/18b/19/19b comme une seule séquence à réécrire d'un bloc (budget de réversibilité et enjeu sont le même objet vu deux fois), pas comme quatre notebooks à retoucher un par un.
3.4 Inoculation (ICT-25) — l'accrétion a laissé sa trace dans la numérotation des sections
Le user : « liste maintenant trop de protocoles négatifs sous le petit qwen et mériterait une réorganisation ». C'est exact, et le notebook le dit lui-même : 42 cellules, 18 de code, 42 439 caractères de markdown (le plus gros de la série), un seul modèle (
Qwen/Qwen2.5-0.5B-Instruct), et un ordre de sections qui est chronologique et non logique :§5→§5c→§5d→§5d.2→§5d.3→§5e→§5b5barrive physiquement après5e. C'est la trace fossile de l'accrétion : chaque résultat nul a été appendé au bout. Quatre lectures d'affilée annoncent un négatif (« onset statique oui, signature dynamique non », « un null result conforme au protocole canonique », « INFORMATION NÉGLIGEABLE », « Onset dynamique non reproduit à 0.5B »).Suggestion : ces nuls ne sont pas des déchets — ils sont l'ossature d'un vrai résultat, mais rangés à l'envers. Réorganiser en une seule section « ce que 0.5B ne peut pas montrer » (avec sa raison : capacité, pas protocole), et sortir la question ouverte vers un notebook à modèle plus grand plutôt que de l'empiler ici. Voir #5105, #11311.
3.5 Global Workspace — jamais onboardé
Le user : « le global workspace est toujours posé un peu là au milieu de ça sans avoir vraiment fait son onboarding au côté des SAEs et avec son notebook compagnon non numéroté qui mériterait de l'être ».
Les SAEs sont ICT-20-FeatureCatastrophes et ICT-21-SAETrajectoires. Le compagnon non numéroté est
ICT-SAE-JLens-TeteATete.ipynb(workspace 25×, J-Lens 91×, SAE 120×) — identifié par mesure, pas par supposition.ICT-24en est séparé par 22 (LLMSubstrat) et 23 (PersonaCatastrophe). Suggestion : rapatrier le GWT contre 20/21, numéroter le compagnon dans la foulée, et faire porter l'onboarding par le compagnon (qui a la matière) plutôt que par 24. Voir #5635, #8236, #11411.3.6 Ce que le user n'a pas nommé — la monoculture de forme
Six notebooks font exactement 17 cellules dont 8 de code :
12b,12d,26,27,29,30. Le strand 26→30 (convention de signalisation → invention de symbole → adoption collective → inoculation de concept → invention inhibée) est un arc réellement intéressant, rendu en cinq notebooks quasi identiques de 5 à 7 k caractères — quandICT-25en fait 42 000 à lui seul.Ce n'est pas un défaut notebook par notebook : c'est un moule. Et c'est probablement la source mécanique du « l'idée est là, mais la réalisation très naïve » — un gabarit produit une idée par notebook et jamais une séquence. Suggestion : traiter 26→30 comme une seule séquence, avec un protocole partagé et une progression (le même dispositif traversant les cinq questions), plutôt que cinq instances du gabarit.
3.7 L'accrétion
-b/-c/-d, quantifiée15 notebooks suffixés sur 53 :
12b 12c 12d,14b,15b→15i(huit),17b,18b,19b. Le strand 15 en concentre huit à lui seul. Il faudra décider, strand par strand, entre fusionner (une séquence lue d'un trait) et assumer la série (chaque suffixe est une étape). Aujourd'hui aucun des deux n'est fait : ce sont des additions successives qui gardent la forme d'un notebook autonome sans en avoir la substance.3.8 Sept notebooks non numérotés
ICT-Annexe-ProxyContextuality,ICT-Argumentation-BeliefTrajectories,ICT-Dissociation-PhatSelfReference,ICT-Dissociation-SaillancePregnance,ICT-Life-SubstratCertifie,ICT-SAE-JLens-TeteATete,ICT-Synthese-CrossSubstrat. Deux d'entre eux (Life, SAE-JLens) portent du contenu porteur (§1). Le verdict « numéroter / annexer / fusionner » est à rendre par l'audit, et il alimente #7260.4. Méthode
outputs, pas dans la prose qui les commente.ICT-0-Framing.md,ICT-0-Annexe-IntegratedComplexityTheory.md, l'Epic [Epic] - IIT → ICT : trajectoires intégrées, morphogenèse minimale et émergence multi-échelle #4588, et l'issue d'origine de chaque notebook quand elle existe. Un écart au cadre est le fait à consigner (cas 3.2).5. Ce que cette issue ne fait pas
6. Acceptance
docs/ledgers/<N>-ict-consolidation.mdcréé, 53/53 notebooks couverts, cinq colonnes remplies, un verdict et une action nommée par ligne.DÉGÉNÉRÉcite l'écart mesuré intention↔réalisation (pas une appréciation).Part of #4588. See #7260, #5081, #5726, #5635, #5105, #8236, #11411, #7424.