@ecoma-io/loom 0.5.0 → 0.6.0

package/README.md

@@ -1,3 +1,12 @@
+<!-- The README's structure is ten sections, in this order: what Loom is, install,
+     your first component, tokens and theming, the accessibility bar, evidence
+     tiers, templates, module boundaries, governance and contributing,
+     compatibility and requirements. A section exists because a consumer must
+     learn that thing to use Loom — prose that answers none of the ten questions
+     does not earn a section, however fond of it we are. The checklist, with the
+     referent each section must cite, lives in the governing issue
+     (ecoma-io/loom#338). -->
+
 <p align="center">
   <a href="https://github.com/ecoma-io/loom/actions/workflows/ci.yml"><img src="https://github.com/ecoma-io/loom/actions/workflows/ci.yml/badge.svg" alt="CI" /></a>
   <a href="https://github.com/ecoma-io/loom/actions/workflows/analysis.yml"><img src="https://img.shields.io/badge/analysis-semgrep-purple.svg" alt="Analysis" /></a>
@@ -10,25 +19,25 @@
 </p>
 
 <p align="center">
-  <img src=".github/assets/banner.png" alt="Loom — an opinionated UI system and composition library for cross-platform web applications" width="100%" />
+  <img src=".github/assets/banner.png" alt="Loom — an Application Interface System for Vue" width="100%" />
 </p>
 
 <h1 align="center">Loom</h1>
 
 <p align="center">
-  <strong>Opinionated UI system &amp; composition library for cross-platform web applications.</strong><br />
+  <strong>An Application Interface System for Vue.</strong><br />
   An open-source, accessibility-first component library and design-token system —
-  Vue&nbsp;3, TypeScript and Tailwind&nbsp;CSS — from mobile to ultrawide.<br />
-  <em>Build the interface once. Ship it everywhere. Never re-decide what a button is.</em>
+  Vue&nbsp;3, TypeScript and Tailwind&nbsp;CSS.<br />
+  <em>Build the interface once. Never re-decide what a button is.</em>
 </p>
 
 <p align="center">
-  <a href="https://loom.ecoma.io"><strong>Documentation&nbsp;→</strong></a>
+  <a href="https://ecoma.io/docs/contribute/design-system/"><strong>Documentation&nbsp;→</strong></a>
 </p>
 
 ---
 
-## Every product rewrites its buttons. That is the tax Loom exists to stop paying.
+## What Loom is
 
 A design system is not a folder of components. It is a decision, made once, that
 every screen inherits — how far apart two things sit, how a dialog gives focus
@@ -38,133 +47,211 @@ differently, every sprint, by whoever is closest to the deadline.
 
 **Loom is where that decision lives.** One vocabulary of design tokens, one set
 of accessible UI primitives, one motion language — consumed by every surface,
-owned by none of them. Open source under Apache-2.0, so you can take it into
-your own product on the same terms.
-
-## Built for cross-platform web applications
-
-Loom is designed for applications that run everywhere the web does: browsers,
-progressive web apps, Electron, and Tauri (desktop and mobile). A component
-library for products that need desktop window chrome, responsive layouts that
-stretch from phone to ultrawide, and an opinionated visual language that is
-ready to ship — not a skeleton to assemble.
-
-That premise demands more than a component dump. It demands:
-
-- **Responsive composition**, not just responsive CSS — layout primitives that
-  adapt to viewport and container, so a sidebar collapses at the right width
-  and a master-detail panel stacks on mobile without the host writing a
-  breakpoint.
-- **Desktop awareness** — title bars, window controls, safe-area insets. A
-  Tauri or Electron window has chrome a web page does not, and the components
-  that live in it need to know that.
-- **Content never stretches to infinity** — on an ultrawide monitor, readable
-  content is bounded and the extra viewport goes to intentional whitespace,
-  side panels, or supplementary content. Never to stretching.
-- **Same design language on every viewport** — a button is the same button at
-  320px and 3440px. The layout around it changes; the button does not.
-
-Loom originated within the [Ecoma](https://ecoma.io) ecosystem and is developed
-as an independent open-source UI system.
+owned by none of them.
 
-## What Loom gives you
+**Loom owns interface decisions, not application decisions.** What it standardises
+is the reusable layer — visual language, accessibility, interaction semantics,
+responsive behaviour, composition, patterns, templates. What requires knowing
+what your product _is_ belongs to your product. That split is the one rule that
+decides most questions about what belongs here.
 
 |                              |                                                                                                                                                                               |
 | ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | **Design tokens**            | Colour, spacing, radius, elevation, typography and motion — one source that light mode and dark mode both read from, so a rebrand is an edit rather than an audit.            |
 | **UI primitives**            | The generic controls every product needs and no product should own: buttons, inputs, selects, dialogs, menus, toasts, tooltips, skeletons, switches, progress.                |
 | **Composition primitives**   | Layout building blocks — Stack, Grid, Split, Center, Sidebar — that express spatial intent and adapt to viewport without the host writing breakpoint queries.                 |
-| **Blocks**                   | Compositions worth standardising once — empty states, page headers, title bars, sidebar navigation — assembled from primitives, never from scratch.                           |
+| **Patterns**                 | Compositions worth standardising once — empty states, page headers, title bars, sidebar navigation — assembled from primitives, never from scratch.                           |
 | **Showcase**                 | Demonstrations, in this documentation site, of what the parts produce when they compose — for discovery and teaching. A showcase is read; it is not a starting point to copy. |
-| **Templates**                | Copyable prebuilt pages — AI Chat, Dashboard, Music Player — to take into an application and build on. One page each; routing, auth and backend stay with the consumer.       |
+| **Templates**                | Copyable prebuilt pages — Starter, Analytics, Workspace settings — to take into an application and build on. One page each; routing, auth and backend stay with the consumer. |
 | **Accessibility, built in**  | Keyboard paths, focus restoration, accessible names and reduced-motion behaviour ship inside the component. WCAG is the acceptance bar, not a checklist run afterwards.       |
 | **Theming that survives**    | Every visual decision is a token reference, so white-labelling a tenant is configuration rather than a fork.                                                                  |
 | **Typed and tree-shakeable** | Ships ES modules with TypeScript types. Consumers bundle what they import and nothing more.                                                                                   |
 
-## Who this is for
+It is for teams building Vue applications who want the interface layer decided:
+design-system maintainers who want the token model, the artifact conventions and
+the accessibility bar readable in the open, and anyone tired of re-deciding what
+a button is — ship the defaults, override the tokens that don't fit, leave the
+rest alone. Loom originated within the [Ecoma](https://ecoma.io) ecosystem and is
+developed as an independent open-source UI system.
 
-- **Teams building cross-platform web applications** — especially those
-  targeting desktop (Electron, Tauri) alongside browser and mobile, where
-  existing component libraries assume a web page, not an application window.
-- **Design-system maintainers** — the token model, the artifact-per-primitive
-  convention and the accessibility bar are all readable in the open, Apache-2.0,
-  and free to borrow.
-- **Anyone tired of re-deciding what a button is** — Loom is opinionated so
-  you don't have to be. Ship the defaults, override the tokens that don't fit,
-  and leave the rest alone.
+## Install
 
-## Getting started
-
-Requirements: **Node ≥ 24** and **pnpm 11** (pinned in `package.json`, so
-Corepack fetches the right one for you).
+Loom ships as one npm package — the components, the theme composable and the
+stylesheet entry behind a single install:
 
 ```bash
-git clone https://github.com/ecoma-io/loom.git
-cd loom
-pnpm install
+pnpm add @ecoma-io/loom
 ```
 
-`pnpm install` also installs the Git hooks, so formatting, linting and commit
-message checks run before anything reaches a branch.
+One import is the whole styling surface a normal host needs — tokens, the
+self-hosted fonts, base element styling and the motion library ride along:
 
-```bash
-pnpm lint        # ESLint
-pnpm typecheck   # tsc --noEmit
-pnpm test        # Vitest
-pnpm e2e         # Playwright
-pnpm format      # Prettier, in place
+```css
+@import "@ecoma-io/loom/styles/global.css";
 ```
 
-The component surface is landing in the open, one primitive at a time —
-`packages/loom/src/index.ts` is always the complete export list. Follow along or ask for
-something specific in [the issues](https://github.com/ecoma-io/loom/issues).
+It needs Vue 3.5 or newer as a peer and Tailwind CSS 4 in your build; the
+[compatibility table](#compatibility-and-requirements) has the full list. The
+[documentation site](https://ecoma.io/docs/contribute/design-system/) walks an
+empty Vue application to a rendered, themed component.
 
-## Contributing
+## Your first component
 
-Loom holds what is **generic** — an affordance more than one product reaches for
-the same way. That single rule decides most questions about what belongs here,
-and [CONTRIBUTING.md](CONTRIBUTING.md) covers the rest: the commit format, the
-tiers of tests, and what a reviewer will look for.
+```vue
+<script setup lang="ts">
+import { Button } from "@ecoma-io/loom";
+</script>
 
-Everyone taking part is held to the [Code of Conduct](CODE_OF_CONDUCT.md).
-Security issues go through [SECURITY.md](SECURITY.md) — never a public issue.
-
-## Frequently asked
+<template>
+  <Button variant="primary" @click="save">Save</Button>
+</template>
+```
 
-**Can I use Loom outside Ecoma?**
-Yes. It is Apache-2.0, has no runtime dependency on any Ecoma platform, and is
-designed to be consumed as an ordinary npm package.
+Everything importable lives behind the one package: [packages/loom/src/index.ts](packages/loom/src/index.ts)
+is the complete export list, and says so in its own docblock. The generic controls
+sit beside composition primitives that adapt to viewport and container — a
+sidebar collapses at the right width, a master-detail panel stacks on mobile,
+and on an ultrawide monitor content is bounded at readable widths, the extra
+viewport going to intentional whitespace rather than stretching.
+
+A `class` you pass merges with the component's own instead of replacing it —
+`cn` ships from the same package and is Tailwind-aware, so your `px-4` resolves
+against the component's `px-6` rather than both shipping and stylesheet order
+deciding the winner.
+
+Each component's page on the documentation site carries an API table generated
+from the component's own `defineProps`, so the documented surface cannot drift
+from the shipped one.
+
+## Tokens and theming
+
+Every visual decision is a token reference, and the tokens have one home:
+[packages/theme-core/src/theme.css](packages/theme-core/src/theme.css) is the
+source of truth. Light mode and dark mode both derive from that one set — dark
+is not a second theme anyone maintains, which is why the two cannot drift apart.
+A `useTheme` composable switches between light, dark and system preference.
+
+Because a token is a CSS custom property rather than a Tailwind class, the token
+layer is framework-neutral and usable anywhere; the components that consume it
+are Vue. Rebranding is editing tokens; white-labelling a tenant is configuration,
+not a fork.
+
+## The accessibility bar
+
+Accessibility ships inside the component, not as a follow-up: keyboard operation
+with visible focus, focus restored to the trigger when an overlay closes,
+accessible names, no state conveyed by colour alone, and a
+`prefers-reduced-motion` path through the motion library.
+
+The bar is defined, not aspirational. `WCAG_TAGS` in
+[packages/core/src/a11y-scope.ts](packages/core/src/a11y-scope.ts) is the closed
+rule set the library holds itself to — the axe rules mapping to a WCAG Level A
+or AA success criterion — and the browser gate that enforces it carries no
+excludes. Every component also declares an `a11y.json` claim beside its source,
+held by a gate against the role → requirement matrix in
+[packages/core/src/a11y-contract.ts](packages/core/src/a11y-contract.ts), so a
+requirement nothing answers yet is recorded as a named exception rather than
+silently missing. An accessibility bug is a bug, and it is filed and fixed as one.
+
+## Evidence tiers
+
+The claims above are pinned at three runtimes — the same three the
+accessibility contract names (`browserless`, `harness`, `sweep`):
+
+- **browserless** — the jsdom sweep mounts every demo and holds it to its
+  component's accessibility claim, no browser required.
+- **harness** — a Vite dev server mounts one demo at a time, so a component's
+  browser specs run in seconds without paying for a site build.
+- **sweep** — the site-wide suite over the built documentation site: axe,
+  contrast, target size, keyboard, focus-not-obscured, motion, responsive.
+
+Beside them, unit and integration tests live next to each component's source and
+the browser tier lives apart; [CONTRIBUTING.md](CONTRIBUTING.md) holds the
+contract for all of it. The documentation is held to the same honesty: token
+tables are generated from `theme.css` and API tables from the components
+themselves — generated, never transcribed, so a page cannot quietly disagree
+with the code it describes.
+
+## Templates
+
+An Official Template is a copyable prebuilt **page** — a starting point composed
+from Loom components and patterns, taken into an application and built on:
+Starter, Analytics, Workspace settings. Where a pattern is a component you
+compose with and the showcase is a demonstration you read, a template is a page
+you start from. Routing, auth and backend stay with the consumer.
+
+Templates consume the public `@ecoma-io/loom` package exactly as an external
+consumer would — no internal imports, nothing the published package does not
+have — because if a template cannot build against the published surface, that is
+a defect in the surface. [docs/templates/contract.md](docs/templates/contract.md)
+states the artifact kind's law, and the template suite holds every template to
+smoke, axe in light and dark, keyboard and responsive gates.
+
+## Module boundaries
+
+Loom is layered, and the direction is one way: core → labels → primitives →
+composition → patterns → layouts → facade. The facade — the `@ecoma-io/loom`
+package you install — is the only import surface: its exports map offers the
+components, the `./a11y` and `./theme` entries, and the stylesheet files, and
+nothing inside the monorepo is public API.
+
+The boundary is enforced twice, by two readers that see different things:
+[tools/check-architecture.ts](tools/check-architecture.ts) matches the import
+specifier text, and [archkeep](https://github.com/ecoma-io/archkeep) resolves
+each specifier through the TypeScript config and judges the resolved target
+against [module-boundaries.config.mjs](module-boundaries.config.mjs). The
+[architecture contract](docs/architecture/contract.md) records which invariant
+each reader owns.
+
+## Governance and contributing
+
+What Loom takes is decided by the one rule: Loom holds what is **generic** — an
+affordance more than one product reaches for the same way. Everything else about
+working here is the contract, and the contract is
+[CONTRIBUTING.md](CONTRIBUTING.md): the commit format, the test tiers, the
+Semgrep rules, the accessibility bar, and how a pull request lands.
+
+To work on Loom itself:
 
-**Why Apache-2.0 and not MIT?**
-Apache-2.0 carries an explicit patent grant. For a component library that ends
-up embedded in commercial products, that is the difference between "probably
-fine" and "written down".
+```bash
+git clone https://github.com/ecoma-io/loom.git
+cd loom
+pnpm install
+```
 
-**Which framework does it target?**
-Vue 3 with TypeScript, styled through Tailwind CSS. The design tokens themselves
-are framework-neutral CSS custom properties, so they are usable anywhere.
+`pnpm install` also installs the Git hooks, so formatting, linting and commit
+message checks run before anything reaches a branch. The component surface is
+landing in the open, one artifact at a time — follow along or ask for something
+specific in [the issues](https://github.com/ecoma-io/loom/issues).
 
-**Does it support dark mode?**
-Dark is derived from the same token set as light rather than maintained as a
-second theme, which is why the two cannot drift apart. A `useTheme` composable
-switches between light, dark, and system preference.
+Everyone taking part is held to the [Code of Conduct](CODE_OF_CONDUCT.md).
+Security issues go through [SECURITY.md](SECURITY.md) — never a public issue.
 
-**How is accessibility verified?**
-Keyboard operation, focus restoration and accessible naming are pinned by tests
-and reviewed on every pull request — see the accessibility section of
-[CONTRIBUTING.md](CONTRIBUTING.md).
+Loom is [Apache-2.0](LICENSE) — an explicit patent grant, which for a component
+library that ends up embedded in commercial products is the difference between
+"probably fine" and "written down" — with no runtime dependency on any Ecoma
+platform, so consuming it as an ordinary npm package includes consuming it
+outside Ecoma. Use it, ship it, fork it, sell what you build with it.
 
-**What about responsive layouts?**
-Loom provides composition primitives (Stack, Grid, Split, Center, Sidebar) that
-express layout intent and adapt to viewport width. Content is bounded at
-readable widths on ultrawide screens — extra viewport goes to whitespace, not
-stretching.
+## Compatibility and requirements
 
-## License
+| Requirement  | Version                                        |
+| ------------ | ---------------------------------------------- |
+| Node         | ≥ 24 (`engines` in `package.json`)             |
+| pnpm         | 11 — pinned, so Corepack fetches the right one |
+| Vue          | ≥ 3.5, as a peer dependency                    |
+| Tailwind CSS | 4, in your build (`@tailwindcss/vite`)         |
 
-[Apache License 2.0](LICENSE) © Ecoma.
+Types ship strict, and the package ships ES modules that tree-shake: consumers
+bundle what they import and nothing more.
 
-Use it, ship it, fork it, sell what you build with it.
+Cross-platform is a design constraint, not the product category. Loom's
+interface decisions are made so they can survive a change of rendering target —
+a browser tab, an installed PWA, an Electron or Tauri desktop shell, a mobile
+webview — and the platform-specific parts stay at the boundary, passed in by the
+host rather than sniffed at runtime: window chrome, safe-area insets, PWA
+overlays. Loom today is a Vue-facing interface system, not a cross-platform
+framework.
 
 ---
 
@@ -172,7 +259,7 @@ Use it, ship it, fork it, sell what you build with it.
   <img src=".github/assets/logo.png" alt="" width="56" /><br />
   <sub>
     An <a href="https://ecoma.io">Ecoma</a> open-source project ·
-    <a href="https://loom.ecoma.io">Documentation</a> ·
+    <a href="https://ecoma.io/docs/contribute/design-system/">Documentation</a> ·
     <a href="https://github.com/ecoma-io">Organisation</a> ·
     <a href="CONTRIBUTING.md">Contribute</a>
   </sub>

package/dist/a11y.js

@@ -1,3 +1,4 @@
-import { BROWSERLESS_RULES, BROWSER_REQUIRED_RULES, WCAG_TAGS } from "./packages/core/src/a11y-scope.js";
-import "./packages/core/src/index.js";
-export { BROWSERLESS_RULES, BROWSER_REQUIRED_RULES, WCAG_TAGS };
+import { BROWSERLESS_RULES, BROWSER_REQUIRED_RULES, WCAG_TAGS } from "./core/src/a11y-scope.js";
+import { A11Y_EVIDENCE_MATRIX, A11Y_EVIDENCE_REQUIREMENTS, A11Y_EVIDENCE_TIERS, A11Y_ROLES, ARIA_ROLES, NON_ROLE_MEMBERS } from "./core/src/a11y-contract.js";
+import "./core/src/index.js";
+export { A11Y_EVIDENCE_MATRIX, A11Y_EVIDENCE_REQUIREMENTS, A11Y_EVIDENCE_TIERS, A11Y_ROLES, ARIA_ROLES, BROWSERLESS_RULES, BROWSER_REQUIRED_RULES, NON_ROLE_MEMBERS, WCAG_TAGS };

package/dist/composition/center/src/Center.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"Center.js","names":[],"sources":["../../../../packages/composition/center/src/Center.vue"],"sourcesContent":["<script lang=\"ts\">\n/**\n * Center — centered content with a max-width constraint.\n *\n * A horizontally centered block that caps its own width and widens its\n * gutters at wider breakpoints. Critical for ultra-wide viewports, where\n * content that stretches to infinity is unreadable: the extra viewport goes\n * to intentional whitespace, never to stretching lines of text or card grids.\n *\n * A Center is a component, not `mx-auto max-w-3xl px-4`, because the\n * gutters step up at breakpoints (the component's job, not every call\n * site's) and the `maxWidth` prop names readable intent rather than a\n * Tailwind size.\n */\nexport type CenterMaxWidth = \"sm\" | \"md\" | \"lg\" | \"xl\" | \"prose\";\n\nconst maxWidthClass: Record<CenterMaxWidth, string> = {\n  sm: \"max-w-sm\",\n  md: \"max-w-md\",\n  lg: \"max-w-lg\",\n  xl: \"max-w-xl\",\n  prose: \"max-w-prose\",\n} as const;\n\nexport { maxWidthClass };\n</script>\n\n<script setup lang=\"ts\">\nimport { cn } from \"@ecoma-io/loom-core\";\n\nwithDefaults(\n  defineProps<{\n    /** Maximum content width — names intent rather than a pixel value. */\n    maxWidth?: CenterMaxWidth;\n    /** Whether to add horizontal gutters that widen at wider breakpoints. */\n    gutter?: boolean;\n  }>(),\n  { maxWidth: \"lg\", gutter: true },\n);\n</script>\n\n<template>\n  <!--\n    Gutters step up at `sm` and `3xl`: narrow viewports need less margin\n    because the viewport itself is margin, and ultra-wide viewports need more\n    so the gap between content and screen edge stays proportional.\n  -->\n  <div\n    :class=\"cn(maxWidthClass[maxWidth], 'mx-auto', gutter ? 'px-4 sm:px-6 3xl:px-8' : undefined)\"\n  >\n    <slot />\n  </div>\n</template>\n"],"mappings":""}

package/dist/composition/center/src/Center.vue_vue_type_script_setup_true_lang.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"Center.vue_vue_type_script_setup_true_lang.js","names":[],"sources":["../../../../packages/composition/center/src/Center.vue"],"sourcesContent":["<script lang=\"ts\">\n/**\n * Center — centered content with a max-width constraint.\n *\n * A horizontally centered block that caps its own width and widens its\n * gutters at wider breakpoints. Critical for ultra-wide viewports, where\n * content that stretches to infinity is unreadable: the extra viewport goes\n * to intentional whitespace, never to stretching lines of text or card grids.\n *\n * A Center is a component, not `mx-auto max-w-3xl px-4`, because the\n * gutters step up at breakpoints (the component's job, not every call\n * site's) and the `maxWidth` prop names readable intent rather than a\n * Tailwind size.\n */\nexport type CenterMaxWidth = \"sm\" | \"md\" | \"lg\" | \"xl\" | \"prose\";\n\nconst maxWidthClass: Record<CenterMaxWidth, string> = {\n  sm: \"max-w-sm\",\n  md: \"max-w-md\",\n  lg: \"max-w-lg\",\n  xl: \"max-w-xl\",\n  prose: \"max-w-prose\",\n} as const;\n\nexport { maxWidthClass };\n</script>\n\n<script setup lang=\"ts\">\nimport { cn } from \"@ecoma-io/loom-core\";\n\nwithDefaults(\n  defineProps<{\n    /** Maximum content width — names intent rather than a pixel value. */\n    maxWidth?: CenterMaxWidth;\n    /** Whether to add horizontal gutters that widen at wider breakpoints. */\n    gutter?: boolean;\n  }>(),\n  { maxWidth: \"lg\", gutter: true },\n);\n</script>\n\n<template>\n  <!--\n    Gutters step up at `sm` and `3xl`: narrow viewports need less margin\n    because the viewport itself is margin, and ultra-wide viewports need more\n    so the gap between content and screen edge stays proportional.\n  -->\n  <div\n    :class=\"cn(maxWidthClass[maxWidth], 'mx-auto', gutter ? 'px-4 sm:px-6 3xl:px-8' : undefined)\"\n  >\n    <slot />\n  </div>\n</template>\n"],"mappings":";;;;AAgBA,IAAM,gBAAgD;CACpD,IAAI;CACJ,IAAI;CACJ,IAAI;CACJ,IAAI;CACJ,OAAO;AACT;;;;;;;;;;;;GAyBE,OAAA,UAAA,GAAA,mBAIM,OAAA,EAHH,OAAK,eAAE,MAAA,EAAA,CAAE,CAAC,cAAc,QAAA,WAAQ,WAAc,QAAA,SAAM,0BAA6B,KAAA,CAAS,CAAA,EAAA,GAAA,CAE3F,WAAQ,KAAA,QAAA,SAAA,CAAA,GAAA,CAAA"}

package/dist/composition/dashboard-grid/src/DashboardGrid.js

@@ -0,0 +1,7 @@
+import DashboardGrid_vue_vue_type_script_setup_true_lang_default from "./DashboardGrid.vue_vue_type_script_setup_true_lang.js";
+//#region packages/composition/dashboard-grid/src/DashboardGrid.vue
+var DashboardGrid_default = DashboardGrid_vue_vue_type_script_setup_true_lang_default;
+//#endregion
+export { DashboardGrid_default as default };
+
+//# sourceMappingURL=DashboardGrid.js.map

package/dist/composition/dashboard-grid/src/DashboardGrid.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"DashboardGrid.js","names":[],"sources":["../../../../packages/composition/dashboard-grid/src/DashboardGrid.vue"],"sourcesContent":["<script lang=\"ts\">\n/** The gutter step — the same scale Stack's gap steps mirror. */\nexport type DashboardGridGap = \"sm\" | \"md\" | \"lg\";\n</script>\n\n<script setup lang=\"ts\">\n/**\n * DashboardGrid — the reflowing tile grid a dashboard's panels sit in: a CSS\n * grid that fits as many `minTileWidth`-wide tracks as the container allows,\n * so a KPI row and a couple of wider panels share one layout without the\n * host authoring a single breakpoint.\n *\n * `auto-fit` + `minmax` (never fixed `grid-cols-N` breakpoints) is the\n * deliberate choice: a fixed column count needs one breakpoint per host\n * viewport, while auto-fit recomputes the column count from the container's\n * own width — it reflows identically inside a sidebar-narrowed workspace and\n * full-bleed on an ultra-wide monitor, with zero Tailwind breakpoints\n * authored here or at the call site. The `minmax` lower bound is wrapped in\n * `min(100%, …)` so a tile never forces horizontal overflow on a container\n * narrower than `minTileWidth` itself.\n *\n * Presentational only: panels arrive through the default slot, and a panel\n * spans multiple tracks with its own `col-span-*` utility at the call\n * site — the grid does not know or count how many panels it holds.\n */\nwithDefaults(\n  defineProps<{\n    /** Narrowest a tile may get before the grid drops to fewer columns. Any valid CSS length (e.g. \"14rem\"). */\n    minTileWidth?: string;\n    /** Row/column gap step — mirrors Surface's `pad` scale at `sm` and up (sm 12px · md 16px · lg 24px); each step drops one notch below `sm`. */\n    gap?: \"sm\" | \"md\" | \"lg\";\n  }>(),\n  { minTileWidth: \"16rem\", gap: \"md\" },\n);\n\n// One notch tighter below the `sm` breakpoint. A gutter is spent viewport, and\n// on a phone the grid is already single-column — 24px of air between stacked\n// tiles buys no separation the tile borders do not already give, it just\n// pushes the second tile off screen. From `sm` up each step is its\n// documented value.\nconst gapClass: Record<DashboardGridGap, string> = {\n  sm: \"gap-2 sm:gap-3\",\n  md: \"gap-3 sm:gap-4\",\n  lg: \"gap-4 sm:gap-6\",\n} as const;\n</script>\n\n<template>\n  <div\n    class=\"grid\"\n    :class=\"gapClass[gap]\"\n    :style=\"{ gridTemplateColumns: `repeat(auto-fit, minmax(min(100%, ${minTileWidth}), 1fr))` }\"\n  >\n    <slot />\n  </div>\n</template>\n"],"mappings":""}

package/dist/composition/dashboard-grid/src/DashboardGrid.vue_vue_type_script_setup_true_lang.js

@@ -0,0 +1,45 @@
+import { createElementBlock, defineComponent, normalizeClass, normalizeStyle, openBlock, renderSlot } from "vue";
+//#region packages/composition/dashboard-grid/src/DashboardGrid.vue?vue&type=script&setup=true&lang.ts
+var DashboardGrid_vue_vue_type_script_setup_true_lang_default = /*@__PURE__*/ defineComponent({
+	__name: "DashboardGrid",
+	props: {
+		minTileWidth: { default: "16rem" },
+		gap: { default: "md" }
+	},
+	setup(__props) {
+		/**
+		* DashboardGrid — the reflowing tile grid a dashboard's panels sit in: a CSS
+		* grid that fits as many `minTileWidth`-wide tracks as the container allows,
+		* so a KPI row and a couple of wider panels share one layout without the
+		* host authoring a single breakpoint.
+		*
+		* `auto-fit` + `minmax` (never fixed `grid-cols-N` breakpoints) is the
+		* deliberate choice: a fixed column count needs one breakpoint per host
+		* viewport, while auto-fit recomputes the column count from the container's
+		* own width — it reflows identically inside a sidebar-narrowed workspace and
+		* full-bleed on an ultra-wide monitor, with zero Tailwind breakpoints
+		* authored here or at the call site. The `minmax` lower bound is wrapped in
+		* `min(100%, …)` so a tile never forces horizontal overflow on a container
+		* narrower than `minTileWidth` itself.
+		*
+		* Presentational only: panels arrive through the default slot, and a panel
+		* spans multiple tracks with its own `col-span-*` utility at the call
+		* site — the grid does not know or count how many panels it holds.
+		*/
+		const gapClass = {
+			sm: "gap-2 sm:gap-3",
+			md: "gap-3 sm:gap-4",
+			lg: "gap-4 sm:gap-6"
+		};
+		return (_ctx, _cache) => {
+			return openBlock(), createElementBlock("div", {
+				class: normalizeClass(["grid", gapClass[__props.gap]]),
+				style: normalizeStyle({ gridTemplateColumns: `repeat(auto-fit, minmax(min(100%, ${__props.minTileWidth}), 1fr))` })
+			}, [renderSlot(_ctx.$slots, "default")], 6);
+		};
+	}
+});
+//#endregion
+export { DashboardGrid_vue_vue_type_script_setup_true_lang_default as default };
+
+//# sourceMappingURL=DashboardGrid.vue_vue_type_script_setup_true_lang.js.map

package/dist/composition/dashboard-grid/src/DashboardGrid.vue_vue_type_script_setup_true_lang.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"DashboardGrid.vue_vue_type_script_setup_true_lang.js","names":[],"sources":["../../../../packages/composition/dashboard-grid/src/DashboardGrid.vue"],"sourcesContent":["<script lang=\"ts\">\n/** The gutter step — the same scale Stack's gap steps mirror. */\nexport type DashboardGridGap = \"sm\" | \"md\" | \"lg\";\n</script>\n\n<script setup lang=\"ts\">\n/**\n * DashboardGrid — the reflowing tile grid a dashboard's panels sit in: a CSS\n * grid that fits as many `minTileWidth`-wide tracks as the container allows,\n * so a KPI row and a couple of wider panels share one layout without the\n * host authoring a single breakpoint.\n *\n * `auto-fit` + `minmax` (never fixed `grid-cols-N` breakpoints) is the\n * deliberate choice: a fixed column count needs one breakpoint per host\n * viewport, while auto-fit recomputes the column count from the container's\n * own width — it reflows identically inside a sidebar-narrowed workspace and\n * full-bleed on an ultra-wide monitor, with zero Tailwind breakpoints\n * authored here or at the call site. The `minmax` lower bound is wrapped in\n * `min(100%, …)` so a tile never forces horizontal overflow on a container\n * narrower than `minTileWidth` itself.\n *\n * Presentational only: panels arrive through the default slot, and a panel\n * spans multiple tracks with its own `col-span-*` utility at the call\n * site — the grid does not know or count how many panels it holds.\n */\nwithDefaults(\n  defineProps<{\n    /** Narrowest a tile may get before the grid drops to fewer columns. Any valid CSS length (e.g. \"14rem\"). */\n    minTileWidth?: string;\n    /** Row/column gap step — mirrors Surface's `pad` scale at `sm` and up (sm 12px · md 16px · lg 24px); each step drops one notch below `sm`. */\n    gap?: \"sm\" | \"md\" | \"lg\";\n  }>(),\n  { minTileWidth: \"16rem\", gap: \"md\" },\n);\n\n// One notch tighter below the `sm` breakpoint. A gutter is spent viewport, and\n// on a phone the grid is already single-column — 24px of air between stacked\n// tiles buys no separation the tile borders do not already give, it just\n// pushes the second tile off screen. From `sm` up each step is its\n// documented value.\nconst gapClass: Record<DashboardGridGap, string> = {\n  sm: \"gap-2 sm:gap-3\",\n  md: \"gap-3 sm:gap-4\",\n  lg: \"gap-4 sm:gap-6\",\n} as const;\n</script>\n\n<template>\n  <div\n    class=\"grid\"\n    :class=\"gapClass[gap]\"\n    :style=\"{ gridTemplateColumns: `repeat(auto-fit, minmax(min(100%, ${minTileWidth}), 1fr))` }\"\n  >\n    <slot />\n  </div>\n</template>\n"],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;EAwCA,MAAM,WAA6C;GACjD,IAAI;GACJ,IAAI;GACJ,IAAI;EACN;;GAIE,OAAA,UAAA,GAAA,mBAMM,OAAA;IALJ,OAAK,eAAA,CAAC,QACE,SAAS,QAAA,IAAG,CAAA;IACnB,OAAK,eAAA,EAAA,qBAAA,qCAA8D,QAAA,aAAY,UAAA,CAAA;GAEhF,GAAA,CAAA,WAAQ,KAAA,QAAA,SAAA,CAAA,GAAA,CAAA"}

package/dist/composition/frame/src/Frame.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"Frame.js","names":[],"sources":["../../../../packages/composition/frame/src/Frame.vue"],"sourcesContent":["<script lang=\"ts\">\n/**\n * Frame — fixed-ratio container.\n *\n * A container that maintains a consistent aspect ratio regardless of its\n * width, using CSS `aspect-ratio`. Useful for media embeds, image thumbnails,\n * and any content that needs a fixed ratio (video players, avatar crops,\n * card illustrations).\n *\n * A Frame is a component, not `aspect-video`, because the `ratio` prop\n * names the intent (\"16:9\", \"1:1\") rather than requiring the caller to\n * compute the `aspect-ratio` value, and the component handles the\n * `overflow: hidden` that prevents content from distorting the frame.\n */\nexport type FrameRatio = \"16:9\" | \"4:3\" | \"1:1\" | \"3:4\";\n\nconst aspectRatioValue: Record<FrameRatio, string> = {\n  \"16:9\": \"16 / 9\",\n  \"4:3\": \"4 / 3\",\n  \"1:1\": \"1 / 1\",\n  \"3:4\": \"3 / 4\",\n} as const;\n\nexport { aspectRatioValue };\n</script>\n\n<script setup lang=\"ts\">\nimport { cn } from \"@ecoma-io/loom-core\";\n\nwithDefaults(\n  defineProps<{\n    /** The aspect ratio to maintain. Named ratios or any valid CSS `aspect-ratio` value (e.g. \"21 / 9\"). */\n    ratio?: FrameRatio | string;\n  }>(),\n  { ratio: \"16:9\" },\n);\n\n/** Resolve a named ratio or pass through a raw CSS value. */\nfunction resolveRatio(r: FrameRatio | string): string {\n  return r in aspectRatioValue ? aspectRatioValue[r as FrameRatio] : r;\n}\n</script>\n\n<template>\n  <div :class=\"cn('relative overflow-hidden w-full')\" :style=\"{ aspectRatio: resolveRatio(ratio) }\">\n    <slot />\n  </div>\n</template>\n"],"mappings":""}

package/dist/composition/frame/src/Frame.vue_vue_type_script_setup_true_lang.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"Frame.vue_vue_type_script_setup_true_lang.js","names":[],"sources":["../../../../packages/composition/frame/src/Frame.vue"],"sourcesContent":["<script lang=\"ts\">\n/**\n * Frame — fixed-ratio container.\n *\n * A container that maintains a consistent aspect ratio regardless of its\n * width, using CSS `aspect-ratio`. Useful for media embeds, image thumbnails,\n * and any content that needs a fixed ratio (video players, avatar crops,\n * card illustrations).\n *\n * A Frame is a component, not `aspect-video`, because the `ratio` prop\n * names the intent (\"16:9\", \"1:1\") rather than requiring the caller to\n * compute the `aspect-ratio` value, and the component handles the\n * `overflow: hidden` that prevents content from distorting the frame.\n */\nexport type FrameRatio = \"16:9\" | \"4:3\" | \"1:1\" | \"3:4\";\n\nconst aspectRatioValue: Record<FrameRatio, string> = {\n  \"16:9\": \"16 / 9\",\n  \"4:3\": \"4 / 3\",\n  \"1:1\": \"1 / 1\",\n  \"3:4\": \"3 / 4\",\n} as const;\n\nexport { aspectRatioValue };\n</script>\n\n<script setup lang=\"ts\">\nimport { cn } from \"@ecoma-io/loom-core\";\n\nwithDefaults(\n  defineProps<{\n    /** The aspect ratio to maintain. Named ratios or any valid CSS `aspect-ratio` value (e.g. \"21 / 9\"). */\n    ratio?: FrameRatio | string;\n  }>(),\n  { ratio: \"16:9\" },\n);\n\n/** Resolve a named ratio or pass through a raw CSS value. */\nfunction resolveRatio(r: FrameRatio | string): string {\n  return r in aspectRatioValue ? aspectRatioValue[r as FrameRatio] : r;\n}\n</script>\n\n<template>\n  <div :class=\"cn('relative overflow-hidden w-full')\" :style=\"{ aspectRatio: resolveRatio(ratio) }\">\n    <slot />\n  </div>\n</template>\n"],"mappings":";;;;AAgBA,IAAM,mBAA+C;CACnD,QAAQ;CACR,OAAO;CACP,OAAO;CACP,OAAO;AACT;;;;;;EAiBA,SAAS,aAAa,GAAgC;GACpD,OAAO,KAAK,mBAAmB,iBAAiB,KAAmB;EACrE;;GAIE,OAAA,UAAA,GAAA,mBAEM,OAAA;IAFA,OAAK,eAAE,MAAA,EAAA,CAAE,CAAA,iCAAA,CAAA;IAAsC,OAAK,eAAA,EAAA,aAAiB,aAAa,QAAA,KAAK,EAAA,CAAA;GAC3F,GAAA,CAAA,WAAQ,KAAA,QAAA,SAAA,CAAA,GAAA,CAAA"}

package/dist/composition/grid/src/Grid.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"Grid.js","names":[],"sources":["../../../../packages/composition/grid/src/Grid.vue"],"sourcesContent":["<script lang=\"ts\">\n/**\n * Grid — CSS Grid with responsive column count.\n *\n * A grid that derives its column count from the container's own width\n * (`auto-fit` + `minmax`, never fixed `grid-cols-N` breakpoints), so the same\n * grid reflows inside a sidebar-narrowed workspace and full-bleed on an\n * ultra-wide monitor alike.\n *\n * A Grid is a component, not `grid grid-cols-3 gap-4`, because the responsive\n * column count is the component's job (a fixed count needs one breakpoint per\n * viewport and is already wrong the moment the grid sits in a sidebar narrower\n * than the viewport), and the gap tightens one step below `sm` like Stack and\n * DashboardGrid.\n */\nexport type GridGap = \"sm\" | \"md\" | \"lg\";\n\nconst gapClass: Record<GridGap, string> = {\n  sm: \"gap-2 sm:gap-3\",\n  md: \"gap-3 sm:gap-4\",\n  lg: \"gap-4 sm:gap-6\",\n} as const;\n\nexport { gapClass };\n</script>\n\n<script setup lang=\"ts\">\nimport { cn } from \"@ecoma-io/loom-core\";\n\nwithDefaults(\n  defineProps<{\n    /** Narrowest a column may get before the grid drops to fewer columns. Any valid CSS length (e.g. \"14rem\"). */\n    minColWidth?: string;\n    /** Column/row gap step — mirrors Stack's scale. Tightens one notch below `sm`. */\n    gap?: GridGap;\n  }>(),\n  { minColWidth: \"16rem\", gap: \"md\" },\n);\n</script>\n\n<template>\n  <div\n    class=\"grid\"\n    :class=\"cn(gapClass[gap])\"\n    :style=\"{ gridTemplateColumns: `repeat(auto-fit, minmax(min(100%, ${minColWidth}), 1fr))` }\"\n  >\n    <slot />\n  </div>\n</template>\n"],"mappings":""}

package/dist/composition/grid/src/Grid.vue_vue_type_script_setup_true_lang.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"Grid.vue_vue_type_script_setup_true_lang.js","names":[],"sources":["../../../../packages/composition/grid/src/Grid.vue"],"sourcesContent":["<script lang=\"ts\">\n/**\n * Grid — CSS Grid with responsive column count.\n *\n * A grid that derives its column count from the container's own width\n * (`auto-fit` + `minmax`, never fixed `grid-cols-N` breakpoints), so the same\n * grid reflows inside a sidebar-narrowed workspace and full-bleed on an\n * ultra-wide monitor alike.\n *\n * A Grid is a component, not `grid grid-cols-3 gap-4`, because the responsive\n * column count is the component's job (a fixed count needs one breakpoint per\n * viewport and is already wrong the moment the grid sits in a sidebar narrower\n * than the viewport), and the gap tightens one step below `sm` like Stack and\n * DashboardGrid.\n */\nexport type GridGap = \"sm\" | \"md\" | \"lg\";\n\nconst gapClass: Record<GridGap, string> = {\n  sm: \"gap-2 sm:gap-3\",\n  md: \"gap-3 sm:gap-4\",\n  lg: \"gap-4 sm:gap-6\",\n} as const;\n\nexport { gapClass };\n</script>\n\n<script setup lang=\"ts\">\nimport { cn } from \"@ecoma-io/loom-core\";\n\nwithDefaults(\n  defineProps<{\n    /** Narrowest a column may get before the grid drops to fewer columns. Any valid CSS length (e.g. \"14rem\"). */\n    minColWidth?: string;\n    /** Column/row gap step — mirrors Stack's scale. Tightens one notch below `sm`. */\n    gap?: GridGap;\n  }>(),\n  { minColWidth: \"16rem\", gap: \"md\" },\n);\n</script>\n\n<template>\n  <div\n    class=\"grid\"\n    :class=\"cn(gapClass[gap])\"\n    :style=\"{ gridTemplateColumns: `repeat(auto-fit, minmax(min(100%, ${minColWidth}), 1fr))` }\"\n  >\n    <slot />\n  </div>\n</template>\n"],"mappings":";;;;AAiBA,IAAM,WAAoC;CACxC,IAAI;CACJ,IAAI;CACJ,IAAI;AACN;;;;;;;;;GAoBE,OAAA,UAAA,GAAA,mBAMM,OAAA;IALJ,OAAK,eAAA,CAAC,QACE,MAAA,EAAA,CAAE,CAAC,SAAS,QAAA,IAAG,CAAA,CAAA;IACtB,OAAK,eAAA,EAAA,qBAAA,qCAA8D,QAAA,YAAW,UAAA,CAAA;GAE/E,GAAA,CAAA,WAAQ,KAAA,QAAA,SAAA,CAAA,GAAA,CAAA"}

package/dist/composition/inline/src/Inline.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"Inline.js","names":[],"sources":["../../../../packages/composition/inline/src/Inline.vue"],"sourcesContent":["<script lang=\"ts\">\n/**\n * Inline — horizontal flow with wrap, consistent gap.\n *\n * A flex row that wraps naturally at the container edge and tightens its gutter\n * one step below the `sm` breakpoint. The gap steps mirror Stack's and\n * DashboardGrid's: the value each step names applies from `sm` up, and drops\n * one notch below it.\n *\n * An Inline is a component, not `flex flex-row flex-wrap gap-4`, because the\n * responsive gap is the component's job, the `align` prop maps cross-axis\n * intent to a class, and the `wrap` prop controls line-wrapping behaviour.\n */\nexport type InlineGap = \"sm\" | \"md\" | \"lg\";\n\nexport type InlineAlign = \"start\" | \"center\" | \"end\" | \"stretch\" | \"baseline\";\n\nconst gapClass: Record<InlineGap, string> = {\n  sm: \"gap-2 sm:gap-3\",\n  md: \"gap-3 sm:gap-4\",\n  lg: \"gap-4 sm:gap-6\",\n} as const;\n\nconst alignClass: Record<InlineAlign, string> = {\n  start: \"items-start\",\n  center: \"items-center\",\n  end: \"items-end\",\n  stretch: \"items-stretch\",\n  baseline: \"items-baseline\",\n} as const;\n\nexport { gapClass, alignClass };\n</script>\n\n<script setup lang=\"ts\">\nimport { cn } from \"@ecoma-io/loom-core\";\n\nwithDefaults(\n  defineProps<{\n    /** Horizontal gap step — mirrors Stack's scale. Tightens one notch below `sm`. */\n    gap?: InlineGap;\n    /** Cross-axis alignment of children. */\n    align?: InlineAlign;\n    /** Whether items wrap to new lines when they exceed the container width. */\n    wrap?: boolean;\n  }>(),\n  { gap: \"md\", align: \"stretch\", wrap: true },\n);\n</script>\n\n<template>\n  <div\n    :class=\"\n      cn('flex flex-row', gapClass[gap], alignClass[align], wrap ? 'flex-wrap' : 'flex-nowrap')\n    \"\n  >\n    <slot />\n  </div>\n</template>\n"],"mappings":""}

package/dist/composition/inline/src/Inline.vue_vue_type_script_setup_true_lang.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"Inline.vue_vue_type_script_setup_true_lang.js","names":[],"sources":["../../../../packages/composition/inline/src/Inline.vue"],"sourcesContent":["<script lang=\"ts\">\n/**\n * Inline — horizontal flow with wrap, consistent gap.\n *\n * A flex row that wraps naturally at the container edge and tightens its gutter\n * one step below the `sm` breakpoint. The gap steps mirror Stack's and\n * DashboardGrid's: the value each step names applies from `sm` up, and drops\n * one notch below it.\n *\n * An Inline is a component, not `flex flex-row flex-wrap gap-4`, because the\n * responsive gap is the component's job, the `align` prop maps cross-axis\n * intent to a class, and the `wrap` prop controls line-wrapping behaviour.\n */\nexport type InlineGap = \"sm\" | \"md\" | \"lg\";\n\nexport type InlineAlign = \"start\" | \"center\" | \"end\" | \"stretch\" | \"baseline\";\n\nconst gapClass: Record<InlineGap, string> = {\n  sm: \"gap-2 sm:gap-3\",\n  md: \"gap-3 sm:gap-4\",\n  lg: \"gap-4 sm:gap-6\",\n} as const;\n\nconst alignClass: Record<InlineAlign, string> = {\n  start: \"items-start\",\n  center: \"items-center\",\n  end: \"items-end\",\n  stretch: \"items-stretch\",\n  baseline: \"items-baseline\",\n} as const;\n\nexport { gapClass, alignClass };\n</script>\n\n<script setup lang=\"ts\">\nimport { cn } from \"@ecoma-io/loom-core\";\n\nwithDefaults(\n  defineProps<{\n    /** Horizontal gap step — mirrors Stack's scale. Tightens one notch below `sm`. */\n    gap?: InlineGap;\n    /** Cross-axis alignment of children. */\n    align?: InlineAlign;\n    /** Whether items wrap to new lines when they exceed the container width. */\n    wrap?: boolean;\n  }>(),\n  { gap: \"md\", align: \"stretch\", wrap: true },\n);\n</script>\n\n<template>\n  <div\n    :class=\"\n      cn('flex flex-row', gapClass[gap], alignClass[align], wrap ? 'flex-wrap' : 'flex-nowrap')\n    \"\n  >\n    <slot />\n  </div>\n</template>\n"],"mappings":";;;;AAiBA,IAAM,WAAsC;CAC1C,IAAI;CACJ,IAAI;CACJ,IAAI;AACN;AAEA,IAAM,aAA0C;CAC9C,OAAO;CACP,QAAQ;CACR,KAAK;CACL,SAAS;CACT,UAAU;AACZ;;;;;;;;;;;;;GAsBE,OAAA,UAAA,GAAA,mBAMM,OAAA,EALH,OAAK,eAAS,MAAA,EAAA,CAAE,CAAA,iBAAkB,SAAS,QAAA,MAAM,WAAW,QAAA,QAAQ,QAAA,OAAI,cAAA,aAAA,CAAA,EAAA,GAAA,CAIzE,WAAQ,KAAA,QAAA,SAAA,CAAA,GAAA,CAAA"}

package/dist/composition/scroll-reel/src/ScrollReel.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"ScrollReel.js","names":[],"sources":["../../../../packages/composition/scroll-reel/src/ScrollReel.vue"],"sourcesContent":["<script lang=\"ts\">\n/**\n * ScrollReel — horizontal scrolling strip with scroll-snap.\n *\n * A touch-friendly, keyboard-navigable horizontal scroll container with\n * optional scroll-snap alignment. Arrow keys scroll to the next or previous\n * snap point; the `Home` and `End` keys jump to the start or end of the\n * strip.\n *\n * A ScrollReel is a component, not `overflow-x-auto snap-x snap-mandatory`,\n * because keyboard accessibility for scroll-snap requires JavaScript (arrow\n * keys must find the next snap-aligned child and scroll it into view), and\n * the gap tightens one step below `sm` like Stack and DashboardGrid.\n */\nexport type ScrollReelSnap = \"start\" | \"center\" | \"end\" | \"none\";\n\nexport type ScrollReelGap = \"sm\" | \"md\" | \"lg\";\n\n/**\n * Loom's English, co-located with the component so it tree-shakes with it,\n * and exported so a host can build a partial vocabulary against the real\n * thing rather than a transcription of it. The type itself lives in the\n * labels registry (`ScrollReelLabels`) like every other slot's, so\n * `provideLoomLabels({ scrollReel: … })` reaches this component exactly as\n * it reaches every primitive — composition sits above labels in the layer\n * direction, and a host localising one reel should not have to learn a\n * second seam to do it.\n */\nexport const SCROLL_REEL_LABELS: ScrollReelLabels = {\n  region: \"Scrollable content\",\n};\n\nconst snapClass: Record<ScrollReelSnap, string> = {\n  start: \"snap-x snap-mandatory snap-start\",\n  center: \"snap-x snap-mandatory snap-center\",\n  end: \"snap-x snap-mandatory snap-end\",\n  // `none` means no snap alignment — items scroll freely.\n  none: \"\",\n} as const;\n\nconst gapClass: Record<ScrollReelGap, string> = {\n  sm: \"gap-2 sm:gap-3\",\n  md: \"gap-3 sm:gap-4\",\n  lg: \"gap-4 sm:gap-6\",\n} as const;\n\nexport { snapClass, gapClass };\n</script>\n\n<script setup lang=\"ts\">\nimport { ref } from \"vue\";\nimport { cn, smoothScrollBehavior } from \"@ecoma-io/loom-core\";\nimport { useLabels, type LabelOverrides, type ScrollReelLabels } from \"@ecoma-io/loom-labels\";\n\nconst props = withDefaults(\n  defineProps<{\n    /** Scroll-snap alignment. \"none\" disables snap entirely. */\n    snap?: ScrollReelSnap;\n    /** Gap between items — mirrors Stack's scale. Tightens one notch below `sm`. */\n    gap?: ScrollReelGap;\n    /**\n     * Names for what the reel says out loud, as any subset of\n     * `ScrollReelLabels` — the per-instance correction over\n     * `SCROLL_REEL_LABELS`, in the same shape a primitive's `labels` prop\n     * takes.\n     */\n    labels?: LabelOverrides<ScrollReelLabels>;\n  }>(),\n  { snap: \"start\", gap: \"md\" },\n);\n\n// `text`, not `labels`: the prop of that name is one of the three sources this\n// resolves (own prop, then the host vocabulary from `provideLoomLabels`, then\n// these English defaults), and a template reading the raw prop would be\n// reading the overrides rather than the answer.\nconst text = useLabels(\"scrollReel\", SCROLL_REEL_LABELS, () => props.labels);\n\nconst reel = ref<HTMLDivElement | null>(null);\n\n// The reduced-motion softening lives in core (`smoothScrollBehavior`): an\n// explicit `\"smooth\"` in a scrollTo dictionary overrides the stylesheet's\n// kill-switch, so the question has to be answered at the call site — and\n// Carousel asks it too, which is why the answer is shared rather than owned.\nconst scrollBehavior = smoothScrollBehavior;\n\n/**\n * Keyboard navigation for scroll-snap: arrow keys scroll to the next or\n * previous snap-aligned child. Without this, the browser's default arrow-key\n * behaviour scrolls by a fixed pixel amount that rarely aligns with snap\n * points, leaving the strip between two items.\n */\nfunction onKeydown(event: KeyboardEvent) {\n  const el = reel.value;\n  if (!el) return;\n\n  // A keypress inside a nested editable (search field, combobox, contenteditable\n  // chip) bubbles up to this listener: the arrows and Home/End are the caret's\n  // keys there, not the reel's. Step aside so the text control keeps them —\n  // the same boundary Toolbar draws at its own listener.\n  if ((event.target as HTMLElement).closest(\"input, select, textarea, [contenteditable]\")) return;\n\n  const direction = event.key === \"ArrowRight\" ? 1 : event.key === \"ArrowLeft\" ? -1 : 0;\n  if (direction === 0 && event.key !== \"Home\" && event.key !== \"End\") return;\n\n  event.preventDefault();\n\n  const behavior = scrollBehavior();\n  if (event.key === \"Home\") {\n    el.scrollTo({ left: 0, behavior });\n    return;\n  }\n  if (event.key === \"End\") {\n    el.scrollTo({ left: el.scrollWidth, behavior });\n    return;\n  }\n\n  // Find the next snap-aligned child in the scroll direction.\n  const children = [...el.children] as HTMLElement[];\n  const scrollEdge = direction === 1 ? el.scrollLeft + el.clientWidth : el.scrollLeft;\n\n  for (const child of direction === 1 ? children : children.reverse()) {\n    const childEdge = direction === 1 ? child.offsetLeft : child.offsetLeft + child.offsetWidth;\n    const isNext = direction === 1 ? childEdge > scrollEdge - 1 : childEdge < scrollEdge + 1;\n    if (isNext) {\n      child.scrollIntoView({ behavior, block: \"nearest\", inline: \"start\" });\n      break;\n    }\n  }\n}\n</script>\n\n<template>\n  <!-- `role=\"region\"` + `tabindex=\"0\"` + an accessible name make this a named,\n    focusable landmark region. The keyboard handler is what makes the\n    scroll-snap strip navigable by arrow keys — a genuine interaction on\n    a genuinely interactive element. The rule does not account for\n    non-interactive ARIA roles with an explicit tabindex. -->\n  <!-- eslint-disable-next-line vuejs-accessibility/no-static-element-interactions -->\n  <div\n    ref=\"reel\"\n    class=\"overflow-x-auto\"\n    :class=\"cn('flex flex-row', snapClass[snap], gapClass[gap])\"\n    tabindex=\"0\"\n    role=\"region\"\n    :aria-label=\"text.region\"\n    @keydown=\"onKeydown\"\n  >\n    <slot />\n  </div>\n</template>\n"],"mappings":""}

package/dist/composition/scroll-reel/src/ScrollReel.vue_vue_type_script_setup_true_lang.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"ScrollReel.vue_vue_type_script_setup_true_lang.js","names":[],"sources":["../../../../packages/composition/scroll-reel/src/ScrollReel.vue"],"sourcesContent":["<script lang=\"ts\">\n/**\n * ScrollReel — horizontal scrolling strip with scroll-snap.\n *\n * A touch-friendly, keyboard-navigable horizontal scroll container with\n * optional scroll-snap alignment. Arrow keys scroll to the next or previous\n * snap point; the `Home` and `End` keys jump to the start or end of the\n * strip.\n *\n * A ScrollReel is a component, not `overflow-x-auto snap-x snap-mandatory`,\n * because keyboard accessibility for scroll-snap requires JavaScript (arrow\n * keys must find the next snap-aligned child and scroll it into view), and\n * the gap tightens one step below `sm` like Stack and DashboardGrid.\n */\nexport type ScrollReelSnap = \"start\" | \"center\" | \"end\" | \"none\";\n\nexport type ScrollReelGap = \"sm\" | \"md\" | \"lg\";\n\n/**\n * Loom's English, co-located with the component so it tree-shakes with it,\n * and exported so a host can build a partial vocabulary against the real\n * thing rather than a transcription of it. The type itself lives in the\n * labels registry (`ScrollReelLabels`) like every other slot's, so\n * `provideLoomLabels({ scrollReel: … })` reaches this component exactly as\n * it reaches every primitive — composition sits above labels in the layer\n * direction, and a host localising one reel should not have to learn a\n * second seam to do it.\n */\nexport const SCROLL_REEL_LABELS: ScrollReelLabels = {\n  region: \"Scrollable content\",\n};\n\nconst snapClass: Record<ScrollReelSnap, string> = {\n  start: \"snap-x snap-mandatory snap-start\",\n  center: \"snap-x snap-mandatory snap-center\",\n  end: \"snap-x snap-mandatory snap-end\",\n  // `none` means no snap alignment — items scroll freely.\n  none: \"\",\n} as const;\n\nconst gapClass: Record<ScrollReelGap, string> = {\n  sm: \"gap-2 sm:gap-3\",\n  md: \"gap-3 sm:gap-4\",\n  lg: \"gap-4 sm:gap-6\",\n} as const;\n\nexport { snapClass, gapClass };\n</script>\n\n<script setup lang=\"ts\">\nimport { ref } from \"vue\";\nimport { cn, smoothScrollBehavior } from \"@ecoma-io/loom-core\";\nimport { useLabels, type LabelOverrides, type ScrollReelLabels } from \"@ecoma-io/loom-labels\";\n\nconst props = withDefaults(\n  defineProps<{\n    /** Scroll-snap alignment. \"none\" disables snap entirely. */\n    snap?: ScrollReelSnap;\n    /** Gap between items — mirrors Stack's scale. Tightens one notch below `sm`. */\n    gap?: ScrollReelGap;\n    /**\n     * Names for what the reel says out loud, as any subset of\n     * `ScrollReelLabels` — the per-instance correction over\n     * `SCROLL_REEL_LABELS`, in the same shape a primitive's `labels` prop\n     * takes.\n     */\n    labels?: LabelOverrides<ScrollReelLabels>;\n  }>(),\n  { snap: \"start\", gap: \"md\" },\n);\n\n// `text`, not `labels`: the prop of that name is one of the three sources this\n// resolves (own prop, then the host vocabulary from `provideLoomLabels`, then\n// these English defaults), and a template reading the raw prop would be\n// reading the overrides rather than the answer.\nconst text = useLabels(\"scrollReel\", SCROLL_REEL_LABELS, () => props.labels);\n\nconst reel = ref<HTMLDivElement | null>(null);\n\n// The reduced-motion softening lives in core (`smoothScrollBehavior`): an\n// explicit `\"smooth\"` in a scrollTo dictionary overrides the stylesheet's\n// kill-switch, so the question has to be answered at the call site — and\n// Carousel asks it too, which is why the answer is shared rather than owned.\nconst scrollBehavior = smoothScrollBehavior;\n\n/**\n * Keyboard navigation for scroll-snap: arrow keys scroll to the next or\n * previous snap-aligned child. Without this, the browser's default arrow-key\n * behaviour scrolls by a fixed pixel amount that rarely aligns with snap\n * points, leaving the strip between two items.\n */\nfunction onKeydown(event: KeyboardEvent) {\n  const el = reel.value;\n  if (!el) return;\n\n  // A keypress inside a nested editable (search field, combobox, contenteditable\n  // chip) bubbles up to this listener: the arrows and Home/End are the caret's\n  // keys there, not the reel's. Step aside so the text control keeps them —\n  // the same boundary Toolbar draws at its own listener.\n  if ((event.target as HTMLElement).closest(\"input, select, textarea, [contenteditable]\")) return;\n\n  const direction = event.key === \"ArrowRight\" ? 1 : event.key === \"ArrowLeft\" ? -1 : 0;\n  if (direction === 0 && event.key !== \"Home\" && event.key !== \"End\") return;\n\n  event.preventDefault();\n\n  const behavior = scrollBehavior();\n  if (event.key === \"Home\") {\n    el.scrollTo({ left: 0, behavior });\n    return;\n  }\n  if (event.key === \"End\") {\n    el.scrollTo({ left: el.scrollWidth, behavior });\n    return;\n  }\n\n  // Find the next snap-aligned child in the scroll direction.\n  const children = [...el.children] as HTMLElement[];\n  const scrollEdge = direction === 1 ? el.scrollLeft + el.clientWidth : el.scrollLeft;\n\n  for (const child of direction === 1 ? children : children.reverse()) {\n    const childEdge = direction === 1 ? child.offsetLeft : child.offsetLeft + child.offsetWidth;\n    const isNext = direction === 1 ? childEdge > scrollEdge - 1 : childEdge < scrollEdge + 1;\n    if (isNext) {\n      child.scrollIntoView({ behavior, block: \"nearest\", inline: \"start\" });\n      break;\n    }\n  }\n}\n</script>\n\n<template>\n  <!-- `role=\"region\"` + `tabindex=\"0\"` + an accessible name make this a named,\n    focusable landmark region. The keyboard handler is what makes the\n    scroll-snap strip navigable by arrow keys — a genuine interaction on\n    a genuinely interactive element. The rule does not account for\n    non-interactive ARIA roles with an explicit tabindex. -->\n  <!-- eslint-disable-next-line vuejs-accessibility/no-static-element-interactions -->\n  <div\n    ref=\"reel\"\n    class=\"overflow-x-auto\"\n    :class=\"cn('flex flex-row', snapClass[snap], gapClass[gap])\"\n    tabindex=\"0\"\n    role=\"region\"\n    :aria-label=\"text.region\"\n    @keydown=\"onKeydown\"\n  >\n    <slot />\n  </div>\n</template>\n"],"mappings":";;;;;;;;;;;;;;;;;;AA4BA,IAAa,qBAAuC,EAClD,QAAQ,qBACV;AAEA,IAAM,YAA4C;CAChD,OAAO;CACP,QAAQ;CACR,KAAK;CAEL,MAAM;AACR;AAEA,IAAM,WAA0C;CAC9C,IAAI;CACJ,IAAI;CACJ,IAAI;AACN;;;;;;;;;EAUA,MAAM,QAAQ;EAqBd,MAAM,OAAO,UAAU,cAAc,0BAA0B,MAAM,MAAM;EAE3E,MAAM,OAAO,IAA2B,IAAI;EAM5C,MAAM,iBAAiB;;;;;;;EAQvB,SAAS,UAAU,OAAsB;GACvC,MAAM,KAAK,KAAK;GAChB,IAAI,CAAC,IAAI;GAMT,IAAK,MAAM,OAAuB,QAAQ,4CAA4C,GAAG;GAEzF,MAAM,YAAY,MAAM,QAAQ,eAAe,IAAI,MAAM,QAAQ,cAAc,KAAK;GACpF,IAAI,cAAc,KAAK,MAAM,QAAQ,UAAU,MAAM,QAAQ,OAAO;GAEpE,MAAM,eAAe;GAErB,MAAM,WAAW,eAAe;GAChC,IAAI,MAAM,QAAQ,QAAQ;IACxB,GAAG,SAAS;KAAE,MAAM;KAAG;IAAS,CAAC;IACjC;GACF;GACA,IAAI,MAAM,QAAQ,OAAO;IACvB,GAAG,SAAS;KAAE,MAAM,GAAG;KAAa;IAAS,CAAC;IAC9C;GACF;GAGA,MAAM,WAAW,CAAC,GAAG,GAAG,QAAQ;GAChC,MAAM,aAAa,cAAc,IAAI,GAAG,aAAa,GAAG,cAAc,GAAG;GAEzE,KAAK,MAAM,SAAS,cAAc,IAAI,WAAW,SAAS,QAAQ,GAAG;IACnE,MAAM,YAAY,cAAc,IAAI,MAAM,aAAa,MAAM,aAAa,MAAM;IAEhF,IADe,cAAc,IAAI,YAAY,aAAa,IAAI,YAAY,aAAa,GAC3E;KACV,MAAM,eAAe;MAAE;MAAU,OAAO;MAAW,QAAQ;KAAQ,CAAC;KACpE;IACF;GACF;EACF;;GAUE,OAAA,UAAA,GAAA,mBAUM,OAAA;IATA,SAAA;IAAJ,KAAI;IACJ,OAAK,eAAA,CAAC,mBACE,MAAA,EAAA,CAAE,CAAA,iBAAkB,UAAU,QAAA,OAAO,SAAS,QAAA,IAAG,CAAA,CAAA;IACzD,UAAS;IACT,MAAK;IACJ,cAAY,MAAA,IAAA,CAAI,CAAC;IACR;GAEV,GAAA,CAAA,WAAQ,KAAA,QAAA,SAAA,CAAA,GAAA,IAAA,UAAA"}

package/dist/composition/sidebar/src/Sidebar.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"Sidebar.js","names":[],"sources":["../../../../packages/composition/sidebar/src/Sidebar.vue"],"sourcesContent":["<script lang=\"ts\">\n/**\n * Sidebar — content + sidebar with intrinsic CSS collapse.\n *\n * The Every Layout \"Sidebar\" pattern: the sidebar gets a fixed `flex-basis`\n * and the content gets `flex-grow: 999`, so the layout wraps and both panels\n * go full-width the moment the content can't fit its `contentMin` percentage.\n * No media query, no JavaScript — the layout derives its own breakpoint from\n * the container's width.\n *\n * A Sidebar is a component because the `calc()` technique for intrinsic\n * sidebar width is non-obvious and easy to get wrong, and Loom wrapping it\n * prevents footguns. It differs from Split in that the content area is the\n * star — it grows to fill all available space — and the sidebar has a\n * preferred, not a minimum, width.\n */\nexport type SidebarSide = \"left\" | \"right\";\n</script>\n\n<script setup lang=\"ts\">\nimport { cn } from \"@ecoma-io/loom-core\";\n\nwithDefaults(\n  defineProps<{\n    /** Which side the sidebar sits on. Controls flex direction and stacking order. */\n    side?: SidebarSide;\n    /** Preferred width for the sidebar (e.g. \"16rem\"). The sidebar does not grow. */\n    sideWidth?: string;\n    /** Minimum percentage of the container the content demands before the layout wraps. Default: `\"50%\"`. */\n    contentMin?: string;\n    /** Whether to add a gap between the two panels. Default: `true`. */\n    gap?: boolean;\n  }>(),\n  { side: \"left\", sideWidth: \"16rem\", contentMin: \"50%\", gap: true },\n);\n</script>\n\n<template>\n  <!--\n    `flex-wrap: wrap` is the intrinsic collapse mechanism. When the content\n    can't fit its `contentMin`, it wraps to a new line and both panels take\n    full width — the sidebar becomes a full-width section above or below the\n    content, depending on `side`.\n\n    The sidebar's `flex-basis` is its preferred width. The content's\n    `flex-grow: 999` ensures it takes all remaining space when there is room,\n    but its `flex-basis: 0` and `min-width: contentMin` trigger wrapping\n    when there isn't.\n  -->\n  <div\n    :class=\"cn('flex flex-row', gap ? 'gap-3 sm:gap-4' : undefined)\"\n    :style=\"{ flexWrap: 'wrap' }\"\n  >\n    <!--\n      Document order follows `side`, so the wrapped stack never contradicts\n      the side-by-side row and screen-reader order matches the visual one:\n      content first when `side=\"right\"`, sidebar first when `side=\"left\"`.\n      flex-row (never reverse) plus this ordering is what makes the wrap\n      produce content-above-sidebar for `side=\"right\"`.\n    -->\n    <template v-if=\"side === 'right'\">\n      <!-- Content: fills all remaining space (flex-grow: 999), but its\n           min-width: contentMin triggers wrapping when there isn't room. -->\n      <div\n        :style=\"{\n          flexBasis: 0,\n          flexGrow: 999,\n          flexShrink: 1,\n          minWidth: contentMin,\n        }\"\n      >\n        <slot />\n      </div>\n      <!-- Sidebar: preferred width as flex-basis, does not grow. -->\n      <div\n        :style=\"{\n          flexBasis: sideWidth,\n          flexGrow: 0,\n          flexShrink: 1,\n        }\"\n      >\n        <slot name=\"side\" />\n      </div>\n    </template>\n    <template v-else>\n      <!-- Sidebar: preferred width as flex-basis, does not grow. -->\n      <div\n        :style=\"{\n          flexBasis: sideWidth,\n          flexGrow: 0,\n          flexShrink: 1,\n        }\"\n      >\n        <slot name=\"side\" />\n      </div>\n      <!-- Content: fills all remaining space (flex-grow: 999), but its\n           min-width: contentMin triggers wrapping when there isn't room. -->\n      <div\n        :style=\"{\n          flexBasis: 0,\n          flexGrow: 999,\n          flexShrink: 1,\n          minWidth: contentMin,\n        }\"\n      >\n        <slot />\n      </div>\n    </template>\n  </div>\n</template>\n"],"mappings":""}

package/dist/composition/sidebar/src/Sidebar.vue_vue_type_script_setup_true_lang.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"Sidebar.vue_vue_type_script_setup_true_lang.js","names":[],"sources":["../../../../packages/composition/sidebar/src/Sidebar.vue"],"sourcesContent":["<script lang=\"ts\">\n/**\n * Sidebar — content + sidebar with intrinsic CSS collapse.\n *\n * The Every Layout \"Sidebar\" pattern: the sidebar gets a fixed `flex-basis`\n * and the content gets `flex-grow: 999`, so the layout wraps and both panels\n * go full-width the moment the content can't fit its `contentMin` percentage.\n * No media query, no JavaScript — the layout derives its own breakpoint from\n * the container's width.\n *\n * A Sidebar is a component because the `calc()` technique for intrinsic\n * sidebar width is non-obvious and easy to get wrong, and Loom wrapping it\n * prevents footguns. It differs from Split in that the content area is the\n * star — it grows to fill all available space — and the sidebar has a\n * preferred, not a minimum, width.\n */\nexport type SidebarSide = \"left\" | \"right\";\n</script>\n\n<script setup lang=\"ts\">\nimport { cn } from \"@ecoma-io/loom-core\";\n\nwithDefaults(\n  defineProps<{\n    /** Which side the sidebar sits on. Controls flex direction and stacking order. */\n    side?: SidebarSide;\n    /** Preferred width for the sidebar (e.g. \"16rem\"). The sidebar does not grow. */\n    sideWidth?: string;\n    /** Minimum percentage of the container the content demands before the layout wraps. Default: `\"50%\"`. */\n    contentMin?: string;\n    /** Whether to add a gap between the two panels. Default: `true`. */\n    gap?: boolean;\n  }>(),\n  { side: \"left\", sideWidth: \"16rem\", contentMin: \"50%\", gap: true },\n);\n</script>\n\n<template>\n  <!--\n    `flex-wrap: wrap` is the intrinsic collapse mechanism. When the content\n    can't fit its `contentMin`, it wraps to a new line and both panels take\n    full width — the sidebar becomes a full-width section above or below the\n    content, depending on `side`.\n\n    The sidebar's `flex-basis` is its preferred width. The content's\n    `flex-grow: 999` ensures it takes all remaining space when there is room,\n    but its `flex-basis: 0` and `min-width: contentMin` trigger wrapping\n    when there isn't.\n  -->\n  <div\n    :class=\"cn('flex flex-row', gap ? 'gap-3 sm:gap-4' : undefined)\"\n    :style=\"{ flexWrap: 'wrap' }\"\n  >\n    <!--\n      Document order follows `side`, so the wrapped stack never contradicts\n      the side-by-side row and screen-reader order matches the visual one:\n      content first when `side=\"right\"`, sidebar first when `side=\"left\"`.\n      flex-row (never reverse) plus this ordering is what makes the wrap\n      produce content-above-sidebar for `side=\"right\"`.\n    -->\n    <template v-if=\"side === 'right'\">\n      <!-- Content: fills all remaining space (flex-grow: 999), but its\n           min-width: contentMin triggers wrapping when there isn't room. -->\n      <div\n        :style=\"{\n          flexBasis: 0,\n          flexGrow: 999,\n          flexShrink: 1,\n          minWidth: contentMin,\n        }\"\n      >\n        <slot />\n      </div>\n      <!-- Sidebar: preferred width as flex-basis, does not grow. -->\n      <div\n        :style=\"{\n          flexBasis: sideWidth,\n          flexGrow: 0,\n          flexShrink: 1,\n        }\"\n      >\n        <slot name=\"side\" />\n      </div>\n    </template>\n    <template v-else>\n      <!-- Sidebar: preferred width as flex-basis, does not grow. -->\n      <div\n        :style=\"{\n          flexBasis: sideWidth,\n          flexGrow: 0,\n          flexShrink: 1,\n        }\"\n      >\n        <slot name=\"side\" />\n      </div>\n      <!-- Content: fills all remaining space (flex-grow: 999), but its\n           min-width: contentMin triggers wrapping when there isn't room. -->\n      <div\n        :style=\"{\n          flexBasis: 0,\n          flexGrow: 999,\n          flexShrink: 1,\n          minWidth: contentMin,\n        }\"\n      >\n        <slot />\n      </div>\n    </template>\n  </div>\n</template>\n"],"mappings":";;;;;;;;;;;;;;;;;GAiDE,OAAA,UAAA,GAAA,mBA2DM,OAAA;IA1DH,OAAK,eAAE,MAAA,EAAA,CAAE,CAAA,iBAAkB,QAAA,MAAG,mBAAsB,KAAA,CAAS,CAAA;IAC7D,OAAO,EAAA,UAAA,OAAA;GASQ,GAAA,CAAA,QAAA,SAAI,WAApB,UAAA,GAAA,mBAuBW,UAAA,EAAA,KAAA,EAAA,GAAA,CApBT,mBASM,OAAA,EARH,OAAK,eAAA;;;;IAAkG,UAAA,QAAA;GAOxG,CAAA,EAAA,GAAA,CAAA,WAAQ,KAAA,QAAA,SAAA,CAAA,GAAA,CAAA,GAGV,mBAQM,OAAA,EAPH,OAAK,eAAA;IAAyB,WAAA,QAAA;;;GAM/B,CAAA,EAAA,GAAA,CAAA,WAAoB,KAAA,QAAA,MAAA,CAAA,GAAA,CAAA,CAAA,GAAA,EAAA,MAGxB,UAAA,GAAA,mBAuBW,UAAA,EAAA,KAAA,EAAA,GAAA,CArBT,mBAQM,OAAA,EAPH,OAAK,eAAA;IAAyB,WAAA,QAAA;;;GAM/B,CAAA,EAAA,GAAA,CAAA,WAAoB,KAAA,QAAA,MAAA,CAAA,GAAA,CAAA,GAItB,mBASM,OAAA,EARH,OAAK,eAAA;;;;IAAkG,UAAA,QAAA;GAOxG,CAAA,EAAA,GAAA,CAAA,WAAQ,KAAA,QAAA,SAAA,CAAA,GAAA,CAAA,CAAA,GAAA,EAAA,EAAA,GAAA,CAAA"}

package/dist/composition/split/src/Split.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"Split.js","names":[],"sources":["../../../../packages/composition/split/src/Split.vue"],"sourcesContent":["<script lang=\"ts\">\n/**\n * Split — two-panel layout with intrinsic collapse.\n *\n * A flex row that places a side panel and a content area side by side, and\n * stacks them vertically once the container is too narrow for both. The side\n * panel gets a fixed minimum width; the content area grows to fill the\n * remaining space.\n *\n * This is the Every Layout \"Sidebar\" pattern, simplified for the common\n * two-panel case. The intrinsic collapse — panels stack when the container is\n * too narrow — avoids a breakpoint per viewport, and works identically inside\n * a sidebar-narrowed workspace and full-bleed on an ultra-wide monitor.\n *\n * A Split is a component, not a hand-rolled flex row with a media query,\n * because the wrap-and-floor technique is non-obvious and easy to get wrong,\n * and the stacking order (side above or below) is an intent the `side` prop\n * expresses.\n */\nexport type SplitSide = \"left\" | \"right\";\n\nexport type SplitGap = \"sm\" | \"md\" | \"lg\" | \"none\";\n\nconst gapClass: Record<Exclude<SplitGap, \"none\">, string> = {\n  sm: \"gap-2 sm:gap-3\",\n  md: \"gap-3 sm:gap-4\",\n  lg: \"gap-4 sm:gap-6\",\n} as const;\n\nexport { gapClass };\n</script>\n\n<script setup lang=\"ts\">\nimport { cn } from \"@ecoma-io/loom-core\";\n\nwithDefaults(\n  defineProps<{\n    /** The side the panel sits on. Controls stacking order when collapsed: \"left\" stacks the panel above, \"right\" stacks it below. */\n    side?: SplitSide;\n    /** Minimum width for the side panel (e.g. \"16rem\"). The content area takes the rest. */\n    minSideWidth?: string;\n    /** Gap between the two panels. Tightens one notch below `sm` (except \"none\"). */\n    gap?: SplitGap;\n  }>(),\n  { side: \"left\", minSideWidth: \"16rem\", gap: \"md\" },\n);\n</script>\n\n<template>\n  <!--\n    `flex-wrap` is the intrinsic collapse mechanism: when the combined\n    `min-width` of both panels exceeds the container, the second panel wraps\n    to a new line. Where that happens is decided by the panels' own minimum\n    widths — there is no breakpoint prop to set it with.\n  -->\n  <div\n    :class=\"cn('flex flex-row', gap !== 'none' ? gapClass[gap] : undefined)\"\n    :style=\"{\n      flexWrap: 'wrap',\n    }\"\n  >\n    <!--\n      Document order follows `side`, so the wrapped stack never contradicts\n      the side-by-side row and screen-reader order matches the visual one:\n      content first when `side=\"right\"`, side first when `side=\"left\"`.\n      flex-row (never reverse) plus this ordering is what makes the wrap\n      produce content-above-panel for `side=\"right\"`.\n    -->\n    <template v-if=\"side === 'right'\">\n      <!-- Content area: fills remaining space, but demands at least 50% of\n           the container before wrapping. Wrapped onto a line of its own it\n           takes that whole line: flex-basis 0 starts from nothing and\n           flex-grow 999 absorbs every free pixel on the line. -->\n      <div\n        :style=\"{\n          flexBasis: 0,\n          flexGrow: 999,\n          flexShrink: 1,\n          minWidth: '50%',\n        }\"\n      >\n        <slot />\n      </div>\n      <!-- Side panel: fixed minimum width, does not grow. Wrapped onto a\n           line of its own it keeps exactly that declared width — flex-grow 0\n           with an explicit basis never widens, so the full-line stretch is\n           the content side's alone. -->\n      <div\n        :style=\"{\n          flexBasis: minSideWidth,\n          flexGrow: 0,\n          flexShrink: 0,\n          minWidth: minSideWidth,\n        }\"\n      >\n        <slot name=\"side\" />\n      </div>\n    </template>\n    <template v-else>\n      <!-- Side panel: fixed minimum width, does not grow. Wrapped onto a\n           line of its own it keeps exactly that declared width — flex-grow 0\n           with an explicit basis never widens, so the full-line stretch is\n           the content side's alone. -->\n      <div\n        :style=\"{\n          flexBasis: minSideWidth,\n          flexGrow: 0,\n          flexShrink: 0,\n          minWidth: minSideWidth,\n        }\"\n      >\n        <slot name=\"side\" />\n      </div>\n      <!-- Content area: fills remaining space, but demands at least 50% of\n           the container before wrapping. Wrapped onto a line of its own it\n           takes that whole line: flex-basis 0 starts from nothing and\n           flex-grow 999 absorbs every free pixel on the line. -->\n      <div\n        :style=\"{\n          flexBasis: 0,\n          flexGrow: 999,\n          flexShrink: 1,\n          minWidth: '50%',\n        }\"\n      >\n        <slot />\n      </div>\n    </template>\n  </div>\n</template>\n"],"mappings":""}