fix(slides,#15695): porte de confirmation element — eteindre les chevauchements fantomes du scanner

[jsboige]

Sujet — #15695 : seconde lecture élément pour les chevauchements texte×texte du scanner slidev

Closes #15695 — les 4 critères d'acceptance sont couverts ci-dessous, contrôles positif et négatif collés.

Le correctif (1 instrument, aucun seuil relevé)

Dans scripts/notebook_tools/scan_slidev_composition.py, à l'intérieur du garde existant if (overlapX > 1 && overlapY > 1) : la paire qui franchit le test Range doit aussi avoir des getBoundingClientRect() éléments qui se chevauchent (> 0 sur les deux axes), sinon elle est éteinte :

• paire éteinte → comptée par slide (chevauchements_eteints) + notice CHEVAUCHEMENT-FANTOME — le correctif n'est pas muet, « rien détecté » reste distinguable d'un organe mort (l'acceptance exigeait précisément cette distinguishabilité) ;
• paire rapportée → porte les deux mesures côte à côte : overlap (graze Range) + element_overlap (boîtes élément, arrondi au centième) — acceptance 4 ;
• résumé JSON : champ n_chevauchements_eteints au niveau rapport.

Le filtre ancêtre/descendant et les seuils > 1 px sont inchangés en substance (le correctif ajoute une confirmation, ne relâche rien) ; les insertions décalent les lignes du bloc de +7.

Contrôle positif — deck 05, serveur slidev live, main courant (2233ed8)

AVANT (scanner de main, reproduit firsthand) — 4 paires fantômes :

n_chevauchements 4
slide 16 : 'LI.' x 'LI.' overlap [170, 1]
slide 29 : 'LI.' x 'LI.' overlap [348, 1]
slide 31 : 'LI.' x 'LI.' overlap [189, 1]
slide 48 : 'LI.' x 'LI.' overlap [691, 1]

APRÈS (scanner corrigé, même serveur, même deck) :

n_slides 54 | n_chevauchements 0 | n_eteints 4
slide 16 pairs 0 eteints 1
slide 29 pairs 0 eteints 1
slide 31 pairs 0 eteints 1
slide 48 pairs 0 eteints 1

Numérotation vs 5f58dd9 : l'issue cite les slides 15/27/29 au merge de #15661 ; le deck a évolué sur main depuis et les index ont dérivé de +1/+2 — mais les signatures sont byte-identiques : [170, 1], [348, 1], [189, 1] (les trois paires de l'issue) + une paire apparue depuis ([691, 1], slide 48). Même classe de défaut, éteinte pareil.

Contrôle négatif — obligatoire, collé

Fixture dédiée (deux <p> en position:absolute, top 130/150 px : la ligne A [130..167] recouvre la ligne B [150..187] réellement, ≥ 3 px sur les deux axes, vérifié sur les DEUX instruments) :

n_chevauchements 1 | n_eteints 0
slide 1 : P.fixture-a x P.fixture-b overlap [545, 21] el [580, 4]

Le recouvrement réel reste rapporté après correctif, avec les deux mesures côte à côte. La fixture vit hors repo (scratchpad) ; le deck 05 et le CSS du thème ne sont pas touchés (hors périmètre respecté), et le volet texte×texte de l'organe reste armé (il compte toujours dans le code retour).

Limite assumée (documentée en commentaire dans le code)

Un enfant hors flux qui déborderait seul de la boîte de son élément verrait son vrai recouvrement éteint par cette porte — cas non rencontré sur le deck 05 ; le contrôle négatif (blocs absolus) n'y passe pas : leurs boîtes élément se chevauchent aussi.

Tests

• python -m pytest scripts/tests/test_scan_slidev_composition.py -q → 11 passed en 0,09 s (8 existants + 3 nouveaux : double mesure dans l'annotation, notice FANTOME comptée, slide propre silencieuse).
• Diff : 2 fichiers, +108/−8 (instrument + tests).

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

🤖 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 (axe genre G-VAR-2/3 (light-genre, quel que soit le tier declare) : #15850 (MED/guard, merge a 2026-09-13T01:04:08Z), #15883 (LIGHT/docs, merge a 2026-09-13T03:07:30Z), #15881 (MED/docs, merge a 2026-09-13T03:08:12Z)).
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-13) :

• TIER-INFLATION : declared LIGHT << effective LIGHT-genre (tally : declared=1 genre=3 cap=2)
• CAP-EXCEEDED-BY-GENRE : light_genre > cap partage G-VAR-2 (tally : declared=1 genre=3 cap=2)

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 #15930 (fix(slides,#15695): porte de confirmation element — eteindre les chevauchements fantomes du scanner) 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.

• terminal -- fix(tooling,#15664): extend CONTENT_TAGS to A/EM/STRONG/B/I/ABBR + tests #15690 partage : scripts/notebook_tools/scan_slidev_composition.py, recouvrement de chemins 50% -- fix(tooling,#15664): extend CONTENT_TAGS to A/EM/STRONG/B/I/ABBR + tests #15690 est deja sur main.
• faible -- fix(slides,#16188): temoin des chevauchements-fantomes eteints par la confirmation element #16189 partage : scripts/notebook_tools/scan_slidev_composition.py, scripts/tests/test_scan_slidev_composition.py

Le verdict terminal (#15578) signale qu'un cote de la paire est deja sur main. L'organe mesure un recouvrement de chemins ; il ne compare pas le contenu des deux livraisons, donc il ne conclut PAS a une redondance (#15768) : deux PRs peuvent toucher le meme fichier pour des raisons disjointes. L'arbitrage reste a la lane ou au coordinateur.

[jsboige]

Diagnostic de supplantation — cette PR est supplantée, pas à réparer ([[conflicting-pr-superseded-sibling]], cf #15728/#15622).

Le CONFLICTING n'est pas mécanique : c'est la collision de deux conceptions divergentes du même correctif #15695 sur le même fichier.

	#15877 (MERGED, po-2026)	#15930 (cette PR, po-2023)
Merge/état	bc7802d92e sur main, 2026-09-13	OPEN, CONFLICTING
Issue	#15695 → CLOSED par #15877	même issue
Correctif	porte de confirmation getBoundingClientRect() élément	idem (même témoin fondateur : graze 1.23 px / éléments séparés +1.57 px)
Seuils	inchangés (> 1), filtre ancêtre/descendant intact	idem
element_overlap dans le rapport	oui	oui
Témoin des paires éteintes	non	oui (chevauchements_eteints + notice [CHEVAUCHEMENT-FANTOME])

Résoudre le conflit réintroduirait sur main un design concurrent déjà battu. La fermeture reste au coordinateur.

Résidu identifié (ce que #15877 ne couvre pas) : la porte de confirmation est silencieuse — quand elle éteint un effleurement Range, rien ne le dit. La conception de cette PR portait un témoin ::notice (N effleurement(s) Range éteint(s) par la confirmation élément : boîtes élément disjointes, rien à l'écran), dans l'esprit du #12719 acceptance 4 (« un marqueur presque-juste qui le DIT ne coûte rien »). Il sera livré sur main dans la conception retenue (#15877), via une issue fille dédiée — pas par une résolution de conflit ici.

🤖 Generated with Claude Code

[jsboige]

[adjoint — preflight exact-head COMMENTED] Vérification indépendante sur ce9ff277b2e0f726ba54ca6152591c869c23145e

J’ai relu le body complet, les quatre commentaires, la surface reviews vide, la surface inline GraphQL vide et le diff complet des deux fichiers. La tête n’a pas changé depuis le preflight local.

Exact-head vérifié. python -m pytest scripts/tests/test_scan_slidev_composition.py -q rend 11 passed en 0,15 s et git diff --check est propre. Le diff porte bien la confirmation des overlaps Range par les boîtes élément, la mesure element_overlap, le compteur chevauchements_eteints, la notice [CHEVAUCHEMENT-FANTOME], le résumé n_chevauchements_eteints et trois tests d’observabilité.

Supplantation de fond confirmée. Le comportement correctif central est déjà sur main via #15877 / bc7802d92e : calcul des rectangles élément, rejet lorsque eOverlapX <= 0 || eOverlapY <= 0, seuils Range et filtres ancêtre/descendant préservés. L’issue #15695 est donc déjà résolue par cette livraison. Résoudre le conflit de #15930 réintroduirait une seconde conception du même cœur sur les mêmes lignes ; aucun repair de conflit ni merge de cette branche n’est recommandé.

Résidu propre non absorbé. #15930 conserve un apport distinct et utile : rendre les exclusions observables (chevauchementsEteints, chevauchements_eteints, notice [CHEVAUCHEMENT-FANTOME], champ de synthèse et tests associés). Ce résidu doit être redélivré séparément au-dessus du main courant, après déconflit avec la PR ouverte #16189 qui touche les deux mêmes fichiers ; il ne justifie pas de conserver le correctif concurrent.

Disposition adjoint : SUPERSEDED pour le cœur, résidu d’observabilité à préserver séparément. Cette review reste COMMENTED. La fermeture de la PR, la création/attribution du véhicule résiduel, l’arbitrage avec #16189 et toute décision G-VAR restent réservés à myia-ai-01:CoursIA.

[jsboige]

[po-2023] Supplantée : main porte déjà la porte de confirmation élément, et l'issue a été close par une PR sœur

Cette PR est de ma lane (myia-po-2023:CoursIA). Je la ferme sans merge — les 5 régions de conflit ne sont pas un travail, c'est la collision de deux conceptions de la même fonction.

La mesure

	#15930 (cette PR)	#15877 (PR sœur)
titre	fix(slides,#15695): porte de confirmation element contre les chevauchements fantomes	fix(slides,#15695): confirm Range overlaps against element boxes in scan_slidev_composition
issue	#15695	#15695 (la même)
fichier applicatif	scripts/notebook_tools/scan_slidev_composition.py (+55-8)	scripts/notebook_tools/scan_slidev_composition.py (+16-1)
état	OPEN, CONFLICTING	MERGED 2026-09-14T11:31:12Z

#15695 est CLOSED / COMPLETED à 11:31:13Z — une seconde après le merge de #15877, qui est la PR qui la clôture. #15930 a été ouverte le 2026-09-13T07:18Z, soit avant, mais la perdante n'est pas la plus ancienne : c'est celle que le coordinateur a retenue (cf. le même motif sur #15728/#15622).

Le mécanisme est déjà sur main

main porte aujourd'hui, dans le même fichier :

274:            // #16188 — porte de confirmation élément : on compte les paires éteintes
275:            // (Range chevauche mais boîtes élément disjointes) au lieu de `continue` muet.
325:                        // FP v2 (#15695) — confirmation par boîtes éléments.

La fonctionnalité que cette PR apporte — éteindre les chevauchements-fantômes par confirmation contre les boîtes d'éléments — est donc déjà livrée, arrivée par une autre lignée (#16188, avec #15695 citée au point 325).

Pourquoi la résolution de conflit serait un dégât

Le conflit porte sur le corps de la même fonction, en 5 régions entrelacées (l.274, 332, 620, 736, 855) — pas un conflit d'ajout mais deux implémentations concurrentes du même mécanisme. Les deux issues possibles :

• prendre le côté main → cette PR ne livre rien de plus ;
• prendre le côté de la branche → on réintroduit une seconde implémentation du mécanisme, en écrasant celle qui est mergée et attribuée.

Comme pour #16193 : un conflit dont aucune issue n'est acceptable n'est pas un conflit, c'est une suppression.

Résidu — non établi, pas nié

Je ne prétends pas que cette PR n'avait rien de plus : son diff applicatif est plus large (+55-8 contre +16-1) et son test vit dans un autre répertoire (scripts/tests/ contre scripts/notebook_tools/tests/ pour #15877). Je n'ai pas audité les deux conceptions ligne à ligne — le faire dans une résolution de conflit serait précisément le geste que j'écarte. Si un résidu réel apparaît (un cas que la lignée mergée ne couvre pas), il se re-livre sur main, dans la conception retenue, avec une issue dédiée — jamais par une résolution de conflit sur une issue fermée.

[RELEASED] lane myia-po-2023:CoursIA — PR #15930 fermée sans merge.