check_output_failure_text : MACHINE_PATH confond un utilisateur d'image de conteneur avec un chemin machine (2 faux positifs, 1 controle positif) #20120

Activity

1. jsboige commented on Oct 9, 2026

   

   jsboige

   on Oct 9, 2026

   OwnerAuthor

   More actions

   Contribution de mesure — lane myia-po-2024:CoursIA-2. Aucune PR (la lane est au plafond WIP) et aucune décision de design-gate prise ici : je livre les mesures que réclame l'acceptation, plus deux corrections de chiffres.

   Reproduction du constat

   python scripts/notebook_tools/check_output_failure_text.py --all --json à la tête 977e8bbdbb5f (behind_origin_main: 0) :

   carnets balayés	77
   MACHINE_PATH	73 sur 38 carnets
   dont chemins conteneur	7 (/home/user/ ×5, /home/appuser/ ×2)
   dont hôte/env	66

   Le constat du body est confirmé : les 73 sont en sortie. C'est le premier candidat discriminant testé — et il tombe.

   Deux candidats réfutés par la mesure

   1. « source contre sortie » — 73/73 occurrences sont en sortie, y compris les 2 Aspire. La cellule Aspire n'a pas le chemin dans sa source : elle affiche le contenu d'AppHost.cs, et le chemin est dans le fichier affiché. Le candidat ne sépare donc rien.
   2. « le littéral vit aussi dans une source suivie du dépôt » — git grep --fixed-strings rend 0 fichier (hors .ipynb) pour /home/appuser/.cache/huggingface comme pour /home/user/wt-aspire. L'AppHost.cs affiché est généré (non suivi), donc les deux populations se ressemblent aussi sur cet axe.

   Le troisième candidat évident — le nom d'utilisateur — est déjà exclu par le contrôle positif, comme le body le dit.

   Le discriminant qui sépare, mesuré

   Le chemin ouvre-t-il un littéral de chaîne sur sa ligne de sortie ? C'est-à-dire : le caractère immédiatement à sa gauche est-il un guillemet.

   forme	occurrences	dont conteneur
   BARE (chemin nu)	71	5 (Orleans)
   OPEN_LITERAL (ouvre un littéral)	2	2 (Aspire)

   Les 2 OPEN_LITERAL sont exactement les 2 faux positifs Aspire ; les 5 Orleans restent BARE. Collatéral sur le reste du corpus : 0 sur 66.

   La raison est celle du body — la provenance — et elle se lit sur les lignes :

   • Aspire : .WithBindMount(Path.Combine(…UserProfile), ".cache/huggingface"), "/home/appuser/.cache/huggingface") → texte de programme affiché ;
   • Orleans : Content root path: /home/user/wt-aspire/MyIA.AI.Notebooks/… → valeur émise par le runtime.

   Sur ce corpus, la forme satisfait les critères 1, 2 et 3 sans nommer aucun utilisateur.

   Deux chiffres à corriger avant d'écrire l'acceptation

   • Critère 3 — le nombre à protéger est 66, pas 64. Mesuré : 73 − 7 = 66 occurrences hôte/env. C'est ce total qu'un --all --json avant/après doit retrouver.
   • Critère 4 — le champ cell de l'organe est 0-based. Les cellules Orleans citées (12, 16, 19, 21, 23) sont des index 0-based ; en convention 1-based — celle qu'emploient les autres organes notebooks du dépôt — ce sont 13, 17, 20, 22, 24. Un test qui rejoue « ces 7 lignes précises » doit épingler la convention, sinon il compare la cellule voisine. (Même piège que celui rencontré sur fix(ml,#19754): rafraichir les outputs des carnets 04-Vision 4.4-4.6 apres le renumerotage (noms 4.2[c-k] residuels en sortie) #19984.)

   Bornes du prédicat — ce qu'il ne dit pas

   C'est un proxy de la provenance, pas la provenance. Deux classes le font mentir, à zéro occurrence mesurée aujourd'hui :

   • faux négatif : un bandeau runtime qui cite le chemin (Serving from "/home/user/x") ouvre un littéral et serait exempté ;
   • faux positif : un chemin en commentaire dans du code affiché (// /home/user/…) n'ouvre rien et resterait signalé.

   0 sur 66 est un chiffre de corpus, pas une couverture — la leçon vaut d'être appliquée ici : le prédicat doit porter son contrôle positif et son contrôle négatif dans le --self-test de l'organe (il en a un), faute de quoi il peut se vider en silence sans qu'aucun rouge ne le dise.

   Je ne tranche pas le choix : c'est le design-gate du propriétaire de l'organe. La mesure, la forme candidate et ses bornes sont ci-dessus.