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

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (2) hide show
  1. package/package.json +3 -3
  2. package/shared/sample-index.json +4 -4
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@public-ui/mcp",
3
- "version": "4.1.0-rc.0",
3
+ "version": "4.1.0",
4
4
  "license": "EUPL-1.2",
5
5
  "homepage": "https://public-ui.github.io",
6
6
  "repository": {
@@ -46,13 +46,13 @@
46
46
  "express": "5.2.1",
47
47
  "fuse.js": "7.1.0",
48
48
  "zod": "4.3.6",
49
- "@public-ui/components": "4.1.0-rc.0"
49
+ "@public-ui/components": "4.1.0"
50
50
  },
51
51
  "devDependencies": {
52
52
  "@eslint/js": "9.39.3",
53
53
  "@modelcontextprotocol/inspector": "0.21.0",
54
54
  "@types/express": "5.0.6",
55
- "@types/node": "25.3.0",
55
+ "@types/node": "25.3.1",
56
56
  "@typescript-eslint/eslint-plugin": "8.56.1",
57
57
  "@typescript-eslint/parser": "8.56.1",
58
58
  "eslint": "9.39.3",
package/shared/sample-index.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "metadata": {
3
- "generatedAt": "2026-02-25T12:56:15.631Z",
3
+ "generatedAt": "2026-02-26T14:10:44.288Z",
4
4
  "buildMode": "ci",
5
5
  "counts": {
6
6
  "total": 248,
@@ -10,7 +10,7 @@
10
10
  "totalScenarios": 18
11
11
  },
12
12
  "repo": {
13
- "commit": "4484b97170edfb7989ad16c53c7b138ad4bdce0e",
13
+ "commit": "eae24019adc3a0505672254410541725b227310b",
14
14
  "branch": "develop",
15
15
  "repoUrl": "https://github.com/public-ui/kolibri"
16
16
  }
@@ -85,7 +85,7 @@
85
85
  "group": "docs",
86
86
  "name": "CVE_OVERVIEW",
87
87
  "path": "docs/CVE_OVERVIEW.md",
88
- "code": "# CVE Overview\n\n> For more security information, see [SECURITY.md](./SECURITY.md)\n\n## 1. Production Dependencies\n\n### Summary\n\n| Severity | v4 | v3 | v2 | v1 |\n| -------- | --: | --: | --: | --: |\n| critical | 0 | 0 | 0 | 0 |\n| high | 1 | 1 | 1 | 7 |\n| moderate | 1 | 1 | 1 | 9 |\n| low | 0 | 0 | 0 | 4 |\n| info | 0 | 0 | 0 | 0 |\n| unknown | 0 | 0 | 0 | 0 |\n\n### Vulnerabilities\n\n| Package | Severity | CVE | Affected Versions | Description |\n| -------------------- | -------- | ------------------- | ----------------- | -------------------------------------------------------------------------------- |\n| lodash.pick | high | CVE-2020-8203 | v1 | Prototype Pollution in lodash |\n| minimatch | high | CVE-2026-26996 | v4, v3, v2, v1 | minimatch has a ReDoS via repeated wildcards with non-matching literal in patter |\n| playwright | high | CVE-2025-59288 | v1 | Playwright downloads and installs browsers without verifying the authenticity of |\n| qs | high | CVE-2025-15284 | v1 | qs's arrayLimit bypass in its bracket notation allows DoS via memory exhaustion |\n| semver | high | CVE-2022-25883 | v1 | semver vulnerable to Regular Expression Denial of Service |\n| ajv | moderate | CVE-2025-69873 | v4, v3, v2, v1 | ajv has ReDoS when using `$data` option |\n| ejs | moderate | CVE-2024-33883 | v1 | ejs lacks certain pollution protection |\n| esbuild | moderate | GHSA-67mh-4wv8-2f99 | v1 | esbuild enables any website to send any requests to the development server and r |\n| js-yaml | moderate | CVE-2025-64718 | v1 | js-yaml has prototype pollution in merge (<<) |\n| nanoid | moderate | CVE-2024-55565 | v1 | Predictable results in nanoid generation when given non-integer values |\n| serialize-javascript | moderate | CVE-2024-11831 | v1 | Cross-site Scripting (XSS) in serialize-javascript |\n| webpack | moderate | CVE-2024-43788 | v1 | Webpack's AutoPublicPathRuntimeModule has a DOM Clobbering Gadget that leads to |\n| webpack-dev-server | moderate | CVE-2025-30360 | v1 | webpack-dev-server users' source code may be stolen when they access a malicious |\n| webpack-dev-server | moderate | CVE-2025-30359 | v1 | webpack-dev-server users' source code may be stolen when they access a malicious |\n| diff | low | CVE-2026-24001 | v1 | jsdiff has a Denial of Service vulnerability in parsePatch and applyPatch |\n| qs | low | CVE-2026-2391 | v1 | qs's arrayLimit bypass in comma parsing allows denial of service |\n| webpack | low | CVE-2025-68458 | v1 | webpack buildHttp: allowedUris allow-list bypass via URL userinfo (@) leading to |\n| webpack | low | CVE-2025-68157 | v1 | webpack buildHttp HttpUriPlugin allowedUris bypass via HTTP redirects → SSRF + c |\n\n## 2. All Dependencies\n\n### Summary\n\n| Severity | v4 | v3 | v2 | v1 |\n| -------- | --: | --: | --: | --: |\n| critical | 2 | 2 | 2 | 1 |\n| high | 8 | 8 | 11 | 16 |\n| moderate | 3 | 3 | 11 | 10 |\n| low | 2 | 2 | 6 | 4 |\n| info | 0 | 0 | 0 | 0 |\n| unknown | 0 | 0 | 0 | 0 |\n\n### Vulnerabilities\n\n| Package | Severity | CVE | Affected Versions | Description |\n| -------------------- | -------- | ------------------- | ----------------- | -------------------------------------------------------------------------------- |\n| fast-xml-parser | critical | CVE-2026-25896 | v4, v3, v2 | fast-xml-parser has an entity encoding bypass via regex injection in DOCTYPE ent |\n| locutus | critical | CVE-2026-25521 | v4, v3, v2, v1 | locutus is vulnerable to Prototype Pollution |\n| @angular/common | high | CVE-2025-66035 | v1 | Angular is Vulnerable to XSRF Token Leakage via Protocol-Relative URLs in Angula |\n| @angular/compiler | high | CVE-2025-66412 | v1 | Angular Stored XSS Vulnerability via SVG Animation, SVG URL and MathML Attribute |\n| @angular/compiler | high | CVE-2026-22610 | v1 | Angular has XSS Vulnerability via Unsanitized SVG Script Attributes |\n| @angular/core | high | CVE-2026-22610 | v1 | Angular has XSS Vulnerability via Unsanitized SVG Script Attributes |\n| axios | high | CVE-2026-25639 | v4, v3, v2 | Axios is Vulnerable to Denial of Service via **proto** Key in mergeConfig |\n| braces | high | CVE-2024-4068 | v4, v3, v2, v1 | Uncontrolled resource consumption in braces |\n| fast-xml-parser | high | CVE-2026-25128 | v4, v3, v2 | fast-xml-parser has RangeError DoS Numeric Entities Bug |\n| fast-xml-parser | high | CVE-2026-26278 | v4, v3, v2 | fast-xml-parser affected by DoS through entity expansion in DOCTYPE (no expansio |\n| lodash.pick | high | CVE-2020-8203 | v2, v1 | Prototype Pollution in lodash |\n| minimatch | high | CVE-2026-26996 | v4, v3, v2, v1 | minimatch has a ReDoS via repeated wildcards with non-matching literal in patter |\n| playwright | high | CVE-2025-59288 | v1 | Playwright downloads and installs browsers without verifying the authenticity of |\n| qs | high | CVE-2025-15284 | v4, v3, v2, v1 | qs's arrayLimit bypass in its bracket notation allows DoS via memory exhaustion |\n| semver | high | CVE-2022-25883 | v2, v1 | semver vulnerable to Regular Expression Denial of Service |\n| tar | high | CVE-2026-23950 | v1 | Race Condition in node-tar Path Reservations via Unicode Ligature Collisions on |\n| tar | high | CVE-2026-24842 | v1 | node-tar Vulnerable to Arbitrary File Creation/Overwrite via Hardlink Path Trave |\n| tar | high | CVE-2026-23745 | v1 | node-tar is Vulnerable to Arbitrary File Overwrite and Symlink Poisoning via Ins |\n| tar | high | CVE-2026-26960 | v4, v3, v2, v1 | Arbitrary File Read/Write via Hardlink Target Escape Through Symlink Chain in no |\n| ajv | moderate | CVE-2025-69873 | v4, v3, v2, v1 | ajv has ReDoS when using `$data` option |\n| ejs | moderate | CVE-2024-33883 | v2, v1 | ejs lacks certain pollution protection |\n| esbuild | moderate | GHSA-67mh-4wv8-2f99 | v2, v1 | esbuild enables any website to send any requests to the development server and r |\n| js-yaml | moderate | CVE-2025-64718 | v2, v1 | js-yaml has prototype pollution in merge (<<) |\n| micromatch | moderate | CVE-2024-4067 | v4, v3, v2, v1 | Regular Expression Denial of Service (ReDoS) in micromatch |\n| nanoid | moderate | CVE-2024-55565 | v2, v1 | Predictable results in nanoid generation when given non-integer values |\n| serialize-javascript | moderate | CVE-2024-11831 | v2, v1 | Cross-site Scripting (XSS) in serialize-javascript |\n| webpack | moderate | CVE-2024-43788 | v2, v1 | Webpack's AutoPublicPathRuntimeModule has a DOM Clobbering Gadget that leads to |\n| webpack-dev-server | moderate | CVE-2025-30360 | v2, v1 | webpack-dev-server users' source code may be stolen when they access a malicious |\n| webpack-dev-server | moderate | CVE-2025-30359 | v2, v1 | webpack-dev-server users' source code may be stolen when they access a malicious |\n| diff | low | CVE-2026-24001 | v4, v3, v2, v1 | jsdiff has a Denial of Service vulnerability in parsePatch and applyPatch |\n| hono | low | GHSA-gq3j-xvxp-8hrf | v2 | Hono added timing comparison hardening in basicAuth and bearerAuth |\n| qs | low | CVE-2026-2391 | v4, v3, v2, v1 | qs's arrayLimit bypass in comma parsing allows denial of service |\n| webpack | low | CVE-2025-68458 | v2, v1 | webpack buildHttp: allowedUris allow-list bypass via URL userinfo (@) leading to |\n| webpack | low | CVE-2025-68157 | v2, v1 | webpack buildHttp HttpUriPlugin allowedUris bypass via HTTP redirects → SSRF + c |\n",
88
+ "code": "# CVE Overview\n\n> For more security information, see [SECURITY.md](./SECURITY.md)\n\n## 1. Production Dependencies\n\n### Summary\n\n| Severity | v4 | v3 | v2 | v1 |\n| -------- | --: | --: | --: | --: |\n| critical | 0 | 0 | 0 | 1 |\n| high | 1 | 1 | 2 | 8 |\n| moderate | 1 | 1 | 1 | 9 |\n| low | 0 | 0 | 0 | 4 |\n| info | 0 | 0 | 0 | 0 |\n| unknown | 0 | 0 | 0 | 0 |\n\n### Vulnerabilities\n\n| Package | Severity | CVE | Affected Versions | Description |\n| -------------------- | -------- | ------------------- | ----------------- | -------------------------------------------------------------------------------- |\n| basic-ftp | critical | CVE-2026-27699 | v1 | Basic FTP has Path Traversal Vulnerability in its downloadToDir() method |\n| lodash.pick | high | CVE-2020-8203 | v1 | Prototype Pollution in lodash |\n| minimatch | high | CVE-2026-26996 | v4, v3, v2, v1 | minimatch has a ReDoS via repeated wildcards with non-matching literal in patter |\n| playwright | high | CVE-2025-59288 | v1 | Playwright downloads and installs browsers without verifying the authenticity of |\n| qs | high | CVE-2025-15284 | v1 | qs's arrayLimit bypass in its bracket notation allows DoS via memory exhaustion |\n| rollup | high | CVE-2026-27606 | v2, v1 | Rollup 4 has Arbitrary File Write via Path Traversal |\n| semver | high | CVE-2022-25883 | v1 | semver vulnerable to Regular Expression Denial of Service |\n| ajv | moderate | CVE-2025-69873 | v4, v3, v2, v1 | ajv has ReDoS when using `$data` option |\n| ejs | moderate | CVE-2024-33883 | v1 | ejs lacks certain pollution protection |\n| esbuild | moderate | GHSA-67mh-4wv8-2f99 | v1 | esbuild enables any website to send any requests to the development server and r |\n| js-yaml | moderate | CVE-2025-64718 | v1 | js-yaml has prototype pollution in merge (<<) |\n| nanoid | moderate | CVE-2024-55565 | v1 | Predictable results in nanoid generation when given non-integer values |\n| serialize-javascript | moderate | CVE-2024-11831 | v1 | Cross-site Scripting (XSS) in serialize-javascript |\n| webpack | moderate | CVE-2024-43788 | v1 | Webpack's AutoPublicPathRuntimeModule has a DOM Clobbering Gadget that leads to |\n| webpack-dev-server | moderate | CVE-2025-30360 | v1 | webpack-dev-server users' source code may be stolen when they access a malicious |\n| webpack-dev-server | moderate | CVE-2025-30359 | v1 | webpack-dev-server users' source code may be stolen when they access a malicious |\n| diff | low | CVE-2026-24001 | v1 | jsdiff has a Denial of Service vulnerability in parsePatch and applyPatch |\n| qs | low | CVE-2026-2391 | v1 | qs's arrayLimit bypass in comma parsing allows denial of service |\n| webpack | low | CVE-2025-68458 | v1 | webpack buildHttp: allowedUris allow-list bypass via URL userinfo (@) leading to |\n| webpack | low | CVE-2025-68157 | v1 | webpack buildHttp HttpUriPlugin allowedUris bypass via HTTP redirects → SSRF + c |\n\n## 2. All Dependencies\n\n### Summary\n\n| Severity | v4 | v3 | v2 | v1 |\n| -------- | --: | --: | --: | --: |\n| critical | 3 | 3 | 3 | 2 |\n| high | 8 | 8 | 12 | 18 |\n| moderate | 3 | 3 | 11 | 10 |\n| low | 1 | 1 | 6 | 4 |\n| info | 0 | 0 | 0 | 0 |\n| unknown | 0 | 0 | 0 | 0 |\n\n### Vulnerabilities\n\n| Package | Severity | CVE | Affected Versions | Description |\n| -------------------- | -------- | ------------------- | ----------------- | -------------------------------------------------------------------------------- |\n| basic-ftp | critical | CVE-2026-27699 | v4, v3, v2, v1 | Basic FTP has Path Traversal Vulnerability in its downloadToDir() method |\n| fast-xml-parser | critical | CVE-2026-25896 | v4, v3, v2 | fast-xml-parser has an entity encoding bypass via regex injection in DOCTYPE ent |\n| locutus | critical | CVE-2026-25521 | v4, v3, v2, v1 | locutus is vulnerable to Prototype Pollution |\n| @angular/common | high | CVE-2025-66035 | v1 | Angular is Vulnerable to XSRF Token Leakage via Protocol-Relative URLs in Angula |\n| @angular/compiler | high | CVE-2025-66412 | v1 | Angular Stored XSS Vulnerability via SVG Animation, SVG URL and MathML Attribute |\n| @angular/compiler | high | CVE-2026-22610 | v1 | Angular has XSS Vulnerability via Unsanitized SVG Script Attributes |\n| @angular/core | high | CVE-2026-22610 | v1 | Angular has XSS Vulnerability via Unsanitized SVG Script Attributes |\n| axios | high | CVE-2026-25639 | v4, v3, v2 | Axios is Vulnerable to Denial of Service via **proto** Key in mergeConfig |\n| braces | high | CVE-2024-4068 | v4, v3, v2, v1 | Uncontrolled resource consumption in braces |\n| fast-xml-parser | high | CVE-2026-25128 | v4, v3, v2 | fast-xml-parser has RangeError DoS Numeric Entities Bug |\n| fast-xml-parser | high | CVE-2026-26278 | v4, v3, v2 | fast-xml-parser affected by DoS through entity expansion in DOCTYPE (no expansio |\n| lodash.pick | high | CVE-2020-8203 | v2, v1 | Prototype Pollution in lodash |\n| minimatch | high | CVE-2026-26996 | v4, v3, v2, v1 | minimatch has a ReDoS via repeated wildcards with non-matching literal in patter |\n| playwright | high | CVE-2025-59288 | v1 | Playwright downloads and installs browsers without verifying the authenticity of |\n| qs | high | CVE-2025-15284 | v2, v1 | qs's arrayLimit bypass in its bracket notation allows DoS via memory exhaustion |\n| rollup | high | CVE-2026-27606 | v4, v3, v2, v1 | Rollup 4 has Arbitrary File Write via Path Traversal |\n| semver | high | CVE-2022-25883 | v2, v1 | semver vulnerable to Regular Expression Denial of Service |\n| tar | high | CVE-2026-23950 | v1 | Race Condition in node-tar Path Reservations via Unicode Ligature Collisions on |\n| tar | high | CVE-2026-24842 | v1 | node-tar Vulnerable to Arbitrary File Creation/Overwrite via Hardlink Path Trave |\n| tar | high | CVE-2026-23745 | v1 | node-tar is Vulnerable to Arbitrary File Overwrite and Symlink Poisoning via Ins |\n| tar | high | CVE-2026-26960 | v4, v3, v2, v1 | Arbitrary File Read/Write via Hardlink Target Escape Through Symlink Chain in no |\n| ajv | moderate | CVE-2025-69873 | v4, v3, v2, v1 | ajv has ReDoS when using `$data` option |\n| ejs | moderate | CVE-2024-33883 | v2, v1 | ejs lacks certain pollution protection |\n| esbuild | moderate | GHSA-67mh-4wv8-2f99 | v2, v1 | esbuild enables any website to send any requests to the development server and r |\n| js-yaml | moderate | CVE-2025-64718 | v2, v1 | js-yaml has prototype pollution in merge (<<) |\n| micromatch | moderate | CVE-2024-4067 | v4, v3, v2, v1 | Regular Expression Denial of Service (ReDoS) in micromatch |\n| nanoid | moderate | CVE-2024-55565 | v2, v1 | Predictable results in nanoid generation when given non-integer values |\n| serialize-javascript | moderate | CVE-2024-11831 | v2, v1 | Cross-site Scripting (XSS) in serialize-javascript |\n| webpack | moderate | CVE-2024-43788 | v2, v1 | Webpack's AutoPublicPathRuntimeModule has a DOM Clobbering Gadget that leads to |\n| webpack-dev-server | moderate | CVE-2025-30360 | v2, v1 | webpack-dev-server users' source code may be stolen when they access a malicious |\n| webpack-dev-server | moderate | CVE-2025-30359 | v2, v1 | webpack-dev-server users' source code may be stolen when they access a malicious |\n| diff | low | CVE-2026-24001 | v4, v3, v2, v1 | jsdiff has a Denial of Service vulnerability in parsePatch and applyPatch |\n| hono | low | GHSA-gq3j-xvxp-8hrf | v2 | Hono added timing comparison hardening in basicAuth and bearerAuth |\n| qs | low | CVE-2026-2391 | v2, v1 | qs's arrayLimit bypass in comma parsing allows denial of service |\n| webpack | low | CVE-2025-68458 | v2, v1 | webpack buildHttp: allowedUris allow-list bypass via URL userinfo (@) leading to |\n| webpack | low | CVE-2025-68157 | v2, v1 | webpack buildHttp HttpUriPlugin allowedUris bypass via HTTP redirects → SSRF + c |\n",
89
89
  "kind": "doc"
90
90
  },
91
91
  {
@@ -1573,7 +1573,7 @@
1573
1573
  "group": "spec",
1574
1574
  "name": "_skeleton",
1575
1575
  "path": "packages/tools/mcp/node_modules/@public-ui/components/doc/_skeleton.md",
1576
- "code": "# Controller Performance Analyse\n\n## Executive Summary\n\nDie KoliBri-Komponenten verwenden aktuell **Pattern 1: `new` pro Web Component** für Controller-Instanzen. Dieser Ansatz bietet starke Isolation und Einfachheit:\n\n- ✅ **Zugänglichkeit**: State bleibt vollständig pro Komponenten-Instanz isoliert\n- ✅ **Stabilität**: Keine Race Conditions durch Shared State\n- ✅ **Wartbarkeit**: Klare 1:1-Zuordnung WC ↔ Controller, einfach zu verstehen\n- ✅ **Debuggbarkeit**: Straightforward Debugging ohne Pool-Komplexität\n- ⚠️ **RAM**: ~60 KB für 100 Instanzen (akzeptabel, aber nicht minimal)\n\n> **Future Consideration**: [Pattern 3 (WeakMap Pool)](#pattern-3-weakmap-pool-future) könnte für massive Skalierung (1000+ Komponenten) erwogen werden, but current implementation prioritizes simplicity and stability.\n\n## Szenario: 100 `<kol-click-button>` Komponenten im DOM\n\n### Memory-Footprint pro Controller\n\nAnnahmen:\n\n- Pro ClickButtonController: ~500 Bytes (State + Methoden-Referenzen)\n- Overhead JavaScript Engine: ~100 Bytes pro Instanz\n\n## Pattern 1: `new` pro Web Component (Aktuell) ✅\n\n```typescript\n// Web Component:\nexport class KolClickButton {\n\tprivate readonly ctrl = new ClickButtonController(); // ✅ 1× pro WC-Instanz\n}\n```\n\n### Charakteristiken\n\n| Metrik | Wert |\n| ------------------------ | -------------------------- |\n| **Controller-Instanzen** | 100 |\n| **RAM (Gesamt)** | ~60 KB |\n| **Constructor Aufrufe** | 100 |\n| **Share State möglich?** | ❌ Nein (isoliert) |\n| **Memory Leak Risk** | ✅ Niedrig (GC-freundlich) |\n| **Wartbarkeit** | ✅ Einfach |\n| **Performance Scaling** | ❌ Linear schlecht |\n\n### Vorteile\n\n- ✅ Maximale Isolation pro Komponenten-Instanz\n- ✅ Keine Komplexität mit Pools/Factories\n- ✅ Debugging einfach (1:1 Mapping)\n- ✅ Test-freundlich (Mock ist straightforward)\n\n### Nachteile\n\n- ❌ 100× redundante Instanzen\n- ❌ 100× Constructor-Aufrufe bei Mount\n- ❌ bei 1000 Komponenten: 500+ KB Ram verschwendet\n- ❌ Redundante Methoden-Referenzen (`handleClick`, `setButtonRef` 100×)\n\n### Reale Performance-Impact\n\n```\nAnwendungsfall: Single Page mit 100 Buttons\n─────────────────────────────────────────\nInitial Load: +25ms (100× Constructor-Aufrufe)\nMemory: +60 KB (100 Controller × 600 Bytes)\nRuntime: Neutral (jeder Controller ist optimiert)\nGarbage: Gut (GC hat leichte Zeit)\n```\n\n## Pattern 2: Reiner Singleton (1 Controller für ALLE)\n\n```typescript\n// Controller:\nexport const clickButtonController = { // ✅ 1× global\n validateLabel: (value) => { ... },\n handleClick: (callback) => { ... },\n};\n\n// Web Component:\nexport class KolClickButton {\n private readonly ctrl = clickButtonController; // ✅ Referenz, kein new\n private buttonRef?: HTMLButtonElement; // ❌ State in WC\n}\n```\n\n### Charakteristiken\n\n| Metrik | Wert |\n| ------------------------ | -------------------------------------------- |\n| **Controller-Instanzen** | 1 |\n| **RAM (Gesamt)** | ~1 KB + 100× State-Duplikate in WCs |\n| **Constructor Aufrufe** | 1 |\n| **Share State möglich?** | ✅ Ja (aber problematisch!) |\n| **Memory Leak Risk** | ✅ Sehr niedrig |\n| **Wartbarkeit** | ⚠️ Hybrid (State in WC, Logik in Controller) |\n| **Performance Scaling** | ✅ Konstant |\n\n### Vorteile\n\n- ✅ Minimale Controller-Instanzen\n- ✅ Shared Validierungslogik\n- ✅ Performance bei scale-out\n- ✅ GC-Druck minimal\n\n### Nachteile\n\n- ❌ **State muss in Web Component sitzen** → WC wird fett\n- ❌ Schwer zu verstehen: \"Wo lebt welcher State?\"\n- ❌ **Shared State Bug-Gefahr**: `buttonRef` zeigt auf zuletzt geclickten Button\n- ❌ Logik und State getrennt → Cognitive Load hoch\n- ❌ Proxy-Methoden in WC (State-Übergabe)\n- ⚠️ Test-Komplexität: Mock-State ist versteckt\n\n### Reale Performance-Impact\n\n```\nAnwendungsfall: Single Page mit 100 Buttons\n─────────────────────────────────────────\nInitial Load: -20ms (nur 1× Constructor)\nMemory: -58 KB (100 Controllers gespart)\nRuntime: + komplexere State-Übergabe\nWartbarkeit: 😞 WC ist kompliziert\nDebugging: 😞 \"Wo ist der State?\"\n```\n\n### Das Shared-State-Problem\n\n```typescript\n// ❌ KRITISCHER BUG mit Singleton:\nexport const clickButtonController = {\n private buttonRef?: HTMLButtonElement; // ⚠️ Geteilt!\n\n setButtonRef: (el) => { this.buttonRef = el; },\n focus: () => this.buttonRef?.focus(), // ❌ Focus auf LETZTEN Button!\n};\n\n// HTML:\n<button id=\"btn1\"></button>\n<button id=\"btn2\"></button>\n\n// Szenario:\n// 1. btn1.setButtonRef(btn1_element)\n// 2. btn2.setButtonRef(btn2_element) // ⚠️ Überschreibt!\n// 3. clickButtonController.focus() // 🐛 Fokussiert btn2, nicht btn1!\n```\n\n## Pattern 3: WeakMap Pool (Zukünftige Alternative) 🔮\n\n```typescript\n// BaseController:\nexport abstract class BaseController {\n\tprotected static readonly pool = new WeakMap<object, BaseController>();\n}\n\n// ClickButtonController:\nexport class ClickButtonController extends BaseController {\n\tprivate static readonly pool = new WeakMap<object, ClickButtonController>();\n\n\tprivate buttonRef?: HTMLButtonElement; // ✅ Pro Instanz\n\n\tpublic static getOrCreate(wcInstance: object): ClickButtonController {\n\t\tif (!this.pool.has(wcInstance)) {\n\t\t\tthis.pool.set(wcInstance, new ClickButtonController());\n\t\t}\n\t\treturn this.pool.get(wcInstance)!;\n\t}\n}\n\n// Web Component:\nexport class KolClickButton {\n\tprivate readonly ctrl = ClickButtonController.getOrCreate(this); // 🔮 Optional future\n}\n```\n\n### Charakteristiken\n\n| Metrik | Wert |\n| ------------------------ | ------------------------------------- |\n| **Controller-Instanzen** | 100 (aber pooled) |\n| **RAM (Gesamt)** | ~60 KB |\n| **Constructor Aufrufe** | 100 (aber 1× pro Komponenten-Instanz) |\n| **Share State möglich?** | ❌ Nein (isoliert) |\n| **Memory Leak Risk** | ✅ Minimal (WeakMap GC) |\n| **Wartbarkeit** | ✅ Sehr gut |\n| **Performance Scaling** | ✅ Linear akzeptabel |\n\n### Vorteile\n\n- ✅ Staat bleibt pro Komponenten-Instanz isoliert\n- ✅ Keine Shared-State-Bugs\n- ✅ Logik BLEIBT im Controller (WC bleibt schlank)\n- ✅ Auto-Cleanup via WeakMap\n- ✅ Memory Leak-frei\n- ✅ Einfach zu verstehen: \"1 WC = 1 Controller\"\n- ✅ Test-freundlich\n- ✅ Debuggbar\n\n### Nachteile\n\n- ⚠️ 100 Controller-Instanzen (statt 1)\n- ⚠️ ~60 KB RAM statt 1 KB (akzeptabel bei moderaten Komponenten-Zahlen)\n- ⚠️ Nicht maximale Performance-Optimierung\n\n### Reale Performance-Impact\n\n```\nAnwendungsfall: Single Page mit 100 Buttons\n─────────────────────────────────────────\nInitial Load: +10ms (100 Constructors, aber gecacht)\nMemory: ~60 KB (100 Controller × 600 Bytes)\nRuntime: Neutral (optimierte Methoden)\nGarbage: ✅ Gut (WeakMap GC ist effizient)\nWartbarkeit: ✅ Exzellent\nDebugging: ✅ Sehr gut\nStabilität: ✅ Keine Race Conditions\n```\n\n## Pattern 4: Klassischer Singleton mit Private Constructor\n\n```typescript\n// ClickButtonController:\nexport class ClickButtonController {\n\tprivate static instance: ClickButtonController;\n\tprivate buttonRef?: HTMLButtonElement; // ❌ Geteilt!\n\n\tprivate constructor() {}\n\n\tpublic static getInstance(): ClickButtonController {\n\t\tif (!this.instance) {\n\t\t\tthis.instance = new ClickButtonController();\n\t\t}\n\t\treturn this.instance;\n\t}\n}\n\n// Web Component:\nexport class KolClickButton {\n\tprivate readonly ctrl = ClickButtonController.getInstance(); // ✅ 1× Instance\n}\n```\n\n### Charakteristiken\n\n| Metrik | Wert |\n| ------------------------ | ---------------------- |\n| **Controller-Instanzen** | 1 |\n| **RAM (Gesamt)** | ~1 KB |\n| **Constructor Aufrufe** | 1 |\n| **Share State möglich?** | ✅ Ja (problematisch!) |\n| **Memory Leak Risk** | ✅ Sehr niedrig |\n| **Wartbarkeit** | ❌ Problematisch |\n| **Performance Scaling** | ✅ Konstant |\n\n### Probleme (identisch mit Pattern 2)\n\n- ❌ **Shared State zwischen allen Komponenten**\n- ❌ `buttonRef` zeigt auf zuletzt registrierte Komponente\n- ❌ 100 `<kol-click-button>` müssen State extern verwalten\n- ❌ Race Conditions möglich\n- ❌ Nicht-Thread-Safe (theoretisch, aber JS ist Single-Threaded)\n\n### Reale Performance-Impact\n\n```\nMemory: ⭐⭐⭐⭐⭐ (1 KB)\nPerformance: ⭐⭐⭐⭐⭐ (keine Constructor)\nStabilität: ⭐☆☆☆☆ (Shared State Bugs!)\nWartbarkeit: ⭐☆☆☆☆ (State versteckt)\nScaling: ⭐⭐⭐⭐⭐ (konstant)\n```\n\n## Vergleich aller Patterns\n\n```\n┌─────────────────────────────────────────────────────────────┐\n│ Pattern │ RAM │ Performance │ Stabilität │ Wart. │\n├──────────────────┼──────────┼─────────────┼────────────┼────────┤\n│ new pro WC ✅ │ 60 KB │ ⚠️ Linear │ ✅ Gut │ ✅ Gut │\n│ Reiner Singleton │ 1 KB │ ✅ Optimal │ ❌ Bugs │ ❌ Komplex│\n│ WeakMap Pool 🔮 │ 60 KB │ ⚠️ Akzeptabel│ ✅ Gut │ ✅ Sehr gut│\n│ Klassisches Sing.│ 1 KB │ ✅ Optimal │ ❌ Bugs │ ❌ Schlecht│\n└─────────────────────────────────────────────────────────────┘\n```\n\n## Warum aktuell Pattern 1 (`new` pro WC)?\n\n### 1. **Stabilität first**\n\n```\nAnforderung: 100+ Komponenten ohne Bugs\n─────────────────────────────────────────\n✅ new pro WC: Jede WC hat ihren Controller, volle Isolation\n⚠️ WeakMap Pool: Zusätzliche Komplexität für später, wenn nötig\n❌ Singleton: Shared State → Focus-Bug auf falscher Komponente\n```\n\n### 2. **Zugänglichkeit**\n\n```\nAnforderung: Code muss für neue Entwickler verständlich sein\n──────────────────────────────────────────────────────────\n✅ new pro WC: \"Diese WC erstellt einen Controller\" – einfach und klar\n⚠️ WeakMap Pool: \"Pool-Pattern mit WeakMap+getOrCreate\" – mehr Denkaufwand\n❌ Singleton: \"State ist... irgendwo anders?\"\n```\n\n### 3. **RAM vs. Verständlichkeit Trade-off**\n\n```\nSzenario: Typische Anwendung mit 100 Komponenten\n────────────────────────────────────────────────\nnew pro WC: ~60 KB RAM (akzeptabel, verständlich)\nWeakMap Pool: ~60 KB RAM (identisch, aber komplexer)\nSingleton: ~2 KB RAM (aber: 10+ Stunden Debugging für Race Conditions)\n```\n\n**Kosten-Nutzen:**\n\n- new pro WC: Klarheit + Stabilität > minimale RAM-Ersparnis\n- Wenn Skalierung (1000+) nötig wird: dann auf WeakMap Pool migrieren\n\n### 4. **Skalierbarkeit später**\n\n```\nWenn später 1000+ Komponenten im DOM?\n──────────────────────────────────────\nnew pro WC: ~600 KB RAM (linear, aber noch okay für Moderns UIs)\nWeakMap Pool: ~600 KB RAM (identisch, dann würde Optimierung mehr Sinn machen)\nSingleton: ~2 KB RAM (aber 1000× Potential für Bugs = unmaintainable)\n\nRealität: 1000 Komponenten kommen vor (Virtual Scrolling, Data Tables)\nLösung: WeakMap Pool beschrieben + kann später hinzugefügt werden\nStatus Quo: new pro WC ist der bessere Default\n```\n\n## Micro-Optimierungen (Zukunft)\n\nFalls die Anwendung wirklich in extreme Skalierung geht (1000+ gleichzeitig im DOM):\n\n### Option A: Object Pool mit Max-Size\n\n```typescript\nprivate static readonly pool = new WeakMap<object, ClickButtonController>();\nprivate static readonly maxPoolSize = 100;\n\npublic static getOrCreate(wcInstance: object): ClickButtonController {\n if (this.pool.size >= this.maxPoolSize) {\n // Cleanup alte Instanzen\n // Aber: WeakMap hat keine .size Property\n }\n // ...\n}\n```\n\n### Option B: Lazy Initialization für Häufige Props\n\n```typescript\n// Cache häufige Validierungen\nconst LABEL_CACHE = new Map<string, LabelPropType>();\n\npublic watchLabel(value?: LabelPropType): void {\n if (LABEL_CACHE.has(value!)) {\n this.setProp('label', LABEL_CACHE.get(value!)!);\n return;\n }\n // Teuer Validierung\n const normalized = labelProp.normalize(value);\n LABEL_CACHE.set(value!, normalized);\n this.setProp('label', normalized);\n}\n```\n\n### Option C: Shared Stateless Validators\n\n```typescript\n// Nur Validierung teilen, State bleibt privat\nexport const createClickButtonValidators = () => ({\n validateLabel: (value?: LabelPropType) => { ... },\n});\n\n// Dann: 1× Validator, 100× Controller\n```\n\n## Architektur-Entscheidung: Pattern 1 (`new` pro WC) – Aktuell\n\n### Begründung\n\n1. **Zugänglichkeit**: Neue Entwickler verstehen schnell: \"1 WC = 1 Controller\"\n2. **Stabilität**: Keine Shared-State-Bugs, Race-Conditions ausgeschlossen\n3. **Wartbarkeit**: Logik bleibt zentral im Controller, WC bleibt schlank\n4. **Performance**: 60 KB für 100 Komponenten ist ein akzeptabler Trade-off\n5. **Debugging**: Straightforward, kein Pool-Overhead\n6. **Zukunftssicherheit**: Kann später zu WeakMap Pool migrieren, wenn nötig\n\n### Nicht-Ziele (bewusst)\n\n- ❌ Maximale RAM-Effizienz um jeden Preis\n- ❌ Complexe Pooling-Mechaniken für Szenarien, die nicht häufig sind\n- ❌ Micro-Optimierungen ohne Nutzen\n\n### Trade-off Akzeptanz\n\n```\nWas wir AUFGEBEN: 58 KB RAM pro 100 Komponenten, etwas mehr Constructor-Aufrufe\nWas wir GEWINNEN:\n ✅ Stabile, verständliche Architektur\n ✅ Verständlicher Code für alle Entwickler\n ✅ Keine Race Conditions\n ✅ Test-freundlich\n ✅ Einfach zu debuggen\n ✅ Kann später zu WeakMap Pattern migrieren\n```\n\n### Zukünftige Überlegung\n\nFalls die Anwendung in extreme Skalierung geht (1000+ gleichzeitig im DOM), kann **Pattern 3 (WeakMap Pool)** in einem Major-Release eingebaut werden, ohne dass die API bricht – die Änderung würde nur in den Internals stattfinden.\n\n## Messungen (reale Szenarien)\n\n### Szenario 1: React Sample mit 50 Skeleton Komponenten\n\n```\nInitial Load:\n new pro WC: ~8ms\n WeakMap Pool: ~7ms\n Differenz: -1ms (irrelevant)\n\nMemory (Chrome DevTools):\n new pro WC: ~25 KB\n WeakMap Pool: ~25 KB\n Differenz: 0 KB (gleich)\n\nLaufzeit GC:\n new pro WC: ~2ms (GC nach Unmount)\n WeakMap Pool: ~0.5ms (WeakMap GC ist effizienter)\n```\n\n### Szenario 2: Table mit 100 Rows (100× Row Component)\n\n```\nInitial Load:\n new pro WC: ~45ms\n WeakMap Pool: ~42ms\n Differenz: -3ms (irrelevant)\n\nMemory:\n new pro WC: ~60 KB\n WeakMap Pool: ~60 KB\n Differenz: 0 KB (identisch)\n\nInteraktion (Focus/Blur):\n new pro WC: ~0.1ms pro Focus\n WeakMap Pool: ~0.1ms pro Focus\n Differenz: 0ms (identisch)\n```\n\n## Conclusion\n\n**Pattern 1 (`new` pro WC) ist die richtige Wahl für KoliBri – aktuell und kurzfristig**, weil:\n\n1. **Performance**: Akzeptabel, kein messbarer Unterschied in echten Apps\n2. **Stabilität**: Garantiert keine Race Conditions\n3. **Code-Qualität**: Wartbar, verständlich, testbar\n4. **Developer Experience**: \"1 WC = 1 Controller\" ist unmittelbar verständlich\n5. **Zukunftssicherheit**: Kann später zu WeakMap Pool migriert werden, wenn die Skalierung (1000+) es erfordert\n\nDies ist die beste Wahl für die aktuelle Phase der KoliBri-Entwicklung: **Klarheit und Stabilität vor theoretischer Optimalität**. Wenn die Skalierung später ein Problem wird, ist Pattern 3 beschrieben und kann dann hinzugefügt werden.\n\n## Referenzen\n\n- [WeakMap MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WeakMap)\n- [Stencil Component Lifecycle](https://stenciljs.com/docs/component-lifecycle)\n- [Performance Best Practices](https://web.dev/performance/)\n",
1576
+ "code": "# Refactoring-Auftrag: Komponente auf Skeleton/Internals-Architektur migrieren\n\n## Rolle\n\nDu bist ein **Senior Software Architect und Developer** mit über 15 Jahren Erfahrung in komponentenbasierter Frontend-Architektur. Du legst höchsten Wert auf:\n\n- **Clean Architecture** — klare Schichtentrennung, Single Responsibility, Dependency Inversion.\n- **Wartbarkeit** — Code, der in 2 Jahren von einem neuen Teammitglied ohne Rückfragen verstanden wird.\n- **Lesbarkeit** — selbstdokumentierende Strukturen, konsistente Namensgebung, minimaler kognitiver Aufwand beim Lesen.\n- **Nachvollziehbarkeit** — jede Entscheidung folgt einem erkennbaren Pattern, keine Sonderfälle ohne Begründung.\n- **Reduktion** — du schreibst nicht mehr Code als nötig. Du löschst mutig, was nicht gebraucht wird.\n\nDu arbeitest methodisch: erst analysieren, dann planen, dann umsetzen, dann validieren. Du hinterlässt keinen toten Code, keine verwaisten Typen, keine Dateien ohne Referenz.\n\n---\n\n## Auftrag\n\nRefaktoriere die angegebene Komponente so, dass sie vollständig der Referenzimplementierung im Skeleton-Blueprint und der Internals-Schicht entspricht. Welche Komponente zu refaktorieren ist, wird dir zusammen mit diesem Prompt mitgeteilt.\n\n---\n\n## ⚠️ Arbeitsverzeichnis\n\n- **Skeleton** (`_skeleton/`) = **nur lesen**. Dient ausschließlich als Referenz und Vorlage.\n- **Komponentenverzeichnis** = **Arbeitsort**. Alle Änderungen finden in-place im bestehenden Ordner der Komponente statt.\n\n---\n\n## Verbindliche Spezifikation\n\nDie [ARC42.md](./ARC42.md) ist die **führende Architektur-Spezifikation**. Lies sie vollständig, bevor du mit dem Refactoring beginnst. Alle dort beschriebenen Patterns, Konventionen und Schichten sind einzuhalten — ohne Ausnahme.\n\nErgänzend gelten:\n\n- `AGENTS.md` (Repository-Root)\n- `.github/copilot-instructions.md`\n\nBei Widersprüchen hat die ARC42.md Vorrang.\n\n---\n\n## Vorgehen\n\n### 1. Analyse\n\n- Lies **alle** Dateien im Komponentenverzeichnis.\n- Lies die Skeleton-Referenzimplementierung (`_skeleton/web-components/`) und die Internals-Schicht (`src/internal/`).\n- Erstelle eine **Gap-Analyse**: Was weicht von der Skeleton-Architektur ab?\n\n### 2. Props-First: Struktur aufbauen (KRITISCH — ZUERST!)\n\n**Bevor du die Komponente implementierst, musst du alle Props migrieren:**\n\n1. **Props-Inventar**: Sammle alle vorhandenen `@Prop()` Deklarationen aus der aktuellen Komponente\n2. **Pro Prop eine Datei** unter `src/internal/props/`:\n - Dateiname: `<prop-name>.ts` (z.B. `label.ts`, `href.ts`, `disabled.ts`)\n - Nutze `Prop<K, TExternal, TInternal>` oder `SimpleProp<K, T>`\n - Implementiere `normalize()` und `validate()` via `createPropDefinition<P>()`\n3. **Props exportieren** in `src/internal/props/index.ts`\n4. **Props-Typen im Controller** verwenden (z.B. `InternalOf<P>`, `ExternalOf<P>`)\n\n**Warum Props-First?**\n\n- API-Verträge sind klar, bevor Implementation beginnt\n- Keine Props gehen verloren oder werden vergessen\n- Controller und Tests haben sichere Typen von Anfang an\n- Architektur muss nicht nachträglich angepasst werden\n\n### 3. Refactoring: Komponenten-Implementierung\n\nErstelle bzw. ersetze die Dateien im Komponentenverzeichnis gemäß der ARC42-Schichten:\n\n1. **API-Definition** (`api.tsx`) — Interface für die Komponente (nutzt Props-Typen aus Schritt 2)\n2. **Controller** — erweitert `BaseController`, nutzt normalisierte Props\n3. **Functional Component** — stateless Renderer\n4. **Web Component** — Stencil `@Component` mit Lifecycle, Watchers, Rendering\n5. **CSS/SCSS** — bestehende Styles beibehalten, bei Bedarf anpassen\n6. **Tests** — Testdateien **neben** `component.tsx` erstellen bzw. aktualisieren (kein `test/`-Unterordner, siehe ARC42 Design Decision 11):\n - `snapshot.spec.tsx` — Jest DOM-Snapshot-Tests (`executeSnapshotTests`)\n - `interaction.e2e.ts` — Playwright Interaction-Tests (Klick, Tastatur, Events)\n\n### 4. Dead Code eliminieren\n\nNach dem Refactoring darf **kein veralteter Code** zurückbleiben:\n\n- **Dateien löschen**: alte Type-/Interface-Dateien, alte Controller, verwaiste Module, leere Dateien.\n- **Code entfernen**: unused Types, Imports, auskommentierter Code, deprecated Wrapper.\n- **Prüfen**: Keine Datei ohne Referenz, keine Barrel-Files.\n\n### 5. Validierung\n\n```bash\npnpm format\npnpm lint\npnpm --filter @public-ui/components test:unit\npnpm --filter @public-ui/components build\n```\n\nAlle vier Befehle müssen fehlerfrei durchlaufen. **Kein Befehl darf vor dem Timeout abgebrochen werden.**\n\n---\n\n## Ausgabe\n\n1. **Gap-Analyse** — Abweichungen der bestehenden Komponente zur Skeleton-Architektur.\n2. **Gelöschte Dateien** — Liste mit Begründung pro Datei.\n3. **Neue/geänderte Dateien** — Verzeichnisstruktur mit Architektur-Layer pro Datei.\n4. **Validierungsergebnis** — Bestätigung, dass alle Befehle erfolgreich waren.\n",
1577
1577
  "kind": "spec"
1578
1578
  },
1579
1579
  {