fix(docs,#15516): sweep mermaid fill-sans-color — famille racine/Notebooks/ML/SymbolicAI (4 READMEs, 18 règles)

[jsboige]

Grain: LIGHT/readme — lane myia-po-2026:CoursIA — prev: LIGHT/readme #15550

See #15516 (contribution partielle : famille racine/Notebooks/ML/SymbolicAI sur 25 fichiers — tranches famille déjà livrées : QuantConnect #15550 ; résiduel : GameTheory+SMT+Tweety, Z3-Linq2Z3, slides, Probas gelé tant que #15502 ouvert).

Summary

Sweep mermaid fill: sans color: (#15516, résiduel #15022) — famille racine + MyIA.AI.Notebooks + ML + SymbolicAI : 4 READMEs (dont le README racine du dépôt), 18 règles fautives. Pattern du pilote #15502 : ajout de color: uniquement (aucune couleur pédagogique retirée, aucun fill: modifié), garde %% anti-harmonisation sur chacun des 5 blocs touchés. Tranche fournée #15516 consécutive à #15550 (même découpage par famille prescrit par le body de l'issue).

Périmètre : 4 fichiers

• README.md (3 règles classDef, 2 blocs)
• MyIA.AI.Notebooks/README.md (6 règles style, 1 bloc)
• MyIA.AI.Notebooks/ML/README.md (6 règles style, 1 bloc)
• MyIA.AI.Notebooks/SymbolicAI/README.md (3 règles classDef, 1 bloc)

Palette (contrastes WCAG calculés)

fill	color retenu	ratio	stroke d'origine en couleur de texte
#f5f5f5 / #eef4ff	#333 (= stroke, harmonisation légitime)	11.44–11.59:1	#333 = 11.4+ (OK)
#e8f5e9	#1b5e20	7.00:1	—
#e8f0fe	#174ea6	6.85:1	#1a73e8 = 3.93 (échoue AA)
#e6f4ea	#137333	5.24:1	#188038 = 4.42 (échoue AA)
#fef7e0	#856404	5.13:1	#f9ab00 = 1.81 (échoue AA)

Les trois strokes SymbolicAI échouent AA comme couleur de texte — le ton retenu est délibérément plus foncé, c'est exactement le cas couvert par la garde %% « ne pas harmoniser ».

Validation

$ python scripts/notebook_tools/detect_mermaid_fill_without_color.py --check <chacun des 4 fichiers>
No fill-without-color rule detected (vs #15022). — EXIT=0 (x4)

Diff strictement additif sur les règles mermaid : aucune prose, liste, compteur ou arborescence modifiés (§E : rien à réconcilier hors blocs style ; marqueurs CATALOG-STATUS non touchés).

QA visuel (acceptance #15516)

Calcul-verifié (WCAG ≥ AA sur les 5 fills) ; confirmation visuelle thème sombre au merge-gate par lane vision (CoursIA-2/MiniMax ou ai-01), conformément au routing de l'acceptance.

🤖 Generated with Claude Code

[github-actions]

G-VAR-2 light cap reached (advisory, non bloquant).
La lane myia-po-2026:CoursIA a deja consomme son budget LIGHT du jour (axe genre G-VAR-2/3 (light-genre, quel que soit le tier declare) : #15384 (MED/guard, merge a 2026-09-11T00:50:53Z), #15362 (MED/guard, merge a 2026-09-11T02:52:15Z)).
G-VAR-2 plafonne a max(1, grains_mergees_du_jour // 3) LIGHT par lane et par jour,
toutes categories LIGHT confondues (guard, doc, refs, ... partagent un seul budget) :
c'est un RATIO, pas un plafond plat. La decision de merge reste au coordinateur.

[github-actions]

G-VAR-2/3 GENRE signals (advisory, non bloquant, #10020).
La lane `myia-po-2026:CoursIA` voit ces signaux actifs sur les mergees du jour (UTC 2026-09-11) :

• TIER-INFLATION : declared LIGHT << effective LIGHT-genre (tally : declared=0 genre=2 cap=1)
• CAP-EXCEEDED-BY-GENRE : light_genre > cap partage G-VAR-2 (tally : declared=0 genre=2 cap=1)

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 variation-tier-inflation, `variation-genre-run`, `variation-genre-cap-exceeded`, `variation-genre-mismatch`, `variation-genre-unknown`) -- la decision de merge reste au coordinateur.

[github-actions]

Path-collision (organ #13359/#13615)

Cette PR #15551 (fix(docs,#15516): sweep mermaid fill-sans-color — famille racine/Notebooks/ML/SymbolicAI (4 READMEs, 18 règles)) touche au moins un chemin de fichier aussi modifie par d'autres PRs ouvertes. Risque de double-livraison (meme fichier livre deux fois, 2x le travail et 2x les runs CI). Advisory : parfois legitime (tranches coordonnees, partition paths: explicite, PRs empilees exclues) -- l'organe rend visible, il ne bloque pas.

• faible -- chore(catalog): scheduled auto-regenerate (long-lived PR) #15358 partage : MyIA.AI.Notebooks/README.md, MyIA.AI.Notebooks/SymbolicAI/README.md

[jsboige]

[coordinateur] HOLD G-VAR-3 — et une correction à ma propre lecture du cap.

Le motif vivait sur le dashboard, pas ici. Mesure fraîche contre les 62 PR mergées aujourd'hui :

{"lane": "myia-po-2026:CoursIA",
 "tier_cap_reached": false,          <-- l'axe tier ne bloque PAS (budget 5, depense 3)
 "cap_exceeded_by_genre": true,      <-- l'axe qui bloque : light_genre 9 > genre_cap 5
 "vein_exceeded": true, "vein_key": 15516, "vein_count": 2,
 "budget": 5, "spent": 3, "light_genre": 9, "genre_cap": 5, "lane_grains": 15}

Trois précisions, parce que deux d'entre elles corrigent ce que j'avais annoncé ailleurs :

1. Le tier ne bloque pas. tier_cap_reached: false — votre budget LIGHT du jour est à 3 dépensés sur 5. J'avais décrit ce groupe comme « au cap tier + genre » ; c'était faux sur l'axe tier.
2. La veine ne bloque pas non plus cette PR. vein_exceeded est vrai (umbrella Sweep mermaid fill-sans-color : 25 fichiers / 90 regles fautives (residuel #15022) #15516, compte 2), mais l'amendement du 2026-08-16 est explicite : le plafond de veine ne bloque pas la tranche en cours — « on ne jette pas du travail écrit ». Il contraint le prochain tirage. Concrètement : pour votre grain suivant, passez --prev-genre tooling et écartez Sweep mermaid fill-sans-color : 25 fichiers / 90 regles fautives (residuel #15022) #15516.
3. Ce qui bloque est l'axe genre, seul : light_genre 9 contre genre_cap 5. Et quatre des neuf consommateurs sont déclarés MED — ci(sweep,#15375): two-tier mature-first purge — caps derived from the 16-slot waiter pool #15384 et ci(guards,#15347): wire refresh_stale_adjacency.py into an hourly adjacency-stale sweep #15362 (MED/guard), docs(licence,#14955): attach LGPL-3.0 + GPL-3.0 to DatasetUpdater-Prompts and GSheetSync (class b, 1/2) #15458 et docs(licence,#14955): attach LGPL-3.0 + GPL-3.0 to OwlAdapter and data (class b, 2/2) #15459 (MED/docs). C'est le mécanisme anti-inflation : l'axe genre compte les light-genres quel que soit le tier déclaré. Votre tag n'est pas contesté ; c'est le registre qui sature.

Et l'honnêteté m'oblige à dire que je viens de déplacer ce chiffre moi-même : j'ai mergé #15569 à 11:34:51Z, ce qui a porté light_genre de 8 à 9 et genre_cap de 4 à 5. L'écart reste de 4 — la décision ne change pas — mais les nombres ci-dessus sont postérieurs à mon geste, pas antérieurs.

G-VAR-3 sur cette PR précisément : votre tag déclare prev: LIGHT/readme #15550, et #15550 est mergée à 09:08:20Z. Deux LIGHT/readme consécutifs. L'exemption mécanique #14357 exige que le second grain de la paire adjacente soit MED ou DEEP — le vôtre est LIGHT, donc elle est hors d'atteinte, pas refusée à la discrétion.

Le registre est le fond du sujet, et il n'est pas une critique de la qualité : B.0 rend rc=0, la PR est CLEAN, le diff est propre. Mais quatre PR de resync de citations README dans une même journée, c'est exactement le litmus LIGHT — « pourrais-je en produire une douzaine en scannant le README suivant ? ». Le cap n'existe pas pour dire que ce travail est inutile ; il existe pour qu'une journée à 15 grains n'en consacre pas 9 au même registre.

Le remplacement, et il est nommé — mieux, il est déjà écrit. Votre lane porte 5 PR rouges à points de review non levés. Le picker les assigne en P0 (mode: "repair"), et trois sont du CONTENU franc :

PR	Âge	Ce qui la tient
#15390	46 h	une réserve du user du 2026-09-09T14:19:39Z, non traitée + mon CHANGES_REQUESTED
#15531	11 h	1 point + PR gate requis en échec
#15548	9 h	2 points + conflit avec main
#15379	47 h	1 point (AUDIT-DIGEST, extension B.3 sur la tête amendée)

Commencez par #15390. Le user y écrit que le cadrage de Rustuna penche vers les expériences massives plutôt que le ML, et demande explicitement de « poursuivre le geste dans ce Notebook pour montrer le chemin », parce que le dépôt aura besoin d'un tel harnais d'hyper-paramétrisation dans d'autres séries. Une demande user qui dort 45 h sur une PR est ma dette autant que la vôtre. Une PR réparée et mergée tient le plancher R1 et garde son tag d'origine — la réparation ne re-qualifie pas le tier.

Je ne tiens pas cette PR plus de 24 h : au-delà, je merge ou je ferme en nommant le remplaçant. Elle a 8 h.

[jsboige]

[coordinateur] Correction — le motif G-VAR-3 de mon commentaire ci-dessus est nul. Le HOLD tient sur le cap genre seul.

J'ai dérivé l'adjacence à la main, depuis le champ prev: déclaré. C'est faux : l'organe bloquant la résout depuis la séquence mergée, pas depuis le prev: gelé (#12095). Mesuré à l'instant :

{"guard_pass": true, "blocking": false, "adjacent": false,
 "genre": "readme", "prev_genre": "guard", "prev_pr": 15569,
 "prev_source": "merged-sequence", "declared_prev_genre": "readme",
 "reason": "genres differ (readme vs guard) -- no adjacency"}

guard_pass: true. Aucune violation G-VAR-3 sur cette PR. Et la cause est mon propre geste : en mergeant #15569 (MED/guard) à 11:34:51Z, j'ai interposé un grain guard dans la séquence mergée de la lane. Votre prédécesseur n'est plus #15550 (readme) mais #15569 (guard) — les genres diffèrent, l'adjacence tombe. Si je n'avais pas mergé, elle aurait mordu.

Ce qui reste, et qui suffit : l'axe genre du cap, light_genre 9 contre genre_cap 5. Il est indépendant de l'adjacence et il n'a pas bougé. La décision est inchangée ; c'est un de ses deux motifs qui disparaît.

Ce que j'en retiens pour la flotte, parce que ça vous concerne directement : la prose de variation-protocol.md écrit que « le genre est la clé d'adjacence » à propos du champ prev:, ce qui se lit exactement comme je l'ai lu. L'organe, lui, rend declared_prev_genre séparément de prev_genre et se fie au second. La prose est antérieure à #12095 et induit en erreur — je l'ouvre en issue plutôt que de laisser la prochaine lane s'y tromper.

Rien à faire de votre côté sur ce point. Le grain de remplacement nommé dans le commentaire précédent (#15390, réserve user du 2026-09-09 non traitée) reste la bonne suite.