Repository navigation
Conversation
|
Scope = notebooks CHANGED in this PR, not the whole corpus. Explicit |
|
✅ No unanchored measurement claim detected in the notebooks this PR changed. Scope = notebooks CHANGED in this PR, not the whole corpus. The |
|
✅ No factual mislabel detected in the notebooks this PR changed (entity counts and tuple formulas checked against nearby committed streams). Scope = notebooks CHANGED in this PR, not the whole corpus. The |
Trois liens pointaient l'ancien nom du carnet natif : la cellule de table du
jumeau Python ("meme sujet que son pendant natif"), la ligne de table du carnet
natif (libelle + lien _en), et la marche franchissable ("companion natif").
Depend du renommage #22932 : a merger APRES lui.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
|
No organ-duplication: no added def/class collides with another series organ API (scripts/audit/organ_api_index.yaml). Detector: |
Golden-Set Execution (H.7 P3)✅ 9/9 notebooks passed (certified reproducible)
Pinned lockfile: |
clusterManager-Myia
left a comment
clusterManager-Myia
left a comment
There was a problem hiding this comment.
[NanoClaw]
VERDICT: CONCERNS (le rename est bien byte-identique ; mais 5 gardes sont rouges au head, et la justification « le cron régénère après merge » ne tient pas)
Revue structurelle — aucun corps de patch n'a été fetché : taille via pulls/22932 (+0/−0, 2 fichiers), liste via --jq '.[].filename', puis les blobs base et head récupérés par l'API contents et comparés localement. Pas de gh pr diff, pas de /files avec patches.
Ce que j'ai vérifié moi-même (et qui confirme le body)
- Le rename est byte-identique.
ANALYSE-06-Sensibilite-2026-Lean.ipynben base etANALYSE-06b-Sensibilite-2026-Lean.ipynben head rendent le même blob :9c7f0ca4dc563ffe5bd2315074b48d9cf5f36b2f, 98 608 octets. Le jumeau_en:00d2be7c70d8f03d1b01f22a34604db78cd26e0b, 98 123 octets, des deux côtés. Aucun octet de contenu n'a bougé — la promesse du body est exacte. - Le diff publié (+0/−0, 2 fichiers) est cohérent avec un
git mvpur. sensitivity_lean/Check.lean:8vise bien le jumeau Python, qui garde son numéro : aucune modification due là — vérifié.
Ce qui ne va pas, au head 1efd9bcd
- 🔴 5 gardes sont rouges, et elles ne le sont pas par hasard.
Audit README -> .ipynb links: deltabase=0 head=2, 2 nouvelles entrées cassées, exactement les deux liens deMyIA.AI.Notebooks/SymbolicAI/Lean/ANALYSE/README.md:17qui pointent encore l'ancien nom.check-navlinks: 2 nouveaux navlinks cassés, les liens croisés intra-paire dansANALYSE-06b-…Lean.ipynbcellule 0 ligne 15 (et le jumeau_en).check-nav-chain: 5 nouveaux findings imputables au diff, dont[independent_chain] …/SymbolicAI/Lean/ANALYSE.Pedagogy density baseline orphan guard:LOST_KEY×2 sur les anciens chemins plusUNKEYED_FILE×2 sur les neufs — le garde connaît le mapping (old -> new) et sort quand même en code 1.Always-on guardsagrège et nomme deux organes en échec :fastlaneetpair_count_declared.PR gateestcancelled— c'est un artefact de minuteur DWELL, je ne le lis pas comme un verdict organique, mais il ne compte pas non plus comme un feu vert. - 🔴 La justification « les fichiers générés sont laissés tels quels, le cron les régénère après le merge » ne tient pas.
quarto-pages-deploy.ymlexécute bienregen_quarto_render.py(lignes 177 et 325), mais aucune étape de la chaîne ne commite ni ne pousse : pas degit commit, pas degit push, pas decreate-pull-request. La régénération ne vit que dans le workspace éphémère du runner. Rien ne réécritmainaprès le merge. Conséquence concrète :_quarto.yml(198 271 o) garde les entrées de rendu de l'ancien chemin aux lignes 2131-2134, et le catalogue généré aussi. Le trou est masqué par un garde qui devrait l'attraper :_quarto.yml render list freshness (advisory)rend success avec deux entrées pendantes — c'est un trou du garde sur les renames, pas une preuve que la liste est propre. - 🟡 Un registre vivant, indexé par chemin, est absent de la liste des fichiers générés du body :
translations/translation_golden_set.json(157 104 o) porte encore"fr": …/ANALYSE-06-Sensibilite-2026-Lean.ipynbet"en": …_en.ipynbaux lignes 1760-1761. Ce n'est pas un artefact régénéré : c'est une source de vérité de la chaîne de traduction, et elle pointe maintenant un fichier qui n'existe plus. Même famille pourscripts/notebook_tools/pedagogy_density_baseline.json(lignes 1130-1131), qui explique à lui seul leLOST_KEYci-dessus. - 🟡 Des références en prose désignent désormais un autre objet.
sensitivity_lean/Sensitivity/Separations.lean:26etSeparations_en.lean:25écrivent «ANALYSE-06-Sensibilite-2026construit les variantes globales » — sans le suffixe-Lean. Après ce rename,ANALYSE-06-Sensibilite-2026(nu) désigne une famille qui contient maintenant…-Pythonet…06b-…Lean: la phrase reste vraie mais devient ambiguë.Check.lean:5(« carnet ANALYSE-06 ») a le même flou. Ce n'est pas bloquant, c'est du texte Lean qui devra être relu au prochain passage sur ce dossier. - Pour être précis sur un point que le body traite correctement : le
[link_404]signalé parcheck-nav-chaindepuisANALYSE-04-PFR-Primitives-Python.ipynbest explicitement hors-diff et préexistant dans le log du garde. Je ne l'attribue pas à cette PR.
Ce que je propose
Deux options, la première est la moins coûteuse. Soit cette PR embarque les quatre corrections mécaniques qui la rendent verte (les 2 liens du README ANALYSE/, les 2 liens croisés en cellule 0 des deux carnets renommés, les clés de pedagogy_density_baseline.json, les deux entrées de translation_golden_set.json), soit elle est explicitement requalifiée « rename seul, la verdure vient d'une PR suivante » — et dans ce cas le body doit cesser d'imputer la régénération au cron, qui ne commite rien. Le merge order annoncé (celle-ci, puis #22670, puis l'étape d) reste valable dans les deux cas ; ce qui change, c'est qui porte les liens.
Rien de tout cela ne met en cause l'intention : un git mv propre, annoncé comme tel, sur un carnet dont le contenu est intégralement préservé. Ce sont les registres qui n'ont pas suivi.
Non vérifié : l'exécution réelle des workflows (revue statique depuis mon siège) ; le contenu des deux carnets au-delà de l'identité de blob — je n'ai pas relu les cellules, précisément parce que rien n'a changé d'un octet ; l'état des autres PR de la pile (#22670 et l'étape d), hors périmètre de ce passage.
État au head 1efd9bcd3b481a8303444d01b83eb01e12e64e97 : 2 fichiers, +0/−0, mergeable, opener jsboige, 0 review avant celle-ci, 5 commentaires d'issue tous github-actions[bot].
Path-collision (organ #13359/#13615)Cette PR #22932 (
|
github-actions
Bot
added
the
pr-overlap
…#22932 Option 1 de la review : les corrections mecaniques embarquent dans la PR. README ANALYSE (2 liens + labels), liens croises intra-paire cellule 0 des deux carnets (cibles seules), pedagogy_density_baseline.json (2 cles), translation_golden_set.json (fr/en), _quarto.yml render list (2 entrees -- sinon le build Quarto de main casse au merge), docs/curriculum (2 liens, meme famille). COURSE_CATALOG.generated.* intouchable (regle catalogue, regenere par l'automatisation). 11+/11-, aucune cellule code touchee. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
|
Translation guard violation (#10332). translation-guard violation: no override label 'translation-override' and no comment marker '[TRANSLATION-OVERRIDE] '. NOTE (#15198): translation-sync is on manual-maintainer hold since 2026-08-12 (#10038) -- editing the FR source does not refresh the derived file until the hold is lifted; while it stands, the dual-key override (#10332) is the expected exit for a legitimate change. Three exits to clear this gate:
See #10332 for the override protocol. |
… 04, intro du jumeau EN metadata.papermill du 04 reduit au basename par le hook auto (chemins absolus herites de la machine d'execution) ; paths des deux 06b laisses tels quels (basenames, trace du nom a l'execution). Zero reference fonctionnelle restante hors catalogue genere. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Notebook outputs-required (H.4 schema): PASS (every code cell carries an
|
|
Translation guard violation (#10332). translation-guard violation: no override label 'translation-override' and no comment marker '[TRANSLATION-OVERRIDE] '. NOTE (#15198): translation-sync is on manual-maintainer hold since 2026-08-12 (#10038) -- editing the FR source does not refresh the derived file until the hold is lifted; while it stands, the dual-key override (#10332) is the expected exit for a legitimate change. Three exits to clear this gate:
See #10332 for the override protocol. |
…ron catalogue Quarto render list, golden set de traduction et page parcours ia-symbolique sont regeneres et commites par catalog-cron.yml vers chore/catalog-refresh-pending (arbitrage #19901, docstring build_golden_set.py post-#22216 : une branche de contenu ne les regenere pas). La PR ne porte que les registres bloquants : README, liens croises cellule 0, cles pedagogy_density_baseline. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
|
Réponse à la review NanoClaw — les deux points, par reserve. Reserve 1 — les gardes au head
Le recablage complet de la chaine (tables de navigation des carnets voisins) reste l'etape d (#22933, empilee). Reserve 2 — la justification cron. La premisse « aucune etape de la chaine ne commite ni ne pousse » est incomplete : Le body initial etait faux dans sa forme — il est reecrit avec le mecanisme cite a la source. Consequence assumee et documentee : Les deux points jaunes : le CSV de traductions (26 lignes, memoire d'extraction) est declare en residu dans le body, aucune garde ne le lit au head ; la prose Lean ambigue ( La levee des reserves reste a myia-ai-01. |
|
Diagnostic de l'échec Reproduction firsthand du guard sur cette branche (
Pourquoi aucune valeur honnête ne satisfait pas le guard ici. Le verdict exige Cause dans le code ( Action lane : le fix du guard part en PR séparée (jamais dans la PR que l'organe bloque) — renommer |
|
Le fix du défaut diagnostiqué en c.6445658213 est livré en PR séparée : #22975 ( |
Notebook PR Validation: PASS
Checks: H.1 (no errors), H.3 (execution_count), C.1 (no banned patterns) |
…e ne derive pas le compte (#22975) Un rename FR+EN renomme ensemble (statut R des deux cotes) laisse le compte de paires inchange, mais le guard l'exigeait un bump: 18->18 n'est pas une modification (rouge pour absence de bump), 18->N ecrit un compte faux qui casse test_check_translation_parity. Aucune valeur honnete ne satisfaisait le guard -- reproduction sur #22932/#22670 (pair_changes=[renamed], 18->18, rouge:true). Le fix distingue les paires qui changent le compte des renames purs: - count_changing_pairs exclut le statut renamed; le verdict rouge n'exige un bump que sur added/removed; - un R dont l'ANCIEN chemin etait aussi une traduction est un rename pur; un R dont l'ancien chemin n'etait pas une traduction (ex notes.md -> X_en.ipynb) reste une addition -- le bump reste du; - le message ROUGE ne compte plus les renames dans delta_added; le message GREEN note les renames purs (count preserved). Tests: 26 existants + 2 nouveaux (rename complet de paire -> vert sans bump, statut renamed; rename-into-translation -> added, rouge sans bump). 28/28 verts. Preuve contrefactuelle: guard fixe rejoue sur #22932 (ac9bdca) et #22670 -> rouge:false sur les deux, paire classee renamed, 18->18. Co-authored-by: Claude Sonnet 5.5 <noreply@anthropic.com>
…ain + ligne 06b renommee Conflit unique sur ANALYSE/README.md. Trois lignes en presence : main a ajoute ANALYSE-05b-KLS-Song-Zhang-O1 et garde ANALYSE-06-Sensibilite-2026-Lean ; cette branche porte le renommage 06 -> 06b du companion natif. Resolution : la ligne 05b (nouveau carnet) et la ligne 06b (renommee) sont conservees dans l'ordre numerique ; la ligne de l'ancien ANALYSE-06 est retiree, sa cible n'existant plus dans l'arbre depuis le renommage de cette PR. COURSE_CATALOG.generated.* et docs/curriculum/ia-symbolique.md portent encore l'ancien chemin : fichiers generes, regeneres par le cron catalogue apres merge, jamais edites sur une branche feature. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
|
Rafraîchissement de base, tête
Périmètre inchangé après fusion : 5 fichiers — Les 77 carnets de la série parsent, aucun Le dossier exact-head est périmé à cette nouvelle tête et doit être refabriqué après stabilisation de la branche. |
github-actions
Bot
added
the
variation-light-cap-reached
|
G-VAR-2 light cap reached (advisory, non bloquant). |
|
G-VAR-2/3 GENRE signals (advisory, non bloquant, #10020).
G-VAR-2 plafonne a max(1, grains_mergees_du_jour // 3) LIGHT par lane et par jour, toutes categories LIGHT confondues -- un RATIO, pas un plafond plat ; le cap calcule du jour est dans le tally ci-dessus. G-VAR-3 interdit deux genres LIGHT consecutifs. Les signaux ci-dessus rendent le fait VISIBLE (labels |
|
[ADJOINT PREFLIGHT] |
… companion Lean Le registre de traduction pointait encore vers l'ancien nom du companion renomme en ANALYSE-06b : la chaine de traduction lisait un fichier qui n'existe plus. Les deux entrees (fr et en) portent desormais le nouveau chemin ; les entrees du companion Python (ANALYSE-06-...-Lean-Python) sont inchangees. Les quatre chemins ANALYSE-06* du registre existent sur disque apres edition ; le diff est de deux lignes. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
jsboige
added
the
translation-override
|
[TRANSLATION-OVERRIDE] Edition de Sur le fond de la revue : les cinq gardes cites comme rouges au head Les quatre corrections mecaniques annoncees comme option ont ete embarquees dans les commits posterieurs a la revue :
Sur la question de fond — « la regeneration ne vit que dans le workspace ephemere du runner » — le constat est exact et je ne le corrige pas par une formulation : c'est pourquoi les quatre corrections ci-dessus sont dans le diff plutot que laissees a une regeneration qui n'existe pas. Il reste les deux points d'interpretation, notes sans etre reserves :
Le merge order annonce (cette PR, puis #22670, puis l'etape d) reste valable. Lane myia-po-2024:CoursIA. |
github-actions
Bot
removed
the
variation-light-cap-reached
Grain: LIGHT/refactor — lane myia-po-2024:CoursIA — prev: MED/lean #22925
See #22649 (étape c, sur 3)
Ce que fait cette PR
Le companion natif porte désormais le numéro 06b, conformément à la décision des deux objets distincts postée sur #22649 (commentaire 6413771956) avant toute PR :
ANALYSE-06-Sensibilite-2026-Lean.ipynb→ANALYSE-06b-Sensibilite-2026-Lean.ipynbANALYSE-06-Sensibilite-2026-Lean_en.ipynb→ANALYSE-06b-Sensibilite-2026-Lean_en.ipynbLe commit de renommage lui-même (
1efd9bcd) reste ungit mvpur — similarité 100 %, aucun octet de contenu modifié, conformément à la règlenotebook-accretion-numberinget à #22671 (trois gestes, trois PR). Les commits suivants embarquent les registres bloquants que les gardes au head lisent (réponse à la réserve NanoClaw) :266ade7b68aANALYSE/README.md· liens croisés intra-paire en cellule 0 des deux carnets renommés · cléspedagogy_density_baseline.jsonrenommées (l'orphan guardLOST_KEY/UNKEYED_FILElit le head de la PR)3d26f31cb24ANALYSE-04retargeté vers 06b · mention du jumeau FR dans l'intro du_enac9bdcaffbaFichiers possédés par le cron — laissés byte-identiques à main
COURSE_CATALOG.generated.*,_quarto.yml(render list),translations/translation_golden_set.jsonetdocs/curriculum/ia-symbolique.md(page parcours) sont régénérés et committés parcatalog-cron.ymlverschore/catalog-refresh-pending(lignes 165-178 :regen_quarto_render.py,build_golden_set.py, puisgit add+ commit/push) — arbitrage #19901, et docstring debuild_golden_set.pypost-#22216 : « un fichier généré appartient au cron, une branche de contenu ne le régénère pas ». Entre le merge et le prochain passage du cron, la liste de rendu committée reste périmée par design : le garde per-PR est advisory précisément pour ça, etquarto-pages-deploy.ymlrégénère la liste dans le runner avant le rendu (les pages publiées ne cassent pas).ac9bdcaffbaretire mes edits manuels initiaux de ces fichiers : une édition à la main n'y produit jamais la sortie du générateur (empreintes, ordre, sections), et ne fait que brouiller le diff du cron.Résidus déclarés
translations/symbolicai-lean/symbolicai-lean.csv(26 lignes) : mémoire de traduction extraite des carnets, indexée par l'ancien chemin — aucune garde ne la lit au head de PR ; elle se réalignera au prochain passage du pipeline de traduction.sensitivity_lean/Sensitivity/Separations.lean:26,Separations_en.lean:25,Check.lean:5: la prose «ANALYSE-06-Sensibilite-2026» (sans suffixe) désigne désormais une famille ambiguë après le rename — non bloquant, repris en Disambiguer la prose Lean qui cite ANALYSE-06-Sensibilite-2026 apres le rename 06b #22970.metadata.papermill.*_pathdes deux carnets : traces du nom à l'exécution d'origine (basenames) — tolérance metadata, pas une sortie.sensitivity_lean/Check.lean:8: vise le jumeau Python, qui garde son numéro — aucun changement dû.Ordre de merge demandé
Vérifications
git grep "ANALYSE-06-Sensibilite-2026-Lean\.ipynb"au head : catalogue généré (2, cron), papermill metadata du carnet renommé (2, tolérance), CSV traductions (26, résidu déclaré) — aucune référence fonctionnelle restante.ac9bdcaffbasuivis au registre de vérifications de la lane.🤖 Generated with Claude Code