origam 2.19.0 → 2.20.0

package/dist/src/interfaces/Commons/padding.interface.d.ts

@@ -6,7 +6,10 @@
  *
  *   1. `padding`                        — global shorthand
  *   2. `paddingBlock` / `paddingInline` — logical axis
- *   3. `paddingTop` / `paddingRight` / `paddingBottom` / `paddingLeft`
+ *   3. `paddingInlineStart` / `paddingInlineEnd` /
+ *      `paddingBlockStart` / `paddingBlockEnd`  — logical side
+ *   4. `paddingTop` / `paddingRight` / `paddingBottom` / `paddingLeft`
+ *      — physical side
  *
  * Each rung only overrides the edge(s) it targets. See
  * `resolveSpacingValue` for the accepted value forms, and
@@ -15,6 +18,14 @@
  * ⚠️ The 4-value `padding` shorthand distributes as
  * **Haut/Gauche/Bas/Droite**, NOT the CSS clockwise order (issue #216).
  * The per-side props exist so you never have to know that.
+ *
+ * ⚠️ Rungs 3 and 4 are EQUALLY specific — `paddingInlineStart` and
+ * `paddingLeft` are two spellings of the same edge in LTR horizontal-tb, so
+ * neither is "more specific" than the other and the tiebreak is a choice,
+ * not a derivation. The physical one wins, which keeps the direction the
+ * repo's only other physical-vs-logical tiebreak already takes (see
+ * `ROUNDED_CORNER_MAP` in `consts/Commons/spacing.const.ts`). Setting both
+ * for one edge is a consumer mistake either way; pick one grid.
  */
 export interface IPaddingProps {
     /**
@@ -35,4 +46,33 @@ export interface IPaddingProps {
     paddingBlock?: boolean | number | string;
     /** Left + right. Overrides `padding`; beaten by `paddingLeft` / `paddingRight`. */
     paddingInline?: boolean | number | string;
+    /*********************************************************
+     * Logical per-side padding — rung 3 (issue #1013)
+     *
+     * @description
+     * One WRITING-MODE-RELATIVE edge each. They emit the native logical
+     * longhands (`padding-inline-start`, …), so the browser flips them
+     * under RTL and in vertical writing modes for you.
+     *
+     * @description
+     * `paddingInlineStart` — left in LTR, **right in RTL**.
+     * `paddingInlineEnd` — right in LTR, **left in RTL**.
+     * `paddingBlockStart` — top in horizontal-tb.
+     * `paddingBlockEnd` — bottom in horizontal-tb.
+     *
+     * @description
+     * Same vocabulary as `padding` (`16`, `"4"`, `"8px"`, `"var(…)"`,
+     * `"calc(…)"`). Each overrides `padding` and its axis prop for the one
+     * edge it targets, and is in turn beaten by the matching PHYSICAL prop
+     * (`paddingLeft` & co) — see the precedence note above.
+     *
+     * @description
+     * Prefer these over the physical four whenever the value is a
+     * reading-order offset — an indent, a gutter beside an accent rule —
+     * rather than a genuinely physical one.
+     ********************************************************/
+    paddingInlineStart?: boolean | number | string;
+    paddingInlineEnd?: boolean | number | string;
+    paddingBlockStart?: boolean | number | string;
+    paddingBlockEnd?: boolean | number | string;
 }

package/dist/src/interfaces/Commons/rounded.interface.d.ts

@@ -3,17 +3,26 @@ import type { TRounded } from '../../types/Commons/rounded.type';
  * Corner-radius surface.
  *
  * Precedence — SPECIFIC beats GLOBAL, same grammar as `IPaddingProps` /
- * `IMarginProps` / `IBorderProps`, with two rungs instead of three (there
- * is no logical-axis form for corners):
+ * `IMarginProps` / `IBorderProps`, with three rungs instead of four (there
+ * is no logical-AXIS form for corners — a corner belongs to both axes at
+ * once):
  *
  *   1. `rounded`                   — global shorthand
- *   2. `roundedTopLeft` / `roundedTopRight` /
- *      `roundedBottomLeft` / `roundedBottomRight`
+ *   2. `roundedStartStart` / `roundedStartEnd` /
+ *      `roundedEndStart` / `roundedEndEnd`      — logical corner
+ *   3. `roundedTopLeft` / `roundedTopRight` /
+ *      `roundedBottomLeft` / `roundedBottomRight`  — physical corner
  *
  * A corner prop only overrides the corner it targets — `rounded="lg"` plus
  * `roundedTopLeft="0px"` flattens one corner and leaves the other three at
  * `lg`. See `resolveRoundedCornerValue` for the accepted value forms and
  * `packages/docs/guide/spacing-and-corners.md` for the full reference.
+ *
+ * ⚠️ Rungs 2 and 3 are EQUALLY specific — `roundedStartStart` and
+ * `roundedTopLeft` are the same corner in LTR horizontal-tb, so the
+ * tiebreak is a choice, not a derivation. The physical one wins, the same
+ * direction `ROUNDED_CORNER_MAP` already documents against the shorthand's
+ * logical output. Pick one grid per component.
  */
 export interface IRoundedProps {
     /**
@@ -40,4 +49,38 @@ export interface IRoundedProps {
     roundedBottomLeft?: boolean | number | string;
     /** Bottom-right corner only. Same vocabulary as `roundedTopRight`. */
     roundedBottomRight?: boolean | number | string;
+    /*********************************************************
+     * Logical per-corner radius — rung 2 (issue #1013)
+     *
+     * @description
+     * One WRITING-MODE-RELATIVE corner each, emitted as the native logical
+     * longhands (`border-start-start-radius`, …) — the same family the
+     * 4-value `rounded` shorthand already emits, so these four address one
+     * of its corners instead of all four.
+     *
+     * @description
+     * ⚠️ THE NAME READS `{block}-{inline}`, per CSS. The first half is the
+     * block end, the second the inline end — it is NOT a clockwise walk,
+     * and the two halves are not interchangeable:
+     *
+     * @description
+     * `roundedStartStart` — block-start inline-start = top-LEFT in LTR.
+     * `roundedStartEnd` — block-start inline-end = top-RIGHT in LTR.
+     * `roundedEndStart` — block-end inline-start = bottom-LEFT in LTR.
+     * `roundedEndEnd` — block-end inline-end = bottom-RIGHT in LTR.
+     *
+     * @description
+     * Swapping the halves silently rounds the opposite corner — nothing
+     * warns, and the result looks deliberate.
+     *
+     * @description
+     * Same vocabulary as `roundedTopRight` (`8`, `'8px'`, `'md'`,
+     * `'large'`, `'var(…)'`), minus `shaped` / `shaped-invert`. Each
+     * overrides `rounded` for its corner and is beaten by the matching
+     * PHYSICAL corner prop.
+     ********************************************************/
+    roundedStartStart?: boolean | number | string;
+    roundedStartEnd?: boolean | number | string;
+    roundedEndStart?: boolean | number | string;
+    roundedEndEnd?: boolean | number | string;
 }

package/dist/src/types/Bracket/bracket.type.d.ts

@@ -103,3 +103,85 @@ export type TBracketElevation = TElevation | boolean | null | undefined;
  * layer.
  */
 export type TBracketBorder = IBorderProps['borderTop'] | null | undefined;
+/*********************************************************
+ * TBracketBorderProps
+ *
+ * @description
+ * `IBorderProps` MOINS les quatre aretes logiques INLINE (#1013). Partage
+ * par les interfaces Bracket dont les props de bordure sont resolues par
+ * `bracketSurfaceVars` — `IBracketProps` (la racine) et `IBracketMatchProps`
+ * (la carte). Declare UNE fois ici plutot que deux `Omit<>` recopies.
+ *
+ * @description
+ * ⛔ `IBracketCompetitorProps` n'utilise PAS ce type, a dessein :
+ * `OrigamBracketCompetitor` appelle `useStateEffect` pour de vrai
+ * (`OrigamBracketCompetitor.vue:209`), donc ses quatre aretes logiques
+ * atteignent `useBorder` et peignent. Restreindre par FAMILLE de composant
+ * au lieu de par consommation mesuree y retirerait quatre props qui
+ * marchent.
+ *
+ * @description
+ * Pourquoi les deux autres sont restreintes : elles ne peignent pas via
+ * `useBorder` mais via des custom properties `--origam-bracket-match---*`
+ * lues dans des declarations PHYSIQUES. Mapper une arete logique sur une
+ * arete physique au moment d'ecrire la feuille exige de connaitre le mode
+ * d'ecriture, et `inline-start` vaut `left` en LTR mais `right` en RTL.
+ * Aucune chaine de repli `var()` ne peut l'exprimer : la substitution est
+ * AVEUGLE au mode d'ecriture alors que le mapping de la propriete ne l'est
+ * pas.
+ *
+ * @description
+ * Les deux aretes de BLOC restent declarees et sont honorees :
+ * `block-start`/`block-end` valent invariablement `top`/`bottom` en
+ * `horizontal-tb`, hypothese que la feuille faisait deja pour `borderBlock`.
+ * Confirme par sonde navigateur sur l'axe logique (Chromium, LTR vs RTL) :
+ * les noms porteurs d'une composante INLINE changent d'arete, le controle
+ * negatif `padding-block-start` ne bouge pas.
+ *
+ * @description
+ * ⛔ Retirer plutot que declarer-et-ignorer est la regle que
+ * `bracket-surface.interface.ts` enonce deja pour cette couche : une prop
+ * typee, editable dans Histoire, et inerte est pire qu'une prop absente.
+ * Arbitre par le proprietaire le 2026-10-01. La completude de l'axe inline
+ * part dans son propre ticket (elle demande de convertir la cascade en
+ * longhands logiques, ce qui change le comportement RTL des props physiques
+ * existantes).
+ ********************************************************/
+export type TBracketBorderProps = Omit<IBorderProps, 'borderInlineStart' | 'borderInlineEnd' | 'borderInlineStartColor' | 'borderInlineEndColor'>;
+/*********************************************************
+ * TBracketRoundedProps — le pendant « coins » de {@link TBracketBorderProps}
+ *
+ * @description
+ * Même couche, même cause, même arbitrage (#1013, tranché par le
+ * propriétaire le 2026-10-01) : `OrigamBracket` n'appelle pas `useRounded`,
+ * il passe `props` en bloc à `utils/Bracket/bracket-surface.util.ts`, qui
+ * émet des custom properties relues par le SCSS d'`OrigamBracketMatch` dans
+ * des déclarations PHYSIQUES par coin. La substitution `var()` est AVEUGLE
+ * au mode d'écriture alors que le mapping de la propriété ne l'est pas,
+ * donc aucune chaîne de repli ne peut encoder « le physique gagne » ET « le
+ * logique se retourne en RTL » simultanément.
+ *
+ * @description
+ * ⛔ MAIS LES QUATRE SORTENT, là où le côté border n'en retire que deux. Le
+ * sursis des arêtes de BLOC ne s'applique pas à un coin : tout nom de coin
+ * logique est `{bloc}-{inline}` et porte donc une composante inline. Mesuré
+ * dans Chromium (sonde Playwright, LTR vs RTL) plutôt que déduit —
+ * `start-start` top-left -> top-RIGHT, `start-end` top-right -> top-LEFT,
+ * `end-start` bottom-left -> bottom-RIGHT, `end-end` bottom-right ->
+ * bottom-LEFT. Contrôle négatif `padding-block-start` -> `padding-top` :
+ * 40px dans les deux sens, il ne bouge pas, ce qui prouve que la sonde sait
+ * distinguer l'immobilité et que les quatre déplacements sont réels.
+ *
+ * @description
+ * PORTÉE VÉRIFIÉE — seul `IBracketProps` est restreint. Les deux autres
+ * interfaces Bracket qui étendent `IRoundedProps` consomment réellement
+ * leurs coins : `OrigamBracketMatch` et `OrigamBracketCompetitor` appellent
+ * `useRounded` / `useStateEffect`, et gardent donc la surface complète.
+ * `OrigamBracket` est le seul à n'avoir aucun de ces appels.
+ *
+ * @description
+ * Retirer plutôt que déclarer-et-ignorer, même règle que ci-dessus. La
+ * complétude de l'axe inline pour les coins suit le même ticket que pour
+ * les arêtes : il faut convertir la cascade en longhands logiques.
+ ********************************************************/
+export type TBracketRoundedProps = Omit<IRoundedProps, 'roundedStartStart' | 'roundedStartEnd' | 'roundedEndStart' | 'roundedEndEnd'>;

package/dist/src/types/Commons/anchor.type.d.ts

@@ -1,3 +1,4 @@
+import { BORDER_LOGICAL_AXIS } from '../../enums/Commons/border.enum';
 import { BLOCK, INLINE, START_END } from '../../enums/Commons/anchor.enum';
 export type TStartEnd = `${START_END}`;
 export type TBlock = `${BLOCK}`;
@@ -5,6 +6,53 @@ export type TBlockStartEnd = TBlock | TStartEnd;
 export type TInline = `${INLINE}`;
 export type TInlineStartEnd = TInline | TStartEnd;
 export type TDirectionBoth = TBlock | TInline;
+/*********************************************************
+ * TLogicalSide
+ *
+ * @description
+ * One LOGICAL box edge — `block-start` | `block-end` | `inline-start` |
+ * `inline-end`. The writing-mode-relative twin of {@link TDirectionBoth},
+ * which names the four PHYSICAL edges.
+ *
+ * @description
+ * Composed from the two enums that already carry this vocabulary rather
+ * than spelling a fifth literal union : `BORDER_LOGICAL_AXIS` fournit
+ * l'axe, `START_END` son extremite. Rien de neuf n'est declare, donc les
+ * cotes logiques ne peuvent pas deriver des props d'axe (`paddingInline`,
+ * `borderBlock`, …) qui lisent les memes membres.
+ *
+ * @description
+ * ⚠️ `BORDER_LOGICAL_AXIS` est border-NOMME mais pas border-PORTE — c'est
+ * deja le vocabulaire d'axe de padding et margin
+ * (`consts/Commons/spacing.const.ts` l'importe pour
+ * `PADDING_LOGICAL_AXIS_MAP` / `MARGIN_LOGICAL_AXIS_MAP`). Le reutiliser
+ * ici suit ce precedent au lieu d'ajouter un enum quasi identique.
+ *
+ * @description
+ * Consomme par les familles `*InlineStart` / `*InlineEnd` / `*BlockStart`
+ * / `*BlockEnd` de `IPaddingProps`, `IMarginProps` et `IBorderProps`
+ * (#1013), et par les tables qui les cablent.
+ ********************************************************/
+export type TLogicalSide = `${BORDER_LOGICAL_AXIS}-${START_END}`;
+/*********************************************************
+ * TLogicalCorner
+ *
+ * @description
+ * One LOGICAL box CORNER — `start-start` | `start-end` | `end-start` |
+ * `end-end`, dans l'ordre natif `border-{block}-{inline}-radius` (fin de
+ * bloc d'abord, fin d'inline ensuite). Le jumeau relatif au mode
+ * d'ecriture des noms physiques `top-left` / ….
+ *
+ * @description
+ * Compose depuis `START_END` seul, pour la meme raison anti-duplication
+ * que {@link TLogicalSide} : un coin est l'intersection d'une fin de bloc
+ * et d'une fin d'inline, donc le vocabulaire est `START_END` au carre.
+ *
+ * @description
+ * Consomme par les props `roundedStartStart` / `roundedStartEnd` /
+ * `roundedEndStart` / `roundedEndEnd` de `IRoundedProps` (#1013).
+ ********************************************************/
+export type TLogicalCorner = `${START_END}-${START_END}`;
 export type TAnchor = TBlock | TInline | 'center' | 'center center' | `${TBlock} ${TInline | 'center'}` | `${TInline} ${TBlock | 'center'}`;
 export type TParsedAnchor = {
     side: 'center';

package/dist/src/types/Commons/variant-preset.type.d.ts

@@ -6,10 +6,28 @@
  * pas une couche CSS : `Record<valeur du variant, Partial<props>>`.
  *
  * @description
- * C'est le type d'AUTORAT, celui qu'une table
- * `consts/{Composant}/{composant}-variant.const.ts` annote pour que le
- * compilateur refuse une valeur de variant inconnue ou un nom de prop que
- * le composant ne declare pas :
+ * C'est le type d'AUTORAT, celui qu'une table annote pour que le compilateur
+ * refuse une valeur de variant inconnue ou un nom de prop que le composant ne
+ * declare pas.
+ *
+ * @description
+ * La table vit dans le fichier de consts EXISTANT du composant —
+ * `consts/{Composant}/{composant}.const.ts` — jamais dans un second fichier
+ * cree pour elle. Arbitrage du proprietaire, 2026-10-01 : la regle
+ * anti-duplication du `CLAUDE.md` global commande de reutiliser le fichier de
+ * consts deja en place plutot que d'en ouvrir un parallele. Le pilote
+ * `KBD_VARIANT_PRESETS` est dans `consts/Kbd/kbd.const.ts`, et c'est la forme
+ * a copier.
+ *
+ * @description
+ * ⚠️ Cet en-tete prescrivait `{composant}-variant.const.ts`. C'etait FAUX —
+ * aucune table n'a jamais ete ecrite a ce chemin, et le `fixHint` de la garde
+ * `no-variant-css` portait la meme erreur. Les deux sont corriges ; voir la
+ * section « `variant` = a props PRESET » du `CLAUDE.md` a la racine, qui fait
+ * foi.
+ *
+ * @description
+ * La forme, telle que le pilote la pose :
  *
  *     export const KBD_VARIANT_PRESETS: TVariantPresets<TKbdVariant, IKbdProps> = {
  *         outlined: { bgColor: '...', border: 1 },

package/dist/src/utils/Bracket/bracket-surface.util.cjs

@@ -129,5 +129,24 @@ function bracketSurfaceVars(input) {
     const width = resolveBracketBorderWidth(input[widthProp]);
     if (width) vars[`--origam-bracket-match---border-${axis}-width`] = width;
   });
+  const BLOCK_EDGES = [{
+    edge: "block-start",
+    widthProp: "borderBlockStart",
+    colorProp: "borderBlockStartColor"
+  }, {
+    edge: "block-end",
+    widthProp: "borderBlockEnd",
+    colorProp: "borderBlockEndColor"
+  }];
+  BLOCK_EDGES.forEach(({
+    edge,
+    widthProp,
+    colorProp
+  }) => {
+    const width = resolveBracketBorderWidth(input[widthProp]);
+    if (width) vars[`--origam-bracket-match---border-${edge}-width`] = width;
+    const edgeColor = resolveBracketBorderColor(input[colorProp]);
+    if (edgeColor) vars[`--origam-bracket-match---border-${edge}-color`] = edgeColor;
+  });
   return vars;
 }

package/dist/src/utils/Bracket/bracket-surface.util.js

@@ -101,5 +101,15 @@ export function bracketSurfaceVars(input) {
     const width = resolveBracketBorderWidth(input[widthProp]);
     if (width) vars[`--origam-bracket-match---border-${axis}-width`] = width;
   });
+  const BLOCK_EDGES = [
+    { edge: "block-start", widthProp: "borderBlockStart", colorProp: "borderBlockStartColor" },
+    { edge: "block-end", widthProp: "borderBlockEnd", colorProp: "borderBlockEndColor" }
+  ];
+  BLOCK_EDGES.forEach(({ edge, widthProp, colorProp }) => {
+    const width = resolveBracketBorderWidth(input[widthProp]);
+    if (width) vars[`--origam-bracket-match---border-${edge}-width`] = width;
+    const edgeColor = resolveBracketBorderColor(input[colorProp]);
+    if (edgeColor) vars[`--origam-bracket-match---border-${edge}-color`] = edgeColor;
+  });
   return vars;
 }

package/dist/src/utils/Commons/border.util.d.ts

@@ -1,4 +1,4 @@
-import type { TDirectionBoth } from '../../types/Commons/anchor.type';
+import type { TDirectionBoth, TLogicalSide } from '../../types/Commons/anchor.type';
 import type { TBorderLogicalAxis } from '../../types/Commons/border.type';
 import type { TColor } from '../../types/Commons/color.type';
 /**
@@ -43,14 +43,22 @@ export declare function parseBorderPositionValue(value: string): {
  * physical too: no logical/physical mismatch for the consumer to
  * mentally translate) or a LOGICAL axis (`TBorderLogicalAxis` —
  * `borderBlock` / `borderInline`, which map onto the native CSS logical
- * properties `border-block-*` / `border-inline-*` verbatim). Both share
- * the exact same `border-{position}-{width,style,color}` template, so
- * one function covers both without duplicating the formatting logic
- * (unlike `formatBorderStylesVar`'s 2/4-value output for the global
- * `border` shorthand, which distributes ACROSS axes from a single value
- * list — a different concern).
+ * properties `border-block-*` / `border-inline-*` verbatim) or a LOGICAL
+ * SIDE (`TLogicalSide` — `borderInlineStart` / `borderInlineEnd` /
+ * `borderBlockStart` / `borderBlockEnd`, issue #1013, mapping onto
+ * `border-inline-start-*` and friends). All three share the exact same
+ * `border-{position}-{width,style,color}` template, so one function
+ * covers all of them without duplicating the formatting logic (unlike
+ * `formatBorderStylesVar`'s 2/4-value output for the global `border`
+ * shorthand, which distributes ACROSS axes from a single value list — a
+ * different concern).
+ *
+ * #1013 widened the `position` union by one member and changed NOTHING
+ * else here: `'inline-start'` interpolates into the same template and
+ * yields the correct native longhands. That is the whole reason the
+ * logical-per-side grid needed no new formatter.
  */
-export declare function formatBorderPositionStylesVar(position: TDirectionBoth | TBorderLogicalAxis, facets: {
+export declare function formatBorderPositionStylesVar(position: TDirectionBoth | TBorderLogicalAxis | TLogicalSide, facets: {
     width?: string;
     style?: string;
     color?: string;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "origam",
-  "version": "2.19.0",
+  "version": "2.20.0",
   "type": "module",
   "description": "origam — a Vue 3 design system with multi-theme design tokens, CSS-first components and TypeScript types.",
   "keywords": [