Ratchets notebook : aucun organe ne mesure la substance de la SOURCE — 3116 caracteres et un verificateur entier supprimes sous 30 checks verts (#15862) #15901

Le fait

PR #15862 a fait passer au vert l'intégralité de la suite de ratchets notebook — Output-collapse ratchet, Papermill ratchet, Exec-sequence ratchet, Source-output ratchet, H.4 outputs-required — et son diff supprimait 3116 caractères de la cellule de code la plus durcie du notebook, dont un organe de vérification entier.

Mesure firsthand sur MyIA.AI.Notebooks/GameTheory/GameTheory-06e-Open-Source-Game-Theory.ipynb, trois refs (base = merge-base 244c7c54f032, head = 7a355873de32, main = tip) :

base : 7 code / 24 markdown        head : 7 code / 26 markdown
cellules code dont la source differe : 1  -> [5]
main[5] == base[5] ?  True         main[5] == head[5] ?  False
longueurs : base=8425  head=5309  main=8425

Ce que la cellule [5] perd entre base et head :

1. la table EXPECTED_TABLE_V2 (25 entrées encodées à la main), remplacée par un builder _spec_action() qui ré-encode les règles de string-match du moteur ('return "C"' in src, "DefectBot_toy_v2" in src) — exactement l'oracle non-indépendant que le REPAIR c.1013 / Add: GameTheory-06e Open Source Game Theory — transparence PD one-shot (#15173) #15175 avait retiré, et dont le commentaire sur main dit : « c'etait l'organe declaratif qui re-encodait la meme regle que l'implementation, pas un oracle independant » ;
2. le troisième organe de vérification en entier — le vérificateur externe en sous-processus avec assert proc.returncode == 0 (Tranche A [GameTheory] Tranche A Math for AI Safety — jeux-programmes one-shot exécutés #15173, scripts/notebook_tools/verify_program_games_table.py).

Le diagnostic — et la correction de mon premier diagnostic

J'ai d'abord écrit que la suite était aveugle parce que le merge-base était périmé (thèse : -X theirs écrase du contenu plus récent, et au merge-base la cellule régressée avait déjà cette tête). Cette thèse est fausse, et ma propre mesure la réfute : base = main = 8425. Le merge-base n'est pas périmé sur cette cellule, et la suppression de 3116 caractères est plainement présente dans le diff base↔head. Aucun organe n'avait besoin d'un meilleur point de référence pour la voir.

Le vrai défaut est plus simple et plus large :

Aucun ratchet ne mesure la substance de la SOURCE. Ils mesurent tous des sorties, des séquences d'exécution ou de la structure. Une cellule peut perdre 37 % de son code — table de référence, assert, appel de vérificateur externe — en restant présente, exécutée, avec des sorties cohérentes.

Et c'est précisément pourquoi check_output_collapse.py est resté muet : le matériel supprimé est une donnée déclarative et un assert silencieux en cas de succès. Il ne produit presque pas de sortie. Retirer un garde ne fait pas rétrécir la sortie — c'est même la définition d'un bon garde.

Le cherry-pick -X theirs (annoncé dans le body de #15862 : « -X theirs du seul commit substance 8f3151b262 ») est le mécanisme qui a produit la régression : il a fait gagner un commit antérieur au REPAIR contre le contenu de la branche. Ce n'est pas la cause de l'angle mort — l'angle mort resterait entier pour une suppression tapée à la main.

Le geste proposé

Organe symétrique de check_output_collapse.py, côté source. La doctrine existe déjà et n'a pas besoin d'être inventée — pr-review-discipline.md §D.7 énonce pour les sorties : un finding MAGNITUDE (perte d'un ordre de grandeur sur une cellule) exige une justification écrite dans le body, faute de quoi CHANGES_REQUESTED. Il s'agit d'étendre ce contrat à la source :

• par cellule de code, mesurer la perte de longueur de source base→head ;
• exempter mécaniquement ce que l'organe sorties exempte déjà (contenu déplacé vers une autre cellule, purge de diagnostic) — l'intersection des textes supprimés avec les textes ajoutés ailleurs dans le même notebook ;
• advisory, blocking=False, conclusion neutre, signal dans le détail du check-run — même forme que ci: aucun organe ne mesure l'effondrement du VOLUME de sortie des notebooks (angle mort demontre sur #15209) #15327, pour la même raison : le jugement reste au relecteur, l'organe rend la perte visible.

Un second organe, plus étroit et à discuter séparément : détecter la disparition d'une forme de garde dans une cellule (assert, subprocess.run(...) suivi d'un test de returncode, table de référence déclarative). Plus précis sur ce cas, mais heuristique — je ne le propose pas en premier.

Ce que je ne demande pas

Ce n'est pas un reproche à la lane porteuse de #15862. Le grain réel de cette PR — 20 cellules markdown pédagogiques, +2 — est bon et voulu ; la régression a voyagé dans le véhicule, et trente organes verts lui ont dit que tout allait bien. C'est le défaut d'outillage qui est en cause, et il vaut pour toute PR notebook du dépôt.

Critère d'acceptance

1. Un organe scripts/notebook_tools/check_source_collapse.py (ou nom équivalent), enregistré blocking=False dans scripts/ci/fast_lane_registry.py.
2. Un contrôle positif : rejoué sur le couple base 244c7c54f032 → head 7a355873de32 de fix(gametheory,#15210): distillation 06e Aumann/Nash/correlated -- rebase propre (1 fichier, +209/-195) #15862, il doit rendre un finding sur la cellule [5]. Un organe qui ne rougit pas sur l'incident qui l'a motivé n'est pas livré.
3. Un contrôle négatif : un enrichissement markdown-only du même notebook ne doit rien rendre.
4. §D de pr-review-discipline.md étendu d'un point, à la forme du D.7 existant.

— ouverte par myia-ai-01 avant tout merge de #15862, comme annoncé dans issuecomment-5650459644.