BRI-304 — Corrections drifts Uimmo (à faire à la main dans Figma)¶
Fiche d'exécution. Chaque drift = un état, une action concrète dans Figma, une précaution, une vérif. Fichier : 🎨 Uimmo (
yEPrXyd3donmRXv4K7kHtN) → panneau Variables locales / Styles de texte. ⚠️ Uimmo est publié : après chaque lot de modifs, publier la mise à jour de bibliothèque pour propager. Ordre conseillé : commencer par le plus sûr (D1), finir par les décisions design (D2/D6). 💡 Conseil général : fais ça sur une branche Figma (menu fichier → Create branch), review, puis merge.
D1 — Renommer brandborder500 (casse) ✅ sûr¶
Problème : Bricks specific/brandborder500 (b minuscule) casse la convention de brandBorder300 / brandBorder400.
Action :
1. Panneau Variables locales → collection Colors → groupe Bricks specific.
2. Trouver brandborder500 (clé ac5bb2b4…).
3. Double-clic sur le nom → renommer en brandBorder500.
Précaution : aucun risque — les bindings suivent l'id de la variable, pas son nom. Aucun écran ne casse.
Vérif : le groupe Bricks specific affiche désormais brandBorder300 / 400 / 500 cohérents.
D4 — Core/white dans 2 collections 🔍 vérifier (probable faux positif)¶
Problème supposé : Core/white existe dans Colors (ea000bcf…) et Primitives (ed47f31a…).
À vérifier AVANT de toucher — c'est sans doute légitime (pattern primitive → alias) :
1. Ouvre Primitives → Core/white : sa valeur doit être un hex brut (#ffffff). C'est la primitive de base.
2. Ouvre Colors → Core/white : regarde sa valeur.
- Si elle pointe vers la primitive (alias, petite icône de lien / nom de variable au lieu d'un hex) → ✅ c'est normal, ne rien faire. Architecture saine.
- Si c'est un hex brut indépendant (#ffffff saisi en dur) → 🎯 vrai doublon : édite Colors/Core/white pour qu'il référence Primitives/Core/white (alias) au lieu d'une valeur en dur.
Vérif : Colors/Core/white est un alias de la primitive, plus aucune valeur blanche saisie en dur.
D3 — Doublon infoBackground950 ⚠️ destructif, soft-delete¶
Problème : deux variables portent ce nom :
- Info state/infoBackground950 (clé 9ae0b98e…) — dans le groupe, légitime.
- infoBackground950 (clé ad1d9eb8…) — orphelin hors groupe (Colors/color/infoBackground950), à supprimer.
⚠️ Limite Figma : il n'y a pas de « find usages » fiable pour une variable. Supprimer sèchement = risque de casser un nœud qui pointe sur l'orphelin. → ne pas supprimer d'un coup, faire un soft-delete :
- Compare les valeurs des deux : si l'orphelin a la même valeur que
Info state/infoBackground950, c'est bien un doublon accidentel. - Renomme l'orphelin en
infoBackground950_ADELETER(au lieu de supprimer). - Publie la lib. Laisse passer quelques jours / un cycle de QA : si rien ne casse et que personne ne le signale → personne ne l'utilisait.
- Ensuite seulement : supprime
infoBackground950_ADELETERet republie.
Si tu veux aller plus vite et que tu es sûr qu'il n'a jamais servi (créé par erreur), tu peux supprimer directement — mais le soft-delete est l'option sans regret.
Vérif : à terme, un seul infoBackground950, dans le groupe Info state.
D2 — Structure des bordures Info incohérente 🧠 décision design¶
Problème : Info state a deux bordures numérotées — infoBorder600 (c5674a4e…) et infoBorder950 (06ed436b…) — alors que Success / Alert / Pending ont une seule bordure non numérotée (successBorder, alertBorder, pendingBorder).
Ce n'est pas mécanique : il faut décider quelle structure est la norme. Deux options :
- Option A — aligner Info sur les autres (recommandé pour la cohérence) : garder une bordure « canonique »
infoBorder(probablement l'actuelinfoBorder600, à confirmer selon l'usage) et traiterinfoBorder950comme un cas particulier (le renommer explicitement, ex.infoBorderStrong, ou le supprimer s'il ne sert pas). - Option B — généraliser les bordures numérotées à tous les états : beaucoup plus de travail (créer
successBorder600/950, etc.), à ne faire que si le besoin de 2 niveaux de bordure est réel partout.
Avant de trancher : regarder à quoi servent réellement infoBorder600 vs infoBorder950 (sur quels composants). Décision à prendre en tant que PD.
Action une fois décidé (Option A) :
1. Renommer infoBorder600 → infoBorder (si c'est la bordure standard).
2. Renommer infoBorder950 → infoBorderStrong ou soft-delete (cf. méthode D3) s'il ne sert pas.
Vérif : la structure de bordure d'Info ressemble à celle des autres états.
D6 — Tokens disabled multi-rôles 🧠 décision design¶
Problème : Disabled state/disabledBackground sert à la fois de fond d'élément disabled ET de bordure d'élément non cliquable (cf. sa description) ; disabledText a un scope quasi ALL_SCOPES. Un même token porte plusieurs intentions → matching 1:1 difficile côté code.
Ce n'est pas un bug, c'est un choix d'économie de tokens. À décider :
- Laisser tel quel si l'équipe assume qu'un token disabled couvre plusieurs usages (et le documenter clairement, c'est le vrai manque).
- Scinder si on veut un mapping propre 1 token = 1 intention : créer p. ex. disabledBorderNonClickable distinct de disabledBackground. Plus rigoureux, mais ça touche les composants qui les utilisent.
Recommandation : ne pas scinder pour le V0. Documenter les rôles multiples dans la description de chaque token disabled + resserrer les scopes trop larges (ex. limiter disabledText à TEXT_FILL). C'est l'action à faible risque qui réduit l'ambiguïté.
Action (basse intensité) :
1. Sur disabledText : restreindre les scopes à ce qui est réellement utilisé (panneau de la variable → Scoping).
2. Sur disabledBackground : description explicite « fond disabled + bordure non cliquable ».
D5 — Pollution lib legacy WebApp ➡️ PAS un fix Uimmo¶
Rappel : ce n'est pas une correction à faire dans Uimmo. C'est une consigne pour l'extracteur du cron (BRI-304) : filtrer les résultats sur la bibliothèque Uimmo (libraryKey Uimmo / libraryName: 🎨 Uimmo) et exclure 🖥️ WebApp, sinon faux drifts massifs (colors/white, Text/md/md - Medium, gray-secondary…).
→ À noter dans la doc des conventions de matching (livrable du ticket), pas ici.
💡 Question de fond pour plus tard : faut-il dépublier / archiver la lib WebApp legacy si plus personne ne la consomme ? Ça réglerait D5 à la source. À voir avec le lead dev.
Récap ordre d'exécution¶
| Ordre | Drift | Action | Risque |
|---|---|---|---|
| 1 | D1 | Renommer brandborder500 → brandBorder500 |
nul |
| 2 | D4 | Vérifier alias Core/white (sans doute no-op) |
nul |
| 3 | D6 | Resserrer scopes + documenter disabled | faible |
| 4 | D3 | Soft-delete orphelin infoBackground950 |
moyen (soft-delete) |
| 5 | D2 | Décider structure bordures Info, puis renommer | moyen (décision d'abord) |
| — | D5 | (rien dans Figma — consigne extracteur cron) | — |
Après chaque lot : Publish library update dans Uimmo. Si tu travailles sur une branche : merge quand le diff te convient.