Refactor documentation and improve formatting across multiple files

- Enhanced the structure and readability of the building block view, deployment view, cross-cutting concepts, quality requirements, risks and technical debt, glossary, and package.json.
- Standardized table formatting for better clarity and consistency.
- Updated formatting scripts in package.json to ensure proper execution of Prettier for various file types.

Author: deleonio

.claude/commands/migrate-to-skeleton.md

@@ -52,11 +52,11 @@ The [`ARC42.md`](packages/components/src/components/_skeleton/ARC42.md) is the *
    - `packages/components/src/internal/functional-components/skeleton/component.tsx`
 3. Create a **gap analysis** and output it as a Markdown table:
 
-| Aspect | Legacy (Current) | Skeleton (Target) | Action Required |
-|--------|-----------------|-------------------|-----------------|
-| Inheritance | None / custom | `BaseWebComponent<Api>` | Migrate |
-| Controller | None / inline | `BaseController<Api>` | Create |
-| ... | ... | ... | ... |
+| Aspect      | Legacy (Current) | Skeleton (Target)       | Action Required |
+| ----------- | ---------------- | ----------------------- | --------------- |
+| Inheritance | None / custom    | `BaseWebComponent<Api>` | Migrate         |
+| Controller  | None / inline    | `BaseController<Api>`   | Create          |
+| ...         | ...              | ...                     | ...             |
 
 ### Phase 2: Props-First — Establish Structure (CRITICAL — DO THIS FIRST!)
 
@@ -165,15 +165,15 @@ public componentWillLoad(): void {
 
 ```typescript
 export class MyController extends BaseController<MyApi> implements ControllerInterface<MyApi> {
-  public constructor(setState: SetStateFn<MyApi>, getState: GetStateFn<MyApi>) {
-    super(myPropsConfig, setState, getState);
-  }
-
-  public watchName(value?: string): void {
-    nameProp.apply(value, (v) => {
-      this.setRenderProp('name', v);
-    });
-  }
+	public constructor(setState: SetStateFn<MyApi>, getState: GetStateFn<MyApi>) {
+		super(myPropsConfig, setState, getState);
+	}
+
+	public watchName(value?: string): void {
+		nameProp.apply(value, (v) => {
+			this.setRenderProp('name', v);
+		});
+	}
 }
 ```
 
@@ -189,7 +189,7 @@ export class MyController extends BaseController<MyApi> implements ControllerInt
 - Underscored public props (`_name`, `_label`)
 - Tests co-located next to `component.tsx`
 - No `types.ts` files, no barrel files
-- **ARIA IDs via `nonce()`**: Any `id` referenced by `aria-controls`, `aria-labelledby`, `aria-describedby` or `aria-owns` must be unique per instance — declare as `private readonly myId = \`prefix-${nonce()}\`` using `nonce()` from `utils/dev.utils`
+- **ARIA IDs via `nonce()`**: Any `id` referenced by `aria-controls`, `aria-labelledby`, `aria-describedby` or `aria-owns` must be unique per instance — declare as `private readonly myId = \`prefix-${nonce()}\``using`nonce()`from`utils/dev.utils`
 - **Kein `data-testid`**: Tests verwenden BEM-Klassen als Selektoren (`page.locator('.kol-component__element')`), niemals `data-testid`-Attribute im Komponenten-Markup
 
 ---

KNOWN_ISSUES.md

@@ -194,11 +194,11 @@ Toasts are unsolicited interruptions. `role="alert"` literally interrupts the ru
 
 Every measure that makes a toast genuinely accessible transforms it into a different component:
 
-| Measure | Result |
-|---|---|
-| No auto-dismiss | → Persistent inline alert |
-| Focus moved into the toast | → Non-modal dialog |
-| Notification history | → Notification panel / landmark region |
+| Measure                                  | Result                                        |
+| ---------------------------------------- | --------------------------------------------- |
+| No auto-dismiss                          | → Persistent inline alert                     |
+| Focus moved into the toast               | → Non-modal dialog                            |
+| Notification history                     | → Notification panel / landmark region        |
 | Plain text only, no interactive elements | → ARIA live region (no longer a visual toast) |
 
 > "If a notification contains an interactive element, it should not be a live region. And it should also not be a toast."
@@ -221,13 +221,13 @@ The structural accessibility problems remain unresolved:
 
 #### How leading design systems decide
 
-| Design system | Decision |
-|---|---|
-| **GOV.UK Design System** | No toast — Notification Banner (persistent) instead |
-| **U.S. Web Design System** | No toast — Alert + Site Alert instead |
-| **GitHub Primer** | Toast officially banned after moderated usability tests with disabled users: "The tests showed significant problems that cannot be addressed with a sprinkling of ARIA." |
-| **Adobe Spectrum** | Toast with strict constraints: min. 5 s timeout, pause on hover/focus, F6 landmark navigation |
-| **Carbon (IBM) v11** | Split into non-interactive (`role="status"`) and interactive (`role="alertdialog"` with full focus management) |
+| Design system              | Decision                                                                                                                                                                 |
+| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| **GOV.UK Design System**   | No toast — Notification Banner (persistent) instead                                                                                                                      |
+| **U.S. Web Design System** | No toast — Alert + Site Alert instead                                                                                                                                    |
+| **GitHub Primer**          | Toast officially banned after moderated usability tests with disabled users: "The tests showed significant problems that cannot be addressed with a sprinkling of ARIA." |
+| **Adobe Spectrum**         | Toast with strict constraints: min. 5 s timeout, pause on hover/focus, F6 landmark navigation                                                                            |
+| **Carbon (IBM) v11**       | Split into non-interactive (`role="status"`) and interactive (`role="alertdialog"` with full focus management)                                                           |
 
 #### References
 

docs/arc42/01-introduction-and-goals.md

@@ -17,13 +17,13 @@ This section introduces Public UI - KoliBri (KoliBri), outlining its core missio
 
 ## 1.2 Quality Goals
 
-| Priority | Quality Goal | Motivation |
-|----------|-------------|------------|
-| 1 | **Accessibility** | Core mission - every component must be accessible to all users regardless of disabilities |
-| 2 | **Standard Compliance** | Build on W3C standards ensures longevity and interoperability |
-| 3 | **Usability** | Components should be intuitive for developers and end-users |
-| 4 | **Maintainability** | Clean architecture enables long-term evolution and community contributions |
-| 5 | **Performance** | Fast loading and rendering for optimal user experience |
+| Priority | Quality Goal            | Motivation                                                                                |
+| -------- | ----------------------- | ----------------------------------------------------------------------------------------- |
+| 1        | **Accessibility**       | Core mission - every component must be accessible to all users regardless of disabilities |
+| 2        | **Standard Compliance** | Build on W3C standards ensures longevity and interoperability                             |
+| 3        | **Usability**           | Components should be intuitive for developers and end-users                               |
+| 4        | **Maintainability**     | Clean architecture enables long-term evolution and community contributions                |
+| 5        | **Performance**         | Fast loading and rendering for optimal user experience                                    |
 
 ### Quality Scenarios
 
@@ -34,22 +34,24 @@ This section introduces Public UI - KoliBri (KoliBri), outlining its core missio
 
 ## 1.3 Stakeholders
 
-| Role/Name | Expectations | Contact |
-|-----------|-------------|---------|
-| **End Users** | Accessible, usable web interfaces that work with assistive technologies | - |
-| **Developers** | Easy-to-use, well-documented components that integrate with their tech stack | - |
-| **Designers** | Flexible theming system that supports their design systems | - |
-| **ITZBund** | Sustainable open-source project that meets public sector requirements | kolibri@itzbund.de |
-| **Public Sector Organizations** | BITV-compliant components for government websites and applications | - |
-| **Open Source Community** | Transparent development, contribution opportunities, and reusable components | GitHub Issues/PRs |
-| **Accessibility Advocates** | Reference implementation of WCAG standards in web components | - |
+| Role/Name                       | Expectations                                                                 | Contact            |
+| ------------------------------- | ---------------------------------------------------------------------------- | ------------------ |
+| **End Users**                   | Accessible, usable web interfaces that work with assistive technologies      | -                  |
+| **Developers**                  | Easy-to-use, well-documented components that integrate with their tech stack | -                  |
+| **Designers**                   | Flexible theming system that supports their design systems                   | -                  |
+| **ITZBund**                     | Sustainable open-source project that meets public sector requirements        | kolibri@itzbund.de |
+| **Public Sector Organizations** | BITV-compliant components for government websites and applications           | -                  |
+| **Open Source Community**       | Transparent development, contribution opportunities, and reusable components | GitHub Issues/PRs  |
+| **Accessibility Advocates**     | Reference implementation of WCAG standards in web components                 | -                  |
 
 ## 1.4 Vision and Mission
 
 ### Vision
+
 > Together we make **HTML** accessible using **reusable web components** to ensure **usability** and **accessibility**.
 
 ### Mission
+
 The HTML web standard is openly specified to be long-lasting and robust, but this often results in compositions that are not easily accessible, semantic, or valid. KoliBri provides:
 
 - **Framework-agnostic components** based on W3C web standards