@public-ui/mcp 4.4.0-rc.0 → 4.4.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@public-ui/mcp",
-  "version": "4.4.0-rc.0",
+  "version": "4.4.0",
   "license": "EUPL-1.2",
   "homepage": "https://public-ui.github.io",
   "repository": {
@@ -48,7 +48,7 @@
     "glob": "13.0.6",
     "simple-git": "3.36.0",
     "zod": "4.4.3",
-    "@public-ui/components": "4.4.0-rc.0"
+    "@public-ui/components": "4.4.0"
   },
   "devDependencies": {
     "@modelcontextprotocol/inspector": "2.4.0",

package/shared/sample-index.json

@@ -1,6 +1,6 @@
 {
   "metadata": {
-    "generatedAt": "2026-09-07T13:52:19.220Z",
+    "generatedAt": "2026-09-09T07:08:55.741Z",
     "buildMode": "ci",
     "counts": {
       "total": 334,
@@ -10,7 +10,7 @@
       "totalScenarios": 20
     },
     "repo": {
-      "commit": "cec8305b216a7738d03e4812cfbfd473eb47251b",
+      "commit": "9ac818e686a0ab8ef2d6e77598c2e576779cec15",
       "branch": "develop",
       "repoUrl": "https://github.com/public-ui/kolibri"
     }
@@ -21,7 +21,7 @@
       "group": "docs",
       "name": "AGENTS",
       "path": "AGENTS.md",
-      "code": "# Agent Instructions\n\nThis repository is a monorepo managed with **pnpm** and **Nx**. It contains multiple packages under `packages/` such as web components, themes, adapters, samples and tooling.\n\n## Handling hints\n\nWe have a monorepo structure with multiple packages, each with its own `package.json`. The root `package.json` contains shared dependencies and scripts. Use `pnpm` commands to manage dependencies and run scripts across packages.\n\n- To install dependencies, use `pnpm i` at the root level. This will install all dependencies for all packages.\n- If you change a dependency in a package:\n  - Use only exact version numbers in `package.json`. Other peers will not be able to use the package if you can use a range version.\n  - You need to run `pnpm i` at the root level. This updates the lockfile and ensures all packages are using the correct versions.\n- Never add a `packageManager` field to any `package.json` file.\n- Avoid that branch name may contain hidden characters.\n- If something does not work, check in the event of an error whether all dependent submodules have been built.\n- To build a single package faster, run commands with downstream dependents using `pnpm --filter ...<package>` (e.g., `pnpm --filter ...@public-ui/sample-react build`).\n\n## 🚨 Format-first rule\n\n> **Stop before you commit:** run the formatter so CI never rejects your patch for style drift.\n\n1. Run `pnpm format` from the repo root whenever you change code, docs or configs.\n2. If you only touched one package, you may instead run `pnpm --filter <package> format` for a quicker pass.\n3. Re-stage the affected files (`git add -u`) so the formatted result is what lands in the commit.\n\nNo package scripts in this repo need extra flags such as `-- --write`; the scripts already know when to write changes versus just check.\n\n## Semantic Versioning\n\nThis repository follows **Semantic Versioning** (SemVer) for all packages. Each package version is defined in its own `package.json` file. The versioning scheme is as follows:\n\n- **Major version**: Incremented for incompatible API changes.\n- **Minor version**: Incremented for adding functionality in a backwards-compatible manner.\n- **Patch version**: Incremented for backwards-compatible bug fixes.\n\nIf we deprecate a feature, we will mark it as deprecated in the code and documentation, but we will not remove it immediately. Instead, we will provide a migration guide (migration\\*.md) for users to transition to the new feature. Also we provide a migration tool in the `packages/tools/kolibri-cli` package to help with the migration process. You have to add a migration task from the previous version to the new version in the `packages/tools/kolibri-cli/src/migrations` folder. In the migration package, are a lot of migration tasks already implemented, so you can use them as a reference.\n\n## Project Structure\n\n- `packages/components` – Stencil based web components\n  - `packages/components/src/component` – components\n  - `packages/components/src/schema` – schema definitions for all components\n- `packages/samples` – sample applications demonstrating usage\n  - `packages/samples/angular` – Angular sample app; do not edit\n  - `packages/samples/react` – React sample app; all samples; write component samples here\n- `packages/adapters/*` – generated framework integration packages; do not edit\n- `packages/themes` – style themes and assets\n  - `packages/themes/default` – primary maintained standard theme\n  - All other themes are not actively maintained\n- `packages/tools/kolibri-cli` – helper CLI for migration\n- Documentation lives in `docs/`.\n- Do always ignore and do not edit all `assets` folders in all packages, as these are generated by the build process and should not be edited manually. If you need to change something in the assets, you have to change it in the source code and rebuild the package.\n\n## Theming\n\nThe theming is realized with adopted style sheets on web components and will be adopted at the mounted hook of the components. All following styling rules are only relevant for the `components` and `themes` packages.\n\n### The 5 styling layers\n\n1. **A11y Preset layer**: This layer comes out of the `adopted-style-sheets` package and contains the basic styles for accessibility. It is applied to all components.\n2. **Basis Global layer**: This layer contains the basis global styles for all components and comes out of the `@public-ui/components` package. It is applied only component specific layout styles without margins and paddings. Generally, the styling works without colors, as the colors should only be set through the custom Theme Layer.\n3. **Basis Component layer**: This layer contains the basis styles for one component and comes out of the `@public-ui/components` package. It is applied only component specific layout styles without margins and paddings. Generally, the styling works without colors, as the colors should only be set through the custom Theme Layer.\n4. **Theme Global layer**: This layer contains the global styles for all components of a theme and comes out of a own theme package, like `@public-ui/theme-default`.\n5. **Theme Component layer**: This layer contains the component specific styles for one component of a theme and comes out of a own theme package, like `@public-ui/theme-default`.\n\n### Global accessibility styles\n\n```css\n/*\n * This file contains all rules for accessibility.\n */\n@layer kol-global {\n\t:host {\n\t\t/*\n\t\t * Minimum size of interactive elements.\n\t\t */\n\t\t--a11y-min-size: #{rem(44)};\n\t\t/*\n\t\t * No element should be used without a background and font color whose contrast ratio has\n\t\t * not been checked. By initially setting the background color to white and the font color\n\t\t * to black, the contrast ratio is ensured and explicit adjustment is forced.\n\t\t */\n\t\tbackground-color: white;\n\t\tcolor: black;\n\t}\n\n\t* {\n\t\t/*\n\t\t * This rule enables the word dividing for all texts. That is important for high zoom levels.\n\t\t */\n\t\thyphens: auto;\n\t\t/*\n\t\t * Verdana is an accessible font that can be used without requiring additional loading time.\n\t\t */\n\t\tfont-family: Verdana;\n\t\t/*\n\t\t * Letter spacing is required for all texts.\n\t\t */\n\t\tletter-spacing: inherit;\n\t\t/*\n\t\t * This rule enables the word dividing for all texts. That is important for high zoom levels.\n\t\t */\n\t\tword-break: break-word;\n\t\t/*\n\t\t * Word spacing is required for all texts.\n\t\t */\n\t\tword-spacing: inherit;\n\t}\n\n\t/*\n\t * All interactive elements should have a minimum size of rem(44).\n\t */\n\t/* input:not([type='checkbox'], [type='radio'], [type='range']), */\n\t/* option, */\n\t/* select, */\n\t/* textarea, */\n\t[role='button'],\n\tbutton:not([role='link']),\n\t.kol-input .input {\n\t\tmin-height: var(--a11y-min-size);\n\t\tmin-width: var(--a11y-min-size);\n\t}\n\n\t/*\n\t * Some interactive elements should not inherit the font-family and font-size.\n\t */\n\ta,\n\tbutton,\n\th1,\n\th2,\n\th3,\n\th4,\n\th5,\n\th6,\n\tinput,\n\toption,\n\tselect,\n\ttextarea {\n\t\t/*\n\t\t * All elements should inherit the font family from his parent element.\n\t\t */\n\t\tfont-family: inherit;\n\t\t/*\n\t\t * All elements should inherit the font size from his parent element.\n\t\t */\n\t\tfont-size: inherit;\n\t}\n}\n\n/**\n * Sometimes we need the semantic element for accessibility reasons,\n * but we don't want to show it.\n *\n * - https://www.a11yproject.com/posts/how-to-hide-content/\n */\n.visually-hidden {\n\tclip: rect(0 0 0 0);\n\tclip-path: inset(50%);\n\theight: 1px;\n\toverflow: hidden;\n\tposition: absolute;\n\twhite-space: nowrap;\n\twidth: 1px;\n}\n```\n\n### Styling rules\n\nThe basis global layer set the default font-size and box-sizing for all components.\n\n```css\n@layer kol-global {\n\t:host {\n\t\tfont-size: rem(16);\n\t\t/*\n\t\t * The max-width is needed to prevent the table from overflowing the\n\t\t * parent node, if the table is wider than the parent node.\n\t\t */\n\t\tmax-width: 100%;\n\t}\n\n\t* {\n\t\t/*\n\t\t * We prefer to box-sizing: border-box for all elements.\n\t\t */\n\t\tbox-sizing: border-box;\n\t}\n  ...\n}\n```\n\n### Custom Theming rules\n\nThe custom theme layer is used to set the colors and other theme specific styles. The custom theme layer should not contain any layout styles, as these are already set in the basis global and component layers.\n\nFor example, generally the font-family is set in the theme global layer, on the `:host` element, so that all components inherit the font-family from the theme. The font-size is set in the basis global layer, so that all components inherit the font-size from the basis global layer. But it is possible to set a other base font-size in the theme global layer, if needed.\n\n```css\n@layer kol-theme-global {\n\t:host {\n\t\t--font-family: var(--kolibri-font-family, Verdana, Arial, Calibri, Helvetica, sans-serif);\n\t\t--font-size: var(--kolibri-font-size, #{rem(16)});\n    ...\n\t}\n\n\t:host {\n\t\tfont-size: var(--font-size);\n\n\t\t* {\n\t\t\tfont-family: var(--font-family);\n\t\t}\n\t}\n  ...\n}\n```\n\nIn the theme component layer, you can set what ever you need to realize your own custom style guidelines. For example, you can set the colors, borders, shadows, etc. for the component.\n\n```css\n@layer kol-theme-component {\n  ...\n}\n```\n\n### CSS Custom Properties and SASS Variables\n\nCSS custom properties remain part of the global cascade and are not isolated by the Shadow DOM.\nOverusing them (in theme files as well as in component styles) can collide with variables defined\non a host page, and every custom property you declare is implicitly overridable from outside,\nwhether you intended that or not.\n\n**Prefer plain CSS over a custom property.** Before adding a custom property, check whether the\nplatform already gives the consumer a way to control it — the standard box model (`width`,\n`height`), inherited properties (`color`, `font-size` via `em`), or relative units (`%`, container\nquery units). A component that simply fills its host (`width: 100%; height: 100%` inside, a sane\ndefault `width`/`height` on `:host`) can be resized with plain CSS, exactly like a native element —\nno bespoke API, no documentation burden, nothing to keep in sync. Only reach for a custom property\nwhen the value genuinely cannot be derived this way (e.g. a semantic color token that isn't just\n`currentColor`, or a value with no corresponding native CSS mechanism).\n\n**Rule:** only declare a CSS custom property when it is a deliberate, documented customization\npoint (a `--kol-<component>-<name>` design token). For anything else — internal aliases,\nintermediate values, ratios, or derived defaults — use a SASS `$variable` instead. SASS variables\nare resolved at build time, can't leak into the global cascade, and can't be overridden from a host\npage, so they can't accidentally become part of the public API.\n\nDo not introduce a second, internal custom property just to make the code more readable:\n\n```scss\n// ❌ Bad: `--color-bar` is an unintended, additional public custom property.\n// It reacts to overrides from a host page exactly like `--kol-progress-color-bar`,\n// even though only the latter was meant to be part of the API.\n.kol-progress {\n\t--color-bar: var(--kol-progress-color-bar, #0075ff);\n\n\t&__bar-progress {\n\t\tfill: var(--color-bar);\n\t}\n}\n```\n\n```scss\n// ✅ Good: the SASS variable holds the default value; the only custom property\n// is `--kol-progress-color-bar`, referenced directly wherever needed.\n$kol-progress-default-color-bar: #0075ff;\n\n.kol-progress {\n\t&__bar-progress {\n\t\tfill: var(--kol-progress-color-bar, #{$kol-progress-default-color-bar});\n\t}\n}\n```\n\nAny further unit conversion or math that doesn't depend on a runtime custom property (e.g. `to-rem()`,\nratios, breakpoints) belongs in SASS, not in an extra layer of `calc()`/custom-property indirection.\n\n`kol-avatar` is an example of preferring plain CSS: instead of a `--kol-avatar-size` custom property,\n`:host` gets a default `width` and an `aspect-ratio: 1`, and the inner element derives its size from the\nhost via container query units (`cqw`/`cqh`) instead of a separate ratio calculation. Consumers resize it\nthe same way they'd resize any block-level element — with plain `width`/`height`.\n\nThe avatar must always stay square, even if `width` and `height` end up different (e.g. both are set\nexplicitly to different values), so the inner element uses `max(100cqw, 100cqh)` for both its own `width`\nand `height` — the larger of the two wins, and `:host` centers it (`align-items`/`justify-content`), so it\nmay visually extend beyond the host on the smaller axis. Since CSS can't distinguish \"our default\" from\n\"an explicit author value\" on two independent properties, only setting `width` reliably resizes the avatar\nbelow its 100px default; setting only `height` below 100px does not shrink it, because our own default\n`width` is still in effect and wins the `max()`. This is a deliberate, documented trade-off, not a bug —\nachieving full symmetry would require either a custom property or JavaScript, both of which cost more\nthan the trade-off is worth.\n\n### SCSS Architecture Guidelines: BEM with Smart Nesting\n\nWhen writing component theme styles, follow these principles for clean, maintainable SCSS:\n\n#### 1. **Flat BEM Structure (Root Level)**\n\nAll BEM modifiers and independent elements belong at **root level** of the mixin. Never nest BEM class names:\n\n```scss\n@mixin kol-alert-theme {\n\t// ✅ All BEM selectors on root (flat)\n\t.kol-alert { ... }\n\t.kol-alert--variant-msg { ... }\n\t.kol-alert--variant-card { ... }\n\t.kol-alert--type-default { ... }\n\t.kol-alert__container { ... }\n\t.kol-alert__heading { ... }\n}\n```\n\n**Why?** BEM classnames are independent selectors. Each class should be predictable and flat.\n\n#### 2. **Contextual Nesting (When Variants Change Element Behavior)**\n\nNest **only when a modifier changes how a child element behaves**. Keep all rules for an element together:\n\n```scss\n.kol-alert__closer {\n\tplace-self: center;\n\n\t.kol-button {\n\t\tborder-radius: 50%;\n\t\twidth: var(--a11y-min-size);\n\t\theight: var(--a11y-min-size);\n\t\tcursor: pointer;\n\n\t\t// ✅ Variant changes button styling - nest here\n\t\t.kol-alert--variant-msg & {\n\t\t\t--text-color: var(--alert-accent-color);\n\t\t}\n\n\t\t.kol-alert--variant-card & {\n\t\t\t--text-color: var(--color-light);\n\t\t}\n\t}\n}\n```\n\n**Rule of thumb**: All rules for `.kol-button` in `.kol-alert__closer` stay in one place. This keeps related styles together and makes maintenance easier.\n\n#### 3. **Never Use `$root` or `@at-root`**\n\n❌ **Outdated pattern (removed):**\n\n```scss\n.kol-alert {\n\t$root: &;\n\t&__closer {\n\t\t@at-root #{$root}--variant-msg & { ... }\n\t}\n}\n```\n\n✅ **Modern pattern (direct nesting):**\n\n```scss\n.kol-alert__closer {\n\t.kol-button {\n\t\t.kol-alert--variant-msg & { ... }\n\t}\n}\n```\n\nThis is clearer and doesn't require Sass variable gymnastics.\n\n#### 4. **Structure Template**\n\n```scss\n@mixin kol-component-theme {\n\t// 1. Base component (no children)\n\t.kol-component {\n\t\tdisplay: flex;\n\t\twidth: 100%;\n\t}\n\n\t// 2. All BEM modifiers at root (flat)\n\t.kol-component--variant-a {\n\t\t...\n\t}\n\n\t.kol-component--type-default {\n\t\t...\n\t}\n\n\t// 3. Elements with contextual nesting for variants\n\t.kol-component__heading {\n\t\tfont-weight: bold;\n\n\t\t.kol-component--variant-a & {\n\t\t\tcolor: red;\n\t\t}\n\t}\n\n\t.kol-component__content {\n\t\tpadding: 1rem;\n\n\t\t.kol-component--variant-a & {\n\t\t\tbackground: white;\n\t\t}\n\t}\n\n\t// 4. Child components with variant context\n\t.kol-component__button {\n\t\t.kol-button {\n\t\t\tcursor: pointer;\n\n\t\t\t.kol-component--variant-a & {\n\t\t\t\t--text-color: var(--accent);\n\t\t\t}\n\t\t}\n\t}\n}\n```\n\n### General rules for custom themes\n\n- Do not use `!important` in your styles, as this will override the styles of the basis global and component layers.\n- Do only overwrite styling definitions you will really customize. Do not set styling definitions that are already set (redundant) in the basis global and component layers, as this will override the styles of the basis global and component layers.\n- Do not `inherit` styles over the `:host` element, as this will override the styles of the basis global and component layers. This makes your component less robust from outside environment styles. Only the `kol-icon` inherits some specific styles, like `color`, `font-size`, `font-family` and `line-height`, as these are needed for the icon to be displayed correctly inline to this neighbored elements.\n- Do not set the default `font-family`, `font-size` or `box-sizing` in the basis or theme component layer (redundant), as these are already set in the basis global layers. If you need to set a different font-family or font-size, you can do this in the theme global layer.\n- Do not set `margin` or `padding` in the basis global and component layers. If you need to set a different margin or padding, you can do this in the theme global or component layers.\n- Do not use `overflow: hidden` in styling or theming, as it often causes issues for reuse and should be avoided.\n- **Do not use `@layer` declarations in utility files**: Helper files, mixin files, and partial files (starting with `_`) should not contain `@layer` declarations. These files are utilities and should be layer-agnostic. This is enforced by the custom Stylelint rule `kolibri/no-layer-in-utility-files`.\n- **Never use `$root` variables or `@at-root` in component mixins**: All selectors should be explicit. Use direct child/descendant nesting only when a modifier changes element behavior within a specific context.\n\n## Samples\n\nThe samples are located in `packages/samples/react` and demonstrate how to use the components in react. Each component has its own folder and the basic sample are in `basic.tsx`. Other stories can be added in the same folder. All samples of a component are registered in the `routes.ts` file.\n\n## Coding Conventions\n\n- Formatting is enforced via **Prettier** with settings defined in `prettier.config.js` (print width 160, single quotes, tabs).\n- `.editorconfig` sets `indent_style = tab` and `max_line_length = 160` for code files. Markdown and YAML files use spaces.\n- ESLint and Stylelint are run using `pnpm lint`. Lint rules should **not** be disabled via inline comments. Instead, describe the problem and work towards a clean solution.\n- Lists and enumerations in code should be kept in alphanumeric order. This also applies to import specifiers and union type literals.\n- Do not disable ESLint, Stylelint or TypeScript rules inline. Fix the code instead of turning such rules off.\n- ESLint and Stylelint are run using `pnpm lint`.\n- Lists and enumerations in code should be kept in alphabetical order (see `docs/tutorials/NEW_COMPONENT.md`).\n- Commit messages follow the **Conventional Commits** specification.\n- See also the [Contributing Guide](CONTRIBUTING.md) for more details on coding conventions and best practices.\n- Spell \"KoliBri\" with this casing in all documentation and code. The only exception is the component named KolKolibri.\n- Use ESM import syntax in browser code and scripts whenever supported, instead of `require` imports.\n- Do not create barrel files (e.g. `index.ts` that re-export modules). Import modules directly instead.\n- Do not place constant declarations before import statements; imports must always be at the very top of the file.\n- **Scripts must be platform-independent**: All scripts in the `scripts/` folder must work on Windows, macOS, and Linux without requiring external tools or platform-specific dependencies. Use Node.js built-in modules instead of external command-line tools like `rg`, `grep`, `find`, etc.\n\n## Linting and Formatting\n\n- Run `pnpm lint` to check for linting errors across all packages. This script runs ESLint, Stylelint and TypeScript checks.\n  - ⚠️ **Note**: TypeScript type checking in the lint script can require built artifacts. If you've made source code changes, lint will handle any necessary compilation. Explicit pre-build is typically unnecessary.\n  - You can try to automatically fix linting issues with `pnpm lint:eslint --fix`, but this may not resolve all issues.\n- Run `pnpm format` to format all code files using Prettier. You can try to automatically fix linting issues with `pnpm format -w`, but this may not resolve all issues.\n- If your pull request only modifies Markdown files, skip `pnpm build`, `pnpm lint` and `pnpm test`. Just format the Markdown using `pnpm format` or Prettier.\n\n### Pre-commit checklist\n\n- **Always run `pnpm format` (or `pnpm --filter <package> format` for a single workspace) right before committing.** Formatting failures are one of the most common reasons for blocked quality gates, so make this the last step before `git commit` even for documentation-only changes.\n- **For SCSS changes**: Always run `pnpm lint:stylelint --fix` (or `pnpm --filter <package> lint:stylelint --fix`) to automatically correct formatting, property order, and selector structure rules before committing. This ensures compliance with BEM structure and style consistency.\n- After formatting, re-stage affected files with `git add -u` so the formatted content is what gets committed.\n\n## Testing\n\n- Run `pnpm test` from the repository root to execute all unit and integration tests.\n  - ⚠️ **Note**: Test runners (Vitest, Jest, Playwright, etc.) execute an implicit build automatically before running tests. **Do NOT run a separate `pnpm build` beforehand** — this wastes time. The test scripts handle compilation and type checking internally.\n- Visual and snapshot tests can be updated with `pnpm test:update` or via the `update-snapshots.yml` GitHub workflow (see `CONTRIBUTING.md`).\n- Individual packages provide their own test scripts (e.g. `pnpm --filter @public-ui/components test:unit`).\n  - These also perform implicit builds, so explicit pre-build is unnecessary.\n\n## Pull Request Guidelines\n\n- PR titles should be meaningful as they appear in the release notes.\n- Every PR must link to its issue and contain only changes related to that issue.\n- Ensure automated tests pass and manual testing is completed when required.\n- Update documentation or migration guides if your changes affect them.\n",
+      "code": "# Agent Instructions\n\nThis repository is a monorepo managed with **pnpm** and **Nx**. It contains multiple packages under `packages/` such as web components, themes, adapters, samples and tooling.\n\n## Handling hints\n\nWe have a monorepo structure with multiple packages, each with its own `package.json`. The root `package.json` contains shared dependencies and scripts. Use `pnpm` commands to manage dependencies and run scripts across packages.\n\n- To install dependencies, use `pnpm i` at the root level. This will install all dependencies for all packages.\n- If you change a dependency in a package:\n  - Use only exact version numbers in `package.json`. Other peers will not be able to use the package if you can use a range version.\n  - You need to run `pnpm i` at the root level. This updates the lockfile and ensures all packages are using the correct versions.\n- Never add a `packageManager` field to any `package.json` file.\n- Avoid that branch name may contain hidden characters.\n- If something does not work, check in the event of an error whether all dependent submodules have been built.\n- To build a single package faster, run commands with downstream dependents using `pnpm --filter ...<package>` (e.g., `pnpm --filter ...@public-ui/sample-react build`).\n\n## 🚨 Format-first rule\n\n> **Stop before you commit:** run the formatter so CI never rejects your patch for style drift.\n\n1. Run `pnpm format` from the repo root whenever you change code, docs or configs.\n2. If you only touched one package, you may instead run `pnpm --filter <package> format` for a quicker pass.\n3. Re-stage the affected files (`git add -u`) so the formatted result is what lands in the commit.\n\nNo package scripts in this repo need extra flags such as `-- --write`; the scripts already know when to write changes versus just check.\n\n## Semantic Versioning\n\nThis repository follows **Semantic Versioning** (SemVer) for all packages. Each package version is defined in its own `package.json` file. The versioning scheme is as follows:\n\n- **Major version**: Incremented for incompatible API changes.\n- **Minor version**: Incremented for adding functionality in a backwards-compatible manner.\n- **Patch version**: Incremented for backwards-compatible bug fixes.\n\nIf we deprecate a feature, we will mark it as deprecated in the code and documentation, but we will not remove it immediately. Instead, we will provide a migration guide (migration\\*.md) for users to transition to the new feature. Also we provide a migration tool in the `packages/tools/kolibri-cli` package to help with the migration process. You have to add a migration task from the previous version to the new version in the `packages/tools/kolibri-cli/src/migrations` folder. In the migration package, are a lot of migration tasks already implemented, so you can use them as a reference.\n\n## Project Structure\n\n- `packages/components` – Stencil based web components\n  - `packages/components/src/component` – components\n  - `packages/components/src/schema` – schema definitions for all components\n- `packages/samples` – sample applications demonstrating usage\n  - `packages/samples/angular` – Angular sample app; do not edit\n  - `packages/samples/react` – React sample app; all samples; write component samples here\n- `packages/adapters/*` – generated framework integration packages; do not edit\n- `packages/themes` – style themes and assets\n  - `packages/themes/default` – primary maintained standard theme\n  - All other themes are not actively maintained\n- `packages/tools/kolibri-cli` – helper CLI for migration\n- Documentation lives in `docs/`.\n- Do always ignore and do not edit all `assets` folders in all packages, as these are generated by the build process and should not be edited manually. If you need to change something in the assets, you have to change it in the source code and rebuild the package.\n\n## Theming\n\nThe theming is realized with adopted style sheets on web components and will be adopted at the mounted hook of the components. All following styling rules are only relevant for the `components` and `themes` packages.\n\n### The 5 styling layers\n\n1. **A11y Preset layer**: This layer comes out of the `adopted-style-sheets` package and contains the basic styles for accessibility. It is applied to all components.\n2. **Basis Global layer**: This layer contains the basis global styles for all components and comes out of the `@public-ui/components` package. It is applied only component specific layout styles without margins and paddings. Generally, the styling works without colors, as the colors should only be set through the custom Theme Layer.\n3. **Basis Component layer**: This layer contains the basis styles for one component and comes out of the `@public-ui/components` package. It is applied only component specific layout styles without margins and paddings. Generally, the styling works without colors, as the colors should only be set through the custom Theme Layer.\n4. **Theme Global layer**: This layer contains the global styles for all components of a theme and comes out of a own theme package, like `@public-ui/theme-default`.\n5. **Theme Component layer**: This layer contains the component specific styles for one component of a theme and comes out of a own theme package, like `@public-ui/theme-default`.\n\n### Global accessibility styles\n\n```css\n/*\n * This file contains all rules for accessibility.\n */\n@layer kol-global {\n\t:host {\n\t\t/*\n\t\t * Minimum size of interactive elements.\n\t\t */\n\t\t--a11y-min-size: #{rem(44)};\n\t\t/*\n\t\t * No element should be used without a background and font color whose contrast ratio has\n\t\t * not been checked. By initially setting the background color to white and the font color\n\t\t * to black, the contrast ratio is ensured and explicit adjustment is forced.\n\t\t */\n\t\tbackground-color: white;\n\t\tcolor: black;\n\t}\n\n\t* {\n\t\t/*\n\t\t * This rule enables the word dividing for all texts. That is important for high zoom levels.\n\t\t */\n\t\thyphens: auto;\n\t\t/*\n\t\t * Verdana is an accessible font that can be used without requiring additional loading time.\n\t\t */\n\t\tfont-family: Verdana;\n\t\t/*\n\t\t * Letter spacing is required for all texts.\n\t\t */\n\t\tletter-spacing: inherit;\n\t\t/*\n\t\t * This rule enables the word dividing for all texts. That is important for high zoom levels.\n\t\t */\n\t\tword-break: break-word;\n\t\t/*\n\t\t * Word spacing is required for all texts.\n\t\t */\n\t\tword-spacing: inherit;\n\t}\n\n\t/*\n\t * All interactive elements should have a minimum size of rem(44).\n\t */\n\t/* input:not([type='checkbox'], [type='radio'], [type='range']), */\n\t/* option, */\n\t/* select, */\n\t/* textarea, */\n\t[role='button'],\n\tbutton:not([role='link']),\n\t.kol-input .input {\n\t\tmin-height: var(--a11y-min-size);\n\t\tmin-width: var(--a11y-min-size);\n\t}\n\n\t/*\n\t * Some interactive elements should not inherit the font-family and font-size.\n\t */\n\ta,\n\tbutton,\n\th1,\n\th2,\n\th3,\n\th4,\n\th5,\n\th6,\n\tinput,\n\toption,\n\tselect,\n\ttextarea {\n\t\t/*\n\t\t * All elements should inherit the font family from his parent element.\n\t\t */\n\t\tfont-family: inherit;\n\t\t/*\n\t\t * All elements should inherit the font size from his parent element.\n\t\t */\n\t\tfont-size: inherit;\n\t}\n}\n\n/**\n * Sometimes we need the semantic element for accessibility reasons,\n * but we don't want to show it.\n *\n * - https://www.a11yproject.com/posts/how-to-hide-content/\n */\n.visually-hidden {\n\tclip: rect(0 0 0 0);\n\tclip-path: inset(50%);\n\theight: 1px;\n\toverflow: hidden;\n\tposition: absolute;\n\twhite-space: nowrap;\n\twidth: 1px;\n}\n```\n\n### Styling rules\n\nThe basis global layer set the default font-size and box-sizing for all components.\n\n```css\n@layer kol-global {\n\t:host {\n\t\tfont-size: rem(16);\n\t\t/*\n\t\t * The max-width is needed to prevent the table from overflowing the\n\t\t * parent node, if the table is wider than the parent node.\n\t\t */\n\t\tmax-width: 100%;\n\t}\n\n\t* {\n\t\t/*\n\t\t * We prefer to box-sizing: border-box for all elements.\n\t\t */\n\t\tbox-sizing: border-box;\n\t}\n  ...\n}\n```\n\n### Custom Theming rules\n\nThe custom theme layer is used to set the colors and other theme specific styles. The custom theme layer should not contain any layout styles, as these are already set in the basis global and component layers.\n\nFor example, generally the font-family is set in the theme global layer, on the `:host` element, so that all components inherit the font-family from the theme. The font-size is set in the basis global layer, so that all components inherit the font-size from the basis global layer. But it is possible to set a other base font-size in the theme global layer, if needed.\n\n```css\n@layer kol-theme-global {\n\t:host {\n\t\t--font-family: var(--kolibri-font-family, Verdana, Arial, Calibri, Helvetica, sans-serif);\n\t\t--font-size: var(--kolibri-font-size, #{rem(16)});\n    ...\n\t}\n\n\t:host {\n\t\tfont-size: var(--font-size);\n\n\t\t* {\n\t\t\tfont-family: var(--font-family);\n\t\t}\n\t}\n  ...\n}\n```\n\nIn the theme component layer, you can set what ever you need to realize your own custom style guidelines. For example, you can set the colors, borders, shadows, etc. for the component.\n\n```css\n@layer kol-theme-component {\n  ...\n}\n```\n\n### CSS Custom Properties and SASS Variables\n\nCSS custom properties remain part of the global cascade and are not isolated by the Shadow DOM.\nOverusing them (in theme files as well as in component styles) can collide with variables defined\non a host page, and every custom property you declare is implicitly overridable from outside,\nwhether you intended that or not.\n\n**Prefer plain CSS over a custom property.** Before adding a custom property, check whether the\nplatform already gives the consumer a way to control it — the standard box model (`width`,\n`height`), inherited properties (`color`, `font-size` via `em`), or relative units (`%`, container\nquery units). A component that simply fills its host (`width: 100%; height: 100%` inside, a sane\ndefault `width`/`height` on `:host`) can be resized with plain CSS, exactly like a native element —\nno bespoke API, no documentation burden, nothing to keep in sync. Only reach for a custom property\nwhen the value genuinely cannot be derived this way (e.g. a semantic color token that isn't just\n`currentColor`, or a value with no corresponding native CSS mechanism).\n\n**Rule:** only declare a CSS custom property when it is a deliberate, documented customization\npoint (a `--kol-<component>-<name>` design token). For anything else — internal aliases,\nintermediate values, ratios, or derived defaults — use a SASS `$variable` instead. SASS variables\nare resolved at build time, can't leak into the global cascade, and can't be overridden from a host\npage, so they can't accidentally become part of the public API.\n\nDo not introduce a second, internal custom property just to make the code more readable:\n\n```scss\n// ❌ Bad: `--color-bar` is an unintended, additional public custom property.\n// It reacts to overrides from a host page exactly like `--kol-progress-color-bar`,\n// even though only the latter was meant to be part of the API.\n.kol-progress {\n\t--color-bar: var(--kol-progress-color-bar, #0075ff);\n\n\t&__bar-progress {\n\t\tfill: var(--color-bar);\n\t}\n}\n```\n\n```scss\n// ✅ Good: the SASS variable holds the default value; the only custom property\n// is `--kol-progress-color-bar`, referenced directly wherever needed.\n$kol-progress-default-color-bar: #0075ff;\n\n.kol-progress {\n\t&__bar-progress {\n\t\tfill: var(--kol-progress-color-bar, #{$kol-progress-default-color-bar});\n\t}\n}\n```\n\nAny further unit conversion or math that doesn't depend on a runtime custom property (e.g. `to-rem()`,\nratios, breakpoints) belongs in SASS, not in an extra layer of `calc()`/custom-property indirection.\n\n`kol-avatar` is an example of preferring plain CSS: instead of a `--kol-avatar-size` custom property,\n`:host` gets a default `width` and an `aspect-ratio: 1`, and the inner element derives its size from the\nhost via container query units (`cqw`/`cqh`) instead of a separate ratio calculation. Consumers resize it\nthe same way they'd resize any block-level element — with plain `width`/`height`.\n\nThe avatar must always stay square, even if `width` and `height` end up different (e.g. both are set\nexplicitly to different values), so the inner element uses `max(100cqw, 100cqh)` for both its own `width`\nand `height` — the larger of the two wins, and `:host` centers it (`align-items`/`justify-content`), so it\nmay visually extend beyond the host on the smaller axis. Since CSS can't distinguish \"our default\" from\n\"an explicit author value\" on two independent properties, only setting `width` reliably resizes the avatar\nbelow its 100px default; setting only `height` below 100px does not shrink it, because our own default\n`width` is still in effect and wins the `max()`. This is a deliberate, documented trade-off, not a bug —\nachieving full symmetry would require either a custom property or JavaScript, both of which cost more\nthan the trade-off is worth.\n\n### SCSS Architecture Guidelines: BEM with Smart Nesting\n\nWhen writing component theme styles, follow these principles for clean, maintainable SCSS:\n\n#### 1. **Flat BEM Structure (Root Level)**\n\nAll BEM modifiers and independent elements belong at **root level** of the mixin. Never nest BEM class names:\n\n```scss\n@mixin kol-alert-theme {\n\t// ✅ All BEM selectors on root (flat)\n\t.kol-alert { ... }\n\t.kol-alert--variant-msg { ... }\n\t.kol-alert--variant-card { ... }\n\t.kol-alert--type-default { ... }\n\t.kol-alert__container { ... }\n\t.kol-alert__heading { ... }\n}\n```\n\n**Why?** BEM classnames are independent selectors. Each class should be predictable and flat.\n\n#### 2. **Contextual Nesting (When Variants Change Element Behavior)**\n\nNest **only when a modifier changes how a child element behaves**. Keep all rules for an element together:\n\n```scss\n.kol-alert__closer {\n\tplace-self: center;\n\n\t.kol-button {\n\t\tborder-radius: 50%;\n\t\twidth: var(--a11y-min-size);\n\t\theight: var(--a11y-min-size);\n\t\tcursor: pointer;\n\n\t\t// ✅ Variant changes button styling - nest here\n\t\t.kol-alert--variant-msg & {\n\t\t\t--text-color: var(--alert-accent-color);\n\t\t}\n\n\t\t.kol-alert--variant-card & {\n\t\t\t--text-color: var(--color-light);\n\t\t}\n\t}\n}\n```\n\n**Rule of thumb**: All rules for `.kol-button` in `.kol-alert__closer` stay in one place. This keeps related styles together and makes maintenance easier.\n\n#### 3. **Never Use `$root` or `@at-root`**\n\n❌ **Outdated pattern (removed):**\n\n```scss\n.kol-alert {\n\t$root: &;\n\t&__closer {\n\t\t@at-root #{$root}--variant-msg & { ... }\n\t}\n}\n```\n\n✅ **Modern pattern (direct nesting):**\n\n```scss\n.kol-alert__closer {\n\t.kol-button {\n\t\t.kol-alert--variant-msg & { ... }\n\t}\n}\n```\n\nThis is clearer and doesn't require Sass variable gymnastics.\n\n#### 4. **Structure Template**\n\n```scss\n@mixin kol-component-theme {\n\t// 1. Base component (no children)\n\t.kol-component {\n\t\tdisplay: flex;\n\t\twidth: 100%;\n\t}\n\n\t// 2. All BEM modifiers at root (flat)\n\t.kol-component--variant-a {\n\t\t...\n\t}\n\n\t.kol-component--type-default {\n\t\t...\n\t}\n\n\t// 3. Elements with contextual nesting for variants\n\t.kol-component__heading {\n\t\tfont-weight: bold;\n\n\t\t.kol-component--variant-a & {\n\t\t\tcolor: red;\n\t\t}\n\t}\n\n\t.kol-component__content {\n\t\tpadding: 1rem;\n\n\t\t.kol-component--variant-a & {\n\t\t\tbackground: white;\n\t\t}\n\t}\n\n\t// 4. Child components with variant context\n\t.kol-component__button {\n\t\t.kol-button {\n\t\t\tcursor: pointer;\n\n\t\t\t.kol-component--variant-a & {\n\t\t\t\t--text-color: var(--accent);\n\t\t\t}\n\t\t}\n\t}\n}\n```\n\n### General rules for custom themes\n\n- Do not use `!important` in your styles, as this will override the styles of the basis global and component layers.\n- Do only overwrite styling definitions you will really customize. Do not set styling definitions that are already set (redundant) in the basis global and component layers, as this will override the styles of the basis global and component layers.\n- Do not `inherit` styles over the `:host` element, as this will override the styles of the basis global and component layers. This makes your component less robust from outside environment styles. Only the `kol-icon` inherits some specific styles, like `color`, `font-size`, `font-family` and `line-height`, as these are needed for the icon to be displayed correctly inline to this neighbored elements.\n- Do not set the default `font-family`, `font-size` or `box-sizing` in the basis or theme component layer (redundant), as these are already set in the basis global layers. If you need to set a different font-family or font-size, you can do this in the theme global layer.\n- Do not set `margin` or `padding` in the basis global and component layers. If you need to set a different margin or padding, you can do this in the theme global or component layers.\n- Do not use `overflow: hidden` in styling or theming, as it often causes issues for reuse and should be avoided.\n- **Do not use `@layer` declarations in utility files**: Helper files, mixin files, and partial files (starting with `_`) should not contain `@layer` declarations. These files are utilities and should be layer-agnostic. This is enforced by the custom Stylelint rule `kolibri/no-layer-in-utility-files`.\n- **Never use `$root` variables or `@at-root` in component mixins**: All selectors should be explicit. Use direct child/descendant nesting only when a modifier changes element behavior within a specific context.\n\n## Samples\n\nThe samples are located in `packages/samples/react` and demonstrate how to use the components in react. Each component has its own folder and the basic sample are in `basic.tsx`. Other stories can be added in the same folder. All samples of a component are registered in the `routes.ts` file.\n\n## Coding Conventions\n\n- Formatting is enforced via **Prettier** with settings defined in `prettier.config.js` (print width 160, single quotes, tabs).\n- `.editorconfig` sets `indent_style = tab` and `max_line_length = 160` for code files. Markdown and YAML files use spaces.\n- ESLint and Stylelint are run using `pnpm lint`. Lint rules should **not** be disabled via inline comments. Instead, describe the problem and work towards a clean solution.\n- Lists and enumerations in code should be kept in alphanumeric order. This also applies to import specifiers and union type literals.\n- Do not disable ESLint, Stylelint or TypeScript rules inline. Fix the code instead of turning such rules off.\n- ESLint and Stylelint are run using `pnpm lint`.\n- Lists and enumerations in code should be kept in alphabetical order (see `docs/tutorials/NEW_COMPONENT.md`).\n- Commit messages follow the **Conventional Commits** specification.\n- See also the [Contributing Guide](CONTRIBUTING.md) for more details on coding conventions and best practices.\n- Spell \"KoliBri\" with this casing in all documentation and code. The only exception is the component named KolKolibri.\n- Use ESM import syntax in browser code and scripts whenever supported, instead of `require` imports.\n- Do not create barrel files (e.g. `index.ts` that re-export modules). Import modules directly instead.\n- Do not place constant declarations before import statements; imports must always be at the very top of the file.\n- **Scripts must be platform-independent**: All scripts in the `scripts/` folder must work on Windows, macOS, and Linux without requiring external tools or platform-specific dependencies. Use Node.js built-in modules instead of external command-line tools like `rg`, `grep`, `find`, etc.\n\n## Linting and Formatting\n\n- Run `pnpm lint` to check for linting errors across all packages. This script runs ESLint, Stylelint and TypeScript checks.\n  - ⚠️ **Note**: TypeScript type checking in the lint script can require built artifacts. If you've made source code changes, lint will handle any necessary compilation. Explicit pre-build is typically unnecessary.\n  - You can try to automatically fix linting issues with `pnpm lint:eslint --fix`, but this may not resolve all issues.\n- Run `pnpm format` to format all code files using Prettier. You can try to automatically fix linting issues with `pnpm format -w`, but this may not resolve all issues.\n- If your pull request only modifies Markdown files, skip `pnpm build`, `pnpm lint` and `pnpm test`. Just format the Markdown using `pnpm format` or Prettier.\n\n### Pre-commit checklist\n\n- **Always run `pnpm format` (or `pnpm --filter <package> format` for a single workspace) right before committing.** Formatting failures are one of the most common reasons for blocked quality gates, so make this the last step before `git commit` even for documentation-only changes.\n- **For SCSS changes**: Always run `pnpm lint:stylelint --fix` (or `pnpm --filter <package> lint:stylelint --fix`) to automatically correct formatting, property order, and selector structure rules before committing. This ensures compliance with BEM structure and style consistency.\n- After formatting, re-stage affected files with `git add -u` so the formatted content is what gets committed.\n\n## Testing\n\n- Run `pnpm test` from the repository root to execute all unit and integration tests.\n  - ⚠️ **Note**: Test runners (Vitest, Jest, Playwright, etc.) execute an implicit build automatically before running tests. **Do NOT run a separate `pnpm build` beforehand** — this wastes time. The test scripts handle compilation and type checking internally.\n- Text snapshots of the unit tests can be updated with `pnpm test:update:unit` or via the `update-snapshots.yml` GitHub workflow. Visual screenshots are **not** committed: differences are approved on the review page of the pull request (see `docs/visual-review.md`); `pnpm snapshots:pull` fetches the current baseline for local runs.\n- Individual packages provide their own test scripts (e.g. `pnpm --filter @public-ui/components test:unit`).\n  - These also perform implicit builds, so explicit pre-build is unnecessary.\n\n## Pull Request Guidelines\n\n- PR titles should be meaningful as they appear in the release notes.\n- Every PR must link to its issue and contain only changes related to that issue.\n- Ensure automated tests pass and manual testing is completed when required.\n- Update documentation or migration guides if your changes affect them.\n",
       "kind": "doc"
     },
     {
@@ -333,7 +333,7 @@
       "group": "docs",
       "name": "CONTRIBUTING",
       "path": "CONTRIBUTING.md",
-      "code": "# Contributing\n\nWe would love for you to contribute to **KoliBri**and help make it even better than it is today! As a contributor, we ask that you follow the following guidelines:\n\n- [Contributing](#contributing)\n  - [Code of Conduct](#code-of-conduct)\n  - [Questions and problems](#questions-and-problems)\n  - [Report an error](#report-an-error)\n  - [Further development](#further-development)\n    - [Git flow](#git-flow)\n    - [Pull Request Guidelines](#pull-request-guidelines)\n    - [Developing](#developing)\n    - [Develop new component](#develop-new-component)\n    - [Switching between branches](#switching-between-branches)\n    - [Back porting to older Major-Versions](#back-porting-to-older-major-versions)\n    - [Snapshot Testing for Visual Changes](#snapshot-testing-for-visual-changes)\n      - [How to Update Snapshots](#how-to-update-snapshots)\n\n## Code of Conduct\n\nHelp us keep **KoliBri** open and inclusive. Please read and follow our [Code of Conduct](CODE_OF_CONDUCT.md).\n\n## Questions and problems\n\nPlease do not create issue tickets for general support questions. We want to use the ticket system for tracking bug reports and feature requests.\n\nInstead, we recommend first checking [Stack Overflow](https://stackoverflow.com/questions/tagged/kolibri) to see whether someone else has already solved the question or problem. You can also create new questions with the tag “hummingbird”.\nTo save your time and ours, we will close all general questions in the ticket system and redirect those asking to Stack Overflow.\n\nIf you would like to contact us, please send us an email to [kolibri@itzbund.de](mailto:kolibri@itzbund.de).\n\n## Report an error\n\nIf you find an error in the source code, you can report it to our ticket system.\n\nIt would be even better if you suggested a solution to us as a pull request.\n\n## Further development\n\nYou can request new features by submitting an issue to our ticket system. If you would like to implement a new function, please note the following steps for further action:\n\n- It is helpful to read the KoliBri [architecture concept](https://public-ui.github.io/docs/concepts/architecture) before implementing.\n- For major innovations, please create a ticket with the description of the new function.\n- For small innovations, you can offer and justify the implementation directly as a pull request.\n\n### Git flow\n\nWe work according to the Git flow: https://medium.com/android-news/gitflow-with-github-c675aa4f606a\n\n### Pull Request Guidelines\n\nWhen creating a pull request, please follow these guidelines:\n\n- **PR Title:** The pull request title must follow the [Conventional Commits](https://www.conventionalcommits.org/) specification. This is enforced by automated validation in our CI pipeline.\n- **PR Title Format:** `<type>: <description>` or `<type>(<scope>): <description>`\n- **Allowed Types:** `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `chore`, `revert`\n- **Description:** The description should start with a lowercase letter and clearly explain the change.\n\n**Examples of valid PR titles:**\n\n- `feat: add new button component`\n- `fix: resolve navigation issue on mobile devices`\n- `docs: update installation instructions`\n- `refactor(components): simplify input validation logic`\n\n**Examples of invalid PR titles:**\n\n- `Add new feature` (missing type prefix)\n- `feat: Add feature` (description should start with lowercase)\n- `feature: add new button` (invalid type, should be `feat`)\n\n### Developing\n\n1. For contributing, you need a [GitHub account](https://github.com/login)\n2. Fork [our repository](https://github.com/public-ui/kolibri) on GitHub\n3. Open your preferred command line interface\n4. Clone the forked repository via HTTPS to your local machine. The VS Code GitHub extension can handle authentication.\n5. Navigate the project root directory\n6. Create a new branch for your changes\n7. Install Node.js version 22\n8. [Install PNPM](https://pnpm.io/installation) on you local machine\n9. Install all packages with `pnpm i`\n10. Build all packages within the mono repository `pnpm -r build`\n11. Navigate to the desired package in our monorepo\n12. When you want to start the project navigate to `packages/components/` and run `pnpm dev`\n13. To watch for changes navigate to `packages/samples/react/` and execute `pnpm start`. `http://localhost:8080/` will open automatically\n\nRun ESLint across the repository with `pnpm lint` (or `pnpm lint:eslint` to invoke ESLint directly); the configuration lives in `packages/*/eslint.config.cjs`. Formatting is handled by Prettier via `pnpm format`, so run format first to keep ESLint focused on code-quality rules rather than style drift.\n\n### VS Code Setup\n\nWe recommend using [Visual Studio Code](https://code.visualstudio.com/):\n\n- Install the Prettier and ESLint extensions.\n- Enable \"Format on Save\" in your settings.\n\n### Tests\n\nAll tests run via GitHub Actions when you open a pull request. Monitor them under the **Actions** tab.\n\n### Develop new component\n\nRefer to [new component](docs/tutorials/NEW_COMPONENT.md) tutorial.\n\n### Switching between branches\n\nWhen changing the current working branch, it is important to reinstall all dependencies, as these may have changed. It is very important that all packages are built when working on dependents. This is because the packages always use the built state of the referenced packages in the mono repo.\nTo avoid unexpected problems, it is therefore always advisable to build all packages once. This can be done with these steps:\n\n- Reinstall all dependencies: `pnpm i`\n- Build all packages: `pnpm -r build`\n- You can then switch to the package to be processed and start it with `pnpm start`.\n\nIf it is also necessary to edit dependent packages such as `@public-ui/components`, these must be rebuilt for each change. Such packages offer the `dev` script for this purpose. This automatically rebuilds the package after each change.\n\n### Back porting to older Major-Versions\n\nBy default, development is carried out in the `development` branch for the following version. However, if it becomes necessary to provide an issue for an older major release, such as version 1.x.x, the code change must also be merged into the corresponding release branch. In this case, it would be the `release/1` branch. It is important that the branch that was created from the `develop` is not merged into the release branch, as otherwise the next patch version will receive all the changes from the current development status.\nThe simplest procedure is therefore to create a new branch from the release branch (e.g. `release/1`) and transfer the individual commits of the feature branch from the `develop` to the new branch using cherry-picking. This branch can then be merged into the release branch as normal with a new pull request.\n\n### Snapshot Testing for Visual Changes\n\nThe Continuous Integration (CI) pipeline incorporates automated visual regression testing using the React sample app across all available themes.\n\nWhen introducing visual modifications to components, themes, or the React sample app, initial test failures are expected. To address this, the\n`update-snapshots.yml` action on GitHub should be executed, followed by a **careful review** of the changes.\n\n#### How to Update Snapshots\n\nThe following methods can be used to update the snapshots.\n\n1. **GitHub website:** Update the snapshots directly on the GitHub website by following these steps.\n\n- Navigate to the `Actions` tab in the `kolibri` repository.\n- Execute the `03 - Update Snapshots` action.\n- Select the desired branch in which you want to update the snapshots.\n- The workflow checks out the branch, updates all snapshot files, and commits the changes to that branch.\n\n2. **Terminal Command:** Use the [GitHub CLI (gh)](https://cli.github.com/) to run the `update-snapshots.yml` action from the local terminal. This method is recommended for updating snapshots on the current branch without navigating to the GitHub website. For terminal convenience, the [GitHub CLI (gh)](https://cli.github.com/) needs to be installed.\n\n- Run the following command within the project directory to update the snapshots in your checked-out branch:\n  ```bash\n  gh workflow run update-snapshots.yml -r `git rev-parse --abbrev-ref HEAD`\n  ```\n- If your want to delete all snapshots before regenerating them add `-f purge_snapshots=true` to the command:\n  ```bash\n  gh workflow run update-snapshots.yml -r `git rev-parse --abbrev-ref HEAD` -f purge_snapshots=true\n  ```\n- You can also run the action on a different branch by specifying the another target branch with the `-r <branch_name>` flag. For example, to update snapshots on the `main` branch:\n  ```bash\n  gh workflow run update-snapshots.yml -r main\n  ```\n\nThese steps ensure that visual snapshots are updated systematically, maintaining the integrity of the testing process.\n",
+      "code": "# Contributing\n\nWe would love for you to contribute to **KoliBri**and help make it even better than it is today! As a contributor, we ask that you follow the following guidelines:\n\n- [Contributing](#contributing)\n  - [Code of Conduct](#code-of-conduct)\n  - [Questions and problems](#questions-and-problems)\n  - [Report an error](#report-an-error)\n  - [Further development](#further-development)\n    - [Git flow](#git-flow)\n    - [Pull Request Guidelines](#pull-request-guidelines)\n    - [Developing](#developing)\n    - [Develop new component](#develop-new-component)\n    - [Switching between branches](#switching-between-branches)\n    - [Back porting to older Major-Versions](#back-porting-to-older-major-versions)\n    - [Snapshot Testing for Visual Changes](#snapshot-testing-for-visual-changes)\n      - [How to Update Snapshots](#how-to-update-snapshots)\n\n## Code of Conduct\n\nHelp us keep **KoliBri** open and inclusive. Please read and follow our [Code of Conduct](CODE_OF_CONDUCT.md).\n\n## Questions and problems\n\nPlease do not create issue tickets for general support questions. We want to use the ticket system for tracking bug reports and feature requests.\n\nInstead, we recommend first checking [Stack Overflow](https://stackoverflow.com/questions/tagged/kolibri) to see whether someone else has already solved the question or problem. You can also create new questions with the tag “hummingbird”.\nTo save your time and ours, we will close all general questions in the ticket system and redirect those asking to Stack Overflow.\n\nIf you would like to contact us, please send us an email to [kolibri@itzbund.de](mailto:kolibri@itzbund.de).\n\n## Report an error\n\nIf you find an error in the source code, you can report it to our ticket system.\n\nIt would be even better if you suggested a solution to us as a pull request.\n\n## Further development\n\nYou can request new features by submitting an issue to our ticket system. If you would like to implement a new function, please note the following steps for further action:\n\n- It is helpful to read the KoliBri [architecture concept](https://public-ui.github.io/docs/concepts/architecture) before implementing.\n- For major innovations, please create a ticket with the description of the new function.\n- For small innovations, you can offer and justify the implementation directly as a pull request.\n\n### Git flow\n\nWe work according to the Git flow: https://medium.com/android-news/gitflow-with-github-c675aa4f606a\n\n### Pull Request Guidelines\n\nWhen creating a pull request, please follow these guidelines:\n\n- **PR Title:** The pull request title must follow the [Conventional Commits](https://www.conventionalcommits.org/) specification. This is enforced by automated validation in our CI pipeline.\n- **PR Title Format:** `<type>: <description>` or `<type>(<scope>): <description>`\n- **Allowed Types:** `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `chore`, `revert`\n- **Description:** The description should start with a lowercase letter and clearly explain the change.\n\n**Examples of valid PR titles:**\n\n- `feat: add new button component`\n- `fix: resolve navigation issue on mobile devices`\n- `docs: update installation instructions`\n- `refactor(components): simplify input validation logic`\n\n**Examples of invalid PR titles:**\n\n- `Add new feature` (missing type prefix)\n- `feat: Add feature` (description should start with lowercase)\n- `feature: add new button` (invalid type, should be `feat`)\n\n### Developing\n\n1. For contributing, you need a [GitHub account](https://github.com/login)\n2. Fork [our repository](https://github.com/public-ui/kolibri) on GitHub\n3. Open your preferred command line interface\n4. Clone the forked repository via HTTPS to your local machine. The VS Code GitHub extension can handle authentication.\n5. Navigate the project root directory\n6. Create a new branch for your changes\n7. Install Node.js version 22\n8. [Install PNPM](https://pnpm.io/installation) on you local machine\n9. Install all packages with `pnpm i`\n10. Build all packages within the mono repository `pnpm -r build`\n11. Navigate to the desired package in our monorepo\n12. When you want to start the project navigate to `packages/components/` and run `pnpm dev`\n13. To watch for changes navigate to `packages/samples/react/` and execute `pnpm start`. `http://localhost:8080/` will open automatically\n\nRun ESLint across the repository with `pnpm lint` (or `pnpm lint:eslint` to invoke ESLint directly); the configuration lives in `packages/*/eslint.config.cjs`. Formatting is handled by Prettier via `pnpm format`, so run format first to keep ESLint focused on code-quality rules rather than style drift.\n\n### VS Code Setup\n\nWe recommend using [Visual Studio Code](https://code.visualstudio.com/):\n\n- Install the Prettier and ESLint extensions.\n- Enable \"Format on Save\" in your settings.\n\n### Tests\n\nAll tests run via GitHub Actions when you open a pull request. Monitor them under the **Actions** tab.\n\n### Develop new component\n\nRefer to [new component](docs/tutorials/NEW_COMPONENT.md) tutorial.\n\n### Switching between branches\n\nWhen changing the current working branch, it is important to reinstall all dependencies, as these may have changed. It is very important that all packages are built when working on dependents. This is because the packages always use the built state of the referenced packages in the mono repo.\nTo avoid unexpected problems, it is therefore always advisable to build all packages once. This can be done with these steps:\n\n- Reinstall all dependencies: `pnpm i`\n- Build all packages: `pnpm -r build`\n- You can then switch to the package to be processed and start it with `pnpm start`.\n\nIf it is also necessary to edit dependent packages such as `@public-ui/components`, these must be rebuilt for each change. Such packages offer the `dev` script for this purpose. This automatically rebuilds the package after each change.\n\n### Back porting to older Major-Versions\n\nBy default, development is carried out in the `development` branch for the following version. However, if it becomes necessary to provide an issue for an older major release, such as version 1.x.x, the code change must also be merged into the corresponding release branch. In this case, it would be the `release/1` branch. It is important that the branch that was created from the `develop` is not merged into the release branch, as otherwise the next patch version will receive all the changes from the current development status.\nThe simplest procedure is therefore to create a new branch from the release branch (e.g. `release/1`) and transfer the individual commits of the feature branch from the `develop` to the new branch using cherry-picking. This branch can then be merged into the release branch as normal with a new pull request.\n\n### Visual Review for Visual Changes\n\nThe Continuous Integration (CI) pipeline takes screenshots of the React sample app in every theme and compares them with the baseline of the base branch. The screenshots are **not** stored in git: every push to `develop`, `main` and `release/*` publishes them as the artifact `visual-baseline-<package>`, and a pull request compares against the artifact of the commit it is merged with.\n\nWhen you introduce visual modifications to components, themes or the React sample app:\n\n1. The `visual-tests (<package>)` jobs report the differences. That is expected – there is nothing to regenerate or commit.\n2. The bot comment **📸 Visual Review** on the pull request links the review page (`https://public-ui.github.io/kolibri/visual/?pr=<number>`), where every changed, added and removed screenshot can be inspected side by side, with a slider, as onion skin or as diff.\n3. A reviewer with write access approves (or rejects) the screenshots there – directly with a fine-grained GitHub token, or by pasting the generated comment on the pull request. The commit status **Visual Review** turns green once everything is approved; approvals are bound to the screenshot content and survive later pushes that do not change the screenshot again.\n\nThe full process is described in [docs/visual-review.md](docs/visual-review.md).\n\n#### Running the visual tests locally\n\n```bash\npnpm snapshots:pull                          # download the current develop baseline into the snapshot folders (needs `gh auth login`)\npnpm --filter @public-ui/theme-default test  # compare; the result is written to packages/themes/default/visual-report/\npnpm test:update:docker default              # regenerate a baseline locally in the pinned Playwright container\n```\n\nScreenshots are platform specific (font rendering), so only the Docker variant produces files that match the CI.\n\n#### Text snapshots of the unit tests\n\nThe `__snapshots__` files of the unit tests (components, hydrate, hydrate-server) stay in git. Update them with `pnpm test:update:unit`, or run the `03 - Update Snapshots` action on your branch:\n\n```bash\ngh workflow run update-snapshots.yml -r `git rev-parse --abbrev-ref HEAD`\n```\n",
       "kind": "doc"
     },
     {
@@ -509,7 +509,7 @@
       "group": "docs",
       "name": "visual-review",
       "path": "docs/visual-review.md",
-      "code": "# Visual Review\n\nHow screenshot changes of the KoliBri themes are detected, published and approved.\n\n## In one picture\n\n```\npush to develop ──► Visual Baseline workflow ──► artifact visual-baseline-<package> (per commit, 90 days)\n\npull request push ──► CI-Pipeline, job visual-tests (<package>)\n                        compares against the baseline of the base commit\n                        ──► artifact visual-review-<package> (report.json + changed images)\n                                  │\n                                  ▼\n                       Visual Review workflow (base repository context)\n                         publishes visual/pr-<n>/ on GitHub Pages\n                         reads the reviewers' comments\n                         sets the commit status \"Visual Review\"\n                                  │\n                                  ▼\nreviewer ──► https://public-ui.github.io/kolibri/visual/?pr=<n>\n               inspects baseline / actual / diff, approves or rejects, leaves notes\n               saves the review as a pull-request comment (directly with a token, or by pasting it)\n```\n\n## What a contributor sees\n\n- The job `visual-tests (<package>)` of the CI-Pipeline fails when screenshots differ – that is\n  expected and not something to \"fix\" by regenerating snapshots. The job summary lists what changed.\n- The bot comment **📸 Visual Review** on the pull request links the review page and shows the counts\n  per package.\n- The commit status **Visual Review** stays `pending` until a reviewer with write access approved every\n  changed, added and removed screenshot, turns `success` then, and `failure` when a screenshot was\n  rejected or a route could not be compared at all (missing block, timeout).\n- Docs-only pull requests get `success` immediately; nothing to review.\n\nNothing has to be committed: the baseline is regenerated from `develop` after the merge.\n\n## What a reviewer does\n\n1. Open the review page from the bot comment (or the status link).\n2. Walk through the changed, added and removed snapshots (`j`/`k` or the list). Compare with\n   _side by side_, _slider_, _onion skin_, _diff_ or _blink_; zoom in for subpixel changes.\n3. Approve (`a`), reject or annotate each one – or **Approve all open changes** for an intentional\n   sweep such as a browser upgrade.\n4. Save the review:\n   - **with a token**: enter a fine-grained personal access token with _Pull requests: read and write_\n     for `public-ui/kolibri` at the bottom of the page. The page posts (and later edits) one comment\n     in your name. The token stays in this browser session unless you tick \"remember\".\n   - **without a token**: click _Copy comment for the pull request_ and paste it as a comment on the\n     pull request.\n\nThe comment carries a machine-readable block, for example:\n\n```markdown\n<!-- visual-review:v1\n{\"approveAll\":{\"digest\":\"sha256:…\"},\"approvals\":[{\"item\":\"theme-default/button-basic--variants\",\"hash\":\"sha256:…\"}],\"rejects\":[],\"notes\":[]}\n-->\n\n**Visual Review** – all changes approved ([review page](…))\n```\n\nApprovals bind to the **content hash** of a screenshot, not to a commit: a later push that leaves an\napproved screenshot untouched keeps its approval, a push that changes it again reopens exactly that\none. `approveAll` binds to the digest of the whole report and therefore expires with the next change.\n\nOnly comments of users with write access count. Bots are ignored. A rejection wins over an approval.\n\n## Where things live\n\n| What                             | Where                                                                                 |\n| -------------------------------- | ------------------------------------------------------------------------------------- |\n| Report per package (CI artifact) | `visual-review-<package>` – `report.json` + PNGs of changed items, 14 days            |\n| Baseline per base commit         | `visual-baseline-<package>` – snapshots + `meta.json`, 90 days                        |\n| Published review data            | `gh-pages`: `visual/pr-<n>/report.json`, `status.json`, `<package>/<name>.<kind>.png` |\n| Review page                      | `gh-pages`: `visual/` (built from `packages/tools/visual-tests/review-ui`)            |\n| Reporter                         | `packages/tools/visual-tests/src/visual-reporter.js`                                  |\n| Workflow scripts                 | `scripts/visual-review/` (see `scripts/README.md`)                                    |\n| Workflows                        | `visual-baseline.yml`, `visual-review.yml`, `visual-review-ui.yml`, job in `ci.yml`   |\n\nThe folder `visual/pr-<n>/` is removed when the pull request closes (`pr-preview-cleanup.yml`).\n\n## Trust boundary\n\nThe reports come from the pull request's own CI run, i.e. from code the pull request controls. The\nVisual Review workflow never executes that code: it downloads the artifacts, validates every field and\nfile name (`merge-reports.mjs`) and publishes only what passes. A pull request could still upload a\nreport that claims \"no changes\" – the human review of the code and the branch protection remain the\nactual safeguard; the visual review makes intentional changes visible and reviewable, it does not\nreplace code review.\n\n## Local work\n\n```bash\npnpm snapshots:pull                        # fetch the current develop baseline into the snapshot folders\npnpm --filter @public-ui/theme-default test\npnpm --filter @public-ui/visual-tests review-ui:dev   # the review page against a local report: ?src=<folder>\n```\n\n`pnpm test:update:docker <theme>` regenerates a baseline locally in the pinned Playwright container.\n",
+      "code": "# Visual Review\n\nHow screenshot changes of the KoliBri themes are detected, published and approved.\n\n## In one picture\n\n```\npush to develop ──► Visual Baseline workflow ──► artifact visual-baseline-<package> (per commit, 90 days)\n\npull request push ──► CI-Pipeline, job visual-tests (<package>)\n                        compares against the baseline of the base commit\n                        ──► artifact visual-review-<package> (report.json + changed images)\n                                  │\n                                  ▼\n                       Visual Review workflow (base repository context)\n                         publishes visual/pr-<n>/ on GitHub Pages\n                         reads the reviewers' comments\n                         sets the commit status \"Visual Review\"\n                                  │\n                                  ▼\nreviewer ──► https://public-ui.github.io/kolibri/visual/?pr=<n>\n               inspects baseline / actual / diff, approves or rejects, leaves notes\n               saves the review as a pull-request comment (directly with a token, or by pasting it)\n```\n\n## What a contributor sees\n\n- The job `visual-tests (<package>)` of the CI-Pipeline fails when screenshots differ – that is\n  expected and not something to \"fix\" by regenerating snapshots. The job summary lists what changed.\n- The bot comment **📸 Visual Review** on the pull request links the review page and shows the counts\n  per package.\n- The commit status **Visual Review** stays `pending` until a reviewer with write access approved every\n  changed, added and removed screenshot, turns `success` then, and `failure` when a screenshot was\n  rejected or a route could not be compared at all (missing block, timeout).\n- Docs-only pull requests get `success` immediately; nothing to review.\n\nNothing has to be committed: the baseline is regenerated from `develop` after the merge.\n\n## What a reviewer does\n\n1. Open the review page from the bot comment (or the status link).\n2. Walk through the changed, added and removed snapshots (`j`/`k` or the list). Compare with\n   _side by side_, _slider_, _onion skin_, _diff_ or _blink_; zoom in for subpixel changes.\n3. Approve (`a`), reject or annotate each one – or **Approve all open changes** for an intentional\n   sweep such as a browser upgrade.\n4. Save the review:\n   - **with a token**: enter a fine-grained personal access token with _Pull requests: read and write_\n     for `public-ui/kolibri` at the bottom of the page. The page posts (and later edits) one comment\n     in your name. The token stays in this browser session unless you tick \"remember\".\n   - **without a token**: click _Copy comment for the pull request_ and paste it as a comment on the\n     pull request. To change your verdict later, edit that comment or post a new one – only your\n     newest comment counts.\n\nThe comment carries a machine-readable block, for example:\n\n```markdown\n<!-- visual-review:v1\n{\"approveAll\":{\"digest\":\"sha256:…\"},\"approvals\":[{\"item\":\"theme-default/button-basic--variants\",\"hash\":\"sha256:…\"}],\"rejects\":[],\"notes\":[]}\n-->\n\n**Visual Review** – all changes approved ([review page](…))\n```\n\nApprovals bind to the **content hash** of a screenshot, not to a commit: a later push that leaves an\napproved screenshot untouched keeps its approval, a push that changes it again reopens exactly that\none. `approveAll` binds to the digest of the whole report and therefore expires with the next change.\n\nOnly comments of users with write access count. Bots are ignored. A rejection wins over an approval.\n\n## Where things live\n\n| What                             | Where                                                                                 |\n| -------------------------------- | ------------------------------------------------------------------------------------- |\n| Report per package (CI artifact) | `visual-review-<package>` – `report.json` + PNGs of changed items, 14 days            |\n| Baseline per base commit         | `visual-baseline-<package>` – snapshots + `meta.json`, 90 days                        |\n| Published review data            | `gh-pages`: `visual/pr-<n>/report.json`, `status.json`, `<package>/<name>.<kind>.png` |\n| Review page                      | `gh-pages`: `visual/` (built from `packages/tools/visual-tests/review-ui`)            |\n| Reporter                         | `packages/tools/visual-tests/src/visual-reporter.js`                                  |\n| Workflow scripts                 | `scripts/visual-review/` (see `scripts/README.md`)                                    |\n| Workflows                        | `visual-baseline.yml`, `visual-review.yml`, `visual-review-ui.yml`, job in `ci.yml`   |\n\nThe folder `visual/pr-<n>/` is removed when the pull request closes (`pr-preview-cleanup.yml`).\n\n## Trust boundary\n\nThe reports come from the pull request's own CI run, i.e. from code the pull request controls. The\nVisual Review workflow never executes that code: it downloads the artifacts, validates every field and\nfile name (`merge-reports.mjs`) and publishes only what passes. A pull request could still upload a\nreport that claims \"no changes\" – the human review of the code and the branch protection remain the\nactual safeguard; the visual review makes intentional changes visible and reviewable, it does not\nreplace code review.\n\n## Local work\n\n```bash\npnpm snapshots:pull                        # fetch the current develop baseline into the snapshot folders\npnpm --filter @public-ui/theme-default test\npnpm --filter @public-ui/visual-tests review-ui:dev   # the review page against a local report: ?src=<folder>\n```\n\n`pnpm test:update:docker <theme>` regenerates a baseline locally in the pinned Playwright container.\n",
       "kind": "doc"
     },
     {

package/shared/template-index.json

@@ -18,7 +18,7 @@
     "stats": {
       "size": 9600,
       "lines": 246,
-      "lastModified": "2026-09-07T13:50:47.899Z"
+      "lastModified": "2026-09-09T07:07:14.860Z"
     }
   },
   {
@@ -40,7 +40,7 @@
     "stats": {
       "size": 3486,
       "lines": 75,
-      "lastModified": "2026-09-07T13:50:47.899Z"
+      "lastModified": "2026-09-09T07:07:14.860Z"
     }
   },
   {
@@ -62,7 +62,7 @@
     "stats": {
       "size": 2425,
       "lines": 98,
-      "lastModified": "2026-09-07T13:50:47.935Z"
+      "lastModified": "2026-09-09T07:07:14.897Z"
     }
   },
   {
@@ -84,7 +84,7 @@
     "stats": {
       "size": 50,
       "lines": 4,
-      "lastModified": "2026-09-07T13:50:47.935Z"
+      "lastModified": "2026-09-09T07:07:14.897Z"
     }
   },
   {
@@ -106,7 +106,7 @@
     "stats": {
       "size": 1549,
       "lines": 35,
-      "lastModified": "2026-09-07T13:50:47.934Z"
+      "lastModified": "2026-09-09T07:07:14.896Z"
     }
   },
   {
@@ -128,7 +128,7 @@
     "stats": {
       "size": 182,
       "lines": 8,
-      "lastModified": "2026-09-07T13:50:47.931Z"
+      "lastModified": "2026-09-09T07:07:14.892Z"
     }
   },
   {
@@ -150,7 +150,7 @@
     "stats": {
       "size": 4276,
       "lines": 75,
-      "lastModified": "2026-09-07T13:50:47.922Z"
+      "lastModified": "2026-09-09T07:07:14.884Z"
     }
   },
   {
@@ -172,7 +172,7 @@
     "stats": {
       "size": 2812,
       "lines": 74,
-      "lastModified": "2026-09-07T13:50:47.915Z"
+      "lastModified": "2026-09-09T07:07:14.876Z"
     }
   },
   {
@@ -194,7 +194,7 @@
     "stats": {
       "size": 587,
       "lines": 56,
-      "lastModified": "2026-09-07T13:50:47.912Z"
+      "lastModified": "2026-09-09T07:07:14.873Z"
     }
   },
   {
@@ -216,7 +216,7 @@
     "stats": {
       "size": 566,
       "lines": 50,
-      "lastModified": "2026-09-07T13:50:47.910Z"
+      "lastModified": "2026-09-09T07:07:14.872Z"
     }
   },
   {
@@ -238,7 +238,7 @@
     "stats": {
       "size": 568,
       "lines": 50,
-      "lastModified": "2026-09-07T13:50:47.909Z"
+      "lastModified": "2026-09-09T07:07:14.870Z"
     }
   },
   {
@@ -260,7 +260,7 @@
     "stats": {
       "size": 601,
       "lines": 45,
-      "lastModified": "2026-09-07T13:50:47.902Z"
+      "lastModified": "2026-09-09T07:07:14.864Z"
     }
   },
   {
@@ -282,7 +282,7 @@
     "stats": {
       "size": 587,
       "lines": 56,
-      "lastModified": "2026-09-07T13:50:47.903Z"
+      "lastModified": "2026-09-09T07:07:14.865Z"
     }
   },
   {
@@ -304,7 +304,7 @@
     "stats": {
       "size": 566,
       "lines": 50,
-      "lastModified": "2026-09-07T13:50:47.901Z"
+      "lastModified": "2026-09-09T07:07:14.862Z"
     }
   },
   {
@@ -326,7 +326,7 @@
     "stats": {
       "size": 615,
       "lines": 50,
-      "lastModified": "2026-09-07T13:50:47.900Z"
+      "lastModified": "2026-09-09T07:07:14.861Z"
     }
   },
   {
@@ -348,7 +348,7 @@
     "stats": {
       "size": 31,
       "lines": 2,
-      "lastModified": "2026-09-07T13:50:47.920Z"
+      "lastModified": "2026-09-09T07:07:14.881Z"
     }
   },
   {
@@ -370,7 +370,7 @@
     "stats": {
       "size": 31,
       "lines": 2,
-      "lastModified": "2026-09-07T13:50:47.919Z"
+      "lastModified": "2026-09-09T07:07:14.881Z"
     }
   },
   {
@@ -392,7 +392,7 @@
     "stats": {
       "size": 25,
       "lines": 2,
-      "lastModified": "2026-09-07T13:50:47.917Z"
+      "lastModified": "2026-09-09T07:07:14.878Z"
     }
   },
   {
@@ -414,7 +414,7 @@
     "stats": {
       "size": 327,
       "lines": 19,
-      "lastModified": "2026-09-07T13:50:47.915Z"
+      "lastModified": "2026-09-09T07:07:14.877Z"
     }
   },
   {
@@ -436,7 +436,7 @@
     "stats": {
       "size": 416,
       "lines": 2,
-      "lastModified": "2026-09-07T13:50:47.910Z"
+      "lastModified": "2026-09-09T07:07:14.871Z"
     }
   },
   {
@@ -458,7 +458,7 @@
     "stats": {
       "size": 416,
       "lines": 2,
-      "lastModified": "2026-09-07T13:50:47.902Z"
+      "lastModified": "2026-09-09T07:07:14.863Z"
     }
   },
   {
@@ -481,7 +481,7 @@
     "stats": {
       "size": 88,
       "lines": 6,
-      "lastModified": "2026-09-07T13:50:47.931Z"
+      "lastModified": "2026-09-09T07:07:14.892Z"
     }
   },
   {
@@ -503,7 +503,7 @@
     "stats": {
       "size": 0,
       "lines": 1,
-      "lastModified": "2026-09-07T13:50:47.918Z"
+      "lastModified": "2026-09-09T07:07:14.879Z"
     }
   },
   {
@@ -525,7 +525,7 @@
     "stats": {
       "size": 0,
       "lines": 1,
-      "lastModified": "2026-09-07T13:50:47.918Z"
+      "lastModified": "2026-09-09T07:07:14.880Z"
     }
   },
   {
@@ -547,7 +547,7 @@
     "stats": {
       "size": 21,
       "lines": 2,
-      "lastModified": "2026-09-07T13:50:47.918Z"
+      "lastModified": "2026-09-09T07:07:14.879Z"
     }
   },
   {
@@ -569,7 +569,7 @@
     "stats": {
       "size": 23,
       "lines": 2,
-      "lastModified": "2026-09-07T13:50:47.918Z"
+      "lastModified": "2026-09-09T07:07:14.879Z"
     }
   },
   {
@@ -591,7 +591,7 @@
     "stats": {
       "size": 25,
       "lines": 2,
-      "lastModified": "2026-09-07T13:50:47.917Z"
+      "lastModified": "2026-09-09T07:07:14.879Z"
     }
   },
   {
@@ -613,7 +613,7 @@
     "stats": {
       "size": 220,
       "lines": 20,
-      "lastModified": "2026-09-07T13:50:47.919Z"
+      "lastModified": "2026-09-09T07:07:14.880Z"
     }
   },
   {
@@ -635,7 +635,7 @@
     "stats": {
       "size": 587,
       "lines": 56,
-      "lastModified": "2026-09-07T13:50:48.305Z"
+      "lastModified": "2026-09-09T07:07:15.233Z"
     }
   },
   {
@@ -658,7 +658,7 @@
     "stats": {
       "size": 472,
       "lines": 14,
-      "lastModified": "2026-09-07T13:50:48.311Z"
+      "lastModified": "2026-09-09T07:07:15.245Z"
     }
   },
   {
@@ -681,7 +681,7 @@
     "stats": {
       "size": 35,
       "lines": 4,
-      "lastModified": "2026-09-07T13:50:48.311Z"
+      "lastModified": "2026-09-09T07:07:15.245Z"
     }
   },
   {
@@ -704,7 +704,7 @@
     "stats": {
       "size": 43,
       "lines": 2,
-      "lastModified": "2026-09-07T13:50:48.311Z"
+      "lastModified": "2026-09-09T07:07:15.245Z"
     }
   },
   {
@@ -727,7 +727,7 @@
     "stats": {
       "size": 916,
       "lines": 39,
-      "lastModified": "2026-09-07T13:50:48.311Z"
+      "lastModified": "2026-09-09T07:07:15.245Z"
     }
   },
   {
@@ -750,7 +750,7 @@
     "stats": {
       "size": 368,
       "lines": 13,
-      "lastModified": "2026-09-07T13:50:48.311Z"
+      "lastModified": "2026-09-09T07:07:15.245Z"
     }
   },
   {
@@ -773,7 +773,7 @@
     "stats": {
       "size": 97,
       "lines": 5,
-      "lastModified": "2026-09-07T13:50:48.311Z"
+      "lastModified": "2026-09-09T07:07:15.245Z"
     }
   },
   {
@@ -796,7 +796,7 @@
     "stats": {
       "size": 2358,
       "lines": 44,
-      "lastModified": "2026-09-07T13:50:48.311Z"
+      "lastModified": "2026-09-09T07:07:15.245Z"
     }
   },
   {
@@ -819,7 +819,7 @@
     "stats": {
       "size": 9997,
       "lines": 367,
-      "lastModified": "2026-09-07T13:50:48.309Z"
+      "lastModified": "2026-09-09T07:07:15.240Z"
     }
   },
   {
@@ -842,7 +842,7 @@
     "stats": {
       "size": 1199,
       "lines": 34,
-      "lastModified": "2026-09-07T13:50:48.309Z"
+      "lastModified": "2026-09-09T07:07:15.240Z"
     }
   },
   {
@@ -865,7 +865,7 @@
     "stats": {
       "size": 10353,
       "lines": 555,
-      "lastModified": "2026-09-07T13:50:48.308Z"
+      "lastModified": "2026-09-09T07:07:15.240Z"
     }
   },
   {
@@ -888,7 +888,7 @@
     "stats": {
       "size": 646,
       "lines": 21,
-      "lastModified": "2026-09-07T13:50:48.311Z"
+      "lastModified": "2026-09-09T07:07:15.244Z"
     }
   },
   {
@@ -911,7 +911,7 @@
     "stats": {
       "size": 519,
       "lines": 19,
-      "lastModified": "2026-09-07T13:50:48.311Z"
+      "lastModified": "2026-09-09T07:07:15.244Z"
     }
   },
   {
@@ -934,7 +934,7 @@
     "stats": {
       "size": 670,
       "lines": 22,
-      "lastModified": "2026-09-07T13:50:48.310Z"
+      "lastModified": "2026-09-09T07:07:15.243Z"
     }
   },
   {
@@ -957,7 +957,7 @@
     "stats": {
       "size": 3451,
       "lines": 9,
-      "lastModified": "2026-09-07T13:50:48.310Z"
+      "lastModified": "2026-09-09T07:07:15.242Z"
     }
   },
   {
@@ -980,7 +980,7 @@
     "stats": {
       "size": 10313,
       "lines": 46,
-      "lastModified": "2026-09-07T13:50:48.310Z"
+      "lastModified": "2026-09-09T07:07:15.242Z"
     }
   },
   {
@@ -1003,7 +1003,7 @@
     "stats": {
       "size": 107635,
       "lines": 364,
-      "lastModified": "2026-09-07T13:50:48.310Z"
+      "lastModified": "2026-09-09T07:07:15.242Z"
     }
   },
   {
@@ -1026,7 +1026,7 @@
     "stats": {
       "size": 64024,
       "lines": 323,
-      "lastModified": "2026-09-07T13:50:48.310Z"
+      "lastModified": "2026-09-09T07:07:15.242Z"
     }
   },
   {
@@ -1049,7 +1049,7 @@
     "stats": {
       "size": 23737,
       "lines": 110,
-      "lastModified": "2026-09-07T13:50:48.310Z"
+      "lastModified": "2026-09-09T07:07:15.242Z"
     }
   },
   {
@@ -1072,7 +1072,7 @@
     "stats": {
       "size": 18200,
       "lines": 75,
-      "lastModified": "2026-09-07T13:50:48.310Z"
+      "lastModified": "2026-09-09T07:07:15.242Z"
     }
   },
   {
@@ -1095,7 +1095,7 @@
     "stats": {
       "size": 12909,
       "lines": 87,
-      "lastModified": "2026-09-07T13:50:48.310Z"
+      "lastModified": "2026-09-09T07:07:15.242Z"
     }
   },
   {
@@ -1118,7 +1118,7 @@
     "stats": {
       "size": 19632,
       "lines": 75,
-      "lastModified": "2026-09-07T13:50:48.310Z"
+      "lastModified": "2026-09-09T07:07:15.242Z"
     }
   },
   {
@@ -1141,7 +1141,7 @@
     "stats": {
       "size": 8806,
       "lines": 38,
-      "lastModified": "2026-09-07T13:50:48.310Z"
+      "lastModified": "2026-09-09T07:07:15.242Z"
     }
   },
   {
@@ -1164,7 +1164,7 @@
     "stats": {
       "size": 103382,
       "lines": 377,
-      "lastModified": "2026-09-07T13:50:48.310Z"
+      "lastModified": "2026-09-09T07:07:15.242Z"
     }
   },
   {
@@ -1187,7 +1187,7 @@
     "stats": {
       "size": 3703,
       "lines": 21,
-      "lastModified": "2026-09-07T13:50:48.310Z"
+      "lastModified": "2026-09-09T07:07:15.242Z"
     }
   },
   {
@@ -1210,7 +1210,7 @@
     "stats": {
       "size": 35770,
       "lines": 74,
-      "lastModified": "2026-09-07T13:50:48.309Z"
+      "lastModified": "2026-09-09T07:07:15.240Z"
     }
   },
   {
@@ -1233,7 +1233,7 @@
     "stats": {
       "size": 2763,
       "lines": 89,
-      "lastModified": "2026-09-07T13:50:48.311Z"
+      "lastModified": "2026-09-09T07:07:15.245Z"
     }
   },
   {
@@ -1256,7 +1256,7 @@
     "stats": {
       "size": 1234,
       "lines": 48,
-      "lastModified": "2026-09-07T13:50:48.311Z"
+      "lastModified": "2026-09-09T07:07:15.245Z"
     }
   },
   {
@@ -1279,7 +1279,7 @@
     "stats": {
       "size": 897,
       "lines": 36,
-      "lastModified": "2026-09-07T13:50:48.311Z"
+      "lastModified": "2026-09-09T07:07:15.245Z"
     }
   },
   {
@@ -1302,7 +1302,7 @@
     "stats": {
       "size": 881,
       "lines": 34,
-      "lastModified": "2026-09-07T13:50:48.311Z"
+      "lastModified": "2026-09-09T07:07:15.245Z"
     }
   },
   {
@@ -1325,7 +1325,7 @@
     "stats": {
       "size": 1587,
       "lines": 56,
-      "lastModified": "2026-09-07T13:50:48.311Z"
+      "lastModified": "2026-09-09T07:07:15.245Z"
     }
   },
   {
@@ -1348,7 +1348,7 @@
     "stats": {
       "size": 1226,
       "lines": 49,
-      "lastModified": "2026-09-07T13:50:48.311Z"
+      "lastModified": "2026-09-09T07:07:15.245Z"
     }
   },
   {
@@ -1371,7 +1371,7 @@
     "stats": {
       "size": 1446,
       "lines": 57,
-      "lastModified": "2026-09-07T13:50:48.311Z"
+      "lastModified": "2026-09-09T07:07:15.244Z"
     }
   },
   {
@@ -1394,7 +1394,7 @@
     "stats": {
       "size": 293,
       "lines": 13,
-      "lastModified": "2026-09-07T13:50:48.311Z"
+      "lastModified": "2026-09-09T07:07:15.245Z"
     }
   },
   {
@@ -1417,7 +1417,7 @@
     "stats": {
       "size": 453,
       "lines": 21,
-      "lastModified": "2026-09-07T13:50:48.311Z"
+      "lastModified": "2026-09-09T07:07:15.245Z"
     }
   },
   {
@@ -1440,7 +1440,7 @@
     "stats": {
       "size": 149,
       "lines": 7,
-      "lastModified": "2026-09-07T13:50:48.311Z"
+      "lastModified": "2026-09-09T07:07:15.245Z"
     }
   },
   {
@@ -1463,7 +1463,7 @@
     "stats": {
       "size": 3978,
       "lines": 140,
-      "lastModified": "2026-09-07T13:50:48.714Z"
+      "lastModified": "2026-09-09T07:07:15.625Z"
     }
   },
   {
@@ -1486,7 +1486,7 @@
     "stats": {
       "size": 4209,
       "lines": 140,
-      "lastModified": "2026-09-07T13:50:48.714Z"
+      "lastModified": "2026-09-09T07:07:15.625Z"
     }
   },
   {
@@ -1509,7 +1509,7 @@
     "stats": {
       "size": 9615,
       "lines": 318,
-      "lastModified": "2026-09-07T13:50:48.714Z"
+      "lastModified": "2026-09-09T07:07:15.625Z"
     }
   },
   {
@@ -1532,7 +1532,7 @@
     "stats": {
       "size": 14891,
       "lines": 466,
-      "lastModified": "2026-09-07T13:50:48.714Z"
+      "lastModified": "2026-09-09T07:07:15.625Z"
     }
   },
   {
@@ -1556,7 +1556,7 @@
     "stats": {
       "size": 350,
       "lines": 12,
-      "lastModified": "2026-09-07T13:50:48.745Z"
+      "lastModified": "2026-09-09T07:07:15.654Z"
     }
   },
   {
@@ -1580,7 +1580,7 @@
     "stats": {
       "size": 77,
       "lines": 5,
-      "lastModified": "2026-09-07T13:50:48.745Z"
+      "lastModified": "2026-09-09T07:07:15.654Z"
     }
   },
   {
@@ -1604,7 +1604,7 @@
     "stats": {
       "size": 720,
       "lines": 44,
-      "lastModified": "2026-09-07T13:50:48.745Z"
+      "lastModified": "2026-09-09T07:07:15.654Z"
     }
   },
   {
@@ -1628,7 +1628,7 @@
     "stats": {
       "size": 7031,
       "lines": 276,
-      "lastModified": "2026-09-07T13:50:48.745Z"
+      "lastModified": "2026-09-09T07:07:15.654Z"
     }
   },
   {
@@ -1652,7 +1652,7 @@
     "stats": {
       "size": 313,
       "lines": 18,
-      "lastModified": "2026-09-07T13:50:48.745Z"
+      "lastModified": "2026-09-09T07:07:15.654Z"
     }
   },
   {
@@ -1676,7 +1676,7 @@
     "stats": {
       "size": 92,
       "lines": 6,
-      "lastModified": "2026-09-07T13:50:48.745Z"
+      "lastModified": "2026-09-09T07:07:15.654Z"
     }
   },
   {
@@ -1700,7 +1700,7 @@
     "stats": {
       "size": 94,
       "lines": 6,
-      "lastModified": "2026-09-07T13:50:48.745Z"
+      "lastModified": "2026-09-09T07:07:15.654Z"
     }
   },
   {
@@ -1724,7 +1724,7 @@
     "stats": {
       "size": 120,
       "lines": 8,
-      "lastModified": "2026-09-07T13:50:48.714Z"
+      "lastModified": "2026-09-09T07:07:15.625Z"
     }
   },
   {
@@ -1747,7 +1747,7 @@
     "stats": {
       "size": 818,
       "lines": 32,
-      "lastModified": "2026-09-07T13:50:48.746Z"
+      "lastModified": "2026-09-09T07:07:15.654Z"
     }
   },
   {
@@ -1770,7 +1770,7 @@
     "stats": {
       "size": 3041,
       "lines": 90,
-      "lastModified": "2026-09-07T13:50:48.716Z"
+      "lastModified": "2026-09-09T07:07:15.627Z"
     }
   },
   {
@@ -1793,7 +1793,7 @@
     "stats": {
       "size": 667863,
       "lines": 18947,
-      "lastModified": "2026-09-07T13:50:48.716Z"
+      "lastModified": "2026-09-09T07:07:15.626Z"
     }
   }
 ]