origam 2.19.0 → 2.20.0

package/dist/src/consts/Commons/border.const.d.ts

@@ -1,5 +1,6 @@
 import { BLOCK, INLINE } from '../../enums';
 import type { TBorderLogicalAxis, TBorderWidthKeyword } from '../../types/Commons/border.type';
+import type { TLogicalSide } from '../../types/Commons/anchor.type';
 export declare const BORDER_REGEX: RegExp;
 /**
  * Physical-side lookup driving the per-side border wiring (issue #215).
@@ -37,14 +38,74 @@ export declare const BORDER_POSITION_MAP: readonly [{
  * onto the native CSS logical properties `border-block-{width,style,color}`
  * / `border-inline-{width,style,color}` — no physical translation table
  * needed, the browser resolves start/end per the active writing mode.
- * No matching `borderBlockColor` / `borderInlineColor` prop exists (the
- * per-side color override only applies to the 4 physical corners), so
- * unlike `BORDER_POSITION_MAP` there is no `colorProp` here.
+ * No matching `borderBlockColor` / `borderInlineColor` prop exists — the
+ * per-side color override is defined PER EDGE, not per axis, so an
+ * axis-level color prop would be ambiguous about which of its two edges
+ * it paints. Hence, unlike `BORDER_POSITION_MAP` and
+ * `BORDER_LOGICAL_SIDE_MAP` (both per-EDGE), there is no `colorProp`
+ * here.
+ *
+ * ⚠️ This note used to read "the per-side color override only applies to
+ * the 4 physical corners". That was true until #1013, which added the 4
+ * LOGICAL per-side color props — per-edge color is now available on both
+ * spellings. The reason this map has no `colorProp` was never the
+ * physical/logical distinction; it is the axis/edge one, which #1013 does
+ * not change.
  */
 export declare const BORDER_LOGICAL_AXIS_MAP: ReadonlyArray<{
     axis: TBorderLogicalAxis;
     widthProp: 'borderBlock' | 'borderInline';
 }>;
+/*********************************************************
+ * BORDER_LOGICAL_SIDE_MAP
+ *
+ * @description
+ * Logical-PER-SIDE lookup driving `borderInlineStart` / `borderInlineEnd`
+ * / `borderBlockStart` / `borderBlockEnd` and their four `*Color` twins
+ * (issue #1013). The third and last of the three directional grids: this
+ * map is to `BORDER_LOGICAL_AXIS_MAP` what `BORDER_POSITION_MAP` is to
+ * the global `border` shorthand — it narrows an axis to ONE of its two
+ * edges.
+ *
+ * @description
+ * ⛔ DELIBERATELY THE SAME SHAPE AS `BORDER_POSITION_MAP`
+ * (`{side, widthProp, colorProp}`), because `useBorder` iterates both
+ * with the SAME loop body. That body emits
+ * `border-${side}-{width,style,color}`, so a `side` of `'inline-start'`
+ * produces `border-inline-start-width` / `-style` / `-color` verbatim —
+ * the native CSS logical longhands, which the browser maps to the correct
+ * physical edge per the active writing mode. This lot is therefore an
+ * extension of an existing TABLE, not a new precedence grammar: nothing
+ * in the loop body changed to accommodate it.
+ *
+ * @description
+ * WHY LOGICAL PER SIDE AT ALL, given `borderInline` exists. The axis prop
+ * paints BOTH edges; there was no way to paint a single writing-mode-
+ * relative edge. The only alternative was a PHYSICAL prop
+ * (`borderLeft`), which silently breaks RTL — exactly the trap
+ * `OrigamBlockquote`'s accent rule avoids by hand-writing
+ * `border-inline-start` in its SCSS (#1013's trigger).
+ *
+ * @description
+ * ⚠️ VALUE GRAMMAR IS SHARED WITH THE OTHER TWO GRIDS, LIMITS INCLUDED.
+ * String values go through `parseBorderPositionValue` → `BORDER_REGEX`,
+ * so these props accept exactly what `borderLeft` / `borderBlock` accept
+ * and reject exactly what they reject. Measured 2026-10-01, and NOT
+ * introduced by this lot: `"calc(2px + 1px) solid red"` and a FRACTIONAL
+ * width such as `"0.5rem solid red"` both fail the regex outright (the
+ * width group is `[0-9]+` with no decimal point, and has no `calc()`
+ * alternative), so `parseBorderPositionValue` returns `null` and NOTHING
+ * is emitted. A tokenised width works only in the `var(--x) <style>`
+ * form, and a bare number (`:border-inline-start="4"`) bypasses the regex
+ * entirely via `convertToUnit`. Pinned by the "shared grammar limits"
+ * tests in `packages/tests/TU/composables/Commons/border-logical-side.spec.ts`
+ * so a future regex change has to acknowledge all three grids at once.
+ ********************************************************/
+export declare const BORDER_LOGICAL_SIDE_MAP: ReadonlyArray<{
+    side: TLogicalSide;
+    widthProp: 'borderBlockStart' | 'borderBlockEnd' | 'borderInlineStart' | 'borderInlineEnd';
+    colorProp: 'borderBlockStartColor' | 'borderBlockEndColor' | 'borderInlineStartColor' | 'borderInlineEndColor';
+}>;
 /*********************************************************
  * BORDER_PROP_KEYS
  *
@@ -63,7 +124,7 @@ export declare const BORDER_LOGICAL_AXIS_MAP: ReadonlyArray<{
  * retyped in four templates, where one forgotten key (`borderBlock`,
  * `borderTopColor`, …) would silently restore the defect for that one value.
  */
-export declare const BORDER_PROP_KEYS: readonly ["border", "borderTop", "borderRight", "borderBottom", "borderLeft", "borderBlock", "borderInline", "borderColor", "borderStyle", "borderTopColor", "borderRightColor", "borderBottomColor", "borderLeftColor"];
+export declare const BORDER_PROP_KEYS: readonly ["border", "borderTop", "borderRight", "borderBottom", "borderLeft", "borderBlock", "borderInline", "borderBlockStart", "borderBlockEnd", "borderInlineStart", "borderInlineEnd", "borderColor", "borderStyle", "borderTopColor", "borderRightColor", "borderBottomColor", "borderLeftColor", "borderBlockStartColor", "borderBlockEndColor", "borderInlineStartColor", "borderInlineEndColor"];
 /*********************************************************
  * BORDER_KEYWORD_WIDTH
  *

package/dist/src/consts/Commons/border.const.js

@@ -1,4 +1,4 @@
-import { BLOCK, BORDER_LOGICAL_AXIS, BORDER_STYLE, INLINE } from "../../enums/index.js";
+import { BLOCK, BORDER_LOGICAL_AXIS, BORDER_STYLE, INLINE, START_END } from "../../enums/index.js";
 const BORDER_STYLE_ALTERNATION = Object.values(BORDER_STYLE).join("|");
 const BORDER_LENGTH_UNITS = "(?:px|pt|PC|in|cm|mm|em|rem|%|ex|ch|fr)?";
 const BORDER_COLOR_GROUP = "(?<color>(?: ?(?:(?:(?:#)(?:[a-f0-9]{3}|[a-f0-9]{6}))|(?:var\\(--[^)]+\\))|(?:(?:rgb|hsl|rgba)a?\\(.*\\))|(?:[A-Za-z]+))){0,4})";
@@ -15,6 +15,12 @@ export const BORDER_LOGICAL_AXIS_MAP = [
   { axis: BORDER_LOGICAL_AXIS.BLOCK, widthProp: "borderBlock" },
   { axis: BORDER_LOGICAL_AXIS.INLINE, widthProp: "borderInline" }
 ];
+export const BORDER_LOGICAL_SIDE_MAP = [
+  { side: `${BORDER_LOGICAL_AXIS.BLOCK}-${START_END.START}`, widthProp: "borderBlockStart", colorProp: "borderBlockStartColor" },
+  { side: `${BORDER_LOGICAL_AXIS.BLOCK}-${START_END.END}`, widthProp: "borderBlockEnd", colorProp: "borderBlockEndColor" },
+  { side: `${BORDER_LOGICAL_AXIS.INLINE}-${START_END.START}`, widthProp: "borderInlineStart", colorProp: "borderInlineStartColor" },
+  { side: `${BORDER_LOGICAL_AXIS.INLINE}-${START_END.END}`, widthProp: "borderInlineEnd", colorProp: "borderInlineEndColor" }
+];
 export const BORDER_PROP_KEYS = [
   "border",
   "borderTop",
@@ -23,12 +29,20 @@ export const BORDER_PROP_KEYS = [
   "borderLeft",
   "borderBlock",
   "borderInline",
+  "borderBlockStart",
+  "borderBlockEnd",
+  "borderInlineStart",
+  "borderInlineEnd",
   "borderColor",
   "borderStyle",
   "borderTopColor",
   "borderRightColor",
   "borderBottomColor",
-  "borderLeftColor"
+  "borderLeftColor",
+  "borderBlockStartColor",
+  "borderBlockEndColor",
+  "borderInlineStartColor",
+  "borderInlineEndColor"
 ];
 export const BORDER_KEYWORD_WIDTH = {
   none: "var(--origam-border__width---0)",

package/dist/src/consts/Commons/spacing.const.cjs

@@ -3,7 +3,7 @@
 Object.defineProperty(exports, "__esModule", {
   value: true
 });
-exports.UTILITY_RADIUS_FALLBACK = exports.SPACING_SCALE_STEPS = exports.ROUNDED_CORNER_MAP = exports.PADDING_POSITION_MAP = exports.PADDING_LOGICAL_AXIS_MAP = exports.NAMED_RADIUS_TOKEN = exports.MARGIN_POSITION_MAP = exports.MARGIN_LOGICAL_AXIS_MAP = void 0;
+exports.UTILITY_RADIUS_FALLBACK = exports.SPACING_SCALE_STEPS = exports.ROUNDED_LOGICAL_CORNER_MAP = exports.ROUNDED_CORNER_MAP = exports.PADDING_POSITION_MAP = exports.PADDING_LOGICAL_SIDE_MAP = exports.PADDING_LOGICAL_AXIS_MAP = exports.NAMED_RADIUS_TOKEN = exports.MARGIN_POSITION_MAP = exports.MARGIN_LOGICAL_SIDE_MAP = exports.MARGIN_LOGICAL_AXIS_MAP = void 0;
 var _enums = require("../../enums/index.cjs");
 const SPACING_SCALE_STEPS = exports.SPACING_SCALE_STEPS = ["0", "1", "2", "3", "4", "5", "6", "8", "10", "12"];
 const PADDING_POSITION_MAP = exports.PADDING_POSITION_MAP = [{
@@ -26,6 +26,19 @@ const PADDING_LOGICAL_AXIS_MAP = exports.PADDING_LOGICAL_AXIS_MAP = [{
   axis: _enums.BORDER_LOGICAL_AXIS.INLINE,
   prop: "paddingInline"
 }];
+const PADDING_LOGICAL_SIDE_MAP = exports.PADDING_LOGICAL_SIDE_MAP = [{
+  side: `${_enums.BORDER_LOGICAL_AXIS.BLOCK}-${_enums.START_END.START}`,
+  prop: "paddingBlockStart"
+}, {
+  side: `${_enums.BORDER_LOGICAL_AXIS.BLOCK}-${_enums.START_END.END}`,
+  prop: "paddingBlockEnd"
+}, {
+  side: `${_enums.BORDER_LOGICAL_AXIS.INLINE}-${_enums.START_END.START}`,
+  prop: "paddingInlineStart"
+}, {
+  side: `${_enums.BORDER_LOGICAL_AXIS.INLINE}-${_enums.START_END.END}`,
+  prop: "paddingInlineEnd"
+}];
 const MARGIN_POSITION_MAP = exports.MARGIN_POSITION_MAP = [{
   side: _enums.BLOCK.TOP,
   prop: "marginTop"
@@ -46,6 +59,19 @@ const MARGIN_LOGICAL_AXIS_MAP = exports.MARGIN_LOGICAL_AXIS_MAP = [{
   axis: _enums.BORDER_LOGICAL_AXIS.INLINE,
   prop: "marginInline"
 }];
+const MARGIN_LOGICAL_SIDE_MAP = exports.MARGIN_LOGICAL_SIDE_MAP = [{
+  side: `${_enums.BORDER_LOGICAL_AXIS.BLOCK}-${_enums.START_END.START}`,
+  prop: "marginBlockStart"
+}, {
+  side: `${_enums.BORDER_LOGICAL_AXIS.BLOCK}-${_enums.START_END.END}`,
+  prop: "marginBlockEnd"
+}, {
+  side: `${_enums.BORDER_LOGICAL_AXIS.INLINE}-${_enums.START_END.START}`,
+  prop: "marginInlineStart"
+}, {
+  side: `${_enums.BORDER_LOGICAL_AXIS.INLINE}-${_enums.START_END.END}`,
+  prop: "marginInlineEnd"
+}];
 const ROUNDED_CORNER_MAP = exports.ROUNDED_CORNER_MAP = [{
   corner: "top-left",
   prop: "roundedTopLeft"
@@ -59,6 +85,19 @@ const ROUNDED_CORNER_MAP = exports.ROUNDED_CORNER_MAP = [{
   corner: "bottom-right",
   prop: "roundedBottomRight"
 }];
+const ROUNDED_LOGICAL_CORNER_MAP = exports.ROUNDED_LOGICAL_CORNER_MAP = [{
+  corner: `${_enums.START_END.START}-${_enums.START_END.START}`,
+  prop: "roundedStartStart"
+}, {
+  corner: `${_enums.START_END.START}-${_enums.START_END.END}`,
+  prop: "roundedStartEnd"
+}, {
+  corner: `${_enums.START_END.END}-${_enums.START_END.START}`,
+  prop: "roundedEndStart"
+}, {
+  corner: `${_enums.START_END.END}-${_enums.START_END.END}`,
+  prop: "roundedEndEnd"
+}];
 const NAMED_RADIUS_TOKEN = exports.NAMED_RADIUS_TOKEN = {
   "x-small": "var(--origam-radius---xs, 2px)",
   "small": "var(--origam-radius---sm, 4px)",

package/dist/src/consts/Commons/spacing.const.d.ts

@@ -1,4 +1,4 @@
-import type { TDirectionBoth } from '../../types/Commons/anchor.type';
+import type { TDirectionBoth, TLogicalCorner, TLogicalSide } from '../../types/Commons/anchor.type';
 import type { TBorderLogicalAxis } from '../../types/Commons/border.type';
 /**
  * Spacing scale steps mirrored by the global utility classes emitted from
@@ -45,6 +45,33 @@ export declare const PADDING_LOGICAL_AXIS_MAP: ReadonlyArray<{
     axis: TBorderLogicalAxis;
     prop: 'paddingBlock' | 'paddingInline';
 }>;
+/*********************************************************
+ * Logical-SIDE lookup driving the `paddingInlineStart` / `paddingInlineEnd`
+ * / `paddingBlockStart` / `paddingBlockEnd` wiring (issue #1013).
+ *
+ * This is the third and last grid of the directional surface. The repo
+ * already had PHYSICAL-per-side ({@link PADDING_POSITION_MAP}) and
+ * LOGICAL-per-axis ({@link PADDING_LOGICAL_AXIS_MAP}); logical-per-side was
+ * the half that stayed empty, which forced a consumer who wanted ONE
+ * writing-mode-relative edge to fall back on a physical prop and break RTL.
+ *
+ * Shape is deliberately identical to the two maps around it, so the SAME
+ * `forEach` body serves all three: `padding-${side}` yields
+ * `padding-inline-start` from `'inline-start'` exactly as it yields
+ * `padding-top` from `'top'`. No new grammar, one extra table.
+ *
+ * ⚠️ PRECEDENCE — these declarations are pushed AFTER the logical-axis rung
+ * and BEFORE the physical-per-side rung, so `paddingInlineStart` beats
+ * `paddingInline` (more specific: one edge, not two) while `paddingLeft`
+ * still beats `paddingInlineStart`. The tiebreak at that last step is not a
+ * specificity call — a physical and a logical longhand for the same edge
+ * are equally specific — it keeps "physical wins for the same edge" uniform
+ * with the rule {@link ROUNDED_CORNER_MAP} already documents below.
+ ********************************************************/
+export declare const PADDING_LOGICAL_SIDE_MAP: ReadonlyArray<{
+    side: TLogicalSide;
+    prop: 'paddingBlockStart' | 'paddingBlockEnd' | 'paddingInlineStart' | 'paddingInlineEnd';
+}>;
 /**
  * Physical-side lookup driving the per-side `margin*` wiring.
  * Same contract as {@link PADDING_POSITION_MAP}, one axis over.
@@ -61,6 +88,20 @@ export declare const MARGIN_LOGICAL_AXIS_MAP: ReadonlyArray<{
     axis: TBorderLogicalAxis;
     prop: 'marginBlock' | 'marginInline';
 }>;
+/*********************************************************
+ * Logical-SIDE lookup driving the `marginInlineStart` / `marginInlineEnd` /
+ * `marginBlockStart` / `marginBlockEnd` wiring (issue #1013).
+ * Same contract and same precedence rank as
+ * {@link PADDING_LOGICAL_SIDE_MAP}, one axis over.
+ *
+ * These four also accept the `auto` keyword, like their physical twins —
+ * `marginInlineStart="auto"` is the RTL-safe way to push a flex child to
+ * the far end, which `marginLeft="auto"` gets wrong under RTL.
+ ********************************************************/
+export declare const MARGIN_LOGICAL_SIDE_MAP: ReadonlyArray<{
+    side: TLogicalSide;
+    prop: 'marginBlockStart' | 'marginBlockEnd' | 'marginInlineStart' | 'marginInlineEnd';
+}>;
 /**
  * Per-corner lookup driving the `rounded{Corner}` wiring.
  *
@@ -77,6 +118,32 @@ export declare const ROUNDED_CORNER_MAP: ReadonlyArray<{
     corner: string;
     prop: 'roundedTopLeft' | 'roundedTopRight' | 'roundedBottomLeft' | 'roundedBottomRight';
 }>;
+/*********************************************************
+ * Logical-CORNER lookup driving the `roundedStartStart` / `roundedStartEnd`
+ * / `roundedEndStart` / `roundedEndEnd` wiring (issue #1013).
+ *
+ * Emits the native LOGICAL corner longhands
+ * (`border-start-start-radius`, …) — the same family the 4-value `rounded`
+ * shorthand already emits through `formatRoundedStylesVar`, so these four
+ * props address exactly one of its corners instead of all four.
+ *
+ * ⚠️ CORNER NAME ORDER IS `{block}-{inline}`, per CSS: `start-start` is the
+ * block-start inline-start corner (top-left in LTR horizontal-tb),
+ * `start-end` is block-start inline-end (top-right in LTR). It is NOT the
+ * physical clockwise order, and it is NOT axis-agnostic — swapping the two
+ * halves silently addresses the opposite corner.
+ *
+ * ⚠️ PRECEDENCE — pushed AFTER the `rounded` shorthand and BEFORE
+ * {@link ROUNDED_CORNER_MAP}'s physical declarations, so a logical corner
+ * beats the shorthand (more specific: one corner, not four) and a physical
+ * corner still beats a logical one for the same corner. That last step is
+ * the rule the paragraph above already states for the shorthand, applied
+ * one rung down; see `useRounded`'s precedence table.
+ ********************************************************/
+export declare const ROUNDED_LOGICAL_CORNER_MAP: ReadonlyArray<{
+    corner: TLogicalCorner;
+    prop: 'roundedStartStart' | 'roundedStartEnd' | 'roundedEndStart' | 'roundedEndEnd';
+}>;
 /**
  * Named radius variant → primitive radius token.
  *

package/dist/src/consts/Commons/spacing.const.js

@@ -1,4 +1,4 @@
-import { BLOCK, BORDER_LOGICAL_AXIS, INLINE } from "../../enums/index.js";
+import { BLOCK, BORDER_LOGICAL_AXIS, INLINE, START_END } from "../../enums/index.js";
 export const SPACING_SCALE_STEPS = [
   "0",
   "1",
@@ -21,6 +21,12 @@ export const PADDING_LOGICAL_AXIS_MAP = [
   { axis: BORDER_LOGICAL_AXIS.BLOCK, prop: "paddingBlock" },
   { axis: BORDER_LOGICAL_AXIS.INLINE, prop: "paddingInline" }
 ];
+export const PADDING_LOGICAL_SIDE_MAP = [
+  { side: `${BORDER_LOGICAL_AXIS.BLOCK}-${START_END.START}`, prop: "paddingBlockStart" },
+  { side: `${BORDER_LOGICAL_AXIS.BLOCK}-${START_END.END}`, prop: "paddingBlockEnd" },
+  { side: `${BORDER_LOGICAL_AXIS.INLINE}-${START_END.START}`, prop: "paddingInlineStart" },
+  { side: `${BORDER_LOGICAL_AXIS.INLINE}-${START_END.END}`, prop: "paddingInlineEnd" }
+];
 export const MARGIN_POSITION_MAP = [
   { side: BLOCK.TOP, prop: "marginTop" },
   { side: INLINE.RIGHT, prop: "marginRight" },
@@ -31,12 +37,24 @@ export const MARGIN_LOGICAL_AXIS_MAP = [
   { axis: BORDER_LOGICAL_AXIS.BLOCK, prop: "marginBlock" },
   { axis: BORDER_LOGICAL_AXIS.INLINE, prop: "marginInline" }
 ];
+export const MARGIN_LOGICAL_SIDE_MAP = [
+  { side: `${BORDER_LOGICAL_AXIS.BLOCK}-${START_END.START}`, prop: "marginBlockStart" },
+  { side: `${BORDER_LOGICAL_AXIS.BLOCK}-${START_END.END}`, prop: "marginBlockEnd" },
+  { side: `${BORDER_LOGICAL_AXIS.INLINE}-${START_END.START}`, prop: "marginInlineStart" },
+  { side: `${BORDER_LOGICAL_AXIS.INLINE}-${START_END.END}`, prop: "marginInlineEnd" }
+];
 export const ROUNDED_CORNER_MAP = [
   { corner: "top-left", prop: "roundedTopLeft" },
   { corner: "top-right", prop: "roundedTopRight" },
   { corner: "bottom-left", prop: "roundedBottomLeft" },
   { corner: "bottom-right", prop: "roundedBottomRight" }
 ];
+export const ROUNDED_LOGICAL_CORNER_MAP = [
+  { corner: `${START_END.START}-${START_END.START}`, prop: "roundedStartStart" },
+  { corner: `${START_END.START}-${START_END.END}`, prop: "roundedStartEnd" },
+  { corner: `${START_END.END}-${START_END.START}`, prop: "roundedEndStart" },
+  { corner: `${START_END.END}-${START_END.END}`, prop: "roundedEndEnd" }
+];
 export const NAMED_RADIUS_TOKEN = {
   "x-small": "var(--origam-radius---xs, 2px)",
   "small": "var(--origam-radius---sm, 4px)",

package/dist/src/interfaces/Bracket/bracket-match-component.interface.d.ts

@@ -1,6 +1,6 @@
 import type { IActiveEmits, IActiveProps } from '../Commons/active.interface';
 import type { IBgColorProps, IColorProps } from '../Commons/color.interface';
-import type { IBorderProps } from '../Commons/border.interface';
+import type { TBracketBorderProps } from '../../types/Bracket/bracket.type';
 import type { ICommonsComponentProps, ITagProps } from '../Commons/commons.interface';
 import type { IDensityProps } from '../Commons/density.interface';
 import type { IDimensionProps } from '../Commons/dimension.interface';
@@ -20,7 +20,7 @@ import type { IBracketMatch } from './bracket-match.interface';
  * border, density, dimension, padding, margin) so a standalone card
  * behaves like any other origam component.
  */
-export interface IBracketMatchProps extends ICommonsComponentProps, ITagProps, IColorProps, IBgColorProps, IHoverProps, IActiveProps, IRoundedProps, IElevationProps, IBorderProps, IDensityProps, IDimensionProps, IPaddingProps, IMarginProps {
+export interface IBracketMatchProps extends ICommonsComponentProps, ITagProps, IColorProps, IBgColorProps, IHoverProps, IActiveProps, IRoundedProps, IElevationProps, TBracketBorderProps, IDensityProps, IDimensionProps, IPaddingProps, IMarginProps {
     /** The match payload to render. */
     match: IBracketMatch;
     /**

package/dist/src/interfaces/Bracket/bracket-surface.interface.d.ts

@@ -53,4 +53,43 @@ export interface IBracketSurfaceInput {
     borderRightColor?: TBracketColor;
     borderBottomColor?: TBracketColor;
     borderLeftColor?: TBracketColor;
+    /*********************************************************
+     * LES DEUX ARETES LOGIQUES DE BLOC — ET POURQUOI PAS LES INLINE
+     *
+     * @description
+     * `borderBlockStart` / `borderBlockEnd` (+ `*Color`), issue #1013. Ce
+     * sont les SEULES des quatre aretes logiques que cette couche peut
+     * honorer, et l'asymetrie est mesuree, pas arbitraire.
+     *
+     * @description
+     * Cette couche peint via des custom properties
+     * `--origam-bracket-match---*` que la SCSS d'`OrigamBracketMatch` lit
+     * dans des declarations PHYSIQUES. Mapper une arete logique sur une
+     * arete physique a l'ecriture de la feuille demande donc de connaitre
+     * le mode d'ecriture.
+     * @description
+     * • AXE DE BLOC — `block-start` vaut `top` et `block-end` vaut `bottom`
+     *   en `horizontal-tb`, invariablement. Bracket ne declare jamais
+     *   `writing-mode` (verifie : 0 occurrence) et sa feuille fait DEJA
+     *   cette hypothese pour `borderBlock`, dont la var alimente
+     *   `border-top-width` et `border-bottom-width`. Ces deux aretes
+     *   n'ajoutent donc aucune hypothese nouvelle.
+     * @description
+     * • AXE INLINE — `inline-start` vaut `left` en LTR mais `right` en RTL.
+     *   Aucune chaine de repli ne peut exprimer ca : la substitution
+     *   `var()` est aveugle au mode d'ecriture alors que le mapping de la
+     *   propriete ne l'est pas. Les 4 props inline sont donc RETIREES de la
+     *   surface de Bracket par `Omit<>` (`bracket.interface.ts`) plutot que
+     *   declarees et ignorees — une prop typee et inerte est pire qu'une
+     *   prop absente.
+     *
+     * @description
+     * La completude de Bracket sur 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.
+     ********************************************************/
+    borderBlockStart?: TBracketBorder;
+    borderBlockEnd?: TBracketBorder;
+    borderBlockStartColor?: TBracketColor;
+    borderBlockEndColor?: TBracketColor;
 }

package/dist/src/interfaces/Bracket/bracket.interface.d.ts

@@ -1,14 +1,12 @@
 import type { IBgColorProps, IColorProps } from '../Commons/color.interface';
-import type { IBorderProps } from '../Commons/border.interface';
 import type { ICommonsComponentProps, ITagProps } from '../Commons/commons.interface';
 import type { IDensityProps } from '../Commons/density.interface';
 import type { IDimensionProps } from '../Commons/dimension.interface';
 import type { IElevationProps } from '../Commons/elevation.interface';
 import type { IMarginProps } from '../Commons/margin.interface';
 import type { IPaddingProps } from '../Commons/padding.interface';
-import type { IRoundedProps } from '../Commons/rounded.interface';
 import type { ITypographyProps } from '../Commons/typography.interface';
-import type { TBracketConnectorPath, TBracketVariant } from '../../types/Bracket/bracket.type';
+import type { TBracketBorderProps, TBracketRoundedProps, TBracketConnectorPath, TBracketVariant } from '../../types/Bracket/bracket.type';
 import type { IBracketCompetitor } from './bracket-competitor.interface';
 import type { IBracketMatchCompetitorSlot } from './bracket-match-component.interface';
 import type { IBracketMatch } from './bracket-match.interface';
@@ -24,7 +22,30 @@ import type { IBracketRound } from './bracket-round.interface';
  * data and re-render. No internal state is held about scores or
  * winners — the data passed in is the source of truth.
  */
-export interface IBracketProps extends ICommonsComponentProps, ITagProps, IDensityProps, IRoundedProps, IColorProps, IBgColorProps, IBorderProps, IDimensionProps, IElevationProps, IMarginProps, IPaddingProps, Pick<ITypographyProps, 'fontSize' | 'fontWeight' | 'letterSpacing'> {
+/*********************************************************
+ * Pourquoi les surfaces `border` ET `rounded` sont RESTREINTES ici — #1013
+ *
+ * @description
+ * `OrigamBracket` n'appelle ni `useBorder` ni `useRounded` : il passe
+ * `props` en bloc a `utils/Bracket/bracket-surface.util.ts`, qui emet des
+ * custom properties relues par un SCSS PHYSIQUE. Les props logiques par
+ * cote y sont donc structurellement incablables, et une prop typee,
+ * editable dans Histoire, mais inerte est pire qu'une prop absente.
+ *
+ * @description
+ * Les deux restrictions vivent dans `types/Bracket/bracket.type.ts`, un
+ * type nomme chacune, et portent la mesure qui les justifie :
+ * {@link TBracketBorderProps} retire les 4 aretes INLINE et garde les 2
+ * aretes de bloc (invariantes en `horizontal-tb`, donc cablees) ;
+ * {@link TBracketRoundedProps} retire les 4 coins logiques, car tout nom de
+ * coin est `{bloc}-{inline}` et porte donc une composante inline — le
+ * sursis de l'axe bloc n'existe pas pour un coin.
+ *
+ * @description
+ * Un seul idiome pour les deux moities du lot, volontairement : la
+ * directive du ticket est « si un format existe, il existe partout ».
+ ********************************************************/
+export interface IBracketProps extends ICommonsComponentProps, ITagProps, IDensityProps, TBracketRoundedProps, IColorProps, IBgColorProps, TBracketBorderProps, IDimensionProps, IElevationProps, IMarginProps, IPaddingProps, Pick<ITypographyProps, 'fontSize' | 'fontWeight' | 'letterSpacing'> {
     /**
      * Required. Pre-ordered list of rounds. For single-elimination,
      * the rounds are laid out from earliest (e.g. round-of-16) to

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

@@ -24,6 +24,72 @@ export interface IBorderProps {
      * mapped onto `border-inline-{width,style,color}`.
      */
     borderInline?: boolean | number | string;
+    /*********************************************************
+     * borderInlineStart
+     *
+     * @description
+     * Largeur/style/couleur LOGIQUE PAR COTE pour l'arete inline-start —
+     * gauche en LTR, droite en RTL (#1013). Le jumeau relatif au mode
+     * d'ecriture de `borderLeft`, resolu vers les longhands natifs
+     * `border-inline-start-{width,style,color}`, que le navigateur mappe
+     * lui-meme sur la bonne arete physique.
+     *
+     * @description
+     * A preferer a `borderLeft` des que l'intention de design est « l'arete
+     * ou le texte commence » (filet d'accent d'une citation, indicateur de
+     * nav, guide d'arborescence) : `borderLeft` epingle la peinture a la
+     * gauche physique et inverse silencieusement le design en RTL.
+     *
+     * @description
+     * Meme grammaire de valeur que toute autre prop directionnelle de
+     * bordure — opt-in booleen (token `thin`), largeur numerique nue, ou
+     * chaine libre `"width style color"`.
+     *
+     * @description
+     * Precedence : bat `borderInline` et le `border` global pour cette
+     * seule arete, mais un `borderLeft` PHYSIQUE l'emporte encore en LTR
+     * (les deux orthographes visent la meme arete a specificite egale,
+     * donc le dernier push gagne — voir la table de precedence de
+     * `useBorder`).
+     *
+     * @description
+     * ⚠️ Herite des limites partagees de `BORDER_REGEX` : un `calc()` ou
+     * une largeur fractionnaire (`"0.5rem solid red"`) ne parse pas et
+     * n'emet RIEN — mesure dans `BORDER_LOGICAL_SIDE_MAP`.
+     ********************************************************/
+    borderInlineStart?: boolean | number | string;
+    /*********************************************************
+     * borderInlineEnd
+     *
+     * @description
+     * Jumeau logique par cote de `borderInlineStart` pour l'arete
+     * inline-end — droite en LTR, gauche en RTL. Mappe sur
+     * `border-inline-end-{width,style,color}`. Meme grammaire, memes
+     * regles de precedence (un `borderRight` physique l'emporte en LTR).
+     ********************************************************/
+    borderInlineEnd?: boolean | number | string;
+    /*********************************************************
+     * borderBlockStart
+     *
+     * @description
+     * Jumeau logique par cote de `borderInlineStart` pour l'arete
+     * block-start — le haut dans le mode d'ecriture `horizontal-tb` par
+     * defaut. Mappe sur `border-block-start-{width,style,color}`. Meme
+     * grammaire, memes regles de precedence (un `borderTop` physique
+     * l'emporte).
+     ********************************************************/
+    borderBlockStart?: boolean | number | string;
+    /*********************************************************
+     * borderBlockEnd
+     *
+     * @description
+     * Jumeau logique par cote de `borderInlineStart` pour l'arete
+     * block-end — le bas dans le mode d'ecriture `horizontal-tb` par
+     * defaut. Mappe sur `border-block-end-{width,style,color}`. Meme
+     * grammaire, memes regles de precedence (un `borderBottom` physique
+     * l'emporte).
+     ********************************************************/
+    borderBlockEnd?: boolean | number | string;
     borderColor?: string;
     borderStyle?: string;
     /**
@@ -45,4 +111,61 @@ export interface IBorderProps {
     borderRightColor?: TColor;
     borderBottomColor?: TColor;
     borderLeftColor?: TColor;
+    /*********************************************************
+     * borderInlineStartColor
+     *
+     * @description
+     * Surcharge de couleur PAR ARETE pour l'arete inline-start (#1013) —
+     * le jumeau logique de `borderLeftColor`, emis en
+     * `border-inline-start-color`.
+     *
+     * @description
+     * Memes semantiques que la famille `*Color` physique : additive, bat
+     * toute couleur impliquee par `borderInlineStart` lui-meme (ex.
+     * `borderInlineStart="2px dashed red"`), la couleur d'axe de
+     * `borderInline`, et le `borderColor` / `border` global — pour cette
+     * arete seulement. Un `borderLeftColor` PHYSIQUE l'emporte encore en
+     * LTR, meme sens que pour les props de largeur.
+     *
+     * @description
+     * Accepte un {@link TColor} (intent semantique, couleur CSS brute, ou
+     * valeur fausse pour se desengager). Une bordure est un TRAIT, donc un
+     * intent se resout via la famille de tokens de PREMIER PLAN (comme la
+     * prop `color`), jamais un token de fond.
+     *
+     * @description
+     * Les degrades ne sont PAS supportes — `border-color` en CSS n'a pas de
+     * forme degradee — et sont ignores silencieusement.
+     ********************************************************/
+    borderInlineStartColor?: TColor;
+    /*********************************************************
+     * borderInlineEndColor
+     *
+     * @description
+     * Surcharge de couleur par arete pour l'arete inline-end — jumeau
+     * logique de `borderRightColor`, emis en `border-inline-end-color`.
+     * Meme grammaire {@link TColor} et meme precedence que
+     * `borderInlineStartColor`.
+     ********************************************************/
+    borderInlineEndColor?: TColor;
+    /*********************************************************
+     * borderBlockStartColor
+     *
+     * @description
+     * Surcharge de couleur par arete pour l'arete block-start — jumeau
+     * logique de `borderTopColor`, emis en `border-block-start-color`.
+     * Meme grammaire {@link TColor} et meme precedence que
+     * `borderInlineStartColor`.
+     ********************************************************/
+    borderBlockStartColor?: TColor;
+    /*********************************************************
+     * borderBlockEndColor
+     *
+     * @description
+     * Surcharge de couleur par arete pour l'arete block-end — jumeau
+     * logique de `borderBottomColor`, emis en `border-block-end-color`.
+     * Meme grammaire {@link TColor} et meme precedence que
+     * `borderInlineStartColor`.
+     ********************************************************/
+    borderBlockEndColor?: TColor;
 }

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

@@ -6,7 +6,10 @@
  *
  *   1. `margin`                       — global shorthand
  *   2. `marginBlock` / `marginInline` — logical axis
- *   3. `marginTop` / `marginRight` / `marginBottom` / `marginLeft`
+ *   3. `marginInlineStart` / `marginInlineEnd` /
+ *      `marginBlockStart` / `marginBlockEnd`  — logical side
+ *   4. `marginTop` / `marginRight` / `marginBottom` / `marginLeft`
+ *      — physical side
  *
  * Each rung only overrides the edge(s) it targets. See
  * `resolveSpacingValue` for the accepted value forms (the directionals
@@ -16,6 +19,9 @@
  * ⚠️ The 4-value `margin` 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 — see the same note on
+ * `IPaddingProps`. The physical spelling wins for a given edge.
  */
 export interface IMarginProps {
     /**
@@ -36,4 +42,32 @@ export interface IMarginProps {
     marginBlock?: boolean | number | string;
     /** Left + right. Overrides `margin`; beaten by `marginLeft` / `marginRight`. */
     marginInline?: boolean | number | string;
+    /*********************************************************
+     * Logical per-side margin — rung 3 (issue #1013)
+     *
+     * @description
+     * One WRITING-MODE-RELATIVE edge each, emitted as the native logical
+     * longhands (`margin-inline-start`, …) so the browser flips them under
+     * RTL and in vertical writing modes.
+     *
+     * @description
+     * `marginInlineStart` — left in LTR, **right in RTL**.
+     * `marginInlineEnd` — right in LTR, **left in RTL**.
+     * `marginBlockStart` — top in horizontal-tb.
+     * `marginBlockEnd` — bottom in horizontal-tb.
+     *
+     * @description
+     * Same vocabulary as `margin`, the `auto` keyword included — and that
+     * is their best argument: `marginInlineStart="auto"` pushes an element
+     * to the far end of its line in BOTH reading directions, where
+     * `marginLeft="auto"` pushes it the wrong way under RTL.
+     *
+     * @description
+     * Each overrides `margin` and its axis prop for the one edge it
+     * targets, and is beaten by the matching PHYSICAL prop.
+     ********************************************************/
+    marginInlineStart?: boolean | number | string;
+    marginInlineEnd?: boolean | number | string;
+    marginBlockStart?: boolean | number | string;
+    marginBlockEnd?: boolean | number | string;
 }