origam 2.18.7 → 2.18.9

package/CHANGELOG.md

@@ -18,6 +18,170 @@ This project follows [Semantic Versioning](https://semver.org).
 
 ## [Unreleased]
 
+## [2.18.8] - 2026-09-23
+
+### Fixed — #901 `OrigamBtn` — `calc(auto + 0px)` ramenait `min-width` à `0` sur tous les boutons
+
+`OrigamBtn.vue`, second bloc `<style scoped>`, déclarait sans condition sur
+`.origam-btn` `--origam-btn---min-width: calc(var(--origam-btn---width, 36px)
++ var(--origam-btn---density, 0px))`. La feuille (`light.css`/`dark.css`)
+déclare `--origam-btn---width: auto`, donc le repli `36px` n'était jamais
+atteint et la valeur devenait `calc(auto + 0px)` — invalide au moment de la
+substitution dans `min-width` (ligne 563), pas au parse : la propriété
+retombait sur sa valeur initiale (`auto` → `0` hors flex), jamais sur le
+repli `64px`. Même spécificité `(0,2,0)` que les modificateurs `&--size-*`,
+mais déclaré APRÈS eux : les 5 échelons de `size` et `&--icon` étaient donc
+tous écrasés — famille de la garde 29 `unitless-zero-in-calc` / #607.
+
+Mesuré en navigateur réel (Playwright + Histoire statique, chromium) :
+
+| | avant | après |
+|---|---|---|
+| `size=x-small` | `0px` | `36px` |
+| `size=small` | `0px` | `50px` |
+| `size=default` | `0px` | `64px` |
+| `size=large` | `0px` | `78px` |
+| `size=x-large` | `0px` | `92px` |
+| `density=comfortable` (size=default) | `0px` | `72px` |
+| `icon=true` | `28px` (dépendait de `--origam-btn---height` résolue, pas de 0 voulu) | `0px` |
+
+Correctif : `min-width` (l.563) lit désormais directement
+`--origam-btn---min-width` (repli `64px`) plutôt que `--origam-btn---width`,
+et le second bloc `<style scoped>` ne réécrit plus ce canal (ni
+`--origam-btn---min-height`, strictement identique au repli déjà présent
+l.566 et jamais déclaré par aucune feuille — retrait vérifié sans effet).
+
+⛔ **Corollaire découvert en réparant** : le nouveau `calc(var(--origam-
+btn---min-width, 64px) + var(--origam-btn---density, 0px))` fait
+maintenant participer `--origam-btn---min-width` à une addition — et
+`&--icon` le posait à `0` NU (`<number>`, pas `<length>`), le même défaut
+que celui réparé ici. `OrigamCode.vue` déclarait le même canal en `0` nu
+pour son bouton de copie compact (`.origam-code__copy`,
+`.origam-code__copy--compact`). Les trois déclarations passent à `0px` —
+changement sémantiquement neutre (`0` == `0px` en CSS), guard
+`unitless-zero-in-calc` self-testé vert. `token-var-channels` gagne 1 entrée
+« canal mort connu » pour `--origam-btn---min-height` (jamais alimenté par
+le pipeline de tokens, extension locale volontaire — baseline mise à jour).
+
+**VRT** : mesuré (pas supposé) via `pnpm -F @origam/tests test:vrt:docker`
+(image `mcr.microsoft.com/playwright:v1.59.1-jammy` pinnée, seule verdict
+valable — cf. `vrt/VRT.md`) — `vrt/btn-variant.spec.ts`, 7/7 verts, **aucune
+capture ne bouge**. Les 7 libellés de la matrice (`Text` … `Outlined`, 4 à
+8 caractères) dépassent déjà le plancher `size=small` (`50px`) une fois le
+padding `12px`×2 ajouté, donc le nouveau plancher ne change la largeur
+d'aucun bouton de ce pilote. Aucune baseline à régénérer dans cette PR.
+
+### Fixed — #411 : `OrigamChartMap` faisait **disparaître** contours et pays sous un thème de marque
+
+Ce n'est pas « la couleur ne suit pas le thème ». `borderColor` **était** une
+prop déclarée, donc le résolveur d'ADR-005 l'atteignait déjà : un thème
+nommant `components['origam-chart-map'].borderColor` posait bien sa valeur.
+Le défaut est en aval — la valeur partait **verbatim dans le `stroke` inline
+du SVG, sans passer par `resolveColor()`**, contrairement à sa voisine
+`lineColor` qui y passait déjà.
+
+Or un intent comme `'success'` **n'est pas du CSS valide pour `stroke`** : le
+navigateur ne repeint pas en gris, il **jette la déclaration entière**. Une
+marque nommant cette prop ne recevait donc pas un contour mal thémé — elle
+n'avait **plus de contours de pays du tout**.
+
+```
+- :style="{ fill: country.fill, stroke: borderColor }"
++ :style="{ fill: country.fill, stroke: resolveColor(borderColor) }"
+```
+
+**Le jumeau, trouvé en réparant et livré dans la même PR** :
+`defaultCountryFill` portait le défaut identique une ligne plus bas
+(`fill = props.defaultCountryFill` sans `resolveColor()`, typé `string` nu
+face au `TIntent | string` de `lineColor`) — donc les pays **absents du jeu
+de données** disparaissaient de la même façon. Vérifié dans le code avant de
+le traiter, pas déduit par symétrie.
+
+Les deux props sont retypées `TIntent | string` et passent par
+`resolveColor()`, qui laisse traverser les littéraux CSS.
+
+⚠️ **Le défaut de `defaultCountryFill` reste le littéral
+`rgba(0,0,0,0.08)`, délibérément.** `resolveColor()` ne rend qu'une couleur
+**opaque fixe**, là où ce littéral est un **voile semi-transparent composité
+sur le `bgColor` que le graphique peint lui-même** : il s'adapte donc au
+clair, au sombre et à un `bgColor` personnalisé. Aucun intent ne reproduit
+ça — le retyper « pour la symétrie » aurait échangé un comportement
+adaptatif contre un comportement figé. Consigné dans le JSDoc de
+`IChartMapProps` et dans la table de la doc. Le défaut de `borderColor`,
+lui, passe de `rgba(0,0,0,0.2)` à l'intent `'neutral'`.
+
+⚠️ **Le ticket était périmé aux deux tiers**, revérifié avant d'écrire une
+ligne : des trois composants qu'il nomme, `OrigamSelect` était déjà réparé
+par `331d9b62` (#456) et `OrigamDatePickerField` par `374858be5` — lequel
+citait déjà #411 sans le fermer. Son périmètre à 3 était en revanche exact :
+grep des littéraux cités, aucune 4ᵉ occurrence dans le DS.
+
+A/B contre le commit parent, en Vitest (chaîne `style` littérale) **et** en
+Chromium réel (`getComputedStyle`) : `borderColor` stable **10/10** ;
+`defaultCountryFill` **2/4 rouge avant, 4/4 vert après** en unitaire, rouge
+puis vert en navigateur, stable 10/10 sous `--repeat-each=5`. Story, doc,
+2 specs TU et 2 specs e2e (ajoutées à `GREEN_SPECS`).
+
+### Fixed — #535 : le contraste syntaxique de `OrigamCode` était sous AA, deux fois plus bas que le ticket ne le disait
+
+⚠️ **Le `4,27:1` du ticket ne se reproduit plus** — `HomeHero` a migré vers
+un extrait `bash` qui ne touche que 2 des 8 catégories shiki, toutes deux
+déjà conformes. Le défaut sous-jacent, lui, est réel et bien plus large.
+
+Remesuré sur **8 catégories shiki** (mots-clés, ponctuation, chaînes,
+commentaires, nombres/variables, fonctions, paramètres, balises) × **8 fonds**
+(DS par défaut + 7 thèmes de marque) × **2 modes**, depuis les valeurs hex
+littérales réelles (shiki 4.3.1, `*.theme.ts`) :
+
+| | avant | thème shiki seul | **livré** |
+|---|---|---|---|
+| clair, pire cas | **2,93:1** *(paramètre, `geek`)* | 4,23:1 | **4,77:1** *(commentaire, `glass`)* |
+| sombre, pire cas | **2,55:1** *(commentaire, `material`)* | 5,79:1 | **6,77:1** *(mot-clé, `material`)* |
+
+**Le pire cas réel était à 2,55:1 : le ticket sous-estimait son propre défaut
+d'un facteur deux.**
+
+**D'où vient la couleur, établi et non supposé.** Shiki peint chaque token via
+`--shiki-light` / `--shiki-dark` **inline sur chaque `<span>`**, depuis deux
+thèmes figés déclarés dans `consts/Code/code.const.ts`. **Aucun token
+`--origam-code---syntax-*` par catégorie n'existe** — déjà établi par #399 /
+#661, reconfirmé en relisant le code. La fausse piste signalée dans le ticket
+tient toujours : `--origam-color__feedback--success---fgSubtle` (touché par
+#524) alimente bien `--origam-code__syntax---string`, mais **ce n'est pas ce
+que shiki peint**.
+
+**Aucun token créé, et l'arbitrage a été évité plutôt que contourné.** La
+question « faut-il des tokens de syntaxe par catégorie ? » était posée comme
+point d'arrêt ; le calcul a montré qu'aucune décision d'architecture n'était
+nécessaire :
+
+1. `CODE_LIGHT_THEME` / `CODE_DARK_THEME` → `github-light-high-contrast` /
+   `github-dark-high-contrast` — **mêmes paquets shiki, coût de bundle
+   inchangé**.
+2. `--origam-code---background-color` : `surface---sunken` →
+   `surface---raised`, **un token sémantique qui existe déjà par thème**.
+
+Le thème shiki seul ne suffisait pas (4,23:1 en clair) : **il fallait les
+deux**.
+
+Nouveau `describe` `Syntax contrast (#535)` dans `code.spec.ts`,
+`getComputedStyle` réel sur chaque couleur shiki distincte, clair + sombre —
+**3/3 vert**.
+
+**Non vérifié** : les 7 thèmes de marque **via Playwright contre le site
+marketing lui-même** — calcul déterministe sur les valeurs source à la place,
+le mécanisme CSS étant, lui, vérifié en navigateur réel. VitePress a son
+propre pipeline shiki indépendant, hors périmètre. Le seed marketing
+(`server/db/seed/const.json`) garde une copie figée des anciens noms de
+thème : signalé, **non resynchronisé**, ça demande un re-sync de base séparé.
+
+**Trouvaille annexe** : le `#29` cité dans les commentaires « bugs DS
+connus » de `code.spec.ts` ne correspond à aucun ticket — `gh issue view 29`
+est une PR dependabot sans rapport. Corrigé dans le commentaire. Même motif
+que le `#46` qui a circulé des mois dans la doc de ce dépôt.
+
+## [2.18.7] - 2026-09-23
+
 ### Fixed — #607 / #569 : 19 canaux de thème confisqués par le bloc du composant
 
 Un composant qui redéclare un token que les feuilles déclarent déjà rend ce
@@ -156,6 +320,8 @@ sont **compositées** sur le `default` de leur propre thème, avec l'opération
 décimales (composite 0.9757 contre pixel rendu 0.9754). Vérifiée ROUGE sur les
 valeurs du commit parent, une fois par marque : `geek/light` puis `glass/light`.
 
+## [2.18.6] - 2026-09-23
+
 ### Fixed — #818 baseline shrink : les 8 `color-contrast` du DS (8 → 0)
 
 ⚠️ **Ce lot porte sur le DS lui-même, pas sur une palette marketing** : il
@@ -294,76 +460,7 @@ d'intention) rejouée après le lot : **226 passed, 0 failed**. Suite unitaire
 complète : **7149 passed**. `pnpm -F origam guards` 28/28, `guards:self`
 15/15, `type-check` et `pnpm audit` propres.
 
-### Fixed — #818 baseline shrink : `aria-allowed-attr`/`aria-prohibited-attr`/`aria-valid-attr-value` (12 des 25 entrées)
-
-Recompté sur `a11y-violations.baseline.json` (pas repris d'un chiffre cité
-ailleurs) : la baseline #818 portait **25 clés / 33 violations** sur 24
-composants, dont **12 `aria-allowed-attr`** concentrées sur la famille
-`OrigamDataTable*`. Cause commune, pas 12 défauts distincts :
-`OrigamTextField` ne posait pas `inheritAttrs: false` alors qu'il
-redistribue déjà explicitement chaque attr de fall-through
-(`filterInputAttrs` → `rootAttrs` sur `<origam-input>`, `inputAttrs` sur le
-vrai `<input>`). Sans ce flag, Vue appliquait EN PLUS le `$attrs` brut sur
-la racine `<origam-input>`, qui ne s'y soustrayait pas non plus — doublant
-`aria-haspopup`/`aria-expanded`/`aria-controls`/`aria-valuenow`/… sur le
-`<div>` wrapper, qui ne porte aucun rôle les autorisant. `role` (prop
-déclarée sur `OrigamTextField`) n'atteignait par ailleurs que
-`<origam-field>`, jamais le vrai `<input>` — c'est ce défaut exact que le
-commentaire `KNOWN_FAILURES` documentait déjà pour `OrigamSelect` (test
-`fixme`).
-
-**Correctif à la source** (`packages/ds/src/components/TextField/OrigamTextField.vue`) :
-`defineOptions({ inheritAttrs: false })` + `role` désormais aussi lié sur le
-`<input>` réel. Élimine, mesuré axe-core en navigateur réel (Playwright +
-Histoire statique) :
-- `OrigamSelect` — sort de `KNOWN_FAILURES` (`components.spec.ts`), test
-  `fixme` → vert.
-- `OrigamDataTable`, `OrigamDataTableFooter`, `OrigamDataTableHeaderCell`,
-  `OrigamDataTableHeaders`, `OrigamDataTableHeadersCell`,
-  `OrigamDataTableRow` — `aria-allowed-attr` disparaît, entrée de baseline
-  retirée entièrement.
-- `OrigamDataTableGroupHeaderRow`, `OrigamDataTableRows`, `OrigamNumberField`
-  — `aria-allowed-attr` disparaît, l'entrée reste pour leur AUTRE violation
-  (`button-name` / `color-contrast`), non touchée par ce lot.
-- `OrigamDataTableHeadersCellMobile` — `aria-allowed-attr` ET
-  `aria-prohibited-attr` disparaissent (même fuite, deux règles axe
-  différentes), entrée retirée entièrement.
-
-**Deuxième cause, distincte, deux composants** —
-`packages/ds/src/components/ColorPickerField/OrigamColorPickerField.vue` et
-`.../DatePickerField/OrigamDatePickerField.vue` posaient un
-`aria-haspopup` avec une valeur inventée (`'colorpickerbox'` /
-`'datepickerbox'`, jamais un token ARIA valide) sur l'élément
-`.origam-field` (via `activator="parent"` d'`OrigamMenu`), sans `role` le
-justifiant. Remplacé par `aria-haspopup: 'dialog'` (motif WAI-ARIA « Date
-Picker Dialog ») + `role: 'combobox'` sur le même élément — même principe
-que `comboboxAriaAttrs` d'`OrigamSelect`. `aria-allowed-attr` ET
-`aria-valid-attr-value` disparaissent pour les deux ; `OrigamColorPickerField`
-est intégralement retiré de la baseline, `OrigamDatePickerField` y reste
-pour son `color-contrast` (non touché).
-
-**Bilan mesuré** : baseline #818 25 clés/33 violations → **17 clés/18
-violations**. Suite `pnpm -F @origam/tests test:a11y` complète (226 tests,
-catalogue 218/218) : **226 passed**, aucune régression sur les 36
-composants à baseline vide. Contrôle positif exécuté : réintroduire l'ancien
-comportement fait échouer `a11y — OrigamSelect Default Variant` avec
-`aria-allowed-attr`/`aria-prohibited-attr` NON baselinés — la porte capte
-la régression, pas seulement l'édition du JSON.
-
-**Laissé de côté, délibérément** (17 clés / 18 violations restent dans
-`a11y-violations.baseline.json`, cf. #818) : `color-contrast` (8 instances —
-plusieurs agents dédiés au contraste travaillent déjà sur ce périmètre),
-`button-name` (3, boutons icône sans libellé — famille distincte),
-`scrollable-region-focusable` (3), `aria-required-parent`/`aria-required-children`/
-`listitem`/`aria-prohibited-attr` (`OrigamChartMap`, sans lien avec ce
-correctif) — un défaut chacun, cause non partagée avec ce lot, non
-instruit ici.
-
-Récolte de deux dépréciations posées "pour la prochaine majeure" avant que le
-`CLAUDE.md` n'acte que `3.0.0` est réservé à la séparation en modules et que
-les ruptures, elles, ne le sont pas — voir "Work priorities and versioning"
-du `CLAUDE.md`. `origam` n'a aucun consommateur : les deux ruptures
-ci-dessous partent en **mineure**, sans shim ni période de grâce.
+## [2.18.5] - 2026-09-23
 
 ### Fixed — `button-name` et `scrollable-region-focusable` (6 des 18 violations laissées de côté par le lot précédent)
 
@@ -442,172 +539,109 @@ au vert. `pnpm -F origam guards` (28/28), `guards:self` (15/15),
 d'autres agents), `aria-required-parent`/`aria-required-children`/`listitem`/
 `aria-prohibited-attr` (un défaut chacun, cause non partagée avec ce lot).
 
-### ⚠️ BREAKING — `click:prepend` / `click:append` retirés d'`IBtnEmits` (#443, #577)
+## [2.18.4] - 2026-09-23
 
-`<OrigamBtn>` n'émet plus `click:prepend` ni `click:append` — ni au niveau du
-type, ni au niveau de l'exécution. `IBtnEmits` n'`extends` plus
-`IAdjacentEmits`, et les `<span>` `origam-btn__prepend` / `__append` ne
-portent plus de `@click` du tout : un clic souris dessus ne déclenche plus
-rien.
+### Fixed — #818 baseline shrink : `aria-allowed-attr`/`aria-prohibited-attr`/`aria-valid-attr-value` (12 des 25 entrées)
 
-**Pourquoi cette paire précisément, et pourquoi une suppression plutôt qu'un
-correctif.** Les deux émissions n'ont jamais été atteignables au clavier :
-l'événement partait d'un `<span>` descendant, alors qu'une activation clavier
-synthétise son clic sur la RACINE du composant — l'écouteur posé sur le
-descendant ne le voit jamais. Le correctif générique appliqué aux dix autres
-consommateurs d'`useAdjacent` (promouvoir la zone en `role="button"` + arrêt
-de tabulation) est **illégal** ici : `<OrigamBtn>` rend un `<button>` ou un
-`<a>`, et le modèle de contenu HTML interdit à tous deux un descendant de
-contenu interactif *et* tout descendant portant `tabindex`. Un
-`<button type="button">` imbriqué y est tout aussi invalide. La forme était
-fausse, pas seulement le balisage : un contrôle qui possède déjà une action
-ne peut pas en héberger une seconde — deux actions sont deux boutons,
-composés via `<origam-btn-group>`.
+Recompté sur `a11y-violations.baseline.json` (pas repris d'un chiffre cité
+ailleurs) : la baseline #818 portait **25 clés / 33 violations** sur 24
+composants, dont **12 `aria-allowed-attr`** concentrées sur la famille
+`OrigamDataTable*`. Cause commune, pas 12 défauts distincts :
+`OrigamTextField` ne posait pas `inheritAttrs: false` alors qu'il
+redistribue déjà explicitement chaque attr de fall-through
+(`filterInputAttrs` → `rootAttrs` sur `<origam-input>`, `inputAttrs` sur le
+vrai `<input>`). Sans ce flag, Vue appliquait EN PLUS le `$attrs` brut sur
+la racine `<origam-input>`, qui ne s'y soustrayait pas non plus — doublant
+`aria-haspopup`/`aria-expanded`/`aria-controls`/`aria-valuenow`/… sur le
+`<div>` wrapper, qui ne porte aucun rôle les autorisant. `role` (prop
+déclarée sur `OrigamTextField`) n'atteignait par ailleurs que
+`<origam-field>`, jamais le vrai `<input>` — c'est ce défaut exact que le
+commentaire `KNOWN_FAILURES` documentait déjà pour `OrigamSelect` (test
+`fixme`).
 
-**Ce qui NE bouge PAS** : les slots `prepend` / `append` (`IBtnSlots extends
-IAdjacentSlots`) restent intacts, ainsi que les props `prependIcon` /
-`appendIcon` / `prependAvatar` / `appendAvatar` — un contenu décoratif ou
-informationnel en prepend/append reste parfaitement légitime, seule
-l'émission d'un clic disparaît.
+**Correctif à la source** (`packages/ds/src/components/TextField/OrigamTextField.vue`) :
+`defineOptions({ inheritAttrs: false })` + `role` désormais aussi lié sur le
+`<input>` réel. Élimine, mesuré axe-core en navigateur réel (Playwright +
+Histoire statique) :
+- `OrigamSelect` — sort de `KNOWN_FAILURES` (`components.spec.ts`), test
+  `fixme` → vert.
+- `OrigamDataTable`, `OrigamDataTableFooter`, `OrigamDataTableHeaderCell`,
+  `OrigamDataTableHeaders`, `OrigamDataTableHeadersCell`,
+  `OrigamDataTableRow` — `aria-allowed-attr` disparaît, entrée de baseline
+  retirée entièrement.
+- `OrigamDataTableGroupHeaderRow`, `OrigamDataTableRows`, `OrigamNumberField`
+  — `aria-allowed-attr` disparaît, l'entrée reste pour leur AUTRE violation
+  (`button-name` / `color-contrast`), non touchée par ce lot.
+- `OrigamDataTableHeadersCellMobile` — `aria-allowed-attr` ET
+  `aria-prohibited-attr` disparaissent (même fuite, deux règles axe
+  différentes), entrée retirée entièrement.
 
-**Preuve du comportement retiré** — A/B contre le commit parent, fonctionnel
-et pas seulement typé : `packages/tests/TU/components/Btn/OrigamBtn.adjacent-emit-removed.spec.ts`
-monte `<OrigamBtn>` avec un écouteur `onClick:prepend` / `onClick:append` et
-déclenche un vrai `click` DOM sur la zone. Sur le commit parent, ce même test
-appellerait l'écouteur (l'émission déclarée par `IAdjacentEmits` partait
-encore) ; sur ce commit, l'écouteur n'est jamais invoqué — vérifié en
-rejouant le fichier de spec avant/après le changement, pas seulement en le
-lisant une fois vert.
+**Deuxième cause, distincte, deux composants** —
+`packages/ds/src/components/ColorPickerField/OrigamColorPickerField.vue` et
+`.../DatePickerField/OrigamDatePickerField.vue` posaient un
+`aria-haspopup` avec une valeur inventée (`'colorpickerbox'` /
+`'datepickerbox'`, jamais un token ARIA valide) sur l'élément
+`.origam-field` (via `activator="parent"` d'`OrigamMenu`), sans `role` le
+justifiant. Remplacé par `aria-haspopup: 'dialog'` (motif WAI-ARIA « Date
+Picker Dialog ») + `role: 'combobox'` sur le même élément — même principe
+que `comboboxAriaAttrs` d'`OrigamSelect`. `aria-allowed-attr` ET
+`aria-valid-attr-value` disparaissent pour les deux ; `OrigamColorPickerField`
+est intégralement retiré de la baseline, `OrigamDatePickerField` y reste
+pour son `color-contrast` (non touché).
 
-Nettoyage induit : le helper `warnDeprecatedEmit` (`color.util.ts`) et la
-constante `ADJACENT_EMIT_REPLACEMENT` (`consts/Btn/btn.const.ts`) sont
-retirés — `<OrigamBtn>` était leur seul appelant, et le fichier `btn.const.ts`
-devenu vide est supprimé.
+**Bilan mesuré** : baseline #818 25 clés/33 violations → **17 clés/18
+violations**. Suite `pnpm -F @origam/tests test:a11y` complète (226 tests,
+catalogue 218/218) : **226 passed**, aucune régression sur les 36
+composants à baseline vide. Contrôle positif exécuté : réintroduire l'ancien
+comportement fait échouer `a11y — OrigamSelect Default Variant` avec
+`aria-allowed-attr`/`aria-prohibited-attr` NON baselinés — la porte capte
+la régression, pas seulement l'édition du JSON.
 
-**Migration.** Aucun consommateur interne (DS, marketing, stories, docs,
-tests) n'utilisait `click:prepend` / `click:append` sur `<OrigamBtn>` —
-balayage exhaustif, zéro résultat. Un consommateur externe qui les écoutait
-doit remplacer l'action posée sur la zone prepend/append par un second
-`<origam-btn>` dans un `<origam-btn-group>`.
+**Laissé de côté, délibérément** (17 clés / 18 violations restent dans
+`a11y-violations.baseline.json`, cf. #818) : `color-contrast` (8 instances —
+plusieurs agents dédiés au contraste travaillent déjà sur ce périmètre),
+`button-name` (3, boutons icône sans libellé — famille distincte),
+`scrollable-region-focusable` (3), `aria-required-parent`/`aria-required-children`/
+`listitem`/`aria-prohibited-attr` (`OrigamChartMap`, sans lien avec ce
+correctif) — un défaut chacun, cause non partagée avec ce lot, non
+instruit ici.
 
-### ⚠️ BREAKING — `createOrigam()` nu n'installe plus le thème par défaut (#360)
+### Fixed
 
-`createOrigam()` préfixait inconditionnellement chaque install avec le thème
-neutre interne `origamTheme` (`[...origamTheme, ...suppliedThemes]`) : même un
-appel nu, ou un `themes: []` explicite, recevait quand même les variables CSS
-et — surtout — les **props par défaut par composant** (ADR-005,
-`components: { 'origam-avatar': { rounded: 'full' }, … }`) de ce thème. Une
-application qui n'en voulait pas ne pouvait pas s'en défaire. Ce préfixage est
-retiré : `createOrigam()` installe désormais exactement ce qu'on lui passe,
-rien de plus.
+- **#871 (clôture) — les 7 dernières violations AA étaient UN défaut de
+  palette répété, pas sept défauts de composant.** Mesuré avec
+  `packages/tests/audit/dark-contrast.audit.mjs` : **7 / 1 664 → 0 / 1 664**,
+  les 8 identités × 2 modes × 2 portées, quatre contrôles verts des deux
+  côtés. Exactement **7 lignes changent, aucune ne se dégrade**, et le ratio
+  minimum de toute la surface passe de 3.65 à **4.70**.
 
-**Ce qui change concrètement.** Sans `themes`/`theme` explicite,
-`createOrigam()` n'injecte plus aucune variable `--origam-*` et le résolveur
-de props par défaut (`installThemePropsResolver`, ADR-005) n'a plus rien à
-résoudre — chaque composant retombe uniquement sur ses propres valeurs
-`withDefaults()`. Concrètement : un `<origam-avatar>` sans prop `rounded`
-explicite n'est plus automatiquement circulaire (`rounded="full"` venait du
-thème, pas du composant).
+  Les 7 se répartissaient en deux causes, toutes deux dans
+  `packages/marketing/src/themes` — **aucune dans le DS**, qui était déjà à
+  zéro :
 
-**Le thème par défaut reste disponible, à la demande** — `origamTheme`,
-exporté par `origam/themes` (déjà public avant cette rupture, aucun nouvel
-export nécessaire) :
+  | cause | marque · mode | couple | avant | après |
+  |---|---|---|---|---|
+  | encre héritée du mode clair | `apple` sombre | `#ffffff` → `#000000` sur `#0a84ff` | 3.65 | **5.76** |
+  | encre héritée du mode clair | `ecom` sombre | `#ffffff` → `#1a0f0a` sur `#f43f5e` | 3.67 | **5.12** |
+  | jeton de rôle inversé | `ecom` clair | `action.primary.bg` → `.fgSubtle` sur la crème | 4.43 | **5.93** |
 
-```ts
-// AVANT (2.x) — enregistrait implicitement le thème origam par défaut
-import { createOrigam } from 'origam'
-app.use(createOrigam())
+  **La cause commune.** Le mode sombre ÉCLAIRCIT l'accent de marque — c'est
+  la bonne pratique pour une grande surface (`#0071e3` → `#0a84ff` chez
+  `apple`, rose-600 → rose-500 chez `ecom`) — mais les deux palettes gardaient
+  l'encre `#ffffff` de leur jumeau clair. Or chacune applique **déjà** la règle
+  inverse à ses intentions `feedback` : les 4 d'`ecom` et 3 des 4 d'`apple`
+  encrent leur accent éclairci avec le `text.inverse` de la palette.
+  `action.primary` était la dernière exception. Le badge n'était pas en cause :
+  `--origam-badge__badge---{background-color,color}` lit exactement ce couple —
+  tout comme `--origam-btn--primary---*`, qui n'est pas dans la sonde et était
+  donc en défaut sans être mesuré.
 
-// APRÈS — le thème par défaut est un choix explicite
-import { createOrigam } from 'origam'
-import { origamTheme } from 'origam/themes'
-app.use(createOrigam({ themes: origamTheme }))
-```
-
-**Rayon de souffle mesuré, corrigé dans le même lot** — quatre consommateurs
-directs de `createOrigam()` nu trouvés par balayage exhaustif (DS, marketing,
-stories, docs, tests) :
-- `packages/ds/src/nuxt/module.ts` — le module Nuxt officiel. **Non cassé** :
-  son propre `DEFAULT_THEMES` (utilisé quand l'option `origam.themes` du
-  consommateur est omise) passe désormais `origamTheme` explicitement à
-  `createOrigam()`, préservant à l'identique le comportement de tout
-  consommateur Nuxt existant (marketing compris) qui ne configurait rien.
-  Seul un `createOrigam()` direct, hors module Nuxt, doit s'adapter.
-- `packages/marketing/nuxt.config.ts` — configure `origam.themes`
-  explicitement (7 thèmes de marque + un thème `origam` renommé pour le
-  playground `/theming`), ce qui **contourne** le fallback du module. Le vrai
-  thème neutre non-nommé (celui que `activeDefaultsFor` fusionne toujours en
-  premier, avant la marque active) était fourni jusqu'ici par le préfixage
-  implicite de `createOrigam()` — invisible dans la config marketing. Il est
-  désormais listé explicitement, en premier, dans le tableau `themes`.
-- `packages/stories/histoire.setup.ts` — Histoire (utilisé par les ~208
-  stories de composants) appelait `createOrigam()` nu ; sans correction,
-  chaque story aurait silencieusement perdu les props par défaut du thème
-  (avatars carrés au lieu de circulaires, etc.). Passe désormais
-  `{ themes: origamTheme }`.
-- `packages/docs/.vitepress/theme/index.ts` — les démos de composants live de
-  la doc VitePress appelaient `createOrigam()` nu ; même correction.
-
-Les échantillons de code montrés au consommateur (`installation.const.ts` /
-`installation.vue` sur le marketing, `guide/usage.md` côté docs) sont mis à
-jour pour montrer la forme correcte — un utilisateur copiant l'ancien
-exemple aurait obtenu des composants non stylés selon le thème.
-
-**Tests adaptés** (comptés avant correction, comme demandé) — 3 fichiers /
-5 assertions reposaient sur l'enregistrement implicite et ont été corrigés
-pour installer `origamTheme` explicitement là où le test vérifie précisément
-une valeur par défaut issue du thème, ou réécrits pour pinner le NOUVEAU
-contrat plutôt que l'ancien :
-- `theme-props-resolver.spec.ts` (2 assertions — `origam-radio`/`origam-text-field`
-  vs `origam-input` density) ;
-- `installed-themes.composable.spec.ts` (describe block entier renommé
-  `origam baseline — explicit opt-in only (#360)`, 2 assertions corrigées et
-  2 nouvelles ajoutées pour couvrir explicitement le nouveau contrat) ;
-- `OrigamChip.spec.ts` (1 assertion — `components['origam-chip'].size`).
-
-**Preuve fonctionnelle** (pas seulement structurelle) —
-`packages/tests/TU/origam/createOrigam-bare-no-theme-360.spec.ts` monte un
-vrai `<OrigamAvatar>` : sans thème, la classe `origam--rounded-full` est
-absente ; avec `origamTheme` passé explicitement, elle est présente — la
-même monteuse prouve donc que le harnais peut actionner la prop avant de
-conclure qu'elle ne l'est plus par défaut.
-
-### Fixed
-
-- **#871 (clôture) — les 7 dernières violations AA étaient UN défaut de
-  palette répété, pas sept défauts de composant.** Mesuré avec
-  `packages/tests/audit/dark-contrast.audit.mjs` : **7 / 1 664 → 0 / 1 664**,
-  les 8 identités × 2 modes × 2 portées, quatre contrôles verts des deux
-  côtés. Exactement **7 lignes changent, aucune ne se dégrade**, et le ratio
-  minimum de toute la surface passe de 3.65 à **4.70**.
-
-  Les 7 se répartissaient en deux causes, toutes deux dans
-  `packages/marketing/src/themes` — **aucune dans le DS**, qui était déjà à
-  zéro :
-
-  | cause | marque · mode | couple | avant | après |
-  |---|---|---|---|---|
-  | encre héritée du mode clair | `apple` sombre | `#ffffff` → `#000000` sur `#0a84ff` | 3.65 | **5.76** |
-  | encre héritée du mode clair | `ecom` sombre | `#ffffff` → `#1a0f0a` sur `#f43f5e` | 3.67 | **5.12** |
-  | jeton de rôle inversé | `ecom` clair | `action.primary.bg` → `.fgSubtle` sur la crème | 4.43 | **5.93** |
-
-  **La cause commune.** Le mode sombre ÉCLAIRCIT l'accent de marque — c'est
-  la bonne pratique pour une grande surface (`#0071e3` → `#0a84ff` chez
-  `apple`, rose-600 → rose-500 chez `ecom`) — mais les deux palettes gardaient
-  l'encre `#ffffff` de leur jumeau clair. Or chacune applique **déjà** la règle
-  inverse à ses intentions `feedback` : les 4 d'`ecom` et 3 des 4 d'`apple`
-  encrent leur accent éclairci avec le `text.inverse` de la palette.
-  `action.primary` était la dernière exception. Le badge n'était pas en cause :
-  `--origam-badge__badge---{background-color,color}` lit exactement ce couple —
-  tout comme `--origam-btn--primary---*`, qui n'est pas dans la sonde et était
-  donc en défaut sans être mesuré.
-
-  ⚠️ **On n'a PAS foncé l'accent**, bien que ce soit l'autre levier : chez
-  `apple`, `action.primary.bg` sert aussi d'ENCRE (le bloc `components` passe
-  ce `var()` en `color` sur `origam-breadcrumb-item`). Le ramener à `#0071e3`
-  donnait 4.70 sous du blanc mais faisait tomber le fil d'Ariane à **4.47** sur
-  le fond noir — un défaut échangé contre un autre. Vérifié par calcul avant
-  d'écrire la moindre ligne.
+  ⚠️ **On n'a PAS foncé l'accent**, bien que ce soit l'autre levier : chez
+  `apple`, `action.primary.bg` sert aussi d'ENCRE (le bloc `components` passe
+  ce `var()` en `color` sur `origam-breadcrumb-item`). Le ramener à `#0071e3`
+  donnait 4.70 sous du blanc mais faisait tomber le fil d'Ariane à **4.47** sur
+  le fond noir — un défaut échangé contre un autre. Vérifié par calcul avant
+  d'écrire la moindre ligne.
 
   La 3ᵉ cause est une erreur de RÔLE : `bg` est un jeton de surface, `fgSubtle`
   la teinte prévue pour être LUE sur une surface neutre. `ecomDarkTheme` posait
@@ -673,40 +707,89 @@ conclure qu'elle ne l'est plus par défaut.
   du filtre. **Vérifiée ROUGE sur `origin/develop`** : 3 échecs / 14 succès.
   C'est elle qui a trouvé la 8ᵉ violation ci-dessus.
 
-- **#871 — le mode sombre ne peignait qu'à moitié dans un sous-arbre thémé.**
-  Les feuilles de tokens portent ~1 761 déclarations **dérivées**
-  (`--origam-title---color: var(--origam-color__text---primary)`). Une custom
-  property est substituée **sur l'élément qui la déclare** ; ce qu'un
-  descendant hérite est la valeur DÉJÀ substituée. Le bloc sombre étant ancré
-  à la racine (`:root:not([data-theme])[data-mode="dark"]`), un sous-arbre
-  `<OrigamThemeProvider mode="dark">` basculait bien les ~60 tokens
-  sémantiques — le bloc runtime, lui, émet `[data-mode="dark"]` — mais laissait
-  les 1 761 dérivés **gelés** sur les valeurs claires de la racine. Motif
-  dominant mesuré : `rgb(10,10,10)` sur `rgb(10,10,10)`, texte et fond
-  identiques.
+## [2.18.3] - 2026-09-23
 
-  Les deux feuilles s'accrochent désormais aussi à l'axe `data-mode` :
+#### `v-contrast` était silencieusement inerte sur fond opaque (#869)
 
-  ```css
-  :root, [data-theme="light"], [data-mode="light"]      { /* clair */ }
-  [data-theme="dark"], [data-mode="dark"]:not([data-theme="light"]) { /* sombre */ }
-  ```
+La directive `v-contrast`, câblée sur 30 composants, n'émettait **jamais**
+rien — ni classe, ni `color: !important`, ni `console.warn` — dès que fond
+**et** texte étaient tous deux OPAQUES, c'est-à-dire la configuration par
+défaut du DS. Deux ruptures indépendantes dans le code partagé, corrigeant
+l'une ne suffisait pas sans l'autre :
 
-  Rejoué sur 30 composants × 8 identités × 2 modes × 2 portées (racine ET
-  sous-arbre), soit **1 664 instances**, Chromium, contrôles positif et négatif
-  verts : **185 → 7 violations AA**, dont sombre **182 → 4** et clair
-  **3 → 3** (aucune régression). Les 7 restantes appartiennent toutes aux
-  palettes de marque de `packages/marketing`, aucune au DS, et aucune ne
-  descend sous 2:1. Harnais : `pnpm -F @origam/tests audit:dark-contrast`.
+1. **`toRgb()`** faisait **toujours** passer la couleur par un aller-retour
+   `canvas.fillStyle`, même quand `getComputedStyle` avait déjà rendu une
+   chaîne `rgb()/rgba()` exploitable. Le getter `fillStyle` de Chromium
+   sérialise toute couleur OPAQUE en hexadécimal `#rrggbb` (seul l'alpha < 1
+   ressort en `rgba(…)`), ce qui transformait une valeur déjà utilisable en
+   une valeur morte pour `rgbaParts`/`channelsOf`.
+2. **`channelsOf()`** extrayait les canaux via `match(/[\d.]+/g)`, taillé
+   pour `rgb(r, g, b)` — une suite de chiffres hexadécimaux SANS séparateur
+   (ex. `#777777`, six chiffres) s'agrège en UN seul grand nombre au lieu de
+   trois, donc `channelsOf` rend `null` sur exactement la forme hex que la
+   rupture 1 pouvait encore produire (couleur nommée, `hsl()`, …
+   nécessitant légitimement le détour par le canvas).
 
-  ⚠️ **Ces bornes ont d'abord été publiées à `189 → 11`, et les deux étaient
-  fausses de 4.** Le parseur de couleurs du harnais ne connaissait pas
-  `color(srgb …)`, que la palette `apple` émet : le fond translucide du
-  tooltip était pris pour « pas de fond », la remontée d'ancêtres sautait
-  jusqu'à la surface opaque et rapportait du noir sur noir à 1.00 — quatre
-  violations **fabriquées**, présentes des DEUX côtés de la mesure. Le
-  **delta de 178 n'a jamais été faux** ; seules les bornes l'étaient. Détail
-  et garde de non-récidive plus bas.
+**Correctif** : `toRgb()` court-circuite désormais le canvas quand l'entrée
+est déjà `rgb()/rgba()` (le cas de la quasi-totalité des appels, puisqu'ils
+lisent `getComputedStyle`), et le chemin canvas restant convertit son
+résultat hexadécimal en `rgb()/rgba()` via un nouveau `hexToRgb()` avant de
+le rendre — `toRgb()` ne rend plus jamais de hex. La mécanique de correction
+elle-même (forcer noir/blanc, poser `data-origam-contrast-fixed`, journaliser
+le ratio) n'est pas modifiée : elle fonctionnait déjà, elle n'était
+simplement jamais atteinte.
+
+**Preuve** — `packages/tests/e2e/contrast-directive.spec.ts` (Playwright,
+Chromium réel — jsdom n'a pas de `canvas.getContext('2d')` fonctionnel dans
+ce dépôt, donc ne peut ni reproduire ni vérifier ce bug) : contrôle positif
+(`#777777` sur blanc, 4.48:1, opaque des deux côtés) déclenche désormais la
+correction + le `console.warn` ; contrôle négatif (noir sur blanc, 21:1) ne
+déclenche rien ; non-régression du chemin translucide (fond composé via
+`resolvePaintedBackground`) inchangée. **A/B contre le commit parent** : 4
+des 5 tests rougissent sur le code d'avant (le contrôle négatif reste vert
+des deux côtés, comme attendu).
+
+⚠️ **Rayon mesuré séparément, pas hérité de #871 — et le chiffre publié par
+#871 contenait un artefact, corrigé depuis par #883.** Le chiffrage initial
+du ticket (346 violations en mode sombre) datait d'avant #876. #876 avait
+d'abord publié **189 → 11** ; en rejouant `audit/dark-contrast.audit.mjs`
+avec la VRAIE directive (redirect du stub désactivé) au lieu de sa
+reformulation mathématique, seuls **7 `console.warn` réels** se
+déclenchaient sur les 32 configurations (30 composants × 8 identités × 2
+modes, portées racine + sous-arbre) — écart signalé à l'auteur de #876, qui
+l'a reproduit, creusé et corrigé sous #883 : **les bornes AVANT et APRÈS
+étaient toutes les deux fausses (185 → 7, pas 189 → 11)**, la même erreur de
+mesure existant déjà dans le comptage "avant". Le delta réel (178) n'a
+jamais changé.
+
+L'écart venait d'`origam-tooltip__content` (identité `apple`, root + subtree,
+light + dark) et, découvert par #883, également d'`origam-bottom-nav` sur la
+même identité. Fond réel : `color(srgb 0.898039 0.898039 0.905882 / 0.94)`
+(translucide) ; `toRgb()` le résout correctement en `rgb(215, 215, 217)` une
+fois composé sur son ancêtre opaque, contre du texte noir : **ratio 14.61:1,
+conforme** — vérifié en appelant directement `toRgb()`/
+`resolvePaintedBackground()` de la vraie directive sur cette page. La
+fonction `parse()` de `dark-contrast.audit.mjs` (une réimplémentation
+distincte, pas la directive) ne reconnaissait que `rgba?\(…\)` — elle
+ignorait silencieusement cette couche `color(srgb …)`, sautait jusqu'à
+l'ancêtre opaque suivant et rapportait à tort un faux "noir sur noir"
+(ratio 1.00). **Ce n'était pas un défaut du DS ni de `v-contrast`** — la
+même classe de lacune que ce ticket corrige, mais dans un autre fichier. Les
+7 restantes (4 `origam-badge__badge`, 3 `origam-breadcrumb-item`) sont
+confirmées identiques entre les deux mesures, et `sous 2:1` passe à **0** une
+fois l'artefact retiré : plus rien de ce qui reste n'est proche d'invisible.
+
+Non corrigé ici : `dark-contrast.audit.mjs` appartenait à #871/#876, pas à ce
+ticket — signalé, reproduit et corrigé séparément sous #883 (ne pas citer
+189 → 11, c'était faux des deux côtés).
+
+**Rupture d'API** : aucune — `toRgb`/`channelsOf`/`hexToRgb` restent des
+fonctions privées du module, non exportées ; la surface publique
+(`setContrastConfig`, `v-contrast` par défaut) est inchangée.
+
+## [2.18.2] - 2026-09-23
+
+### Fixed
 
 - **#871 — le harnais de contraste ne savait pas lire `color(srgb …)`, et
   FABRIQUAIT donc des violations.** Son `parse()` ne reconnaissait que
@@ -741,46 +824,6 @@ conclure qu'elle ne l'est plus par défaut.
   propre n'a été ouvert : le défaut est dans l'instrumentation de #871, donc
   il se règle sous #871.
 
-- **#871 — `system-bar` et `tooltip` illisibles en sombre.** Les deux peignent
-  une surface sombre dans les DEUX modes (`neutral---700` / `neutral---800`)
-  et lisaient `text---inverse`, qui vaut blanc en clair et **encre** en
-  sombre : 1.91:1 et 1.31:1. `dark.css` lit maintenant `text---primary` ;
-  `light.css` est inchangé.
-
-- **#871 — `bottom-nav` peignait une dalle claire dans une UI sombre.** Son
-  fond était épinglé à la primitive `neutral---200` (#e6e6e6) dans les deux
-  modes, sous un `text---primary` presque blanc (1.03:1). En sombre il passe
-  au token sémantique `surface---overlay`. Le clair est inchangé.
-
-### Changed — ⛔ RUPTURE (documentée, assumée)
-
-- **Les feuilles de tokens ne sont plus ancrées à `:root`.** Un consommateur
-  qui avait contourné le gel ci-dessus en re-déclarant lui-même des variables
-  de composant dans un sous-arbre `[data-mode]` voit désormais la feuille les
-  déclarer aussi, en (0,1,0) côté clair et (0,2,0) côté sombre. Son bloc de
-  contournement doit donc être au moins aussi spécifique, ou être retiré.
-
-  Concrètement dans ce dépôt : `packages/marketing` embarque
-  `ORIGAM_COMPONENT_RESET_LIGHT/DARK` (`themes/origam-reset.generated.ts`),
-  une re-déclaration GÉNÉRÉE de ~2 700 variables de composant, écrite
-  exactement pour ce défaut. Elle est maintenant redondante — **elle n'a pas
-  été retirée ici**, faute de mesure sur le rendu du site.
-
-  Ce qui NE change pas : `data-theme="light" data-mode="dark"` reste clair
-  (l'axe marque gouverne quand les deux se contredisent, règle #807),
-  `data-mode="light"` sous un OS sombre reste clair (#794), et une marque
-  claire continue de gagner sur la feuille par l'ordre source.
-
-### Documentation
-
-- `CLAUDE.md`, section *Multi-theme* : la note qui affirmait que le bloc
-  auto-mode ne porte que **11** déclarations est **fausse** — recompté en
-  parsant la feuille le 2026-09-22, les deux blocs en portent **2 731**
-  chacun. L'affirmation décrivait un état antérieur à #794 que plus rien ne
-  remesurait.
-
-### Fixed
-
 - **#371 (point 3) — le sélecteur « Items per page » du footer
   DataTable n'avait aucun nom accessible**, déjà corrigé par `3f063d727`
   (2026-09-10) — ce commit **citait #371 sans le fermer**, sixième
@@ -816,85 +859,218 @@ conclure qu'elle ne l'est plus par défaut.
   `OrigamDataTableRow.story.vue`) et d'une section « Responsive » +
   ligne de table dans `OrigamDataTable.md`.
 
----
+## [2.18.1] - 2026-09-22
 
-#### `v-contrast` était silencieusement inerte sur fond opaque (#869)
+Récolte de deux dépréciations posées "pour la prochaine majeure" avant que le
+`CLAUDE.md` n'acte que `3.0.0` est réservé à la séparation en modules et que
+les ruptures, elles, ne le sont pas — voir "Work priorities and versioning"
+du `CLAUDE.md`. `origam` n'a aucun consommateur : les deux ruptures
+ci-dessous partent en **mineure**, sans shim ni période de grâce.
 
-La directive `v-contrast`, câblée sur 30 composants, n'émettait **jamais**
-rien — ni classe, ni `color: !important`, ni `console.warn` — dès que fond
-**et** texte étaient tous deux OPAQUES, c'est-à-dire la configuration par
-défaut du DS. Deux ruptures indépendantes dans le code partagé, corrigeant
-l'une ne suffisait pas sans l'autre :
+### ⚠️ BREAKING — `click:prepend` / `click:append` retirés d'`IBtnEmits` (#443, #577)
 
-1. **`toRgb()`** faisait **toujours** passer la couleur par un aller-retour
-   `canvas.fillStyle`, même quand `getComputedStyle` avait déjà rendu une
-   chaîne `rgb()/rgba()` exploitable. Le getter `fillStyle` de Chromium
-   sérialise toute couleur OPAQUE en hexadécimal `#rrggbb` (seul l'alpha < 1
-   ressort en `rgba(…)`), ce qui transformait une valeur déjà utilisable en
-   une valeur morte pour `rgbaParts`/`channelsOf`.
-2. **`channelsOf()`** extrayait les canaux via `match(/[\d.]+/g)`, taillé
-   pour `rgb(r, g, b)` — une suite de chiffres hexadécimaux SANS séparateur
-   (ex. `#777777`, six chiffres) s'agrège en UN seul grand nombre au lieu de
-   trois, donc `channelsOf` rend `null` sur exactement la forme hex que la
-   rupture 1 pouvait encore produire (couleur nommée, `hsl()`, …
-   nécessitant légitimement le détour par le canvas).
+`<OrigamBtn>` n'émet plus `click:prepend` ni `click:append` — ni au niveau du
+type, ni au niveau de l'exécution. `IBtnEmits` n'`extends` plus
+`IAdjacentEmits`, et les `<span>` `origam-btn__prepend` / `__append` ne
+portent plus de `@click` du tout : un clic souris dessus ne déclenche plus
+rien.
 
-**Correctif** : `toRgb()` court-circuite désormais le canvas quand l'entrée
-est déjà `rgb()/rgba()` (le cas de la quasi-totalité des appels, puisqu'ils
-lisent `getComputedStyle`), et le chemin canvas restant convertit son
-résultat hexadécimal en `rgb()/rgba()` via un nouveau `hexToRgb()` avant de
-le rendre — `toRgb()` ne rend plus jamais de hex. La mécanique de correction
-elle-même (forcer noir/blanc, poser `data-origam-contrast-fixed`, journaliser
-le ratio) n'est pas modifiée : elle fonctionnait déjà, elle n'était
-simplement jamais atteinte.
+**Pourquoi cette paire précisément, et pourquoi une suppression plutôt qu'un
+correctif.** Les deux émissions n'ont jamais été atteignables au clavier :
+l'événement partait d'un `<span>` descendant, alors qu'une activation clavier
+synthétise son clic sur la RACINE du composant — l'écouteur posé sur le
+descendant ne le voit jamais. Le correctif générique appliqué aux dix autres
+consommateurs d'`useAdjacent` (promouvoir la zone en `role="button"` + arrêt
+de tabulation) est **illégal** ici : `<OrigamBtn>` rend un `<button>` ou un
+`<a>`, et le modèle de contenu HTML interdit à tous deux un descendant de
+contenu interactif *et* tout descendant portant `tabindex`. Un
+`<button type="button">` imbriqué y est tout aussi invalide. La forme était
+fausse, pas seulement le balisage : un contrôle qui possède déjà une action
+ne peut pas en héberger une seconde — deux actions sont deux boutons,
+composés via `<origam-btn-group>`.
 
-**Preuve** — `packages/tests/e2e/contrast-directive.spec.ts` (Playwright,
-Chromium réel — jsdom n'a pas de `canvas.getContext('2d')` fonctionnel dans
-ce dépôt, donc ne peut ni reproduire ni vérifier ce bug) : contrôle positif
-(`#777777` sur blanc, 4.48:1, opaque des deux côtés) déclenche désormais la
-correction + le `console.warn` ; contrôle négatif (noir sur blanc, 21:1) ne
-déclenche rien ; non-régression du chemin translucide (fond composé via
-`resolvePaintedBackground`) inchangée. **A/B contre le commit parent** : 4
-des 5 tests rougissent sur le code d'avant (le contrôle négatif reste vert
-des deux côtés, comme attendu).
+**Ce qui NE bouge PAS** : les slots `prepend` / `append` (`IBtnSlots extends
+IAdjacentSlots`) restent intacts, ainsi que les props `prependIcon` /
+`appendIcon` / `prependAvatar` / `appendAvatar` — un contenu décoratif ou
+informationnel en prepend/append reste parfaitement légitime, seule
+l'émission d'un clic disparaît.
 
-⚠️ **Rayon mesuré séparément, pas hérité de #871 — et le chiffre publié par
-#871 contenait un artefact, corrigé depuis par #883.** Le chiffrage initial
-du ticket (346 violations en mode sombre) datait d'avant #876. #876 avait
-d'abord publié **189 → 11** ; en rejouant `audit/dark-contrast.audit.mjs`
-avec la VRAIE directive (redirect du stub désactivé) au lieu de sa
-reformulation mathématique, seuls **7 `console.warn` réels** se
-déclenchaient sur les 32 configurations (30 composants × 8 identités × 2
-modes, portées racine + sous-arbre) — écart signalé à l'auteur de #876, qui
-l'a reproduit, creusé et corrigé sous #883 : **les bornes AVANT et APRÈS
-étaient toutes les deux fausses (185 → 7, pas 189 → 11)**, la même erreur de
-mesure existant déjà dans le comptage "avant". Le delta réel (178) n'a
-jamais changé.
+**Preuve du comportement retiré** — A/B contre le commit parent, fonctionnel
+et pas seulement typé : `packages/tests/TU/components/Btn/OrigamBtn.adjacent-emit-removed.spec.ts`
+monte `<OrigamBtn>` avec un écouteur `onClick:prepend` / `onClick:append` et
+déclenche un vrai `click` DOM sur la zone. Sur le commit parent, ce même test
+appellerait l'écouteur (l'émission déclarée par `IAdjacentEmits` partait
+encore) ; sur ce commit, l'écouteur n'est jamais invoqué — vérifié en
+rejouant le fichier de spec avant/après le changement, pas seulement en le
+lisant une fois vert.
 
-L'écart venait d'`origam-tooltip__content` (identité `apple`, root + subtree,
-light + dark) et, découvert par #883, également d'`origam-bottom-nav` sur la
-même identité. Fond réel : `color(srgb 0.898039 0.898039 0.905882 / 0.94)`
-(translucide) ; `toRgb()` le résout correctement en `rgb(215, 215, 217)` une
-fois composé sur son ancêtre opaque, contre du texte noir : **ratio 14.61:1,
-conforme** — vérifié en appelant directement `toRgb()`/
-`resolvePaintedBackground()` de la vraie directive sur cette page. La
-fonction `parse()` de `dark-contrast.audit.mjs` (une réimplémentation
-distincte, pas la directive) ne reconnaissait que `rgba?\(…\)` — elle
-ignorait silencieusement cette couche `color(srgb …)`, sautait jusqu'à
-l'ancêtre opaque suivant et rapportait à tort un faux "noir sur noir"
-(ratio 1.00). **Ce n'était pas un défaut du DS ni de `v-contrast`** — la
-même classe de lacune que ce ticket corrige, mais dans un autre fichier. Les
-7 restantes (4 `origam-badge__badge`, 3 `origam-breadcrumb-item`) sont
-confirmées identiques entre les deux mesures, et `sous 2:1` passe à **0** une
-fois l'artefact retiré : plus rien de ce qui reste n'est proche d'invisible.
+Nettoyage induit : le helper `warnDeprecatedEmit` (`color.util.ts`) et la
+constante `ADJACENT_EMIT_REPLACEMENT` (`consts/Btn/btn.const.ts`) sont
+retirés — `<OrigamBtn>` était leur seul appelant, et le fichier `btn.const.ts`
+devenu vide est supprimé.
 
-Non corrigé ici : `dark-contrast.audit.mjs` appartenait à #871/#876, pas à ce
-ticket — signalé, reproduit et corrigé séparément sous #883 (ne pas citer
-189 → 11, c'était faux des deux côtés).
+**Migration.** Aucun consommateur interne (DS, marketing, stories, docs,
+tests) n'utilisait `click:prepend` / `click:append` sur `<OrigamBtn>` —
+balayage exhaustif, zéro résultat. Un consommateur externe qui les écoutait
+doit remplacer l'action posée sur la zone prepend/append par un second
+`<origam-btn>` dans un `<origam-btn-group>`.
 
-**Rupture d'API** : aucune — `toRgb`/`channelsOf`/`hexToRgb` restent des
-fonctions privées du module, non exportées ; la surface publique
-(`setContrastConfig`, `v-contrast` par défaut) est inchangée.
+### ⚠️ BREAKING — `createOrigam()` nu n'installe plus le thème par défaut (#360)
+
+`createOrigam()` préfixait inconditionnellement chaque install avec le thème
+neutre interne `origamTheme` (`[...origamTheme, ...suppliedThemes]`) : même un
+appel nu, ou un `themes: []` explicite, recevait quand même les variables CSS
+et — surtout — les **props par défaut par composant** (ADR-005,
+`components: { 'origam-avatar': { rounded: 'full' }, … }`) de ce thème. Une
+application qui n'en voulait pas ne pouvait pas s'en défaire. Ce préfixage est
+retiré : `createOrigam()` installe désormais exactement ce qu'on lui passe,
+rien de plus.
+
+**Ce qui change concrètement.** Sans `themes`/`theme` explicite,
+`createOrigam()` n'injecte plus aucune variable `--origam-*` et le résolveur
+de props par défaut (`installThemePropsResolver`, ADR-005) n'a plus rien à
+résoudre — chaque composant retombe uniquement sur ses propres valeurs
+`withDefaults()`. Concrètement : un `<origam-avatar>` sans prop `rounded`
+explicite n'est plus automatiquement circulaire (`rounded="full"` venait du
+thème, pas du composant).
+
+**Le thème par défaut reste disponible, à la demande** — `origamTheme`,
+exporté par `origam/themes` (déjà public avant cette rupture, aucun nouvel
+export nécessaire) :
+
+```ts
+// AVANT (2.x) — enregistrait implicitement le thème origam par défaut
+import { createOrigam } from 'origam'
+app.use(createOrigam())
+
+// APRÈS — le thème par défaut est un choix explicite
+import { createOrigam } from 'origam'
+import { origamTheme } from 'origam/themes'
+app.use(createOrigam({ themes: origamTheme }))
+```
+
+**Rayon de souffle mesuré, corrigé dans le même lot** — quatre consommateurs
+directs de `createOrigam()` nu trouvés par balayage exhaustif (DS, marketing,
+stories, docs, tests) :
+- `packages/ds/src/nuxt/module.ts` — le module Nuxt officiel. **Non cassé** :
+  son propre `DEFAULT_THEMES` (utilisé quand l'option `origam.themes` du
+  consommateur est omise) passe désormais `origamTheme` explicitement à
+  `createOrigam()`, préservant à l'identique le comportement de tout
+  consommateur Nuxt existant (marketing compris) qui ne configurait rien.
+  Seul un `createOrigam()` direct, hors module Nuxt, doit s'adapter.
+- `packages/marketing/nuxt.config.ts` — configure `origam.themes`
+  explicitement (7 thèmes de marque + un thème `origam` renommé pour le
+  playground `/theming`), ce qui **contourne** le fallback du module. Le vrai
+  thème neutre non-nommé (celui que `activeDefaultsFor` fusionne toujours en
+  premier, avant la marque active) était fourni jusqu'ici par le préfixage
+  implicite de `createOrigam()` — invisible dans la config marketing. Il est
+  désormais listé explicitement, en premier, dans le tableau `themes`.
+- `packages/stories/histoire.setup.ts` — Histoire (utilisé par les ~208
+  stories de composants) appelait `createOrigam()` nu ; sans correction,
+  chaque story aurait silencieusement perdu les props par défaut du thème
+  (avatars carrés au lieu de circulaires, etc.). Passe désormais
+  `{ themes: origamTheme }`.
+- `packages/docs/.vitepress/theme/index.ts` — les démos de composants live de
+  la doc VitePress appelaient `createOrigam()` nu ; même correction.
+
+Les échantillons de code montrés au consommateur (`installation.const.ts` /
+`installation.vue` sur le marketing, `guide/usage.md` côté docs) sont mis à
+jour pour montrer la forme correcte — un utilisateur copiant l'ancien
+exemple aurait obtenu des composants non stylés selon le thème.
+
+**Tests adaptés** (comptés avant correction, comme demandé) — 3 fichiers /
+5 assertions reposaient sur l'enregistrement implicite et ont été corrigés
+pour installer `origamTheme` explicitement là où le test vérifie précisément
+une valeur par défaut issue du thème, ou réécrits pour pinner le NOUVEAU
+contrat plutôt que l'ancien :
+- `theme-props-resolver.spec.ts` (2 assertions — `origam-radio`/`origam-text-field`
+  vs `origam-input` density) ;
+- `installed-themes.composable.spec.ts` (describe block entier renommé
+  `origam baseline — explicit opt-in only (#360)`, 2 assertions corrigées et
+  2 nouvelles ajoutées pour couvrir explicitement le nouveau contrat) ;
+- `OrigamChip.spec.ts` (1 assertion — `components['origam-chip'].size`).
+
+**Preuve fonctionnelle** (pas seulement structurelle) —
+`packages/tests/TU/origam/createOrigam-bare-no-theme-360.spec.ts` monte un
+vrai `<OrigamAvatar>` : sans thème, la classe `origam--rounded-full` est
+absente ; avec `origamTheme` passé explicitement, elle est présente — la
+même monteuse prouve donc que le harnais peut actionner la prop avant de
+conclure qu'elle ne l'est plus par défaut.
+
+### Fixed
+
+- **#871 — le mode sombre ne peignait qu'à moitié dans un sous-arbre thémé.**
+  Les feuilles de tokens portent ~1 761 déclarations **dérivées**
+  (`--origam-title---color: var(--origam-color__text---primary)`). Une custom
+  property est substituée **sur l'élément qui la déclare** ; ce qu'un
+  descendant hérite est la valeur DÉJÀ substituée. Le bloc sombre étant ancré
+  à la racine (`:root:not([data-theme])[data-mode="dark"]`), un sous-arbre
+  `<OrigamThemeProvider mode="dark">` basculait bien les ~60 tokens
+  sémantiques — le bloc runtime, lui, émet `[data-mode="dark"]` — mais laissait
+  les 1 761 dérivés **gelés** sur les valeurs claires de la racine. Motif
+  dominant mesuré : `rgb(10,10,10)` sur `rgb(10,10,10)`, texte et fond
+  identiques.
+
+  Les deux feuilles s'accrochent désormais aussi à l'axe `data-mode` :
+
+  ```css
+  :root, [data-theme="light"], [data-mode="light"]      { /* clair */ }
+  [data-theme="dark"], [data-mode="dark"]:not([data-theme="light"]) { /* sombre */ }
+  ```
+
+  Rejoué sur 30 composants × 8 identités × 2 modes × 2 portées (racine ET
+  sous-arbre), soit **1 664 instances**, Chromium, contrôles positif et négatif
+  verts : **185 → 7 violations AA**, dont sombre **182 → 4** et clair
+  **3 → 3** (aucune régression). Les 7 restantes appartiennent toutes aux
+  palettes de marque de `packages/marketing`, aucune au DS, et aucune ne
+  descend sous 2:1. Harnais : `pnpm -F @origam/tests audit:dark-contrast`.
+
+  ⚠️ **Ces bornes ont d'abord été publiées à `189 → 11`, et les deux étaient
+  fausses de 4.** Le parseur de couleurs du harnais ne connaissait pas
+  `color(srgb …)`, que la palette `apple` émet : le fond translucide du
+  tooltip était pris pour « pas de fond », la remontée d'ancêtres sautait
+  jusqu'à la surface opaque et rapportait du noir sur noir à 1.00 — quatre
+  violations **fabriquées**, présentes des DEUX côtés de la mesure. Le
+  **delta de 178 n'a jamais été faux** ; seules les bornes l'étaient. Détail
+  et garde de non-récidive plus bas.
+
+- **#871 — `system-bar` et `tooltip` illisibles en sombre.** Les deux peignent
+  une surface sombre dans les DEUX modes (`neutral---700` / `neutral---800`)
+  et lisaient `text---inverse`, qui vaut blanc en clair et **encre** en
+  sombre : 1.91:1 et 1.31:1. `dark.css` lit maintenant `text---primary` ;
+  `light.css` est inchangé.
+
+- **#871 — `bottom-nav` peignait une dalle claire dans une UI sombre.** Son
+  fond était épinglé à la primitive `neutral---200` (#e6e6e6) dans les deux
+  modes, sous un `text---primary` presque blanc (1.03:1). En sombre il passe
+  au token sémantique `surface---overlay`. Le clair est inchangé.
+
+### Changed — ⛔ RUPTURE (documentée, assumée)
+
+- **Les feuilles de tokens ne sont plus ancrées à `:root`.** Un consommateur
+  qui avait contourné le gel ci-dessus en re-déclarant lui-même des variables
+  de composant dans un sous-arbre `[data-mode]` voit désormais la feuille les
+  déclarer aussi, en (0,1,0) côté clair et (0,2,0) côté sombre. Son bloc de
+  contournement doit donc être au moins aussi spécifique, ou être retiré.
+
+  Concrètement dans ce dépôt : `packages/marketing` embarque
+  `ORIGAM_COMPONENT_RESET_LIGHT/DARK` (`themes/origam-reset.generated.ts`),
+  une re-déclaration GÉNÉRÉE de ~2 700 variables de composant, écrite
+  exactement pour ce défaut. Elle est maintenant redondante — **elle n'a pas
+  été retirée ici**, faute de mesure sur le rendu du site.
+
+  Ce qui NE change pas : `data-theme="light" data-mode="dark"` reste clair
+  (l'axe marque gouverne quand les deux se contredisent, règle #807),
+  `data-mode="light"` sous un OS sombre reste clair (#794), et une marque
+  claire continue de gagner sur la feuille par l'ordre source.
+
+### Documentation
+
+- `CLAUDE.md`, section *Multi-theme* : la note qui affirmait que le bloc
+  auto-mode ne porte que **11** déclarations est **fausse** — recompté en
+  parsant la feuille le 2026-09-22, les deux blocs en portent **2 731**
+  chacun. L'affirmation décrivait un état antérieur à #794 que plus rien ne
+  remesurait.
 
 ## [2.18.0] - 2026-09-19