@sebgroup/green-core 2.19.0 → 2.20.0-rc.20251218145150154

package/generated/mcp/concepts/architecture.md

@@ -0,0 +1,11 @@
+# Green architecture
+
+Green Core is the foundation of the Green Design System, and consists of a set of Web Components that underpins the React and Angular components that are typically used when building applications.
+
+The Web Components are themselves often composed of a hierarchy of smaller Web Componentes, called primitives, that defines the various atomic pieces that make up a component.
+
+The Green architecture roughly looks something like this:
+
+Of course, design tokens, markup and styles can be used on all levels of composition, but are only drawn at the top here in order to simplify the diagram.
+
+Public API Boundry before Web Components means that anything that is lower level than a complete component is considered internal to the framework and should not be used by consumers. We only guarantee semantic versioning for the public api. Anything that is considered internal could change in breaking ways in any release.

package/generated/mcp/concepts/declarative-layout.md

@@ -0,0 +1,114 @@
+# Declarative layout
+
+## Why?
+
+One of the main reasons we are building Green Core using web components is style encapsulation. The use
+of Shadow DOM greatly reduces the risk of styling conflicts in a micro-frontend architecture environment.
+
+This is great for styling the components themselves, but what about the rest of the stuff in an application?
+Things like margins, paddings, and grid systems also need styling. These sorts of things are usually handled
+by utility classes in traditional CSS frameworks. Utility classes are good, because you don't need to think
+about class names for everything. It allows you to quickly build out a responsive layout without writing
+a lot of CSS, and it also makes it clear from looking at the markup what the layout is supposed to be.
+
+The main problem with utility classes, in our case, is that they are, in fact, still CSS classes. And CSS classes
+can, and will, lead to conflicts.
+
+But, you may ask, if everyone just agrees to use Tailwind or Bootstrap, or some other available
+library, won't that solve the problem? Well, it may, initially. But as is always the case with libraries,
+they evolve over time. They have to, because CSS evolves over time. And so it inevitably leads to a version
+lock-in effect. Because if the next version of Bootstrap have any breaking changes, it means that every
+micro-frontend needs to upgrade at the same time to avoid conflicts. This is not a good situation to be in,
+because coordinating upgrades across multiple teams and products is hard, bordering on impossible.
+
+And even if we could solve the lock-in problem, there is still the issue of the size of the CSS payload. Any utility
+framework will have a lot of utility classes, and if you only use a few of them, you may be shipping a lot of
+unused CSS to the client. In a single application context, this is typically not that big of an issue, because there
+are ways to tree-shake the classes and keep only the used ones. This (amongst other things) is what the Tailwind
+compiler does for you. But in a micro-frontend environment, it is often not possible to determine ahead of time which
+classes are going to be used in a given document, since it may consist of multiple independently developed parts.
+
+The declarative layout system in Green Core is an attempt to solve these problems in a way that let's us have the
+cake and eat it too.
+
+## How?
+
+Instead of utility classes, the declarative layout system generates CSS on the fly and injects into the
+shadow roots of components. It does this using something we call `style expression properties`. These properties
+are used to inform the component what CSS it needs to generate and inject into its Shadow DOM.
+
+The system introduces a set of layout oriented components:
+
+- `<gds-div>`
+  - `<gds-grid>`
+  - `<gds-flex>`
+  - `<gds-card>`
+  - `<gds-text>`
+
+The hierechy in the list here is intentional. `<gds-div>` is the base component, providing all the base properties,
+while the other ones extend this base with specific defaults, and in some cases, additional properties.
+
+Additionally, some style expression properties are available on other components, where it makes sense. For example,
+`<gds-button>` supports horizontal sizing properties, margin properties and flex/grid child items properties. Check
+the API table for each component to see which properties are available. They are listed under a separate section in
+the API table.
+
+### Responsiveness
+
+Style expression properties allows you to write responsive styles in a compact and declarative way. Here is an example:
+
+```html
+<!-- Here, we're setting the default padding to `xs`, but increasing it to `m` in `l` viewports -->
+<gds-div padding="xs; l {m}">
+  <!-- Similarly, here we default to 1 column, increase to 2 columns in `m` viewpors, and 4 columns in `xl` viewports -->
+  <gds-grid columns="1; m {2}; xl {4}">
+    <!-- Any HTML element can go as children -->
+  </gds-grid>
+</gds-div>
+```
+
+This is a very simple example, but it should give you an idea of how the style expression properties work.
+
+Media queries can also be expressed as CSS units and as ranges, for example:
+
+- `>m, <xl { ... }` - Above `m`, below `xl`
+- `>500px, <1000px { ... }` - Above 500px, below 1000px
+
+The value that goes in the media query is usually resolved to a css variable. In the padding example, it would
+resolve to `var(--gds-sys-space-m)`. This is then transformed into a CSS property, typically of the same name as the
+property used on the component. So, here it would be `padding: var(--gds-sys-space-m)`. That means you can also use
+regular CSS shorthand patterns, like `padding: 1em 2em 3em 4em` by adding more values. They will each resolve to\
+a CSS variable. For example: `padding="xs; l {m xl m xl}"`
+
+When no media query is specified, it is the same as setting the breakpoint to 0. So, `padding="0 {m}"` is equivalent
+to `padding="m"`.
+
+### Pseudo selectors
+
+Psudeo selectors can be added to any media query as a separate value sequence. For example:
+
+```html
+<gds-div padding="xs; hover: s; l { s; hover: m }">
+  <!-- Any HTML element can go as children -->
+</gds-div>
+```
+
+In the above example, the padding will be `xs` by default, `s` on hover, `m` in `l` viewports, and `m` on hover in `l` viewports.
+
+## Other components
+
+Style expression properties are not limited to the declarative layout components. In fact, they are a central part of the Green Core architecture, and is available in many components, wherever it makes sense. For example, on `<gds-button>` you can set the width using style expression syntax.
+
+In the API-tables in Storybook, you can find more information about the available style expression properties for each component under a separate section.
+
+## Conclusion
+
+In conclusion, this system solves the conflict issue by injecting the CSS directly into the shadow DOM of the component,
+and it solves the payload size issue by generating the CSS that is needed on the fly on the client side. It also solves
+the version lock-in by using the same version scoping mechanism as the rest of the components in Green Core.
+
+Internally, the style expression properties are using a custom property decorator which can be configured for different
+needs on a per-property basis. This keeps the code size in the implementation to a minimum, while still allowing for a
+sufficient level of flexibility.
+
+To learn more about Declarative layout, and the syntax for style expression properties, head over to the [Declarative layout section on seb.io](https://seb.io/primitives/declarative-layout).

package/generated/mcp/concepts/localization.md

@@ -0,0 +1,62 @@
+# Localization
+
+Green Core has built in localization for English (default) and Swedish. This affects the built-in copy of the components.
+For the rest of the copy in your application, you need to handle the localization separately. The localization in Green Core
+is based on the `@lit/localize` library.
+
+To use the localization features, you need to import and call the `gdsInitLocalization` function from Green Core:
+
+```ts
+
+const { setLocale } = gdsInitLocalization()
+```
+
+The current language can be set by calling the `setLocale` function that is returned from `gdsInitLocalization`:
+
+```ts
+setLocale('sv')
+```
+
+This can be called at any time, and it will cause all Green Core components on the page to re-render with the correct locale.
+
+Note that `gdsInitLocalization()` can only be called once, so you need to set up a singleton of some kind (for example a service in Angular or `useEffect` in React) to make sure that
+you only do this once per page load. If it is called twice, it'll throw an error the second time.
+
+### List available locals
+
+You can get a list of all available target locales by importing `targetLocales` from `@sebgroup/green-core/localization`:
+
+```ts
+
+// This will log an array of all available target locales
+console.log(targetLocales)
+```
+
+Note that this list will not include the *source* locale, which is English in our case. Since we currently only support English and Swedish, the list will only contain `['sv']`.
+
+## Additional locales
+
+Green should have translations for all the required languages built-in, so if you are missing the locale that you need, please get in touch and we will help you add it.
+
+If you find yourself in some edge case where you absolutely need a custom translation or locale, we got you covered too.
+
+When calling `gdsInitLocalization` you can supply additional locales and templates:
+
+```ts
+const { setLocale, getLocale } = gdsInitLocalization({
+  extraLocales,
+  extraTemplates,
+})
+```
+
+`extraLocales` is just an array of locale ids, like `['es', 'fr']` and `extraTemplates` needs to be a `Map` with locale id keys and `@lit/localize` templates as values. These templates can be generated using the `lit-localize` CLI. Check the [Lit website](https://lit.dev/docs/localization/overview/) for more info. You can also check the Green Core source code to see how it is done there.
+
+## `@lit/localize` doesn't work with framework X. Why not use a framework agnostic solution?
+
+Localization is one of those things that is often tightly coupled to the template engine of the framework you're using, which makes it tricky to provide a single framework agnostic solution.
+
+The approach Green Core is going with is to provide built-in localization for standard copy in its components, but leave the rest of the app up to the consumer. The consumer-side requirements can be quite diverse from case to case. For example, translations may come from a CMS or some legacy back-end, so a lot of case-by-case flexibility is needed there, and it's hard to anticipate all of those requirements up front.
+
+For the Green Core web components, `@lit/localize` makes sense, since it is a fairly simple and light-weight library, and the components use the lit-html template engine for their internal rendering needs.
+
+So the mental model you should have here, is that you set up localization however you want in your application, and then in whichever function you set the locale, you also call `setLocale` from Green to keep the component language in sync.

package/generated/mcp/concepts/scoping.md

@@ -0,0 +1,57 @@
+# Custom element scoping
+
+A problem with the current state of the Custom Elements standard is that there is
+only a single, global, `CustomElementRegistry`. This means that if you have two different
+libraries, or two different versions of the same library, that both define a custom
+element with the same name, only one of them will get registered, and the other will
+throw an error, since the name was already taken.
+
+This is a problem for Green, because we need it to work well in a micro-frontend
+architecture, where multiple apps can be loaded on the same page, and each app can
+potentially have its own version of Green.
+
+There is a (proposal)[https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Scoped-Custom-Element-Registries.md]
+for enabling user instantiated CustomElementRegistry scoped to a ShadowRoot, but as of
+mid 2023 this is still only available in Chrome canary behind experimental flags.
+
+## Solution
+
+To get around the problem we define our own scoping mechanism. It works like this:
+
+- Green Core has its own lookup table of custom elements, and a suffix is added to the
+  name of each custom element. For example, `gds-popover` becomes `gds-popover-<versionstring>`.
+  The version string is deterministically generated by hasing the source code in the current
+  version of Green Core package.
+
+- We also define a new `customElement` decorator that will be used to register custom
+  elements. `@gdsCustomElement` will automatically add the version suffix to the name of
+  the custom element, and register it in the lookup table. If the custom element is already
+  registered, it will abort silently, with the assumption that the custom element was
+  already registered by the same version of Green Core and is therefor compatible. This should
+  also make it possible to combine this with module federation at some point, allowing apps
+  that share a version of a component to reuse the same code instance.
+
+- We also have a custom `html` template tag that will automatically rewrite all custom
+  element names from the lookup table to include the version suffix, before passing the
+  template on to the Lit `html` tag. Alternatively, a template tag factory can be used
+  to create a custom `html` tag, if Lit is not used by the consumer.
+
+## Caveats
+
+Consumers using top-level components from Green Core will have to add the version suffix
+in some way. The React and Angular wrappers takes care of this automatically. Another way
+is to use the `html` template tag or template tag factory from Green Core, but it will only
+work if the consumer is using javascript template literals.
+
+If the consumer is using hard coded HTML, or a templating language that does not support
+template tags, the consumer will have to manually add the version suffix to the custom
+element names, which would be cumbersome. In this edge-case, the scoping feature can be disabled,
+and the consumer will have to make sure that only a single version of Green Core is used
+on the page.
+
+The recommendation is to only consume Green Core though the React or Angular wrappers, or to
+use the `html` template tag or template tag factory from Green Core.
+
+At some point in the future, when the scoped custom element registry proposal has been
+implemented in all major browsers, we might remove this custom scoping mechanism and
+switch to using native scoped registries instead.

package/generated/mcp/concepts/tokens.md

@@ -0,0 +1,71 @@
+import { Meta, Markdown } from '@storybook/addon-docs/blocks';
+
+# Tokens
+
+Green Design System uses a token-based approach to design. This means
+that design properties, such as colors and spacing values, are defined
+in a single place and are then used throughout the design system.
+This makes it easier to maintain and update the design system and helps to
+ensure consistency across the components in the system and the products
+that use them.
+
+Tokens are  commonly referred to as <em>variables</em>, and these terms
+can be used interchangeably for the most parts. The distiction is mainly an
+abstract one, with the term <em>token</em> meaning the design value itself,
+whereas <em>variable</em> often refers to the concrete implementation in code. In
+CSS it is typically called `variables` though the technically correct terminlogy
+is `CSS custom properties`. In Figma, they are called `variables`. Other
+languagues and tools may have other names for the same concept.
+
+## Token collections
+
+Tokens in Green are grouped in the following collections:
+
+- Colors\
+  Green uses a three-level color system, which you can read more about under [https://seb.io/primitives/colours](https://seb.io/primitives/colours)
+- Text\
+  Text tokens include font sizes, line heights, and font weights. Read more under [https://seb.io/primitives/typography](https://seb.io/primitives/typography)
+- Spacing\
+  Spacing tokens define the spacing values used for paddings, margins, gaps and other spaces in the design. Read more under [https://seb.io/primitives/spacing](https://seb.io/primitives/spacing)
+- Viewports\
+  Viewport tokens define the breakpoints used in the design system.
+- Shadows\
+  Shadow tokens define the `box-shadow` values used in the design system.
+
+## Using token variables
+
+In most cases you don't need to use variables directly. They are already used in
+the design of the components, and if you are using [Declarative Layout](/docs/concepts-declarative-layout--docs), you have a
+simplified way of using the tokens. You can read more on this on [https://seb.io/primitives/colours](https://seb.io/primitives/colours).
+
+However, in some cases you will need to use CSS variables directly in your code, so
+let's briefly go over how to access them.
+
+### Using the CSS variables
+
+In CSS, you can access the tokens by using the `var()` function. If you are not familiar
+with CSS variables, you can [read more about them on MDN](https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_custom_properties).
+
+By default, tokens are defined on the `:host` selector of every component, so in order to access them, the element you are styling
+needs to be a child to a Green component. CSS variables, as opposed to other CSS properties, propagates down across shadow DOM boundaries,
+so when they are defined on the `:host` selector of a component, they are available to all children of that component.
+
+If a parent of your element is one of the declarative layout components from Green
+(ie, container, flex, grid or card), you're already covered, but if not, you can use `<gds-theme>` for this purpose. `<gds-theme>` does not
+add any visible layout to the page, but it provides access to all the CSS variables. The theme component can also be used to toggle
+between light and dark mode, as well as setting the design version to be used by its descendants. You can [read more about the theme component here](/docs/components-theme--docs).
+
+Here is an example of using the theme component to get access to variables:
+
+<gds-theme design-version="2023">
+  <div>Hello world</div>
+</gds-theme>
+```html
+<gds-theme design-version="2023">
+  <div style="background-color: var(--gds-sys-color-l2-neutral-02); color: var(--gds-sys-color-content-neutral-01); padding: var(--gds-sys-space-l);">
+    Hello world
+  </div>
+</gds-theme>
+```
+
+Try inspecting this example in Chrome DevTools, and change the value of the `color-scheme` attribute in the `<gds-theme>` element to `dark` to see what happens to the color variables.

package/generated/mcp/concepts/transitional-styles.md

@@ -0,0 +1,59 @@
+# Transitional styles
+
+Transitional Styles is a temporary mechanism that we have in place to facilitate the transition from the old 2016 design version over to the new 2023 design version.
+
+## How it works
+
+The idea is that the Core Components will use the 2023 design by default, but will also have alternative "transitional styles" representing the 2016 version. By calling a function called `register()` (or `registerTransitionalStyles()` to do it globally), the consuming application can enable these styles, which will then override the 2023 styling by replacing the internal Contructed Stylesheet of the components.
+
+This example will import and apply 2016 design to buttons in the document:
+
+```ts
+// Here we import the transitional styles for the button component. It's a good practice to only
+// import the styles for the specific components you need.
+
+// This call is what will cause the styles to get applied to the button components
+ButtonStyles.register()
+```
+
+Transitional styles are available for some, but not all, components. If it's not available, you can simply use the 23 style along older 16 styles during the transition period.
+
+### Granular control
+
+When transitional styles have been loaded for a component, it will apply to all instances of that component in the document. However, let's say you are adopting the new style for buttons in your application, but for some legacy reason, you still need some buttons to use the 2016 style. In that case, you can use `gds-theme` to override the transitional styles for that specific button:
+
+```html
+<gds-theme design-version="2023">
+  <gds-button>Button with 2023 style</gds-button>
+</gds-theme>
+````
+
+`gds-theme` gives you granular control over which parts of the application should use the 2023 design and which should use the 2016 design. Since Core 2.0, the default design version is `2023`.
+
+***Note:** The 2016 styles expects some CSS variables from Chlorophyll to be present. In many cases, Chlorophyll is already used in the document, but in case it isn't, you can add these variables by using wrapping in `<gds-theme>`. You also need to import and register transitional styles for the gds-theme component in that case.*
+
+## Info for library developers
+
+Transitional Styles consist of a few different parts:
+
+- A singleton called `TransitionalStyles`, which keeps track of all registered transistional styles.
+- The actual stylesheets for each component. To support Transitional Styles, a component should have a separate file named `component-name.styles.trans.ts`, which exports a function called `register()`. This function registers the transitional styles with the singleton.
+- A call to apply transitional styles in the `connectedCallback()` method in each component. The call can look like this `TransitionalStyles.instance.apply(this, 'gds-dropdown')`. This will replace the stylesheet of the component with the on that has been registered with the singleton, if it exists.
+- A function called `registerTransitionalStyles()` that calls `register()` on all the components. This will load _all_ transitional styles, and prevents tree-shaking, so it should only be used if all the styles are really needed.
+
+If `register()`, or `registerTransitionalStyles()`, has not been called, the components will simple use the default 2023 styling.
+
+### How to add transitional styles to a component
+
+1. Create these files in the component directory: `component-name.trans.styles.ts` and `component-name.trans.styles.scss`. The `scss`-file can import styles from Chlorophyll, through releative paths (not from node_modules). If necessarary, the styles can be copied from Chlorophyll and modified as needed.
+2. The `.ts` module should a) import the `scss` for this component, b) import the `trans.ts` from any sub-components that this components depends on, and c) export a `register()` function. The register function should register the imported styles with the `TransistionalStyles` singleton and also call `register()` on the imported sub-components. Check for example `gds-dropdown` for reference.
+3. Import the `.ts` file in the `transitional-styles.ts` module and add a call to the `register()` function in the `registerTransitionalStyles()` function.
+4. In the `connectedCallback()` function of the component, call `TransitionalStyles.instance.apply(this, 'component-name')`
+
+That should be it! Now, when the `register()` function is called, the component should switch to the transitional styles.
+
+### Tree-shaking
+
+In order for transitional styles to be tree-shakable, it's important to make it possible to import the styles separately for individual components. This means that every component also needs to be responsible for forwarding the `register()` call to any sub-components it depends on. This includes both "primitives" and regular components. For example, `gds-datepicker` use both `gds-dropdown` (component), `gds-popover` (primitive) and `gds-calendar` (primitive). So in the `register()` function of `gds-datepicker` we also need to call the `register()` function of all these sub-components. Also, if a primitive depends on other primitives or components, the same applies there. The point is that the consumber of Green Core should only need to remember to call `register()` on the component they are using, and not have to worry about what other components are used internally.
+
+This may lead to the `register()` function being called several times for some components, but that is fine.

package/generated/mcp/context-menu/angular.md

@@ -0,0 +1,26 @@
+# gds-context-menu - Angular
+
+## Import
+
+```typescript
+import { GdsContextMenuComponent } from '@sebgroup/green-core-ng'
+```
+
+## Usage
+
+Use the component in your Angular templates:
+
+```html
+<gds-context-menu>
+  <!-- content -->
+</gds-context-menu>
+```
+
+## Event Handling
+
+Events are emitted using Angular output syntax. Event names are converted from kebab-case to camelCase:
+
+| Web Component Event | Angular Output | Handler Example |
+|---------------------|----------------|-----------------|
+| `gds-menu-item-click` | `gdsMenuItemClick` | `(gdsMenuItemClick)="handler($event)"` |
+| `gds-ui-state` | `gdsUiState` | `(gdsUiState)="handler($event)"` |

package/generated/mcp/context-menu/api.md

@@ -0,0 +1,42 @@
+# gds-context-menu
+
+**Class**: `GdsContextMenu`
+
+**Tag**: `<gds-context-menu>`
+
+
+## Properties
+
+| Name | Type | Default | Description |
+|------|------|---------|-------------|
+| `open` | `boolean` | `false` | Whether the context menu popover is open. |
+| `buttonLabel` | `string` | `-` | The label for the trigger button. |
+| `showLabel` | `boolean` | `false` | Whether to show the label on the trigger button. |
+| `label` | `string` | `''` | The label for the popover and menu. Should describe the context of the menu. |
+| `placement` | `Placement` | `'bottom-start'` | The placement of the popover relative to the trigger. |
+| `margin` | `string \| undefined` | `-` | Style Expression Property that controls the `margin` property. Only accepts space tokens. |
+| `'margin-inline'` | `string \| undefined` | `-` | Style Expression Property that controls the `margin-inline` property. Only accepts space tokens. |
+| `'margin-block'` | `string \| undefined` | `-` | Style Expression Property that controls the `margin-block` property. Only accepts space tokens. |
+| `'align-self'` | `string \| undefined` | `-` | Style Expression Property that controls the `align-self` property. Supports all valid CSS `align-self` values. |
+| `'justify-self'` | `string \| undefined` | `-` | Style Expression Property that controls the `justify-self` property. Supports all valid CSS `justify-self` values. |
+| `'place-self'` | `string \| undefined` | `-` | Style Expression Property that controls the `place-self` property. Supports all valid CSS `place-self` values. |
+| `'grid-column'` | `string \| undefined` | `-` | Style Expression Property that controls the `grid-column` property. Supports all valid CSS grid-column values. Documentation: https://developer.mozilla.org/en-US/docs/Web/CSS/grid-column |
+| `'grid-row'` | `string \| undefined` | `-` | Style Expression Property that controls the `grid-row` property. Supports all valid CSS `grid-row` values. |
+| `'grid-area'` | `string \| undefined` | `-` | Style Expression Property that controls the `grid-area` property. Supports all valid CSS `grid-area` values. |
+| `flex` | `string \| undefined` | `-` | Style Expression Property that controls the `flex` property. Supports all valid CSS `flex` values. |
+| `order` | `string \| undefined` | `-` | Style Expression Property that controls the `order` property. Supports all valid CSS `order` values. |
+
+
+## Events
+
+| Name | Type | Description |
+|------|------|-------------|
+| `gds-menu-item-click` | `CustomEvent<any>` | Fired when a menu item is clicked. |
+| `gds-ui-state` | `CustomEvent<any>` | Fired when the menu is opened or closed. |
+
+
+## Slots
+
+| Name | Description |
+|------|-------------|
+| `(default)` | The default slot. Only `gds-menu-item` elements are accepted here. |

package/generated/mcp/context-menu/guidelines.md

@@ -0,0 +1,33 @@
+# Context menu
+
+A context menu displays a list of contextual actions.
+
+
+## Overview
+
+### Custom trigger button
+
+The context menu trigger button can have an icon or custom text slotted.
+
+### Menu item
+
+In a menu item you can slot in text and icons along other layout components.
+
+### Label
+
+It can be visually displayed, or hidden but still available to screen readers.
+
+### Guidelines
+
+Use the context menu to give users all the options when you can’t fit them in the regular view, or to avoid cluttering the interface.
+
+###   Destructive items
+
+Some items in the menu may be destructive. Typical example is Delete. These items behave like the delete-button and should be displayed in red.
+
+### Do's and don'ts
+
+
+## UX Guidelines
+
+### Writing UX text for context menus

package/generated/mcp/context-menu/index.json

@@ -0,0 +1,9 @@
+{
+  "name": "gds-context-menu",
+  "files": {
+    "api": "api.md",
+    "guidelines": "guidelines.md",
+    "angular": "angular.md",
+    "react": "react.md"
+  }
+}

package/generated/mcp/context-menu/react.md

@@ -0,0 +1,26 @@
+# gds-context-menu - React
+
+## Import
+
+```typescript
+import { GdsContextMenu } from '@sebgroup/green-core/react'
+```
+
+## Usage
+
+Use the component as a React JSX element:
+
+```tsx
+<GdsContextMenu>
+  {/* content */}
+</GdsContextMenu>
+```
+
+## Event Handling
+
+Events are handled using React event handler props. Event names are converted from kebab-case to camelCase with an "on" prefix:
+
+| Web Component Event | React Handler Prop | Handler Example |
+|---------------------|--------------------|-----------------|
+| `gds-menu-item-click` | `onGdsMenuItemClick` | `onGdsMenuItemClick={handler}` |
+| `gds-ui-state` | `onGdsUiState` | `onGdsUiState={handler}` |

package/generated/mcp/datepicker/angular.md

@@ -0,0 +1,26 @@
+# gds-datepicker - Angular
+
+## Import
+
+```typescript
+import { GdsDatepickerComponent } from '@sebgroup/green-core-ng'
+```
+
+## Usage
+
+Use the component in your Angular templates:
+
+```html
+<gds-datepicker>
+  <!-- content -->
+</gds-datepicker>
+```
+
+## Event Handling
+
+Events are emitted using Angular output syntax. Event names are converted from kebab-case to camelCase:
+
+| Web Component Event | Angular Output | Handler Example |
+|---------------------|----------------|-----------------|
+| `change` | `change` | `(change)="handler($event)"` |
+| `gds-ui-state` | `gdsUiState` | `(gdsUiState)="handler($event)"` |

package/generated/mcp/datepicker/api.md

@@ -0,0 +1,76 @@
+# gds-datepicker
+
+**Class**: `GdsDatepicker`
+
+**Tag**: `<gds-datepicker>`
+
+
+## Properties
+
+| Name | Type | Default | Description |
+|------|------|---------|-------------|
+| `width` | `string \| undefined` | `-` | Style Expression Property that controls the `width` property. Supports space tokens and all valid CSS `width` values. |
+| `'min-width'` | `string \| undefined` | `-` | Style Expression Property that controls the `min-width` property. Supports space tokens and all valid CSS `min-width` values. |
+| `'max-width'` | `string \| undefined` | `-` | Style Expression Property that controls the `max-width` property. Supports space tokens and all valid CSS `max-width` values. |
+| `'inline-size'` | `string \| undefined` | `-` | Style Expression Property that controls the `inline-size` property. Supports space tokens and all valid CSS `inline-size` values |
+| `'min-inline-size'` | `string \| undefined` | `-` | Style Expression Property that controls the `min-inline-size` property. Supports space tokens and all valid CSS `min-inline-size` values. |
+| `'max-inline-size'` | `string \| undefined` | `-` | Style Expression Property that controls the `max-inline-size` property. Supports space tokens and all valid CSS `max-inline-size` values. |
+| `margin` | `string \| undefined` | `-` | Style Expression Property that controls the `margin` property. Only accepts space tokens. |
+| `'margin-inline'` | `string \| undefined` | `-` | Style Expression Property that controls the `margin-inline` property. Only accepts space tokens. |
+| `'margin-block'` | `string \| undefined` | `-` | Style Expression Property that controls the `margin-block` property. Only accepts space tokens. |
+| `'align-self'` | `string \| undefined` | `-` | Style Expression Property that controls the `align-self` property. Supports all valid CSS `align-self` values. |
+| `'justify-self'` | `string \| undefined` | `-` | Style Expression Property that controls the `justify-self` property. Supports all valid CSS `justify-self` values. |
+| `'place-self'` | `string \| undefined` | `-` | Style Expression Property that controls the `place-self` property. Supports all valid CSS `place-self` values. |
+| `'grid-column'` | `string \| undefined` | `-` | Style Expression Property that controls the `grid-column` property. Supports all valid CSS grid-column values. Documentation: https://developer.mozilla.org/en-US/docs/Web/CSS/grid-column |
+| `'grid-row'` | `string \| undefined` | `-` | Style Expression Property that controls the `grid-row` property. Supports all valid CSS `grid-row` values. |
+| `'grid-area'` | `string \| undefined` | `-` | Style Expression Property that controls the `grid-area` property. Supports all valid CSS `grid-area` values. |
+| `flex` | `string \| undefined` | `-` | Style Expression Property that controls the `flex` property. Supports all valid CSS `flex` values. |
+| `order` | `string \| undefined` | `-` | Style Expression Property that controls the `order` property. Supports all valid CSS `order` values. |
+| `value` | `Date \| undefined` | `-` | The Date value of the datepicker. This can be set to undefined to clear the datepicker. This can be a string if set via the value attribute in markup, or via the setAttribute DOM API. |
+| `min` | `any` | `new Date(new Date().getFullYear() - 10, 0, 1)` | The minimum date that can be selected. |
+| `max` | `any` | `new Date(new Date().getFullYear() + 10, 0, 1)` | The maximum date that can be selected. |
+| `open` | `boolean` | `false` | Controls whether the datepicker popover is open. |
+| `supportingText` | `string` | `''` | The supporting text displayed between the label and the field itself |
+| `size` | `'large' \| 'small'` | `'large'` | Whether to use the small variant of the datepicker field. |
+| `plain` | `boolean` | `false` | Hides the header and the footer, while still keeping the accessible label  Always set the `label` attribute, and if you need to hide it, add this attribute and keep `label` set. |
+| `showWeekNumbers` | `boolean` | `false` | Whether to show a column of week numbers in the calendar. |
+| `hideLabel` | `boolean` | `false` | Whether to hide the label above the input field. |
+| `clearable` | `boolean` | `false` | Whether the Clear button is shown under the calendar. |
+| `hideTodayButton` | `boolean` | `false` | Whether to hide the Today button under the calendar. |
+| `utcHours` | `any` | `-` | Controls the time component of dates selected in the calendar popover or spinbuttons in the field.  The time will be set in UTC. |
+| `dateformat` | `any` | `-` | The date format to use. Accepts a string with the characters `y`, `m` and `d` in any order, separated by a delimiter. For example, `y-m-d` or `d/m/y`. All three characters must be present.  This will determine the structure of the input field.  Defaults to `y-m-d`. |
+| `disabledWeekends` | `boolean` | `false` | Whether to disable weekends in the calendar. |
+| `disabledDates` | `Date[] \| undefined` | `-` | An array of dates that should be disabled in the calendar. |
+| `showExtendedSupportingText` | `boolean` | `false` | Whether the supporting text should be displayed or not. |
+| `test_calendarButton` | `Promise<HTMLButtonElement>` | `-` | A reference to the calendar button element inside the shadow root. Inteded for use in integration tests. |
+| `test_clearButton` | `HTMLButtonElement` | `-` | A reference to the clear button element inside the shadow root. Inteded for use in integration tests. |
+| `test_todayButton` | `HTMLButtonElement` | `-` | A reference to the today button element inside the shadow root. Inteded for use in integration tests. |
+| `validator` | `GdsValidator \| undefined` | `-` | A validator that can be used to validate the form control and set an error message. |
+| `required` | `boolean` | `false` | The required attribute can be used to communicate to users of assistive technology that the control is required. Validation still needs to be done in a validator or equivalent. |
+| `errorMessage` | `string` | `''` | This can be used to manually control the error message that will be displayed when the control is invalid. |
+| `invalid` | `any` | `-` | Validation state of the form control. Setting this to true triggers the invalid state of the control. |
+| `label` | `string` | `''` | The label of the form control. |
+| `name` | `string` | `''` |  |
+| `disabled` | `boolean` | `false` | If the input is Disabled |
+
+
+## Events
+
+| Name | Type | Description |
+|------|------|-------------|
+| `change` | `Event` | Fired when the value of the dropdown is changed through user interaction (not when value prop is set programatically). |
+| `gds-ui-state` | `CustomEvent<any>` | Fired when the dropdown is opened or closed. |
+
+
+## Slots
+
+| Name | Description |
+|------|-------------|
+| `extended-supporting-text` | A longer supporting text can be placed here. It will be displayed in a panel when the user clicks the info button. |
+| `message` | ***(deprecated - use `errorMessage` property instead)*** Error message to show below the input field whem there is a validation error. |
+| `sub-label` | ***(deprecated - use `supporting-text` property instead)*** Renders between the label and the trigger button. |
+
+
+## Form Control
+
+This component is a form control and inherits form-related properties and methods.