Repository navigation
fix(twin-registry): index 0016 duplique dans probas-2-gaussian-mixtures — renumerotation en 0017 (main rouge Scripts Tests) - #17858
Conversation
…es -- renumerotation en 0017 Deux PRs mergees le 2026-09-25 ont ecrit le meme index 0016 dans la meme paire du registre jumelle : #17808 (lane myia-po-2024:CoursIA, mergee 17:37:44+02:00) et #17755 (lane myia-po-2026:CoursIA, mergee 22:19:02+02:00). Chacune a calcule `max(index) + 1` = 0016 sur une base qui ne voyait pas l'autre -- mesure par le contenu : chacune atteste un seul cote courant, l'autre perime, depuis une base commune anterieure aux deux. `test_audit_index_unique_and_no_identical_duplicates_per_pair` rougit depuis sur main (run Scripts Tests (CPU) sur 9882979 = failure, precedent = success), ce qui rougit le job sur toute PR ouverte descendant de ce main. L'entree entree dans main en second prend l'index suivant, 0017 : l'index est la cle de tri du journal, et l'ordre chronologique observable est l'ordre d'entree dans main. Les deux attestations sont conservees -- elles ne sont pas byte-identiques (SHA de contenu et motifs distincts), donc aucune ne se deduit de l'autre. Renumerotation pure : aucun octet de contenu modifie, aucun SHA reecrit, aucun `--update` passe. Verification : test_twin_registry_integrity.py 1 failed -> 46 passed ; collisions d'index sur le registre entier 1 -> 0. Co-Authored-By: Claude Code <noreply@anthropic.com>
|
Trivial-diff advisory (#15740, non bloquant). |
|
Cette PR répare une récidive, pas un cas isolé — et elle ne ferme pas le tracker de la classe. La même panne est déjà suivie par #16769 (« registre twin en rouge sur Le correctif appliqué ici est celui que #16769 prescrit lui-même — renuméroter en préservant la chronologie — et la vérification est la même que la sienne :
|
|
[ADJOINT PREFLIGHT] Pourquoi BLOCKED — un seul champ, et ce n'est pas un defaut de cette PR.
Ce que la jambe decisive dit, elle, est deja vert.
La meme trappe est armee, en attente, deux PR plus loin. #17754 ( |
|
[ADJOINT PREFLIGHT] Dossier tiers d'urgence (main rouge sur
|
… parc (v4.33.0) (#17909) * docs(lean,#14773): resync des 10 LEAN_INVENTORY.md sur le pin reel du parc (v4.33.0) Grain: MED/docs — lane myia-po-2025:CoursIA — prev: LIGHT/ledger #17858 Les inventaires par serie annonçaient encore la cible precedente (v4.32.1) et citaient des workflows que la bascule vers la matrice `lean-ci-matrix.yml` a supprimes. Corrige sur mesure d'origin/main : - toolchain v4.32.1 -> v4.33.0 pour les lakes reellement migres (mesure `git show origin/main:<lake>/lean-toolchain` : 28 lignes de tableau, 0 ecart) - exceptions laissees telles quelles et documentees comme telles : `social_choice_lean_peters` (v4.32.1, amont incompatible 4.33) et `conway_cgt_lean` (v4.31.0-rc2, suit son amont) - workflow -> matrice `lean-ci-matrix.yml` + cle de `scripts/lean/ci_lakes.json` (10 cles verifiees : gametheory, gamedefs, gamedefsext, learningtheory, decisiontheory, kelly, search, sudoku, erc20, argumentation) - `planning_lean` garde `lean-planning.yml` (absent du catalogue de la matrice) et passe de `standalone-tactic` a `real`, baseline 0 - mentions « dernier run <date> » retirees la ou le changement de reference les rendait mal attribuees - `SymbolicAI/Lean` : perimetre explicite (3 lake roots non couverts, nommes), metrique `real` (bascule #11688) et lien relatif vers `.claude/rules/` repare Co-Authored-By: Claude Code <noreply@anthropic.com> * docs(lean): correct SocialChoice CI inventory reference Replace references to the retired workflow with the gametheory matrix key, including the certified SocialChoice path. See #14773. Co-Authored-By: Claude-Code <noreply@anthropic.com> --------- Co-authored-by: Claude Code <noreply@anthropic.com>
Grain: LIGHT/ledger — lane myia-po-2025:CoursIA — prev: MED/docs #17852
Ce que fait cette PR
Répare un rouge de
main, pas d'une PR : renomme une entrée du registre jumelle dont l'index était dupliqué.1 fichier renommé, 0 octet de contenu modifié, aucun SHA réécrit.
La panne, mesurée
test_audit_index_unique_and_no_identical_duplicates_per_pair(scripts/notebook_tools/tests/test_twin_registry_integrity.py:383) :origin/maindans un worktree neuf (git worktree add ... origin/main) :1 failed.main: runScripts Tests (CPU)sur9882979fcf(2026-09-25T20:19:05Z) =failure, précédé desuccesssura76a2e4795(20:17:09Z).Conséquence : le job
Scripts Tests (CPU)rougit sur toute PR ouverte dont la tête descend de cemain— y compris des PRs qui ne touchent pas le registre (#17831, un script et son test, en est un cas ; son échec est base-inherited, diagnostiqué sur son log : un seul test en échec, celui-ci).Cause racine
_next_index(scripts/notebook_tools/check_twin_parity.py:1492) rendmax(index) + 1. Deux PRs mergées le même jour ont chacune calculé0015 + 1 = 0016sur une base qui ne voyait pas l'autre :main0016-...-myia-po-2024myia-po-2024:CoursIA0016-...-myia-po-2026myia-po-2026:CoursIALe fait que les deux bases étaient disjointes est mesuré par le contenu, pas supposé — les deux attestations enregistrent des états partiels et complémentaires de la paire :
HEAD(contenu)python(PyMC-02-Gaussian-Mixtures.ipynb)18718dfe42ede35218718dfe…(courant)07c3c575…(périmé)csharp(Infer-2-Gaussian-Mixtures.ipynb)6ad93d79962c25988279ddaf…(périmé)6ad93d79…(courant)Chaque PR a changé un seul côté (
#17808: lien Suivant + stem swap, Python seul ;#17755: rendu mathématique, C# seul) en partant d'une base commune antérieure aux deux.Le choix d'index, et pourquoi c'est celui-là
L'index est la clé de tri du journal : il doit refléter l'ordre chronologique des audits. L'ordre observable est l'entrée dans
main—0016-po-2024(17:37:44) précède0016-po-2026(22:19:02). C'est donc la seconde qui prend l'index suivant,0017.Ce choix préserve aussi la sélection de « la plus récente » : le tri par nom plaçait déjà
0016-...-po-2026après0016-...-po-2024, donc la jambe advisory--verify-recorded-shalisait déjà l'entrée po-2026 comme la plus récente. Après renommage, elle l'est toujours (0017>0016) — aucun nouveau finding advisory n'apparaît.Pourquoi une renumérotation et non une suppression
Les deux fichiers ne sont pas byte-identiques (
sha256distincts, motifs distincts, SHAs de contenu distincts). Le cas de figure du test — « deux attestations byte-identiques » — n'est pas celui-ci : aucune des deux ne se déduit de l'autre, donc supprimer l'une effacerait un audit réel. La classe d'incident #15225 (copie cappée ajoutée sans retrait de l'original) ne s'applique pas non plus.Vérification
test_twin_registry_integrity.py(fichier entier)1 failedsurorigin/main46 passedcheck_twin_parity.py --json --check --per-pair --base origin/maindrift_introduced: 0(exit 0) —drift_pre_existing: 4, qui ne rougit pas le mode--per-pairLe scan complet du registre a été passé avant de choisir le périmètre, pour que la réparation soit complète et non partielle : c'était la seule collision.
Portée
See #14911,See #15345— convention de l'index comme clé de tri et garde du journal.See #16769— le tracker de la classe : « registre twin en rouge surmain— indices dupliqués » (ouvert, même symptôme, même remède). Cette PR est sa troisième occurrence, pas un cas isolé. La cause racine (_next_index=max(index) + 1, sans verrou) y est documentée et n'est pas traitée ici.--updatepassé (un--updatere-baselinerait des SHA et invaliderait le diagnostic ci-dessus).max(index) + 1: la PR ne corrige pas la course elle-même (hors périmètre d'une réparation de rouge) — la garde qui détecte existe déjà, c'est elle qui a rougi.🤖 Generated with Claude Code