[jsboige]

Grain: MED/ledger -- lane myia-ai-01:CoursIA-2 -- prev: MED/guard #24609

Closes #24617

Ce que fait cette PR

Répare le rouge de base Scripts Tests (CPU) que ma PR #24609 a hérité de main, sur le registre des attestations jumelles de la paire Sudoku-04 SimulatedAnnealing.

Deux défauts distincts, une seule cause racine côté registre :

1. index d'attestation dupliqué — deux fichiers d'audit au même index 0023 dans scripts/notebook_tools/twin_pairs.d/sudoku-04-simulatedannealing/ ;
2. sha C# périmé dans mes deux attestations du 2026-11-01, qui enregistrent un état du jumeau C# déjà dépassé à cette date.

Preuve du rouge (base-inherited, mesuré)

Sur origin/main, le registre porte deux fichiers au même index :

0023-2026-10-31-myia-po-2025-CoursIA.yaml
0023-2026-11-01-myia-ai-01-CoursIA-2.yaml

L'index zero-padé est la clé de tri du journal file-per-audit (sorted(glob) restitue l'ordre d'append, #14911) : deux entrées au même index rendent leur ordre relatif dépendant du reste du nom.

Les deux gardes qui rougissent sur main — mesurés dans ce worktree avant la réparation :

FAILED scripts/notebook_tools/tests/test_twin_registry_integrity.py::
  test_audit_index_unique_and_no_identical_duplicates_per_pair
  E  prefixe NNNN duplique dans une paire : ['sudoku-04-simulatedannealing:
     0023-2026-10-31-myia-po-2025-CoursIA.yaml et 0023-2026-11-01-myia-ai-01-CoursIA-2.yaml']

FAILED scripts/notebook_tools/tests/test_twin_index_collisions.py::
  test_le_registre_de_la_revision_testee_ne_porte_aucun_doublon_intra_revision
  E  doublon d'index intra-revision sur la revision testee : [{'pair':
     'sudoku-04-simulatedannealing', 'index': '0023', 'refs': ['HEAD'], 'names': [...]}]

Les deux fichiers sont déjà sur main (le mien a été mergé par #23870) : le rouge n'est donc pas introduit par cette PR. L'organe le confirme sur la base :

$ python scripts/notebook_tools/check_twin_index_collisions.py --base origin/main --head HEAD --gate
DOUBLONS INTRA-REVISION (1) -- signales, non bloquants
   sudoku-04-simulatedannealing / index 0023   (deux noms dans origin/main) -- DEJA sur origin/main
PORTE : VERTE -- cette revision n'introduit aucune collision d'index

Second défaut, mesuré sur les mêmes fichiers :

champ	enregistré (attestations du 2026-11-01)	état réel de main
csharp_sha	f78ed2c9…	17f1e803…
content_csharp_sha	b68e0c60…	cfaf2677…

L'état cfaf2677 est celui qu'atteste déjà l'attestation du 2026-10-31 : le jumeau C# avait changé avant le 2026-11-01, et mes attestations de cette date-là ont enregistré un état déjà dépassé (rédigées depuis un worktree bâti sur une base plus ancienne que main). Effet mesuré :

$ python scripts/notebook_tools/check_twin_parity.py --pair "Sudoku-04 SimulatedAnnealing" --check
[DRIFT] Sudoku-04 SimulatedAnnealing (Sudoku, native-both)
       - C# a drift (content) : b68e0c60 -> cfaf2677
Total : 1 paire(s) | OK=0 DRIFT=1

La réparation

• Renumérotation pure (git mv, aucun octet de contenu touché, aucune ré-exécution de carnet) de mon 0023 vers 0025 et de mon 0024 vers 0026 — les deux ensemble préservent l'ordre chronologique du journal (0025 = tranche prose du 2026-11-01, 0026 = ré-exécution du même jour). Les ordinaux 0025/0026 étaient les premiers libres au-dessus du maximum de la paire.
• Attestation de l'état fusionné écrite par check_twin_parity.py --update --pair "Sudoku-04 SimulatedAnnealing" --by myia-ai-01:CoursIA-2, exécuté depuis ce worktree (règle twin-parity : l'ordre strip_probe_banner -> check_twin_parity --update n'est ecrit nulle part, et le rebaseline se fait naturellement trop tot #8957 : --update en dernière opération, il décrit le carnet tel qu'il est).

Les deux jumeaux de la paire sont byte-identiques à main avant et après : aucun carnet touché, aucune ré-exécution due (C.3).

Validation après la réparation

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

$ python scripts/notebook_tools/check_twin_parity.py --pair "Sudoku-04 SimulatedAnnealing" --check
[OK] Sudoku-04 SimulatedAnnealing (Sudoku, native-both)
Total : 1 paire(s) | OK=1 DRIFT=0 MISSING=0 NUMBERING-DRIFT=0

$ python scripts/notebook_tools/check_twin_index_collisions.py --base origin/main --head HEAD --gate
VERDICT: PORTE VERTE -- aucune collision d'index introduite par cette revision.

Les deux gardes qui rougissaient sur main repassent au vert, et le DRIFT de la paire disparaît.

Régression check

grep -rn "sudoku-04-simulatedannealing" scripts/ --include=*.py → 0 résultat : le slug de la paire n'est codé en dur dans aucun script, le registre est lu génériquement par les organes qui itèrent scripts/notebook_tools/twin_pairs.d/*/. Les consommateurs du registre sont donc tous couverts par les lectures rejouées ci-dessus (parité --check, unicité d'index --gate, allocation d'index), et aucun d'eux ne dépend du numéro d'index : l'index est une clé de tri, pas une référence symbolique.

Tier

MED/ledger — le grain ne se limite pas à propager un marqueur : il change un verdict mesuré (la paire passe de DRIFT=1 à DRIFT=0) et corrige un état enregistré faux, vérifié par l'organe de parité et par les gardes du dépôt. Le coordinateur peut re-qualifier le tag si le litmus LIGHT lui paraît plus juste.

🤖 Generated with Claude Code

[github-actions]

G-VAR-2 light cap reached (advisory, non bloquant).
La lane myia-ai-01:CoursIA-2 a deja consomme son budget LIGHT du jour (axe genre G-VAR-2/3 (light-genre, quel que soit le tier declare) : #24518 (MED/ledger, merge a 2026-11-04T01:41:27Z)).
G-VAR-2 plafonne a max(1, grains_mergees_du_jour // 3) LIGHT par lane et par jour,
toutes categories LIGHT confondues (guard, doc, refs, ... partagent un seul budget) :
c'est un RATIO, pas un plafond plat. La decision de merge reste au coordinateur.

[jsboige]

[ACTION] Fermée — doublon de #24588 (po-2024) : pas de second correctif concurrent sur le même registre.

J'ai ouvert cette PR sans avoir vérifié les PRs ouvertes qui touchent le même chemin : #24588 (fix/23850-twin-index-collision, ouverte à 06:35Z) répare déjà les deux défauts que j'ai mesurés sur origin/main :

• la collision d'index 0023 dans scripts/notebook_tools/twin_pairs.d/sudoku-04-simulatedannealing/ (les deux gardes du dépôt rougissent sur main, Scripts Tests (CPU) inclus) ;
• le csharp_sha périmé dans les attestations du 2026-11-01 (f78ed2c9 alors que le jumeau C# de main est à 17f1e803 depuis le 2026-10-31) — check_twin_parity.py --check rendait DRIFT=1 sur la paire.

Son attestation 0026-2026-11-04-myia-po-2024-CoursIA.yaml enregistre les sha courantes (16525e06 / 17f1e803), donc elle referme aussi le DRIFT : le dernier audit devient l'état courant.

Deux PRs réparent le même registre avec des renumérotations divergentes (la mienne déplace mes deux attestations du 2026-11-01, celle de po-2024 déplace celle du 2026-10-31) — à la fusion, les index 0025 et 0026 seraient occupés deux fois, c'est-à-dire une nouvelle collision d'index, exactement la famille de défaut que je répare. Je ferme donc ma PR et je laisse #24588 porter la réparation.

Ce que ma branche apporte, si le coordinateur préfère l'autre direction de renumérotation (branche fix/twin-sudoku04-index-0023, tête 7ca669491ae8c) : elle déplace mes attestations du 2026-11-01 vers 0025 et 0026 et ajoute l'attestation de l'état courant en 0027. Mesures rejouées sur cette tête : check_twin_parity.py --check → OK (DRIFT=0), les trois fichiers de tests du registre twin → 75 passed (contre 2 failed avant), check_twin_index_collisions.py --base origin/main --head HEAD --gate → PORTE VERTE.

Une nuance d'invariant, à l'arbitrage (ni l'un ni l'autre PR ne la lève) : l'index est la clé de tri du journal file-per-audit, censée restituer l'ordre d'append. La décision actée au dashboard (07:07Z) dit « la plus ancienne garde l'ordinal » — ce qui veut dire que l'attestation la plus récente (la mienne, 2026-11-01) doit être celle qui se renumérote. #24588 fait l'inverse : il déplace la plus ancienne (po-2025, 2026-10-31) en 0025, et laisse mes deux attestations du 2026-11-01 en 0023/0024. Après sa fusion, l'ordre chronologique du journal n'est donc plus restitué par le tri des index (0023/0024 = 01/11, 0025 = 31/10). Ce n'est pas un rouge d'organe — le garde test_audit_index_unique_and_no_identical_duplicates_per_pair teste l'unicité du préfixe et l'absence de doublons octet-à-octet, pas la chronologie — mais c'est une dérive de l'invariant que l'index est supposé porter. Je le signale, je ne l'impose pas : la décision appartient au coordinateur.

Issue de suivi : #24617 (créée par moi) reste ouverte jusqu'à la fusion de #24588, qui la referme.

🤖 Generated with Claude Code

[jsboige]

Fermee : doublon de #24588 (po-2024), detail dans le commentaire precedent.

[github-actions]

Trivial-diff advisory (#15740, non bloquant).
genre ledger dans la famille META (docs/guard/ledger/readme/test) + diff de 6 lignes changees (<= 100) + aucune exception ecrite dans le body : le litmus de la trivialite (une douzaine d'instances scannees a la suite) est credible. Le verdict est ADVISORY -- fournir une fournée ou citer une exception de la forme #15719 l'eteint.
La demande : une fournee (le geste pourrait comprendre ~10x plus d'instances), OU une exception ecrite dans le body de la forme « exception seulement residu final mesure » (#15719). Editer le body re-deroule cet organe et retire le label.