@portnet/ui 6.0.1 → 6.0.3

package/CHANGELOG.md

@@ -10,6 +10,743 @@ The format is loosely based on [Keep a Changelog](https://keepachangelog.com/en/
 
 ### Added
 
+- **`useFocusOnRouteChange` — le focus après une navigation (gap G-60).**
+
+  Dans une application à page unique, naviguer ne déplace **pas** le focus : le
+  navigateur ne le fait qu'au chargement d'un vrai document. Le focus reste
+  donc sur ce qui a été cliqué — ou tombe sur `document.body` quand cet élément
+  est démonté par la navigation qu'il vient de déclencher.
+
+  Depuis `document.body`, le Tab suivant repart du haut du **navigateur** et
+  non de la page : l'utilisateur au clavier retraverse la barre d'adresse et la
+  barre d'outils à chaque écran. Un utilisateur de lecteur d'écran, lui,
+  n'obtient aucune annonce — la nouvelle page existe, en silence, et il doit
+  partir à sa recherche. C'est WCAG 2.4.3 qui échoue, et rien à l'écran ne le
+  montre : les pixels sont parfaits.
+
+  Le défaut est à son maximum quand la navigation SUIT une action, puisque le
+  déclencheur a disparu au moment où le focus devrait y revenir. **Relevé depuis
+  `autorisation-admis-pour-conforme-fe` (Area 10)** : archiver un dossier ferme
+  un dialogue de confirmation puis navigue en arrière, si bien que le piège de
+  focus du dialogue restitue le focus à un bouton qui n'existe plus.
+
+  **Agnostique du routeur par construction** — aucun routeur importé, l'hôte
+  passe la clé qu'il veut surveiller :
+
+      const { pathname } = useLocation();
+      useFocusOnRouteChange(pathname);
+
+  Et la consigne compte autant que le hook : **passer le CHEMIN, pas
+  `location.key` ni l'URL complète.** Un écran de liste écrit ses filtres, sa
+  page et son tri dans la query string, et chacun produit une nouvelle clé —
+  la surveiller volerait le focus au champ dans lequel l'utilisateur est en
+  train de taper. Ce qui mérite un déplacement de focus est un changement de
+  PAGE, pas un changement d'état de page.
+
+  La library est le bon endroit même sans connaître de routeur : `AppMain` est
+  la cible, et c'est lui qui porte le `tabIndex={-1}` qui rend la région
+  focalisable. Un hôte qui câblerait cela à la main réimplementerait
+  l'appariement que `SkipLink` + `AppMain` possèdent déjà.
+
+  Le premier rendu est ignoré (le navigateur a déjà placé le focus, et le
+  déplacer alors casserait un lien profond vers une ancre), une cible absente
+  ne provoque rien plutôt qu'une exception, et `preventScroll` n'est pas posé :
+  amener le haut de la région dans le champ de vision fait partie de ce qu'on
+  attend d'un changement de page. Tests :
+  `__tests__/useFocusOnRouteChange.test.tsx`.
+
+- **`AppMain` — `ariaLabel` et `ariaBusy` pour le landmark pré-contenu.**
+
+  Un hôte qui rend le landmark AVANT son routeur, comme R-Pp.1 l'exige
+  (« jamais d'écran blanc »), n'a rien à l'intérieur pour le nommer, et
+  « région principale » seul ne dit pas à l'utilisateur ce qui se passe. Le
+  couple compte : sans `aria-busy`, un landmark simplement VIDE est
+  indiscernable d'un landmark qui a échoué.
+
+  Pas de surface spéculative — le consommateur est nommé : la coque
+  pré-authentification d'`autorisation-admis-pour-conforme-fe` (Area 10)
+  écrivait le landmark **à la main** (`id`, `tabIndex`, `outline`, `minHeight`)
+  PARCE QU'ELLE ne pouvait pas exprimer ces deux attributs à travers ce
+  composant. Un pattern qui oblige un hôte à le réimplementer pour pouvoir le
+  nommer n'a pas fini son travail.
+
+  Aucun des deux attributs n'est émis par défaut : un `aria-busy="false"` sur
+  chaque page serait du bruit dans l'arbre d'accessibilité.
+
+- **`chartChrome` (gap G-54) et `ChartFigure` (gap G-55) — le mobilier d'un
+  graphe, et son équivalent textuel.**
+
+  `tokens/chart` portait déjà la palette catégorielle (G-37) et énonçait, dans
+  son propre en-tête, l'obligation que la librairie ne permettait pas de tenir :
+  « COLOUR IS NEVER THE ONLY CHANNEL (WCAG 1.4.1). This palette makes slices
+  distinguishable; it does not make a chart accessible. Every consumer still
+  owes a legend with text labels, and a text equivalent of the data — 1.1.1 for
+  the chart as a whole. »
+
+  **`chartChrome` est une correspondance RÔLE → TOKEN, pas un magasin de
+  valeurs**, et la distinction est la justification. Chaque valeur existait
+  déjà, et un module qui lit `ink.fgMuted` pour ses étiquettes d'axe respecte
+  déjà R-2.3. Ce qu'aucun module ne peut trancher seul, c'est QUEL token joue
+  QUEL rôle : un titre de graphe est-il un `h2` ou un `h3` ? les étiquettes,
+  `xs` ou `sm` ? le fond, `surface` ou transparent ? Sans réponse de plateforme,
+  chaque écran répond à nouveau — trois écrans de bilan et cinq définitions de
+  graphes dans le module relevé, d'accord entre eux seulement parce qu'ils se
+  sont recopiés. La réponse, une fois : titre = titre de carte (`h3`, semibold,
+  encre pleine), étiquettes = indications (`xs`, encre atténuée), fond
+  TRANSPARENT — un fond blanc en dur est exactement ce qui casse un graphe en
+  mode sombre.
+
+  Agnostique de librairie par construction : des chaînes simples, aucune
+  librairie de graphes importée, aucune forme d'options supposée. Les tailles
+  de police y sont des chaînes AVEC UNITÉ, contrairement à `fontSize.*` qui
+  sont des entiers : un moteur de graphes passe ses objets de style à des
+  attributs SVG, qui ne reçoivent jamais d'unité gratuitement — un `16` nu est
+  ignoré par certains moteurs et lu comme `16px` par d'autres.
+
+  **`ChartFigure` porte l'équivalent textuel, et `caption` y est OBLIGATOIRE.**
+  C'est la seule décision de conception de ce composant : un graphe rendu à
+  travers lui ne peut pas partir sans ses chiffres en texte. Une règle énoncée
+  sans composant pour la porter est tenue par qui s'en souvient — et
+  l'équivalent textuel est la partie qui disparaît la première, parce que c'est
+  la seule que personne ne VOIT manquer : un graphe sans équivalent a l'air
+  fini.
+
+  Le canevas est `aria-hidden` : un moteur émet des dizaines de nœuds de texte
+  SVG — graduations, pourcentages, infobulles — qu'un lecteur d'écran parcourt
+  un par un, dans l'ordre visuel, sans structure. C'est du bruit, et c'est PIRE
+  que le silence. **Corollaire contraignant** : aucun contrôle interactif ne va
+  dedans — `aria-hidden` sur un ancêtre focalisable produit un élément
+  atteignable au clavier et inannonçable, ce qui échoue à WCAG 4.1.2 plus
+  franchement que le bruit évité. Un sélecteur de période se met À CÔTÉ.
+  `hideCanvasFromScreenReaders={false}` reste l'issue pour un moteur qui
+  construit sa propre table de données navigable.
+
+  Rendu à travers `Surface component="figure"`, dont le docblock pointait déjà
+  ici : « Surface deliberately has NO title, NO actions and NO header … Those
+  compose this. » La légende est un `figcaption` VISIBLE, pas une chaîne
+  masquée : les chiffres servent aussi au lecteur qui voit le graphe — c'est
+  l'objet même d'un `figcaption` — et une légende que personne ne voit est une
+  légende dont personne ne remarque qu'elle a vieilli.
+
+  **Relevé depuis `autorisation-admis-pour-conforme-fe` (Area 5)** : trois
+  écrans répétant `Surface` + `SectionHeader` + un canevas `aria-hidden` + un
+  paragraphe de légende, styles de légende (`--text-xs`, `--fg-subtle`) recopiés
+  avec.
+
+  Surface : `chartChrome` par `@portnet/ui/tokens` (le baril de tokens, qui est
+  la route que les modules utilisent déjà pour `chartCategorical` — il n'y a
+  pas de liste de noms explicite à tenir à jour de ce côté) ; `ChartFigure` +
+  `ChartFigureProps` par `patterns`, donc par la racine plate.
+  Purement additif. Tests : `__tests__/ChartFigure.test.tsx`.
+
+- **`AppMain` — le landmark `<main>` (gap G-53).**
+
+  La librairie livrait **la moitié** d'un contrat en deux parties, et
+  prescrivait l'autre moitié sans la fournir. Le docblock de `SkipLink` dit,
+  mot pour mot :
+
+      <SkipLink href="#main-content" />
+      …
+      <main id="main-content">
+
+  Ce `<main>` n'a jamais existé ici. Chaque module l'écrivait donc, et ce n'est
+  pas une ligne : il porte trois choses faciles à rater subtilement —
+  `tabIndex={-1}`, sans quoi le lien d'évitement FAIT DÉFILER mais ne déplace
+  pas le focus sous Safari (`SkipLink` compense d'ailleurs en posant l'attribut
+  lui-même au clic, rustine pour un landmark qui aurait dû être focalisable
+  d'origine) ; `outline: none`, parce qu'un anneau de focus dessiné autour de
+  toute la page n'est pas ce que R-F.1 demande ; et **la mesure de contenu de
+  R-L.5**, un MUST que la librairie n'honorait nulle part — `PageContent` tient
+  le padding canonique et l'espacement des sections, et **ne plafonne rien**,
+  si bien qu'un module certifié étalait encore ses tableaux d'un bord à l'autre
+  d'un écran 1920 px.
+
+  Et le plafond a un compagnon que personne ne retient : **sans
+  `margin-inline: auto`**, le contenu plafonné se colle à gauche et laisse une
+  gouttière de 480 px à droite, ce qui paraît plus cassé que de ne pas
+  plafonner.
+
+  **Relevé depuis `autorisation-admis-pour-conforme-fe` (Area 5)** — et le
+  module de référence certifié `ms-ti-fe` porte le même landmark local : deux
+  copies des mêmes vingt lignes, plus un MUST non tenu.
+
+  Périmètre, puisque §07 est explicite : la Sidebar et la Topbar globale
+  relèvent du shell HÔTE, pas d'un module et pas de ce composant. `AppMain` est
+  la région de contenu À L'INTÉRIEUR de ce shell. Il ne rend ni fil d'Ariane ni
+  en-tête de page : ceux-là portent titre, sous-titre et actions propres à la
+  route, donc l'`ActionBar` de chaque page (R-L.1 / R-L.2).
+
+  Surface : `AppMain`, `AppMainProps`, `AppMainMeasure`. `measure` vaut `wide`
+  (`--content-max`) par défaut, `form` (`--form-max`) pour un formulaire
+  mono-colonne, `full` pour ne pas plafonner — à justifier au point d'appel,
+  R-L.5 étant un MUST et non un défaut. Tests :
+  `__tests__/AppMain.test.tsx`, dont l'appariement de bout en bout avec
+  `SkipLink`, qui n'avait jamais pu être exercé que dans du code de module.
+
+- **Validation des téléversements — `getFileRejection`, `isForbiddenExecutable`,
+  `isAcceptedFile`, `describeAcceptedTypes`, `toAcceptAttribute` (gap G-52).**
+
+  `Dropzone` accepte un attribut `accept` et rapporte des rejets, mais **ne
+  valide rien** : `accept` est un filtre de SÉLECTEUR DE FICHIERS, pas un
+  contrôle — le glisser-déposer l'ignore, et « Tous les fichiers » dans le
+  sélecteur l'ignore aussi sur la plupart des plateformes. La librairie
+  demandait donc à chaque hôte de décider lui-même, et chaque hôte écrivait
+  trois choses côte à côte : sa liste blanche d'extensions (politique métier,
+  légitimement la sienne), **une liste de refus des exécutables et scripts**, et
+  **un contrôle croisé extension / type MIME** avec ses tolérances navigateur.
+
+  Les deux dernières ne sont pas de la politique métier. C'est UNE décision de
+  sécurité, et une décision de sécurité recopiée dans chaque module dérivera :
+  le jour où un type doit rejoindre la liste de refus, personne ne peut dire
+  lesquels des quinze modules GU l'ont reçu. Et la divergence y est SILENCIEUSE
+  — un module qui manque une entrée ressemble exactement à un module qui l'a,
+  jusqu'au téléversement.
+
+  D'où la découpe : **l'hôte décide quelles extensions son métier accepte ; la
+  librairie tient la liste de refus et le contrôle croisé.**
+
+  **Relevé depuis `autorisation-admis-pour-conforme-fe` (Area 5)**, qui portait
+  localement une liste de refus de 21 extensions et une table MIME de six
+  extensions.
+
+  Trois décisions inscrites dans le fichier :
+  - la table MIME **n'est pas** `getMimeType` de `./fileDownload`, bien que les
+    deux associent extensions et types. Celle-là répond « quel type estampiller
+    sur ce Blob » (UNE valeur canonique) ; celle-ci répond « quels types un
+    navigateur peut plausiblement annoncer » (un ENSEMBLE, incluant des
+    variantes non enregistrées comme `image/jpg`, que les navigateurs envoient
+    quand même). Les confondre refuserait des fichiers valides ;
+  - `application/octet-stream` est toléré pour les documents Office : sans cette
+    tolérance, un `.docx` légitime est refusé sur certains postes, et de façon
+    INTERMITTENTE — le pire cas à diagnostiquer depuis un ticket ;
+  - une extension inconnue de la table est acceptée sur sa seule extension : la
+    table est un contrôle croisé, pas une seconde liste blanche, et un hôte qui
+    ajoute un format à sa politique ne doit pas être refusé par une table qu'il
+    ne voit pas.
+
+  **Ne remplace pas la validation serveur**, et c'est écrit dans le fichier :
+  tout ceci s'exécute dans un navigateur que l'utilisateur contrôle. Le but est
+  de donner une raison claire et immédiate (R-4.1, R-4.4) au lieu d'un rejet
+  serveur après téléversement complet.
+
+  **Pas d'option de taille maximale**, alors qu'elle aurait été tentante :
+  aucun consommateur n'en a la même forme aujourd'hui, et la leçon de G-51 vient
+  d'être apprise — une option publique sans consommateur réel est de la surface
+  spéculative (§2.8).
+
+  Flat-only, ajouté à `lib/index.ts` dans le même commit (invariant G-34).
+  Tests : `__tests__/fileValidation.test.ts`.
+
+- **`fmtDate` / `fmtDateTime` — rendu d'une date pour l'AFFICHAGE (gap G-51).**
+
+  La librairie tenait déjà le versant monétaire du même travail — `fmtMoney`,
+  même dossier, même « — » pour une valeur absente, pour la même raison : une
+  cellule de tableau ne doit jamais afficher « NaN ». Elle ne tenait RIEN pour
+  les dates, que les écrans GU rendent bien plus souvent que des montants.
+  Chaque module écrivait donc le sien, et toutes les copies partageaient le
+  même défaut :
+
+      const date = new Date(stringDate);
+      const day = formatIntoTwoDigits(date.getDate());
+
+  `new Date(undefined)` est une date INVALIDE dont tous les accesseurs rendent
+  `NaN` : le helper affichait littéralement **« NaN/NaN/NaN NaN:NaN »** sur
+  n'importe quel champ facultatif — date de mise à jour, de visite, de clôture,
+  c'est-à-dire la majorité d'entre eux.
+
+  **Relevé depuis `autorisation-admis-pour-conforme-fe` (Area 5)**, où la garde
+  avait été ajoutée à HUIT POINTS D'APPEL au fil de quatre lots avant d'être
+  remontée dans le helper du module : le formateur est le seul endroit où elle
+  ne peut pas être oubliée, et c'est l'argument pour qu'il vive ici.
+
+  Deux corrections mineures par construction : un helper à deux chiffres qui
+  rendait `"08"` (chaîne) ou `12` (nombre) selon la valeur, et une date absente
+  rendue en chaîne VIDE — indiscernable d'une cellule non rendue, là où « — »
+  dit « on a regardé, il n'y a rien ». L'option `absent` permet malgré tout la
+  chaîne vide là où c'est un choix délibéré (une colonne de grille qui doit
+  rester visuellement silencieuse).
+
+  **Une option retirée après vérification.** Le premier jet exposait aussi
+  `separator`, justifié par un helper du module documenté comme alimentant les
+  critères de recherche, « d'où le séparateur paramétrable ». Un `grep` du
+  module montre que ce helper n'a **aucun importateur** : la justification était
+  du code mort, et le réglage était donc de la surface spéculative sur une API
+  certifiée (§2.8 — minimum API surface). Retiré avant publication.
+
+  **Pas de `moment`, bien que le paquet en dépende déjà.** `moment` est là pour
+  les sélecteurs, et précisément pour du parsing STRICT contre un format
+  explicite (`patterns/_pickerSerialisation`) : c'est son bon usage. Rendre un
+  instant déjà parsé en deux nombres et une année n'en est pas un — ce dossier
+  est sans dépendance à dessein, et `moment(chaîne)` sans format retombe sur
+  `new Date` EN ÉMETTANT UN AVERTISSEMENT DE DÉPRÉCIATION en console, bruit
+  qu'un helper appelé une fois par cellule ne doit pas produire.
+
+  **Fuseau, énoncé plutôt que sous-entendu** : la sortie est dans le fuseau du
+  LECTEUR, comme le faisaient les helpers remplacés. Un instant `…T23:30:00Z`
+  se lit donc le lendemain à Casablanca. Si un écran a besoin du jour calendaire
+  du serveur, c'est une AUTRE fonction — basculer celle-ci en UTC décalerait
+  des dates d'un jour sur toute la plateforme.
+
+  Surface : `fmtDate`, `fmtDateTime`, `FmtDateInput`, `FmtDateOptions`, sur la
+  racine plate. Ajoutées à `lib/index.ts` DANS LE MÊME COMMIT que l'entrée du
+  baril — invariant G-34, ce baril étant re-exporté par liste de noms
+  explicite. Purement additif. Tests : `__tests__/fmtDate.test.ts`.
+
+- **`reviveSavedCriteria` — relecture d'un `SavedFilter.criteria` persisté (gap G-50).**
+
+  `criteria` est OPAQUE à dessein, et ce choix est bon : `savedFilters` le
+  stocke et le réémet verbatim, ce qui rend le cadre utilisable par toutes les
+  listes quel que soit leur schéma de filtres. Mais **l'aller-retour n'est pas
+  symétrique, et l'asymétrie est celle de la librairie** :
+  `createLocalStorageAdapter` écrit avec `JSON.stringify` — donc une `Date`
+  part en chaîne ISO — et relit avec un `JSON.parse` **sans reviver**.
+
+  Tout hôte qui persiste une date récupérait donc une chaîne, dans un champ que
+  ses propres types déclarent `Date`. Deux conséquences, silencieuses toutes
+  les deux : la chaîne arrive telle quelle dans `<DatePicker value>`, et elle
+  part telle quelle dans les critères envoyés au back-end. Le typage ne pouvait
+  pas l'attraper, puisque la seule façon d'affecter la charge utile relue dans
+  un état de formulaire typé est une conversion — qui éteint précisément
+  l'erreur qui l'aurait révélée.
+
+  **Relevé depuis `autorisation-admis-pour-conforme-fe` (Area 5)** : NEUF
+  écrans de liste convertissaient la charge utile DEUX FOIS dans leur `onApply`
+  — une conversion simple ne compilait pas. C'est la forme que prend un manque
+  de la librairie sous un typecheck strict.
+
+  Ferme aussi un effet plus discret : un filtre enregistré sous une forme
+  ANTÉRIEURE (clé renommée, champ retiré) était étalé tel quel dans l'état du
+  formulaire, clés inconnues comprises ; les clés admises sont désormais celles
+  des valeurs par défaut fournies par l'appelant.
+
+  **Pas corrigé dans l'adaptateur, délibérément** : un reviver dans
+  `createLocalStorageAdapter` s'appliquerait à TOUTES les charges utiles de
+  capacité — préférences de grille, favoris — et devrait deviner quelles
+  chaînes sont des dates pour des données dont il ne sait rien. La relecture
+  appartient à l'endroit où la forme est connue, c'est-à-dire là où l'hôte
+  passe ses propres valeurs par défaut. L'adaptateur distant à venir en
+  bénéficie aussi.
+
+  Contrainte écrite `Record<keyof TValues, unknown>` et non
+  `Record<string, unknown>` : la seconde n'est satisfaite que par les ALIAS de
+  type, et cinq des neuf formulaires concernés déclarent leur forme en
+  `interface`. La contrainte mappée accepte les deux, donc aucune conversion ne
+  remonte au point d'appel — vérifié par un test de niveau type.
+
+  Surface : `reviveSavedCriteria`, racine plate et
+  `@portnet/ui/personalization`. Conformément à la politique de dépréciation de
+  `./v2`, la capacité n'est PAS ajoutée à `v2/index.ts`. Purement additif.
+  Tests : `__tests__/reviveSavedCriteria.test.ts`.
+
+- **`usePrefersReducedMotion` — lecture RUNTIME de `prefers-reduced-motion` (gap G-49).**
+
+  R-7.5 / R-Tg.2 sont respectées partout où la librairie POSSÈDE l'animation
+  (`motion.ts`, feuille de base, `Skeleton` R-Sk.4). Ce qui manquait, c'est la
+  lecture en JS, pour l'animation qu'elle ne possède pas : un graphe, un
+  canvas, un défilement impératif, un widget tiers configuré par options. CSS
+  ne répond pas à ces cas — la décision est une valeur passée à une autre
+  librairie.
+
+  Chaque hôte écrivait donc le même helper, et **toutes les copies observées
+  portaient les deux mêmes défauts** : la valeur est lue UNE FOIS pendant un
+  rendu qui peut ne jamais se reproduire (activer la préférence en cours de
+  session ne coupait donc rien), et elle est lue PENDANT le rendu, hors de
+  l'état React, si bien que deux composants d'une même page peuvent diverger.
+  `useSyncExternalStore` traite les deux, et fournit un instantané serveur au
+  lieu d'un garde `typeof window` recopié à chaque appel.
+
+  **Relevé depuis `autorisation-admis-pour-conforme-fe` (Area 4 — détection
+  d'infrastructure UI locale)** : trois copies identiques du helper, une par
+  écran de bilan.
+
+  Surface : `usePrefersReducedMotion` (défaut) +
+  `PREFERS_REDUCED_MOTION_QUERY`, atteignables par la racine plate et par
+  `@portnet/ui/hooks`. Purement additif. Tests :
+  `__tests__/usePrefersReducedMotion.test.tsx` — dont la non-régression de
+  l'abonnement, que jsdom seul ne peut pas exercer (il n'évalue pas les
+  requêtes média).
+
+  > Numéro de gap **G-49** retenu comme premier libre au vu des en-têtes du
+  > dépôt (plus haut référencé : G-48). À confirmer par l'équipe DS si un
+  > registre central existe ailleurs.
+
+### Fixed
+
+- **`Field` — tout `Select` était SANS NOM ACCESSIBLE (R-I.1, WCAG 4.1.2 / 1.3.1).**
+
+  `Field` n'associait son libellé que par `htmlFor` / `id`. Cette paire ne nomme
+  que les éléments **étiquetables** — `input`, `select`, `textarea`, `button`,
+  `meter`, `output`, `progress`. `Select` rend sa surface visible en
+  `div[role="combobox"]`, qui n'en fait pas partie : l'association était donc
+  **nulle**, et un lecteur d'écran annonçait « liste déroulante, réduite » sans
+  jamais dire de quel champ il s'agissait.
+
+  Le code portait son hypothèse fautive en commentaire : « a single labelable
+  control is named by the htmlFor/id pair below » — vrai d'un `<input>`, faux de
+  la moitié des contrôles de cette librairie. **Tous les tiroirs de filtres et
+  tous les formulaires de tous les modules étaient concernés**, et rien à
+  l'écran ne le montrait : le libellé était là, au bon endroit, de la bonne
+  couleur.
+
+  **Trouvé par la suite axe-core d'`autorisation-admis-pour-conforme-fe`**
+  (Area 10), qui a échoué sur `aria-input-field-name` au premier `Select` rendu.
+
+  LE CORRECTIF PASSE PAR `labelId`, LE CANAL DE MUI. Une première tentative
+  passait `aria-labelledby` à tous les enfants : elle ne fonctionne pas et
+  casse autre chose. MUI répand les props inconnues sur son **wrapper racine**,
+  donc l'attribut atterrissait sur `div.MuiInputBase-root` et jamais sur le
+  contrôle — le combobox restait anonyme, tandis que pour `Input` le wrapper
+  devenait un SECOND élément porteur du libellé, ce qui est faux pour les
+  technologies d'assistance et suffit à casser n'importe quel `getByLabelText`
+  dans les tests d'un hôte (deux suites du socle sont tombées ainsi).
+  `SelectInput` fusionne `labelId` dans l'`aria-labelledby` du combobox : c'est
+  le seul chemin qui atteigne l'élément.
+
+  `labelId` n'est transmis qu'aux enfants qui **déclarent** le consommer, via le
+  marqueur statique `puiLabelTarget` porté par `Select`. Un `labelId` passé à
+  l'aveugle atteindrait `<input>` et les champs texte de MUI, qui ne le
+  connaissent pas : React avertirait alors d'un attribut DOM inconnu à chaque
+  rendu, dans la console de chaque hôte. **Tout composant de cette librairie
+  dont la surface visible n'est pas étiquetable doit porter ce marqueur.**
+
+  LIMITE CONNUE, énoncée parce qu'elle est asymétrique avec R-I.3 : un
+  `aria-labelledby` fourni par l'appelant sur un enfant non-`group` n'est pas
+  fusionné dans le nom. `aria-describedby`, lui, l'est. Rien n'est perdu en
+  silence — le champ est nommé par son propre libellé — mais un hôte qui veut
+  AJOUTER au nom doit passer par `label`.
+
+  Tests : `__tests__/FieldNaming.test.tsx`, qui couvre le contrôle natif (pour
+  que le correctif ne le régresse pas), le `Select`, l'astérisque des champs
+  requis exclu du nom, et le mode `group`.
+
+- **Pagination de `DataGrid` — cibles tactiles des quatre boutons de navigation
+  (R-7.4 / WCAG 2.5.5).**
+
+  Les mêmes `IconButton size="small"` sans plancher que ceux de l'en-tête de
+  `Drawer`, corrigés juste avant — mais dans la barre de pagination de **chaque
+  liste** du portefeuille, quatre par barre. Environ 34 px là où
+  `tokens/density` impose 44.
+
+  Le rapprochement des deux est le vrai constat : la règle est écrite dans les
+  tokens (« Icon-only buttons MUST set min-width/min-height to `tactileMin` »)
+  et **aucun** composant de la librairie qui rend des boutons d'icône ne
+  l'appliquait. Le défaut est systémique, pas ponctuel : une règle que la
+  librairie impose à ses hôtes sans se l'imposer à elle-même.
+
+  `min-width`/`min-height` et non `width`/`height` : la zone d'appui grandit,
+  le dessin de l'icône ne change pas. Valeur lue sur `var(--tactile-min)`,
+  comme le voisin `HEADER_CHECKBOX_CELL_SX`, et non réécrite en dur.
+
+  Relevé depuis `autorisation-admis-pour-conforme-fe` (Area 10).
+
+  **Signalé sans correction** : le sélecteur « lignes par page » de cette même
+  barre porte `height: 28`. Pour lui, la boîte visuelle EST la zone d'appui,
+  donc la remonter à 44 px change le dessin de la barre dans toutes les listes
+  du portefeuille : c'est une décision de design et non une correction de
+  défaut. La note vit dans `_dataGridShared.tsx`, à l'endroit où elle se
+  prendra.
+
+  Vérifié au passage, et donc non modifié : la pagination annonce déjà ses
+  changements de page — région vivante `polite` et `atomic` sur l'intervalle,
+  si bien qu'un lecteur d'écran entend « 26–50 sur 100 » en paginant.
+
+- **`Drawer` — cibles tactiles de l'en-tête sous le plancher (R-7.4 / WCAG 2.5.5).**
+
+  Le docblock de `tokens/density` énonce la règle sans ambiguïté : « Icon-only
+  buttons MUST set min-width/min-height to `tactileMin` », parce que la hauteur
+  VISUELLE d'un bouton peut descendre sous 44 px dans les paliers de densité
+  serrés sans que la zone d'appui le puisse. Les trois boutons d'icône de
+  l'en-tête de `Drawer` — précédent, suivant, fermer — étaient des
+  `IconButton size="small"` avec une seule règle de couleur : environ 34 px,
+  soit dix de moins que le minimum que cette librairie impose à ses hôtes.
+
+  **La librairie édictait la règle dans ses tokens et la violait dans son
+  propre composant.**
+
+  L'écart est resté invisible tant que la navigation entre items était peu
+  câblée : un tiroir de filtres ne rend que le bouton de fermeture. Relevé
+  depuis `autorisation-admis-pour-conforme-fe` (Area 9), qui vient d'équiper
+  ses dix aperçus de `onPrev`/`onNext` — trois cibles sous-dimensionnées par
+  tiroir, sur dix écrans.
+
+  `min-width`/`min-height` et non `width`/`height` : la zone d'appui grandit,
+  le dessin de l'icône ne change pas — exactement la distinction que fait la
+  note de `tokens/density`. Les valeurs viennent du token `layout.tactileMin`
+  et non d'un littéral, pour que le plancher suive le token s'il bouge.
+
+  Tests : `__tests__/DrawerTactileTargets.test.tsx`, dont le cas du bouton
+  DÉSACTIVÉ — une flèche inerte reste une cible que l'utilisateur vise, et la
+  rétrécir ferait sauter la rangée d'un tiroir à l'autre.
+
+- **`--field-w-*` : cinq largeurs de champ annoncées comme révisables, jamais émises.**
+
+  `Field.FIELD_MAX_WIDTH` consomme `var(--field-w-s, 200px)` et le docblock de
+  `Field` affirme que les cinq valeurs sont « exposées en variables CSS pour
+  être revues sans toucher au code » — l'échappatoire prévue pour une décision
+  que ce même docblock signale comme à confirmer par l'équipe design.
+
+  `cssVariables` n'émettait aucune de ces variables. **Seuls les replis ont
+  jamais rendu**, donc les cinq gabarits étaient impossibles à réviser sans
+  modifier le code, et la promesse était fausse. Le rendu, lui, était correct :
+  c'est une lacune de révisabilité, pas un défaut visuel — ce qui explique
+  qu'elle ait survécu.
+
+  C'est la SEPTIÈME occurrence de la classe A7-02, dont la note dans
+  `cssVariables` dit exactement ceci : « six token names were referenced
+  fleet-wide that this emitter never emitted, so their var() fallbacks were the
+  only thing that ever rendered (R-2.3 / R-AI.1 magic values wearing a token's
+  name) ». Le correctif A7-02 avait traité l'interlettrage et laissé celle-ci.
+
+  Les valeurs sont promues dans `tokens.layout.fieldWidth` — une seule source —
+  et émises par `cssVariables`. Les replis de `Field` RESTENT : un hôte qui
+  n'appelle jamais `injectCssVariables` doit continuer à rendre des largeurs
+  correctes. Les deux doivent donc rester d'accord.
+
+  `xl` n'est délibérément pas tokenisé : ce gabarit vaut `100%`, une largeur
+  relative et non une valeur de la grille. En faire un token en pixels
+  inviterait à lui donner un plafond qu'il ne doit pas avoir.
+
+  **Relevé depuis `addm-fe` (Area 4 — détection d'infrastructure UI locale).**
+  Le module n'avait aucun token local ; c'est en vérifiant que chaque `var()`
+  qu'il consomme existe réellement côté socle que l'absence est apparue.
+
+- **`DataGrid` : une action de ligne déclenchait AUSSI le clic de ligne.**
+
+  La cellule d'actions est un descendant de la ligne, qui porte
+  `onClick={() => onRowClick(row)}` et un `onKeyDown`. Elle n'arrêtait ni l'un
+  ni l'autre. Sur toute grille où `onRowClick` et `rowActions` coexistent —
+  c'est-à-dire tout listing de la plateforme, puisque §Row Interaction fait du
+  clic de ligne l'ouverture du drawer d'aperçu et des actions l'affordance
+  complémentaire — activer une action produisait l'action ET un drawer qui
+  s'ouvre par-dessus.
+
+  **Ce n'était pas rattrapable au niveau de l'action.** `buildRowActions` /
+  `buildRowActionMenu` décrivent une action comme `onClick: (row) => void` et
+  n'exposent délibérément pas l'événement DOM — un descripteur métier n'a pas à
+  connaître la propagation — et le déclencheur d'`OverflowMenu` est dans la
+  même position. La cellule est donc le seul endroit qui puisse tenir
+  l'invariant pour TOUTES les formes : le kebab, la rangée d'icônes
+  (`iconsUpTo`), et n'importe quel renderer `rowActions` écrit par un hôte.
+
+  La cellule de sélection, juste à côté, arrête ces deux événements depuis
+  toujours, et pour exactement cette raison. Des deux cellules interactives
+  d'une ligne, une seule était gardée.
+
+  `stopPropagation` et non `preventDefault` : l'activation propre des boutons,
+  Entrée/Espace sur une action focalisée comprise, est inchangée.
+
+  **Relevé depuis `addm-fe` (Area 3).** Ses deux listings avaient écrit leur
+  rangée d'icônes à la main spécifiquement pour appeler `stopPropagation()`
+  bouton par bouton — ce qui faisait passer l'adoption de `buildRowActions`
+  (G-41) pour une régression, et explique pourquoi cette fabrique était restée
+  non adoptée là-bas. Le défaut n'était donc pas seulement latent : il
+  BLOQUAIT la déduplication qu'il rendait nécessaire.
+
+  `DataGridVirtualized` n'est pas concerné : il n'expose pas `rowActions`.
+
+  Test de régression : `__tests__/DataGridRowActionsPropagation.test.tsx`,
+  qui couvre les deux formes et les deux chemins (souris et clavier), plus le
+  cas inverse — une cellule de données doit continuer à déclencher le clic de
+  ligne, sans quoi un containment posé trop haut passerait le test tout en
+  cassant §Row Interaction.
+
+### Added
+
+- **`ReferentielField` : `container="drawer"` et `searchOnOpen` — deux capacités qui bloquaient l'adoption du pattern (S-1, S-2).**
+
+  Ces deux absences n'étaient pas des manques de confort : elles rendaient le
+  pattern INADOPTABLE pour un hôte conforme, qui gardait donc sa propre
+  implémentation.
+
+  **S-1 — le conteneur était en dur.** R-M.5 est explicite : « Drawer plutôt que
+  Modal pour ≥ 3 champs ou contenu défilable long ». Un sélecteur à critères
+  PLUS une grille paginée satisfait les deux branches, et §Drawer Pattern
+  réserve par ailleurs le drawer à la « consultation rapide » — ce qu'est le
+  choix d'une ligne de référentiel. Le pattern rendait un `Modal`, et
+  `modalProps` étant un `Partial<ComponentProps<typeof Modal>>`, aucun réglage
+  ne pouvait le changer. Un hôte qui LIT R-M.5 devait donc choisir entre la
+  charte et le pattern.
+
+  Défaut inchangé (`"modal"`) : aucun appelant existant ne bouge. Le corps est
+  extrait en UNE expression partagée par les deux enveloppes, donc recherche,
+  sélection et pagination ne peuvent pas diverger entre conteneurs. Dans la
+  branche drawer, `footer` devient `actions` (même emplacement, autre nom),
+  `size` n'a pas d'équivalent — un drawer est borné par sa largeur — et
+  `modalProps` n'est délibérément PAS transmis : son type est celui de `Modal`,
+  le faire fuiter sur un `Drawer` serait un mensonge de typage.
+
+  **S-2 — pas de recherche à l'ouverture.** « Saisissez un critère puis lancez
+  la recherche » est le bon état initial quand la population est trop grande
+  pour être listée — le cas d'usage que décrit l'en-tête du fichier. Mais
+  certaines populations sont COURTES et CONNUES : les mandatants habilités d'un
+  transitaire, une nomenclature paginée par cinq. La réponse attendue y est la
+  liste. `initialCriteria` ne couvrait pas ce besoin — il sème les critères sans
+  déclencher d'appel.
+
+  La garde est un `ref` et non de l'état, et c'est le point délicat :
+  `runSearch` dépend de `draft`, donc un effet naïf repartirait à chaque frappe
+  dans un critère — une requête par caractère, exactement ce que le bouton
+  « Rechercher » existe pour éviter. Les critères semés sont par ailleurs
+  passés EXPLICITEMENT à `runSearch`, qui lirait sinon le `draft` du rendu
+  courant, non encore appliqué par l'effet d'ouverture.
+
+  Tests : `__tests__/ReferentielFieldContainer.test.tsx`. L'assertion centrale
+  n'est pas que la recherche initiale part, mais qu'elle part UNE SEULE FOIS —
+  une saisie dans un critère ne doit pas la rappeler.
+
+  **Relevé depuis `addm-fe` (Areas 3 et 5).** Ce module gardait deux sélecteurs
+  locaux de ~14 Ko chacun, et l'Area 3 avait conclu à tort que la raison était
+  une contrainte de valeur primitive — c'est celle de `FormikCombobox`, pas de
+  ce pattern, qui est objet par contrat. Les vraies raisons étaient ces deux-ci.
+
+- **`TabPanel` + `tabDomId` / `tabPanelDomId` — l'autre moitié du contrat `Tabs` (G-46).**
+
+  `Tabs` émet la moitié ONGLET de R-Ar.6 : chaque onglet porte son `id` et un
+  `aria-controls` vers `pui-panel-<id>`. L'élément qui doit porter cet id — avec
+  `role="tabpanel"` et un `aria-labelledby` en retour — était laissé à l'hôte,
+  et la library ne fournissait rien pour lui.
+
+  Le format des ids était donc une connaissance PRIVÉE que chaque hôte
+  réécrivait en chaîne littérale. Une faute de frappe y est invisible : le
+  balisage reste valide et l'onglet annonce simplement un élément contrôlé qui
+  n'existe pas. **Un `aria-controls` cassé est pire que son absence** — la
+  technologie d'assistance propose à l'utilisateur une relation qu'elle ne peut
+  ensuite pas suivre.
+
+  `tabDomId` / `tabPanelDomId` sont exportées avec le composant, et `Tabs` les
+  consomme désormais lui aussi : la convention n'a plus qu'UNE définition, et un
+  hôte qui a besoin de son propre panneau (virtualisé, animé) en dérive les ids
+  au lieu d'en refaire une copie.
+
+  DEUX DÉCISIONS LAISSÉES À L'HÔTE, délibérément :
+
+  - **Le montage.** `TabPanel` ne connaît pas l'onglet actif et ne se masque pas
+    lui-même. Un hôte qui monte ses panneaux conditionnellement garde un DOM
+    léger ; un hôte qui doit préserver l'état des panneaux inactifs les rend
+    tous et masque lui-même. Imposer le second forcerait ce comportement sur
+    tout le monde, et un panneau `hidden` resté dans le DOM change ce qu'un
+    lecteur d'écran énumère.
+  - **`focusable`**, par défaut `true` : l'APG exige qu'un tabpanel soit
+    focalisable quand il ne contient AUCUN élément focalisable, pour qu'un
+    utilisateur clavier atteigne le contenu après avoir parcouru la tablist. Un
+    panneau de texte `KV` en lecture seule est exactement ce cas, et c'est le
+    cas courant sur une page de consultation.
+
+  **Relevé depuis `addm-fe` (Area 5).** Sa page de consultation rendait ses
+  panneaux en `{tab === "x" && <…/>}` nus — les deux onglets pointaient dans le
+  vide — puis un `TabPanel` local avait été écrit **en relisant la convention
+  dans la source de `Tabs`**. C'est la preuve même que la connaissance était
+  requise et non publiée.
+
+- **`HStepperRichStep` / `HStepperStep` — une asymétrie de surface typée, fermée.**
+
+  Le bloc `StepStatus` du barrel surface l'union des statuts d'étape ET, du côté vertical, `VStepperItem` — avec cette justification : « le même consommateur construit les objets dans lesquels l'union vit ». Le côté HORIZONTAL n'avait reçu que l'union.
+
+  L'argument est pourtant mot pour mot le même : un hôte qui pilote `HStepper` en mode riche construit des objets `{ id, label, status }`, et dans un `.map()` le ternaire de statut s'élargit en `string` tant que le type de retour n'est pas annoté — la prop est alors refusée. Sans le type d'étape, il ne restait que deux issues : redéclarer la forme localement (la duplication que ce bloc existe précisément pour éviter), ou l'atteindre par `ComponentProps<typeof HStepper>["steps"][number]`, un accès indexé qui ne dit rien de l'intention.
+
+  `HStepperStep` accompagne : c'est ce que prend réellement la prop `steps` — l'union « libellé simple ou étape riche » — donc le type nécessaire à qui annote la VARIABLE tableau plutôt que le callback de `map`.
+
+  **Relevé depuis `addm-fe` (Area 2).** `DemandeStepper` pilote les trois étapes du wizard en mode riche ; la migration TypeScript a bloqué net sur cette absence. À noter que le module était en JavaScript jusque-là : la lacune existait depuis que le mode riche existe, et seul un consommateur typé pouvait la révéler.
+
+  Additif et type-only : aucun changement d'exécution, aucun export existant modifié.
+
+- **`FormikDisplay.width` — le seul champ de la library qui ne portait pas de gabarit (G-H, suite).**
+
+  `Field.width` (entree ci-dessous) est relaye par tous les ponts de saisie. `FormikDisplay` ne passait pas — et ne pouvait pas passer — par ce relais : il ne s'appuie PAS sur `Field`, il rend sa propre boite, parce qu'un champ en lecture seule n'a ni controle a nommer par `htmlFor` ni erreur a decrire.
+
+  **Consequence concrete : un formulaire melant saisie et affichage produisait le defaut que le standard nomme.** Les `FormikInput` s'arretaient a leur plafond (400px en `m`), les `FormikDisplay` voisins remplissaient toute la cellule de grille — c'est-a-dire le « jagged right-side layout edge » explicitement interdit par la section « Form Field Width & Layout Standards », et la « Homogeneous Field Rule » violee entre deux champs du meme bloc logique.
+
+  `FIELD_MAX_WIDTH` est IMPORTE de `Field`, pas recopie : deux tables de largeurs finiraient par diverger, et le plafond reste pose au palier `sm` seulement, pour la meme raison qu'ailleurs (le standard impose 100 % de la largeur de grille sur mobile).
+
+  **Releve depuis `addm-fe` (Area 2 — certification TypeScript).** `EntrepriseStep` passait `width` a ses NEUF champs en lecture seule depuis sa modernisation UI, et la prop etait ignoree en silence : la conformite annoncee de cette section ne tenait en realite que pour ses trois champs saisissables. A noter, parce que l'entree `Field.width` ci-dessous affirme l'inverse — « une prop non declaree echoue a la compilation, donc rien ne se perd en silence » : c'est vrai du consommateur TYPESCRIPT. `addm-fe` etait en JavaScript, la prop se perdait donc bel et bien sans bruit, et c'est sa migration qui l'a fait apparaitre. La garantie vaut ce que vaut le typage du module qui consomme.
+
+  Retrocompatible : sans `width`, aucun plafond n'est pose.
+
+- **`Field.width` — les cinq gabarits de largeur semantique du standard (G-H).**
+
+  La section « Form Field Width & Layout Standards » des Platform Mandatory UX Patterns impose de rattacher chaque champ a l'un de cinq gabarits d'apres sa contrainte de CARACTERES (`xs` 1-5, `s` 6-15, `m` 16-60, `l` 61-256, `xl` au-dela), et y interdit explicitement les « arbitrary input field widths » et les « jagged alignment fields within forms ».
+
+  **La library n'avait rien pour l'exprimer.** `FormGrid` raisonne en COLONNES (1/2/3/4, ou `minColumnWidth`), `FormGrid.Item span` en colonnes, et `Input` n'expose ni largeur ni taille. Un module voulant s'y conformer n'avait donc que le `sx` — c'est-a-dire precisement les « local UI tokens » que le meme document interdit. Releve depuis `refonte-frontend` (lot 8), ou l'audit de conformite a constate que la section entiere n'avait pas pu etre appliquee.
+
+  **Sur `Field`, et non sur chaque controle.** Le gabarit est une contrainte de MISE EN PAGE, pas une propriete de l'input : c'est la boite du champ — libelle, controle, indication, erreur — qui doit etre bornee, sinon le message d'erreur s'etale sur toute la cellule pendant que l'input est borne. `Field` est le seul endroit qui voit cette boite entiere.
+
+  **Un plafond, et seulement a partir de `sm`.** Le standard exige aussi l'empilement a 100 % de la largeur de grille sur mobile, et l'alignement des champs heterogenes sur des fractions de colonnes. Avec un `maxWidth` pose au palier tablette, la grille continue de decider des COLONNES et le gabarit borne le champ DANS sa cellule : les deux regles coexistent au lieu de se contredire.
+
+  **Les cinq valeurs sont une decision de design, pas une lecture.** Le standard donne des fourchettes (« ~80px to 120px max »). Le HAUT de chacune a ete retenu, ces largeurs etant des plafonds : prendre le bas tronquerait des valeurs qui tiennent dans la contrainte de caracteres annoncee. Elles passent par des variables CSS (`--field-w-xs` a `--field-w-l`) pour etre revues sans modification de code, et `FIELD_MAX_WIDTH` est exporte pour que le test les epingle — le plafond etant pose derriere une requete media, jsdom ne peut pas lire la largeur effective, seule la story le montre.
+
+  Relaye par `FormikInput`, `FormikTextarea`, `FormikSelect`, `FormikCombobox`, `FormikDatePicker` et `FormikDateTimePicker`, chacun documentant le gabarit que le standard associe a SON type de controle (les « simple dropdowns » en `m`, les « long dropdowns » et les « complex search auto-completes » en `l`, les dates en `s`). `FormikReferentielField` ne le relaie pas encore : une prop non declaree echoue a la compilation, donc rien ne se perd en silence.
+
+  Retrocompatible : sans `width`, aucun plafond n'est pose.
+- **`FormikDateTimePicker` — le pont date + HEURE qui manquait (G-E).**
+
+  `FormikDatePicker` etait le SEUL pont de date de la library, et il est date-seule. Sa propre note d'audit le disait : « DateTimePicker, TimePicker and DateRangePicker are exposed as bare components ». Un hote ayant besoin de l'heure n'avait donc que deux options : la perdre, ou recabler `useField` + le `DateTimePicker` nu.
+
+  **Perdre l'heure n'est pas un compromis d'affichage : ca change ce que recoit le backend.** Releve depuis `refonte-frontend` (lot 7). Le formulaire de visite physique stocke une date de visite portant une heure et soumet `moment(valeur).format("YYYY-MM-DD HH:mm")`. Passe par le pont date-seule, toute visite aurait ete programmee a 00:00 — silencieusement, sans erreur nulle part, et seul l'agent se presentant a la mauvaise heure l'aurait fini par decouvrir. Le test unitaire epingle les deux comportements cote a cote, pour que la raison d'etre des deux ponts reste lisible.
+
+  Et recabler a la main, c'est la duplication interdite par R-2.1, dans la forme ou les messages de validation disparaissent — meme histoire que G-A et G-C.
+
+  **Au passage, `coerceToDate` / `serialiseDate` sortent en module interne partage** (`patterns/_pickerSerialisation`), consommees par les DEUX ponts. Aucun changement de comportement : le code est deplace, pas modifie.
+
+  Ce n'est pas du rangement. La note S-03 de `FormikDatePicker` documente ce qui arrive quand la LECTURE et l'ECRITURE d'une date divergent : un « 31-12-2026 » relu par `new Date()` devient Invalid Date, un « 05-03-2026 » devient le 3 mai au lieu du 5 mars. Le chemin d'ecriture fonctionne, donc le degat n'apparait qu'a la RELECTURE — en modification, le parcours qu'un test de fumee n'exerce jamais. Un module a livre ce defaut pendant sept lots sous un typecheck strict. Deux copies privees de ce couple auraient recree la meme classe de bug, sous une forme encore moins visible : deux ponts qui se ressemblent, que personne ne compare, et qui ont l'air corrects isolement.
+
+- **`FormikRadioGroup` — le pont qui manquait pour un groupe de radios (G-C).**
+
+  R-Sel.2 est un MUST : 2-3 options -> Radio ou Segmented, jamais un Select. Toute question metier binaire passe donc obligatoirement par `RadioGroup` — qui n'avait aucun pont Formik, la ou `FormikSelect`, `FormikCombobox`, `FormikCheckboxGroup`, `FormikDatePicker`, `FormikTextarea`, `FormikFile` et `FormikInput` en ont tous un. Les hotes recablaient donc `useField` + `RadioGroup` a la main, avec la meme consequence que pour G-A : le controle est rendu, `FieldError` est oublie. Releve depuis `refonte-frontend` (lot 5), ou UN formulaire portait deux de ces groupes.
+
+  **Le contrat qui compte est invisible : la valeur ecrite est celle DECLAREE dans `options`, pas la chaine que rapporte le DOM.** Un `<input type="radio">` ne rapporte jamais qu'une chaine. Un hote dont les options sont numeriques — `{ value: 1 }`, `{ value: 2 }` — et dont le payload declare un nombre se mettrait a envoyer `"1"` des le premier clic. L'API l'accepte, ou le refuse trois jours plus tard ; rien dans l'interface ne le signale. Le pont reapparie donc la chaine du DOM contre la liste d'options et ecrit la valeur d'origine. La chaine brute ne passe qu'a defaut de correspondance — perdre le clic de l'utilisateur serait pire.
+
+  Symetriquement, la SELECTION se compare en chaine : un champ portant le booleen `false` selectionne l'option declaree `"false"`, un champ portant `2` selectionne `{ value: 2 }`. C'est le cas des hotes qui initialisent en booleen et transmettent du texte au backend. La valeur STOCKEE n'est jamais reecrite par cette comparaison — un formulaire ouvert puis ferme sans reponse transmet exactement ce dont il a ete amorce.
+
+  Le champ est marque touche AU CLIC : pour un groupe de radios, la premiere interaction EST la reponse, il n'y a pas de blur-avant-changement. Attendre un blur laisserait le message d'un groupe requis cache pendant que l'utilisateur clique.
+
+  `required` est porte par le CHAMP et non par les options : `Field` rend l'asterisque sur le libelle du groupe et injecte `aria-required`, valide sur `role="radiogroup"` — contrairement au cas de la case a cocher seule (G-A), ou l'injection atterrissait sur un conteneur qui ne la transmet pas.
+
+- **`FormikCheckbox` — le pont qui manquait pour une case a cocher BOOLEENNE (G-A).**
+
+  `FormikCheckboxGroup` existait deja, et il porte un TABLEAU de valeurs selectionnees. C'est le bon modele pour « choisir plusieurs dans une liste », et le mauvais pour un drapeau seul. Un hote dont l'etat est `autreInfo.fabrication: boolean` ou `objectDeclaration.premiereDeclaration: boolean` ne peut pas l'adopter sans changer la forme de ce que son payload envoie au backend.
+
+  **Consequence observee** : faute de pont, les modules recablaient `Checkbox` + `useField` a la main. C'est la duplication que R-2.1 interdit, et elle a coute exactement ce que coutent les ponts artisanaux — le rendu de l'erreur. Releve depuis `refonte-frontend` (lot 5) : ses champs cables main n'affichaient AUCUN message de validation, si bien qu'une erreur sur un champ requis etait invisible pour l'utilisateur (R-4.1 MUST). Le defaut ne se voit ni a la relecture ni sur une capture : les pixels sont corrects, seul le message manque.
+
+  Trois details du contrat valent d'etre notes, parce qu'ils ne sont pas devinables :
+
+  La case est enveloppee dans un `CheckboxGroup`, comme le fait `FormikCheckboxGroup`, et pour la meme raison : `Field` clone son enfant avec `error` / `disabled`, que `MuiCheckbox` propagerait jusqu'a l'`<input>` natif (avertissement React, attribut DOM invalide). `CheckboxGroup` destructure ses props explicitement et absorbe le reste.
+
+  Le libelle nomme la CASE, via `FormControlLabel`, et non le champ : une case seule portant un libelle de champ ET un libelle de controle se lit comme deux questions. `Field` ne recoit donc pas de `label`, et `required` s'exprime la ou il compte — asterisque sur le libelle du controle, `aria-required` sur l'`<input>` (l'injection de `Field` atterrit sur le groupe, qui ne la transmet pas).
+
+  Le champ est marque touche AU CHANGEMENT, pas au blur. Une case n'a pas de blur-avant-changement significatif : attendre un blur garderait le message cache quel que soit le nombre de clics.
+
+  `checked` compare a `true` explicitement : les hotes initialisent ces drapeaux a `null` (« pas encore repondu »), et `checked={null}` rend l'input non controle le temps d'un rendu.
+
+- **`RowFavoriteToggle` — the follow star, reachable outside a DataGrid column (G-36).**
+
+  This component already existed. It was `FavoriteCell`, private inside `makeFavoriteColumn`, which made the follow control reachable at exactly one composition point: as a DataGrid column definition.
+
+  The other place a row always appears is the mobile card. `DataGrid` swaps to `renderMobileCard` below its `mobileBreakpoint`, and `MobileRowCard` has a `leading` slot for precisely this kind of per-row control — but a column definition cannot be rendered into a slot, so every host re-derived the star by hand. `onssa-export-fe` carried a local `MobileFavoriteToggle`; `ms-ti-fe` destructures the same `MobileRowCard` + `FavoriteToggle` + `useIsFavorite` trio for the same reason.
+
+  **Same failure mode as G-10**, one level down: the library owned the behaviour but exposed it at a single composition point, so consumers reimplemented it at the others.
+
+  **And the copy drifted exactly where drift is hardest to notice.** The local twin announced itself as "Ajouter aux favoris" / "Retirer des favoris" while the grid column *in the same list* announced "Suivre" / "Ne plus suivre", and it omitted the status tooltip entirely. One affordance, one list, two accessible names — selected by viewport width. R-2.1 MUST is "un même concept = un même composant + un même libellé partout"; a sighted user could not have seen this, and a screen-reader user met a different control on a phone than on a desktop.
+
+  `makeFavoriteColumn` now renders this component rather than a private twin, so the column and the card agree **by construction instead of by review**. `FavoriteColumnLabels` extends `RowFavoriteToggleLabels` and the column's defaults spread the shared ones, so the label set has one definition too.
+
+  Behaviour is carried over unchanged: action-oriented accessible name with `aria-pressed` for state, visible status on hover/focus via `Tooltip`, and click/keydown propagation stopped so toggling never fires the row's `onRowClick`. No change for existing `makeFavoriteColumn` callers.
+
+- **`useGridPreferences` — per-user hidden columns, because a bare `localStorage` key is not a user (G-35).**
+
+  `DataGridToolbar` owns the column-visibility UI (`hiddenColumns` + `onHiddenColumnsChange`) but deliberately holds no state, so *persisting* the choice was left to the host. Every listing screen therefore reached for raw `localStorage` — `onssa-export-fe` had `"onssaCertificates:listing:hiddenColumns"`, hand-written `JSON.parse` included.
+
+  **The defect is not the duplication, it is the key.** This foundation partitions every capability as `portnet-ui:perso:v1:{tenantId?}:{userId}:{capabilityId}`; a host-invented key has no user segment. Favorites and saved filters were already immune because they route through the store — column visibility was the one grid preference that bypassed it. On a shared workstation, which is the norm at a port, user B inherited user A's hidden columns: a column A had hidden was simply absent for B, with nothing on screen to explain why. A preference silently became a data-visibility rule for someone else.
+
+  **This could not be fixed in a host, and that is a second finding.** `registerCapability` is exported as a "capability registration seam — for custom/host-defined capabilities", but the two primitives every capability hook needs, `usePersonalizationStore` and `useStoreSelector`, are private by design (architecture doc §2.8, minimum API surface). A host could register a descriptor and then had no way to read or write its payload. The seam is advertised without being complete. Completing it was rejected as the fix here: it would widen a certified library's internal surface *and* leave every module re-authoring the same slice. Owning the slice does neither — but the incomplete seam should either be finished or stop advertising itself.
+
+  Payload is `{ [resourceKey]: { hiddenColumns: string[] } }`, with the entry object rather than a bare array so column order and widths can join it later without a `schemaVersion` bump. The pure helpers rebuild only the touched `resourceKey` and shallow-copy the map, so structural sharing keeps every other resource referentially stable; the exposed `Set` is memoised on the stored array so its identity survives re-renders and does not defeat `DataGrid`'s memoisation.
+
+  `migrate` normalises on load even though v1 has no predecessor version — it is the trust boundary for a payload coming back from storage, and a column key is used to *hide* grid columns, so a number or an object from an older build (or from hand-edited devtools storage) must not reach the grid as if it were one. This absorbs, once, the validation each host was writing for itself.
+
+  Density is deliberately **not** part of this: `useDensity` owns it as a global, non-resource-scoped value and applies `data-density` to `<html>`, and folding it in would give one preference two owners.
+
+  **Known related debt, not addressed here.** `useDensity` (`portnet-ui-density`) and `useFormAutoSave` (host-supplied `storageKey`) both persist outside this foundation on unscoped keys, for the same reason G-35 existed. `useFormAutoSave` is the more serious of the two — a draft is keyed by resource id only, so on a shared workstation one user is offered another's unsubmitted form, business data included. Neither is fixed here: `storageKey` is a required public prop, so scoping it is a signature change (MAJOR under §10.1) affecting every module with a create form, and moving density into the foundation would change its storage key and make it require a provider. Both need their own RFC.
+
 - **`SkeletonPageShell` — the route-level `Suspense` fallback R-P.1 requires (G-02).**
 
   R-P.1 MUST says "routing avec `React.lazy` + `Suspense`, **fallback skeleton page**". The library shipped every skeleton *part* — `Skeleton`, `SkeletonRow`, `SkeletonKPI`, `SkeletonDetailHero`, `SkeletonTabContent`, `SkeletonText` — plus `PageBusy`, and yet nothing that satisfies the rule: `PageBusy` is a full-viewport spinner, which R-8.1 MUST forbids for navigation, and the parts are shaped for the inside of a page rather than the page frame.