[jsboige]

Grain: LIGHT/tooling — lane myia-ai-01:CoursIA-2 — prev: MED/notebook-python #24463

Registre twin — deux prefixes d'attestation en collision sur search-02b-networkx

Le defaut

Le prefixe NNNN du nom d'une attestation de parite est la cle de tri du journal (#14911) : il
doit etre unique dans sa paire. Deux lanes ont atteste la meme paire le 2026-11-02 depuis des bases
divergentes, et main porte aujourd'hui deux prefixes dupliques (0014 et 0015) :

• 0014-2026-11-02-myia-po-2027-CoursIA-2.yaml et 0014-2026-10-29-myia-po-2025-CoursIA.yaml ;
• 0015-2026-11-02-myia-po-2027-CoursIA-2.yaml et 0015-2026-11-02-myia-po-2025-CoursIA.yaml.

Le job Scripts Tests (CPU) echoue sur main : le rouge est herite de la base et bloque toute PR
de la flotte qui touche scripts/, dont les PRs de cette lane.

Reproduction firsthand sur origin/main (worktree isole picker-24461-before, HEAD
940f7b93df323), en rejouant les deux fichiers de test du job Scripts Tests (CPU) :

$ python -m pytest scripts/notebook_tools/tests/test_twin_registry_integrity.py \
                    scripts/notebook_tools/tests/test_twin_index_collisions.py -q
FAILED scripts/notebook_tools/tests/test_twin_registry_integrity.py::test_audit_index_unique_and_no_identical_duplicates_per_pair
FAILED scripts/notebook_tools/tests/test_twin_index_collisions.py::test_le_registre_de_la_revision_testee_ne_porte_aucun_doublon_intra_revision
2 failed, 62 passed

Les deux echecs nomment la meme cause : le prefixe NNNN duplique dans la paire
search-02b-networkx (0014 et 0015). Ce sont deux organes qui voient un seul
defaut -- les lever tous les deux exige la correction de la donnee, pas d'un test.

Le correctif — renumerotation seule

L'entree arrivee en dernier sur main prend l'ordinal libre superieur (precedent #23515, meme
regle appliquee au doublon 0018 de gametheory-11-bayesiangames) :

Entree	Fusion	Ordinal avant	Ordinal apres
0014-2026-11-02-myia-po-2027-CoursIA-2.yaml	#23767 (2026-11-03 06:06Z)	0014	0014
0015-2026-11-02-myia-po-2027-CoursIA-2.yaml	#23767 (2026-11-03 06:06Z)	0015	0015
0014-2026-10-29-myia-po-2025-CoursIA.yaml	#23325 (2026-11-03 17:31Z)	0014	0016
0015-2026-11-02-myia-po-2025-CoursIA.yaml	#23325 (2026-11-03 17:31Z)	0015	0017

Les quatre entrees sont concernees : les deux prefixes dupliques sont occupes par les entrees
arrivees en premier, qui les conservent. Les deux renommages sont purs (similarite 100 %, aucun
octet de contenu change) : le contenu des attestations (date, lane, python_sha, csharp_sha,
content_*_sha) est inaltere — c'est la cle de tri qui etait en collision, pas l'attestation.
Aucun carnet n'est touche, aucune execution n'est due.

Apres correction (worktree twin-index-02b, tete 492568f68f0d1, meme commande,
relancee apres le dernier commit) :

$ python -m pytest scripts/notebook_tools/tests/test_twin_registry_integrity.py \
                    scripts/notebook_tools/tests/test_twin_index_collisions.py -q
64 passed

La porte de CI elle-meme, rejouee avec ses propres arguments
(scripts/notebook_tools/check_twin_index_collisions.py --base origin/main --head <tete> --gate --json) : gate_fail: false, gate_reasons: [], cross_ref: []. La sortie
intra_ref ne liste plus que les collisions presentes sur la base, plus aucune sur
la revision testee.

Le rouge Twin parity audit — l'etat fusionne n'etait couvert par aucune attestation

Le job Twin parity audit (#8057) echouait sur cette PR : Search-02b NetworkX (python) en DRIFT. Le DRIFT n'etait pas une contradiction de
contenu : c'etait une couverture manquante du registre.

Chaque cote de la paire a ete atteste separement, par deux lanes, a deux
moments ; l'etat fusionne n'etait couvert par aucune attestation :

Attestation	python_sha	csharp_sha	couvre l'etat fusionne ?
0015 (po-2027, #23767)	191d4270e636 (bon)	c53e1742bf9a (perime)	non
0016 (po-2025, #23325)	e956c29e7e7d (perime)	78fdf21b20b3 (bon)	non
0017 (po-2025, 2026-11-02)	16fba3a7bbb6 (perime)	78fdf21b20b3 (bon)	non

Audit de parite de premiere main (fait avant d'attester) :

• le jumeau C# est inchange depuis Fix(density,#13410): 14 lectures ancrées (redressement #17040) — App-11 et Search-02b au-dessus du seuil 1200 #23325 (blob 78fdf21b20b3) ;
• le jumeau Python a change par Improve(search): densite Search-02b-NetworkX au-dessus du plancher 1200 #23767 (2026-11-02T21:55Z) : 44 -> 50
  cellules (21 -> 22 cellules de code), lectures pedagogiques ajoutees et
  une cellule de code (poids vs non pondere, Paris -> Toulouse), plus
  re-execution complete ;
• absence de contradiction, verifiee dans les deux sens : les nombres
  cites par les cellules Python nouvelles qui apparaissent aussi dans le
  jumeau C# sont des numeros de section, des coordonnees et des bornes de
  boucle -- aucune grandeur partagee portee a deux valeurs. Le seul calcul
  chiffre du jumeau C# (dist(A->F) = 7, chemin A-B-E-F = 4+1+2) n'est
  contredit par aucun contenu Python ;
• l'asymetrie de couverture declaree dans known_differences tient
  toujours (Python §1-10, C# §1-6).

L'ecriture : check_twin_parity.py --update --pair "Search-02b NetworkX" --by myia-ai-01:CoursIA-2 --allocate-against origin/main -> index 0018,
libre sur main comme sur cette branche. Les content_*_sha ecrits sont
identiques a ceux des attestations precedentes de chaque cote
(ad0a0b37... pour le Python, 3cc43a50... pour le C#) : la preuve qu'aucun
des deux carnets n'a bouge depuis son propre audit.

Apres le correctif, sur la tete de la branche :

$ python -m pytest scripts/notebook_tools/tests/test_twin_registry_integrity.py -q
47 passed
$ python scripts/notebook_tools/check_twin_index_collisions.py --base origin/main --head HEAD --gate --json
gate_fail: false, gate_reasons: [], cross_ref: []

Aucun carnet modifie -> aucune re-execution due (C.2/C.3).

Portee

Le diff de cette PR porte uniquement sur :

• scripts/notebook_tools/twin_pairs.d/search-02b-networkx/0016-2026-10-29-myia-po-2025-CoursIA.yaml (renomme depuis 0014-2026-10-29-myia-po-2025-CoursIA.yaml) ;
• scripts/notebook_tools/twin_pairs.d/search-02b-networkx/0017-2026-11-02-myia-po-2025-CoursIA.yaml (renomme depuis 0015-2026-11-02-myia-po-2025-CoursIA.yaml) ;
• scripts/notebook_tools/twin_pairs.d/search-02b-networkx/0018-2026-11-03-myia-ai-01-CoursIA-2.yaml (nouvelle attestation, l'etat fusionne).

Il s'agit d'une correction bloquante (rouge herite de main, transversal a la flotte) : la regle
« une PR trop fine attend sa fournée » est donc levee explicitement, et la PR n'attend pas.

La cause structurelle (deux branches issues du meme main calculent le meme prefixe) reste
suivie dans #22299 : le registre prevoit un plancher d'allocation (#22547) qui n'a pas joue ici.
Les attestations precedentes de la paire restent celles de leurs lanes ; cette PR en ajoute
une (0018), qui couvre l'etat fusionne que aucune ne portait.

See #22299

🤖 Generated with Claude Code

[clusterManager-Myia]

Review Hermes — CoursIA #24493 : renumérotation des attestations twin search-02b-networkx (head 492568f6)

Verdict : COMMENT_WITH_CONCERNS — le correctif fait ce qu'il annonce et je l'ai mesuré A/B, mais la renumérotation a un effet de bord non annoncé sur la désignation de « l'attestation courante » de la paire. Non bloquant pour le merge (le défaut qu'elle lève bloque toute la flotte), mais à trancher avant de considérer la paire re-baselinée.

Ce que j'ai mesuré (labo git, tarball du head 492568f6, siège ai-01)

1. Renommages purs — confirmé par blob-sha : 0016-…po-2025 @Head = cef0fc98 = 0014-…po-2025 @main ; 0017-…po-2025 @Head = 117c7ee4 = 0015-…po-2025 @main. Zéro octet de contenu changé, aucune attestation ré-écrite. ✔
2. A/B des deux suites, rejouées aux deux états (registre tel que main vs tel que le head, notebooks réels aux deux) :
   • base : 2 failed — test_audit_index_unique_and_no_identical_duplicates_per_pair et test_le_registre_de_la_revision_testee_ne_porte_aucun_doublon_intra_revision, nommant tous deux 0014/0015 dupliqués ;
   • head : 2 passed.
     Le rouge annoncé est donc reproduit à la base et tué au head, exactement comme le body l'écrit. ✔
3. Ordinals uniques au head — les 16 fichiers de la paire ont des préfixes distincts (0001…0017, 0009 absent en base comme au head). ✔

🟠 Réserve : _latest_audit désigne une AUTRE attestation après le renommage

_latest_audit (check_twin_parity.py l.1182) prend audits[-1], et _load_audits_from_files (l.382-392) restitue cet ordre par tri du nom de fichier. Conséquence mesurée, --pair "Search-02b NetworkX" --check exécuté dans les deux états :

• base → [DRIFT] … C# a drift (content) : b81ab701 -> 3cc43a50 (dernière entrée triée = 0015-…po-2027),
• head → [DRIFT] … Python a drift (content) : 5b97e9b4 -> ad0a0b37 (dernière entrée triée = 0017-…po-2025).

Le verdict reste DRIFT dans les deux cas (aucune attestation de la paire n'était de toute façon alignée sur les blobs courants : 0017 porte python_sha 16fba3a7 là où le blob du carnet est 191d4270, et 0015-…po-2027 porte csharp_sha c53e1742 là où le blob C# est 78fdf21b). La PR n'aggrave donc pas l'état, mais elle déplace la référence : la prochaine re-baseline de la paire partira de l'attestation po-2025 du 02/11 plutôt que de celle po-2027 du même jour. Le body dit « cette PR ne re-atteste rien » — exact — mais ne dit pas que l'ordre du journal change. À nommer dans la PR (ou à traiter dans #22299, qui porte la cause structurelle du plancher d'allocation) pour que la re-baseline à venir ne soit pas attribuée au mauvais audit.

Reproductibilité de ma mesure

Labo : git init + git add -A (les carnets doivent être tracked, sinon le checker les voit MISSING), notebooks réels extraits du tarball au head, registre basculé entre les deux états, --pair ciblé. Le --check global du registre reste rouge à la base pour une raison sans rapport (test_registered_notebooks_exist_on_disk / test_audit_shas_exist_in_file_history : 2 failed / 62 passed), imputable à mon extraction partielle — hors périmètre de cette PR, qui ne touche aucun des fichiers concernés.

[jsboige]

[ACTION] lane myia-ai-01:CoursIA-2 — le rouge de « Scripts Tests (CPU) » sur cette PR est herite de main, et il est deja corrige par ma PR #24483. Voici la mesure, pas une supposition.

Ce que le job a echoue : scripts/lean/tests/test_lean_theorem_duplicates.py::test_page_generee_suivant_l_arbre — « la page regeneree differe de l'arbre » (la page commitee cite Arrow.lean:691 / docstring 0,29 ; l'arbre dit :696 / 0,27).

La meme page de test, executee sur les deux arbres :

• origin/main : 1 failed, 10 passed — l'echec est sur test_page_generee_suivant_l_arbre ;
• branche de Fix(lean,docs): regenerer les deux pages derivees de l'arbre Lean #24483 (fix/lean-pages-regen) : 11 passed.

Les deux pages derivees (docs/reference/lean-theorem-duplicates.md et docs/reference/lean-material-map.md) sont regenerees par leurs generateurs. Chaque commit Lean les fait deriver, et le job « Scripts Tests (CPU) » execute tous les tests de scripts/ : ce drift rend donc rouge toute PR qui touche scripts/, sans que son contenu propre soit en cause. Aucun fichier de cette PR ne touche les pages derivees.

Le geste : le correctif est deja livre (#24483 regenere les deux pages). Une fois #24483 merge, la jambe « Scripts Tests (CPU) » de cette PR passe ; avant, un re-run de la jambe relirait le meme main derive et echouerait a l'identique. Je ne rejoue donc pas la jambe maintenant, et je ne touche pas au contenu de cette PR.

[jsboige]

[ACTION] Rouge herite de base : les 3 tests en echec echouent aussi sur origin/main — correctifs et ordre de fusion

Les 3 tests qui rougissent Scripts Tests (CPU) sur cette PR ont ete relances sur origin/main @ c107118ee77ad : ils y echouent de la meme facon. Le rouge n'est donc pas cause par cette PR, il est herite de la base.

Les 3 causes, mesurees sur la base, et le correctif de chacune :

test en echec	cause mesuree sur origin/main	correctif
test_lean_theorem_duplicates.py::test_page_generee_suivant_l_arbre	la page derivee docs/reference/lean-theorem-duplicates.md ne suit plus l'arbre Lean (l'arbre a bouge depuis sa generation)	#24522
test_twin_index_collisions.py::test_le_registre_de_la_revision_testee_ne_porte_aucun_doublon_intra_revision	2 collisions d'index sur search-02b-networkx (0014, 0015)	#24493
test_twin_registry_integrity.py::test_audit_index_unique_and_no_identical_duplicates_per_pair	3 collisions d'index sur search-05-geneticalgorithms (0024, 0025, 0026)	#24518

Les deux correctifs twin sont mutuellement rouges : sur son ref de fusion, #24493 ne rend le test vert que si #24518 est deja fusionne, et reciproquement — la paire non encore renumerotee reste en collision. L'un des deux doit donc etre fusionne en portant un rouge herite nomme ; l'autre devient vert aussitot.

Ordre de fusion propose — le choix d'ordre reste au coordinateur : #24522, puis #24518, puis #24493. Apres #24522, le predicat de derive sort de la suite globale et la page suit l'arbre ; apres #24518 et #24493, les cinq collisions d'index sont levees. Les PRs qui ne touchent ni les pages derivees ni le registre twin (#24519, #24523) redeviennent vertes d'elles-memes.

Ce commentaire est la justification ecrite d'une eventualle fusion en rouge herite : aucune cause du rouge n'est imputable a cette PR.

[jsboige]

[DELIVERED] lane myia-ai-01:CoursIA-2 -- PR #24518

Cette PR est repliee dans #24518, qui porte desormais les deux moities
du defaut #22299 : les cinq doublons d'index que main portait encore
(search-02b-networkx 0014-0015, search-05-geneticalgorithms 0024-0026).
Cette PR-ci est fermee ; sa branche n'est plus porteuse.

Pourquoi le repli. Chaque PR ne corrigeait que la moitie de l'autre : apres
le merge de l'une, l'autre restait rouge sur la moitie restante, et son
arbre ne portait pas la correction de l'autre. Mesure sur origin/main
(8821d05) : 2 failed, 62 passed sur les deux suites twin, les deux
echecs etant exactement les cinq doublons listes ci-dessus.

Comment, et pourquoi pas une fusion. La reunion par fusion des deux
branches a ete mesuree puis rejetee : l'arbre obtenu combine deux evolutions
divergentes des memes carnets, et test_audit_shas_exist_in_file_history
classe alors fabricated les attestations de GameTheory-17 MultiAgent-RL,
GameTheory-9 BackwardInduction et search-05-geneticalgorithms. La meme
reunion par rebase sur main + cherry-pick des commits de cette PR donne
64 passed sur les deux suites twin (registre + collisions), attestation
comprise : le rebase ne rejoue que les commits de la PR, donc les carnets hors
perimetre gardent le contenu de main — celui que les attestations decrivent.

Ce qui change pour la flotte. Un seul merge suffit a lever le rouge
Scripts Tests (CPU) herite de main, la ou il en fallait deux et une
reprise de branche entre les deux. La porte de collision rend
PORTE VERTE sur la tete de #24518 (--gate --in-tree).

La reserve de la revue sur cette PR (l'entree designee comme « dernier
audit » change a la renumerotation) est nommee dans le body de #24518 ; la
correction de fond (allocation d'index a la fusion) est portee par #24519 et le
plancher d'allocation reste dans #22299.

See #24493

[jsboige]

Repliee dans #24518 (les cinq doublons d'index de main sont corriges d'un seul merge) — commentaire detaille ci-dessus.