Skip to content

[EPIC][ICT] Consolidation de la serie — audit sur support intermediaire puis renforcement des protocoles (face contenu de #7260) #11690

Description

@myia-ai-01

État mesuré au 2026-10-05 (consolidation #13906, lane myia-po-2025:CoursIA). Confrontation des cinq cases d'acceptance à origin/main. L'EPIC n'est pas fermable : elle est laissée ouverte, et ce qui reste est nommé ci-dessous.

Le dénominateur « 53/53 » de la case 1 est périmé. Mesure du jour (git ls-tree -r origin/main, hors _output) : 88 notebooks ICT, contre 53 au 2026-08-18. La série a crû par la renumérotation (-Python, ICT-01..09) et par des additions (ICT-40..47, ICT-15j..15l). Citer 53 sans re-mesurer le dénominateur mesure autre chose que la série.

Le ledger existe, les cinq strands sont lus, mais il couvre 29 notebooks — docs/ledgers/11690-ict-consolidation.md (74 911 octets, 29 sections ### de notebook). Sa table d'avancement le dit : rang 1 LU, rang 2 LU, rang 3 LU, rang 4 LU, rang 5 LU 3/3 tranches.

Case d'acceptance Verdict mesuré Preuve / ce qui manque
1. Ledger créé, 53/53 couverts, 5 colonnes, verdict + action par ligne partielle Ledger présent sur main, convention à 5 colonnes respectée ; 29 notebooks couverts sur 88 aujourd'hui. Le dénominateur 53 n'est plus celui de la série.
2. Chaque verdict DÉGÉNÉRÉ cite l'écart mesuré sans objet aujourd'hui Le jeton DÉGÉNÉRÉ est déclaré dans la convention du ledger et n'apparaît dans aucune ligne (0 occurrence). Les lignes écrites (SOLIDE, À MUSCLER) citent bien l'écart mesuré (« idée juste, réalisation non-contrastante »). La discipline est tenue ; le compteur est à zéro.
3. Passe d'arbitrage user tenue, décisions écrites non tenue Le ledger porte les arbitrages demandés (« actions pour l'arbitrage », findings transverses par strand) ; aucune passe de décision n'y est consignée. C'est le verrou réel de cet EPIC.
4. Une issue fille par correction décidée sans objet tant que 3 n'est pas tenue 11 issues citent cet EPIC ; les filles ouvertes viennent des chantiers (#12204, #12206, #12257, #15475), pas de corrections décidées ligne à ligne.
5. #7260 mis à jour avec la table de verdicts, exécuté après les corrections partielle, ordre non respecté #7260 est CLOSED depuis le 2026-09-18 — donc exécuté, mais avant que les corrections de contenu n'aient eu lieu, alors que la case demandait l'inverse.

Ce qui reste, et où ça vit : (a) la passe d'arbitrage user sur les verdicts déjà lus (rangs 1-5, 29 notebooks) — c'est elle qui débloque le reste ; (b) l'extension du ledger aux 59 notebooks non couverts ; (c) les filles de correction, qui ne peuvent naître qu'après (a). Aucune des trois ne se traite sans le user : l'arbitrage du 21 août a explicitement borné le démarrage à la lecture seule.

Portée non vérifiée : la couverture ligne à ligne après #17861 (correction du 26/09 sur un rang annoncé complet) n'a pas été re-dérivée ici ; les 29 notebooks comptés sont ceux qui portent une section ### dans le fichier au 2026-10-05.

Etat mesure au 2026-10-01 (lane myia-po-2024:CoursIA, reecriture acceptance 4 de #13906)

Livraison postérieure à l'état vérifié du 2026-09-08 ci-dessous : #17861 (mergee 2026-09-26) corrige le ledger de consolidation — la table d'avancement disait « rang 5 LU 2/3 » sur un rang complet. La colonne « Livraison vérifiée » du bloc 2026-09-08 n'a pas été re-derivée ligne à ligne depuis ; elle reste la dernière lecture complète, à actualiser depuis le ledger avant toute décision de place.


É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 :

Strand Livraison vérifiée Portée
Life + Čech #12181, mergée le 21 août Trois notebooks lus, résultats et critiques consignés
ICT-25 #12815, mergée le 25 août Lecture du notebook et tri des négatifs consignés
26–30 Non démarré dans le ledger courant Lecture de séquence restante
18 / 18b / 19 / 19b Non démarré dans le ledger courant Lecture de séquence restante
GWT / SAE et non numérotés Non démarré dans le ledger courant Lecture restante avant proposition de place

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)

Je viens également de passer un bout de temps à relire pas mal de notebooks de la série ICT. Il me semble qu'il faudrait consacrer un Epic à consolider ce qu'on a. Pas mal de notebooks m'ont l'air plus ou moins dégénérés (parfois l'idée est là, mais la réalisation très naïve et peu susceptible de donner satisfaction), et certaines séquences mériteraient une consolidation qui tient compte de la série et des additions ultérieures des -b, -c etc.

Il me semble que ça mérite un audit complet sur un support intermédiaire dans lequel le contenu des notebooks, les résultats et les critiques qu'on peut leur faire est consigné. [...] C'est sans doute un travail à mettre en regard de l'issue de renumérotation qui doit être actuellement ouverte, c'est la deuxième face du même travail, qui vise à améliorer les contenus.

Je veux bien durant ce travail qu'on prenne le temps ensemble de décider des corrections à effectuer, j'ai mon avis sur pas mal de notebooks, mais je préfère que tu fasses ta propre suggestion en premier sur laquelle je réagirai.

Bref, une issue à ouvrir, pas forcément à traiter maintenant.

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/main courant ; 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 :

  • 23 Hashlife dans ICT-Life-SubstratCertifie.ipynb = occurrences dans les cells[*].source ; le JSON brut en porte 36, dont 13 répétitions dans les outputs.
  • 91 J-Lens dans ICT-SAE-JLens-TeteATete.ipynb = famille orthographique J-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é.
  • 3 cocycle dans ICT-15d-CechObstruction.ipynb = occurrences dans les cells[*].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

Face Issue Question
Ordre #7260 (fille de #5081) dans quel ordre le lecteur rencontre-t-il les notebooks ?
Contenu cette issue chaque notebook mérite-t-il la place qu'il occupe ?

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 que hashlife_correct garantit 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 :

Colonne Contenu
Intention ce que le cadrage (ICT-0-Framing.md, #4588, l'issue mère) dit que ce notebook doit faire
Contenu réel sections, objets manipulés, mesures effectuées — lu, pas résumé depuis le titre
Résultat ce que la sortie montre réellement : positif / nul / négatif, avec le chiffre
Critique l'écart intention↔réalisation, nommé
Verdict + action SOLIDE · À MUSCLER (idée juste, protocole naïf) · DÉGÉNÉRÉ (la réalisation trahit le cadre) · À FUSIONNER · À COMPLÉTER (ensemble incomplet) · À RENUMÉROTER

Note d'hygiène, écrite ici pour qu'on ne me la reproche pas plus tard. .claude/rules/audit-cross-source-distillation.md interdit 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 de docs/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. cocycle apparaît 3 fois, nerf/nerve 0 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-31 et dans ICT-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 Lean hashlife_correct. La bonne matière existe — elle est dans le fichier sans numéro. Suggestion : ICT-31 n'est pas à étoffer, il est à refondre autour du recollement (§3.1), et ICT-Life à numéroter. Voir #5726, qui porte déjà ce gate.

3.3 Le bloc 18/19 — myopie mesurable

cellules code md
ICT-18-ArrowOfTimeReversibilization 32 14 29 312
ICT-18b-ReversibilityBudget 21 8 9 402
ICT-19-EnjeuBattery 26 11 9 619
ICT-19b-EnjeuBattery-Raffinement 24 9 17 252

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 → §5b

5b arrive physiquement après 5e. 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-24 en 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 — quand ICT-25 en 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ée

15 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

  1. Un notebook = une lecture complète — contenu et sorties, pas le titre ni le résumé. Les verdicts sur sortie se lisent dans les outputs, pas dans la prose qui les commente.
  2. Le cadrage fait référence : 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).
  3. Aucune modification de notebook avant arbitrage user. L'audit produit des verdicts, pas des PRs.
  4. Passe d'arbitrage : je propose, le user réagit, la décision est écrite dans le ledger.
  5. Puis issues filles par correction décidée, et [ICT] Renumérotation série ICT (fille #5081) — placement strand Schmidhuber avant les LLMs #7260 en dernier.

5. Ce que cette issue ne fait pas

6. Acceptance

  • Ledger docs/ledgers/<N>-ict-consolidation.md créé, 53/53 notebooks couverts, cinq colonnes remplies, un verdict et une action nommée par ligne.
  • Chaque verdict DÉGÉNÉRÉ cite l'écart mesuré intention↔réalisation (pas une appréciation).
  • Passe d'arbitrage user tenue, décisions écrites dans le ledger.
  • Une issue fille par correction décidée, avec critère de sortie vérifiable.
  • [ICT] Renumérotation série ICT (fille #5081) — placement strand Schmidhuber avant les LLMs #7260 mis à jour avec la table de verdicts, et exécuté après les corrections de contenu.

Part of #4588. See #7260, #5081, #5726, #5635, #5105, #8236, #11411, #7424.

Activity

  1. added
    auditAutomated quality audit findings
    EPICEpic tracking issue with sub-issues
    on Aug 19, 2026
  2. jsboige commented on Aug 20, 2026

    @jsboige
    Owner

    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) :

    1. 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.
    2. 18/18b/19/19b : reconstruire la sequence reversibilite -> budget -> enjeu comme un bloc coherent.
    3. SAE -> J-Lens -> Workspace : refaire l'onboarding, numeroter le tete-a-tete.
    4. 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.
    5. 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.
    6. 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. »

  3. jsboige commented on Aug 21, 2026

    @jsboige
    Owner

    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 canonique notebook × 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.md du 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 outputs avec 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 promet W_t alors que la matrice ne montre qu'un proxy s est 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)

  4. myia-ai-01 commented on Aug 21, 2026

    @myia-ai-01
    CollaboratorAuthor

    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 cite docs/ict/dissociations-matrix.md au lieu de re-mesurer. Les deux réserves écrites dans le commentaire du 21/08 01:03Z (grade INTERNAL sans 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 (ledger est 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-SubstratCertifie Seul 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.py rend CLEAR sur cette issue à l'instant où j'écris), avec une clause paths: 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

  5. jsboige commented on Aug 21, 2026

    @jsboige
    Owner

    [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.

  6. jsboige commented on Aug 21, 2026

    @jsboige
    Owner

    [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).

  7. added 2 commits that reference this issue on Aug 21, 2026
  8. added a commit that references this issue on Aug 21, 2026
  9. jsboige commented on Aug 24, 2026

    @jsboige
    Owner

    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).

  10. jsboige commented on Aug 24, 2026

    @jsboige
    Owner

    [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.

  11. added a commit that references this issue on Aug 25, 2026
  12. jsboige commented on Aug 30, 2026

    @jsboige
    Owner

    [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.

  13. myia-ai-01 commented on Sep 4, 2026

    @myia-ai-01
    CollaboratorAuthor

    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-IntegratedComplexity 93 KB 24
    ICT-15b-SensitivityCanonicity 63 KB 35
    ICT-15c-MetaProxyObstruction 36 KB 17
    ICT-15d-CechObstruction 91 KB 16
    ICT-15e-Bridge2-RecoverabilityAgency 37 KB 24
    ICT-15f-Bridge1bis-DecoupledFamily 63 KB 20
    ICT-15g-EmpiricalHuangExploitation 41 KB 16
    ICT-15h-Bridge1bis-AsymmetricFamily 75 KB 21
    ICT-15i-Bridge1bis-2DLandscape 139 KB 21
    ICT-15j-NerveDiscriminant 41 KB 20
    ICT-15k-RecollementMacroCells 77 KB 34
    ICT-15l-IndependanceGenerateur 41 KB 22

    Onze accretions. Sur les 83 branches accretees du depot, la profondeur mediane est b (55 branches), et rien ne vit entre f et h. ICT-15 est l'un des trois seuls outliers, avec Lean-16 (→ j) et GameTheory-03 (→ h).

    Ce que les noms rendent evident

    Trois notebooks portent litteralement le meme nom de pont : 15f, 15h, 15i sont tous Bridge1bis-* — 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 : 15c MetaProxy, 15d Cech, 15j Nerve, 15k Recollement. Meme appareil, meme question. Et c'est exactement ce cluster qui a produit #13645 (reference residuelle ICT-15d pointant vers ICT-15j) — la dispersion s'y paie deja en liens casses.

    Partition candidate — de 11 accretions a 5

    Cible Absorbe Sujet
    15b 15b Sensibilite / canonicite (inchange)
    15c 15c + 15d Obstruction : meta-proxy puis Cech
    15d 15j + 15k Nerf discriminant et recollement macro
    15e 15e Bridge2 — recouvrabilite / agentivite (inchange)
    15f 15f + 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 :

    1. 15g (Huang empirique) et 15l (independance du generateur) sont-ils des accretions de 15, ou des resultats qui meritent leur propre numero canonique ?
    2. 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.

  14. 40 remaining items

  15. added 14 commits that reference this issue on Oct 5, 2026
  16. added a commit that references this issue on Oct 7, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    EPICEpic tracking issue with sub-issuesauditAutomated quality audit findings

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions