You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Le cliquet bloquant Split-reading ratchet (base vs PR) lit une fusion — deux cellules de lecture réduites à une — comme une lecture ajoutée. Mesuré sur #17062 (redressement densité P02, 6 carnets GameTheory), au head 92d07bb349, avec l'organe de maincourant (donc après #17749) :
La PR retire des cellules (42 → 40 sur GT-10, 2 → 1 lecture après le même code sur les trois constats) : le compteur de paires et le compte de cellules baissent, et l'organe y voit trois lectures de plus.
Anatomie des trois constats (vérifiée cellule par cellule)
Les cellules de code sont byte-identiques base ↔ tête, l'alignement se fait par ordinal :
Carnet
Tête, après le code
Base, après le même code
Ce que la tête porte
GameTheory-08
md[18], 360 c.
2 cellules : 185 + 173 c.
les deux, concaténées
GameTheory-08c
md[6], 711 c.
2 cellules : 341 + 369 c.
les deux (la 341 était placée avant son code)
GameTheory-08c
md[21], 653 c.
2 cellules : 229 + 423 c.
les deux, concaténées
Les deux cellules de chaque paire viennent de la même PR de densité (#16706 pour GT-08, #16723 pour GT-08c — vérifié par git log -S) : la campagne avait produit deux lectures pour une sortie. La fusion est le remède que le mandat prescrit (« si on rajoute une lecture, on modifie le paragraphe de lecture existant, on n'en rajoute pas un deuxième »).
Pourquoi les trois signaux de réécriture sont hors d'atteinte
Signal
Pourquoi il ne mord pas ici
(a) même index et même source
la source diffère — c'est une fusion
(b) head_id présent dans base_id_pool
les cellules de campagne de ces carnets sont sans id (id=None) : le canal de l'identifiant est fermé
(c) même index et les deux sont markdown (#17044, étendu #17747)
la fusion retire une cellule, donc l'index de la cellule de tête décale de 1
(c) est topologique et indexé : il reconnaît la réécriture en place, pas la réduction du nombre de cellules après un même code.
Signal proposé (exact, sans seuil de similarité)
Dans detect_added_readings, branche SECOND_READING, là où already_had_md_after est évalué : pour le code de tête prev_cell, comparer le nombre de cellules markdown qui le suivent des deux côtés (les positions de base du même code sont déjà calculées dans base_code_positions) :
si la tête en porte strictement moins que la base, alors aucune lecture n'a été ajoutée après ce code — la cellule de tête est une fusion, pas un ajout.
L'empilement réel reste attrapé, et par construction : empiler augmente le compte (c'est déjà ce que dit le commentaire du signal (c) : « la lecture empilée arrive à un index où la base porte autre chose (ou rien), et le compte de paires, lui, monte »). Le contrôle négatif à ajouter est donc : deux lectures en base, deux lectures en tête dont une nouvelle → reste rouge.
Alternative écartée, et pourquoi
La seule variante qui rendrait l'organe vert sans toucher l'organe serait de supprimer les faits portés par l'une des deux cellules (G(5)/G(6) pour GT-08 ; la description de mex/find_periodicity et l'exemple Wythoff pour GT-08c) — c'est-à-dire dégrader la lecture pour satisfaire l'instrument, l'option que #17777 a explicitement écartée pour les énoncés d'exercice. La PR #17062 ne modifie donc pas ces cellules et reste rouge sur ce seul point.
contrôle négatif : base = 2 lectures après un code, tête = 2 lectures dont une nouvelle → reste rouge ;
suite scripts/tests/test_check_split_reading_cells.py verte, self-test du cliquet 5/5.
Séquençage : scripts/notebook_tools/check_split_reading_cells.py est déjà porté par #17831 (et #17721 déclare une collision de fichier) — cette issue n'ouvre pas de PR concurrente ; à arbitrer par ai-01 : absorber dans #17831, ou traiter après son merge.
Le constat
Le cliquet bloquant
Split-reading ratchet (base vs PR)lit une fusion — deux cellules de lecture réduites à une — comme une lecture ajoutée. Mesuré sur #17062 (redressement densité P02, 6 carnets GameTheory), au head92d07bb349, avec l'organe demaincourant (donc après #17749) :La PR retire des cellules (42 → 40 sur GT-10, 2 → 1 lecture après le même code sur les trois constats) : le compteur de paires et le compte de cellules baissent, et l'organe y voit trois lectures de plus.
Anatomie des trois constats (vérifiée cellule par cellule)
Les cellules de code sont byte-identiques base ↔ tête, l'alignement se fait par ordinal :
Les deux cellules de chaque paire viennent de la même PR de densité (#16706 pour GT-08, #16723 pour GT-08c — vérifié par
git log -S) : la campagne avait produit deux lectures pour une sortie. La fusion est le remède que le mandat prescrit (« si on rajoute une lecture, on modifie le paragraphe de lecture existant, on n'en rajoute pas un deuxième »).Pourquoi les trois signaux de réécriture sont hors d'atteinte
head_idprésent dansbase_id_poolid(id=None) : le canal de l'identifiant est fermé(c) est topologique et indexé : il reconnaît la réécriture en place, pas la réduction du nombre de cellules après un même code.
Signal proposé (exact, sans seuil de similarité)
Dans
detect_added_readings, brancheSECOND_READING, là oùalready_had_md_afterest évalué : pour le code de têteprev_cell, comparer le nombre de cellules markdown qui le suivent des deux côtés (les positions de base du même code sont déjà calculées dansbase_code_positions) :L'empilement réel reste attrapé, et par construction : empiler augmente le compte (c'est déjà ce que dit le commentaire du signal (c) : « la lecture empilée arrive à un index où la base porte autre chose (ou rien), et le compte de paires, lui, monte »). Le contrôle négatif à ajouter est donc : deux lectures en base, deux lectures en tête dont une nouvelle → reste rouge.
Alternative écartée, et pourquoi
La seule variante qui rendrait l'organe vert sans toucher l'organe serait de supprimer les faits portés par l'une des deux cellules (G(5)/G(6) pour GT-08 ; la description de
mex/find_periodicityet l'exemple Wythoff pour GT-08c) — c'est-à-dire dégrader la lecture pour satisfaire l'instrument, l'option que #17777 a explicitement écartée pour les énoncés d'exercice. La PR #17062 ne modifie donc pas ces cellules et reste rouge sur ce seul point.Liens
id(même famille : le corpus sansid; ici la réduction échappe au signal (c)) ;Acceptation
scripts/tests/test_check_split_reading_cells.pyverte, self-test du cliquet 5/5.Séquençage :
scripts/notebook_tools/check_split_reading_cells.pyest déjà porté par #17831 (et #17721 déclare une collision de fichier) — cette issue n'ouvre pas de PR concurrente ; à arbitrer par ai-01 : absorber dans #17831, ou traiter après son merge.