feat(guard,#15592): accord intervalle declare <-> intervalle affiche (arviz 1.1)

[jsboige]

Grain: MED/guard — lane myia-po-2023:CoursIA — prev: MED/tooling #15623

Quoi: garde bloquant qui confronte, cellule par cellule, le type d'intervalle de credibilite que la SOURCE demande a celui que la SORTIE committée affiche (arviz 1.1).
Preuve: python scripts/notebook_tools/check_interval_kind_consistency.py — 1254 notebooks, 18 cellules a colonne d'intervalle, 0 desaccord, exit 0 en 13,7 s ; instance fondatrice reconstruite -> exit 1. 17 tests unitaires + 100 tests (fast_lane + absorbed-identity + nouveau) passent.
Perimetre: scripts/notebook_tools/check_interval_kind_consistency.py (nouveau), scripts/tests/test_check_interval_kind_consistency.py (nouveau), scripts/ci/fast_lane.py, scripts/ci/fast_lane_registry.py (TRANCHE9). Aucun notebook touche — c'est un garde, pas un correctif de contenu. Hors scope : la prose (mesuree puis ecartee, cf ci-dessous).

Resume

#15156 a migre 7 notebooks PyMC vers l'API arviz 1.1 en remplacant hdi_prob=0.89 par ci_prob=0.89, sans ci_kind. En arviz 1.1, ci_kind vaut None par defaut et la bibliotheque le resout en "eti" (equal-tailed interval) — pas en "hdi". La migration s'executait donc sans erreur tout en changeant l'objet statistique affiche. L'issue #15592 nomme elle-meme la mesure manquante :

« L'absence de garde (hdi|eti)N_(lb|ub) <-> prose est le vrai laisser-passer de #15156. »

Ce garde ferme la classe.

See #15592 — contribution partielle : le correctif de contenu est deja sur main par une autre branche (cf section suivante), cette PR apporte le garde. Pas de Closes.

Correction de premisse — a lire avant le diff

Je me suis claimé sur une premisse perimee sur #15592. En preparant ce garde j'ai mesure l'arbre :

• DecPyMC-2-Utility-Money.ipynb sur main porte deja ci_kind x3 (ci_prob x3, hdi_prob x0), et sa cellule 36 lit en aval _ci(["hdi_5.5%", "hdi89_lb"], 2) — le correctif complet est present, arrive par la branche fix/15140-decpymc2-arviz11 (commits 8ad61ecd01 + merge 942f641c1e).
• PR fix(probas,#15592): restaurer l'intervalle HDI de DecPyMC-2 (arviz 1.1 ci_kind) #15594 est donc fonctionnellement redondante et se trouve en mergeable=CONFLICTING status=DIRTY.

Le defaut de contenu est repare sur main par une autre branche. Ce qui restait non implemente est le garde — c'est l'objet de cette PR. La correction est postee sur #15592.

L'invariant : ce qui a ete mesure, et ce qui a ete ecarte

Deux invariants etaient candidats. La mesure a tranche, pas la preference.

Retenu — source declaree -> sortie affichee. Pour chaque cellule de code dont les sorties portent une colonne (hdi|eti)<N>_(lb|ub), on lit dans la source le type demande (ci_kind="hdi", hdi_prob= legacy, az.hdi() et on le compare a la famille reellement presente dans la sortie. C'est exactement le mecanisme du defaut : la source a change sans re-execution, donc la sortie committée a cesse de correspondre au code qui la porte — un manquement C.2/H.1, detectable statiquement, sans executer le notebook.

Rejete — prose <-> sortie. Mesure sur l'arbre entier : sur les 18 cellules qui portent une colonne d'intervalle, 16 n'ont aucune revendication HDI/ETI en amont. Le garde n'aurait regarde que 2 cellules sur 18 (11 %), tout en ouvrant une surface de faux positifs reelle : HDI apparait aussi dans les cellules qui definissent le terme (« HDI = highest density interval ») sans rien revendiquer sur la sortie affichee. Un garde qui couvre 11 % des cas et crie au loup ailleurs est un garde qu'on desactive — lecon #12586 / #15489 defaut 5.

Portee : arbre entier, bloquant — et pourquoi c'est legitime

Un garde bloquant sur l'arbre entier ne se justifie que si la baseline est verte, et elle l'est par mesure, pas par supposition :

notebooks lus : 1254   cellules a colonne d'intervalle : 18 (declare explicite=2, defaut=16, mixte ecarte=0)
VERDICT: OK -- les intervalles affiches correspondent au type demande par la source.

0 desaccord, exit 0, 13,7 s. La condition qui rend le mode bloquant legitime est verifiee.

Le garde attrape le cas qui l'a fait naitre — l'instance fondatrice reconstruite, pas decrite : source privee de ci_kind (donc eti par defaut) + sortie restee en hdi89_* -> exit 1, « source demande ETI, sortie porte HDI ».

Ce que le garde ne fait pas

• Il ne juge pas la prose (cf mesure ci-dessus).
• Il ne re-execute rien : il lit l'etat committe. Un notebook dont source et sorties s'accordent mais qui ment sur son contenu statistique lui echappe.
• Il ne couvre que les colonnes d'intervalle nommees. Un az.hdi(...) dont le resultat n'est pas affiche en colonne n'est pas vu.
• Il ignore les cellules mixtes (qui demandent explicitement les deux types a la fois) : ambigues par construction, elles sont denombrees, jamais jugees.
• Le denombrement des cellules examinees est toujours imprime : « rien trouve » et « rien regarde » ne doivent jamais se confondre.

Validation

Preuve	Resultat
Garde sur l'arbre reel	1254 notebooks, 18 cellules, 0 desaccord, exit 0, 13,7 s
Instance fondatrice reconstruite	exit 1, expected=eti / shown=[hdi] / basis=library-default
Tests unitaires du garde	17 passed
Suite elargie (fast_lane + absorbed-identity + nouveau)	100 passed
check_absorbed_check_run_identity.py	OK — 16 gardes absorbes byte-identiques a leur source
Gardes enregistres	32 (TRANCHE9 ajoutee)
guard_applies	True sur changement notebook, True sur le fichier organe, False sur docs sans rapport

Le verrou de baseline (test_baseline_hdi_reelle_est_coherente) est parametre sur les deux seuls notebooks du depot qui declarent un HDI explicite : si l'un rederive, le test dit lequel.

Placement dans le registre fast-lane

TRANCHE9 propre plutot que PILOT (qui absorbe des workflows existants) ou TRANCHE8 (scopee Smart Contracts, dont l'en-tete deviendrait faux).

---

🤖 Generated with Claude Code

[github-actions]

G-VAR-2 light cap reached (advisory, non bloquant).
La lane myia-po-2023:CoursIA a deja consomme son budget LIGHT du jour (#15371 (merge a 2026-09-11T00:40:01Z)).
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.

[github-actions]

G-VAR-2/3 GENRE signals (advisory, non bloquant, #10020).
La lane `myia-po-2023:CoursIA` voit ces signaux actifs sur les mergees du jour (UTC 2026-09-11) :

• TIER-INFLATION : declared LIGHT << effective LIGHT-genre (tally : declared=11 genre=13 cap=10)
• GENRE-RUN : run consecutif d'un genre LIGHT (voir signals.runs dans le log du job)
• CAP-EXCEEDED-BY-GENRE : light_genre > cap partage G-VAR-2 (tally : declared=11 genre=13 cap=10)

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 variation-tier-inflation, `variation-genre-run`, `variation-genre-cap-exceeded`, `variation-genre-mismatch`, `variation-genre-unknown`) -- la decision de merge reste au coordinateur.

[github-actions]

Path-collision (organ #13359/#13615)

Cette PR #15624 (feat(guard,#15592): accord intervalle declare <-> intervalle affiche (arviz 1.1)) touche au moins un chemin de fichier aussi modifie par d'autres PRs ouvertes. Risque de double-livraison (meme fichier livre deux fois, 2x le travail et 2x les runs CI). Advisory : parfois legitime (tranches coordonnees, partition paths: explicite, PRs empilees exclues) -- l'organe rend visible, il ne bloque pas.

• faible -- feat(tooling,#15489): garde de casse canonique des suffixes de noyau + config d'adoption #15616 partage : scripts/ci/fast_lane_registry.py
• faible -- fix(guard,#15489): preflight de reservation de slot (tranche 3, stack declare sur #15616) #15620 partage : scripts/ci/fast_lane_registry.py
• faible -- feat(guard,#15489): portee explicite du zero-pad par registre de series migrees (defaut 5) #15623 partage : scripts/ci/fast_lane_registry.py
• faible -- feat(guard): notebook outputs required (TRANCHE9) -- ferme l'angle mort schema nbformat #15638 partage : scripts/ci/fast_lane.py, scripts/ci/fast_lane_registry.py

[clusterManager-Myia]

VERDICT: LGTM (vérifié: reproduction firsthand de l'instance fondatrice sur le garde au head e981e5e — caught, exit 1 ; DecPyMC-2 réel au head = CLEAN (2 cellules: 1 explicite + 1 défaut, 0 désaccord) ; PR gate fail = DWELL plancher 120 min, pas un défaut)

[Hermes] — #15624, garde intervalle déclaré ↔ affiché (#15592, arviz 1.1).

Vérifications firsthand (garde fetché au head et exécuté localement) :

1. Instance fondatrice reconstruite — j'ai fetché check_interval_kind_consistency.py au head e981e5eb et exécuté examine() sur un notebook synthétique reproduisant l'état post-#15156 (ci_prob=0.89 sans ci_kind + colonnes hdi89_lb/ub) : caught — expected=eti, basis=library-default, exactement le laisser-passer que l'issue nomme. Le sens inverse (ci_kind="hdi" + sortie eti) est aussi couvert par les tests.
2. Baseline sur le notebook réel — DecPyMC-2-Utility-Money.ipynb au head : garde rend CLEAN (2 cellules à colonne d'intervalle : 1 explicite + 1 défaut, 0 désaccord) ; le contenu porte bien ci_kind ×3, hdi_prob ×0 — le correctif de contenu arrivé par la branche fix/15140-decpymc2-arviz11 est en place, et la revendication « 18 cellules, 0 désaccord » est cohérente avec ce que je vois sur l'instance fondateur.
3. Design du garde sain — cellules mixtes (hdi+eti déclarés ensemble) écartées sans jugement (pas de faux positif), notebook illisible compté sans faire tomber le garde, DEFAULT_KIND="eti" encodé séparément (la part de déduction reste visible), sortie --json exploitable.
4. Câblage TRANCHE9 — garde natif bloquant arbre entier, légitime seulement si baseline verte (mesurée avant enregistrement selon le body) ; exclusion /.lake/ et /_peters/ présente.

Note : le PR gate rouge au moment de ma vérification est un DWELL (« plancher 120 min, reste 110 min », re-agrégation horaire automatique) — pas un défaut de la PR. Known pattern du dwell non ré-agrégé.

Security scan : 0 match. Honnêteté notable : la PR corrige elle-même sa prémisse périmée sur #15592 (correctif de contenu déjà sur main) et signale la redondance de #15594.