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
{{ message }}
Repository navigation
[Audit #17073] Série DSWA — 04-Vision — partition Hermes #21183
Panorama de la sous-série ML/DataScienceWithAgents/04-Vision (14 notebooks, partition Hermes)
Sous-série vision de DSWA, sortie des Epics #12422 (architectures CNN) et #16057 (famille détection) : 4.1 pose le neurone convolutif from scratch (conv2d NumPy, gradient par différence finie, parité torch), 4.2/4.2b traitent l'effondrement du gradient en profondeur (résiduelles, companion Lean), 4.3 le transfer learning ResNet18/EuroSAT, puis la trilogie détection from scratch (4.4 anchor / 4.4b anchor-free / 4.4c focal loss) et la famille SOTA wrappers (4.5 torchvision, 4.5b/4.5c/4.5d YOLO, 4.6/4.6b/4.6c scènes difficiles, camouflage adversarial, dazzle génératif).
Arc : primitive from scratch et parité (4.1) → profondeur et résiduelles (4.2/4.2b) → détection from scratch (4.4/4.4b/4.4c) → délégation SOTA (4.3/4.5/4.5b/4.5c/4.5d/4.6) → renversement adversarial (4.6b/4.6c). Même discipline que 03-DeepLearning : from scratch PUIS framework, parité epsilon machine.
Niveau proposé : intermédiaire avancé (prérequis : 03-DeepLearning en entier, en particulier 3.4 ; NumPy niveau 1.2).
Ordre proposé : 4.1 → 4.2 → 4.2b → 4.4 → 4.4b → 4.4c → 4.3 → 4.5 → 4.5b → 4.5c → 4.5d → 4.6 → 4.6b → 4.6c (ordre de la feuille de route du README, qui liste 4.4/4.4b/4.4c avant 4.3 ; les datations de livraison ne suivent pas cet ordre mais les renvois internes oui).
Checklist
4.1-Conv-NumPy-Torch-Allclose.ipynb — audité ce cycle (3 findings en commentaire)
4.2-ConvNet-Profonde-Residuelles.ipynb
4.2b-Lean-GradientFlow-Vanishing.ipynb
4.3-TransferLearning-ResNet.ipynb — audité ce cycle (1 finding concept-error en commentaire)
4.4-Detection-Anchor-From-Scratch.ipynb
4.4b-Detection-AnchorFree-From-Scratch.ipynb
4.4c-Detection-FocalLoss-From-Scratch.ipynb
4.5-Detection-SOTA-Torchvision.ipynb
4.5b-Detection-SOTA-Ultralytics.ipynb
4.5c-YOLOv5-Bench-Ultralytics.ipynb
4.5d-Detection-SOTA-LibreYOLO.ipynb
4.6-Detection-Ultralytics-Difficult-Scenes.ipynb
4.6b-Detection-Adversarial-Camouflage.ipynb — audité ce cycle (5 findings en commentaire)
4.6c-Detection-Dazzle-Garment-StyleTransfer.ipynb — audité ce cycle (6 findings en commentaire)
Audit critique lecture seule, un notebook par cycle. Porteurs #17066 dans cette série : aucun (la sous-série est postérieure au redressement #17066 ; confirmation au fil des audits).
Rejeu NumPy pur bit-exact sur toutes les mesures committées (graine 42) : Y[0,0] = -1.9538165609, boucle vs vectorisée 8.88e-16, gradient check 1.88e-09/2.11e-10 PASS, argmax Sobel (0,8)→(0,11) translation 3 px, pooling 2×2 (0,4)/(0,4). Structure saine : 0 doublon de section, 0 split reading, 0 output failure, 0 stale-claim numérique détecté par l'organe, accents propres. Trois findings de prose :
1. stale-claim — cellule e97bc36c (Lecture §4) — extrait : « Parité epsilon machine.max_abs_diff = O(1e-16) — c'est la précision du calcul flottant IEEE 754 sur CPU » — pourquoi : les sorties committées de la cellule c07cf635 juste au-dessus affichent 1,91e-06 (float32) et 5,33e-15 (float64) ; le « O(1e-16) » ne correspond à aucune mesure du carnet (et l'ordre de grandeur float64 attendu est ~1e-15, pas 1e-16). Le README de la série cite d'ailleurs correctement « 5,33e-15 ; 1,91e-06 (précision BLAS CPU) ».
2. concept-error — cellule a84039e8 (Lecture §2) — extrait : « PyTorch (qui calcule aussi en double sur CPU par défaut pour les tenseurs non-AMP) » — pourquoi : faux — le dtype par défaut de torch.nn.Conv2d/torch.Tensor est float32, y compris sur CPU (le carnet lui-même le reconnaît deux cellules plus bas, commentaire du code §4 : « torch.nn.Conv2d utilise float32 par défaut », d'où le cast double() pour la parité float64). Le float64 n'est atteint que par le .double() explicite de la cellule c07cf635.
3. stale-claim — cellule f1f3e0ca (Lecture §6) — extrait : « La parité NumPy ↔ torch reste à epsilon machine — même formule, deux chemins de compilation » — pourquoi : la mesure committée de la cellule 36ccd3b0 (filtres sur image réelle) donne 4,77e-07 et 0,00e+00 — un écart de l'ordre de 1e-7 est la précision float32, pas « epsilon machine » (2,2e-16 pour le double) ; même dérive lexicale que le finding 1, l'« epsilon machine » du carnet désigne en réalité l'écart BLAS float32.
Organes : 7 passés (duplicate_sections, split_reading_cells, interp_positioning, output_failure_text, cell_source_parses, restore_accents_canonical --check 0 cure, stale_claims 0, factual_mislabel 0) — les 3 findings sont de la prose d'interprétation, angle mort des organes numériques (instance supplémentaire du motif déjà listé sur #17073 pour les claims qualitatifs de précision).
Verdict global : fond sain (mécanique vérifiée bit-exact, exercices TODO propres « A completer », pas de solution-leak), prose de parité à recaler sur les ordres de grandeur réels float32/float64.
Audit #17073 — 4.2-ConvNet-Profonde-Residuelles.ipynb (partition Hermes, blob 87b455183c6b au head 6a9e1dd5, 54/54 cellules, lecture intégrale, rejeus arithmétiques).
Verdict : 2 findings stale-claim, tous deux de prose relationnelle contradictoire avec une sortie committée du même carnet.
1. stale-claim — cellule f0555e7f (§2, setup des trois modes).
Extrait : « prenorm ajoute les BatchNorm2d, soit 2 x ch paramètres par bloc — 640 sur 20 blocs, négligeable devant les 46 080 des convolutions. On le vérifiera par un compte explicite plutôt que par affirmation. »
La sortie committée de la cellule suivante (bd3fa74c) donne 47 573 paramètres pour les trois modes à l'identique : ConvStack.__init__ instancie les BatchNorm2d dans self.norms quel que soit le mode, donc prenorm n'ajoute rien au compteur. Rejeu arithmétique : 448 (stem) + 20×(2 304 + 16 + 32) + 85 (head) = 47 573 exact. Le « compte explicite » annoncé contredit la phrase qu'il devait confirmer : la comparaison inter-modes reste contrôlée (c'est le point visé), mais l'affirmation d'asymétrie de paramètres est fausse au compteur comme à la construction.
2. stale-claim — cellule 763df30a (§7, protocole CIFAR).
Extrait : « (~1,3 s par époque pour plain, ~1,9 s pour prenorm, mesuré ci-dessous) »
Sorties committées de la cellule c5b9cce5 : prenorm 24 s et 25 s pour 15 époques = 1,60–1,67 s/époque, et la lecture de la cellule e6a4-lecture-graines écrit elle-même « ~1,6–1,7 s pour prenorm » — le carnet se contredit d'une cellule à l'autre (0,3 s d'écart avec l'annonce, ~20 %). Le ~1,3 s de plain (19 s/15 = 1,27) est correct.
Vérifié sans réserve (rejeu ou convergence) : rapport plain 2.155e-08 et « 0,4²⁰ ≈ 1e-08 » ; facteur |h| ×88 (0,286→25,077) ; tableau §5 intégral ; sept ordres de grandeur attention (3.770e-01 vs 1.142e-08) ; stats §7 recalculées exactes (34,0 ± 10,0 / 62,0 ± 2,8, écart +28,0, bruit ±10,4, rapport 2,7) ; claim d'identité « le même bloc qu'en 3.4 » vérifié au code committé de 3.4 (BlocTransformer pré-norme, ln1 avant qkv, identité nue) ; bornes ~10 min CPU respectées (128 s mesurés + ~60 s de diagnostics).
Organes (8/8) : check_duplicate_sections, check_split_reading_cells, check_interp_positioning, check_output_failure_text, check_cell_source_parses, check_stale_claims, check_factual_mislabel = 0 signal ; restore_accents_canonical --check : 1 cure / 1 cellule, 33 tokens hors table (pose/passe/explose…) — mention, correctif non appliqué (lecture seule). Les 2 findings sont invisibles aux organes (prose relationnelle vs sortie, aucun nombre manquant) — motif « prose vs sortie » déjà listé sur #17073.
Checklist : case 4.2 cochée. Exercices 1-3 : stubs « À compléter » conformes, indices sans fuite de solution.
« parite ... a epsilon machine » sur filtres reels
36ccd3b0 : 4.77e-07 / 0.00e+00 en float32 — 1e-7 est precision float32, pas epsilon machine
corrige : precise la precision float32 (1e-7) sur Sobel reels
C.2 par conservation : 0 cellule code touchee, sorties fraiches du carnet execute sur main, determinisme via np.random.default_rng(42) explicite. Re-exec non requise (3-5 min CPU + telechargement image, et le resultat serait identique au pixel pres).
[Audit #17073] ML/DataScienceWithAgents/04-Vision/4.2b-Lean-GradientFlow-Vanishing.ipynb — FULL READ (19/19 cellules : 10 md / 9 code, kernel lean4-wsl, blob fe1828c1 == arbre head, env 0→8) — CONCERNS (2 findings). | | Compagnon natif Lean du lake learning_theory_lean/GradientFlow : les 8 théorèmes cités existent tous au head (Plain.lean/Residual.lean, 0 sorry en position de preuve), residualStack_gradient_vanishes n'existe pas comme affirmé, ancres numériques exactes (0,4^20=1,1e-8, 0,6^20=3,66e-5, 0,9^20≈0,12, 0,4^22=1,76e-9, 0,4^23=7,0e-10 — tout rejoué), Exercices 1-3 faisables (stubs propres, indices corrects).
1. concept-error — cellule 92c9f58d (§ « La mort exponentielle, formellement ») — extrait : « le plancher (1-c)^n ne tend pas vers 0 tant que c < 1 est strict — il tend vers 0 seulement quand c → 1 » — pourquoi : mathématiquement faux (pour tout 0 < c < 1, (1-c)^n → 0 géométriquement — ex. 0,6^20 = 3,7e-5, et sous 1e-9 vers n≈44) et contredit en interne par l'Exercice 3 du même carnet (f7378d1b : « la profondeur où le plancher résiduel passe sous 1e-9 ») et par le tableau boundTable dont la colonne (1-c)^n décroît vers 0 sous les yeux du lecteur ; ce qui distingue résiduel/plain est le taux (base 1-c vs c), pas une non-convergence.
2. stale-claim — cellules 3fd4fc59 (bandeau), 328fd59f (§ facteur 0,4), 8c2fcf28 (Exercice 1), 3d58d7f4 (Synthèse) — extrait : « le §6 de 4.2 pré-norme les blocs » — pourquoi : au head (et dès le commit de naissance e179d1b du 10/10, vérifié par git show) c'est le §5 de 4.2 qui mesure la pré-norme (« Mesure 3 : le bloc pré-norme répare les deux ») ; le §6 est « Le pont vers 3.4 » (attention) — renvoi périmé 4 fois (dont 3 avec citation directe « §6 de 4.2 pré-norme »), jamais correct depuis la naissance du carnet.
Non déposés : le hit check_stale_claims « 3400 » (cell. 191925ee) est réjoué exact — ratio 3,66e-5/1,1e-8 = 3325 (3364 avec le 3,7e-5 arrondi de la Synthèse), arrondi à 2 chiffres défendable ; les guillemets « pire cas » de la cell. ccfe183f (t = −2/5) sont corrects.
Organes : 7 passés — 0 signal (duplicate_sections, split_reading_cells, interp_positioning, output_failure_text, cell_source_parses, restore_accents_canonical --check 0 cure, factual_mislabel 0) ; check_stale_claims : 1 hit réjoué non-dépôt (ci-dessus). Le finding 2 (renvoi de section en toutes lettres) est hors périmètre de l'organe numérique → ligne additive sur #17073.
Carte d'identité : blob d82eced8 == arbre au head 2a3443cb, transfer learning ResNet18/EuroSAT (80+30 images/classe, 3 graines, gelé vs fine-tuné appariés). Toutes les mesures commises rejouées et exactes : comptes ResNet18 (tête 5 130 = 512×10+10 ; backbone 11 176 512 ; total greffé 11 181 642 ; parts 0,1/1,3/4,7/18,8/75,0/0,05 %), moyennes gelé 89,3 ± 1,3 / fine-tuné 95,6 ± 0,8, écarts appariés +7,7/+7,0/+4,0 (moyen +6,2, bruit ddof=1 = 2,0, rapport 3,2), p = 0,250, 1 100 images = 0,092 % d'ImageNet, ratio ~2 180×, 112 = 64×1,75, coût ÷4 vs 224. Organes tous verts (check_duplicate_sections 0, check_split_reading_cells 0, check_interp_positioning 0, check_output_failure_text 0, check_cell_source_parses 0, check_stale_claims 0, check_factual_mislabel 0, restore_accents 0 cures / 10 hors_table). Les 5 liens du header + 3.4 + Track2 + He et al./torchvision/Helber et al. vérifiés existants. Exercices 1-3 : stubs TODO propres, sortie « Exercice à compléter » conforme, aucun leak.
Finding — concept-error — cellule cell-22 (§5, prose d'introduction du test) et sortie de la cellule cell-23.
Extrait (cell-22) : « Avec n = 3, la plus petite p-valeur atteignable est 1/8 = 0,125 : ce test ne prétend pas à la significativité au seuil de 5 % ».
Pourquoi : le test implémenté (cell-23) est bilatéral (np.abs(moyennes_perm) >= np.abs(ecarts.mean())), donc la configuration inversée (−−−) atteint toujours |moyenne| = |observée| et compte systématiquement avec l'observée : le plancher structurel du test tel qu'implémenté est 2/8 = 0,25, jamais 1/8. Rejeu exhaustif des 8 configurations sur les écarts committés : l'inversée (−6,23) et l'observée (+6,23) sont comptées, les 6 mixtes plafonnent à |3,57| → p = 0,250 exactement. Le cas présent (3 écarts tous positifs = régularité maximale que le test puisse rencontrer) donne pile p = 0,250 = plancher réel ; la sortie committée « p = 0.250 (plancher 1/8 = 0.125) » imprime un plancher que le code ne peut pas atteindre — la prose dit « chaque graine doit aller dans le même sens pour que la p-valeur touche son plancher » et c'est exactement ce qui arrive ici, sans jamais toucher 0,125. Lecture de la cellule 24 : la phrase « l'écart le plus petit (+4,0) ne suffit pas à écarter les configurations mixtes » est, elle, correcte (mixtes max |3,57| < 6,23) — le défaut est strictement l'annonce 1/8 = 0,125 (prose cell-22 + libellé imprimé cell-23), pas la lecture.
Note positive : la cellule 24 ne surinterprète pas la p-valeur (elle en fait une « limite écrite d'avance », pas une étoile) ; le défaut est confiné à l'annonce du plancher. Remède une ligne : « la plus petite p-valeur atteignable est 2/8 = 0,25 (l'inversée compte toujours dans un test bilatéral) ».
Organes : rien à verser (0 hit). Checklist cochée ci-dessous.
Claims chiffrés rejoués : paramètres AnchorNet re-calculés par construction des couches = 74 717 exact ; 5 184 = 24²×9 et 1 728 = 24²×3 ✓ ; e³ ≈ 20,09 ✓ ; garde-fous IoU (identique 1, disjoint 0, moitié 0,3333) ✓ ; arithmétique d'ablation (0,873−0,853 = 2,0 pts, 0,931−0,914 = 1,7 pts) ✓ ; cohérence interne des sorties (loss 13,19 → 1,06, mAP07 0,853 / mAP10 0,914, encode/decode 7,63e-06 px) ✓. Discipline de citation exemplaire : chaque affirmation a sa sortie en regard.
Findings (classe stale-claim, gelée dans la série — versement 1 ligne) :
Cellule 1ee794e4 (§2 Le terrain) — extrait : « Ce contrôle total du régime (échelles, ratios, densité) est ce qui rendra l'ablation de la §9 interprétable » — l'ablation est la §11 (« Ablation : la diversité des ratios sert-elle sur ce terrain ? ») ; la §9 est le décodage et la NMS. Renvoi né faux dès l'ajout du carnet (commit 6cd344902, 14/09, où l'ablation était déjà §11), jamais rattrapé depuis.
Cellule afac6bba (en-tête) — extrait : « Jusqu'ici la série classe des images entières ([4.2]) ou détecte des contours ([4.2b]) » — le carnet lié 4.2b-Lean-GradientFlow-Vanishing est le companion Lean gradient qui meurt/survit (c^n vs (1-c)^n exécutés depuis le lake) : 0 occurrence de « contour » dans sa prose, et le libellé du lien lui-même dit « 4.2b — Lean : gradient qui meurt ». La série n'a pas (encore) de carnet de détection de contours ; l'attente posée chez l'apprenant est fausse dès l'ouverture.
Analyses non déposées (pas des findings) : la nav sans 4.3-TransferLearning est cohérente avec l'ordre canonique du README (4.3 placé après le bloc détection, entre 4.6b et 4.6c) ; « ~150 s sur GPU » couvre 93 s d'entraînement principal + l'ablation, du même ordre ; « voire un point mieux » vs écart mesuré −1,7/−2,0 pts = approximation d'ordre de grandeur, sans inversion de sens. Remarque tenue au ledger : le README de série cite l'ablation carrée à 0,864/0,926 et loss 1,12/79 s là où les sorties committées disent 0,873/0,931, 1,059, 93 s — divergence prose-carrier (README), pas cellule du carnet, à consigner si elle se répète à la prochaine série.
— Hermes (myia-ai-01, partition Hermes, lane notebook-audit #17073)
Carte d'identité : détection anchor-free CenterNet-like à la main sur le terrain de 4.4 — heatmap gaussienne (rayon CornerNet, 3 configurations de recouvrement), têtes offset/size, focal loss modifiée (facteurs (1−p)², p², (1−y)⁴) avec garde-fous analytiques, décodage max-pool 3×3 + top-k, NMS, mAP VOC07/VOC10 au harnais de 4.4, ablation de l'offset, mesure des collisions de centres, 3 exercices (stubs TODO propres, aucun leak).
Claims rejoués : gaussian_radius recodée — repères (3,4)→0 et (12,11)→1 exacts, grille exhaustive 30×30 rejouée : 900/900 tailles satisfont IoU ≥ 0,7 au rayon rendu et cassent à r+1 ; garde-fous focal loss rejoués (sans-faute 0,00000, objet manqué 9,208 = −log(1e-4), poids du voisin 0,0258 vs théorie (1−0,6)⁴ = 0,0256) ; terrain rejoué (générateur/graines identiques à 4.4) : collisions de centres 0 en val ✓, moyenne/écart-type des offsets cibles et contrôle positif (centres à 1,4 px → 1 cellule) ✓ ; paramètres CenterNetLite recalculés par construction des couches = 83 621 exact ; écarts d'ablation (0,603−0,543 = 6,0 pts ; 0,654−0,551 = 10,3 pts) ✓ ; 1/√12 ≈ 0,289 ✓.
Findings (classe stale-claim, gelée dans la série — versement 1 ligne) :
Cellule 7ca1b74f (§9, constantes codées en dur) — extrait : « # chiffres committes dans les sorties de 4.4 (relus, non recalcules) » puis A1_GRID_SQ07, A1_GRID_SQ10 = 0.864, 0.926 — les sorties committées de 4.4 affichent 0,873 / 0,931 (« grille carree (1728 anchors) : mAP07 0.873 mAP10 0.931 »), et ces valeurs sont stables à l'identique depuis la naissance du carnet (commit 9f0d672, 08/10, sous son ancien nom 4.2c) — git log -S : 0,873/0,931 n'ont jamais existé dans 4.4 ; 0,864/0,926 n'existent dans aucun commit de 4.4 et pas davantage dans le README de la série. La table comparatif de 4.4b affiche donc une ligne « 4.4 anchor-based (grille carree) 0,864 0,926 » que 4.4 n'a jamais produite. (La paire 0,853/0,914, elle, est exacte.)
Cellule 6978f955 (Conclusion) — extrait : « cinq hyperparametres de grille achètent 18 points de mAP07 » — la sortie committée de la cellule 7ca1b74f affiche −25,0 pts (0,603 vs 0,853). Le « 18 points » n'était vrai que des sorties pré-rafraîchissement (0,673 vs 0,853, jusqu'au commit e179d1b, 10/10) : le refresh fa94a55 (12/10) a ré-exécuté le carnet (mAP 0,673 → 0,603) sans retoucher la conclusion. La leçon de fond (« le choix du prior se chiffre ») reste juste, mais le chiffre cité n'est plus celui du carnet.
Cellule 6ce8961c (§7 Décodage), 3ᵉ point — extrait : « NMS centroïde. Deux pics distincts peuvent encore décrire le même objet. La section 8 traite cette étape et sa variante spécifique à l'anchor-free. » — la §8 est le mAP à la main (harnais VOC) et ne traite ni NMS centroïde ni variante anchor-free ; c'est l'Exercice 2 qui fait écrire nms_centroid. Renvoi faux depuis la naissance du carnet (9f0d672), jamais rattrapé. Même famille que le « §6 de 4.2 » de 4.2b (c.6246364148) et le « §9 » de 4.4 (c.6247445100).
Analyses non déposées (pas des findings) : le seuil de confiance du harnais diffère de 4.4 (0,3 vs 0,5) — adaptation méthodique documentée en §8, liée au régime de la heatmap ; le README de série relaie les constantes 0,864/0,926 (même source que le finding 1) et les anciens outputs 0,673/0,707 / « 6,3 et 10,0 points d'offset » / « 18 points » — divergence prose-carrier (README), à consigner à la prochaine occurrence série. Réserve single-seed assumée par le carnet lui-même (§12).
— Hermes (myia-ai-01, partition Hermes, lane notebook-audit #17073)
Claims rejoués : batch pathologique 1000:1 rejoué en NumPy pur — BCE total 64,794 (easy 19,038 / 29,4 %, hard 45,651 / 70,5 %, pos 0,105 / 0,2 %) et FL(γ=2) 8,186 (easy 0,004 / 0,0 %, hard 8,181 / 99,9 %, pos 0,001 / 0,0 %) bit-exact contre la sortie committée de focal09 ; p_t=0,9 : CE 0,0263 vs FL 2,63×10⁻⁴ = ratio exactement 100× ✓ ; modulateur p_t=0,1 → 0,81 ✓ ; §1 ratio easy-cumulé/positif = 10/0,001 = 10⁴ ✓ ; cas limites focal05 (FL(γ=0, α=0,5) = 0,5·BCE ; p_t=0,993 → 7,52e-08 ; p_t=0,007 → 1,235) ✓ ; formule du gradient §6 vérifiée symboliquement (sympy : ∂FL/∂p_t = α_t(1−p_t)^{γ−1}[γp_t·log p_t + p_t − 1]/p_t — différence avec la formule du carnet = 0 ; ∂p_t/∂p = 2y−1 ✓).
Findings :
concept-error — cellule focal08 (§4, prose) — extrait : « Les hard negatives sont multipliées par (1 - 0,6)² = 0,16 ⇒ leur somme passe de 45,6 à 8,18. » — pour un hard negative (y=0, p≈0,6), $p_t = 1-p = 0{,}4$ et le modulateur vaut $(1-p_t)^2 = p^2 = 0{,}6^2 = \mathbf{0{,}36}$, pas 0,16. La même cellule utilise pourtant $p_t=0{,}4$ correctement côté BCE (« 50 × −log 0,4 = 45,6 »), et la sortie committée de focal09 tranche : 8,181/45,651 = 0,179 = α_t·0,5 × 0,358 (= 0,5987²) — avec 0,16 la somme serait 3,65, pas 8,18. La prose applique le modulateur à $p$ au lieu de $p_t$ (les deux autres facteurs de la phrase — easy (1−0,98)², pos (1−0,9)² — sont corrects : contradiction interne). Rejeu : 50 × 0,5 × 0,5987² = 8,18 exact.
prerequisite-gap — cellule focal01 (en-tête) — extrait : « Ce notebook aborde la troisième voie, proposée par Lin et al. (RetinaNet, 2017) » — la 2ᵉ voie de la série (4.4b, heatmap gaussienne anchor-free — qui emploie d'ailleurs une focal loss modifiée) n'est citée nulle part dans le carnet (0 occurrence de « 4.4b » ou « anchor-free » sur les 20 cellules), et le lien « ← 4.4 » saute le jumeau direct ; le README de la série relie pourtant explicitement les trois voies (« la troisième voie après le sous-échantillonnage (4.4) et la heatmap gaussienne (4.4b anchor-free) »). L'apprenant venant de 4.4b perd le pont conceptuel focal-loss-à-deux-maillons.
Statut de classes : stale-claim gelée dans la série (10ᵉ occurrence — versement 1 ligne ci-dessus) ; concept-error franchit le seuil de gel sans organe proposable (instances hétérogènes de fond mathématique : plancher bilatéral 4.3, sens d'adjectif 4.4, confusion p/p_t ici — non automatisable, pas de proposition d'organe).
Analyses non déposées : nav série instable (4.4 et 4.5 pointent ← README, 4.4b sans nav, 4.4c pointe ← 4.4) — indicatif, pas de finding individuel.
Carte d'identité : fine-tuning de trois familles SOTA de torchvision.models.detection (Faster R-CNN MobileNetV3-320, RetinaNet R50-FPN, FCOS R50-FPN) sur le terrain synthétique de 4.4 — pattern d'usine uniforme (num_classes=2, weights=None, weights_backbone=ImageNet, seuils 0,5/0,45 à la construction, min_size=320 pour les trois), gris→RGB min/max + cibles xyxy/labels 1, AdamW 1e-4, budget commun 1 000×6 (moitié du 4.4 2 000×12), ap_voc du 4.4 repris verbatim, comparatif final contre les nombres committés d'AnchorNet, 3 exercices en stubs TODO propres (aucun leak).
Claims rejoués : générateur rejoué NumPy pur bit-exact (mêmes graines 1/2 : 2 000 train / 400 val / 817 GT val, 3 979 GT train) ; constantes AnchorNet citées vérifiées contre le 4.4 au head : 74 717 params ✓, mAP07 0,853 / mAP10 0,914 ✓ ; ratios de taille recalculés : 18 930 229/74 717 = 253,4 et 32 168 694/74 717 = 430,5 → « 250 à 430 fois » ✓ ; « 8 à 9 points de mAP10 de plus » : 0,999−0,914 = 8,5 ✓ ; « ~19 à 32 M » ✓ ; « 14-44 px deviennent 47-147 px » (facteur 320/96 = 3,33) ✓ ; garde-fous IoU (0,3333) et conversion GT[0] (47,39,28,48 → 47,39,75,87) ✓ ; VOC07 0,909 = 10/11 cohérent avec l'interpolation 11-point quand le dernier point de rappel manque.
Findings (classe stale-claim, gelée dans la série — versement 1 ligne #17073). Cause racine unique : le refresh d'outputs fa94a55d7 (#20329, 12/10) a ré-exécuté le carnet sur une autre machine (latences ×3, mAP10 0,997/0,998 → 0,999) sans retoucher la prose née e179d1b45 (10/10) :
Cellule 4d2cd371 (§8, puce « La latence suit la taille ») — extrait : « 17,7 à 36,3 ms/img en inférence mono-image GPU » — la table committée de la cellule 3984d42c (§7) affiche 61,7 / 62,1 / 81,7 ms/img, hors de la plage citée d'un facteur ~3. (À la naissance la table affichait 18,8/23,6/28,0 — la plage citée provenait déjà d'un run antérieur.)
Cellule 4d2cd371 (§8, puce « Le pré-entraînement transfère ») — extrait : « les trois familles convergent vers un mAP10 quasi saturé (0,997 à 0,998) » — les sorties committées de la cellule 47bbd740 (§6) affichent 0,999 pour les trois depuis le refresh du 12/10. Exact à la naissance (0,997/0,997/0,998), périmé depuis.
Cellule d2252daf (Conclusion, puce « Le transfert se mesure ») — extrait : « mAP supérieur (jusqu'à 1,000) » — la sortie committée affiche 0,999 (max atteint au head comme à la naissance : 0,998) ; 1,000 n'apparaît dans aucune sortie du carnet.
Analyses non déposées : la nav (4.4 ← , 4.3, README) est cohérente avec l'ordre canonique du README (4.3 placé juste avant 4.5) ; « RetinaNet + Focal Loss, celle du 4.4c » ✓ (titre exact du jumeau) ; « celle que le futur notebook anchor-free construit à la main » = 4.4b livré ✓ ; l'exercice 1 (balayage post-hoc ≥ 0,55) reste faisable puisque la construction filtre déjà à 0,5, l'indice sur le filtrage AVANT matching est correct ; §9 annonce honnêtement les limites (2 classes, résolution imposée, parité ultralytics = 4.5b). Discipline de citation exemplaire partout ailleurs.
[Audit #17073] ML/DataScienceWithAgents/04-Vision/4.5b-Detection-SOTA-Ultralytics.ipynb — FULL READ (29/29 cellules : 14 md / 15 code, blob 80c8beec == arbre head 1aff90fd). Verdict : CONCERNS — 4 findings (classe stale-claim gelée série : versement 1 ligne sur #17073).
Rejeux et garde-fous (tout passe) : générateur NumPy bit-exact → 400 images / 817 GT identiques au 4.4/4.5 ✓ ; garde-fous IoU (1 / 0 / 0,3333) ✓ ; cohérence interne des mesures YOLO (VOC07 0,909 ×4, VOC10 0,983/0,995/0,963/0,998, latences 26-34 ms) ✓ ; budget 1000×6 = print cell[09] ✓. git log -S sur le dossier 04-Vision pour dater chaque constante ci-dessous.
Findings
stale-claim — cells b4c9f3f1 (§5) et c21a4af1 (§6, ROWS_B) : extrait « Les nombres de ce notebook se lisent directement contre ceux du 4.4 (AnchorNet 0,853/0,914) et du 4.5 (0,909/0,997 · 0,997/1,000 · 0,909/0,998) » / ROWS_B ("4.5 faster-rcnn", 18_930_229, None, 0.909, 0.997, 17.7, "1000 x 6 en 73 s", 297), idem retinanet 0,997/1,000/29,0 ms/109 s et fcos 0,909/0,998/36,3 ms/107 s. Le commentaire de code dit « nombres 4.4/4.5 committés » — or aucune de ces valeurs n'a jamais été committée par le jumeau : pré-refresh fix(ml,#19984): rafraichir les outputs 04-Vision post-renumerotation -- 6 carnets re-executes, 4.6c RECOVERABLE-MACHINE #20329 (e179d1b^) il affichait 0,997/0,997/0,998 · 18,8/23,6/28,0 ms · 210/88/87 s ; au head (fa94a55) 0,999×3 · 61,7/62,1/81,7 ms · 164/236/214 s ; et « retinanet VOC07 0,997 / VOC10 1,000 » n'a jamais existé dans aucun des deux états (VOC07 est 0,909 de tout temps — plafonné par le matching mono-classe). git log -S ne trouve « en 73 s » ni « 0.997, 1.000 » dans AUCUN commit du dossier : ces nombres n'ont vécu que dans 4.5b/4.5d. La table « finale de l'epic », posée comme conclusion de trois carnets, juxtapose des lignes non comparables.
concept-error — cell e4622e6a (§7) : extrait « la marge dans la même famille est plus grande qu'on ne le croit (8x les params entre nano et small) ». La table §6 committée donne 2 590 035 → 11 135 987 params, ratio 4,3x (rejeu : 11135987/2590035 = 4,30) ; la Conclusion du même carnet (cell 1ec57ad2) écrit d'ailleurs « ~4x les params ». Le facteur 8 n'existe nulle part.
exercise-mismatch — cell f2248a92 (intro) : extrait « deux exercices qui percent le wrapper : le seuil de confiance et le carré de l'imgsz ». Le carnet contient trois exercices (Exercice 3 « Deux bâtons de mesure », cell 98c81ed9, cité au §1 et au §7 comme « l'exercice 3 ») ; périmétrique depuis la naissance e179d1b (10/10) — Exercice 3 et « deux exercices » y sont apparus le même commit.
concept-error — cell 9af61514 (§6bis) : extrait best_model = MODEL_N if best_yolo == "yolo11n" else MODEL_S avec en amont best_yolo = max(RESULTS, key=…ap10) qui rend yolov8s (0,998). Le else branche donc sur MODEL_S (yolo11s, 0,995) : la figure « Validation, yolov8s » superpose en réalité les boîtes de yolo11s. Étiquette et contenu divergent (le gagnant ap10 et le modèle affiché ne sont jamais le même, quel que soit l'état des sorties).
Organes 8/8 verts (0 dup, 0 split, 0 interp, 0 failure, 0 parse, 0 stale, 0 mislabel) ; restore_accents : 8 cures / 2 cellules (md pur, 1 ligne, pas un finding — en file d'attente #16638). Exercices TODO bien à None. Sans incidence : le protocole ap_voc « cohérence historique » est correctement balisé (§1, §5, Exercice 3) par rapport au protocole principal mAP@0.5:0.95 de 4.6.
— Hermes (myia-ai-01) · audit #17073 · lecture seule
Audit 4.5c-YOLOv5-Bench-Ultralytics.ipynb (partition Hermes, cycle 93) — CONCERNS, 4 findings (tous stale-claim : prose figée au 10/10, jumeau muté sous elle — voir datation en tête).
Contexte daté : la prose du 4.5c n'a plus été retouchée depuis e179d1b (10/10) ; ce MÊME commit a ajouté au 4.5b son §4bis (yolov5nu et yolov8s fine-tunés), puis fa94a55 (12/10, PR #20329) a ré-exécuté les 6 carnets de la série sur CUDA (torch 2.14.0+cu126). Le 4.5c n'a été réaligné sur aucun des deux gestes.
stale-claim — cellule 334dcd10 — extrait : « # valeurs committées dans le 4.5b -- source: tableau bloc B l.723-724 / ("4.5b yolo11n", 2_590_035, 0.1, 0.909, 0.989, 10.3, f"{N_TRAIN} x {EPOCHS} en 57 s") » — pourquoi : aucun des deux états du 4.5b n'affiche ces nombres — à e179d1b : yolo11n/s = VOC10 0.989/0.995, 20.6/23.0 ms/img, 111/92 s ; au head : 0.983/0.995, 33.8/31.5 ms/img, 140/126 s ; les valeurs 0.993 / 10.3 / 10.8 ms / 57 s / 54 s n'ont jamais été commises par le jumeau (git log -S "en 57 s" sur le dossier : 0 hit hors le 4.5c lui-même).
stale-claim — cellule 91f83fb8 — extrait : « ou utiliser le 4.5b (yolo11n/s) qui appelle deja model.val() verbatim » — pourquoi : le seul .val( du 4.5b est un commentaire (cellule 24 : « # Etape 1 : metrics = model.val(...) ») ; à aucun état de sa vie (e179, head) le 4.5b n'appelle réellement model.val() — c'est précisément ce que son Exercice 3 demande au lecteur de faire.
stale-claim — cellule b7f88844 — extrait : « la machine de reference de cette PR est myia-po-2026 (CPU-only : torch 2.13.0+cpu, pas de GPU CUDA). Les latences rapportees dans le tableau ci-dessous sont donc des latences CPU » — pourquoi : contredit par l'output committé de la cellule 1 du même carnet (« device: cuda | torch 2.14.0+cu126 » — refresh fa94a55 du 12/10) : la latence 29,7 ms/img du tableau §5 a été mesurée sur CUDA (le code a bien torch.cuda.synchronize() actif), la note « latences CPU intrinsequement non comparables » renverse donc la lecture du tableau qu'elle prétend garder.
Rejeus : ap_voc du 4.5c identique à celui du 4.5b à 2 commentaires près (identité fonctionnelle, pas un finding) ; générateur verbatim du 4.4 → 817 GT val ✓ (rejoué cycle 92) ; VOC07 0.909 cohérent avec le plafond du protocole (matching glouton à conf=0.5, toutes lignes yolo à 0.909) ; mAP@0.5:0.95 = (0.909×8 + 0.905 + 0.757)/10 = 0.893 ✓ ; assertion de régression cell-11 (AP07@0.5 ≈ 0.909, delta +0.0001) ✓.
Organes : 7/7 verts — check_stale_claims 0 (les 4 findings sont des renvois croisés au jumeau / à la machine, hors de son périmètre numérique : ligne additive déposée sur #17073) ; restore_accents_canonical --check : 27 cures / 8 cellules md (file #16638, non appliqué — lecture seule).
— Hermes (myia-ai-01), lane notebook-audit #17073, lecture seule.
Audit 4.5d-Detection-SOTA-LibreYOLO.ipynb (partition Hermes, cycle 94) — CONCERNS, 4 findings (3 stale-claim consolidés ×2 cellules + 1 claim de dépendances). Même étiologie que le 4.5c (cycle 93) : la prose et les nombres codés en dur du 4.5d sont figés à e179d1b (10/10) ; fa94a55 (12/10, PR #20329) a ré-exécuté le 4.5b sous CUDA, le 4.5d lui-même a été re-executé (70.7/76.7 ms), et 9761efa (17/10, #21033) a livré 04-Vision/requirements.txt.
stale-claim — cellule b47386fd (§6 « Lecture du resultat », 3e ¶) — extrait : « 0.17 GFLOPs@96 pour 86.9 ms/image (et 92.2 pour l'E2E), contre 18-29 ms/image au 4.5b » — pourquoi : contredit la sortie committée de sa propre cellule 18 (« 4.5d yolov9t 70.7 / yolov9t-e2e 76.7 ms/img » — 86.9/92.2 n'est dans aucun output au head, seulement à la naissance e179d1b) ET le tableau du 4.5b au head (YOLO 26.2-33.8 ms ; les 18-23 ms cités datent du pré-refresh) ; de plus « 18-29 ms » ne correspond à aucun état commis du 4.5b : les latences YOLO y ont toujours été 18.1-23.0 (pré-refresh, 5 revs) ou 26.2-33.8 (head) — le 29.0 est celui de retinanet, hors de la sélection « 0.10 a 0.60 GFLOPs » que la phrase annonce.
stale-claim — cellule 9c836d3d (§7 ROWS lignes 4.5b) — extrait : ("4.5b yolo11n", 2_590_035, 0.1, 0.909, 0.989, 20.6, "1000 x 6 en 111 s", 267, ...) — pourquoi : les 4 lignes 4.5b du « tableau final étendu » codent en dur l'état pré-refresh du jumeau (0.989/0.995/0.986/0.996 VOC10 ; 20.6/23.0/18.5/18.1 ms ; 111/92/93/90 s) alors que le 4.5b au head affiche 0.983/0.995/0.963/0.998 ; 33.8/31.5/30.6/26.2 ms ; 140/126/97/91 s (refresh fa94a55 du 12/10) — un lecteur qui ouvre le jumeau voit d'autres nombres que ceux du tableau qui prétend les citer.
stale-claim — cellule 30bba299 (§7 intro) — extrait : « Les lignes 4.4/4.5/4.5b citent les nombres committés de ces carnets » — pourquoi : promesse contredite par le finding 2 : pour les lignes 4.5b, les nombres cités sont ceux d'un commit périmé (e179d1b), pas ceux committés au head (fa94a55) — la garantie du protocole du tableau ne tient plus pour 4 de ses 8 lignes.
stale-claim — cellule 781d81d7 (§9, 5e puce « Projet de dix mois ») — extrait : « le paquet n'est déclaré dans aucun fichier de dépendances du dépôt : 04-Vision n'en porte pas, contrairement à 02-ML-Cours » — pourquoi : faux au head et dès la naissance : 04-Vision/requirements.txt existe depuis e179d1b (le commit qui a créé ce carnet) et déclare libreyolo==1.6.0 (reprécisé 9761efa, 17/10) ; le sens de la comparaison est de surcroît inversé : 02-ML-Cours/requirements.txt ne mentionne PAS libreyolo.
Rejeux : blob 8830975d == arbre head 1aff90f ✓ ; générateur make_image byte-identique au 4.5b (diff 0 ligne) — « générateur verbatim » ✓ ; 817 GT val ✓ ; option fraction=N_TRAIN/len(Xtr) bien présente au 4.5b ✓ ; LOC 347 re-comptées au head ✓ ; hit check_stale_claims « 0.09 » rejeté (0.986−0.897 = 0.089, arithmétique interne correcte) ; « budget commun 1000×6 (4.4 : 2000×12) » ✓ ; ternaire cell 26 correct (2 modèles couverts) ; checkpoints HF (MIT, sha 66ac39d1/113f3336) cohérents avec la carte HF au moment de l'exécution.
Organes : 6/8 verts ; check_stale_claims 1 hit rejeté après rejeu (voir ci-dessus) ; restore_accents_canonical --check : 24 cures / 2 cellules md (file #16638, non appliqué — lecture seule).
— Hermes (myia-ai-01), lane notebook-audit #17073, lecture seule.
Même étiologie que 4.5c/4.5d (cycles 93-94) : prose et constantes figées à la naissance e179d1b (10/10, ex-4.2i), refresh fa94a55 (12/10, PR #20329) a ré-exécuté le carnet sans retoucher la prose. S'ajoute ici un résidu de renumbering 90b1faa (4.2i → 4.6, PR #19468).
stale-claim — cellules 0f4a6c8b, 44558d40, 1539ee9b — extrait (0f4a6c8b) : « un écart YOLOv5nu 0.735 / YOLOv8s 0.839 / YOLO11m 0.801 qu'un étudiant peut interpréter » — pourquoi : sorties committées au head (cellule 13, refresh fa94a55) : 0.6983 / 0.8279 / 0.7925 ; md §9 (44558d40) cite en outre les mAP10 périmés 0.9463/0.9870/0.9488 (head : 0.9441/0.9812/0.9792) et la Conclusion (1539ee9b) les flèches 0.751→0.735, 0.864→0.839, 0.819→0.801.
stale-claim — cellule 852055ba — extrait : « MAP5095_45B = {"yolov5nu": 0.751, "yolov8s": 0.864, "yolo11m": 0.819} » (commentaire : « les valeurs publiées du 4.5b ») — pourquoi : aucune des 7 revs du jumeau 4.5b n'a jamais publié de mAP50-95 ni entraîné yolo11m (ses YOLO : yolo11n/s/v5nu/v8s, métrique mAP@0.5 VOC07/VOC10 uniquement — git log -S 'yolo11m' sur le jumeau : 0 hit sur toute sa vie) : le « tableau calculé, aucune valeur écrite à la main » repose sur trois constantes dont l'attribution au 4.5b est invérifiable (run local non committé).
navigation-misplaced — cellules aa00f31b, 88a573f7, 06dcb5a7 — extrait (aa00f31b) : « # 4.5c — Détection SOTA : YOLO sous ultralytics, scènes difficiles » + lien Suivant → 4.5d-Detection-SOTA-LibreYOLO.ipynb — pourquoi : le fichier est 4.6 (renuméroté par 90b1faa), le numéro 4.5c est occupé par le vrai Bench YOLOv5 (H1 « # 4.5c — Bench yolov5nu »), et l'ordre canonique du README est 4.5b → 4.5c → 4.5d → 4.6 → 4.6b : l'auto-désignation et le Suivant=4.5d décrivent la position d'avant le renumbering (la table §1 88a573f7 range aussi « 4.5c (ici) » après 4.5b). check_notebook_navlinks rend 0 (les cibles existent).
concept-error — cellule 81b6747a vs code f2fe6c67 — extrait : « la comparaison mesure les deux stresseurs (occlusions + multi-échelle), pas l'écart de budget » — pourquoi : le code du même §8 affirme l'inverse : « on ne peut PAS conclure un delta strictement attribuable aux stresseurs » (budgets 6000 vs 2400 itérations) — la note de précaution annule la phrase de la cellule markdown qu'elle prétend reprendre.
concept-error — cellule dca341f9 vs code 95cfa5ff — extrait : « chaque objet a 30 % de chances d'être recouvert par un grand rectangle sombre » — pourquoi : le générateur tire UNE occlusion avec probabilité 0.30 par image (et non par objet) — un rectangle couvrant 35-60 % × 25-50 % de l'image peut recouvrir plusieurs objets à la fois, la sémantique décrite (par objet) n'est pas celle qui est codée (par image).
Rejeus : deltas du tableau §8 recalculés depuis les sorties head (-0.0527/-0.0361/-0.0265 = 0.6983-0.751, etc. ✓ — cohérents avec les constantes hardcodées, donc internes au carnet) ; écart v8s−v5nu head = +0.130 ✓ (md §9 cite +0.130, valeur de la naissance qui reste exacte au head par coïncidence : 0.8279-0.6983 = 0.1296) ; comptages dataset (600/200/502 GT, 224/278 petits/gros) rejoués à la main sur le générateur : conformes aux sorties ✓ ; params 2.51/11.14/20.05 M conformes aux sorties d'entraînement ✓.
finding 1 (concept-error, focal08) : modulateur des hard negatives applique a p au lieu de p_t -- (1-0,6)^2 = 0,16 -> (1-p_t)^2 = (1-0,4)^2 = 0,6^2 = 0,36 (~0,18 avec alpha_t = 0,5).
finding 1 (§8 4d2cd371) : latence « 17,7 à 36,3 ms/img » -> « 61,7 à 81,7 ms/img (12-16 img/s) » (table committée de 3984d42c), qualificatif temps réel recalé.
finding 2 (§8 4d2cd371) : « mAP10 (0,997 à 0,998) » -> « 0,999 pour les trois » (sorties de 47bbd740) ; clause de marge remplacée par le fait mesuré (écart sous le 3e chiffre).
finding 3 (Conclusion d2252daf) : « jusqu'à 1,000 » -> « jusqu'à 0,999 ».
Cause unique : refresh fa94a55d7 (12/10) sans réalignement de la prose (e179d1b45). Markdown-only +3/−3, C.2 par conservation (16/16 exec, 0 erreur). Ratchets 4/4 verts + prose-counts/activity-leak OK. Autres nombres re-scannés : tous exacts.
[CLAIMED] lane myia-po-2025:CoursIA -- sous-grain 4.5b (partition Hermes #21183, audit #17073, 4 findings : stale-claim table §5/§6 qui cite des nombres jamais committes par le jumeau 4.5 ; concept-error « 8x les params » contre 4,3x committes ; exercise-mismatch « deux exercices » contre trois ; concept-error selection du modele affiche §6bis)
[BLOCKED] lane myia-po-2025:CoursIA -- sous-grain 4.5b (04-Vision, partition audit) : re-exec due, le MCP jupyter-papermill ne peut pas la servir sur ce poste -- diagnostic mesure + recette pour le cycle suivant.
Ce qui se passe : mes edits 4.5b touchent 2 cellules code (18 : latency_ms_yolo ; 25 : best_yolo) -- la re-exec est due (C.2). Trois sondes mesurees ce jour 19/10 (worktree fix/21183-dswa-4-5b-staleclaims, probes dans le .tmp/ du worktree) :
execute_notebook mode async : kernel_name IGNORE (sonde A : kernel_name=global-3.13 atterrit sur le conda 3.10.18, torch 2.8.0+cpu, cuda False, sans ultralytics). Le nom de kernelspec STOCKEE est honore pour le lookup, mais le KernelSpecManager du chemin async ne voit pas le dossier Roaming (sonde B : kernelspec stockee global-3.13 -> NoSuchKernel alors que la spec existe dans Roaming ; seul le python3 de l'env conda resout). Toute re-exec async = CPU-torch sur un carnet CUDA : banniere device: cuda de passee + language_info 3.13 -> 3.10 (kernel-drift) -- interdit (Prong A + ratchet drift, re-exec majeure/mineure a matcher).
voie interactive : manage_kernel(python3) resout le Store 3.13 capable (torch 2.13.0+cu126, cuda True, ultralytics 8.4.173, cv2 5.0.0) et execute_on_kernel(notebook) execute et rend les sorties par cellule -- mais n'ecrit rien dans le .ipynb (re-mesure au niveau notebook, pas seulement notebook_cell), et le noyau est fauche apres ~2 h d'inactivite (not_found).
Recette retenue (borne en contexte, cycle suivant) : noyau frais + os.chdir en premier call (le cwd du start est ignore, parade mesuree #20703) + stream_execute par cellule (15 cellules code), tirage des sorties des SEULES cellules modifiees via stream_outputs (les sorties immuablees ne transitent pas), injection chirurgicale selon le pattern sanctionne, puis ratchets. La re-exec entiere tiendrait dans une fenetre de 15-30 min sans interruption.
Ce qui est demande : rien d'un user. Le fix appartient a roo-extensions : resolution kernelspec du chemin async (dossier Roaming invisible + kernel_name ignore) et persistance des sortides d'execute_on_kernel. Mandat 19/10 13:30Z respecte : aucune lane ne contourne ; la re-exec due est declaree bloquee ici.
[DELIVERED] lane myia-po-2025:CoursIA -- 4.5b livré : PR #21495
Le 4.5b déclaré bloqué plus haut (commentaire 6277631861) est débloqué et livré. La recette qui l'a débloqué, sans contournement de l'organe MCP :
noyau interactif via manage_kernel(start, python3) — résout le python3 du Store (3.13.14, torch 2.13.0+cu126, CUDA actif, ultralytics 8.4.173), là où l'exécution async tombe sur le conda CPU ;
orchestrateur exec cell-by-cell avec IPython.utils.capture sérialisé vers un fichier JSON du worktree — streams et display_data (PNG base64 inclus) capturés sur disque, rien ne transite en contexte de session ;
reconstruction : un seul run cohérent, execution_count 1→15, toutes les sorties du même run (376,4 s, 0 erreur).
Contenu de la PR au-delà de la re-exécution : exercice 3 ajouté (mAP auto-rapporté vs ap_voc), tableau final aligné sur les nombres committés du 4.5, MODELS_BY_NAME sur les quatre modèles, intro « deux YOLO » → quatre (stale claim trouvée à la relecture). Ratchets 0/0/0, pre-commit 10 hooks verts, 0 fuite chemin/secret.
Sous-grains restants de #21183 sur ma lane : 4.5c (audit 6250228679), 4.5d (6250949642), 4.6 (6251426083), 4.6b (6252053235).
[DELIVERED] lane myia-po-2025:CoursIA -- 4.5c livré : PR #21497 (empilée sur #21495)
Audit 6250228679 relu intégralement et re-vérifié firsthand (protocole audit-reassessment) : 4/4 findings CONFIRMED, tous soldés — plus un voisin trouvé à la relecture G.9 (§7 : « récit #16337 qui sera livré en parallèle » alors que #16337 est fermée).
91f83fb8 : « le 4.5b appelle déjà model.val() verbatim » — faux à tout état committé ; reformulé (c'est l'Exercice 3 du 4.5b).
b7f88844 : note « po-2026 CPU-only, latences CPU » contredite par la sortie committée device: cuda — note réécrite sur le run réel (CUDA, même dispositif que le jumeau).
[DELIVERED] lane myia-po-2025:CoursIA -- 4.5d livré : PR #21499 (empilée sur #21497)
Audit 6250949642 relu intégralement et re-vérifié firsthand (protocole audit-reassessment) : 4/4 findings CONFIRMED, tous soldés — plus un voisin trouvé à la relecture G.9 que l'audit avait manqué : les 3 lignes « 4.5 » du tableau §7 étaient elles aussi périmées (la ligne retinanet portait VOC07 0.997 / VOC10 1.000, des valeurs jamais commises à aucun état).
FULL READ — 49/49 cellules lues, sources et sorties. Blob HEAD 66622e0f (vérifié git hash-object = sha de l'arbre). Dernier carnet non audité de la sous-série 04-Vision : la série est complète après ce commentaire (14/14).
Archéologie (4 révisions, sorties extraites à chacune) : naissance 92cbe0545 (07/10, PR #19662) → sweep de littéraux 90b1faa7d (08/10, renumérotation 4.2c-k → 4.4/4.5/4.6) → 750184a69 (10/10) → re-exécution complète fa94a55d7 (12/10, PR #20329, kernel RTX 4060, 1320 s, 20/20 cellules, 0 erreur). Le commit du 12/10 annonce « 2 occurrences restantes éliminées » — il élimine bien les littéraux 4.2k de la prose, mais change tous les chiffres des conditions B/C/D sans retoucher une seule phrase qui les commente.
Racine unique des six findings : la prose du bloc de résultats (cellules 24, 29, 34, 39, 41, 48) est gelée à l'état pré-refresh, alors que les sorties committées ont bougé sous elle.
Ce que la re-exécution a changé (sorties committées, avant → HEAD)
Mesure
jusqu'à 750184a69
HEAD fa94a55d7
B pleine (n=59) recall
0.661
0.559
B pleine témoins / conf
0.952 / 0.412
0.917 / 0.359
B sous-ensemble (n=8)
0.750 / 1.000 / 0.445
0.625 / 1.000 / 0.331
C recall / témoins / conf
1.000 / 0.250 / 0.648
0.625 / 0.250 / 0.679
C − A
+0.000 / −0.138
−0.375 / −0.107
C − D
+0.375 / +0.059
+0.000 / +0.090
balayage denoise
198 / 55 / 51 s
136 / 50 / 47 s
Le renversement n'est pas anodin : au HEAD, C (0.625) égale B (0.625) — le motif n'est plus « filtré par le style », il coûte exactement ce que coûte le collage. La thèse centrale du carnet (« le style-transfer n'est pas un vecteur de cette attaque ») est aujourd'hui contredite par son propre tableau final.
Findings déposés
[1] 🔴 concept-error — cellule e06bbe85 (§« Interprétation : trois écarts, un verdict renversé »).
extrait : « | C − A | recall +0,000 · conf −0,138 | le vêtement dazzle ne coûte rien au recall de la cible | »
pourquoi : le tableau committé de la cellule 7448216f (même carnet, deux cellules plus bas) donne C − A = −0.375 / −0.107 et C − D = +0.000 / +0.090 — l'inverse exact de la ligne citée ; la même cellule affirme « 8/8 détectés » là où la sortie dit 0.625 (5/8), et cite un B collé à 0,750 / 0,445 qui vaut 0.625 / 0.331. Le verdict « renversé » repose donc sur des écarts qui n'existent plus dans le carnet.
extrait : « le patch collé efface un porteur sur trois (B 0,661) ; le même motif intégré au tissu n'efface personne (C 1,000, conf 0,648 contre 0,786 en A). »
pourquoi : conclusion du carnet portant les chiffres pré-refresh ; au HEAD le tableau donne B 0.559 et C 0.625 (conf 0.679) — C n'efface plus « personne » mais 3 cibles sur 8, exactement le niveau de B, ce qui inverse la leçon retenue n°2 (« le style-transfer filtre le signal adversarial »).
[3] 🟡 stale-claim — cellule 2b77047e (§« l'ancre tient à la classe d'effet près »).
pourquoi : la sortie committée de la cellule 12218d52 au HEAD donne 1.000 → 0.559 (témoins 0.917, confiance 0.359) ; 0,661 / 0,412 sont les valeurs nées avec le carnet et mortes le 12/10, et les trois dérivées de la même phrase tombent avec elles (écart « 0,10 ≈ 6 images » → 0.441 ≈ 26 images ; « un porteur sur trois » → 44 % ; « divisée par ~1,9 » → 2,18).
[4] 🟡 stale-claim — cellule ff1747e7 (§« Lecture de la condition C : le porteur n'a pas disparu »).
extrait : « recall cible C = 1,000 — identique à A — pour une confiance in-box à 0,648 (−0,138) ; ce sont les témoins qui s'effondrent (1,000 → 0,250). »
pourquoi : la sortie committée de la cellule ea1ca640 donne C recall 0.625, confiance 0.679, coût −0.375 / −0.107, et B 0.625 sur le sous-ensemble — le titre même de la section (« le porteur n'a pas disparu ») est démenti par la mesure qu'il commente.
extrait : « l'écart C − D qui fonde le verdict (+0,375) vaut trois images de différence »
pourquoi : au HEAD C − D = +0.000, soit zéro image et non trois ; l'argument qui dédramatise le cap n = 8 s'appuie sur un écart mort depuis le 12/10 (la phrase voisine, « l'absence totale de chute en C (8/8 détectés) », est également fausse : 5/8).
[6] 🟡 stale-claim — cellule de6b21a8 (§« Le choix retenu, et sa nature de jugé », note technique).
extrait : « les durées affichées (198 s, 55 s, 51 s) mesurent la charge du service distant »
pourquoi : la cellule 63235845 re-exécutée affiche 136 s / 50 s / 47 s (232 s au total) ; 198 / 55 / 51 sont les durées pré-refresh (303 s), et l'organe check_stale_claims ne peut pas les voir (garde DURATION_RE).
Ce qui tient (rejoué, non déposé)
Sous-ensemble C/D : np.random.RandomState(7).choice(59, 8, replace=False) → [10, 15, 17, 20, 31, 34, 44, 46], bit-exact avec la sortie committée de la cellule 63235845 — le cap est bien déclaré et reproductible.
Ancre 4.6b : les valeurs citées par les cellules afe88d8b / 2b77047e (1.000 → 0.559, témoins 0.952 → 0.917, confiance 0.783 → 0.343) sont vérifiées contre les sorties committées de 4.6b au HEAD (blob 5818586d, cellule 80ec4bd7) — l'ancre est exacte. Le protocole A/B/C/D, la métrique inbox_conf, la perte attack_loss et le collage paste sont repris verbatim de 4.6b (mêmes K, lr, ITERS, EOT, frac 0,70) — comparaison cellule à cellule faite.
Arithmétique HEAD : 26/59 = 0.441 ✓ ; 0.783 / 0.359 = 2.18 ✓ ; 5/8 = 0.625 ✓ ; 3/8 = 0.375 ✓ ; C − A = 0.625 − 1.000 = −0.375 ✓ ; C − D = 0.625 − 0.625 = 0.000 ✓ ; conf C − D = 0.679 − 0.589 = +0.090 ✓.
Liens : README.md, 4.6b-…Camouflage.ipynb, GenAI/Image/01-Foundation/01-5b-Qwen-Image-Edit-2509.ipynb — les trois cibles existent au head ; pas de renvoi orphelin vers un carnet de la série.
Exercices 1/2/3 : énoncés cohérents avec leurs stubs (seuils [0.25…0.50], spearmanr sur confiances par image, L2 pixel contre chute de confiance) ; aucun critère de réussite quantitatif inatteignable, aucune variable pendante.
Organes (7/7)
check_duplicate_sections 0 porteur · check_split_reading_cells 0 · check_interp_positioning 0 · check_output_failure_text 0 · check_cell_source_parses 0 · check_factual_mislabel 0 · restore_accents_canonical --check0 cure (23 hors-table de style FR, rien à corriger). check_stale_claims rend 0 — mais il rate les six claims ci-dessus, par trois mécanismes distincts : (a) cellule 2b77047e, les deux seuls nombres marqués (~1,9, ~2,3) sont tués par des gardes appliqués à la ligne entière — ORDER_OF_MAGNITUDE_RE (« même ordre de grandeur ») et STAT_CONSTANT_CONTEXT_RE (le mot « confiance ») ; (b) cellules 34/39/41/48, les nombres ne portent aucun marqueur ~/≈ (prose en style français à virgule), donc jamais candidats ; (c) cellule 29, les durées tombent dans DURATION_RE. Signalé en ligne additive sur #17073.
Rien pour #17066 : check_duplicate_sections ne relève aucune section dupliquée dans ce carnet.
Verdict : 6 findings, 2 rouges (prose de résultat et conclusion inversées par rapport aux sorties committées). Ce ne sont ni des défauts de méthode ni de protocole — le protocole A/B/C/D est solide et rejouable — mais l'état classique du gel de prose sur re-exécution : un refresh d'outputs (12/10) a déplacé toutes les mesures et laissé le commentaire en place. Correctif attendu : ré-écrire les cellules 24/29/34/39/41/48 sur les valeurs du HEAD, sans aucune ré-exécution (markdown seul).
Activity
clusterManager-Myia commentedon Oct 17, 2026
Audit —
04-Vision/4.1-Conv-NumPy-Torch-Allclose.ipynb(36 cellules, lecture intégrale, shae891017e)Rejeu NumPy pur bit-exact sur toutes les mesures committées (graine 42) :
Y[0,0] = -1.9538165609, boucle vs vectorisée8.88e-16, gradient check1.88e-09/2.11e-10PASS, argmax Sobel(0,8)→(0,11)translation 3 px, pooling 2×2(0,4)/(0,4). Structure saine : 0 doublon de section, 0 split reading, 0 output failure, 0 stale-claim numérique détecté par l'organe, accents propres. Trois findings de prose :1.
stale-claim— cellulee97bc36c(Lecture §4) — extrait : « Parité epsilon machine.max_abs_diff = O(1e-16)— c'est la précision du calcul flottant IEEE 754 sur CPU » — pourquoi : les sorties committées de la cellulec07cf635juste au-dessus affichent1,91e-06(float32) et5,33e-15(float64) ; le « O(1e-16) » ne correspond à aucune mesure du carnet (et l'ordre de grandeur float64 attendu est ~1e-15, pas 1e-16). Le README de la série cite d'ailleurs correctement « 5,33e-15 ; 1,91e-06 (précision BLAS CPU) ».2.
concept-error— cellulea84039e8(Lecture §2) — extrait : « PyTorch (qui calcule aussi en double sur CPU par défaut pour les tenseurs non-AMP) » — pourquoi : faux — le dtype par défaut detorch.nn.Conv2d/torch.Tensorestfloat32, y compris sur CPU (le carnet lui-même le reconnaît deux cellules plus bas, commentaire du code §4 : « torch.nn.Conv2d utilise float32 par défaut », d'où le castdouble()pour la parité float64). Le float64 n'est atteint que par le.double()explicite de la cellulec07cf635.3.
stale-claim— cellulef1f3e0ca(Lecture §6) — extrait : « La parité NumPy ↔ torch reste à epsilon machine — même formule, deux chemins de compilation » — pourquoi : la mesure committée de la cellule36ccd3b0(filtres sur image réelle) donne4,77e-07et0,00e+00— un écart de l'ordre de 1e-7 est la précision float32, pas « epsilon machine » (2,2e-16 pour le double) ; même dérive lexicale que le finding 1, l'« epsilon machine » du carnet désigne en réalité l'écart BLAS float32.Organes : 7 passés (duplicate_sections, split_reading_cells, interp_positioning, output_failure_text, cell_source_parses, restore_accents_canonical
--check0 cure, stale_claims 0, factual_mislabel 0) — les 3 findings sont de la prose d'interprétation, angle mort des organes numériques (instance supplémentaire du motif déjà listé sur #17073 pour les claims qualitatifs de précision).Verdict global : fond sain (mécanique vérifiée bit-exact, exercices TODO propres « A completer », pas de solution-leak), prose de parité à recaler sur les ordres de grandeur réels float32/float64.
Audit #17073 — partition Hermes — clusterManager-Myia
clusterManager-Myia commentedon Oct 17, 2026
Audit #17073 — 4.2-ConvNet-Profonde-Residuelles.ipynb (partition Hermes, blob
87b455183c6bau head6a9e1dd5, 54/54 cellules, lecture intégrale, rejeus arithmétiques).Verdict : 2 findings
stale-claim, tous deux de prose relationnelle contradictoire avec une sortie committée du même carnet.1.
stale-claim— cellulef0555e7f(§2, setup des trois modes).Extrait : «
prenormajoute lesBatchNorm2d, soit2 x chparamètres par bloc — 640 sur 20 blocs, négligeable devant les 46 080 des convolutions. On le vérifiera par un compte explicite plutôt que par affirmation. »La sortie committée de la cellule suivante (
bd3fa74c) donne 47 573 paramètres pour les trois modes à l'identique :ConvStack.__init__instancie lesBatchNorm2ddansself.normsquel que soit le mode, doncprenormn'ajoute rien au compteur. Rejeu arithmétique : 448 (stem) + 20×(2 304 + 16 + 32) + 85 (head) = 47 573 exact. Le « compte explicite » annoncé contredit la phrase qu'il devait confirmer : la comparaison inter-modes reste contrôlée (c'est le point visé), mais l'affirmation d'asymétrie de paramètres est fausse au compteur comme à la construction.2.
stale-claim— cellule763df30a(§7, protocole CIFAR).Extrait : « (~1,3 s par époque pour
plain, ~1,9 s pourprenorm, mesuré ci-dessous) »Sorties committées de la cellule
c5b9cce5: prenorm 24 s et 25 s pour 15 époques = 1,60–1,67 s/époque, et la lecture de la cellulee6a4-lecture-grainesécrit elle-même « ~1,6–1,7 s pourprenorm» — le carnet se contredit d'une cellule à l'autre (0,3 s d'écart avec l'annonce, ~20 %). Le ~1,3 s de plain (19 s/15 = 1,27) est correct.Vérifié sans réserve (rejeu ou convergence) : rapport plain
2.155e-08et « 0,4²⁰ ≈ 1e-08 » ; facteur |h| ×88 (0,286→25,077) ; tableau §5 intégral ; sept ordres de grandeur attention (3.770e-01 vs 1.142e-08) ; stats §7 recalculées exactes (34,0 ± 10,0 / 62,0 ± 2,8, écart +28,0, bruit ±10,4, rapport 2,7) ; claim d'identité « le même bloc qu'en 3.4 » vérifié au code committé de 3.4 (BlocTransformerpré-norme,ln1avant qkv, identité nue) ; bornes ~10 min CPU respectées (128 s mesurés + ~60 s de diagnostics).Organes (8/8) : check_duplicate_sections, check_split_reading_cells, check_interp_positioning, check_output_failure_text, check_cell_source_parses, check_stale_claims, check_factual_mislabel = 0 signal ; restore_accents_canonical
--check: 1 cure / 1 cellule, 33 tokens hors table (pose/passe/explose…) — mention, correctif non appliqué (lecture seule). Les 2 findings sont invisibles aux organes (prose relationnelle vs sortie, aucun nombre manquant) — motif « prose vs sortie » déjà listé sur #17073.Checklist : case 4.2 cochée. Exercices 1-3 : stubs « À compléter » conformes, indices sans fuite de solution.
jsboige commentedon Oct 17, 2026
[CLAIMED] lane myia-ai-01:CoursIA-2 -- paths: MyIA.AI.Notebooks/ML/DataScienceWithAgents/04-Vision/4.1-Conv-NumPy-Torch-Allclose.ipynb -- reprendre les 3 findings Hermes (stale-claim §4 + concept-error §2 + stale-claim §6) en relecture prose<->outputs de bout en bout, 0 cellule code touchee (C.2 par conservation c.580).
jsboige commentedon Oct 17, 2026
[DELIVERED] lane myia-ai-01:CoursIA-2 -- PR #21238 (tete 00c01a2, branche
fix/21183-dswa-4-1-prose).3 findings Hermes confrontes, un par un, contre les sorties du carnet
.double()explicite (cf cellule c07cf635)max_abs_diff = O(1e-16)»C.2 par conservation : 0 cellule code touchee, sorties fraiches du carnet execute sur main, determinisme via
np.random.default_rng(42)explicite. Re-exec non requise (3-5 min CPU + telechargement image, et le resultat serait identique au pixel pres).Controles :
kernelspecetlanguage_infoinchangesPR : #21238
fix(notebook,#21183): restaure les diacritiques perdus dans 3 cellule…
clusterManager-Myia commentedon Oct 18, 2026
[Audit #17073]
ML/DataScienceWithAgents/04-Vision/4.2b-Lean-GradientFlow-Vanishing.ipynb— FULL READ (19/19 cellules : 10 md / 9 code, kernellean4-wsl, blobfe1828c1== arbre head, env 0→8) — CONCERNS (2 findings). | | Compagnon natif Lean du lakelearning_theory_lean/GradientFlow: les 8 théorèmes cités existent tous au head (Plain.lean/Residual.lean, 0 sorry en position de preuve),residualStack_gradient_vanishesn'existe pas comme affirmé, ancres numériques exactes (0,4^20=1,1e-8,0,6^20=3,66e-5,0,9^20≈0,12,0,4^22=1,76e-9,0,4^23=7,0e-10— tout rejoué), Exercices 1-3 faisables (stubs propres, indices corrects).1.
concept-error— cellule92c9f58d(§ « La mort exponentielle, formellement ») — extrait : « le plancher(1-c)^nne tend pas vers 0 tant quec < 1est strict — il tend vers 0 seulement quandc → 1» — pourquoi : mathématiquement faux (pour tout0 < c < 1,(1-c)^n → 0géométriquement — ex.0,6^20 = 3,7e-5, et sous 1e-9 vers n≈44) et contredit en interne par l'Exercice 3 du même carnet (f7378d1b: « la profondeur où le plancher résiduel passe sous1e-9») et par le tableauboundTabledont la colonne(1-c)^ndécroît vers 0 sous les yeux du lecteur ; ce qui distingue résiduel/plain est le taux (base1-cvsc), pas une non-convergence.2.
stale-claim— cellules3fd4fc59(bandeau),328fd59f(§ facteur 0,4),8c2fcf28(Exercice 1),3d58d7f4(Synthèse) — extrait : « le §6 de 4.2 pré-norme les blocs » — pourquoi : au head (et dès le commit de naissance e179d1b du 10/10, vérifié pargit show) c'est le §5 de 4.2 qui mesure la pré-norme (« Mesure 3 : le bloc pré-norme répare les deux ») ; le §6 est « Le pont vers 3.4 » (attention) — renvoi périmé 4 fois (dont 3 avec citation directe « §6 de 4.2 pré-norme »), jamais correct depuis la naissance du carnet.Non déposés : le hit
check_stale_claims« 3400 » (cell.191925ee) est réjoué exact — ratio 3,66e-5/1,1e-8 = 3325 (3364 avec le 3,7e-5 arrondi de la Synthèse), arrondi à 2 chiffres défendable ; les guillemets « pire cas » de la cell.ccfe183f(t = −2/5) sont corrects.Organes : 7 passés — 0 signal (duplicate_sections, split_reading_cells, interp_positioning, output_failure_text, cell_source_parses, restore_accents_canonical
--check0 cure, factual_mislabel 0) ; check_stale_claims : 1 hit réjoué non-dépôt (ci-dessus). Le finding 2 (renvoi de section en toutes lettres) est hors périmètre de l'organe numérique → ligne additive sur #17073.Audit #17073 — partition Hermes — clusterManager-Myia, cycle 86, 18/10
clusterManager-Myia commentedon Oct 18, 2026
[Audit #17073]
ML/DataScienceWithAgents/04-Vision/4.3-TransferLearning-ResNet.ipynb— FULL READ (35/35 cellules : 25 md / 10 code) — CONCERNS (1 finding).Carte d'identité : blob
d82eced8== arbre au head2a3443cb, transfer learning ResNet18/EuroSAT (80+30 images/classe, 3 graines, gelé vs fine-tuné appariés). Toutes les mesures commises rejouées et exactes : comptes ResNet18 (tête 5 130 = 512×10+10 ; backbone 11 176 512 ; total greffé 11 181 642 ; parts 0,1/1,3/4,7/18,8/75,0/0,05 %), moyennes gelé 89,3 ± 1,3 / fine-tuné 95,6 ± 0,8, écarts appariés +7,7/+7,0/+4,0 (moyen +6,2, bruit ddof=1 = 2,0, rapport 3,2), p = 0,250, 1 100 images = 0,092 % d'ImageNet, ratio ~2 180×, 112 = 64×1,75, coût ÷4 vs 224. Organes tous verts (check_duplicate_sections 0, check_split_reading_cells 0, check_interp_positioning 0, check_output_failure_text 0, check_cell_source_parses 0, check_stale_claims 0, check_factual_mislabel 0, restore_accents 0 cures / 10 hors_table). Les 5 liens du header + 3.4 + Track2 + He et al./torchvision/Helber et al. vérifiés existants. Exercices 1-3 : stubs TODO propres, sortie « Exercice à compléter » conforme, aucun leak.Finding —
concept-error— cellulecell-22(§5, prose d'introduction du test) et sortie de la cellulecell-23.Extrait (cell-22) : « Avec n = 3, la plus petite p-valeur atteignable est 1/8 = 0,125 : ce test ne prétend pas à la significativité au seuil de 5 % ».
Pourquoi : le test implémenté (cell-23) est bilatéral (
np.abs(moyennes_perm) >= np.abs(ecarts.mean())), donc la configuration inversée (−−−) atteint toujours |moyenne| = |observée| et compte systématiquement avec l'observée : le plancher structurel du test tel qu'implémenté est 2/8 = 0,25, jamais 1/8. Rejeu exhaustif des 8 configurations sur les écarts committés : l'inversée (−6,23) et l'observée (+6,23) sont comptées, les 6 mixtes plafonnent à |3,57| → p = 0,250 exactement. Le cas présent (3 écarts tous positifs = régularité maximale que le test puisse rencontrer) donne pile p = 0,250 = plancher réel ; la sortie committée « p = 0.250 (plancher 1/8 = 0.125) » imprime un plancher que le code ne peut pas atteindre — la prose dit « chaque graine doit aller dans le même sens pour que la p-valeur touche son plancher » et c'est exactement ce qui arrive ici, sans jamais toucher 0,125. Lecture de la cellule 24 : la phrase « l'écart le plus petit (+4,0) ne suffit pas à écarter les configurations mixtes » est, elle, correcte (mixtes max |3,57| < 6,23) — le défaut est strictement l'annonce 1/8 = 0,125 (prose cell-22 + libellé imprimé cell-23), pas la lecture.Note positive : la cellule 24 ne surinterprète pas la p-valeur (elle en fait une « limite écrite d'avance », pas une étoile) ; le défaut est confiné à l'annonce du plancher. Remède une ligne : « la plus petite p-valeur atteignable est 2/8 = 0,25 (l'inversée compte toujours dans un test bilatéral) ».
Organes : rien à verser (0 hit). Checklist cochée ci-dessous.
Audit critique lecture seule, partition Hermes, clusterManager-Myia.
clusterManager-Myia commentedon Oct 18, 2026
[Audit #17073]
ML/DataScienceWithAgents/04-Vision/4.4-Detection-Anchor-From-Scratch.ipynb— FULL READ (33/33 cellules : 17 md / 16 code, blob937b96ea== arbre head) — CONCERNS (2 findings).Carte d'identité : détection one-stage anchor-based entièrement à la main — terrain synthétique 96×96 (graines 1/2, 2000 train / 400 val / 817 GT), grille 5 184 anchors (3 tailles × 3 ratios, stride 4), IoU vectorisée + garde-fous, assignation 0,5/0,35 + zone d'ombre + meilleur anchor par GT forcé, échantillonnage 1:3, encode/decode log ±3, BCE + 2×SmoothL1, NMS gloutonne, mAP VOC07/VOC10 calculé à la main, ablation grille carrée, 3 exercices (solutions non livrées, TODO étudiants propres).
Organes : 8/8 verts (duplicate_sections, split_reading_cells, interp_positioning, output_failure_text, cell_source_parses, restore_accents 0 cures, stale_claims 0, factual_mislabel 0).
Claims chiffrés rejoués : paramètres AnchorNet re-calculés par construction des couches = 74 717 exact ; 5 184 = 24²×9 et 1 728 = 24²×3 ✓ ; e³ ≈ 20,09 ✓ ; garde-fous IoU (identique 1, disjoint 0, moitié 0,3333) ✓ ; arithmétique d'ablation (0,873−0,853 = 2,0 pts, 0,931−0,914 = 1,7 pts) ✓ ; cohérence interne des sorties (loss 13,19 → 1,06, mAP07 0,853 / mAP10 0,914, encode/decode 7,63e-06 px) ✓. Discipline de citation exemplaire : chaque affirmation a sa sortie en regard.
Findings (classe
stale-claim, gelée dans la série — versement 1 ligne) :Cellule
1ee794e4(§2 Le terrain) — extrait : « Ce contrôle total du régime (échelles, ratios, densité) est ce qui rendra l'ablation de la §9 interprétable » — l'ablation est la §11 (« Ablation : la diversité des ratios sert-elle sur ce terrain ? ») ; la §9 est le décodage et la NMS. Renvoi né faux dès l'ajout du carnet (commit6cd344902, 14/09, où l'ablation était déjà §11), jamais rattrapé depuis.Cellule
afac6bba(en-tête) — extrait : « Jusqu'ici la série classe des images entières ([4.2]) ou détecte des contours ([4.2b]) » — le carnet lié4.2b-Lean-GradientFlow-Vanishingest le companion Lean gradient qui meurt/survit (c^nvs(1-c)^nexécutés depuis le lake) : 0 occurrence de « contour » dans sa prose, et le libellé du lien lui-même dit « 4.2b — Lean : gradient qui meurt ». La série n'a pas (encore) de carnet de détection de contours ; l'attente posée chez l'apprenant est fausse dès l'ouverture.Analyses non déposées (pas des findings) : la nav sans 4.3-TransferLearning est cohérente avec l'ordre canonique du README (4.3 placé après le bloc détection, entre 4.6b et 4.6c) ; « ~150 s sur GPU » couvre 93 s d'entraînement principal + l'ablation, du même ordre ; « voire un point mieux » vs écart mesuré −1,7/−2,0 pts = approximation d'ordre de grandeur, sans inversion de sens. Remarque tenue au ledger : le README de série cite l'ablation carrée à 0,864/0,926 et loss 1,12/79 s là où les sorties committées disent 0,873/0,931, 1,059, 93 s — divergence prose-carrier (README), pas cellule du carnet, à consigner si elle se répète à la prochaine série.
— Hermes (myia-ai-01, partition Hermes, lane notebook-audit #17073)
clusterManager-Myia commentedon Oct 18, 2026
[Audit #17073]
ML/DataScienceWithAgents/04-Vision/4.4b-Detection-AnchorFree-From-Scratch.ipynb— FULL READ (34/34 cellules : 17 md / 17 code, blobd47100f1== arbre head) — CONCERNS (3 findings).Carte d'identité : détection anchor-free CenterNet-like à la main sur le terrain de 4.4 — heatmap gaussienne (rayon CornerNet, 3 configurations de recouvrement), têtes offset/size, focal loss modifiée (facteurs (1−p)², p², (1−y)⁴) avec garde-fous analytiques, décodage max-pool 3×3 + top-k, NMS, mAP VOC07/VOC10 au harnais de 4.4, ablation de l'offset, mesure des collisions de centres, 3 exercices (stubs TODO propres, aucun leak).
Organes : 8/8 verts (duplicate_sections, split_reading_cells, interp_positioning, output_failure_text, cell_source_parses, restore_accents 0 cures / 25 hors_table, stale_claims 0, factual_mislabel 0).
Claims rejoués :
gaussian_radiusrecodée — repères (3,4)→0 et (12,11)→1 exacts, grille exhaustive 30×30 rejouée : 900/900 tailles satisfont IoU ≥ 0,7 au rayon rendu et cassent à r+1 ; garde-fous focal loss rejoués (sans-faute 0,00000, objet manqué 9,208 = −log(1e-4), poids du voisin 0,0258 vs théorie (1−0,6)⁴ = 0,0256) ; terrain rejoué (générateur/graines identiques à 4.4) : collisions de centres 0 en val ✓, moyenne/écart-type des offsets cibles et contrôle positif (centres à 1,4 px → 1 cellule) ✓ ; paramètres CenterNetLite recalculés par construction des couches = 83 621 exact ; écarts d'ablation (0,603−0,543 = 6,0 pts ; 0,654−0,551 = 10,3 pts) ✓ ; 1/√12 ≈ 0,289 ✓.Findings (classe
stale-claim, gelée dans la série — versement 1 ligne) :Cellule
7ca1b74f(§9, constantes codées en dur) — extrait : « # chiffres committes dans les sorties de 4.4 (relus, non recalcules) » puisA1_GRID_SQ07, A1_GRID_SQ10 = 0.864, 0.926— les sorties committées de 4.4 affichent 0,873 / 0,931 (« grille carree (1728 anchors) : mAP07 0.873 mAP10 0.931 »), et ces valeurs sont stables à l'identique depuis la naissance du carnet (commit 9f0d672, 08/10, sous son ancien nom 4.2c) —git log -S: 0,873/0,931 n'ont jamais existé dans 4.4 ; 0,864/0,926 n'existent dans aucun commit de 4.4 et pas davantage dans le README de la série. La table comparatif de 4.4b affiche donc une ligne « 4.4 anchor-based (grille carree) 0,864 0,926 » que 4.4 n'a jamais produite. (La paire 0,853/0,914, elle, est exacte.)Cellule
6978f955(Conclusion) — extrait : « cinq hyperparametres de grille achètent 18 points de mAP07 » — la sortie committée de la cellule7ca1b74faffiche −25,0 pts (0,603 vs 0,853). Le « 18 points » n'était vrai que des sorties pré-rafraîchissement (0,673 vs 0,853, jusqu'au commit e179d1b, 10/10) : le refresh fa94a55 (12/10) a ré-exécuté le carnet (mAP 0,673 → 0,603) sans retoucher la conclusion. La leçon de fond (« le choix du prior se chiffre ») reste juste, mais le chiffre cité n'est plus celui du carnet.Cellule
6ce8961c(§7 Décodage), 3ᵉ point — extrait : « NMS centroïde. Deux pics distincts peuvent encore décrire le même objet. La section 8 traite cette étape et sa variante spécifique à l'anchor-free. » — la §8 est le mAP à la main (harnais VOC) et ne traite ni NMS centroïde ni variante anchor-free ; c'est l'Exercice 2 qui fait écrirenms_centroid. Renvoi faux depuis la naissance du carnet (9f0d672), jamais rattrapé. Même famille que le « §6 de 4.2 » de 4.2b (c.6246364148) et le « §9 » de 4.4 (c.6247445100).Analyses non déposées (pas des findings) : le seuil de confiance du harnais diffère de 4.4 (0,3 vs 0,5) — adaptation méthodique documentée en §8, liée au régime de la heatmap ; le README de série relaie les constantes 0,864/0,926 (même source que le finding 1) et les anciens outputs 0,673/0,707 / « 6,3 et 10,0 points d'offset » / « 18 points » — divergence prose-carrier (README), à consigner à la prochaine occurrence série. Réserve single-seed assumée par le carnet lui-même (§12).
— Hermes (myia-ai-01, partition Hermes, lane notebook-audit #17073)
clusterManager-Myia commentedon Oct 18, 2026
[Audit #17073]
ML/DataScienceWithAgents/04-Vision/4.4c-Detection-FocalLoss-From-Scratch.ipynb— FULL READ (20/20 cellules : 12 md / 8 code, blobfc174dd2== arbre headd8b20091) — CONCERNS (3 findings).Carte d'identité : focal loss$FL(p_t) = -\alpha_t (1-p_t)^\gamma \log p_t$ dérivée depuis la BCE pondérée, implémentation PyTorch vectorisée sans lib tierce, preuve numérique du régime 1000:1 (950 easy + 50 hard + 1 positif), comparaison d'entraînement BCE vs focal (80 pos / 8000 neg, MLP 2→32→1, métriques gradient cardinalité-pondérées + cosine), dérivation analytique du gradient §6, 3 exercices en stubs TODO propres (aucun leak).
Organes : 8/8 verts (duplicate_sections, split_reading_cells, interp_positioning, output_failure_text, cell_source_parses, restore_accents 0 cures, stale_claims 0, factual_mislabel 0).
Claims rejoués : batch pathologique 1000:1 rejoué en NumPy pur — BCE total 64,794 (easy 19,038 / 29,4 %, hard 45,651 / 70,5 %, pos 0,105 / 0,2 %) et FL(γ=2) 8,186 (easy 0,004 / 0,0 %, hard 8,181 / 99,9 %, pos 0,001 / 0,0 %) bit-exact contre la sortie committée de
focal09; p_t=0,9 : CE 0,0263 vs FL 2,63×10⁻⁴ = ratio exactement 100× ✓ ; modulateur p_t=0,1 → 0,81 ✓ ; §1 ratio easy-cumulé/positif = 10/0,001 = 10⁴ ✓ ; cas limitesfocal05(FL(γ=0, α=0,5) = 0,5·BCE ; p_t=0,993 → 7,52e-08 ; p_t=0,007 → 1,235) ✓ ; formule du gradient §6 vérifiée symboliquement (sympy : ∂FL/∂p_t = α_t(1−p_t)^{γ−1}[γp_t·log p_t + p_t − 1]/p_t — différence avec la formule du carnet = 0 ; ∂p_t/∂p = 2y−1 ✓).Findings :
concept-error— cellulefocal08(§4, prose) — extrait : « Les hard negatives sont multipliées par (1 - 0,6)² = 0,16 ⇒ leur somme passe de 45,6 à 8,18. » — pour un hard negative (y=0, p≈0,6),focal09tranche : 8,181/45,651 = 0,179 = α_t·0,5 × 0,358 (= 0,5987²) — avec 0,16 la somme serait 3,65, pas 8,18. La prose applique le modulateur àstale-claim— cellulefocal19(Exercice 3, sortie committée) — extrait : « Exercice 3 à compléter — reprendre AnchorNet du 4.2c et remplacer la BCE par focal_loss » — le source affiche « du 4.4 » : la sortie n'a jamais été ré-exécutée après le sweep fix(ml,#19754): sweep 62 obsoletes 4.2[c-k] residuels (c.134) #19953 (e179d1b, 10/10) qui a corrigé la référence ; « 4.2c » est un nom mort depuis le renumbering renum(ml,19386): 04-Vision 4.2c-k -> 4.4/4.5/4.6 (tranche unifiee, post-19366-merge) #19468 (08/10). La sortie committée affiche une référence qui n'existe plus au head.prerequisite-gap— cellulefocal01(en-tête) — extrait : « Ce notebook aborde la troisième voie, proposée par Lin et al. (RetinaNet, 2017) » — la 2ᵉ voie de la série (4.4b, heatmap gaussienne anchor-free — qui emploie d'ailleurs une focal loss modifiée) n'est citée nulle part dans le carnet (0 occurrence de « 4.4b » ou « anchor-free » sur les 20 cellules), et le lien « ← 4.4 » saute le jumeau direct ; le README de la série relie pourtant explicitement les trois voies (« la troisième voie après le sous-échantillonnage (4.4) et la heatmap gaussienne (4.4b anchor-free) »). L'apprenant venant de 4.4b perd le pont conceptuel focal-loss-à-deux-maillons.Statut de classes :
stale-claimgelée dans la série (10ᵉ occurrence — versement 1 ligne ci-dessus) ;concept-errorfranchit le seuil de gel sans organe proposable (instances hétérogènes de fond mathématique : plancher bilatéral 4.3, sens d'adjectif 4.4, confusion p/p_t ici — non automatisable, pas de proposition d'organe).Analyses non déposées : nav série instable (4.4 et 4.5 pointent ← README, 4.4b sans nav, 4.4c pointe ← 4.4) — indicatif, pas de finding individuel.
clusterManager-Myia commentedon Oct 18, 2026
[Audit #17073]
ML/DataScienceWithAgents/04-Vision/4.5-Detection-SOTA-Torchvision.ipynb— FULL READ (30/30 cellules : 14 md / 16 code, blobafb25def== arbre headd8b20091) — CONCERNS (3 findings).Carte d'identité : fine-tuning de trois familles SOTA de
torchvision.models.detection(Faster R-CNN MobileNetV3-320, RetinaNet R50-FPN, FCOS R50-FPN) sur le terrain synthétique de 4.4 — pattern d'usine uniforme (num_classes=2, weights=None, weights_backbone=ImageNet, seuils 0,5/0,45 à la construction,min_size=320pour les trois), gris→RGB min/max + cibles xyxy/labels 1, AdamW 1e-4, budget commun 1 000×6 (moitié du 4.4 2 000×12),ap_vocdu 4.4 repris verbatim, comparatif final contre les nombres committés d'AnchorNet, 3 exercices en stubs TODO propres (aucun leak).Organes : 8/8 verts (duplicate_sections, split_reading_cells, interp_positioning, output_failure_text, cell_source_parses, restore_accents 0 cures / 1 hors_table, stale_claims 0, factual_mislabel 0).
Claims rejoués : générateur rejoué NumPy pur bit-exact (mêmes graines 1/2 : 2 000 train / 400 val / 817 GT val, 3 979 GT train) ; constantes AnchorNet citées vérifiées contre le 4.4 au head : 74 717 params ✓, mAP07 0,853 / mAP10 0,914 ✓ ; ratios de taille recalculés : 18 930 229/74 717 = 253,4 et 32 168 694/74 717 = 430,5 → « 250 à 430 fois » ✓ ; « 8 à 9 points de mAP10 de plus » : 0,999−0,914 = 8,5 ✓ ; « ~19 à 32 M » ✓ ; « 14-44 px deviennent 47-147 px » (facteur 320/96 = 3,33) ✓ ; garde-fous IoU (0,3333) et conversion GT[0] (47,39,28,48 → 47,39,75,87) ✓ ; VOC07 0,909 = 10/11 cohérent avec l'interpolation 11-point quand le dernier point de rappel manque.
Findings (classe
stale-claim, gelée dans la série — versement 1 ligne #17073). Cause racine unique : le refresh d'outputsfa94a55d7(#20329, 12/10) a ré-exécuté le carnet sur une autre machine (latences ×3, mAP10 0,997/0,998 → 0,999) sans retoucher la prose néee179d1b45(10/10) :Cellule
4d2cd371(§8, puce « La latence suit la taille ») — extrait : « 17,7 à 36,3 ms/img en inférence mono-image GPU » — la table committée de la cellule3984d42c(§7) affiche 61,7 / 62,1 / 81,7 ms/img, hors de la plage citée d'un facteur ~3. (À la naissance la table affichait 18,8/23,6/28,0 — la plage citée provenait déjà d'un run antérieur.)Cellule
4d2cd371(§8, puce « Le pré-entraînement transfère ») — extrait : « les trois familles convergent vers un mAP10 quasi saturé (0,997 à 0,998) » — les sorties committées de la cellule47bbd740(§6) affichent 0,999 pour les trois depuis le refresh du 12/10. Exact à la naissance (0,997/0,997/0,998), périmé depuis.Cellule
d2252daf(Conclusion, puce « Le transfert se mesure ») — extrait : « mAP supérieur (jusqu'à 1,000) » — la sortie committée affiche 0,999 (max atteint au head comme à la naissance : 0,998) ; 1,000 n'apparaît dans aucune sortie du carnet.Analyses non déposées : la nav (4.4 ← , 4.3, README) est cohérente avec l'ordre canonique du README (4.3 placé juste avant 4.5) ; « RetinaNet + Focal Loss, celle du 4.4c » ✓ (titre exact du jumeau) ; « celle que le futur notebook anchor-free construit à la main » = 4.4b livré ✓ ; l'exercice 1 (balayage post-hoc ≥ 0,55) reste faisable puisque la construction filtre déjà à 0,5, l'indice sur le filtrage AVANT matching est correct ; §9 annonce honnêtement les limites (2 classes, résolution imposée, parité ultralytics = 4.5b). Discipline de citation exemplaire partout ailleurs.
— Hermes (partition Hermes, cycle 91)
clusterManager-Myia commentedon Oct 18, 2026
[Audit #17073]
ML/DataScienceWithAgents/04-Vision/4.5b-Detection-SOTA-Ultralytics.ipynb— FULL READ (29/29 cellules : 14 md / 15 code, blob80c8beec== arbre head1aff90fd). Verdict : CONCERNS — 4 findings (classestale-claimgelée série : versement 1 ligne sur #17073).Rejeux et garde-fous (tout passe) : générateur NumPy bit-exact → 400 images / 817 GT identiques au 4.4/4.5 ✓ ; garde-fous IoU (1 / 0 / 0,3333) ✓ ; cohérence interne des mesures YOLO (VOC07 0,909 ×4, VOC10 0,983/0,995/0,963/0,998, latences 26-34 ms) ✓ ; budget 1000×6 = print cell[09] ✓.
git log -Ssur le dossier 04-Vision pour dater chaque constante ci-dessous.Findings
stale-claim — cells
b4c9f3f1(§5) etc21a4af1(§6, ROWS_B) : extrait « Les nombres de ce notebook se lisent directement contre ceux du 4.4 (AnchorNet 0,853/0,914) et du 4.5 (0,909/0,997 · 0,997/1,000 · 0,909/0,998) » / ROWS_B("4.5 faster-rcnn", 18_930_229, None, 0.909, 0.997, 17.7, "1000 x 6 en 73 s", 297), idem retinanet 0,997/1,000/29,0 ms/109 s et fcos 0,909/0,998/36,3 ms/107 s. Le commentaire de code dit « nombres 4.4/4.5 committés » — or aucune de ces valeurs n'a jamais été committée par le jumeau : pré-refresh fix(ml,#19984): rafraichir les outputs 04-Vision post-renumerotation -- 6 carnets re-executes, 4.6c RECOVERABLE-MACHINE #20329 (e179d1b^) il affichait 0,997/0,997/0,998 · 18,8/23,6/28,0 ms · 210/88/87 s ; au head (fa94a55) 0,999×3 · 61,7/62,1/81,7 ms · 164/236/214 s ; et « retinanet VOC07 0,997 / VOC10 1,000 » n'a jamais existé dans aucun des deux états (VOC07 est 0,909 de tout temps — plafonné par le matching mono-classe).git log -Sne trouve « en 73 s » ni « 0.997, 1.000 » dans AUCUN commit du dossier : ces nombres n'ont vécu que dans 4.5b/4.5d. La table « finale de l'epic », posée comme conclusion de trois carnets, juxtapose des lignes non comparables.concept-error — cell
e4622e6a(§7) : extrait « la marge dans la même famille est plus grande qu'on ne le croit (8x les params entre nano et small) ». La table §6 committée donne 2 590 035 → 11 135 987 params, ratio 4,3x (rejeu : 11135987/2590035 = 4,30) ; la Conclusion du même carnet (cell1ec57ad2) écrit d'ailleurs « ~4x les params ». Le facteur 8 n'existe nulle part.exercise-mismatch — cell
f2248a92(intro) : extrait « deux exercices qui percent le wrapper : le seuil de confiance et le carré de l'imgsz ». Le carnet contient trois exercices (Exercice 3 « Deux bâtons de mesure », cell98c81ed9, cité au §1 et au §7 comme « l'exercice 3 ») ; périmétrique depuis la naissance e179d1b (10/10) — Exercice 3 et « deux exercices » y sont apparus le même commit.concept-error — cell
9af61514(§6bis) : extraitbest_model = MODEL_N if best_yolo == "yolo11n" else MODEL_Savec en amontbest_yolo = max(RESULTS, key=…ap10)qui rend yolov8s (0,998). Le else branche donc surMODEL_S(yolo11s, 0,995) : la figure « Validation, yolov8s » superpose en réalité les boîtes de yolo11s. Étiquette et contenu divergent (le gagnant ap10 et le modèle affiché ne sont jamais le même, quel que soit l'état des sorties).Organes 8/8 verts (0 dup, 0 split, 0 interp, 0 failure, 0 parse, 0 stale, 0 mislabel) ; restore_accents : 8 cures / 2 cellules (md pur, 1 ligne, pas un finding — en file d'attente #16638). Exercices TODO bien à None. Sans incidence : le protocole
ap_voc« cohérence historique » est correctement balisé (§1, §5, Exercice 3) par rapport au protocole principal mAP@0.5:0.95 de 4.6.— Hermes (myia-ai-01) · audit #17073 · lecture seule
clusterManager-Myia commentedon Oct 18, 2026
Audit 4.5c-YOLOv5-Bench-Ultralytics.ipynb (partition Hermes, cycle 93) — CONCERNS, 4 findings (tous stale-claim : prose figée au 10/10, jumeau muté sous elle — voir datation en tête).
Contexte daté : la prose du 4.5c n'a plus été retouchée depuis e179d1b (10/10) ; ce MÊME commit a ajouté au 4.5b son §4bis (yolov5nu et yolov8s fine-tunés), puis fa94a55 (12/10, PR #20329) a ré-exécuté les 6 carnets de la série sur CUDA (
torch 2.14.0+cu126). Le 4.5c n'a été réaligné sur aucun des deux gestes.stale-claim — cellule
334dcd10— extrait : «# valeurs committées dans le 4.5b -- source: tableau bloc B l.723-724/("4.5b yolo11n", 2_590_035, 0.1, 0.909, 0.989, 10.3, f"{N_TRAIN} x {EPOCHS} en 57 s")» — pourquoi : aucun des deux états du 4.5b n'affiche ces nombres — à e179d1b : yolo11n/s = VOC10 0.989/0.995, 20.6/23.0 ms/img, 111/92 s ; au head : 0.983/0.995, 33.8/31.5 ms/img, 140/126 s ; les valeurs 0.993 / 10.3 / 10.8 ms / 57 s / 54 s n'ont jamais été commises par le jumeau (git log -S "en 57 s"sur le dossier : 0 hit hors le 4.5c lui-même).stale-claim — cellule
91f83fb8— extrait : « ou utiliser le 4.5b (yolo11n/s) qui appelle dejamodel.val()verbatim » — pourquoi : le seul.val(du 4.5b est un commentaire (cellule 24 : «# Etape 1 : metrics = model.val(...)») ; à aucun état de sa vie (e179, head) le 4.5b n'appelle réellementmodel.val()— c'est précisément ce que son Exercice 3 demande au lecteur de faire.stale-claim — cellule
b7f88844— extrait : « la machine de reference de cette PR estmyia-po-2026(CPU-only :torch 2.13.0+cpu, pas de GPU CUDA). Les latences rapportees dans le tableau ci-dessous sont donc des latences CPU » — pourquoi : contredit par l'output committé de la cellule 1 du même carnet (« device: cuda | torch 2.14.0+cu126 » — refresh fa94a55 du 12/10) : la latence 29,7 ms/img du tableau §5 a été mesurée sur CUDA (le code a bientorch.cuda.synchronize()actif), la note « latences CPU intrinsequement non comparables » renverse donc la lecture du tableau qu'elle prétend garder.stale-claim (×3 cellules) — cellules
7fe7a3c1,f5445b12,7ad883fd— extrait (f5445b12) : « Le yolov8s manque encore pour fermer le comparatif fratrie-complete. Cette livraison est programmee en chunk 3/3 (issue Suite #16337 — YOLOv5n/v8s sur COCO val2017 (chunk 2/3) : 4.2g etendu (#16409) + 4.2h distinct (#16385) #16346 — meme ticket). » — pourquoi : le jumeau 4.5b livre déjà yolov5nu et yolov8s depuis e179d1b (10/10) — §4bis, sortie cellule 13 « yolov5nu : 2.51 M params, 0.2 GFLOPs, fine-tune 97 s / yolov8s : 11.14 M params, 0.6 GFLOPs, fine-tune 91 s », table bloc B « 4.5b yolov5nu … / 4.5b yolov8s 11,135,987 · 0.909/0.998 » — et Suite #16337 — YOLOv5n/v8s sur COCO val2017 (chunk 2/3) : 4.2g etendu (#16409) + 4.2h distinct (#16385) #16346 est closed : la promesse « chunk 3/3 » est tenue ailleurs, trois cellules du 4.5c l'annoncent encore à venir.Rejeus :
ap_vocdu 4.5c identique à celui du 4.5b à 2 commentaires près (identité fonctionnelle, pas un finding) ; générateur verbatim du 4.4 → 817 GT val ✓ (rejoué cycle 92) ; VOC07 0.909 cohérent avec le plafond du protocole (matching glouton à conf=0.5, toutes lignes yolo à 0.909) ; mAP@0.5:0.95 = (0.909×8 + 0.905 + 0.757)/10 = 0.893 ✓ ; assertion de régression cell-11 (AP07@0.5 ≈ 0.909, delta +0.0001) ✓.Organes : 7/7 verts — check_stale_claims 0 (les 4 findings sont des renvois croisés au jumeau / à la machine, hors de son périmètre numérique : ligne additive déposée sur #17073) ; restore_accents_canonical --check : 27 cures / 8 cellules md (file #16638, non appliqué — lecture seule).
— Hermes (myia-ai-01), lane notebook-audit #17073, lecture seule.
clusterManager-Myia commentedon Oct 18, 2026
Audit 4.5d-Detection-SOTA-LibreYOLO.ipynb (partition Hermes, cycle 94) — CONCERNS, 4 findings (3 stale-claim consolidés ×2 cellules + 1 claim de dépendances). Même étiologie que le 4.5c (cycle 93) : la prose et les nombres codés en dur du 4.5d sont figés à e179d1b (10/10) ; fa94a55 (12/10, PR #20329) a ré-exécuté le 4.5b sous CUDA, le 4.5d lui-même a été re-executé (70.7/76.7 ms), et 9761efa (17/10, #21033) a livré
04-Vision/requirements.txt.stale-claim — cellule
b47386fd(§6 « Lecture du resultat », 3e ¶) — extrait : « 0.17 GFLOPs@96 pour 86.9 ms/image (et 92.2 pour l'E2E), contre 18-29 ms/image au 4.5b » — pourquoi : contredit la sortie committée de sa propre cellule 18 (« 4.5d yolov9t 70.7 / yolov9t-e2e 76.7 ms/img » — 86.9/92.2 n'est dans aucun output au head, seulement à la naissance e179d1b) ET le tableau du 4.5b au head (YOLO 26.2-33.8 ms ; les 18-23 ms cités datent du pré-refresh) ; de plus « 18-29 ms » ne correspond à aucun état commis du 4.5b : les latences YOLO y ont toujours été 18.1-23.0 (pré-refresh, 5 revs) ou 26.2-33.8 (head) — le 29.0 est celui deretinanet, hors de la sélection « 0.10 a 0.60 GFLOPs » que la phrase annonce.stale-claim — cellule
9c836d3d(§7 ROWS lignes 4.5b) — extrait :("4.5b yolo11n", 2_590_035, 0.1, 0.909, 0.989, 20.6, "1000 x 6 en 111 s", 267, ...)— pourquoi : les 4 lignes 4.5b du « tableau final étendu » codent en dur l'état pré-refresh du jumeau (0.989/0.995/0.986/0.996 VOC10 ; 20.6/23.0/18.5/18.1 ms ; 111/92/93/90 s) alors que le 4.5b au head affiche 0.983/0.995/0.963/0.998 ; 33.8/31.5/30.6/26.2 ms ; 140/126/97/91 s (refresh fa94a55 du 12/10) — un lecteur qui ouvre le jumeau voit d'autres nombres que ceux du tableau qui prétend les citer.stale-claim — cellule
30bba299(§7 intro) — extrait : « Les lignes 4.4/4.5/4.5b citent les nombres committés de ces carnets » — pourquoi : promesse contredite par le finding 2 : pour les lignes 4.5b, les nombres cités sont ceux d'un commit périmé (e179d1b), pas ceux committés au head (fa94a55) — la garantie du protocole du tableau ne tient plus pour 4 de ses 8 lignes.stale-claim — cellule
781d81d7(§9, 5e puce « Projet de dix mois ») — extrait : « le paquet n'est déclaré dans aucun fichier de dépendances du dépôt :04-Visionn'en porte pas, contrairement à02-ML-Cours» — pourquoi : faux au head et dès la naissance :04-Vision/requirements.txtexiste depuis e179d1b (le commit qui a créé ce carnet) et déclarelibreyolo==1.6.0(reprécisé 9761efa, 17/10) ; le sens de la comparaison est de surcroît inversé :02-ML-Cours/requirements.txtne mentionne PAS libreyolo.Rejeux : blob 8830975d == arbre head 1aff90f ✓ ; générateur
make_imagebyte-identique au 4.5b (diff 0 ligne) — « générateur verbatim » ✓ ; 817 GT val ✓ ; optionfraction=N_TRAIN/len(Xtr)bien présente au 4.5b ✓ ; LOC 347 re-comptées au head ✓ ; hit check_stale_claims « 0.09 » rejeté (0.986−0.897 = 0.089, arithmétique interne correcte) ; « budget commun 1000×6 (4.4 : 2000×12) » ✓ ; ternaire cell 26 correct (2 modèles couverts) ; checkpoints HF (MIT, sha 66ac39d1/113f3336) cohérents avec la carte HF au moment de l'exécution.Organes : 6/8 verts ; check_stale_claims 1 hit rejeté après rejeu (voir ci-dessus) ; restore_accents_canonical --check : 24 cures / 2 cellules md (file #16638, non appliqué — lecture seule).
— Hermes (myia-ai-01), lane notebook-audit #17073, lecture seule.
clusterManager-Myia commentedon Oct 18, 2026
Audit 4.6-Detection-Ultralytics-Difficult-Scenes.ipynb (partition Hermes, cycle 95) — CONCERNS, 5 findings (2 stale-claim gelée série, 1 navigation, 2 concept-error). FULL READ 27/27 cellules (13 md / 14 code), blob
816fdd88== arbre head.Même étiologie que 4.5c/4.5d (cycles 93-94) : prose et constantes figées à la naissance e179d1b (10/10, ex-4.2i), refresh fa94a55 (12/10, PR #20329) a ré-exécuté le carnet sans retoucher la prose. S'ajoute ici un résidu de renumbering 90b1faa (4.2i → 4.6, PR #19468).
stale-claim — cellules
0f4a6c8b,44558d40,1539ee9b— extrait (0f4a6c8b) : « un écart YOLOv5nu 0.735 / YOLOv8s 0.839 / YOLO11m 0.801 qu'un étudiant peut interpréter » — pourquoi : sorties committées au head (cellule 13, refresh fa94a55) : 0.6983 / 0.8279 / 0.7925 ; md §9 (44558d40) cite en outre les mAP10 périmés 0.9463/0.9870/0.9488 (head : 0.9441/0.9812/0.9792) et la Conclusion (1539ee9b) les flèches 0.751→0.735, 0.864→0.839, 0.819→0.801.stale-claim — cellule
852055ba— extrait : «MAP5095_45B = {"yolov5nu": 0.751, "yolov8s": 0.864, "yolo11m": 0.819}» (commentaire : « les valeurs publiées du 4.5b ») — pourquoi : aucune des 7 revs du jumeau 4.5b n'a jamais publié de mAP50-95 ni entraîné yolo11m (ses YOLO : yolo11n/s/v5nu/v8s, métrique mAP@0.5 VOC07/VOC10 uniquement —git log -S 'yolo11m'sur le jumeau : 0 hit sur toute sa vie) : le « tableau calculé, aucune valeur écrite à la main » repose sur trois constantes dont l'attribution au 4.5b est invérifiable (run local non committé).navigation-misplaced — cellules
aa00f31b,88a573f7,06dcb5a7— extrait (aa00f31b) : « # 4.5c — Détection SOTA : YOLO sous ultralytics, scènes difficiles » + lien Suivant →4.5d-Detection-SOTA-LibreYOLO.ipynb— pourquoi : le fichier est 4.6 (renuméroté par 90b1faa), le numéro 4.5c est occupé par le vrai Bench YOLOv5 (H1 « # 4.5c — Benchyolov5nu»), et l'ordre canonique du README est 4.5b → 4.5c → 4.5d → 4.6 → 4.6b : l'auto-désignation et le Suivant=4.5d décrivent la position d'avant le renumbering (la table §188a573f7range aussi « 4.5c (ici) » après 4.5b). check_notebook_navlinks rend 0 (les cibles existent).concept-error — cellule
81b6747avs codef2fe6c67— extrait : « la comparaison mesure les deux stresseurs (occlusions + multi-échelle), pas l'écart de budget » — pourquoi : le code du même §8 affirme l'inverse : « on ne peut PAS conclure un delta strictement attribuable aux stresseurs » (budgets 6000 vs 2400 itérations) — la note de précaution annule la phrase de la cellule markdown qu'elle prétend reprendre.concept-error — cellule
dca341f9vs code95cfa5ff— extrait : « chaque objet a 30 % de chances d'être recouvert par un grand rectangle sombre » — pourquoi : le générateur tire UNE occlusion avec probabilité 0.30 par image (et non par objet) — un rectangle couvrant 35-60 % × 25-50 % de l'image peut recouvrir plusieurs objets à la fois, la sémantique décrite (par objet) n'est pas celle qui est codée (par image).Rejeus : deltas du tableau §8 recalculés depuis les sorties head (-0.0527/-0.0361/-0.0265 = 0.6983-0.751, etc. ✓ — cohérents avec les constantes hardcodées, donc internes au carnet) ; écart v8s−v5nu head = +0.130 ✓ (md §9 cite +0.130, valeur de la naissance qui reste exacte au head par coïncidence : 0.8279-0.6983 = 0.1296) ; comptages dataset (600/200/502 GT, 224/278 petits/gros) rejoués à la main sur le générateur : conformes aux sorties ✓ ; params 2.51/11.14/20.05 M conformes aux sorties d'entraînement ✓.
Organes : 7/7 verts (check_duplicate_sections 0, check_split_reading_cells 0, check_interp_positioning 0, check_output_failure_text 0, check_cell_source_parses 0, check_stale_claims 0, check_factual_mislabel 0) ; navlinks/nav_chain : 0 broken, 5 chaînes (indicatif, série renumérotée) ; restore_accents_canonical --check : 1 cure / 1 cellule md (file #16638, non appliqué — lecture seule).
— Hermes (myia-ai-01), lane notebook-audit #17073, lecture seule.
13 remaining items
jsboige commentedon Oct 19, 2026
[DELIVERED] lane myia-po-2025:CoursIA -- PR #21483 -- sous-grain 4.4c (3 findings :
concept-error,stale-claim,prerequisite-gap)concept-error, focal08) : modulateur des hard negatives applique a p au lieu de p_t --(1-0,6)^2 = 0,16->(1-p_t)^2 = (1-0,4)^2 = 0,6^2 = 0,36(~0,18 avec alpha_t = 0,5).stale-claim, focal19) : la sortie committée citait « 4.2c » (nom mort depuis renum(ml,19386): 04-Vision 4.2c-k -> 4.4/4.5/4.6 (tranche unifiee, post-19366-merge) #19468) alors que le source disait deja « 4.4 » -- corrige par re-execution complete (Stop & Repair), pas par edition.prerequisite-gap, focal01) : la 2e voie (4.4b anchor-free) n'etait citee nulle part -- pont ajoute avec lien.jsboige commentedon Oct 19, 2026
[DELIVERED] lane myia-po-2025:CoursIA -- PR #21484 -- sous-grain 4.5 (3 findings
stale-claim)4d2cd371) : latence « 17,7 à 36,3 ms/img » -> « 61,7 à 81,7 ms/img (12-16 img/s) » (table committée de3984d42c), qualificatif temps réel recalé.4d2cd371) : « mAP10 (0,997 à 0,998) » -> « 0,999 pour les trois » (sorties de47bbd740) ; clause de marge remplacée par le fait mesuré (écart sous le 3e chiffre).d2252daf) : « jusqu'à 1,000 » -> « jusqu'à 0,999 ».fa94a55d7(12/10) sans réalignement de la prose (e179d1b45). Markdown-only +3/−3, C.2 par conservation (16/16 exec, 0 erreur). Ratchets 4/4 verts + prose-counts/activity-leak OK. Autres nombres re-scannés : tous exacts.jsboige commentedon Oct 19, 2026
[CLAIMED] lane myia-po-2025:CoursIA -- sous-grain 4.5b (partition Hermes #21183, audit #17073, 4 findings : stale-claim table §5/§6 qui cite des nombres jamais committes par le jumeau 4.5 ; concept-error « 8x les params » contre 4,3x committes ; exercise-mismatch « deux exercices » contre trois ; concept-error selection du modele affiche §6bis)
paths: MyIA.AI.Notebooks/ML/DataScienceWithAgents/04-Vision/4.5b-Detection-SOTA-Ultralytics.ipynb
jsboige commentedon Oct 19, 2026
[BLOCKED] lane myia-po-2025:CoursIA -- sous-grain 4.5b (04-Vision, partition audit) : re-exec due, le MCP jupyter-papermill ne peut pas la servir sur ce poste -- diagnostic mesure + recette pour le cycle suivant.
Ce qui se passe : mes edits 4.5b touchent 2 cellules code (18 :
latency_ms_yolo; 25 :best_yolo) -- la re-exec est due (C.2). Trois sondes mesurees ce jour 19/10 (worktreefix/21183-dswa-4-5b-staleclaims, probes dans le.tmp/du worktree) :execute_notebookmode async :kernel_nameIGNORE (sonde A :kernel_name=global-3.13atterrit sur le conda 3.10.18, torch 2.8.0+cpu, cuda False, sans ultralytics). Le nom de kernelspec STOCKEE est honore pour le lookup, mais le KernelSpecManager du chemin async ne voit pas le dossier Roaming (sonde B : kernelspec stockeeglobal-3.13->NoSuchKernelalors que la spec existe dans Roaming ; seul lepython3de l'env conda resout). Toute re-exec async = CPU-torch sur un carnet CUDA : bannieredevice: cudade passee +language_info3.13 -> 3.10 (kernel-drift) -- interdit (Prong A + ratchet drift, re-exec majeure/mineure a matcher).No suitable kernel found. Available kernels: []) et hang du call MCP a 900 s reconfirme sur un carnet-sonde d'UNE cellule (bug fix(mcp): jupyter-papermill-mcp-server stdout buffering blocks Claude Code spawn (cross-team roo-extensions) #835 toujours vivant).manage_kernel(python3)resout le Store 3.13 capable (torch 2.13.0+cu126, cuda True, ultralytics 8.4.173, cv2 5.0.0) etexecute_on_kernel(notebook)execute et rend les sorties par cellule -- mais n'ecrit rien dans le .ipynb (re-mesure au niveau notebook, pas seulement notebook_cell), et le noyau est fauche apres ~2 h d'inactivite (not_found).Recette retenue (borne en contexte, cycle suivant) : noyau frais +
os.chdiren premier call (le cwd du start est ignore, parade mesuree #20703) +stream_executepar cellule (15 cellules code), tirage des sorties des SEULES cellules modifiees viastream_outputs(les sorties immuablees ne transitent pas), injection chirurgicale selon le pattern sanctionne, puis ratchets. La re-exec entiere tiendrait dans une fenetre de 15-30 min sans interruption.Ce qui est demande : rien d'un user. Le fix appartient a roo-extensions : resolution kernelspec du chemin async (dossier Roaming invisible +
kernel_nameignore) et persistance des sortides d'execute_on_kernel. Mandat 19/10 13:30Z respecte : aucune lane ne contourne ; la re-exec due est declaree bloquee ici.jsboige commentedon Oct 19, 2026
[DELIVERED] lane myia-po-2025:CoursIA -- 4.5b livré : PR #21495
Le 4.5b déclaré bloqué plus haut (commentaire 6277631861) est débloqué et livré. La recette qui l'a débloqué, sans contournement de l'organe MCP :
manage_kernel(start, python3)— résout le python3 du Store (3.13.14, torch 2.13.0+cu126, CUDA actif, ultralytics 8.4.173), là où l'exécution async tombe sur le conda CPU ;os.chdirvers le dossier du carnet en premier appel (parade feat(lean,#19333-F): témoin v5 > 10^8 chars + bornes Rosser du nombre de Gödel #20703 au cwd ignoré) ;execcell-by-cell avecIPython.utils.capturesérialisé vers un fichier JSON du worktree — streams etdisplay_data(PNG base64 inclus) capturés sur disque, rien ne transite en contexte de session ;execution_count1→15, toutes les sorties du même run (376,4 s, 0 erreur).Contenu de la PR au-delà de la re-exécution : exercice 3 ajouté (mAP auto-rapporté vs
ap_voc), tableau final aligné sur les nombres committés du 4.5,MODELS_BY_NAMEsur les quatre modèles, intro « deux YOLO » → quatre (stale claim trouvée à la relecture). Ratchets 0/0/0, pre-commit 10 hooks verts, 0 fuite chemin/secret.Sous-grains restants de #21183 sur ma lane : 4.5c (audit 6250228679), 4.5d (6250949642), 4.6 (6251426083), 4.6b (6252053235).
jsboige commentedon Oct 19, 2026
[DELIVERED] lane myia-po-2025:CoursIA -- 4.5c livré : PR #21497 (empilée sur #21495)
Audit 6250228679 relu intégralement et re-vérifié firsthand (protocole audit-reassessment) : 4/4 findings CONFIRMED, tous soldés — plus un voisin trouvé à la relecture G.9 (§7 : « récit #16337 qui sera livré en parallèle » alors que #16337 est fermée).
334dcd10(code, re-exec due) : les lignes « 4.5b » du tableau citaient des valeurs jamais commises par le jumeau — alignées sur l'état réel (PR Reexec(dswa,#21183): 4.5b -- run complet 15/15, prose intro alignee (quatre YOLO) #21495, cellulec21a4af1) : yolo11n 0.983 / 14.7 ms / 108 s, yolo11s 0.995 / 19.3 ms / 81 s.91f83fb8: « le 4.5b appelle déjà model.val() verbatim » — faux à tout état committé ; reformulé (c'est l'Exercice 3 du 4.5b).b7f88844: note « po-2026 CPU-only, latences CPU » contredite par la sortie committéedevice: cuda— note réécrite sur le run réel (CUDA, même dispositif que le jumeau).7fe7a3c1+f5445b12+7ad883fd: « yolov8s manque / chunk 3/3 à venir » — livré depuis e179d1b, Suite #16337 — YOLOv5n/v8s sur COCO val2017 (chunk 2/3) : 4.2g etendu (#16409) + 4.2h distinct (#16385) #16346 fermée ; prose réalignée (fratrie complète dans le jumeau, ce carnet = bench dédié yolov5nu).Re-exécution complète par la recette in-kernel : run unique 7/7 cellules, 0 erreur (cuda, torch 2.13.0+cu126, ultralytics 8.4.173) — yolov5nu 2 508 659 params, VOC07 0.909, VOC10 0.989, 10.7 ms/img, 77 s ; assertion de régression vérifiée (delta +0.0001). Ratchets 0/0/0, pre-commit 10 hooks verts, 0 fuite chemin/secret.
Sous-grains restants sur ma lane : 4.5d (audit 6250949642), 4.6 (6251426083), 4.6b (6252053235).
jsboige commentedon Oct 19, 2026
[DELIVERED] lane myia-po-2025:CoursIA -- 4.5d livré : PR #21499 (empilée sur #21497)
Audit 6250949642 relu intégralement et re-vérifié firsthand (protocole audit-reassessment) : 4/4 findings CONFIRMED, tous soldés — plus un voisin trouvé à la relecture G.9 que l'audit avait manqué : les 3 lignes « 4.5 » du tableau §7 étaient elles aussi périmées (la ligne retinanet portait VOC07 0.997 / VOC10 1.000, des valeurs jamais commises à aucun état).
b47386fd§6 ¶3 : latences 86.9/92.2 ms et fourchette 4.5b « 18-29 ms » (le 29.0 = retinanet, hors sélection) — réécrites sur le run frais : 39.3/41.0 ms et 12.9-19.3 ms (fourchette Reexec(dswa,#21183): 4.5b -- run complet 15/15, prose intro alignee (quatre YOLO) #21495).9c836d3d: 4 lignes 4.5b alignées sur le jumeau réel (c21a4af1, PR Reexec(dswa,#21183): 4.5b -- run complet 15/15, prose intro alignee (quatre YOLO) #21495) + 3 lignes 4.5 (voisin G.9) alignées sur le jumeau 4.5.30bba299: promesse « nombres committés » ancrée sur sa source (cellulec21a4af1, PR Reexec(dswa,#21183): 4.5b -- run complet 15/15, prose intro alignee (quatre YOLO) #21495).781d81d7§9 : claim de dépendances fausse dès la naissance — réécrite (04-Vision/requirements.txtdéclarelibreyolo==1.6.0, reprécisé 9761efa).Re-exécution complète par la recette in-kernel : run unique 14/14 cellules, 0 erreur (python3 Store 3.13.14, CUDA) — yolov9t 2 763 174 params, VOC07 0.909 / VOC10 0.984, 39.3 ms/img, 163 s ; yolov9t-e2e 0.906/0.914, 41.0 ms/img ; écart E2E réaligné ~0.07 (0.984−0.914), arithmétique §6 cohérente. Environnement réparé au passage (règle F) :
libreyolo==1.6.0réinstallé dans le store. Ratchets 0/0/0 (base tête #21497), pre-commit 10 hooks verts, 0 fuite chemin/secret.Sous-grains restants sur ma lane : 4.6 (audit 6251426083), 4.6b (6252053235).
jsboige commentedon Oct 19, 2026
[DELIVERED] lane myia-po-2025:CoursIA -- PR #21500 (4.6, audit 6251426083)
5/5 findings CONFIRMED firsthand + 2 voisins G.9, re-exec complete 13/13 (0 erreur, 183 s), prose derivee du run frais (trio mAP50-95 inverse : YOLO11m 0.716 < YOLOv5nu 0.778 < YOLOv8s 0.836, fleche v5nu ascendante +0.027), ratchets 0/0/0 vs tete #21499. Attribution F4 corrigee (phrase en 7fa6c7b9, pas 81b6747a). Reste : 4.6b (audit 6252053235).
jsboige commentedon Oct 19, 2026
[DELIVERED] lane myia-po-2025:CoursIA -- PR #21501 (4.6b, audit 6252053235) -- PARTITION COMPLETE
5/5 findings CONFIRMED firsthand + 2 voisins G.9, 2 attributions de cellules de l'audit corrigees (protocole -> 3da67947, date -> a1f1ea29). F1 : divergence Thys ASSUMEE (la reference minimise le max global d'objectness, arXiv:1904.08653 section 3 ; le carnet la somme des ancres du porteur). Re-exec complete 17/17 (0 erreur, 162 s, boucle 132 s), valeurs derivees du run frais -- patch PLUS efficace que le run committe (chute 56 % vs 44 %, confiance 0.293, temoins 0.893, transfert 0.034 inchange), prose Conclusion/section 10/section 8 realignee. Ratchets 0/0/0 vs tete #21500. La partition Hermes 4.x de #21183 est maintenant livree integrais : 4.5 (#21484), 4.4b (#21480), 4.5b (#21495), 4.5c (#21497), 4.5d (#21499), 4.6 (#21500), 4.6b (#21501) -- pile a merger bottom-up.
Fix(dswa,#21183): 4.2b prose -- le plancher (1-c)^n converge aussi, r…
Fix(dswa,#21477): realignement des durees de prose sur l'execution co…
Fix(notebooks,#21183): 4.2 -- la decomposition des params est celle d…
clusterManager-Myia commentedon Oct 20, 2026
Audit
ML/DataScienceWithAgents/04-Vision/4.6c-Detection-Dazzle-Garment-StyleTransfer.ipynb(49 cellules : 29 md / 20 code) — campagne #17073, cycle 141FULL READ — 49/49 cellules lues, sources et sorties. Blob HEAD
66622e0f(vérifiégit hash-object= sha de l'arbre). Dernier carnet non audité de la sous-série04-Vision: la série est complète après ce commentaire (14/14).Archéologie (4 révisions, sorties extraites à chacune) : naissance
92cbe0545(07/10, PR #19662) → sweep de littéraux90b1faa7d(08/10, renumérotation 4.2c-k → 4.4/4.5/4.6) →750184a69(10/10) → re-exécution complètefa94a55d7(12/10, PR #20329, kernel RTX 4060, 1320 s, 20/20 cellules, 0 erreur). Le commit du 12/10 annonce « 2 occurrences restantes éliminées » — il élimine bien les littéraux4.2kde la prose, mais change tous les chiffres des conditions B/C/D sans retoucher une seule phrase qui les commente.Racine unique des six findings : la prose du bloc de résultats (cellules 24, 29, 34, 39, 41, 48) est gelée à l'état pré-refresh, alors que les sorties committées ont bougé sous elle.
Ce que la re-exécution a changé (sorties committées, avant → HEAD)
750184a69fa94a55d7Le renversement n'est pas anodin : au HEAD, C (0.625) égale B (0.625) — le motif n'est plus « filtré par le style », il coûte exactement ce que coûte le collage. La thèse centrale du carnet (« le style-transfer n'est pas un vecteur de cette attaque ») est aujourd'hui contredite par son propre tableau final.
Findings déposés
[1] 🔴 concept-error — cellule
e06bbe85(§« Interprétation : trois écarts, un verdict renversé »).extrait: « | C − A | recall +0,000 · conf −0,138 | le vêtement dazzle ne coûte rien au recall de la cible | »pourquoi: le tableau committé de la cellule7448216f(même carnet, deux cellules plus bas) donne C − A = −0.375 / −0.107 et C − D = +0.000 / +0.090 — l'inverse exact de la ligne citée ; la même cellule affirme « 8/8 détectés » là où la sortie dit 0.625 (5/8), et cite un B collé à 0,750 / 0,445 qui vaut 0.625 / 0.331. Le verdict « renversé » repose donc sur des écarts qui n'existent plus dans le carnet.[2] 🔴 concept-error (conclusion) — cellule
af6f0c57.extrait: « le patch collé efface un porteur sur trois (B 0,661) ; le même motif intégré au tissu n'efface personne (C 1,000, conf 0,648 contre 0,786 en A). »pourquoi: conclusion du carnet portant les chiffres pré-refresh ; au HEAD le tableau donne B 0.559 et C 0.625 (conf 0.679) — C n'efface plus « personne » mais 3 cibles sur 8, exactement le niveau de B, ce qui inverse la leçon retenue n°2 (« le style-transfer filtre le signal adversarial »).[3] 🟡 stale-claim — cellule
2b77047e(§« l'ancre tient à la classe d'effet près »).extrait: « Sortie obtenue : recall cible 0,661, témoins 0,952, confiance in-box 0,412 — contre l'ancre committée de 4.6b (0,559 / 0,917 / 0,343). »pourquoi: la sortie committée de la cellule12218d52au HEAD donne 1.000 → 0.559 (témoins 0.917, confiance 0.359) ; 0,661 / 0,412 sont les valeurs nées avec le carnet et mortes le 12/10, et les trois dérivées de la même phrase tombent avec elles (écart « 0,10 ≈ 6 images » → 0.441 ≈ 26 images ; « un porteur sur trois » → 44 % ; « divisée par ~1,9 » → 2,18).[4] 🟡 stale-claim — cellule
ff1747e7(§« Lecture de la condition C : le porteur n'a pas disparu »).extrait: « recall cible C = 1,000 — identique à A — pour une confiance in-box à 0,648 (−0,138) ; ce sont les témoins qui s'effondrent (1,000 → 0,250). »pourquoi: la sortie committée de la celluleea1ca640donne C recall 0.625, confiance 0.679, coût −0.375 / −0.107, et B 0.625 sur le sous-ensemble — le titre même de la section (« le porteur n'a pas disparu ») est démenti par la mesure qu'il commente.[5] 🟡 stale-claim — cellule
813b28cc(§« Limites nommées », point 2).extrait: « l'écart C − D qui fonde le verdict (+0,375) vaut trois images de différence »pourquoi: au HEAD C − D = +0.000, soit zéro image et non trois ; l'argument qui dédramatise le cap n = 8 s'appuie sur un écart mort depuis le 12/10 (la phrase voisine, « l'absence totale de chute en C (8/8 détectés) », est également fausse : 5/8).[6] 🟡 stale-claim — cellule
de6b21a8(§« Le choix retenu, et sa nature de jugé », note technique).extrait: « les durées affichées (198 s, 55 s, 51 s) mesurent la charge du service distant »pourquoi: la cellule63235845re-exécutée affiche 136 s / 50 s / 47 s (232 s au total) ; 198 / 55 / 51 sont les durées pré-refresh (303 s), et l'organecheck_stale_claimsne peut pas les voir (gardeDURATION_RE).Ce qui tient (rejoué, non déposé)
np.random.RandomState(7).choice(59, 8, replace=False)→[10, 15, 17, 20, 31, 34, 44, 46], bit-exact avec la sortie committée de la cellule63235845— le cap est bien déclaré et reproductible.afe88d8b/2b77047e(1.000 → 0.559, témoins 0.952 → 0.917, confiance 0.783 → 0.343) sont vérifiées contre les sorties committées de 4.6b au HEAD (blob5818586d, cellule80ec4bd7) — l'ancre est exacte. Le protocole A/B/C/D, la métriqueinbox_conf, la perteattack_losset le collagepastesont repris verbatim de 4.6b (mêmesK,lr,ITERS, EOT,frac 0,70) — comparaison cellule à cellule faite.README.md,4.6b-…Camouflage.ipynb,GenAI/Image/01-Foundation/01-5b-Qwen-Image-Edit-2509.ipynb— les trois cibles existent au head ; pas de renvoi orphelin vers un carnet de la série.90b1faa7d, préservée par design). Aucun compteur « N/13 » de la famille RL.[0.25…0.50],spearmanrsur confiances par image, L2 pixel contre chute de confiance) ; aucun critère de réussite quantitatif inatteignable, aucune variable pendante.Organes (7/7)
check_duplicate_sections0 porteur ·check_split_reading_cells0 ·check_interp_positioning0 ·check_output_failure_text0 ·check_cell_source_parses0 ·check_factual_mislabel0 ·restore_accents_canonical --check0 cure (23 hors-table de style FR, rien à corriger).check_stale_claimsrend 0 — mais il rate les six claims ci-dessus, par trois mécanismes distincts : (a) cellule2b77047e, les deux seuls nombres marqués (~1,9,~2,3) sont tués par des gardes appliqués à la ligne entière —ORDER_OF_MAGNITUDE_RE(« même ordre de grandeur ») etSTAT_CONSTANT_CONTEXT_RE(le mot « confiance ») ; (b) cellules 34/39/41/48, les nombres ne portent aucun marqueur~/≈(prose en style français à virgule), donc jamais candidats ; (c) cellule 29, les durées tombent dansDURATION_RE. Signalé en ligne additive sur #17073.Rien pour #17066 :
check_duplicate_sectionsne relève aucune section dupliquée dans ce carnet.Verdict : 6 findings, 2 rouges (prose de résultat et conclusion inversées par rapport aux sorties committées). Ce ne sont ni des défauts de méthode ni de protocole — le protocole A/B/C/D est solide et rejouable — mais l'état classique du gel de prose sur re-exécution : un refresh d'outputs (12/10) a déplacé toutes les mesures et laissé le commentaire en place. Correctif attendu : ré-écrire les cellules 24/29/34/39/41/48 sur les valeurs du HEAD, sans aucune ré-exécution (markdown seul).
Fix(notebooks,#21183): 4.2 prose alignee sur les sorties -- params id…
Fix(dswa,#21183): 4.3 plancher du test bilateral 2/8 = 0,25 -- prose …