origam 2.18.20 → 2.19.0

package/CHANGELOG.md

@@ -18,6 +18,131 @@ This project follows [Semantic Versioning](https://semver.org).
 
 ## [Unreleased]
 
+## [2.19.0] - 2026-09-30
+
+### Changed — ADR-005 lot 2 : `OrigamKbd` converti, ⚠️ deux ruptures
+
+Le lot 1 avait posé le mécanisme et laissé le registre **vide**. Premier
+composant converti : le variant de Kbd n'est plus un bloc SCSS, c'est
+`KBD_VARIANT_PRESETS`. La garde `no-variant-css` passe de **36 à 32**.
+
+Kbd n'était pas convertible mécaniquement, et la cause tient en une phrase :
+**une propriété custom hérite.** `&--combination` posait
+`--origam-kbd---border-width: 0` pour désépaissir l'enveloppe, la valeur
+descendait dans chaque `__key` — dont le mixin `key-surface` lit précisément
+`var(--origam-kbd---border-width, …)` — et les touches perdaient leur bordure.
+C'est **pour la rattraper** que chaque règle de variant devait se redéclarer une
+seconde fois en `&--variant-x &__key`, et c'est ce doublon qui rendait le variant
+inconvertible : une prop de racine ne peut pas peindre un descendant. La
+neutralisation passe donc par `border-width: 0`, propriété physique, qui n'hérite
+pas ; et le composant lie ses déclarations de surface à l'élément qui **est** une
+touche — la racine en forme simple, chaque `__key` en combinaison, les deux ne
+coexistant jamais.
+
+Bénéfice non prévu, relevé par une garde : la règle `&--variant-outlined`, **toujours
+active** puisque `outlined` est le défaut de `withDefaults`, **confisquait**
+`--origam-kbd---border-width` à tout thème de marque.
+`theme-channel-confiscation` passe de **37 à 36**.
+
+⚠️ **Rupture 1** — sur une combinaison, les props de surface (`bgColor`, `color`,
+`border`, `elevation`) peignent désormais **les touches** et non l'enveloppe.
+`<origam-kbd :combination="['Ctrl','S']" bg-color="primary">` rendait un cadre
+coloré autour de touches non colorées ; il colore les touches.
+
+⚠️ **Rupture 2** — `--origam-kbd--outlined---border-width`,
+`--origam-kbd__filled---border-width` et `--origam-kbd__tonal---border-width`
+sont **supprimés**. Ils ne portaient aucune valeur propre : les deux premiers
+valaient `{border.width.thin}`, déjà le défaut de `--origam-kbd---border-width`,
+et le troisième `{border.width.0}`. Pour régler la largeur d'un variant, passer
+par `--origam-kbd---border-width` ou par le prop `border`.
+
+`OrigamKbd` gagne `elevation` (`IElevationProps`) — c'est le canal sur lequel
+voyage l'ombre d'embossage de chaque variant.
+
+Non-régression **mesurée** et non affirmée : un harnais neuf
+(`pnpm -F @origam/tests audit:kbd-preset`) monte le composant sous les **8
+identités × 2 modes** et relève 11 longhands sur chaque surface peinte, `__key`
+compris — Histoire étant épinglé `data-theme="light"` et n'enregistrant aucune
+marque, l'axe des identités y est immesurable. Sur le variant **nu**, zéro écart
+sur `background-color`, `border-*`, `color`, `border-radius`, `padding`,
+`font-size` et `min-width`. Seul `box-shadow` bouge, en deux familles **prouvées
+non-peignantes au pixel** : la sérialisation du blanc
+(`rgba(255,255,255,a)` → `color(srgb 1 1 1 / a)`, même couleur) et, sur `tonal`,
+le mot-clé `none` → `rgba(0,0,0,0) 0px 0px 0px 0px` — étendue et alpha nuls,
+`elevation` ne pouvant pas émettre le mot-clé.
+
+⚠️ La limite du canal `border` découverte en chemin — un
+`border="var(--…---border-width, 1px)"` matchait le groupe `color` de
+`BORDER_REGEX` et émettait un `border-color` — **a été corrigée depuis, en
+2.18.21** (section juste en dessous). Ce qui reste : `IBorderProps` n'expose
+toujours pas de `borderWidth` autonome, et une largeur `var()` **contenant une
+espace** ne voyage que par une prop par côté ou d'axe, la prop globale `border`
+la coupant à son `split(' ')`. Ajouter `borderWidth` avait par ailleurs été
+rejeté sur la mesure, indépendamment de la regex : 24 composants déclarent
+`IBorderProps` sans consommer ses props autonomes, et `unconsumed-props` passait
+de 0 à 24. La suppression des trois tokens de largeur ne repose de toute façon
+pas sur cette limite, mais sur le fait qu'ils ne portaient **aucune valeur
+propre**.
+## [2.18.21] - 2026-09-30
+
+### Fixed — `useBorder` supprimait silencieusement une largeur en `var()`
+
+`BORDER_REGEX` n'acceptait en largeur que des chiffres suivis d'une unite,
+tandis que son groupe **couleur** accepte `var(--…)`. Une chaine comme
+`borderLeft="var(--x) solid var(--y)"` etait donc happee **entierement par le
+groupe couleur** : `parseBorderPositionValue` renvoyait une largeur vide,
+`formatBorderPositionStylesVar` sautait la declaration, et le navigateur
+jetait le `border-left-color` invalide. Resultat rendu : un bord `medium`
+(~3px) en `currentColor` au lieu de la largeur et de la couleur demandees.
+
+⛔ **Aucun diagnostic.** Le type-check passait, rien n'etait leve, rien
+n'etait logue. Le chemin booleen (`borderLeft: true`) emettait pourtant un
+`var()` correctement — seul l'analyseur de chaine refusait.
+
+Le groupe `width` accepte desormais une alternative `var()`, **conditionnee
+par un lookahead sur un mot-clé de style**. Ce garde n'est pas decoratif : les
+trois groupes de la regex peuvent matcher vide, donc une alternative `var()`
+nue aurait happe `var(--ma-couleur)` — une couleur SEULE, cas courant qui
+fonctionnait — et aurait inverse la panne. Le lookahead tire sa liste de
+`BORDER_STYLE`, pour qu'elle ne puisse plus deriver de celle du groupe `style`.
+
+⚠️ **Limite connue, pinnee par trois tests et non corrigee ici.** Une largeur
+`var()` **contenant une espace** (`var(--x, 4px)`) ne passe que par les props
+PAR COTE. La prop globale `border` fait un `split(' ')` et coupe la valeur en
+fragments invalides. Avant ce lot la meme valeur tombait entiere dans `color`
+et y etait scindee en quatre — aucun bord dans les deux cas, donc pas de
+regression, mais pas repare. **Un preset portant une largeur tokenisee doit
+viser une prop par cote ou d'axe, jamais `border`.**
+
+### Added — `fontStyle` en passthrough sur `ITypographyProps`
+
+`font-style` n'avait ni prop, ni groupe de tokens, ni classe utilitaire
+(`0` occurrence dans `interfaces/Commons/` et `composables/Commons/`, `0` pour
+`font__style` dans `primitive.css`). `useTypography` enveloppant toute valeur
+en token, `italic` / `normal` — des mots-clés CSS, pas des echelons — devaient
+passer **litteralement**. Aucun canal nouveau : `--origam-blockquote---font-style`
+etait deja declare et deja lu.
+
+### Internal — ce que la campagne zero-changement ne prouve pas
+
+`BORDER_REGEX` sert la prop `border` sur ~100 composants sans baseline VRT, et
+la verification exigee etait donc : aucune valeur du depot ne change de
+decoupage. Verdict — **81 valeurs `border*` distinctes, 81 decoupages
+identiques, delta zero**.
+
+⛔ Mais la regex **naive** que ce garde-fou existe pour eviter ne diverge, elle
+non plus, **sur aucune des 81 valeurs reelles** : aucun fichier du depot ne
+passe une couleur `var()` seule a une prop de bordure. **Le corpus reel
+n'aurait pas attrape la regression inverse** — seul le controle negatif
+synthetique `var(--c)` l'attrape. Une campagne sur valeurs reelles prouve
+moins qu'elle n'en a l'air ; les controles negatifs sont ce qui la rend
+concluante. Consigne dans `border.const.ts`.
+
+Hors paquet publie, dans le meme intervalle : `pnpm audit` est repasse de
+**7 high / 7 moderate / 3 low** a **0**, par relevement de trois `overrides`
+(`brace-expansion@2`, `brace-expansion@5`, `undici@8`). Aucun fichier de
+`packages/ds` touche, donc le tarball est inchange par cette partie.
+
 ## [2.18.20] - 2026-09-30
 
 ### Added — surfaces de props `opacity` et `backdrop`, et les deux trous de `IStateEffectConfig`