@twobirds/microcomponents 0.4.0 → 0.5.0

package/dist/mcp/concepts/custom-element-registry.md

@@ -0,0 +1,92 @@
+All functionality in Micro Components is registered in the browser's custom element registry, regardless of its purpose. This includes:
+
+- Real web components that render visible DOM elements
+- Logic-only components that execute code in constructor() and oneInit(), then self-remove
+- CSS-only components that attach stylesheets to the document and remove themselves
+
+When a component should not render anything visually, it declares `static tag = '';`. This tells defineCE to register the element but never produce visible markup. The component still runs its lifecycle callbacks (constructor → connectedCallback → oneInit), allowing it to execute setup logic or inject global styles before optionally removing itself from the DOM.
+
+This unified registration model means every piece of functionality — visual, logical, or stylistic — follows the same pattern: extend DC, define behavior, register with defineCE().
+
+---
+
+## Tag Name to File Path Mapping
+
+Because `autoload()` resolves an undefined tag to a script URL by converting kebab-case to path segments (`<shop-header>` → `./shop/header.js`), the tag name _is_ the file path. The kebab-case segments become the directory path and the last segment becomes the filename. The directory structure in `dist/` must mirror this segmentation for autoloading to work.
+
+| Tag                         | Source File                      | Companion Files                                                             |
+| --------------------------- | -------------------------------- | --------------------------------------------------------------------------- |
+| `<shop-header>`             | `src/shop/header.ts`             | `shop/header.target.html`, `shop/header.target.css`                         |
+| `<shop-sidebar>`            | `src/shop/sidebar.ts`            | `shop/sidebar.target.html`, `shop/sidebar.target.css`                       |
+| `<cart-container-articles>` | `src/cart/container/articles.ts` | `cart/container/articles.shadow.html`, `cart/container/articles.shadow.css` |
+
+This is the same contract that makes one-class-per-file mandatory (see [microcomponent-architecture](microcomponent-architecture.md)): one tag → one script → one class.
+
+---
+
+## Frontend Nesting in Folder Structure
+
+When a component is visually and structurally nested inside another (a composed parent projecting child web components — see [mc-types](mc-types.md) §1c), the folder hierarchy reflects that nesting. A child's tag name includes its parent's prefix, and its file resides in a subdirectory of the parent. This applies recursively to grandchildren.
+
+| Parent Tag         | Child Tag                   | Source File                      |
+| ------------------ | --------------------------- | -------------------------------- |
+| `<app-header>`     | `<app-header-left>`         | `src/app/header/left.ts`         |
+| `<app-header>`     | `<app-header-right>`        | `src/app/header/right.ts`        |
+| `<cart-container>` | `<cart-container-articles>` | `src/cart/container/articles.ts` |
+
+```
+src/
+  app/
+    header.ts          ← <app-header>
+    header.css
+    left.ts            ← <app-header-left> (child of header)
+    left.css
+    right.ts           ← <app-header-right> (child of header)
+    right.css
+```
+
+The DOM hierarchy is therefore immediately visible in the file system.
+
+---
+
+## General-Purpose Components in Side Folders
+
+Components serving cross-cutting concerns — used across unrelated parts of the frontend rather than belonging to one visual hierarchy — reside in dedicated side folders organized by purpose. These are not nested under any UI component but exist at a parallel level. They follow the same tag-to-file mapping and are imported directly by any component that needs them, regardless of where that component lives in the UI hierarchy.
+
+| Purpose              | Folder        | Example Tags                                  |
+| -------------------- | ------------- | --------------------------------------------- |
+| Server communication | `transport/`  | `<transport-request>`, `<transport-response>` |
+| Authentication       | `auth/`       | `<auth-guard>`, `<auth-token>`                |
+| State management     | `store/`      | `<store-cart>`, `<store-user>`                |
+| Validation           | `validation/` | `<validation-email>`, `<validation-required>` |
+| Utilities            | `helpers/`    | `<helper-formatter>`, `<helper-locale>`       |
+
+### Diversification Within General-Purpose Folders
+
+General-purpose folders can contain subdirectories for more specific variations within a category, flowing from broad purpose to narrow specialization. Subfolders represent functional specializations, not visual nesting.
+
+| Purpose                  | Folder Structure   | Example Tags                                            |
+| ------------------------ | ------------------ | ------------------------------------------------------- |
+| Transport → HTTP methods | `transport/http/`  | `<transport-http-get>`, `<transport-http-post>`         |
+| Transport → WebSocket    | `transport/ws/`    | `<transport-ws-client>`, `<transport-ws-handler>`       |
+| Validation → Form fields | `validation/form/` | `<validation-form-email>`, `<validation-form-password>` |
+| Store → Persistence      | `store/persist/`   | `<store-persist-local>`, `<store-persist-session>`      |
+
+```
+src/
+  transport/
+    request.ts           ← <transport-request> (general)
+    response.ts          ← <transport-response> (general)
+    http/                ← HTTP-specific diversification
+      get.ts             ← <transport-http-get>
+      post.ts            ← <transport-http-post>
+    ws/                  ← WebSocket-specific diversification
+      client.ts          ← <transport-ws-client>
+  validation/
+    email.ts             ← <validation-email> (general)
+    form/                ← Form-specific diversification
+      email.ts           ← <validation-form-email>
+      password.ts        ← <validation-form-password>
+```
+
+The same tag-to-file mapping applies: `<transport-http-get>` maps to `src/transport/http/get.ts`.

package/dist/mcp/concepts/event-system.md

@@ -0,0 +1,45 @@
+Events in Micro Components use CustomEvent with directional bubbling:
+
+Handler conventions (auto-attached):
+
+- on<EventName>() - persistent listener (fires every time)
+- one<EventName>() - one-time listener (fires once, then detaches)
+
+Lifecycle events when registered via defineCE:
+
+- oneInit() - constructor finished; all synchronous setup complete
+- onConnected() - element inserted into DOM
+- onDisconnected() - element removed from DOM
+- onAdopted() - element moved to new document
+- onAttributeChanged() - observed attribute changed
+
+Bubble directions in trigger():
+
+- 'l' = local dispatch only (default)
+- 'u' = bubble up towards ancestors
+- 'd' = bubble down to descendants
+- Can combine: 'lu', 'ld', 'lud'
+
+Only use bubbling when there is a specific reason for it. Usually directly addressing the target is better, because of the speed advantage using querySelectorAll().
+
+## Payload & propagation
+
+MC-triggered custom events and lifecycle events are `McEvent<D>` — a `CustomEvent` whose `detail` is `{ data, control }`. The payload is always read from `ev.detail.data`, never `ev.data`.
+
+```ts
+cart.on('CartUpdate', (ev: McEvent<{ count: number }>) => {
+	const count = ev.detail.data.count; // payload lives under detail.data
+});
+```
+
+To stop a bubbling event, call `stop()` on the bubble controller carried in the same detail object:
+
+```ts
+cart.on('CartUpdate', (ev: McEvent<{ count: number }>) => {
+	ev.detail.control.stop(); // halt 'u'/'d' propagation
+});
+```
+
+When the event name is part of the component's event map (`EM` on `DC`), the payload type is inferred and the `McEvent<…>` annotation can be omitted; annotate it explicitly only for ad-hoc events.
+
+Native DOM events (`click`, `input`, `submit`, …) are **not** `McEvent` — they carry their natural payload types (`MouseEvent`, `InputEvent`, …) and have no `detail.data` / `detail.control`. Only events dispatched through `trigger()` (and the lifecycle events emitted by `defineCE`) follow the `McEvent` shape above.

package/dist/mcp/concepts/implementation-priority.md

@@ -0,0 +1,10 @@
+When implementing functionality, follow this strict priority chain. Each tier must be exhausted before descending to the next:
+
+**Tier 1 — MC Framework Automatic Functionality (mandatory when inside the framework)**
+Always use built-in DC/MC conventions first. This includes auto-attaching event handlers (`onClick()`, `oneInit()`, etc.), lifecycle callbacks, static properties (`tag`, `assets`, `attributes`), and plugin methods (`.subscribe()` `.bind()` `.formValues()`). These mechanisms are the framework's intended way of wiring behavior — never bypass them with manual alternatives when working inside a DC or MC class.
+
+**Tier 2 — Exported Library Functions (when outside the framework)**
+When using Micro Components alongside another framework, in plain JavaScript, or in non-DC/MC contexts, use the library's exported utility functions: `on()`, `one()`, `trigger()`, `observe()`, `formValues()`, `autoload()`, etc. These are the official public API for accessing MC functionality without extending DC or MC.
+
+**Tier 3 — Pure TypeScript / Vanilla JavaScript (last resort only)**
+Only fall back to native browser APIs (`addEventListener`, `querySelector`, manual DOM manipulation, raw `CustomEvent`, etc.) when neither Tier 1 nor Tier 2 provides a solution. This is the least preferred approach and should be avoided whenever any MC mechanism can accomplish the task.

package/dist/mcp/concepts/mc-types.md

@@ -0,0 +1,349 @@
+# Micro Component Types
+
+Every piece of functionality in Micro Components is registered in the custom element
+registry — visual, logical, or stylistic. What differs is the **base class**, the
+**registration pattern**, and **what (if anything) is rendered**.
+
+This document defines each type, its purpose, and when to reach for it.
+
+---
+
+## Class Hierarchy
+
+```
+McBase          shared root — WeakRef target, auto-listener attachment, Init lifecycle
+├── MC          general-purpose, no DOM requirement
+└── DC          DOM-centric, operates on an HTMLElement
+```
+
+`McBase` is never extended directly. Choose `MC` for DOM-free logic and `DC` for
+anything that touches an element.
+
+---
+
+## Overview
+
+| Type                 | Base              | Registry   | Instantiation                                 | Renders  | Typical Use              |
+| -------------------- | ----------------- | ---------- | --------------------------------------------- | -------- | ------------------------ |
+| Visual Component     | `DC`              | `defineCE` | `<tag-name>` in markup, or `new Ctor(data)`   | Yes      | UI elements              |
+| Logic-Only Component | `DC` (`tag = ''`) | `defineCE` | `getCE()` → `DC.add(host, key, new Ctor())`   | No       | Router, auth, stores     |
+| Style-Only Component | `DC` (`tag = ''`) | `defineCE` | `<tag-name>` in markup, or side-effect import | CSS only | Global stylesheets       |
+| Pure Logic Component | `MC`              | —          | `new Mc(data)` — direct import                | No       | Data processing, helpers |
+| Plugin               | function          | —          | `plugin(DC)` — called, never instantiated     | No       | Prototype extensions     |
+| Utility Function     | function          | —          | called directly                               | No       | Standalone API           |
+
+Registered `DC` types have three instantiation paths:
+
+- **Declarative** — the tag appears in markup and `autoload` loads and constructs it. No
+  import statement is needed.
+- **Programmatic** — `getCE('tag-name')` returns the constructor and `new Ctor(data)`
+  creates the element. Only the `data` payload is passed; the host element is created by
+  the custom element constructor and arrives as the first argument of the `DC`
+  constructor.
+- **Attached** — a logic-only component is constructed with `new Ctor()` and bound to an
+  existing host via `DC.add(host, key, instance)`. It never appears in markup itself.
+
+---
+
+## 1. Visual Components
+
+**Base:** `DC` · **Registry:** `defineCE` · **Renders:** visible DOM
+
+The default type. Any element the user can see and interact with is a `DC`. It owns a
+host element, receives lifecycle events, and wires its own event handlers by naming
+convention.
+
+```ts
+class ShopHeader extends DC {
+	static tag = 'header';
+	static attributes = { role: 'banner' };
+	static assets = ['targetHtml', 'targetCss'];
+}
+
+defineCE('shop-header', ShopHeader);
+```
+
+Visual components split into three structural sub-patterns.
+
+### 1a. Target-Based (flat content)
+
+Markup is injected into `this.target.innerHTML`. Styles are scoped by tag or class and
+adopted into the **document** via `injectCSS(document, ...)`.
+
+Use when the internal structure is simple and flat — a card, a cart line, a label.
+
+```
+src/shop/product/card.ts
+src/shop/product/card.target.html
+src/shop/product/card.target.css
+```
+
+### 1b. Shadow-DOM Based (complex structure)
+
+Markup is injected into `shadowRoot.innerHTML`. Internal styles are adopted into the
+**shadow root** via `injectCSS(shadowRoot, ...)`.
+
+Use when the component has several distinct regions or needs style isolation.
+
+- _Simple shadow_ — one unnamed slot; light-DOM content slots in automatically.
+- _Complex shadow_ — multiple named slots; light-DOM content uses `slot="…"`.
+
+```
+src/cart/container/articles.ts
+src/cart/container/articles.shadow.html
+src/cart/container/articles.shadow.css
+```
+
+### 1c. Composed Components (parents)
+
+A shadow-DOM component that projects **child web components** from the light DOM through
+named `<slot name="…">` elements. Child elements are never embedded in the shadow
+template — projection keeps them in the light DOM so `autoload` can discover and
+register them.
+
+External design of the composed unit is driven by namespaced CSS custom properties
+(`--mcui-btn-*`, `--mcui-card-*`), with defaults declared in the companion `.css` file.
+
+```html
+<cart-container>
+	<cart-container-articles slot="articles"></cart-container-articles>
+	<cart-container-checkout slot="checkout"></cart-container-checkout>
+</cart-container>
+```
+
+### 1d. Leaf Components
+
+Self-contained visual units that project no child custom elements — a button, a badge,
+a single cart line. They are the smallest building block and are usually styled through
+the namespaced variables of their composed parent.
+
+---
+
+## Companion Files
+
+Each custom element (`.ts`/`.js`) ships with optional companion files sharing the same
+base name. The suffix encodes the structural sub-pattern (§1a–1b) and the styling target.
+
+| Suffix         | Purpose                                                               | Styling Target                                       |
+| -------------- | --------------------------------------------------------------------- | ---------------------------------------------------- |
+| `.css`         | CSS custom properties (variable defaults) only — no structural styles | N/A (token definitions)                              |
+| `.target.css`  | Structural style rules for target DOM (`innerHTML`)                   | Global document scope via `injectCSS(document, ...)` |
+| `.shadow.css`  | Structural style rules for shadow DOM                                 | Shadow root via `injectCSS(shadowRoot, ...)`         |
+| `.target.html` | HTML template injected into `this.target.innerHTML`                   | N/A (markup)                                         |
+| `.shadow.html` | HTML template injected into `shadowRoot.innerHTML`                    | N/A (markup)                                         |
+| `.json`        | Static data files imported by the component                           | N/A (data)                                           |
+
+Companion files follow the same directory structure as their source file. A component at
+`src/shop/sidebar.ts` has companions at `src/shop/sidebar.target.html`,
+`src/shop/sidebar.target.css`, etc. Templates, styles, and data are loaded via
+`loadAssets()` / `processAssets()`; keep the `.ts` source focused on logic only —
+constructor, lifecycle, event handlers, state.
+
+### Inline Templates — Escape Hatch
+
+A simple `const template` string constant is allowed **only** when the component has no
+advanced handling: no reactive state (`observe`/`bind`/`subscribe`), no dynamic DOM
+mutations after render, and no separate stylesheet to ship. This is useful for one-time
+placeholder replacement during programmatic creation:
+
+```ts
+const template = '<h1>{title}</h1><button click="this|onGo">Go</button>';
+// ...
+processAssets(this, { targetHtml: parse(template, data) });
+```
+
+`processAssets` still runs `bindTemplateEvents`, so declarative `click='this|onHandler'`
+bindings work for inline strings too. As soon as the component needs reactive data, a
+stylesheet, or autoload-discoverable assets, move the markup into a `.target.html` /
+`.shadow.html` companion file.
+
+---
+
+## Theming via CSS Custom Properties
+
+Components **never hard-code colors**; they read tokens. Four themes — `custom-dark` /
+`custom-light` / `dark` / `light` — are pure token sets on `:root` (switched by a `theme`
+attribute), implemented as style-only components (§3). The `custom-*` themes merge into
+the standard settings, preserving `dark` and `light` defaults.
+
+External design of a composed unit is driven by namespaced CSS custom properties
+(`--mcui-btn-*`, `--mcui-card-*`), with defaults declared in the companion `.css` file.
+Variable names always reflect the element namespace to avoid collisions — a
+`shop-header` component defines `--shop-header-bg`, `--shop-header-color`, etc. in
+`shop-header.css` and consumes them in `shop-header.target.css` / `shop-header.shadow.css`.
+
+---
+
+## 2. Logic-Only Components
+
+**Base:** `DC` with `static tag = ''` · **Registry:** `defineCE` · **Renders:** nothing
+
+Functionality that must be discoverable through the registry and attachable to other
+elements, but produces no markup. `static tag = ''` tells `defineCE` to register the
+element while the constructor removes the host from the DOM. The full lifecycle still
+runs — `constructor` → `connectedCallback` → `oneInit` — so setup logic executes
+normally.
+
+```ts
+class Router extends DC {
+	static tag = '';
+
+	constructor(target: HTMLElement) {
+		super(target);
+		// pure setup, no markup
+	}
+}
+
+defineCE('app-router', Router);
+```
+
+Retrieved from the registry and attached to a host with `DC.add()`:
+
+```ts
+const Router = getCE('app-router')!;
+DC.add(target, 'router', new Router());
+```
+
+Use for: routing, history management, auth guards, state stores, validation engines,
+translation services — anything that should live in the central repository and be
+composable onto existing elements rather than inherited through a class chain.
+
+These components are pulled in through **barrel imports** so they register by
+side-effect without appearing in the DOM.
+
+---
+
+## 3. Style-Only Components
+
+**Base:** `DC` with `static tag = ''` · **Registry:** `defineCE` · **Renders:** CSS only
+
+Structurally identical to a logic-only component, but its side effect is a stylesheet.
+It injects global rules and then self-removes; the styles persist regardless of the
+element's removal.
+
+```ts
+class PageCockpit extends DC {
+	static tag = '';
+	static assets = ['css'];
+}
+
+defineCE('page-cockpit', PageCockpit);
+```
+
+Consumption options: place the tag in a template, side-effect import the `.css.ts`
+module, `@import` the raw `.css` into a bundle, or import it with `?raw` and apply it
+manually.
+
+Use for: global `body`/`:root` token sets, theme definitions, reset stylesheets.
+
+---
+
+## 4. Pure Logic Components
+
+**Base:** `MC` · **Registry:** none · **Renders:** nothing
+
+`MC` is the DOM-free branch of the hierarchy. It skips listener auto-attachment and the
+`Init` lifecycle entirely, which keeps it lightweight for server-side or non-DOM use.
+
+It is **not** registered with `defineCE`. It is imported directly and attached as a
+property on the component that needs it:
+
+```ts
+import { PriceCalculator } from '../shop/helpers.js';
+
+class CartSummary extends DC {
+	constructor(target: HTMLElement) {
+		super(target);
+		this.calculator = new PriceCalculator();
+	}
+}
+```
+
+Use for: reusable process-flow helpers, calculations, parsers, formatters — logic that
+is genuinely independent of the DOM. If the logic needs registry discoverability or
+lifecycle events, use a logic-only `DC` instead.
+
+---
+
+## 5. Plugins
+
+**Base:** none (functions) · **Registry:** none · **Renders:** nothing
+
+Plugins are functions that curry additional instance methods onto `McBase.prototype`,
+making them available on every `DC` and `MC` instance. They are called once at module
+level and are idempotent.
+
+```ts
+observePlugin(DC); // adds notify(), subscribe(), bind()
+formValuePlugin(DC); // adds formValues() — also pulls in observePlugin
+```
+
+Use for: cross-cutting behavior that every component should be able to chain — state
+observation, two-way form binding. A plugin is the right shape when the capability is
+orthogonal to what the component _is_ rather than part of its identity.
+
+---
+
+## 6. Utility Functions
+
+**Base:** none (plain exports) · **Registry:** none · **Renders:** nothing
+
+The public API for using Micro Components **outside** a `DC`/`MC` class — in plain
+JavaScript, alongside another framework, or in a non-component context.
+
+| Group           | Functions                                                                                                           |
+| --------------- | ------------------------------------------------------------------------------------------------------------------- |
+| Events          | `on`, `one`, `off`, `trigger`                                                                                       |
+| State           | `observe`, `formValues`                                                                                             |
+| Assets & styles | `loadAssets`, `processAssets`, `injectCSS`, `htmlToElements`                                                        |
+| Templates       | `parse`, `bindTemplateEvents`                                                                                       |
+| Registry        | `defineCE`, `getCE`, `listCE`                                                                                       |
+| Loading         | `autoload`                                                                                                          |
+| Helpers         | `debounce`, `deepEqual`, `flattenObject`, `sortObject`, `nameSpace`, `kebabToPascal`, `isNativeObject`, `isBrowser` |
+
+Inside a `DC`, prefer the instance equivalents (`this.on()`, `this.trigger()`,
+`this.subscribe()`) — see [implementation-priority](implementation-priority.md).
+
+---
+
+## Not an MC: Plain Custom Elements
+
+`defineCE` also accepts a class that does **not** extend `McBase`. In that case the class
+itself becomes the element and no `_mc` registry is attached. This is an escape hatch for
+interop with existing custom elements — it is not a Micro Component and gains none of the
+framework's conventions.
+
+---
+
+## Decision Flow
+
+```
+Does it need to be discoverable via getCE() / attachable via DC.add()?
+│
+├── No  → Is it DOM-free logic?
+│         ├── Yes → MC (pure logic)
+│         └── No  → Is it a cross-cutting capability for all components?
+│                   ├── Yes → Plugin
+│                   └── No  → Utility function
+│
+└── Yes → Does it render visible DOM?
+          ├── Yes → Visual DC
+          │         ├── Flat content        → target-based
+          │         ├── Regions / isolation → shadow-based
+          │         ├── Projects children   → composed (named slots)
+          │         └── No children         → leaf
+          │
+          └── No  → static tag = ''
+                    ├── Injects styles → style-only DC
+                    └── Runs logic     → logic-only DC
+```
+
+---
+
+## Related
+
+- [microcomponent-architecture](microcomponent-architecture.md) — composition model, `DC.add`
+- [custom-element-registry](custom-element-registry.md) — unified registration
+- [event-system](event-system.md) — handler conventions and lifecycle events
+- [state-management](state-management.md) — observables and form binding
+- [implementation-priority](implementation-priority.md) — which API tier to use

package/dist/mcp/concepts/microcomponent-architecture.md

@@ -0,0 +1,31 @@
+Micro Components are function blocks attached to DOM nodes. They use composition over inheritance and work like building blocks:
+
+Key principles:
+
+- Every visible element is a micro component extending DC
+- Pure logic (not DOM) extends MC
+- Register custom elements with defineCE()
+- Attach additional DOM logic with DC.add()
+- Minimal DOM interference: only _mc property on host elements
+- Works alongside any frontend framework
+- One class per file — see below
+
+## One Class Per File
+
+Every `.ts` or `.js` file contains exactly **one class**, regardless of which type it is:
+visual, logic-only, style-only, or pure logic. This applies to `DC` subclasses, `MC`
+subclasses, and any other class defined in `src/`.
+
+Why:
+
+- **Autoload resolution** — `autoload()` maps a tag name to a single script path
+  (`<shop-header>` → `./shop/header.js`). One class per file keeps that mapping
+  unambiguous.
+- **Companion files** — templates, styles, and data share the class's basename
+  (`header.target.html`, `header.css`). A second class in the same file would have no
+  place to put its own assets.
+- **Registry clarity** — `defineCE()` is called once per file, so file, class, and
+  registered tag stay in a 1:1 relationship.
+
+Non-class entities that belong to the class — interfaces, types, constants, plain
+functions — may live alongside it. A class that is reusable on its own gets its own file.

package/dist/mcp/concepts/state-management.md

@@ -0,0 +1,18 @@
+State management uses observable objects with reactive binding. Two usage patterns exist:
+
+**Standalone functions** (outside MC ecosystem):
+
+- observe(obj) — wraps properties in Observable wrappers; you manage subscribe/bind/notify manually
+- formValues(obj, prop, dom) — binds form controls to an observable property on the object
+
+**Plugins** (inside DC custom elements):
+
+- observePlugin(DC) — adds .notify(), .subscribe(), .bind() instance methods that implicitly create observables on demand
+- formValuePlugin(DC) — adds .formValues() instance method; also pulls in all observePlugin methods
+
+Key behaviors:
+
+- subscribe(callback) registers change listeners
+- bind(target) connects objects to DOM placeholders {propertyName} — only objects can be bound (primitives are ignored)
+- Deep change detection on nested objects with debounced notifications via microtask queue
+- The plugin methods take the property _name_ rather than the value, and are typed as `keyof this & string`: an undeclared or typo'd property is a compile error, and the `subscribe` callback parameter is inferred from the declared class field (`this.subscribe('count', (v) => v.toFixed(1))` — `v` is `number` without an annotation)

package/dist/mcp/index.d.ts

@@ -0,0 +1,3 @@
+#!/usr/bin/env node
+export {};
+//# sourceMappingURL=index.d.ts.map

package/dist/mcp/index.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../src/mcp/index.ts"],"names":[],"mappings":""}