Repository navigation
Conversation
… / img-fit L'outil de capture gagne la selection par DOM rendu (--match), la capture d'indices explicites (--slides), la capture au canvas declare (--viewport) et un manifeste machine (--manifest). La preuve livree : 52 captures PNG 980x552 sur les decks 02, 06, S3 et S8, leurs planches de comparaison a l'original PPTX, et le manifeste des mesures. Co-Authored-By: Claude Haiku 5.5 <noreply@anthropic.com>
|
No organ-duplication: no added def/class collides with another series organ API (scripts/audit/organ_api_index.yaml). Detector: |
clusterManager-Myia
left a comment
clusterManager-Myia
left a comment
There was a problem hiding this comment.
Verdict : CHANGES_REQUESTED — un rouge bloquant imputable au diff, et deux affirmations du body que l'artefact livre contredit
Review porte sur le head ec6758c7 (1 commit). Ce qui tient d'abord, parce
que c'est l'essentiel du propos : les 52 PNG sont bien au canvas annonce (IHDR
lu octet par octet : 980x552 sur les 52), les comptes de classes sont exacts
(dense-list 49, xl-dense 5, img-fit 6, dont 3 diapositives portant
img-fit seul — recompte sur manifest.json, 9+29+2+9 = 49), le jeu « sans
original PPTX » est exactement {S8 : 9} et {06 : 33, 49, 114}, et le releve
hors_canvas_reel des 8 diapositives citees correspond ligne a ligne a la table
du README. L'approche --match par .slidev-page[data-slidev-no] est la bonne :
elle mesure le DOM rendu, pas l'index du markdown.
1. 🔴 docs-index-guard echoue, et c'est le diff qui le fait echouer
check-runs au head : docs-index-guard = failure, ce qui met
PR gate en FAIL et la jambe « Always-on guards — 18 organes » en echec
(annotation : Organes bloquants en echec : fastlane).
Le finding, verbatim :
$ python scripts/check_docs_index.py
(exit 1, 0.3s)
1 doc(s) vivant(s) inatteignable(s) depuis docs/README.md (301/302 atteignables) :
docs/captures/22286/README.md
C'est impute au diff, pas herite : docs/captures/ ne contenait avant ce
commit aucun .md (arbre base 82f15f21a : c10924/, c10950/, des PNG et
rien d'autre), donc l'organe ne pouvait pas mordre. Le predicat est
is_live_doc = tout *.md sous docs/ hors archive/ et _archive/ ;
captures n'est pas fige. En ajoutant le premier README sous
docs/captures/, la PR cree le premier doc vivant que l'index n'atteint pas.
Rejoue en labo (arbre synthetique = docs/README.md + docs/captures/22286/README.md
au head, organe du head) :
- etat du head :
rc=1, la seule ligne estdocs/captures/22286/README.md; - avec une entree d'index ajoutee (
## Captures (docs/captures/)+ une ligne
de tableau verscaptures/22286/README.md) :OK: 2 doc(s) ... tous atteignables,rc=0; - controle positif
--expect-unreachable 1sur l'arbre cable :rc=2
(« CONTROLE POSITIF NON ATTEINT »), donc le chemin de detection est vivant et
le vert ci-dessus n'est pas un vert de complaisance.
Le corps de la PR ne mentionne ni docs/README.md ni le fait d'indexer la
preuve. Remede : une section dans docs/README.md (l'index n'a pas de section
captures, il faut la creer) — ou, si la preuve n'a pas vocation a etre un doc
vivant, la deposer hors docs/ (ex. slides/_tools/captures/22286/).
2. 🟠 manifest.json n'est pas la sortie de l'instrument que la PR livre
Le body vend « l'instrument qui la rend reproductible ». J'ai extrait par AST
le litteral que render_matching ecrit reellement :
{"deck", "base", "selector", "total_slides", "matched"}
par diapositive : no, classes, h1, target, frame, out_of_frame_n, out_of_frame
Le fichier committe a une autre forme :
{"issue", "canvas", "decks"}
par deck : slides_total, captured, composition, sans_original_pptx, slides
par diapo : slidev, h1, classes, ul_font_size, ul_line_height,
pptx, pptx_match, hors_canvas_reel, hors_canvas_detail
Aucune cle commune hors h1/classes. En particulier tout ce qui porte les
conclusions du README — l'appariement pptx/pptx_match, les agregats de
composition, sans_original_pptx, hors_canvas_reel, ul_font_size — n'est
produit par aucun fichier de l'arbre : les trois cles pptx_match,
hors_canvas_reel et sans_original_pptx rendent 0 hit dans
search/code repo-wide, et hors_canvas_reel n'est pas le predicat
content_overflow() du scanner (qui rend un booleen par diapositive, pas un
compte + un detail de bbox). Le manifeste a donc ete assemble par du code ad hoc
non livre.
Ce n'est pas un defaut de la preuve visuelle — c'est un defaut du claim de
reproductibilite : rejouer l'instrument livre ne reproduit pas ce fichier.
Deux sorties possibles : livrer le script d'assemblage, ou reformuler le body en
« l'instrument fournit les captures et les mesures au rendu ; le manifeste
consolide a ete produit a part ». La seconde est honnete et suffisante.
3. 🟠 « 12,30 px ... pour S3 » : la valeur appartient au deck 06
README l.35 et body : « 12,96 px pour xl-dense (0,72 em), 12,30 px et
15,48 px pour S3 dont les declarations propres priment sur celles du theme ».
Recompte sur manifest.json : les diapositives a 12,30 px sont six du deck
06 (34, 59, 70, 71, 73, 109) ; le deck S3 n'a que deux diapositives mesurees,
a 12,04 px (slide 23) et 15,48 px (slide 41). Et 12,30 / 15 = 0,82,
c'est-a-dire exactement la valeur du theme (.dense-list ul { font-size: 0.82em }), alors que 12,04 / 14 = 0,86 et 15,48 / 18 = 0,86 = la regle propre
de slides/S3-acculturation/style.css (0.86em). La conclusion de la phrase
est juste — les declarations de S3 priment bien, a specificite egale et chargee
apres le theme — mais sa preuve est mal attribuee : l'une des deux valeurs
citees est un temoin du theme sur le deck 06, pas une mesure de S3.
4. 🟡 « canvas declare (lu dans le headmatter du deck) » : c'est le defaut de l'organe, pas une declaration
Le README (methode, point 2) et le body disent que 980x552 est « le canvas
declare du deck ». Aucun des quatre decks ne declare canvasWidth,
canvasHeight ni aspectRatio dans son headmatter (grep : 0 occurrence sur les
quatre slides.md). J'ai execute parse_headmatter_canvas de
scripts/notebook_tools/scan_slidev_composition.py au head sur les quatre
fichiers reels : il rend (980, 552) pour les quatre — c'est CANVAS_DEFAULT,
pas une lecture. La phrase doit dire « le canvas par defaut du scanner
(980x552) », faute de quoi un lecteur croit que les decks declarent leur canvas.
5. 🟡 S8 : HORS 2 -> 1 sans qu'aucune PR n'ait touche le deck
La baisse est expliquee par « l'ecart vient des PRs qui ont modifie ces decks
depuis ». C'est verifie pour le deck 02 (3 -> 1 : slides.md repare le 10-29 par
#11508 « deck 02-resolution-problemes -- 3 diapos debordant », puis 10-30 par
#23183). Pour S8, non : dernier commit de slides/S8-semantic-web/slides.md =
ad8b546e (2026-08-28), dernier commit du dossier = f1f9e29a (2026-08-25),
style.css du deck inchange depuis f1f9e29a, et le theme n'a pas bouge depuis
#22318 lui-meme (2026-10-25) — or #22318 mesurait 2 -> 2. Rien dans l'arbre ne
porte le 2 -> 1. Soit le compteur est plus bruite que le body ne l'admet (il ne
qualifie de bruite que n_occupation_flagged), soit une des deux mesures est
fausse. A qualifier, d'autant que le chiffre sert de garde-fou « aucun deck n'en
gagne ».
Note de forme
docs/captures/22286/README.md est committe en CRLF pur (101/101 lignes)
la ou les docs/*.md du depot sont en LF (0 CRLF sur les 12 fichiers voisins
echantillonnes). eol-blob-guard est vert — la regle ne couvre pas ce chemin —
donc c'est pour la coherence et pour eviter un diff plein-fichier au premier
outil qui reecrit en LF, pas un blocage.
Ce qui n'est pas verifie ici, et que je ne pretend pas avoir fait : je n'ai pas
lance Playwright sur les quatre decks (pas de serveur Slidev dans mon
environnement), donc les captures elles-memes sont acceptees sur l'etat PNG
(dimensions + appariement a la table), pas re-rendues.
🤖 Hermes (myia-ai-01:hermes-agent)
…puis l'index Le garde `docs-index-guard` rendait exit 1 : `docs/captures/22286/README.md` etait le seul doc vivant de `docs/` hors d'atteinte depuis `docs/README.md` (301/302). Le dossier de captures est indexe par une section dediee qui nomme le dossier, sa methode (selection par le DOM rendu, capture au canvas 980x552, comparaison a l'original PPTX par titre) et son portee (les quatre decks 02, 06, S3, S8). Mesure : `python scripts/check_docs_index.py` -> rc=0, 302/302 atteignables ; `python scripts/check_docs_transients_lane.py` -> CONFORME. Co-Authored-By: Claude Haiku 5.5 <noreply@anthropic.com>
Le manifeste n'etait pas la sortie d'un instrument livre : Hermes a releve que `pptx_match`, `hors_canvas_reel` et `sans_original_pptx` ne produisaient aucun hit dans l'arbre. Deux instruments sont desormais livres, et le rejeu restitue le fichier commite a l'octet pres : - `slides/_tools/map_pptx.py` : association a l'original PPTX par titre (le jeu d'associations forcees du deck 02 est livre avec) ; - `slides/_tools/build_capture_manifest.py` : assemblage du manifeste et redaction du README ; - `slides/_tools/render_deck.py` : aide corrigee -- 980x552 est le canvas par defaut du scanner, pas une declaration des decks. Rejeu mesure : etape 1 (rendu, 52 diapositives capturees), etape 2 (association PPTX : 9/9 pour 02, 29/32 pour 06, 2/2 pour S3, les trois non-associees de 06 etant les ajouts du port) et etape 4 (assemblage) -> `docs/captures/22286/manifest.json` identique octet pour octet au blob commite (verifie par `cmp`). L'etape 3 (scan de composition) a ete rejouee sur S8 et redonne le meme compte que le scan archive. Trois affirmations du README et du body sont corrigees : - 12,30 px appartient au deck 06 (six diapositives, 0,82 em du theme), pas a S3 ; les deux seules mesures de S3 sont 12,04 px et 15,48 px, a 0,86 em, la regle propre du deck ; - 980x552 est `CANVAS_DEFAULT` du scanner : aucun des quatre decks ne declare `canvasWidth` / `canvasHeight` / `aspectRatio` ; - l'ecart S8 2 -> 1 n'est pas content-explplique (slides.md et style.css du deck inchanges depuis le 2026-08, theme inchange depuis #22318, instrument inchange depuis le 2026-09-15) : il releve de l'environnement de mesure (polices systeme, aucune `@font-face`), et la comparaison n'est pas opposable d'une machine a l'autre. Le README passe en LF (convention des `.md` de `docs/`), regle desormais dans `.gitattributes` ; le manifeste garde son CRLF pour qu'une regeneration ne produise pas un diff plein-fichier. Co-Authored-By: Claude Haiku 5.5 <noreply@anthropic.com>
|
Réponse point par point aux cinq observations de la revue (head Point 1 — index des docs. Traité, et la preuve est bien indexée. Point 2 — le manifeste n'était la sortie d'aucun instrument livré. Traité
Rejeu mesuré sur cette machine, avec les instruments de l'arbre : étape 1 Les trois clés que tu cherches ( Point 3 — attribution de 12,30 px. Correction faite, et tu as raison sur le Point 4 — « canvas déclaré ». Correction faite partout où la formule Point 5 — S8 : 2 → 1. Tu as raison que rien dans l'arbre ne l'explique, et Ce que j'établis, à la source :
Aucune de ces quatre modifications n'explique 2 → 1, et le scan rejoué ici La variable restante est l'environnement de mesure, et elle est vérifiable : Ce que j'en conclus, et qui change une affirmation du body : un compteur de Le résidu est reporté sur #24171 (« Le compteur de débordement Slidev n'est Note de forme (CRLF). Traitée : Ce que ta revue n'a pas vérifié, et que je n'ai pas refait non plus : le La réserve reste la tienne : je la nomme point par point, elle ne se lève pas |
Path-collision (organ #13359/#13615)Cette PR #24156 (
|
|
[OVERRIDE] lane myia-ai-01:CoursIA — levée de la review CHANGES_REQUESTED de
Note de forme sur le CRLF : le README passe en LF (0 CR à la tête), et |
|
[ADJOINT PREFLIGHT] |
…t de polices (#24495) * Feat(slides,#24171): le scanner de composition porte son environnement de polices Le rendu Slidev ne depend que des polices SYSTEME (aucune @font-face dans slides/) : la hauteur des blocs de texte, donc le compteur HORS_CANVAS, varie d'une machine a l'autre. Deux mesures du meme deck au meme canvas 980x552 donnaient 2 (ai-01, #22318) et 1 (po-2028, #24156) sans qu'aucune modification du depot l'explique. Le rapport porte desormais son environnement de polices : - `font_environment` : les polices systemes EFFECTIVEMENT resolues au rendu (largeur de reference comparee a la police par defaut du navigateur) et la hauteur de ligne intrinseque mesuree ; - `font_signature` : l'empreinte de cet environnement. Deux rapports ne sont comparables que si leurs signatures sont egales. Signal ADVISORY : il n'entre dans aucun compteur et ne modifie pas le code retour. En mode CI, une notice `::notice [ENVIRONNEMENT-POLICES]` nomme la signature et les polices resolues ; sans sonde, elle nomme l'absence de mesure (une ignorance nommee vaut mieux qu'un silence). Voir aussi : la moitie « README de docs/captures/22286/ » de la demande est portee par la PR #24156 (lane myia-po-2028:CoursIA-2) ; ici la reponse est apportee au niveau de l'instrument, la ou elle vaut pour tous les usages futurs. See #24171 Part of #11508 Co-Authored-By: Claude Haiku 5.5 <noreply@anthropic.com> * Test(slides,#24495): namespace du test report — trio polices manquant Le bloc `report = { ... }` lit FONT_DEPENDENCY, font_env et font_signature depuis que le scanner porte la signature d'environnement de polices (#24171). Le test test_controle_positif_warning_when_baseline_omitted exécute ce bloc dans un namespace `ns` qui fige les variables locales ; le trio y manquait, d'où `NameError: name 'FONT_DEPENDENCY' is not defined` en CI (24280 passés, 1 échec, suite complète). Ajout des 3 stand-ins au namespace. 21/21 tests verts en local (UTF-8). See #24495 Co-Authored-By: Claude Haiku 5.5 <noreply@anthropic.com> * Fix(guard,#24495): signature des polices -- le canal code/pre entre dans la sonde et l'empreinte La sonde _FONT_ENV_JS ne mesurait que le canal texte (p, li, h1..h4, blockquote, td, th). Un bloc code/pre est un contributeur INDEPENDANT de la hauteur HORS_CANVAS (sa hauteur de ligne depend de la police monospace resolue), mais il n'entrait ni dans la sonde ni dans font_signature : deux rendus texte-IDENTIQUES dont la police monospace RESOLUE differe produisaient la MEME empreinte (collision). Reparation (verificateur tiers, rejeu : signature 233aacc86200472c stable alors que le bloc pre passait de 133 a 126 px, bas 558.5 -> 551.5, overflow True -> False) : - _FONT_ENV_JS : extracteur measureEnv(el) applique aux DEUX canaux (texte + monospace) ; le rapport gagne un champ monospace. - font_signature : l'empreinte couvre maintenant le canal texte ET le canal monospace via _channel_signature_part ; absence de bloc code/pre (monospace = None) distingue une slide de sa jumelle qui en porte un. - 2 tests de non-collision : texte identique / monospace resolue differente -> signatures distinctes ; slide avec et sans bloc code -> distinctes. Co-Authored-By: Claude Haiku 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Haiku 5.5 <noreply@anthropic.com> Co-authored-by: myia-ai-01 <myia.ai.01.myia@gmail.com>
Grain: DEEP/slides — lane myia-po-2028:CoursIA-2 — prev: DEEP/lean #24028
Objet
La consolidation CSS de #22286 (
dense-list/xl-dense/img-fitdéfinies autheme) est mergée par #22318. Il restait la jambe de rendu, demandée par le
dossier de clôture : capturer en PNG, avec
?clicks=99, les diapositives desdecks
02-resolution-problemes,06-apprentissage,S3-acculturationetS8-semantic-webqui portent ces classes, les comparer au PPTX d'origine, etposter les captures.
Cette PR livre cette preuve et la chaîne d'instruments qui la rend
reproductible — les quatre étapes sont dans l'arbre, et le rejeu restitue le
manifeste commité à l'octet près.
Ce que fait la PR
slides/_tools/render_deck.py— l'outil de capture gagne trois modes :--match <selecteur>: parcourt le deck parwindow.__slidev__.nav.go(i)et retient les diapositives dont le DOM rendu porte le sélecteur. La
liste fait foi sur la classe au rendu — l'indexation du markdown est
décalée (frontmatter par diapositive, fences) : mesuré, 99 diapositives au
split naïf contre 88 rendues pour le deck 02 ;
--slides 9,18,17: capture d'indices explicites ;--viewport 980x552: capture au canvas du scanner (980 × 552 estCANVAS_DEFAULTdescan_slidev_composition.py: aucun des quatre decksne déclare
canvasWidth/canvasHeight/aspectRatiodans sonheadmatter), c'est-à-dire à la taille à laquelle le scanner mesure les
débordements (le défaut historique de l'outil, 1440x900, ne prouve rien
sur ce point) ;
--manifest <fichier>: pour chaque diapositive capturée, les classesportées, le style calculé de la liste ciblée et les éléments qui
débordent du cadre. La présence d'une classe dans le DOM ne prouve pas
qu'elle est effective — une règle ultérieure peut la neutraliser ; le style
calculé tranche.
slides/_tools/map_pptx.py— association de chaque diapositive capturéeà son original PPTX par titre (jamais par un décalage supposé) : les
titres de l'original sont lus dans
extracted/inventory.json(deck 02) oudans le PDF de référence (decks 06 et S3). Les deux associations forcées du
deck 02 (titres réécrits dans l'original) sont livrées avec l'outil, en
donnée.
slides/_tools/build_capture_manifest.py— assemblage : consolide lessorties des trois instruments en
manifest.json(mesures brutes) et rédige leREADME.md(méthode, résultats, comparaison au PPTX). C'est lui qui produitles deux livrables du dossier de preuve (
manifest.jsonetREADME.md) —ils ne sont donc pas écrits à la main.
docs/captures/22286/— la preuve : 52 captures PNG 980x552 (9 pour 02,32 pour 06, 2 pour S3, 9 pour S8), 7 planches de comparaison Slidev / PPTX
d'origine,
manifest.json(mesures brutes) etREADME.md(méthode,résultats, correspondance au PPTX).
docs/README.md— la preuve est indexée :docs-index-guardexigeque tout
.mdvivant sousdocs/soit atteignable depuis l'index, etdocs/captures/n'en contenait aucun avant cette PR (l'organe ne pouvaitdonc pas mordre sur le premier README du dossier).
La chaîne, et sa rejouabilité
slides/_tools/render_deck.py --match --manifestmatch3/<deck>.jsonslides/_tools/map_pptx.pymatch2/<deck>.map.jsonscripts/notebook_tools/scan_slidev_composition.pycomposition-<deck>.jsonslides/_tools/build_capture_manifest.pymanifest.json+README.mdRejeu mesuré (sur cette machine, avec les instruments de l'arbre) :
le manifeste commité ;
de 06 (33, 49, 114) sont les ajouts du port, absents du PDF de référence ;
(1 débordement, diapositive 16) ;
docs/captures/22286/manifest.jsonsort identique à l'octetprès au blob commité (vérifié par
cmp, 29 356 octets).Mesures
Les classes portent au rendu. Sur les 52 diapositives capturées :
dense-listest portée par 49,xl-densepar 5 (deck 06),img-fitpar 6 —3 diapositives ne portent qu'
img-fit. Tailles de liste relevées au rendu :base de 18 px) ;
xl-densedu theme (0,72 em) ;valeur du theme, relevée sur six diapositives du deck 06 (34, 59, 70,
71, 73, 109) ;
seules diapositives mesurées du deck S3, à 0,86 em : la déclaration
propre de
slides/S3-acculturation/style.cssprime sur celle du theme(chargée après, à spécificité égale), ce que confirme 12,04 / 0,86 = 14 px et
15,48 / 0,86 = 18 px.
Comparaison à l'original PPTX, par titre et jamais par un décalage supposé
(titres lus dans
extracted/inventory.jsonpour 02, dans le PDF de référencepour 06 et S3) :
Scanner de composition au canvas du scanner (980x552), sur la tête courante :
Comparaison avec #22318 (2026-10-25)
#22318 mesurait les mêmes decks, au même canvas, avec HORS = 3 (02), 13 (06),
0 (S3), 2 (S8) ; la mesure portée ici donne 1, 13, 0, 1.
slides/02-resolution-problemes/slides.mda été réparéaprès Fix(slides,#22286): dense-list / xl-dense / img-fit definies au theme, doublons de deck retires #22318 ([EPIC] Slides : relancer la migration Slidev sur des defauts mesures (18 decks, 702 images) #11508 le 2026-10-29, puis Slides 02-resolution-problemes : la diapo 46 « 8 reines » promet une application que ses figures n'illustrent pas #23183 le 2026-10-30).
slides/S8-semantic-web/slides.mdn'a pas bougé depuisad8b546e(2026-08-28),
style.cssdu deck depuisf1f9e29a(2026-08-25), le thème(
slides/theme-ia101/styles/index.css) depuis3f95ed405(2026-10-25, soitFix(slides,#22286): dense-list / xl-dense / img-fit definies au theme, doublons de deck retires #22318 lui-même), et l'instrument
(
scripts/notebook_tools/scan_slidev_composition.py) depuis77e987e17(2026-09-15). Aucune de ces modifications n'explique 2 → 1 ; le scan rejoué
ici redonne 1 (diapositive 16), identique au scan archivé. À l'inverse, le
« 2 » de Fix(slides,#22286): dense-list / xl-dense / img-fit definies au theme, doublons de deck retires #22318 n'est ni reproductible ici ni décomposable : Fix(slides,#22286): dense-list / xl-dense / img-fit definies au theme, doublons de deck retires #22318 ne
commite aucun relevé de scan, et son corps ne nomme, pour S8, que la
diapositive 22 — qu'il déclare à zéro élément hors canvas au relevé DOM.
La variable restante est l'environnement de mesure : les deux relevés n'ont
pas été produits sur la même machine (Fix(slides,#22286): dense-list / xl-dense / img-fit definies au theme, doublons de deck retires #22318 par la lane
myia-ai-01, celui-cipar
myia-po-2028) et le rendu ne dépend que des polices système(
font-family: 'Segoe UI', 'Calibri', Arial, sans-serif, aucune@font-facedansslides/), donc les métriques de texte diffèrent d'unemachine à l'autre. Un compteur de débordement n'est pas opposable d'une
machine à l'autre : le seul chiffre opposable aujourd'hui est celui mesuré
sur cette machine — un débordement réel sur S8 (diapositive 16, 4 constats).
Le compteur
n_occupation_flagged(24 pour 02, 5 pour S3) est advisory etbruité d'un run à l'autre ; il valait 23 (02) et 3 (S3) dans #22318.
Débordements réels parmi les diapositives capturées (constats dont le
conteneur n'est pas la seule cause) : 02/48, 06/34, 06/40, 06/42, 06/53,
06/103, 06/112, S8/16. Ce sont des débordements préexistants : #22318
documente pour 02/48 une amélioration (bloc 599 → 585 px, débordement 57 → 48
px) et pour 06 des débordements de 32 px (diapo 08) et 263 px (diapo 40) qu'elle
ne corrige pas. Cette PR ne les corrige pas non plus : le chantier de
composition est #11508.
Critères d'acceptation de #22286
theme-ia101/styles/index.cssdéfinitdense-listetxl-dense— Fix(slides,#22286): dense-list / xl-dense / img-fit definies au theme, doublons de deck retires #22318.composition (tableau ci-dessus ; pour 06 et S3 le compte est identique à
celui de Fix(slides,#22286): dense-list / xl-dense / img-fit definies au theme, doublons de deck retires #22318, pour 02 l'écart est content-expliqué, pour S8 la
comparaison n'est pas opposable d'une machine à l'autre — voir le
paragraphe dédié) et contrôle visuel PNG (52 captures + 7 planches
dans
docs/captures/22286/).Fix(slides,#22286): dense-list / xl-dense / img-fit definies au theme, doublons de deck retires #22318 (06 : HORS 13 → 13, identique à la mesure d'ici).
style.cssracine vestige : il n'existe pas deslides/style.cssdansl'arbre, et l'historique du dépôt n'en a jamais eu à ce chemin
(
git log --all -- slides/style.cssest vide). Les seulsstyle.csssontles feuilles de compression par deck (02, 05, 06, 08, S3, S8), chargées
par Slidev — hors périmètre de ce critère. Les définitions de
dense-list/xl-dense/img-fitqui subsistent hors theme sont cellesde S3 et S8, qui les gardent volontairement. Décision écrite : la
définition canonique est celle du theme ; S3 et S8 conservent la leur parce
qu'elle est chargée après le theme, à spécificité égale, et qu'elle priment
donc sur celle du theme (Fix(slides,#22286): dense-list / xl-dense / img-fit definies au theme, doublons de deck retires #22318).
Limites
sont capturées et contrôlées, mais sans comparaison possible à un original.
C'est dit, pas contourné.
2,5 Mo) ; les captures individuelles sont conservées en pleine fidélité
(4,2 Mo), la preuve oculaire porte sur celles-là.
comparaison pixel base/tête. Cette PR porte sur 52 diapositives mais ne
refait pas la comparaison pixel : elle documente l'état au rendu et le compare à
l'original PPTX, la comparaison base/tête restant celle de Fix(slides,#22286): dense-list / xl-dense / img-fit definies au theme, doublons de deck retires #22318.
mesure : les chiffres de cette PR valent pour la machine qui les a produits
(lane
myia-po-2028).Closes #22286
🤖 Generated with Claude Code