[github-actions]

Purpose

Long-lived PR refreshed daily by catalog-cron.yml (schedule cron 03:37 UTC) to keep
COURSE_CATALOG.generated.{json,md} + CATALOG-STATUS markers + the curriculum (docs/curriculum/*.md),
the health dashboard (docs/archive/reference/HEALTH_DASHBOARD.md), the project.render list of
_quarto.yml and the translation golden set (translations/translation_golden_set.json) canonical on main.

Maintainer review only — no direct push to main (issue #10136). The bot opens
or updates this PR; merging it refreshes main through the normal PR gate.

What to review

• Catalog totals (notebook_count, per-family counts) drift only if new notebooks landed on main since the last merge.
• README <!-- CATALOG-STATUS:START -->…:END --> markers reflect the freshly-regenerated catalog.
• Curriculum pages under docs/curriculum/ and docs/archive/reference/HEALTH_DASHBOARD.md stay consistent.
• _quarto.yml project.render stays in sync with the notebooks / READMEs / docs/*.md on main.
  There are no counter lines in it any more (ci(quarto,#19895): workflow quarto-render-list-freshness + regen _quarto.yml (purger la dette main) #19901): a total in a generated file either conflicts
  between two concurrent PRs or merges a false value cleanly.
• translations/translation_golden_set.json (FR/EN pair fingerprints, Fix(ci,#22009): le golden set de traduction ne derive plus en silence (gate + regeneration) #22216) only changes when
  pairs landed on main since the last merge; branches never regenerate it.

Close policy

When the catalog stops drifting (the workflow runs ::notice title=Catalog::main catalog already canonical -- no change.),
this PR will be auto-closed by catalog-pr-close.yml to keep the queue clean. Subsequent
drift reopens it under the same branch.

See .claude/rules/catalog-pr-hygiene.md and #2433, #10136.

Grain: MED/refactor -- lane myia-ai-01:CoursIA

[github-actions]

PR gate absent du rollup (advisory, #10928)

PR ouverte par le bot du depot (son login est nomme dans la ligne « Cause mesuree » ci-dessous ; il s'ecrit github-actions[bot] en REST et app/github-actions en GraphQL) sans PR gate dans son rollup : cas structurel (issue #10928). Un push fait avec GITHUB_TOKEN ne cree pas de nouveau workflow run (regle anti-recursion GitHub), donc le contexte requis ne sera jamais rapporte par un push du bot.

• Remede : un push humain sur la branche (commit par un compte personnel), ou un merge admin via gh auth switch -u jsboige.
• close / reopen ne relance rien.

Cause mesuree : auteur github-actions[bot] (bot du depot) -- push GITHUB_TOKEN sans run

[github-actions]

Path-collision (organ #13359/#13615)

Cette PR #24283 (chore(catalog): scheduled auto-regenerate (long-lived PR)) touche au moins un chemin de fichier aussi modifie par d'autres PRs ouvertes. Risque de double-livraison (meme fichier livre deux fois, 2x le travail et 2x les runs CI). Advisory : parfois legitime (tranches coordonnees, partition paths: explicite, PRs empilees exclues) -- l'organe rend visible, il ne bloque pas.

• terminal -- chore(catalog): scheduled auto-regenerate (long-lived PR) #23266 partage : MyIA.AI.Notebooks/GameTheory/README.md, MyIA.AI.Notebooks/GenAI/FineTuning/README.md, MyIA.AI.Notebooks/GenAI/README.md, MyIA.AI.Notebooks/GenAI/Texte/README.md, MyIA.AI.Notebooks/ML/README.md, MyIA.AI.Notebooks/README.md, MyIA.AI.Notebooks/RL/README.md, MyIA.AI.Notebooks/SymbolicAI/Lean/README.md, MyIA.AI.Notebooks/SymbolicAI/README.md, _quarto.yml, docs/archive/reference/HEALTH_DASHBOARD.md, docs/curriculum/genai.md, docs/curriculum/ia-symbolique.md, docs/curriculum/recherche.md, docs/curriculum/trading.md, translations/translation_golden_set.json, recouvrement de chemins 64% -- chore(catalog): scheduled auto-regenerate (long-lived PR) #23266 est deja sur main.
• faible -- feat(lean,#23499): Pli 2 Poincare -- note de conception, temoin de chaine FR/EN et carnet Lean-42 #23506 partage : MyIA.AI.Notebooks/SymbolicAI/Lean/README.md
• faible -- Fix(gametheory,#14944): renumerotation GT-26 -> GT-22 -- colonne canonique refermee #24392 partage : MyIA.AI.Notebooks/GameTheory/README.md, _quarto.yml, docs/curriculum/recherche.md
• faible -- Docs(gametheory,#24183): T3 -- la carte des lakes dit pourquoi chacun est separe, et couvre les huit lean_lib du package #24412 partage : MyIA.AI.Notebooks/GameTheory/README.md
• faible -- Add(ict,#20298): palier 15 T1 -- sous-série ICT-20-FeatureCatastrophes (substrat, 6 carnets) #24481 partage : _quarto.yml, docs/curriculum/recherche.md
• faible -- Docs(gametheory,#3973): GameTheory -- ligne 01b SocialChoice en lien court + releve de conformite #24487 partage : MyIA.AI.Notebooks/GameTheory/README.md
• faible -- Fix(lean,#17545): T4 -- promotion Lean-16 et rattachement du libre arbitre a l'arc 13e #24626 partage : MyIA.AI.Notebooks/README.md, MyIA.AI.Notebooks/SymbolicAI/Lean/README.md, _quarto.yml, docs/curriculum/ia-symbolique.md
• faible -- Rename(decinfer,#12933): re-flow voie (a) -- compagnons en accretions, compteur aligne sur DecPyMC #24778 partage : MyIA.AI.Notebooks/README.md, _quarto.yml, docs/curriculum/recherche.md, docs/curriculum/trading.md
• faible -- Refactor(gametheory,#14944): renumerotation 26 -> 22 du carnet Shapley, fermeture du trou 22-25 #24809 partage : MyIA.AI.Notebooks/GameTheory/README.md

Le verdict terminal (#15578) signale qu'un cote de la paire est deja sur main. L'organe mesure un recouvrement de chemins ; il ne compare pas le contenu des deux livraisons, donc il ne conclut PAS a une redondance (#15768) : deux PRs peuvent toucher le meme fichier pour des raisons disjointes. L'arbitrage reste a la lane ou au coordinateur.

[clusterManager-Myia]

[Hermes] Revue — véhicule permanent du catalogue, head bbfcef2f

Je ne traite pas cette PR comme une PR de lane : c'est le véhicule catalog-cron (chore/catalog-refresh-pending), auquel catalog-pr-hygiene.md (règle HARD 1) donne le monopole du regen. Je juge donc le contenu produit et l'instrument qui le produit.

Méthode : les deux blobs parsés en entier par API (api_size == octets écrits : 2 911 004 et 2 909 439), 1609 entrées comparées champ par champ, pas le diff texte (1831/−1831 lignes sur COURSE_CATALOG.generated.json, +2 sur _quarto.yml, +2/−2 sur le golden set).

Ce qui est juste, et je l'ai vérifié

• _quarto.yml (règle HARD 5) : +2 entrées nommées, docs/reference/lean-lakes-doctrine.md et lean-theorem-duplicates.md. Les deux fichiers existent à main et au head (blobs 84b34f7018 / 9a5f08550b identiques aux deux refs) — pas d'entrée fantôme. Conforme.
• translation_golden_set.json : les empreintes FT-02-QLoRA passent à 862aa8c5… / 5f2f0a00…. J'ai recalculé le sha1 des octets des deux blobs : exactement ces valeurs, à la base comme au head — le fichier de traduction n'a pas bougé, seule l'empreinte est ré-ancrée. Comportement attendu.
• Champs curés préservés : owner_logique, last_validator, editorial, maturity, status → 0 changement sur 1609 entrées. Le _merge_curated_fields de #2433 tient.
• CI du head : 24 checks, 0 rouge (3 skipped = Gitleaks-fork, Pages, Build Quarto — du déploiement, pas du gate).
• Les 43 vraies mises à jour de last_success_sha sont fondées : recoupées par commits/{sha} — p. ex. 2619463ab7da050dcc366048c272c023316d8764 (« Fix(notebooks,#3436): retirer 49 chemins machine », 26 fichiers) touche bien les carnets concernés, et executed_at suit.

🟠 1. last_success_sha change de largeur sur 1540 entrées sans qu'aucun commit ne change

C'est le corps du diff, et ce n'est pas un fait de catalogue. Sur les 1583 entrées dont le champ bouge :

base : "last_success_sha": "64ec3baa9c"  (10 hex)  -> 1583/1583
head : "last_success_sha": "64ec3baa9"   ( 9 hex)  -> 1583/1583

Sur ces 1583, 1540 sont de purs préfixes : la valeur de tête est la valeur de base tronquée d'un caractère, même commit. Ces 1540 lignes ne portent aucune information — elles disent seulement que l'abrégé a changé de largeur entre deux générations.

Mesures, et ce que j'ai écarté. Historique du champ dans le fichier généré :

f0cbcdbd7  {9: 1481}
44ae7ef76  {10: 1523, 9: 1}
3bb25b376  {10: 1583, 9: 1}   <- base de cette PR
head       {9: 1584}

Donc la largeur a déjà valu 9, puis 10, et revient à 9 — elle n'est pas constante dans le temps. Et elle coexiste dans un même fichier (une entrée à 9 au milieu de 1583 à 10), ce qui exclut l'hypothèse d'une variable d'environnement unique par run : il y a au moins deux chemins d'écriture pour ce champ (regen vs champ préservé par _merge_curated_fields).

Le mécanisme, lui, est lisible dans le code : le champ vient de git log -1 --format=%h (forensic_scan.get_last_commit_sha), et il est confronté à git rev-parse --short HEAD (generate_catalog.get_head_sha). Ces deux commandes calculent chacune un abrégé dont la largeur dépend de la config et du dépôt, pas d'une constante — le docstring de get_last_commit_sha promet d'ailleurs « 7 chars hex » alors que le JSON en porte 10 puis 9. Tant que la largeur n'est pas épinglée, deux générations successives peuvent produire des largeurs différentes pour le même commit.

Conséquences, par ordre de gravité :

• classify_reproducibility() (generate_catalog.py ~l.1098) promeut en REPRODUCED ssi last_success_sha == head_sha. Cette égalité de chaînes compare deux résolutions indépendantes ; si elles ne rendent pas la même largeur pour le même commit, une entrée réellement attestée perd son statut. Dans ce diff, SW-14-Python-Coup-Ontologique.ipynb passe REPRODUCED → EXECUTED sur le même commit 1a4df1971 (son sha perd un caractère). Ici je ne le compte pas comme préjudice : main avait 94 commits d'avance, l'entrée ne pouvait plus être REPRODUCED de toute façon — mais la classe de défaut est réelle et silencieuse.
• Format non versionné pour tout consommateur qui joint sur ce champ : un diff de deux catalogues est bruité par construction, ce qui est exactement le « churn catalogue » que la règle HARD 1 veut éteindre.

Remède, deux lignes, des deux côtés de la comparaison (forensic_scan.get_last_commit_sha et generate_catalog.get_head_sha) : épingler la largeur (git rev-parse --short=7 / --format=%h --no-abbrev-commit + troncature explicite), pour que les deux valeurs soient comparables et que le champ ne dépende plus ni de la config du runner ni de la taille du dépôt. Même classe que la garde plateforme-dépendante de #4505 : une sortie qui suit l'environnement au lieu d'être normalisée.

🟡 2. Les 43 vraies mises à jour sont noyées dans 1540 lignes de bruit

Elles sont justes (recoupées une par une), mais indiscernables dans le diff : personne ne peut relire COURSE_CATALOG.generated.json pour distinguer « GameTheory-04g a réellement été ré-exécuté » de « l'abrégé a changé de largeur ». revisions bouge aussi sur 44 entrées, sans mention au corps. Corriger le point 1 rendrait ces 43 lignes visibles au lieu de les noyer.

Verdict

COMMENT. Je n'oppose pas de CHANGES_REQUESTED à un véhicule d'automatisation dont le corps est conforme à catalog-pr-hygiene.md et dont la CI est verte 24/24 : les 43 vraies mises à jour sont correctes et les champs curés sont préservés. Mais le point 1 est un défaut d'instrument réel, et il ne se corrige pas en re-générant — chaque cron rejouera une largeur potentiellement différente.

Suggestion : merger ce véhicule si la file l'exige, et ouvrir l'issue de l'abrégé avant le prochain cycle (03:37 UTC), sinon la prochaine PR permanente rejouera ~1500 lignes de bruit.

Je ne merge pas et ne le demande pas — arbitrage maintainer.

Revu au head bbfcef2ff19910bbf7bac5fc046b1c40f1f1e458 (mesuré par --jq '.head.sha' juste avant le POST).

[github-actions]

New commit pushed on chore/catalog-refresh-pending by catalog-cron (run 41626107323).
Last commit SHA: 802a40a909c9.
Catalog drift detected; the bot has nothing else to do here. Maintainer: please review + merge when convenient.

[clusterManager-Myia]

[Hermes] Revue incrémentale — véhicule catalog-cron, head 1b7e6289 (précédente : COMMENT @ bbfcef2f, 03/11 06:04Z). Je ne rejoue pas la revue précédente : je mesure ce que cette génération change, et si le défaut d'instrument que j'avais signalé a mordu.

Ce que cette génération apporte, et que je n'avais pas vu

Le catalogue de main est périmé de 27 chemins ; celui du head est exact. C'est le fait neuf, et il change la nature de la PR : ce n'est pas un simple rafraîchissement, c'est le resync après une vague de déplacements que main n'a pas encore absorbée.

Mesuré par confrontation du JSON aux arbres git/trees/<sha>?recursive=1 :

catalogue HEAD  vs arbre HEAD : 0 chemin ajouté absent de l'arbre, 0 retiré encore présent
catalogue MAIN  vs arbre MAIN : 27 chemins référencés ABSENTS de l'arbre

Les 27 : DecPyMC-1..7 → DecPyMC-01..07 (renumérotation), GenAI/Audio/04-Applications/*.ipynb → sous-dossiers 04-Audiobook/, 04-Musique/, 04-Voix/, Marches/Marches-01… → Applications/Marches-01…, Regles-De-Decision/… → DecisionTheory/…. 24 ajouts / 23 retraits, chaque retrait apparié à un ajout. Le head répare, il ne casse pas.

Mesures de fidélité

Blobs extraits par git/blobs avec assert len(data) == size (le JSON fait ~2,9 Mo, contents rend vide au-delà de 1 Mo) : 1610 entrées au head, 1609 à main, 1586 chemins communs.

• Marqueurs README ↔ JSON — cohérence 21/21. CATALOG-STATUS : total 1610 = len(catalog) ✓ ; breakdown 16/16 séries exact (SymbolicAI 402, GenAI 305, Search 165, GameTheory 141, ML 137, QuantConnect 123, IIT 111, Probas 92, Sudoku 39, RL 38, Complexity 22, NLP 11, Compression 8, Physique 8, CaseStudies 6, cross-series 2) ✓ ; maturity 4/4 exact (BETA 1407, DRAFT 116, ALPHA 83, TEMPLATE 4) ✓.
• last_success_sha : 118 changements, dont 0 par effet de largeur. Pour chacun des 118, executed_at avance et le sha diffère autrement que par un préfixe (hi.startswith(lo) = 0 cas) ⇒ ce sont de vraies ré-exécutions, pas le churn d'abrégé que je redoutais. L'unique entrée à 9 caractères (GenAI/SemanticKernel/Créateur de mail personnalisé.ipynb, 66caab58b) est identique à main : préexistante, pas introduite ici.
• Transitions reproducibility : 3, toutes mécaniquement justes. SW-14 REPRODUCED→EXECUTED sur le même last_success_sha (1a4df1971e) — l'entrée perd son statut parce que main a avancé, exactement le comportement décrit dans ma revue précédente ; Tweety-09-Preferences-{Python,CSharp} EXECUTED→REPRODUCED sur des sha frais (802a40a909, exec 03/11 12:12Z) qui sont bien de nouvelles exécutions.
• Champs curés : owner_logique 0 changement, status 0, pedagogical_role 0. maturity (4) et editorial (2) bougent — cohérent avec le code : ils ne sont pas dans CURATED_GIT_FIELDS (qui vaut last_validation, last_validator, issue_pr_associee, last_success_sha, executed_at, forensic_category, scientific_reviewed_by, head_sha), donc recomputés. Les 4 transitions maturity tombent toutes sur des carnets dont executed_at a bougé (ML-05 11-01→11-02, Tweety-09 10-31→11-03, RLPT-00d même jour). Rien d'arbitraire.
• _quarto.yml : 6 entrées ajoutées, les 6 cibles existent au head (backtester-e2-cadrage.md, lean-lakes-doctrine.md, lean-theorem-duplicates.md, niveau-serie.md, GameTheory-04k-Equilibre-Correle-Python.ipynb, ReglesDeDecision-01-EDT-CDT-CCDT-UDT.ipynb). 0 entrée fantôme.

🔴 Le point 1 de ma revue précédente n'est PAS corrigé — et il n'a pas mordu cette fois

Vérifié dans les sources aux deux refs (main et 1b7e6289), byte-identique :

# forensic_scan.get_last_commit_sha   (docstring promet « 7 chars hex »)
["git","-C",repo,"log","-1","--format=%h","--",rel]
# generate_catalog.get_head_sha
["git","rev-parse","--short","HEAD"]

Les deux calculent un abrégé dont la largeur dépend de la config et de la taille du dépôt, et classify_reproducibility() compare ensuite ces deux chaînes. Le défaut est donc intact. Il ne s'est pas manifesté dans ce diff — je le mesure, je ne l'infère pas — mais il n'est pas fermé, et chaque cron le rejouera.

Je maintiens la recommandation : épingler la largeur des deux côtés (--short=7 / %h + troncature explicite) avant le prochain cycle. Ce n'est pas un reproche sur cette génération, c'est le même défaut d'instrument, non traité.

🟡 La justification du gain n'est pas dans le corps

Le corps de cette PR est le gabarit automatique du cron : il ne dit pas que le catalogue de main porte 27 chemins périmés, ni que 118 entrées ont été ré-exécutées, ni que 3 statuts de reproductibilité ont bougé. Ces faits sont dans l'artefact, pas dans le message. Sur un véhicule permanent dont la règle HARD 1 veut éteindre le churn, un corps qui n'énonce pas « ce run répare N chemins et ré-exécute M carnets » laisse le relecteur comparer 1626 lignes à la main. C'est exactement le reproche 2 de ma revue précédente, non résolu.

Verdict

COMMENT. Je n'oppose pas de CHANGES_REQUESTED : le contenu produit est exact sur tous les points que j'ai su mesurer (21 marqueurs, 118 sha, 3 transitions, 6 entrées quarto, 0 chemin fantôme), la CI du head est 26 success / 1 neutral / 3 skipped / 0 failure, et le head répare un état de main périmé. Mes deux réserves portent sur l'instrument (%h) et sur le corps, pas sur les données.

Suggestion : merger ce véhicule — il corrige main — et ouvrir l'issue de l'abrégé, sinon la prochaine génération rejouera le risque.

Revu au head 1b7e628919ef29df6de311fc7749275ba8e752ba (mesuré par --jq '.head.sha' juste avant le POST).

[github-actions]

New commit pushed on chore/catalog-refresh-pending by catalog-cron (run 41821199707).
Last commit SHA: 46103000be9f.
Catalog drift detected; the bot has nothing else to do here. Maintainer: please review + merge when convenient.

[github-actions]

New commit pushed on chore/catalog-refresh-pending by catalog-cron (run 42018890376).
Last commit SHA: 380ca1e21dcd.
Catalog drift detected; the bot has nothing else to do here. Maintainer: please review + merge when convenient.