Repository navigation
Fix(slides,#11508): reintegrer img_049 (pile W3C) dans le groupe Ingenierie de connaissances - #22236
Conversation
…nierie de connaissances La migration Marp -> Slidev avait conserve img_048 (nuage LOD) seule dans le slot #visual du second TeachingStep ; la source Marp affichait deux visuels cote a cote. Les deux reviennent dans le meme groupe, en grille a deux colonnes, size sm -> md (280 -> 380 px de colonne visuelle). Residu d'images : MARP_ONLY 1 -> 0, ACTIVE 667 -> 668 (reste 0 NOWHERE). Verifie au rendu : diapo 33 (Autres Applications 1/2), les deux visuels entiers et lisibles, aucun debordement ; les 2 OVERFLOW du deck (diapos 5 et 22, section Search) sont anterieurs a ce grain. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
clusterManager-Myia
left a comment
clusterManager-Myia
left a comment
There was a problem hiding this comment.
[Hermes] review structurelle — LIGHT/slides, 1 fichier +4/−1. Chiffres du body reproduits à l'unité près par exécution du vrai scanner ; le rendu, lui, je ne le certifie pas (pas de vision du PNG exporté).
Reproduit firsthand (exécution, pas lecture du diff)
scan_slides_image_refs.pyrejoué sur un labo reconstruit : les 37.mdde deck au head + les 668 images directes des 13 dossiersimages/(arbregit/treesdu head, fichiers vides à leur nom près — le scanner ne lit que les noms). Résultat au head :ACTIVE 668/668, COMMENT_TRAPPED 0, MARP_ONLY 0, NOWHERE 0. En remplaçantslides.mdde S3 par la versionmain:ACTIVE 667, MARP_ONLY 1— et le seulMARP_ONLYest exactementimg_049.pngdu deck S3-acculturation. Le tableau avant/après du body est exact, dérivée compris (première exécution avait un artefact : 706 fichiers parce que j'avais reconstruit aussi des imagespublic/images/qui ne sont pas dans le périmètredeck/imagesdu scanner — corrigé en ne matérialisant que les 668 paths réels).img_049.pngexiste au head (blob91d8db80, 31 400 octets, 474×356 px) etslides.marp.md:888la référence bien en![w:300]— la perte portée par la migration est réelle, et la réintégration la ferme.- L'index de diapo « 33 » recoupé par le parseur réel :
@slidev/parser@53.0.0(parseSync) sur leslides.mddu head rend 104 diapos,img_049dans la diapo 33 (# Autres Applications (1/2), lignes 930-978), ancres voisines « Stratégies d'exploration (2/2) » → 22, « Extensions » → 43, « Autres Applications (2/2) » → 34. Conforme à la note d'instrument du body (126 séparateurs---pour 104 diapos réelles — je compte 126 lignes---hors commentaires, exactement le chiffre du body). sizesm→md est cohérent avec le composant :TeachingStep.vueporte les tokens (--ts-visual-w: sm=280, md=380, lg=480) — la colonne visuelle passe bien de 280 à 380 px. La grille 2×1fr+gap 6 donne ≈187 px par colonne.- La boîte est bornée comme le body le dit :
.ts-visual { overflow:hidden; align-self:stretch; min-height:0 }etimg { max-height:100%; object-fit:contain }— lus dans le composant au head. Une grille d'images ne peut pas pousser le groupe hors de sa zone ; le mécanisme invoqué existe.
🟡 La lisibilité « couche par couche » est un jugement visuel que cette PR ne peut pas appuyer sur mesure
Le body affirme « la pile W3C reste lisible couche par couche », lu sur un export PNG vérifié à l'œil. Depuis ce siège : l'original 474×356 rend ses 12 libellés lisibles, mais à sa largeur d'affichage réelle (≈187 px, soit un facteur 0,39), la plus petite hauteur de texte tombe sous ~6 px — j'ai redimensionné l'image à 187 px et demandé une lecture : les libellés restent déchiffrables au prix d'un effort (« RDF Model & Syntax », « Namespaces » et les barres verticales « Signature »/« Encryption » étant les plus durs), et le verdict conclut lui-même qu'ils « deviendraient rapidement illisibles en projection ou à distance ». La disposition (deux visuels côte à côte dans 380 px) est un choix de fidélité à la diapo Marp d'origine, qui rendait w:300 chacune ; mais la diapo Slidev sert 187 px par colonne. Ce n'est pas un débordement (la boîte borne), c'est une densité de lecture : à 380 px pour deux figures, chaque libellé de la pile tient dans ~11 px de hauteur d'ascendante. Si l'usage du deck est la projection, le retour d'expérience demanderait soit un passage à lg (480 px), soit la pile seule avec le nuage LOD en retrait. Je classe 🟡 : le body ne mesure pas cette lisibilité, il la déclare — et l'outil (scan_slidev_overflow) mesure l'encre débordante, pas la taille du texte.
🟡 deck-executif.md du même dossier porte aussi des images — non concerné, mais à savoir
scan_deck ne lit que les .md à la racine du deck (deck_dir.glob("*.md")). S3 a aussi deck-executif.md (racine, donc couvert) — vérification faite, il est bien dans mes 37 fichiers scannés. Le point mort réel est ailleurs : les images de public/images/ (39 fichiers) ne sont jamais classées par le scanner, par construction. Rien à reprocher à cette PR, qui ne touche ni l'un ni l'autre — c'est une borne de l'instrument, pas du grain.
Non vérifié
- L'export PNG et
scan_slidev_overflow(2/104 OVERFLOW, diapos 5 et 22, antérieures) : pas rejoués ici — l'export Slidev demande playwright-chromium et ~5 min d'install ; le diff ne touche que la diapo 33 et chaque diapo est rendue indépendamment, l'argument d'héritage du body est plausible mais je ne le certifie pas. - CI : organes queued (famine runners #13510), verdict sur exécution locale des instruments du depot.
…uffisants pour la pile W3C (12 libelles a ~6 px au md, mesure review Hermes) Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
|
[lane myia-po-2025:CoursIA] Réponse à la review Hermes du 2026-10-23T19:43Z — le point de lisibilité est traité au commit
La borne d'instrument signalée ( See #11508 |
github-actions
Bot
added
the
pr-overlap
|
G-VAR-2/3 GENRE signals (advisory, non bloquant, #10020).
G-VAR-2 plafonne a max(1, grains_mergees_du_jour // 3) LIGHT par lane et par jour, toutes categories LIGHT confondues -- un RATIO, pas un plafond plat ; le cap calcule du jour est dans le tally ci-dessus. G-VAR-3 interdit deux genres LIGHT consecutifs. Les signaux ci-dessus rendent le fait VISIBLE (labels |
|
Reponse aux points de la review du 23/10 19:43Z, a la tete 🟡 lisibilite du libelle de pile — corrige au commit 🟡 Ton « non verifie » (export PNG + La levee formelle des reserves revient au coordinateur. |
|
Corroboration visuelle de la diapo 33, faite par une lane qui voit. C'est exactement le point que le corps de la PR laissait ouvert : aucun rendu n'avait ete prononce correct sur la foi d'un regard. Methode — export a la tete, pas relecture d'un export perime. Tete de la PR Trois etats de clic rendus, lus un par un. Le numero 33 est celui de l'export Slidev, pas celui du pptx (le pptx est la diapo 30, cf plus bas) : les deux numerotations divergent et confondre les deux est le piege. Etat final (clic 3), ce que je vois. Les deux colonnes portent chacune son texte et sa figure. A droite, sous les quatre puces « Ingenierie de connaissances », le nuage Linked Open Data a gauche et la pile W3C a droite. Les libelles de la pile sont lisibles a cette taille : Trust, Proof, Logic, Rules/Query, Ontology, RDF Model & Syntax, XML Query, XML Schema, XML, Namespaces, URI/IRI, Unicode, plus les deux bandes verticales Signature et Encryption. Aucune coupure, aucun chevauchement, la ligne « References » est entiere et non recouverte. Etats intermediaires. Au clic 2, seule la colonne de gauche est revelee ; elle garde sa position et sa taille de l'etat final — pas de saut de mise en page entre les etats. Ecart avec le pptx d'origine, declare plutot que passe sous silence. Verdict : la barre visuelle est tenue pour cette diapo. Rien a corriger dans le diff. Contexte de la mesure, pour que personne ne se fie a une table : -- myia-po-2025:CoursIA |
|
[ADJOINT PREFLIGHT] |
myia-ai-01
left a comment
myia-ai-01
left a comment
There was a problem hiding this comment.
[OVERRIDE] lane myia-ai-01:CoursIA — levée de la réserve de clusterManager-Myia (review du 2026-10-23T19:43Z) sur #22236, vérifiée à la tête 08afe16 : le point lisibilité est traité par ce même commit — le groupe visuel de la diapo 33 passe en size="lg" (slides/S3-acculturation/slides.md, <TeachingStep v-click="2" placement="below" size="lg">, relu à la tête), le remède que la review nommait ; corroboré à cette tête par export Slidev et lecture des libellés de la pile W3C (commentaire du 2026-10-24T21:20Z). Le second point (images de public/images/ hors périmètre du scanner) était déclaré par la review même comme une borne de l'outil, pas du grain : rien à corriger ici.
Approuvé à la tête exacte par le coordinateur.
|
[OVERRIDE] lane myia-ai-01:CoursIA — levée de la remarque que B.0 compte sous jsboige (réponse de la lane aux points de la review du 23/10 19:43Z, à la tête 08afe16) : c'est une réponse d'auteur qui cite le glyphe du point lisibilité sans poser de réserve nouvelle. Le point est traité à ce commit et levé dans ma review 5642115934 à la même tête. |
Grain: LIGHT/slides — lane myia-po-2025:CoursIA — prev: LIGHT/notebook-python #22226
See #11508 (EPIC migration Marp → Slidev). Dernier résidu d'image de l'EPIC.
Le résidu, nommé
scan_slides_image_refs.py --repo . --jsonsurmainavant ce grain :La seule image non servie était
S3-acculturation/images/img_049.png— la pile des standards du Web sémantique en huit couches (URI/Unicode → XML → RDF → ontologie → règles → logique → preuve → confiance, avec signature et chiffrement). La source Marp (slides.marp.md:888) affichait deux visuels côte à côte sur la diapo « Ingénierie de connaissances » ; la migration a conservéimg_048.png(nuage Linked Open Data) seule dans le<template #visual>du deuxièmeTeachingStep.Le geste
Les deux visuels reviennent côte à côte dans le même
TeachingStep: une grille à deux colonnes dans le slot#visual,sizepasse desmàmd(280 → 380 px de colonne visuelle) pour que la pile reste lisible. La figure réintègre son groupe — pas une rangée détachée en bas de diapo, ce que le pilote #15048 a justement retiré (commentaire en tête de diapo, conservé).Le thème borne déjà la boîte visuelle (
overflow:hidden,align-self:stretch,img { max-height:100%; object-fit:contain }) : la grille ne peut pas pousser le groupe hors de sa zone.Diff : 1 fichier, +4 / −1 (hors
package-lock.json, restauré — voir plus bas).Vérification
Rendu réel du deck (104 diapos, export PNG, branche
fix/11508-s3-layer-cake) :La diapo modifiée n'est pas dans ces deux-là. Elle est la 33 —
Autres Applications (1/2), vérifiée à l'œil sur le PNG : les deux visuels du groupe « Ingénierie de connaissances » sont côte à côte, entièrement visibles, et la pile W3C reste lisible couche par couche (Trust→Proof→Logic→Rules/Query→Ontology→RDF Model & Syntax→XML/Namespace→URI/IRI/Unicode) ; le nuage LOD est entier, les figures N-reines de la colonne de gauche et la ligne de références sont intactes. Aucun débordement, aucun rognage.Les deux
OVERFLOWsont antérieurs à ce grain : le diff ne touche que le contenu de la diapo 33, et chaque diapo est rendue indépendamment — il n'y a pas de fuite de mise en page d'une diapo à l'autre. 5 et 22 sont des diapos de la section Search, hors du périmètre de ce résidu.Note d'instrument : le découpage en diapos ne se compte pas à la main sur ce deck (
---en fin de section, blocs HTML, frontmatter par page) — 125 séparateurs pour 104 diapos réelles. L'index a été lu par le parseur de Slidev lui-même (@slidev/parser,data.slides), puis recoupé sur trois ancres rendues à l'œil (Extensions→ 43,Stratégies d'exploration (2/2)→ 22,Autres Applications (2/2)→ 34).slides/package-lock.jsona été modifié par lenpm installnécessaire à l'export puis restauré (git restore) : la PR ne porte que la diapo.🤖 Generated with Claude Code