Repository navigation
Catalogue : 100 % de scientific_review jamais ecrit, 7,3 % de chemins fantomes, et l'organe de #17066 absent du depot #17217
Description
Activity
[CLAIMED] lane myia-ai-01:CoursIA -- paths: scripts/ci/check_catalog_freshness.py, scripts/tests/test_check_catalog_freshness.py, .github/workflows/catalog-cron.yml -- organe de fraicheur du catalogue + deblocage de la livraison quotidienne (point 3 de l'issue)
Correction — «
scientific_reviewn'a jamais été écrit » est fauxL'énoncé de l'issue présente
scientific_review = 100 % UNREVIEWEDcomme un trou de conception : colonne déclarée, jamais alimentée. C'est inexact, et l'inexactitude oriente vers le mauvais remède — j'y proposais de « décider si l'axe est alimenté ou retiré du schéma », alors qu'il n'y a rien à décider sur ce point.Le mécanisme est construit et fonctionnel :
generate_catalog.py:classify_scientific_review()(l. 846) et_load_scientific_review_registry()(l. 1055) ;- la whitelist
docs/notebook-metadata/scientific-review-registry.mdporte trois entrées pilotes, reviewer et PR de preuve à l'appui ; - il n'y a délibérément pas d'auto-promotion par l'auteur du dernier commit — la promotion exige un signal curé. C'est un choix, pas une omission.
Ce que la mesure montre :
Catalogue Entrées scientific_reviewmain(dc0ccbf)1137 1137 UNREVIEWEDchore/catalog-refresh-pending1240 1237 UNREVIEWED, 3AUTHOR_REVIEWEDSudoku/Sudoku-11-Choco-Csharp.ipynb AUTHOR_REVIEWED Sudoku/Sudoku-12-Z3-Csharp.ipynb AUTHOR_REVIEWED Sudoku/Sudoku-18-Comparison-Python.ipynb AUTHOR_REVIEWEDLes trois pilotes sont écrits. Ils sont invisibles sur
mainpour la seule raison que le catalogue demaindate du 09-12 : le cron régénère bien chaque jour, mais livre par la PR #15942, bloquée depuis 8 jours. C'est le même défaut de livraison que le point 3 — pas un second défaut.J'ai lu une colonne constante et conclu à une colonne morte. Le bon geste aurait été de comparer au catalogue fraîchement généré avant d'écrire, ce que je n'avais pas fait. Le zéro venait de la péremption, pas du mécanisme.
Ce qui est demandé — révisé
- Merger l'organe de Redressement critique des 218 notebooks a sections dupliquees -- lecture de bout en bout, consolidation, pas suppression mecanique #17066 (PR feat(notebook_tools,#17066): organe des sections dupliquees par accretion (80 porteurs, 274 sections en trop) #17218) — inchangé.
Décider siSans objet. L'axe est alimenté et le restera. Ce qui reste ouvert est plus étroit, et c'est déjà tracé en catalogue : PRODUCTION est inatteignable par construction — l'axe scientific_review n'a aucun ecrivain (0/1111), et 3 notebooks FINAL+EXECUTED le prouvent #14831 : voie 2 (scientific_reviewest alimenté ou retiré du schéma.aggregate_maturityaccepteAUTHOR_REVIEWED) vs voie 3 (sorry_freepromeut enFORMALLY_VERIFIED). C'est le seul point qui demande un arbitrage.- Câbler la fraîcheur — PR fix(ci,#17217): organe de fraicheur du catalogue + deblocage de la livraison quotidienne #17221 : l'organe
check_catalog_freshness.py, le diagnostic catalog-refresh-pending : le push bot ne declenche aucun check requis (5 CodeQL verts + BLOCKED) — regle et workflow a reconcilier #11202 corrigé par la mesure qui le réfute, et l'approbation automatique des runs garés qui débloquait la livraison. Les 16 runs garés du head courant ont été approuvés à la main : au même head, plus aucunaction_required.
Une fois #15942 mergée, les 83 fantômes, les 301 absents et les 3
AUTHOR_REVIEWEDse règlent du même geste.🤖 Generated with Claude Code
[CLAIMED-AMEND] lane myia-ai-01:CoursIA -- paths: scripts/ci/check_catalog_freshness.py, scripts/tests/test_check_catalog_freshness.py, .github/workflows/catalog-cron.yml, scripts/notebook_tools/generate_catalog.py, scripts/notebook_tools/tests/test_resource_cost.py, scripts/notebook_tools/tests/test_generate_catalog.py -- ajout du champ resource_cost (creation + execution) en plus de l'organe de fraicheur
Fermeture — urne
delivered, vérifiée surorigin/mainpar ai-01 (05/10)Les trois points sont réglés sur main. L'organe des sections dupliquées est livré par #17068 (
scripts/notebook_tools/check_duplicate_sections.py; #17218 a été fermée parce qu'elle était supersédée). La fraîcheur du catalogue est câblée par #17221 et #17634 (scripts/ci/check_catalog_freshness.py, ses tests, etcatalog-cron.yml, dont les runs passent ensuccesschaque jour jusqu'au 04/10). Le catalogue courant compte 1354 entrées, aucun chemin fantôme, etresource_costsur 1354/1354 (#17226). Le sort descientific_reviewa été arbitré le 21/09 (« sans objet »), et le reste étroit, tracé en #14831, est fermé par #17240.
Le constat
Le catalogue généré porte quatre axes de qualité par notebook —
maturity,editorial,reproducibility,scientific_review— plusforensic_category. Mesure du 2026-09-21 surCOURSE_CATALOG.generated.json(1137 entrées) :scientific_reviewUNREVIEWEDeditorialBETAmaturityBETAreproducibilityEXECUTEDstatusREADYforensic_categoryA_ALL_EXEC_OKscientific_reviewn'a jamais été écrit : la colonne existe, elle porte sa valeur par défaut sur l'intégralité du corpus. Les trois autres axes déclaratifs sont mono-valués à ~90 %. Un champ qui prend une seule valeur ne discrimine rien pour le lecteur qui choisit un notebook.Pourquoi les axes verts ne contredisent pas les campagnes de réparation
Les deux axes qui sont réellement mesurés —
reproducibilityetforensic_category— ne mesurent que l'exécution. C'est précisément la classe de défaut que le dépôt a déjà résolue, et elle est orthogonale à celles qu'il répare en ce moment.Contrôle positif.
DecPyMC-9-Prime-Pure-Chargement.ipynba été mergé aujourd'hui (28a003f) pour retirer 11 titres d'interprétation identiques. Son entrée au catalogue :Tous les axes verts, sur un notebook qui nécessitait une PR de réparation le jour même. Ce n'est pas une erreur du catalogue : c'est sa portée. Un titre dupliqué ne casse aucun
execution_count.L'organe manquant
Le chiffre qui pilote #17066 — 218 notebooks porteurs, 726 sections en trop — a été produit par un script qui n'est pas dans le dépôt :
Conséquence : le nombre n'est pas re-mesurable, le défaut ne peut pas être gardé en CI, et la convergence de la campagne est invisible. Un outil qui n'entre pas dans le dépôt est perdu à la session suivante — ici, à l'échelle d'une campagne de 218 notebooks.
La PR jointe dépose cet organe (
scripts/notebook_tools/check_duplicate_sections.py), avec un discriminant hiérarchique : un titre répété sous des parents différents est un gabarit légitime (chaque exercice a son « Objectif ») ; répété sous le même parent, c'est une accrétion.Mesure sur
main(dc0ccbf), 1351 notebooks, 0 illisible :Les 194 notebooks écartés sont des gabarits par exercice. Répartition des 80 : GenAI 17, SymbolicAI 15, GameTheory 11, QuantConnect 10, Sudoku 7, Search 6, Probas 5, RL 4, ML 3, IIT 2.
Contrôle positif retenu :
QC-Py-08-Multi-Asset-Strategies.ipynb, huit sous-sections numérotées en double sous le même parent (1.2 Ajouter Multiple Asset Classes,2.2 Rolling Correlations,3.2 Risk Parity, …). Une numérotation répétée n'est jamais un gabarit.Deux défauts d'intégrité du catalogue, mesurés au passage
Probas/DecisionTheory/PyMC/DecPyMC-9-…(le répertoire réel estDecPyMC/),IIT/ICT-Series/ICT-1-PhiTrajectories.ipynb,GameTheory/GameTheory-03f-Parcours-Complet.ipynb.Le fichier est daté du 2026-09-12 ; le corpus a bougé depuis, et rien ne signale la péremption.
Ce qui est demandé
--prqui empêche une PR d'en ajouter.scientific_review. Deux issues cohérentes, une seule à choisir : soit l'axe est alimenté (et il devient le marqueur de niveau épistémique que le corpus n'a pas — illustration / expérimentation / validation statistique / solveur / preuve formelle), soit il est retiré du schéma. Une colonne constante qui a l'air d'un verdict est pire que pas de colonne.Le point 2 est le seul qui demande un arbitrage : les points 1 et 3 sont mécaniques.
Note de coordination — claims epic-wide accidentelles sur #17066
En vérifiant les claims avant d'écrire,
check_lane_claim.pyrendblocked: Trueavecintersection_summary: "0 fichiers bloques / 0 libres"etopen_pr_collisions: []. Cause : plusieurs marqueurs demyia-po-2025:CoursIAsur #17066 écrivent leur clausepaths:sur une ligne séparée du marqueur, donc elle n'est pas lue (#12072) et la claim retombe en epic-wide, fail-closed — elle bloque toute la campagne au lieu du seul notebook visé.Forme attendue, sur la ligne du marqueur :
Notebooks concernés par ces déclarations mortes :
QC-Py-21,QC-Py-20,QC-Py-08,QC-Py-13,DecPyMC-11.🤖 Generated with Claude Code