chore(changeset): prepare v0.1.0 release

docs(update): update README to reflect .gitea/ CI setup and test image sourcing
Adds the .gitea/ directory to the project structure overview and corrects the claim that local and CI test environments are identical. Both are built from the same Dockerfile.test, but locally the image is built on demand while CI pulls a prebuilt version — see ADR-0002 and the Technology Architecture doc for details.
2026-08-05 17:28:41 +02:00 · 2026-08-05 17:20:41 +02:00 · 2026-08-05 17:00:52 +02:00 · 2026-08-04 12:34:04 +00:00 · 2026-08-03 22:18:14 +02:00 · 2026-08-02 15:39:19 +02:00
76 changed files with 13675 additions and 799 deletions
@@ -7,5 +7,5 @@
  "access": "restricted",
  "baseBranch": "dev",
  "updateInternalDependencies": "patch",
-  "ignore": ["apps/docs"]
+  "ignore": []
 }
@@ -0,0 +1,5 @@
+---
+'luna-charts': minor
+---
+
+Establish the initial project foundation with architecture, documentation, governance, and development tooling.
@@ -0,0 +1,2 @@
+node_modules
+packages/**/node_modules
@@ -0,0 +1,18 @@
+FROM node:22-bullseye
+
+# Install Docker CLI + Compose V2 plugin from Docker's official apt repo
+# (Debian's own docker.io package ships an outdated Docker version and
+# does not include the compose plugin at all).
+RUN apt-get update \
+    && apt-get install -y ca-certificates curl gnupg \
+    && install -m 0755 -d /etc/apt/keyrings \
+    && curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc \
+    && chmod a+r /etc/apt/keyrings/docker.asc \
+    && echo \
+       "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/debian bullseye stable" \
+       | tee /etc/apt/sources.list.d/docker.list > /dev/null \
+    && apt-get update \
+    && apt-get install -y docker-ce-cli docker-compose-plugin \
+    && rm -rf /var/lib/apt/lists/*
+
+RUN corepack enable
@@ -0,0 +1,90 @@
+name: CI
+
+on:
+  push:
+    branches:
+      - '**'
+  pull_request:
+    branches: [dev, main]
+
+jobs:
+  lint-and-format:
+    runs-on: ubuntu-docker-dind
+    container:
+      image: git.byting-pandas.ninja/ci/node22-docker:latest
+      credentials:
+        username: ${{ secrets.REGISTRY_USER }}
+        password: ${{ secrets.REGISTRY_TOKEN }}
+    steps:
+      - uses: actions/checkout@v4
+
+      - run: corepack enable
+      - run: corepack prepare pnpm@11.11.0 --activate
+
+      - run: pnpm install --frozen-lockfile
+
+      - name: Lint
+        run: pnpm lint
+
+      - name: Check formatting
+        run: pnpm format:check
+
+  changeset-check:
+    runs-on: ubuntu-docker-dind
+    container:
+      image: git.byting-pandas.ninja/ci/node22-docker:latest
+      credentials:
+        username: ${{ secrets.REGISTRY_USER }}
+        password: ${{ secrets.REGISTRY_TOKEN }}
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+
+      - run: corepack enable
+      - run: corepack prepare pnpm@11.11.0 --activate
+
+      - run: pnpm install --frozen-lockfile
+
+      - name: Verify changeset exists
+        continue-on-error: true
+        run: pnpm changeset status --since=origin/dev
+
+  unit-tests:
+    runs-on: ubuntu-docker-dind
+    container:
+      image: git.byting-pandas.ninja/ci/node22-docker:latest
+      credentials:
+        username: ${{ secrets.REGISTRY_USER }}
+        password: ${{ secrets.REGISTRY_TOKEN }}
+    steps:
+      - uses: actions/checkout@v4
+
+      - run: corepack enable
+      - run: corepack prepare pnpm@11.11.0 --activate
+
+      - run: pnpm install --frozen-lockfile
+
+      - name: Run unit tests
+        run: pnpm test:unit
+
+  component-tests:
+    runs-on: ubuntu-docker-dind
+    container:
+      image: git.byting-pandas.ninja/ci/luna-charts-test:v1.62.1
+      credentials:
+        username: ${{ secrets.REGISTRY_USER }}
+        password: ${{ secrets.REGISTRY_TOKEN }}
+
+    steps:
+      - uses: actions/checkout@v4
+
+      - run: corepack enable
+
+      - run: corepack prepare pnpm@11.11.0 --activate
+
+      - run: pnpm install --frozen-lockfile
+
+      - name: Run component tests (Playwright)
+        working-directory: packages/luna-charts
+        run: pnpm test:browser
@@ -1 +1,2 @@
 node_modules
+.pnpm-store
@@ -2,5 +2,6 @@
  "singleQuote": true,
  "semi": true,
  "trailingComma": "es5",
-  "printWidth": 100
+  "printWidth": 100,
+    "bracketSameLine": true
 }
@@ -0,0 +1,78 @@
+# Contributing to LUNA Charts
+
+Thank you for considering a contribution to LUNA Charts! This document explains how the project is governed, what's expected of a contribution, and how to get your change through review.
+
+Before contributing, please also read our [Code of Conduct](./.github/CODE_OF_CONDUCT.md).
+
+## Project Status
+
+LUNA Charts is currently in its **groundwork phase** — foundational architecture, tooling, and testing infrastructure are being established before chart components are built out. Check the [Roadmap](./docs/src/content/docs/getting-started/roadmap.mdx) to see what's currently in scope.
+
+## How the Project Is Governed
+
+LUNA Charts balances open community contribution with a documented architecture. In short:
+
+- **The architecture is the authoritative source for implementation decisions** — it's documented under [`docs/.../architecture/adm`](./docs/src/content/docs/architecture/adm) (Architecture Development Method) and [`docs/.../architecture/adr`](./docs/src/content/docs/architecture/adr) (Architecture Decision Records)
+- **Contributions are reviewed on three levels**: automated checks (types, linting, tests, accessibility), architectural compliance (does it fit the documented architecture?), and general project quality (readability, maintainability, documentation)
+- **A Pull Request can be rejected even if all automated checks pass** — for example, if it introduces an unnecessary public API change, bypasses accessibility mechanisms, or conflicts with a documented architectural decision
+- Community members can propose architectural changes, but such changes only become official once the relevant ADR/ADM documentation has been updated to reflect them (see [Architecture Change Management](./docs/src/content/docs/architecture/adm/architecture-change-management.mdx))
+
+If you're planning a larger change, especially one that touches the public API, rendering approach, or accessibility behavior, please open an issue or discussion first so it can be reviewed against the architecture before you invest time in an implementation.
+
+## Getting Started
+
+1. Fork the repository and clone your fork
+2. Install dependencies:
+
+   ```bash
+   pnpm install
+   ```
+
+3. Requirements: Node.js `>= 22.0.0`, pnpm `11.11.0` (via Corepack), and Docker (for component/browser tests)
+
+## Making a Change
+
+1. Create a branch from `main` with a descriptive name (e.g. `fix/axis-label-overflow`, `docs/update-technology-architecture`)
+2. Make your change
+3. Run the checks locally before opening a PR:
+
+   ```bash
+   pnpm lint
+   pnpm test:unit
+   pnpm test:component   # runs inside a Docker/Playwright container
+   pnpm test             # runs both of the above
+   ```
+  
+4. If your change affects published package behavior (bug fix, feature, breaking change), add a changeset:
+
+   ```bash
+   pnpm changeset
+   ```
+
+   Documentation-only or internal tooling changes generally don't need a changeset — if you're unsure, mention it in your PR description and a maintainer will advise.
+
+## Pull Request Guidelines
+
+- Keep PRs focused on a single concern where possible — smaller PRs are easier to review against the architecture
+- Describe **what** changed and **why**, not just what the diff shows
+- If your change affects accessibility behavior, explain how it was verified (e.g. which axe-core checks or manual screen-reader testing was done)
+- If your change touches an area covered by an existing ADR, reference it and note whether the ADR needs a corresponding update
+- Automated testing (unit, accessibility, linting) must pass before a PR can be merged
+
+## Documentation Changes
+
+Documentation lives in `docs/` (Starlight) and is a first-class contribution — fixing unclear wording, expanding examples, or correcting an outdated ADR/ADM page is just as valuable as a code change.
+
+If your code change makes a documented architectural statement incorrect (for example, changing a technology choice or the repository structure), please update the relevant ADR/ADM page in the same PR, including a short **Change Log** entry at the end of that document explaining what changed and why. Keeping documentation in sync with implementation is part of the review criteria described above.
+
+## Reporting Bugs and Suggesting Features
+
+Please open an issue with:
+
+- A clear description of the problem or suggestion
+- Steps to reproduce (for bugs), including browser/OS if relevant to rendering or accessibility
+- What you expected to happen vs. what actually happened
+
+## Questions
+
+If anything here is unclear, feel free to open a discussion or issue — improving this guide based on real contributor questions is welcome too.
@@ -0,0 +1,21 @@
+FROM mcr.microsoft.com/playwright:v1.62.1-noble
+
+RUN corepack enable && corepack prepare pnpm@10 --activate
+
+ENV CI=true
+
+WORKDIR /app
+
+COPY . .
+
+RUN rm -rf node_modules packages/**/node_modules
+
+ENV PNPM_CONFIG_SUPPORTED_ARCHITECTURES="current,linux-x64-gnu"
+
+RUN pnpm install --frozen-lockfile
+
+WORKDIR /app/packages/luna-charts
+
+RUN pnpm add -D @rolldown/binding-linux-x64-gnu
+
+CMD ["pnpm", "test:browser"]
@@ -1,3 +1,116 @@
-# LUNA-Charts
+# LUNA Charts

 LUNA Charts is a reusable, developer-friendly charting library designed to make accessible, WCAG-oriented data visualization the default rather than an afterthought.
+
+> **Project status:** Groundwork phase. Core architecture and tooling are in place; production-ready chart components (starting with `BarChart`) are still in development. See the [Roadmap](./docs/src/content/docs/getting-started/roadmap.mdx) for details.
+
+## Preface & Repository Mirror Notice
+
+Please be aware of our repository structure:
+
+* **Official Repository:** [git.byting-pandas.ninja/Ninosaurier/LUNA-Charts](https://git.byting-pandas.ninja/Ninosaurier/LUNA-Charts)
+
+**Important:** All development, including issue tracking and contribution management, takes place exclusively on our self-hosted server. Issues and pull requests cannot be created or processed on this GitHub mirror. Please visit the original link above to report bugs or request features.
+
+## Why LUNA Charts
+
+Most charting libraries treat accessibility as an add-on. LUNA Charts builds it in from the start:
+
+* **Accessible by default** — components are designed and tested against WCAG guidance from day one, not patched in afterward
+* **Framework-agnostic** — built as standard Web Components (Stencil), usable in React, Vue, Angular, Svelte, or plain HTML
+* **SVG-based rendering** — inspectable, stylable, and screen-reader-friendly output instead of an opaque canvas
+
+## Tech Stack
+
+| Area | Technology |
+| --- | --- |
+| Component framework | [Stencil](https://stenciljs.com) (compiles to standard Web Components) |
+| Language | TypeScript |
+| Package manager | pnpm (monorepo workspaces) |
+| Unit & component testing | [Vitest](https://vitest.dev), with [Playwright](https://playwright.dev) as the browser provider |
+| Accessibility testing | axe-core |
+| Documentation | [Starlight](https://starlight.astro.build) |
+| Component explorer | Storybook |
+| Linting & formatting | ESLint, Prettier |
+| Release management | [Changesets](https://github.com/changesets/changesets) |
+
+The full set of architecture decisions behind these choices is documented in [`docs/.../architecture/adr`](./docs/src/content/docs/architecture/adr) and the broader [Architecture Development Method (ADM) documentation](./docs/src/content/docs/architecture/adm).
+
+## Project Structure
+
+```text
+luna-charts/
+│
+├── packages/
+│   └── luna-charts/        # The library itself (Stencil components, Storybook)
+│
+├── docs/                    # Architecture docs, ADRs, guides (Starlight)
+│
+├── examples/                # Usage examples (framework integrations)
+│
+├── .changeset/               # Release/versioning configuration
+│
+├── .github/                  # Community health files (Code of Conduct, etc.)
+│
+└── .gitea/                   # CI workflows (Gitea Actions) and CI runner image
+```
+
+## Getting Started
+
+### Prerequisites
+
+* Node.js `>= 22.0.0`
+* pnpm `11.11.0` (see `devEngines` in `package.json`; pnpm will be downloaded automatically via Corepack if missing)
+* Docker (required for running component/browser tests locally, see below)
+
+### Installation
+
+```bash
+git clone https://github.com/Ninosaurier/LUNA-Charts.git
+cd luna-charts
+pnpm install
+```
+
+or
+
+```bash
+git clone https://git.byting-pandas.ninja/Ninosaurier/LUNA-Charts.git
+cd luna-charts
+pnpm install
+```
+
+### Common commands
+
+| Command | Description |
+| --- | --- |
+| `pnpm test:unit` | Run unit tests for the `luna-charts` package |
+| `pnpm test:component` | Run component/browser tests inside the containerized Playwright environment |
+| `pnpm test` | Run the full test suite (unit + component) |
+| `pnpm changeset` | Record a changeset for your change (required for any user-facing change) |
+| `pnpm run docs` | Start the documentation site locally (astroJS) |
+| `pnpm run lint` | Run the linter to check for code style and quality issues |
+| `pnpm run format` | Run the formatter to automatically fix code style issues |
+| `pnpm run test:browser` | Run browser tests (only works inside the `packages/luna-charts` directory) |
+
+### Storybook
+
+Storybook currently needs to be started from within the library package directly:
+
+```bash
+cd packages/luna-charts
+pnpm run storybook
+```
+
+> **Note:** Running Storybook from the repository root isn't set up yet. This is a known gap — contributions to add a root-level `pnpm --filter` script are welcome.
+
+Component and browser tests run inside Docker (`docker-compose.test.yaml`), based on the same `Dockerfile.test` used to build the image CI tests against, to guarantee a reproducible browser environment — you don't need Playwright browsers installed locally. Locally this image is built on demand; in CI a prebuilt version of the same image is pulled directly (see [ADR-0002](./docs/src/content/docs/architecture/adr/000200-technology-stack.mdx) and the [Technology Architecture](./docs/src/content/docs/architecture/adm/technology-architecture.mdx#66-test-execution-environment) doc for details).
+
+## Documentation
+
+* **Architecture documentation**: see `docs/` — includes the full Architecture Development Method (ADM) documentation (vision, business architecture, technology architecture, governance, migration planning) and all Architecture Decision Records (ADRs)
+* **Contributing**: see [CONTRIBUTING.md](./CONTRIBUTING.md)
+* **Code of Conduct**: see [.github/CODE_OF_CONDUCT.md](./.github/CODE_OF_CONDUCT.md)
+
+## License
+
+LUNA Charts is licensed under the [GNU Lesser General Public License v3.0 (LGPL-3.0)](./LICENSE).
@@ -0,0 +1,6 @@
+services:
+  test:
+    build:
+      context: .
+      dockerfile: Dockerfile.test
+    working_dir: /app/packages/luna-charts
@@ -0,0 +1,21 @@
+# build output
+dist/
+# generated types
+.astro/
+
+# dependencies
+node_modules/
+
+# logs
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*
+pnpm-debug.log*
+
+
+# environment variables
+.env
+.env.production
+
+# macOS-specific files
+.DS_Store
@@ -0,0 +1,4 @@
+{
+  "recommendations": ["astro-build.astro-vscode"],
+  "unwantedRecommendations": []
+}
@@ -0,0 +1,11 @@
+{
+  "version": "0.2.0",
+  "configurations": [
+    {
+      "command": "./node_modules/.bin/astro dev",
+      "name": "Development server",
+      "request": "launch",
+      "type": "node-terminal"
+    }
+  ]
+}
@@ -0,0 +1,22 @@
+## Development
+
+When starting the dev server, use background mode:
+
+```
+astro dev --background
+```
+
+Manage the background server with `astro dev stop`, `astro dev status`, and `astro dev logs`.
+
+## Documentation
+
+Full documentation: https://docs.astro.build
+
+Consult these guides before working on related tasks:
+
+- [Adding pages, dynamic routes, or middleware](https://docs.astro.build/en/guides/routing/)
+- [Working with Astro components](https://docs.astro.build/en/basics/astro-components/)
+- [Using React, Vue, Svelte, or other framework components](https://docs.astro.build/en/guides/framework-components/)
+- [Adding or managing content](https://docs.astro.build/en/guides/content-collections/)
+- [Adding styles or using Tailwind](https://docs.astro.build/en/guides/styling/)
+- [Supporting multiple languages](https://docs.astro.build/en/guides/internationalization/)
@@ -0,0 +1 @@
+AGENTS.md
@@ -0,0 +1,49 @@
+# Starlight Starter Kit: Basics
+
+[![Built with Starlight](https://astro.badg.es/v2/built-with-starlight/tiny.svg)](https://starlight.astro.build)
+
+```
+pnpm create astro@latest -- --template starlight
+```
+
+> 🧑‍🚀 **Seasoned astronaut?** Delete this file. Have fun!
+
+## 🚀 Project Structure
+
+Inside of your Astro + Starlight project, you'll see the following folders and files:
+
+```
+.
+├── public/
+├── src/
+│   ├── assets/
+│   ├── content/
+│   │   └── docs/
+│   └── content.config.ts
+├── astro.config.mjs
+├── package.json
+└── tsconfig.json
+```
+
+Starlight looks for `.md` or `.mdx` files in the `src/content/docs/` directory. Each file is exposed as a route based on its file name.
+
+Images can be added to `src/assets/` and embedded in Markdown with a relative link.
+
+Static assets, like favicons, can be placed in the `public/` directory.
+
+## 🧞 Commands
+
+All commands are run from the root of the project, from a terminal:
+
+| Command                   | Action                                           |
+| :------------------------ | :----------------------------------------------- |
+| `pnpm install`             | Installs dependencies                            |
+| `pnpm dev`             | Starts local dev server at `localhost:4321`      |
+| `pnpm build`           | Build your production site to `./dist/`          |
+| `pnpm preview`         | Preview your build locally, before deploying     |
+| `pnpm astro ...`       | Run CLI commands like `astro add`, `astro check` |
+| `pnpm astro -- --help` | Get help using the Astro CLI                     |
+
+## 👀 Want to learn more?
+
+Check out [Starlight’s docs](https://starlight.astro.build/), read [the Astro documentation](https://docs.astro.build), or jump into the [Astro Discord server](https://astro.build/chat).
@@ -1,211 +0,0 @@
-# ADR-0002: Technology Stack
-
-* **Status:** Accepted
-* **Date:** 2026-07-12
-* **Decision Makers:** LUNA Charts Maintainers
-
---
-
-## Context
-
-LUNA Charts is an open-source charting library designed to provide accessible, framework-agnostic, and strongly typed chart components.
-
-The selected technology stack must support the architectural principles defined during the TOGAF Architecture Development Method (ADM), including:
-
-* Accessibility by Design
-* Framework Agnosticism
-* Strong Type Safety
-* Component-Based Architecture
-* High Developer Experience
-* Open Source Collaboration
-* Long-Term Maintainability
-
-Rather than selecting technologies based on popularity, each technology is evaluated according to its ability to support these architectural goals.
-
---
-
-## Decision Drivers
-
-The following factors influenced the decision:
-
-* Accessibility
-* Framework Agnosticism
-* Type Safety
-* Developer Experience
-* Maintainability
-* Testability
-* Documentation
-* Open Source Collaboration
-* Long-Term Evolution
-
---
-
-## Considered Alternatives
-
-| Technology Area         | Considered Alternatives                         | Selected           |
-| ----------------------- | ----------------------------------------------- | ------------------ |
-| Component Framework     | React, Vue, Angular, Lit, StencilJS             | **StencilJS**      |
-| Component Documentation | Storybook, Styleguidist                         | **Storybook**      |
-| Project Documentation   | Docusaurus, VitePress, Starlight                | **Starlight**      |
-| Package Manager         | npm, Yarn, pnpm                                 | **pnpm**           |
-| Unit Testing            | Vitest, Jest                                    | **Jest**           |
-| Browser Testing         | Cypress, Playwright                             | **Playwright**     |
-| Accessibility Testing   | Manual Testing Only, axe-core                   | **axe-core**       |
-| Code Formatting         | Manual Formatting, Prettier                     | **Prettier**       |
-| Static Analysis         | TSLint, ESLint                                  | **ESLint**         |
-| Versioning              | Manual Versioning, Semantic Release, Changesets | **Changesets**     |
-| Continuous Integration  | GitLab CI, Azure Pipelines, GitHub Actions      | **GitHub Actions** |
-
-The selected technologies best support the project's architectural goals while remaining broadly adopted and well documented.
-
---
-
-## Decision
-
-The following technology stack is adopted for the implementation of LUNA Charts.
-
-| Technology         | Purpose                                             |
-| ------------------ | --------------------------------------------------- |
-| **StencilJS**      | Web Component development                           |
-| **Storybook**      | Interactive component documentation and development |
-| **Starlight**      | Project and architecture documentation              |
-| **TypeScript**     | Strong typing and developer tooling                 |
-| **pnpm**           | Package management and workspace support            |
-| **Jest**           | Unit testing                                        |
-| **Playwright**     | Browser and interaction testing                     |
-| **axe-core**       | Accessibility validation                            |
-| **ESLint**         | Static code analysis                                |
-| **Prettier**       | Consistent code formatting                          |
-| **Changesets**     | Versioning and release management                   |
-| **GitHub Actions** | Continuous Integration                              |
-
-The technology stack is considered part of the project's architecture and may only be changed through a new Architecture Decision Record.
-
---
-
-## Rationale
-
-Each technology has been selected because it directly supports one or more architectural principles.
-
-### StencilJS
-
-StencilJS enables the development of standards-based Web Components.
-
-This aligns with the project's goal of remaining framework agnostic while allowing framework-specific wrappers to be generated automatically during the build process.
-
---
-
-### Storybook
-
-Storybook provides an isolated environment for component development.
-
-It supports rapid development, interactive examples, accessibility validation, and visual review of chart components.
-
---
-
-### Starlight
-
-Starlight serves as the central documentation platform.
-
-It separates architectural documentation from component documentation and supports long-term maintainability of the project's knowledge base.
-
---
-
-### TypeScript
-
-TypeScript enables strong compile-time validation.
-
-It improves the developer experience by detecting integration errors early and providing comprehensive IDE support.
-
---
-
-### pnpm
-
-pnpm Workspaces enable a modular repository structure while maintaining a single source of truth for dependencies and tooling.
-
---
-
-### Jest
-
-Jest provides fast unit testing for business logic, utility functions, configuration handling, validation, and other non-browser-specific functionality.
-
---
-
-### Playwright
-
-Playwright validates component behavior inside real browsers.
-
-It is used to verify keyboard interaction, focus management, SVG rendering, and other browser-dependent accessibility features.
-
---
-
-### axe-core
-
-axe-core automatically validates accessibility requirements and complements manual accessibility reviews.
-
---
-
-### ESLint and Prettier
-
-Both tools ensure consistent coding standards across the project and reduce friction during code reviews.
-
---
-
-### Changesets
-
-Changesets manages package versioning and release notes while keeping release decisions under maintainer control.
-
---
-
-### GitHub Actions
-
-GitHub Actions automates testing, validation, and release workflows to ensure consistent software quality.
-
---
-
-## Consequences
-
-### Positive
-
-* Technology stack directly supports architectural principles.
-* Strong accessibility support throughout development.
-* Framework-independent component model.
-* Excellent developer experience.
-* Consistent documentation workflow.
-* High maintainability.
-* Modern testing strategy.
-* Simplified contributor onboarding.
-* Automated quality assurance.
-* Scalable project foundation.
-
-### Negative
-
-* Initial project setup is more complex.
-* Contributors must become familiar with multiple development tools.
-* Toolchain maintenance requires periodic updates.
-* CI configuration is more comprehensive than for smaller projects.
-
---
-
-## Related TOGAF Phases
-
-* Architecture Vision (Phase A)
-* Information Systems Architecture (Phase C)
-* Technology Architecture (Phase D)
-* Opportunities & Solutions (Phase E)
-* Migration Planning (Phase F)
-* Implementation Governance (Phase G)
-
---
-
-## References
-
-* LUNA Charts Architecture Wiki
-* ADR-0001: Repository Structure
-* ADR-0003: Web Components as Public API
-* StencilJS Documentation
-* Storybook Documentation
-* Starlight Documentation
-* Playwright Documentation
-* Jest Documentation
-* pnpm Documentation
@@ -1,190 +0,0 @@
-# Architecture Decision Records (ADRs)
-
-Architecture Wiki: [https://wiki.byting-pandas.ninja/en/Projects/LUNA-Charts/Introduction]
-
-## Purpose
-
-This directory contains the **Architecture Decision Records (ADRs)** for the LUNA Charts project.
-
-An Architecture Decision Record documents a significant architectural decision, the context in which it was made, the chosen solution, and its consequences.
-
-The goal is to preserve the reasoning behind architectural decisions so that future contributors and maintainers understand **why** a decision was made—not only **what** was implemented.
-
-ADRs complement the Architecture Development Method (ADM) documentation and serve as the primary record of architectural decisions throughout the project's lifecycle.
-
---
-
-## Architecture Documentation
-
-The complete software architecture of LUNA Charts is documented in the official Architecture Wiki.
-
-The wiki follows the **TOGAF Architecture Development Method (ADM)** and describes the project from the initial vision through implementation governance and long-term architecture evolution.
-
-### Architecture Wiki
-
-* Architecture Vision (Phase A)
-* Business Architecture (Phase B)
-* Information Systems Architecture (Phase C)
-* Technology Architecture (Phase D)
-* Opportunities & Solutions (Phase E)
-* Migration Planning (Phase F)
-* Implementation Governance (Phase G)
-* Architecture Change Management (Phase H)
-
-The ADRs contained in this directory should always be read together with the Architecture Wiki.
-
-The wiki describes the architecture as a whole, whereas ADRs explain the reasoning behind individual architectural decisions.
-
---
-
-## Relationship to the Architecture Documentation
-
-| Architecture Wiki                            | Architecture Decision Records                       |
-| -------------------------------------------- | --------------------------------------------------- |
-| Describes the complete software architecture | Documents individual architectural decisions        |
-| Defines the overall system structure         | Explains why a specific solution was selected       |
-| Organized according to TOGAF ADM phases      | Organized chronologically by architectural decision |
-| Updated when the architecture evolves        | Added whenever a significant decision is made       |
-
-ADRs do **not** replace the Architecture Wiki.
-
-Likewise, the Architecture Wiki should not duplicate ADRs.
-
-Instead, both artifacts complement each other.
-
---
-
-## When to Create an ADR
-
-An ADR should be created whenever a decision has a significant impact on the architecture of the project.
-
-Typical examples include:
-
-* Selecting a new technology
-* Introducing or replacing an architectural pattern
-* Changing the public API
-* Introducing a new rendering strategy
-* Changing accessibility principles
-* Modifying the repository structure
-* Changing release or governance processes
-
-Small implementation details, bug fixes, refactorings, or coding style decisions do **not** require an ADR.
-
---
-
-## ADR Lifecycle
-
-Every ADR has one of the following statuses:
-
-| Status     | Description                                             |
-| ---------- | ------------------------------------------------------- |
-| Proposed   | The decision is under discussion.                       |
-| Accepted   | The decision has been approved and adopted.             |
-| Deprecated | The decision is no longer recommended but still exists. |
-| Superseded | The decision has been replaced by another ADR.          |
-| Discarded  | The proposal was rejected.                              |
-
-Only **Accepted** ADRs represent the current architecture.
-
---
-
-## ADR Structure
-
-Each ADR follows the same structure.
-
-```text
-Title
-
-Status
-
-Context
-
-Decision Drivers
-
-Considered Alternatives
-
-Decision
-
-Rationale
-
-Consequences
-    Positive
-    Negative
-
-Related TOGAF Phases
-
-References
-```
-
-This structure ensures that every ADR answers the following questions:
-
-* **What** decision was made?
-* **Why** was the decision necessary?
-* **When** was it made?
-* **Who** approved the decision?
-* **What** are the expected consequences?
-
---
-
-## Naming Convention
-
-ADRs use sequential numbering.
-
-Examples:
-
-```text
-0001-repository-structure.md
-0002-technology-stack.md
-0003-svg-rendering.md
-```
-
-The number is never reused.
-
-If an ADR becomes obsolete, its status changes instead of deleting the document.
-
---
-
-## Decision Process
-
-Architectural decisions follow the governance model defined in **Implementation Governance (Phase G)**.
-
-```text
-Proposal
-        ↓
-Architecture Discussion
-        ↓
-Architecture Review
-        ↓
-Maintainer Decision
-        ↓
-ADR Update
-        ↓
-Implementation
-```
-
-Community members are encouraged to participate in discussions.
-
-Final architectural decisions are made by the project maintainers.
-
---
-
-## Relationship to Source Code
-
-Source code is expected to reflect accepted ADRs.
-
-If an implementation no longer follows an accepted ADR, one of the following actions should occur:
-
-* Update the implementation to match the ADR.
-* Replace the ADR with a new architectural decision.
-* Deprecate or supersede the ADR.
-
-Architectural changes should always be documented before or together with the implementation.
-
---
-
-## References
-
-* TOGAF Architecture Development Method (ADM)
-* LUNA Charts Architecture Wiki
-* LUNA Charts Implementation Governance (Phase G)
-* LUNA Charts Architecture Change Management (Phase H)
@@ -0,0 +1,39 @@
+// @ts-check
+import { defineConfig } from 'astro/config';
+import starlight from '@astrojs/starlight';
+
+
+// https://astro.build/config
+export default defineConfig({
+  integrations: [
+    starlight({
+      title: 'LUNA-Charts',
+      social: [
+        {
+          icon: 'github',
+          label: 'GitHub',
+          href: 'https://git.byting-pandas.ninja/Ninosaurier/LUNA-Charts',
+        },
+      ],
+      sidebar: [
+        {
+          label: 'Start Here',
+          items: [{ autogenerate: { "directory": "getting-started" } }],
+        },
+        {
+          label: 'Architecture',
+          items: [
+            {
+              label: 'ADM',
+              items: [{ autogenerate: { "directory": "architecture/adm" } }],
+            },
+            {
+              label: 'ADRs',
+              items: [{ autogenerate: { "directory": "architecture/adr" } }],
+            },
+          ],
+        },
+      ],
+    }),
+  ],
+});
@@ -0,0 +1,17 @@
+{
+  "name": "docs",
+  "type": "module",
+  "version": "0.0.1",
+  "scripts": {
+    "dev": "astro dev",
+    "start": "astro dev",
+    "build": "astro build",
+    "preview": "astro preview",
+    "astro": "astro"
+  },
+  "dependencies": {
+    "@astrojs/starlight": "^0.41.3",
+    "astro": "^7.0.2",
+    "sharp": "^0.34.5"
+  }
+}
@@ -0,0 +1,3 @@
+allowBuilds:
+  esbuild: true
+  sharp: true
@@ -0,0 +1,7 @@
+import { defineCollection } from 'astro:content';
+import { docsLoader } from '@astrojs/starlight/loaders';
+import { docsSchema } from '@astrojs/starlight/schema';
+
+export const collections = {
+	docs: defineCollection({ loader: docsLoader(), schema: docsSchema() }),
+};
@@ -0,0 +1,169 @@
+---
+title: 8. Architecture Change Management
+description: Process for evaluating and managing future architectural change in LUNA Charts, ensuring the system evolves without losing consistency.
+sidebar:
+  order: 9
+---
+
+## 1. Overview
+
+Architecture Change Management defines how LUNA Charts adapts to new requirements, technologies, standards, and stakeholder needs throughout its lifecycle.
+
+Rather than treating the architecture as a static artifact, this phase establishes a controlled evolution process that preserves architectural consistency while enabling continuous improvement.
+
+All architectural changes follow documented governance processes and remain aligned with the project's long-term vision and architectural principles.
+
+## 2. Objectives
+
+Architecture Change Management pursues the following objectives:
+
+- Ensure the long-term sustainability of the architecture
+- Adapt to technological and regulatory changes
+- Preserve architectural consistency across releases
+- Support controlled innovation without compromising existing principles
+- Maintain traceable architectural evolution
+
+## 3. Architecture Change Triggers
+
+Architectural changes may be initiated by various internal and external factors.
+
+Typical triggers include:
+
+### External Triggers
+
+- Updates to WCAG recommendations
+- Changes in accessibility regulations
+- Browser platform evolution
+- SVG specification changes
+- TypeScript language evolution
+- New web platform capabilities
+
+### Internal Triggers
+
+- Architectural improvements
+- Lessons learned during implementation
+- Long-term maintainability concerns
+- Performance improvements
+- Community feedback
+- New functional requirements
+
+The existence of a trigger does not automatically require an architectural change. Every trigger must first be evaluated.
+
+## 4. Change Evaluation
+
+Every proposed architectural change is evaluated before implementation begins.
+
+Evaluation includes questions such as:
+
+- Does the proposal align with the Architecture Vision?
+- Does it respect the established architecture principles?
+- Does it improve long-term maintainability?
+- Does it preserve accessibility objectives?
+- Does it maintain a positive developer experience?
+- Does the expected value justify the architectural impact?
+
+Architectural principles always take precedence over feature demand.
+
+New functionality should strengthen the existing architecture rather than weaken its consistency.
+
+## 5. Architecture Evolution Process
+
+Architectural evolution follows a structured review process.
+
+```text
+Change Trigger
+        ↓
+Architecture Evaluation
+        ↓
+Architecture Discussion
+        ↓
+Maintainer Decision
+        ↓
+Architecture Documentation Update
+        ↓
+Implementation
+        ↓
+Project Documentation Update
+        ↓
+Release
+```
+
+Implementation follows documented architectural decisions rather than defining them.
+
+## 6. Documentation Management
+
+Architecture documentation is the primary source of truth for architectural decisions.
+
+Whenever an architectural change is approved, the following artifacts should be reviewed and updated where applicable:
+
+- Architecture documentation (ADM phases)
+- Developer documentation
+- Usage examples
+- Test suites
+- Public Change Log
+
+Documentation updates should precede or accompany implementation to ensure architectural transparency.
+
+## 7. Continuous Improvement
+
+LUNA Charts is designed to evolve continuously through incremental architectural improvements.
+
+Continuous improvement includes:
+
+- Refining existing architectural decisions
+- Improving accessibility support
+- Simplifying developer experience
+- Enhancing maintainability
+- Responding to technological evolution
+
+Continuous evolution should preserve the project's architectural identity.
+
+## 8. Major Architectural Evolution
+
+Some changes may fundamentally affect the architecture.
+
+Examples include:
+
+- Replacing core rendering technologies
+- Redefining the public API model
+- Introducing a new architectural paradigm
+- Fundamental changes to supported platforms
+
+Such changes should be treated as major architectural revisions and may require a new major software version.
+
+Major architectural evolution should be carefully evaluated before implementation begins.
+
+## 9. Relationship to Previous Phases
+
+Architecture Change Management builds upon all previous ADM phases.
+
+- Architecture Vision defines the long-term direction.
+- Business Architecture defines the expected business value.
+- Information Systems Architecture defines the application structure.
+- Technology Architecture defines the technical implementation.
+- Opportunities & Solutions defines the implementation roadmap.
+- Migration Planning defines delivery planning.
+- Implementation Governance ensures architectural compliance during implementation.
+
+Architecture Change Management ensures that future architectural evolution remains aligned with these foundations.
+
+## 10. Key Outcome of this Phase
+
+Architecture Change Management establishes:
+
+- A structured process for architectural evolution
+- Clear architecture change triggers
+- Evaluation criteria for architectural decisions
+- Documentation-first architecture evolution
+- Continuous architectural improvement
+- Controlled management of major architectural revisions
+
+The result is an architecture that remains stable, maintainable, and adaptable throughout the lifecycle of LUNA Charts.
+
+## 11. Change Log
+
+No structural changes were introduced in this document during this iteration.
+
+This phase concludes the Architecture Development Method (ADM) lifecycle by defining how architectural evolution is managed after implementation.
+
+The Architecture Change Management process complements the governance model established in Implementation Governance (Phase G) and provides the long-term evolution strategy for LUNA Charts.
@@ -0,0 +1,135 @@
+---
+title: 1. Architecture Vision
+description: Problem statement, objectives, target audience, guiding principles, and success criteria for LUNA Charts.
+sidebar:
+  order: 2
+---
+
+import { Aside } from '@astrojs/starlight/components';
+
+## 1. Problem Statement
+
+Modern web applications are increasingly required to meet accessibility standards such as the European Accessibility Act (EAA) and WCAG 2.2 guidelines.
+
+However, implementing accessible data visualizations remains a complex and underrepresented area in frontend development. Many developers lack specialized knowledge in accessibility design patterns, especially for chart components such as bar, line, or pie charts. As a result, accessibility is often added late, inconsistently, or not at all.
+
+## 2. Objective
+
+LUNA Charts aims to provide a reusable, developer-friendly charting library that enables the creation of accessible, WCAG-oriented data visualizations for web applications.
+
+The primary objective is to reduce the complexity of implementing accessibility in charts while maintaining flexibility for customization and integration into modern frontend stacks.
+
+## 3. Target Audience
+
+The primary stakeholders of LUNA Charts are:
+
+- Frontend developers integrating chart components into web applications
+- Full-stack developers building data-driven products
+- Teams responsible for accessibility compliance in digital products
+
+Secondary stakeholders include:
+
+- UX/UI designers concerned with accessible data representation
+- Accessibility specialists reviewing compliance with WCAG standards
+- End users, including users with visual, cognitive, or motor impairments
+
+## 4. Benefits
+
+LUNA Charts provides the following benefits:
+
+- Simplifies the implementation of accessible data visualizations
+- Reduces the need for deep accessibility expertise in development teams
+- Promotes consistent WCAG-aligned chart behavior across applications
+- Improves development speed by providing reusable, standardized components
+- Enhances end-user accessibility for data-driven interfaces
+- Supports regulatory compliance with accessibility requirements
+
+## 5. Scope
+
+LUNA Charts is a frontend-focused charting library providing reusable components for accessible data visualization.
+
+It is further defined as a **closed system with a strictly controlled input boundary and deterministic internal processing pipeline** (see [Section 8.4](#84-system-boundary-and-extensibility-constraint)).
+
+## 6. Architecture Principles
+
+The following principles guide all architectural decisions in LUNA Charts. They apply across all ADM phases and serve as the basis for evaluating design options, resolving conflicts, and maintaining long-term consistency.
+
+| ID | Principle | Statement | Rationale |
+|----|-----------|-----------|-----------|
+| P01 | Accessibility by Design | Accessibility is a core requirement of every component, not a feature added after the fact. | Aligns with the EAA and WCAG mandate; prevents costly rework in later development stages. |
+| P02 | Framework Agnosticism | LUNA Charts must not introduce tight coupling to any specific frontend framework. | Maximizes adoption potential across React, Vue, Angular, and Web Components ecosystems. |
+| P03 | Developer Experience First | Every API decision is evaluated primarily by the effort it imposes on the integrating developer. | Adoption depends directly on integration speed and ease of use. |
+| P04 | Open Source by Default | LUNA Charts is developed and maintained as an open-source project. | Builds community trust, enables external contributions, and ensures regulatory transparency. |
+| P05 | Standards over Convention | Where open standards exist (WCAG, ARIA, WAI-ARIA), LUNA Charts follows them over proprietary patterns. | Ensures long-term maintainability and compatibility with assistive technologies. |
+| P06 | Lightweight by Design | The library actively minimizes external dependencies and bundle size. | Prevents performance regressions in integrating products. |
+| P07 | Separation of Concerns | Visual rendering, data processing, configuration resolution, and cross-cutting concerns are clearly separated. | Improves testability, predictability, and architectural clarity. |
+
+## 7. Success Criteria
+
+The success of LUNA Charts is primarily measured by:
+
+- Adoption rate among frontend and full-stack developers
+- Integration into production-grade applications
+- Reduction of accessibility-related implementation effort in charting
+- Positive developer experience and ease of integration
+
+## 8. Change Log
+
+<Aside type="note">
+  During subsequent TOGAF ADM phases (Business and Application Architecture), the following refinements were made.
+</Aside>
+
+### 8.1 Accessibility Model Refinement
+
+- Accessibility was reclassified from a conceptual "Accessibility Engine" to a **system-wide cross-cutting concern**
+- Accessibility is enforced across multiple layers:
+  - Default value handling (design-time)
+  - Validation and checks (build-time)
+  - Runtime warnings and safeguards
+
+*(See original Section 1 + Section 6 — refinement of internal architecture interpretation)*
+
+### 8.2 Architectural Structure Shift (Component → Pipeline Model)
+
+- The system architecture was refined from a component-oriented view to a **deterministic processing pipeline model**
+
+![Architectural Structure Shift](https://wiki.byting-pandas.ninja/luna-charts/architecture-vision/luna_charts_architectural_structure_shift.svg)
+
+- Internal processing is now defined as sequential stages:
+  - Input / Interaction
+  - Validation / Resilience
+  - Configuration Resolution
+  - Accessibility Enforcement
+  - Rendering
+
+*(Impacts Section 5 Scope and Section 6 Principles P07)*
+
+### 8.3 Developer Interaction Model Clarification
+
+- The developer interaction model was clarified as a **component-based declarative API**
+- Developers interact via strongly typed chart-specific components such as:
+  - `<BarChart />`
+  - `<LineChart />`
+  - `<PieChart />`
+- Each chart type defines its own strict data model
+
+*(Refines Section 2 Objective and Section 3 Target Audience assumptions)*
+
+### 8.4 System Boundary and Extensibility Constraint
+
+- The architecture was explicitly defined as a **closed system**
+- No plugin system or extension points are provided
+- Internal pipeline stages cannot be modified or extended by external developers
+- Developer interaction is strictly limited to input and configuration at the system boundary
+
+*(Refines Section 5 Scope and Section 6 Principles P07)*
+
+---
+
+## 🔎 Summary of Changes in This Document
+
+The following sections were updated compared to the original version:
+
+- Section 5 (Scope) → clarified system boundary model
+- Section 6 (Principles) → refined separation of concerns wording
+- Section 8 (Evolution Note) → fully introduced and structured architectural evolution
@@ -0,0 +1,197 @@
+---
+title: 2. Business Architecture
+description: Stakeholders, business processes, decision-making model, capability map, and business value driving adoption of LUNA Charts.
+sidebar:
+  order: 3
+---
+
+import { Aside } from '@astrojs/starlight/components';
+
+## 1. Overview
+
+This Business Architecture describes how LUNA Charts is used in a real-world context. It focuses on stakeholders, decision processes, business workflows, and value creation rather than technical implementation details.
+
+LUNA Charts is a developer-focused charting library designed to support the creation of accessible, WCAG-compliant data visualizations in web applications.
+
+## 2. Business Context
+
+Modern software products are required to meet accessibility regulations such as the European Accessibility Act (EAA) and WCAG 2.2 guidelines.
+
+Accessible data visualization is a particularly complex area, especially for chart components (e.g., bar, line, pie charts), where accessibility is often inconsistent or added late in development.
+
+LUNA Charts addresses this gap by providing a reusable solution that reduces accessibility complexity for development teams.
+
+## 3. Business Actors (Stakeholders)
+
+### 3.1 Primary Actors
+
+- Development Team responsible for evaluating, integrating, and maintaining LUNA Charts within the application
+- Product Owner responsible for final decision-making based on business value, cost, and priorities
+
+### 3.2 Supporting Actors
+
+- Software Architect provides technical evaluation and ensures long-term architectural consistency
+- Accessibility / Compliance Stakeholders ensure adherence to WCAG and regulatory requirements
+
+### 3.3 End Users
+
+- Users consuming data visualizations
+- Includes users with disabilities relying on assistive technologies
+
+## 4. Business Trigger (Why the process starts)
+
+The process begins when a product requirement emerges that requires accessible data visualizations.
+
+Typical triggers include:
+
+- Need for WCAG-compliant charts in a product
+- Accessibility audit findings requiring improvements
+- Product Owner requesting new data visualization features
+
+## 5. Business Process (LUNA Charts Adoption Lifecycle)
+
+The adoption of LUNA Charts typically follows this sequence:
+
+- A business need for accessible charts is identified
+- The team researches possible solutions
+- Alternative charting libraries are evaluated
+- LUNA Charts is selected as a candidate solution
+- The team validates usability through documentation and examples
+- A proof of concept is created
+- The Product Owner makes the final decision
+- LUNA Charts is integrated into the product
+- Developers implement charts in production features
+- End users interact with accessible visualizations
+
+## 6. Decision-Making Model
+
+The decision to adopt LUNA Charts is typically shared across roles:
+
+- Development Team → provides technical feasibility assessment
+- Software Architect → evaluates architectural fit and long-term sustainability
+- Product Owner → makes the final investment and product decision
+
+### Decision Criteria Include:
+
+- Documentation quality
+- Community / support availability
+- Licensing model (e.g., Open Source)
+- Technological compatibility (web ecosystem fit)
+- Ease of integration and developer experience
+
+## 7. Business Capability Map
+
+The following capability map defines what LUNA Charts must be able to do as a product — organized into three levels:
+
+- Core Capabilities
+- Enabling Capabilities
+- Governance & Sustainability Capabilities
+
+### 7.1 Core Capabilities
+
+| Capability | Description |
+|------------|-------------|
+| Chart Rendering | Creation of standard data visualizations: bar, line, pie, scatter charts via SVG or Canvas output |
+| Interaction Handling | Enables keyboard navigation, focus management, and non-pointer interaction models across all chart types |
+
+<Aside type="caution" title="⚠️ Important Architectural Change">
+  The **Accessibility Engine was removed as a standalone capability**. Accessibility is now defined as a **cross-cutting system-wide concern**, not a separate capability or module. See [Evolution Note Section 12.1](#121-accessibility-model-refinement).
+</Aside>
+
+### 7.2 Enabling Capabilities
+
+| Capability | Description |
+|------------|-------------|
+| Configuration & Theming | Allows customization of chart appearance including colors, contrast, labels, and layout |
+| Framework Integration | Enables embedding into modern web application frameworks: React, Vue, Angular, and Web Components |
+| Data Processing | Handles normalization, scaling, and transformation of input datasets into renderable structures |
+| Documentation & DX | Maintains API documentation, examples, and developer experience consistency |
+
+### 7.3 Governance & Sustainability
+
+| Capability | Description |
+|------------|-------------|
+| Release Management | Governs versioning (Semantic Versioning), changelog discipline, and predictable releases |
+| Compliance Monitoring | Tracks WCAG audit status across releases and prevents regressions |
+
+## 8. Business Value
+
+### 8.1 Value for Development Teams
+
+- Faster implementation of charts
+- No need for deep accessibility expertise
+- Reduced implementation complexity
+- Standardized reusable solution
+
+### 8.2 Value for Product Owners
+
+- Reduced development and maintenance costs
+- Lower risk of accessibility compliance issues
+- Avoidance of repeated evaluation efforts
+- Predictable integration effort
+
+### 8.3 Value for End Users
+
+- Improved accessibility of information
+- Support for assistive technologies
+- More consistent data visualization experience
+
+## 9. Business Risks / Reasons for Rejection
+
+LUNA Charts may be rejected if:
+
+- Lack of commercial support raises operational risk concerns
+- Limited chart types do not meet product requirements
+- Insufficient flexibility for custom visualization needs
+- Concerns about long-term maintenance in open-source context
+
+## 10. Business Constraints
+
+- Must operate in modern web environments
+- Must integrate with existing frontend architectures
+- Must support accessibility requirements (WCAG compliance)
+- Must remain lightweight and developer-friendly
+- Must not introduce excessive framework lock-in
+- **Must operate as a closed system with defined input boundary and no extension mechanisms** *(See [Evolution Note 12.2](#122-system-boundary--extensibility-constraint))*
+
+## 11. Key Outcome of this Phase
+
+The Business Architecture defines:
+
+- How LUNA Charts is evaluated and adopted
+- Which stakeholders influence the decision
+- What value is expected from the solution
+- Which risks can lead to rejection
+- How the solution fits into real-world workflows
+- Which capabilities the product must maintain to remain viable
+
+## 12. Change Log
+
+### 12.1 Accessibility Model Refinement
+
+- The previously defined "Accessibility Engine" was removed as a standalone capability
+- Accessibility is now defined as a **system-wide cross-cutting concern**
+- It is enforced through:
+  - Default configurations
+  - Validation processes
+  - Runtime feedback mechanisms
+
+*(Impacts Section 7.1 Core Capabilities)*
+
+### 12.2 System Boundary & Extensibility Constraint
+
+- LUNA Charts is explicitly defined as a **closed system**
+- No plugin or extension mechanism is provided
+- Developers cannot modify internal processing pipeline behavior
+- Interaction is limited to declarative input and configuration only
+
+*(Impacts Section 10 Business Constraints and Section 6 Decision Criteria indirectly)*
+
+### 12.3 Architectural Model Alignment (Business ↔ Application)
+
+- The Business Architecture now explicitly aligns with the Application Architecture:
+  - Declarative component-based API model
+  - Strict separation of responsibilities
+  - Accessibility as cross-cutting concern
+
+*(Ensures consistency with Phase C decisions)*
@@ -0,0 +1,199 @@
+---
+title: 7. Implementation Governance
+description: Roles, review processes, and quality gates that keep LUNA Charts implementation aligned with the documented architecture.
+sidebar:
+  order: 8
+---
+
+## 1. Overview
+
+This phase defines how the implementation of LUNA Charts is governed to ensure long-term architectural consistency, product quality, and maintainability.
+
+Rather than introducing new architectural decisions, Implementation Governance ensures that all implementation activities remain aligned with the architecture defined in previous phases. It establishes responsibilities, review processes, quality gates, and decision-making procedures for both contributors and maintainers.
+
+As an open-source project, LUNA Charts balances community contributions with centralized architectural governance to protect the project's long-term vision.
+
+## 2. Governance Principles
+
+Implementation Governance is guided by the following principles:
+
+- Architecture remains the authoritative source for implementation decisions.
+- Community contributions are encouraged but do not define the architecture.
+- Architectural decisions are reviewed collectively by the Maintainer Team.
+- Quality requirements apply consistently across the entire project.
+- Architectural evolution is documented and traceable through the architecture repository.
+
+## 3. Governance Roles
+
+### Community
+
+The community contributes ideas and implementation proposals.
+
+Responsibilities include:
+- Reporting bugs
+- Suggesting improvements
+- Participating in architectural discussions
+- Creating Pull Requests
+
+The community may influence discussions but does not make architectural decisions.
+
+### Contributors
+
+Contributors actively improve the project.
+
+Responsibilities include:
+- Implementing new features
+- Fixing defects
+- Improving documentation
+- Maintaining existing functionality
+
+All contributions are subject to review before integration.
+
+### Maintainers
+
+The Maintainer Team is responsible for the long-term integrity of the project.
+
+Responsibilities include:
+- Reviewing Pull Requests
+- Protecting architectural consistency
+- Approving architectural changes
+- Ensuring accessibility standards
+- Maintaining API stability
+- Approving public releases
+
+Architectural governance is owned collectively by the Maintainer Team rather than by an individual contributor.
+
+## 4. Governance Layers
+
+Implementation Governance operates across three complementary layers.
+
+### 4.1 Automated Governance
+
+Objective quality checks performed automatically during development.
+
+Examples include:
+- TypeScript validation
+- Linting
+- Unit testing
+- Accessibility testing
+- Build verification
+- Continuous Integration (CI)
+
+These checks ensure that objective quality requirements are consistently enforced.
+
+### 4.2 Architectural Governance
+
+Architectural Governance ensures that implementations remain aligned with the defined architecture.
+
+Maintainers review topics such as:
+- Public API consistency
+- Architectural boundaries
+- Rendering strategy
+- Cross-cutting concerns
+- Long-term maintainability
+
+Architectural compliance cannot be verified solely through automation and therefore requires human review.
+
+### 4.3 Project Governance
+
+Project Governance focuses on overall software quality beyond technical correctness.
+
+Evaluation criteria include:
+- Code readability
+- Maintainability
+- Documentation quality
+- Consistency with project conventions
+- Long-term sustainability
+
+A contribution may therefore be rejected even if all automated quality checks have passed.
+
+## 5. Architectural Compliance
+
+Every contribution is evaluated against the documented architecture.
+
+A Pull Request may be rejected if it:
+- Violates documented architectural decisions
+- Introduces unnecessary API changes
+- Circumvents accessibility mechanisms
+- Ignores cross-cutting concerns
+- Reduces maintainability or consistency
+- Conflicts with established architectural principles
+
+Maintainers are responsible for ensuring compliance before accepting contributions.
+
+## 6. Architectural Change Process
+
+Architectural evolution follows a structured review process.
+
+```text
+Proposal
+    ↓
+Architecture Discussion
+    ↓
+Maintainer Review
+    ↓
+Decision
+    ↓
+Architecture Documentation Update
+    ↓
+Evolution Note
+    ↓
+Implementation
+```
+
+Architectural decisions become official only after the architecture documentation has been updated.
+
+Implementation follows the documented architecture rather than defining it.
+
+## 7. Release Governance
+
+Public releases require successful completion of all mandatory quality gates defined by the Technology Architecture.
+
+These quality gates include, where applicable:
+- Automated testing
+- Accessibility validation
+- Build verification
+- Packaging validation
+- Release-specific usability testing
+
+Implementation Governance ensures that releases cannot be approved until all required validation activities have been successfully completed.
+
+## 8. Continuous Architecture Evolution
+
+The architecture is expected to evolve throughout the lifetime of the project.
+
+Potential triggers include:
+- New WCAG recommendations
+- Browser platform changes
+- TypeScript language evolution
+- SVG specification updates
+- Community feedback
+- Long-term maintainability concerns
+
+All architectural changes follow the same governance process regardless of their origin.
+
+## 9. Key Outcome of this Phase
+
+Implementation Governance defines:
+
+- Governance responsibilities
+- Review and approval processes
+- Automated and manual quality controls
+- Architectural compliance rules
+- Release approval governance
+- Continuous architecture evolution
+
+The result is a governance model that protects the long-term architectural integrity of LUNA Charts while enabling collaborative open-source development.
+
+## 10. Change Log
+
+No structural changes were introduced in this document during this iteration.
+
+This governance model is fully aligned with:
+
+- Architecture Vision (Phase A)
+- Business Architecture (Phase B)
+- Information Systems Architecture (Phase C)
+- Technology Architecture (Phase D)
+- Opportunities & Solutions (Phase E)
+- Migration Planning (Phase F)
@@ -0,0 +1,74 @@
+---
+title: What is the Architecture Development Method (ADM)
+description: Overview of the TOGAF Architecture Development Method (ADM) used in LUNA-Charts.
+sidebar:
+  order: 1
+---
+
+import { Aside, Steps, Card, CardGrid } from '@astrojs/starlight/components';
+
+The **Architecture Development Method (ADM)** is the core process at the heart of [TOGAF](https://www.opengroup.org/togaf) (The Open Group Architecture Framework), one of the most widely used enterprise architecture frameworks. It provides a step-by-step, iterative approach for developing, implementing, and governing enterprise architecture.
+
+## Purpose
+
+ADM gives organizations a repeatable, structured way to design architecture that aligns business goals with IT systems, rather than approaching architecture work ad hoc.
+
+<Aside type="note">
+  ADM is typically visualized as a wheel/cycle, since architecture work is iterative rather than strictly linear.
+</Aside>
+
+## The Phases
+
+<Steps>
+
+1. **Preliminary Phase**
+   Define the architecture framework, principles, and scope for the organization.
+
+2. **Phase A: Architecture Vision**
+   Establish the scope, stakeholders, constraints, and high-level vision of the project.
+
+3. **Phase B: Business Architecture**
+   Model current and target business processes, organization, and capabilities.
+
+4. **Phase C: Information Systems Architectures**
+   Split into Data Architecture and Application Architecture.
+
+5. **Phase D: Technology Architecture**
+   Define hardware, software, and network infrastructure needed to support the architecture.
+
+6. **Phase E: Opportunities & Solutions**
+   Identify major implementation projects and delivery vehicles.
+
+7. **Phase F: Migration Planning**
+   Prioritize projects and develop a detailed roadmap.
+
+8. **Phase G: Implementation Governance**
+   Ensure implementation projects conform to the architecture.
+
+9. **Phase H: Architecture Change Management**
+   Monitor and manage changes to the architecture over time.
+
+</Steps>
+
+<Aside type="tip">
+  **Requirements Management** runs through the center of the ADM cycle, since requirements can emerge and need to be addressed at any phase.
+</Aside>
+
+## Phase C in Detail
+
+<CardGrid>
+  <Card title="Data Architecture">
+    Structure of an organization's logical and physical data assets.
+  </Card>
+  <Card title="Application Architecture">
+    Blueprint for individual application systems, their interactions, and their relationships to core business processes.
+  </Card>
+</CardGrid>
+
+## Key Characteristics
+
+- **Iterative** — Organizations often cycle through the phases multiple times, refining architecture at increasing levels of detail.
+- **Adaptable** — Phases can be tailored, skipped, or reordered depending on the organization's needs and maturity.
+- **Governance-focused** — Strong emphasis on ensuring architecture decisions are actually implemented and maintained correctly.
+
+---
@@ -0,0 +1,206 @@
+---
+title: 3. Information Systems Architecture
+description: Internal application design of LUNA Charts and how the system is structured to process and render data.
+sidebar:
+  order: 4
+---
+
+import { Aside } from '@astrojs/starlight/components';
+
+## 1. Overview
+
+This Application Architecture defines how LUNA Charts is structured at the application level. It describes the internal processing model, developer interaction boundaries, system layers, and architectural style used to ensure accessible, consistent, and predictable chart rendering.
+
+LUNA Charts is designed as a declarative, component-based charting library with a controlled internal processing pipeline and strict input boundaries.
+
+## 2. Architectural Style
+
+LUNA Charts follows a:
+
+- Declarative API model
+- Component-based developer interface
+- Black-box processing pipeline
+- Opinionated and non-extensible architecture
+
+### Key Characteristics
+
+- Single entry point for developers via chart components
+- Strict separation between input and internal processing
+- Deterministic rendering behavior
+- No plugin or extension system
+- Accessibility and validation are enforced internally
+
+## 3. Developer Interaction Model
+
+Developers interact with LUNA Charts exclusively through a declarative component API.
+
+### Public API
+
+- `<BarChart />`
+- `<LineChart />`
+- `<PieChart />`
+- (and other chart-specific components)
+
+Each component has its own strongly typed data model.
+
+### Responsibilities of the Developer
+
+Developers are responsible for:
+
+- Providing correctly structured data per chart type
+- Using typed configuration models provided by the library
+- Preparing and transforming data before passing it into the component
+
+### Restrictions
+
+Developers cannot:
+
+- Modify internal rendering logic
+- Override accessibility processing
+- Inject plugins or extensions
+- Interfere with internal pipeline stages
+
+## 4. System Boundary Model
+
+LUNA Charts exposes a strict system boundary:
+
+### Allowed Inputs
+
+- Typed chart components
+- Structured data per chart type
+- Configuration properties (themes, labels, styling overrides)
+
+### Internal System Ownership
+
+After input is provided, the system fully controls:
+
+- Data validation
+- Configuration resolution
+- Accessibility enforcement (system-wide cross-cutting concern)
+- Rendering process
+- Fallback behavior
+
+## 5. Internal Processing Pipeline
+
+LUNA Charts processes all input through a deterministic pipeline:
+
+![Internal Processing Pipeline](https://wiki.byting-pandas.ninja/luna-charts/information-systems-architecture-diagrams/luna_charts_internal_processing_pipeline.svg)
+
+### 5.1 Interaction Layer (Entry Point)
+
+Receives component input, accepts data and configuration, and normalizes incoming parameters.
+
+### 5.2 Resilience & Validation Layer
+
+Validates input data integrity, detects missing or invalid values, triggers fallback behavior if necessary, and emits warnings for developer feedback.
+
+### 5.3 Configuration Resolution Layer
+
+Merges user configuration with default values, resolves themes, labels, and styling parameters, and applies library-provided defaults when needed.
+
+### 5.4 Accessibility Enforcement Layer
+
+Applies accessibility rules and guidance mechanisms intended to support WCAG-compliant chart implementations, generates ARIA attributes, validates known accessibility constraints, and provides runtime warnings and developer feedback.
+
+<Aside type="tip">
+  Accessibility enforcement is a cross-cutting concern applied across all layers — see [Section 4](#4-system-boundary-model).
+</Aside>
+
+### 5.5 Rendering Layer
+
+Transforms processed data into visual representations, generates SVG or Canvas output, and produces the final chart visualization.
+
+## 6. Chart Type Model
+
+LUNA Charts uses explicit chart-type components:
+
+- `<BarChart />`
+- `<LineChart />`
+- `<PieChart />`
+
+### Characteristics
+
+- Each chart type has a dedicated internal rendering strategy
+- Chart type selection is static and defined at component level
+- No runtime switching of chart types
+- Each chart type defines its own data structure
+
+## 7. Cross-Cutting Concerns
+
+### Accessibility (System-wide Concern)
+
+Accessibility is implemented through a combination of type-safe APIs, validation mechanisms, default configurations, runtime warnings, and internal quality assurance processes.
+
+It includes:
+
+- WCAG compliance rules
+- ARIA generation
+- Accessibility validation
+- Runtime and build-time checks
+
+### Resilience & Fallback Behavior
+
+The system ensures stability through:
+
+- Default values for missing configurations
+- Fallback labels for missing data
+- Safe rendering under incomplete input
+- Warning generation for developer feedback
+
+## 8. Configuration Model
+
+LUNA Charts provides a strongly typed configuration system.
+
+Developers can configure:
+
+- Themes (colors, contrast, styling)
+- Labels and text overrides
+- Chart-specific display options
+- Accessibility hints (optional)
+
+Configuration is merged with system defaults during the processing pipeline.
+
+## 9. Technology-Agnostic Design
+
+This Application Architecture does not assume a specific frontend framework but is compatible with modern web ecosystems such as:
+
+- React
+- Vue
+- Angular
+- Web Components
+
+The API is component-based but conceptually framework-agnostic.
+
+## 10. Key Architectural Decisions
+
+- Component-based declarative API is used instead of pure DSL or JSON input
+- System uses a single controlled entry point for all interactions
+- Internal pipeline is fully deterministic and not externally modifiable
+- Accessibility is enforced as a core system responsibility
+- No plugin or extension mechanisms are provided
+- Chart types are explicitly defined and not dynamically extensible
+
+## 11. Trade-offs
+
+### Advantages
+
+- Strong accessibility guarantees
+- High consistency across all charts
+- Excellent developer experience
+- Predictable behavior
+- Reduced implementation complexity
+
+### Limitations
+
+- Limited extensibility for custom chart types
+- Reduced low-level control over rendering
+- Strict API constraints for developers
+- No plugin ecosystem support
+
+## 12. Evolution Note
+
+No structural changes were introduced in this document during this iteration. This architecture remains fully aligned with:
+
+- Architecture Vision (Phase A)
+- Business Architecture (Phase B)
+- Information System Architecture (Phase C)
@@ -0,0 +1,29 @@
+---
+title: Introduction to LUNA Charts using the ADM
+description: A short introduction to LUNA Charts and how its architecture documentation follows the TOGAF Architecture Development Method (ADM).
+sidebar:
+  order: 1
+---
+
+import { Aside } from '@astrojs/starlight/components';
+
+LUNA Charts is a reusable, developer-friendly charting library that makes accessible, WCAG-oriented data visualization the default rather than an afterthought. Since chart accessibility is often added late or skipped entirely, LUNA Charts bakes it into every component from the start.
+
+## Documented with the ADM
+
+To keep the architecture consistent and traceable as the project grows, this documentation follows the **TOGAF Architecture Development Method (ADM)** — an iterative, phase-based process for developing and governing enterprise architecture.
+
+Each phase of the ADM maps to one section of this wiki:
+
+- **Architecture Vision** — problem statement and objectives
+- **Business Architecture** — stakeholders and value drivers
+- **Information Systems Architecture** — internal application design
+- **Technology Architecture** — underlying technology choices
+- **Opportunities & Solutions** — implementation roadmap
+- **Migration Planning** — staged rollout plan
+- **Implementation Governance** — quality gates and review process
+- **Architecture Change Management** — how the architecture evolves
+
+<Aside type="tip">
+  Reading the phases in order helps, since later phases build on decisions made earlier in the cycle.
+</Aside>
@@ -0,0 +1,221 @@
+---
+title: 6. Migration Planning
+description: Staged delivery plan for rolling out the LUNA Charts architecture over time.
+sidebar:
+  order: 7
+---
+
+## 1. Overview
+
+This phase defines how LUNA Charts transitions from architectural design into a deliverable product.
+
+Unlike traditional migration planning, LUNA Charts is a greenfield project with no existing solution to replace. Therefore, this phase focuses on planning the incremental delivery of the solution through implementation milestones and public releases.
+
+The objective is to maximize business value while minimizing implementation risk by validating architectural decisions before expanding the solution.
+
+## 2. Delivery Strategy
+
+LUNA Charts follows an incremental delivery strategy.
+
+Implementation begins with establishing the architectural groundwork, followed by a reference implementation used to validate the overall architecture.
+
+Once a usable Minimum Viable Product (MVP) has been completed and reviewed internally, the project transitions into parallel development and continuous feature expansion.
+
+This approach enables early stakeholder feedback while ensuring that public releases maintain a professional quality standard.
+
+## 3. Migration Stages
+
+### Stage 1 – Architectural Groundwork
+
+**Objective**
+Establish the technical foundations required for all future chart implementations.
+
+**Deliverables**
+- Type System
+- Public API Contracts
+- Rendering Foundation
+- Configuration Model
+- Validation Framework
+
+**Outcome**
+A stable architectural foundation capable of supporting reusable chart implementations.
+
+### Stage 2 – Reference Implementation
+
+**Objective**
+Validate the architecture through a production-ready BarChart implementation.
+
+**Deliverables**
+- BarChart component
+- Rendering pipeline
+- Accessibility support
+- Configuration integration
+- Validation integration
+
+**Outcome**
+Confirmation that the architectural decisions are viable for real-world usage.
+
+### Stage 3 – Minimum Viable Product (MVP)
+
+**Objective**
+Create the first usable product increment.
+
+**Deliverables**
+- BarChart Reference Implementation
+- Documentation & Developer Experience
+
+**Outcome**
+The first version that can be evaluated by stakeholders and integrated into demonstration applications.
+
+The MVP serves as the primary milestone for Product Owner review and architectural validation.
+
+### Stage 4 – Public Release Preparation
+
+**Objective**
+Prepare the library for public distribution.
+
+**Deliverables**
+- Unit Tests
+- Accessibility Tests
+- Linting
+- Visual Regression Testing
+- GitHub Release Pipeline
+- npm Publishing
+
+**Outcome**
+A production-ready release process capable of delivering reliable public versions.
+
+### Stage 5 – Product Evolution
+
+**Objective**
+Expand the library after the initial public release.
+
+**Examples**
+- LineChart
+- PieChart
+- ScatterChart
+
+Future enhancements remain based on the architectural foundations established during earlier stages.
+
+## 4. Delivery Roadmap
+
+The planned delivery sequence is illustrated below.
+
+### Internal Delivery
+
+```text
+WP1 Groundwork
+        ↓
+WP2 BarChart Reference Implementation
+        ↓
+WP3 Documentation & Developer Experience
+        ↓
+Internal Product Review (MVP)
+```
+
+The MVP enables architectural validation and stakeholder feedback before the first public release.
+
+### Public Delivery
+
+```text
+Internal MVP
+      ↓
+WP4 Quality & Release Infrastructure
+      ↓
+Public Release 1.0.0
+      ↓
+WP5 Additional Chart Types
+      ↓
+Future Releases
+```
+
+The first public release prioritizes stability, documentation, accessibility, and developer experience over feature completeness.
+
+## 5. Stakeholder Validation Strategy
+
+Different stakeholders participate at different stages of the delivery process.
+
+### Internal Stakeholders
+
+- Development Team
+- Software Architect
+- Product Owner
+
+**Responsibilities**
+- Validate architectural decisions
+- Review developer experience
+- Confirm business value
+- Evaluate implementation quality
+
+### External Stakeholders
+
+- Open-source community
+- Frontend developers
+- Accessibility specialists
+
+**Responsibilities**
+- Adopt the library
+- Provide community feedback
+- Report issues
+- Contribute improvements
+
+Public stakeholder involvement begins after the first production-ready release.
+
+## 6. Release Strategy
+
+LUNA Charts distinguishes between internal milestones and public releases.
+
+### Internal Milestones
+
+**Purpose**
+- Validate architecture
+- Validate usability
+- Gather Product Owner feedback
+
+Internal milestones are not intended for public consumption.
+
+### Public Releases
+
+**Purpose**
+- Stable APIs
+- Complete documentation
+- Reliable release process
+- Community adoption
+
+Public releases follow Semantic Versioning and are published through npm and GitHub.
+
+## 7. Migration Risks
+
+Potential risks include:
+
+- Architectural refinements discovered during the reference implementation
+- Additional accessibility requirements emerging during implementation
+- Delays caused by documentation or quality assurance activities
+- API adjustments before the first stable release
+
+These risks are mitigated by validating the architecture before expanding the feature set.
+
+## 8. Key Outcome of this Phase
+
+Migration Planning defines:
+
+- The incremental delivery strategy
+- Internal implementation milestones
+- The Minimum Viable Product (MVP)
+- The transition from internal validation to public releases
+- Stakeholder involvement throughout delivery
+- The long-term release strategy for LUNA Charts
+
+The result is a structured roadmap that transforms the architectural vision into a deliverable, production-ready open-source project.
+
+## 9. Change Log
+
+No structural changes were introduced in this document during this iteration.
+
+This migration strategy is fully aligned with:
+
+- Architecture Vision (Phase A)
+- Business Architecture (Phase B)
+- Information Systems Architecture (Phase C)
+- Technology Architecture (Phase D)
+- Opportunities & Solutions (Phase E)
@@ -0,0 +1,227 @@
+---
+title: 5. Opportunities & Solutions
+description: Work packages that translate the LUNA Charts architecture into an implementation roadmap.
+sidebar:
+  order: 6
+---
+
+import { Aside } from '@astrojs/starlight/components';
+
+## 1. Overview
+
+This phase translates the target architecture into implementable solution increments. It identifies the major work packages required to realize LUNA Charts and defines their dependencies, priorities, and expected outcomes.
+
+As LUNA Charts is a greenfield project, the focus is not on migration from an existing solution but on establishing a structured implementation path from architecture to a production-ready charting library.
+
+The goal of this phase is to identify what must be built, in which order it should be built, and which implementation areas can later evolve independently.
+
+## 2. Solution Strategy
+
+LUNA Charts is implemented incrementally.
+
+The implementation begins with a foundational groundwork package that establishes the architectural contracts and reusable building blocks required by all future chart types.
+
+A BarChart is then implemented as the first production-ready chart and serves as a reference implementation for validating architectural decisions.
+
+Once the architecture has been validated through the BarChart implementation, **Documentation & Developer Experience is completed to form the first usable Minimum Viable Product (MVP)**.¹
+
+After this milestone has been reached, the remaining work packages can proceed in parallel.¹
+
+## 3. Work Packages
+
+### WP1 – Groundwork
+
+**Objective**
+Establish all reusable architectural foundations required for chart implementation.
+
+**Scope**
+- Type System
+- Public API Contracts
+- Rendering Foundation
+- Configuration Model
+- Validation Framework
+
+**Expected Outcome**
+The groundwork package is considered complete when:
+- Public APIs are defined
+- Chart-related data types are available
+- Rendering utilities exist
+- Configuration handling is established
+- Validation and warning mechanisms are implemented
+- A chart implementation can be built on top of the provided foundations
+
+**Architectural Role**
+This work package provides the reusable building blocks used by all future chart types.
+
+### WP2 – BarChart Reference Implementation
+
+**Objective**
+Implement the first production-ready chart type and validate the architecture.
+
+**Scope**
+- BarChart component
+- Rendering integration
+- Accessibility validation
+- Configuration integration
+- Validation integration
+
+**Expected Outcome**
+The BarChart serves as a reference implementation demonstrating that:
+- The public API is usable
+- The rendering architecture is viable
+- Accessibility concepts are effective
+- Reusable foundations support real-world chart implementations
+
+**Architectural Role**
+This work package acts as the architectural proof-of-concept for the entire solution.
+
+### WP3 – Documentation & Developer Experience
+
+**Objective**
+Enable developers to successfully adopt and use LUNA Charts.
+
+**Scope**
+- Getting Started Guides
+- Tutorials
+- API Documentation
+- Accessibility Guidance
+- Usage Examples
+
+**Expected Outcome**
+Developers can understand, integrate, and use LUNA Charts without requiring internal architectural knowledge.
+
+### WP4 – Quality & Release Infrastructure
+
+**Objective**
+Ensure product quality and reliable software delivery.
+
+**Scope**
+- Unit Testing
+- Accessibility Testing
+- Linting
+- Visual Regression Testing
+- GitHub Release Pipeline
+- npm Publishing
+
+**Expected Outcome**
+All releases follow a repeatable and quality-controlled process.
+
+### WP5 – Additional Chart Types
+
+**Objective**
+Extend the library with additional chart implementations.
+
+**Scope**
+Examples include:
+- LineChart
+- PieChart
+- ScatterChart
+
+Additional chart types may be introduced based on project priorities and community demand.
+
+**Expected Outcome**
+The chart ecosystem expands while reusing the foundations established in earlier work packages.
+
+## 4. Work Package Dependencies
+
+The implementation follows a staged approach.
+
+### Phase 1
+
+```
+WP1 Groundwork
+        ↓
+WP2 BarChart Reference Implementation
+        ↓
+WP3 Documentation & Developer Experience¹
+        ↓
+Internal Product Review (MVP)¹
+```
+
+The first implementation phase focuses on validating the architecture and delivering the first usable product increment.
+
+Although Documentation & Developer Experience is modeled as an independent work package, it is functionally coupled to the BarChart Reference Implementation. Together they form the project's first Minimum Viable Product (MVP), enabling meaningful stakeholder evaluation.
+
+### Phase 2
+
+After successful completion of the BarChart reference implementation, additional work packages can proceed independently.
+
+```
+                MVP¹
+                 │
+        ┌────────┴────────┐
+        ▼                 ▼
+WP4 Quality &      WP5 Additional
+Release             Chart Types
+Infrastructure
+```
+
+Although Documentation & Developer Experience is modeled as an independent work package, it is functionally coupled to the BarChart Reference Implementation.¹ Together they form the project's first Minimum Viable Product (MVP), enabling meaningful stakeholder evaluation.
+
+## 5. Accessibility Strategy
+
+Accessibility is not implemented as a dedicated work package.
+
+Instead, accessibility requirements are integrated into all work packages and act as a cross-cutting quality requirement throughout the solution.
+
+Examples include:
+- Accessibility-related type definitions
+- Validation rules and developer warnings
+- Accessible default values and fallbacks
+- Accessible SVG output generation
+- Accessibility-focused documentation
+- Automated accessibility testing
+
+This approach aligns with the architectural principle of Accessibility by Design established in the Architecture Vision.
+
+## 6. Solution Risks
+
+Potential risks include:
+- Architectural assumptions may prove invalid during the BarChart reference implementation
+- Accessibility requirements may reveal additional constraints during implementation
+- Future chart types may require capabilities not anticipated during groundwork design
+- Open-source maintenance capacity may influence implementation speed
+
+These risks are mitigated through the staged implementation approach and early architectural validation.
+
+## 7. Key Outcome of this Phase
+
+- The implementation strategy for LUNA Charts
+- The major work packages required for delivery
+- Dependencies between implementation activities
+- The role of the BarChart as a reference implementation
+- The definition of the first usable MVP consisting of the BarChart implementation and developer documentation¹
+- The integration of accessibility as a cross-cutting concern
+- A phased roadmap for incremental solution realization
+
+## 8. Change Log
+
+<Aside type="note">
+  ¹ Updated during Phase F (Migration Planning). See Evolution Note below for details.
+</Aside>
+
+### Work Package Dependencies and MVP Definition
+
+**Reason**
+
+During Migration Planning (Phase F), it became clear that the BarChart Reference Implementation alone does not provide sufficient business value for stakeholder evaluation. A usable product increment also requires developer documentation and onboarding material.
+
+This insight refined the implementation sequence without changing the overall work package structure.
+
+**Changes**
+
+- Clarified that **WP3 – Documentation & Developer Experience** is functionally coupled to **WP2 – BarChart Reference Implementation**.
+- Defined the project's first **Minimum Viable Product (MVP)** as the combination of:
+  - WP2 – BarChart Reference Implementation
+  - WP3 – Documentation & Developer Experience
+- Updated the work package dependency model so that parallel development begins only after the MVP has been completed and reviewed.
+- Refined the solution strategy to distinguish between:
+  - Architectural validation (Groundwork + BarChart)
+  - MVP completion (Documentation & Developer Experience)
+  - Subsequent parallel solution evolution
+
+**Impact**
+
+The overall work package structure remains unchanged.
+
+Only the implementation sequence has been refined to better align the technical implementation with the project's business objectives. This ensures that the first stakeholder evaluation is based on a usable product increment rather than a purely technical implementation.
@@ -0,0 +1,306 @@
+---
+title: 4. Technology Architecture
+description: Technology choices underlying LUNA Charts and how they are structured together.
+sidebar:
+  order: 5
+---
+
+import { Aside } from '@astrojs/starlight/components';
+
+## 1. Overview
+
+This Technology Architecture defines the underlying technology decisions for LUNA Charts. It describes the runtime environment, rendering technology, programming language, distribution model, testing strategy, and release pipeline.
+
+LUNA Charts is designed as a modern, accessibility-first charting library optimized for web environments, focusing on performance, consistency, and WCAG-oriented rendering behavior.
+
+## 2. Rendering Technology
+
+### SVG-based Rendering Model
+
+LUNA Charts uses **SVG (Scalable Vector Graphics)** as its primary rendering technology.
+
+#### Rationale
+
+- Enables element-level accessibility (focusable nodes)
+- Supports ARIA attributes per visual element
+- Allows keyboard navigation across chart components
+- Provides native DOM structure for assistive technologies
+- Ensures compatibility with WCAG 2.2 requirements
+
+#### Exclusion of Canvas
+
+Canvas-based rendering is explicitly excluded because:
+
+- It produces pixel-based output without semantic structure
+- Individual chart elements cannot be addressed or focused
+- Accessibility must be simulated externally (insufficient for WCAG goals)
+- It conflicts with the "Accessibility by Design" principle
+
+## 3. Programming Language
+
+### TypeScript
+
+LUNA Charts is implemented in TypeScript.
+
+#### Rationale
+
+- Strong typing for chart-specific data models
+- Early error detection at compile time
+- Improved developer experience (DX) via IntelliSense
+- Explicit API contracts for all chart components
+- Supports structured accessibility-related metadata
+
+#### Architectural Impact
+
+- Each chart type has a dedicated strongly typed data model
+- Invalid configurations can be detected before runtime
+- Improves reliability of accessibility-related constraints
+
+## 4. Framework Integration Strategy
+
+### Framework-Neutral Core with Adapter Layer
+
+LUNA Charts is designed as a framework-agnostic system.
+
+#### Architecture Model
+
+- Core rendering and logic are framework-independent
+- Framework-specific adapters provide integration layers
+
+#### Supported Environments
+
+- React
+- Vue
+- Angular
+- Web Components
+
+#### Rationale
+
+- Prevents vendor lock-in
+- Ensures consistent behavior across frameworks
+- Aligns with "Framework Agnosticism" principle (P02)
+- Maximizes adoption across ecosystems
+
+## 5. Distribution Strategy
+
+### Single-Package Consumption Model
+
+LUNA Charts is distributed as a single unified package.
+
+#### Characteristics
+
+- No plugin system
+- No external extensions by consumers
+- All functionality is included in the core distribution
+
+#### Example Usage
+
+```bash
+npm install luna-charts
+```
+
+```jsx
+<BarChart data={...} />
+```
+
+#### Rationale
+
+- Simplifies developer experience
+- Ensures consistent API behavior
+- Maintains strict control over accessibility compliance
+- Avoids fragmentation of implementation quality
+
+## 6. Testing & Quality Strategy
+
+LUNA Charts follows a multi-layer quality assurance model.
+
+### 6.1 Functional Testing
+
+- Unit Tests for core logic
+- Ensures correctness of rendering pipeline
+
+### 6.2 Accessibility Testing
+
+- Automated accessibility validation tools
+- Checks WCAG-related constraints where machine-verifiable
+- Ensures ARIA structure correctness
+
+### 6.3 Code Quality (Linting)
+
+- Enforces architectural consistency
+- Prevents API misuse patterns
+- Ensures maintainable code structure
+
+### 6.4 Visual Regression Testing
+
+- Ensures SVG rendering stability
+- Detects unintended layout or structural changes
+- Validates accessibility-relevant DOM consistency
+
+### 6.5 Usability Testing
+
+- Manual or moderated usability sessions with representative developers/end users
+- Validates real-world developer experience and end-user comprehension of charts
+- Required for **minor and major releases** (new chart types, API changes, significant UX changes)
+- **Not required for patch releases** (bug fixes, internal refactors with no user-facing change)
+
+<Aside type="caution" title="Release Gate Policy">
+  Automated testing (unit, accessibility, linting, visual regression) is a **blocking condition for every release**. Usability testing is a **blocking condition for minor and major releases**, but is skipped for patch releases to avoid delaying critical fixes.
+</Aside>
+
+### 6.6 Test Execution Environment
+
+Component and browser tests (Vitest browser mode, see ADR-0002) run inside
+a **containerized Playwright environment** rather than directly on
+contributor or CI host machines.
+
+#### Characteristics
+
+- A dedicated `Dockerfile.test`, based on the official Playwright container
+  image, provides a reproducible browser environment with pinned browser
+  versions
+- Locally, `docker-compose.test.yaml` builds this image from source and
+  orchestrates test execution, isolating dependencies from the host system
+- In Continuous Integration, the same `Dockerfile.test` is built and
+  pushed to the project's container registry out-of-band (tagged by
+  Playwright version, e.g. `luna-charts-test:v1.62.1`); CI jobs pull this
+  prebuilt image directly rather than rebuilding it on every run, then
+  check out the current commit and install dependencies inside the running
+  container before executing tests
+- `Dockerfile.test` remains the single source of truth for the test
+  environment definition in both cases — only *when* the image is built
+  (on demand locally, ahead of time for CI) differs
+
+#### Rationale
+
+- Ensures deterministic, reproducible accessibility and browser test
+  results independent of the host operating system
+- Removes the need for contributors to install and maintain matching
+  Playwright browser binaries locally
+- Avoids rebuilding the Playwright/browser image on every CI run, which
+  would otherwise require Docker-in-Docker access inside the CI runner —
+  significant infrastructure complexity for a single-service image build
+- Aligns automated testing (Section 6.1–6.4) with a single,
+  version-controlled execution environment definition, even though the
+  build trigger differs between local development and CI
+
+## 7. Release & Distribution Model
+
+### Open Source Release Pipeline
+
+LUNA Charts is developed as an open-source project.
+
+#### Distribution Flow
+
+![Release & Distribution Flow](https://wiki.byting-pandas.ninja/luna-charts/luna_charts_release_distribution_flow_v.svg)
+
+#### Versioning Strategy
+
+Semantic Versioning (SemVer):
+
+- MAJOR: breaking API or chart model changes
+- MINOR: new features or chart types
+- PATCH: bug fixes and accessibility improvements
+
+## 8. Runtime Environment
+
+### Modern Browser & Mobile Support
+
+LUNA Charts targets modern web environments.
+
+#### Constraints
+
+- Modern browsers only (Evergreen browsers)
+- Mobile-first compatibility
+- No legacy browser support
+
+#### Rationale
+
+- Enables SVG-first accessibility design
+- Reduces polyfill and compatibility overhead
+- Improves performance and maintainability
+
+## 9. Key Architectural Decisions
+
+- SVG is the only rendering technology (Canvas excluded)
+- TypeScript is used for strict typing and API contracts
+- Framework-neutral core with adapter layers
+- Single-package distribution model
+- No plugin or extension system
+- Multi-layer testing strategy with release gating
+- Containerized, reproducible test execution environment for browser and accessibility tests
+- Open-source distribution via GitHub and npm
+- Modern browser and mobile-first runtime strategy
+
+## 10. Trade-offs
+
+### Advantages
+
+- Strong accessibility guarantees
+- Predictable and deterministic rendering
+- High developer experience (DX)
+- Consistent cross-framework behavior
+- Simplified integration model
+- High quality assurance via release gates
+
+### Limitations
+
+- Limited extensibility for external developers
+- Reduced customization flexibility
+- Strict architectural constraints
+- No plugin ecosystem
+- Higher responsibility on core maintainers
+
+## 11. Change Log
+
+This document reflects a refined Technology Architecture based on iterative architectural decisions across Phase A (Vision), Phase B (Business Architecture), and Phase C (Application Architecture). Key clarifications introduced in this phase:
+
+- SVG confirmed as the only rendering technology due to accessibility requirements
+- Accessibility is treated as a cross-cutting concern supported by type safety, runtime validation, and internal quality assurance (not a standalone engine)
+- Framework neutrality enforced through adapter-based architecture
+- Distribution model defined as a single-package open-source release via npm and GitHub
+- Testing strategy defined as a multi-layer quality gate system (unit, accessibility, linting, visual regression)
+- Runtime scope restricted to modern browsers and mobile-first environments for performance and accessibility alignment
+
+### 2026-07-17 – Containerized test execution documented
+
+**Reason**
+
+Component and browser tests are executed inside a Docker-based Playwright environment (`Dockerfile.test`, `docker-compose.test.yaml`), which was introduced during implementation but had not yet been reflected in this document.
+
+**Changes**
+
+- Added Section 6.6 "Test Execution Environment" describing the containerized Playwright setup used for local development and CI
+- Added "Containerized, reproducible test execution environment" to Section 9 "Key Architectural Decisions"
+
+**Impact**
+
+This clarifies an already-implemented part of the testing strategy (Section 6) and does not change any other architectural decision in this document.
+
+### 2026-08-04 – CI uses a prebuilt test image instead of rebuilding per run
+
+**Reason**
+
+The initial implementation of Section 6.6 assumed CI would build
+`Dockerfile.test` fresh on every run, identical to local execution. In
+practice, this required Docker-in-Docker access inside the CI runner
+purely to build a single-service image — disproportionate operational
+complexity (privileged sidecar container, custom pod networking,
+runner-level configuration) for the orchestration value actually needed,
+since `docker-compose.test.yaml` defines only one service with no
+inter-service dependencies.
+
+**Changes**
+
+- Section 6.6 updated to describe the actual CI flow: `Dockerfile.test` is
+  built and pushed to the registry out-of-band (not on every CI run), and
+  CI jobs pull the prebuilt image, then check out the current commit and
+  install dependencies at runtime
+- Clarified that `Dockerfile.test` remains the single source of truth for
+  the test environment definition; only the build trigger differs between
+  local and CI usage
+
+**Impact**
+
+No other architectural decision in this document is affected. Local
+component testing (`pnpm test:component`) is unchanged.
@@ -1,7 +1,11 @@
-# ADR-0001: Repository Structure
+---
+title: "ADR-0001000: Repository Structure"
+description: "Decision to use a pnpm-based monorepo structure for LUNA Charts."
+---

 * **Status:** Accepted
 * **Date:** 2026-07-12
+* **Last Updated:** 2026-07-17
 * **Decision Makers:** LUNA Charts Maintainers

 ---
@@ -9,11 +13,8 @@
 ## Context

 LUNA Charts is designed as an open-source charting library with a strong focus on accessibility, maintainability, and long-term evolution.
-
 The project consists of multiple concerns, including source code, documentation, examples, testing infrastructure, and continuous integration.
-
 A repository structure was required that supports collaborative development while keeping the project easy to understand for contributors and maintainers.
-
 The repository should also support future growth without requiring structural changes.

 ---
@@ -41,7 +42,6 @@ The following factors influenced this decision:
 | **Monorepo using pnpm Workspaces**   | One repository containing all project artifacts with logical workspace separation. |

 Multiple repositories were rejected because they increase maintenance effort, duplicate tooling, and complicate contribution workflows.
-
 A single repository without workspaces was rejected because the project is expected to grow over time and benefits from a clear modular organization.

 ---
@@ -67,20 +67,23 @@ luna-charts/
 │
 ├── packages/
 │   └── luna-charts/
-│
-├── apps/
-│   ├── storybook/
-│   └── docs/
+│       └── .storybook/
 │
 ├── docs/
-│   ├── architecture/
-│   └── adr/
+│   └── src/content/docs/architecture/
+│       ├── adr/
+│       └── adm/
 │
 ├── examples/
 │
+├── .changeset/
+│
 └── .github/
 ```

+Storybook is not maintained as a separate app but lives directly inside the `packages/luna-charts` package, alongside the component source code it documents.
+The `docs/` workspace is not nested under an `apps/` directory; it is a top-level workspace built with Starlight, with architecture documentation (ADR and ADM) organized under `docs/src/content/docs/architecture/`.
+
 Internally, the library is organized into architectural modules such as:

 * Core
@@ -95,11 +98,8 @@ These modules are implementation details and are **not** exposed as individual n
 ## Rationale

 A monorepo provides a single source of truth for the entire project.
-
 All contributors work within the same repository using a shared toolchain, coding standards, testing infrastructure, and documentation.
-
 Using **pnpm Workspaces** enables clear separation of responsibilities while avoiding duplicated dependencies and configuration.
-
 This structure supports the project's architecture-first approach and simplifies future expansion.

 ---
@@ -140,3 +140,25 @@ This structure supports the project's architecture-first approach and simplifies
 * LUNA Charts Architecture Wiki
 * ADR-0002: Technology Stack
 * pnpm Workspaces Documentation
+
+---
+
+## Change Log
+
+### 2026-07-17 – Repository structure diagram updated (removal of `apps/`)
+
+**Reason**
+
+The originally planned `apps/` workspace (containing `apps/storybook` and `apps/docs`) was never adopted in this form during implementation. Storybook was instead kept inside `packages/luna-charts` alongside the component source it documents, and the documentation workspace (`docs/`) was placed directly at the repository root rather than nested under `apps/`. The repository structure diagram in this ADR no longer matched the actual repository layout, while the Getting Started documentation (`project-structure.mdx`) already reflected the current structure.
+
+**Changes**
+
+* Removed the `apps/` directory (and its `storybook/` and `docs/` subentries) from the structure diagram
+* Corrected the `docs/` path to reflect the actual Starlight content location (`docs/src/content/docs/architecture/`)
+* Added the `adm/` folder to the diagram, alongside `adr/`, since Architecture Development Method documentation is stored there as well
+* Added `.changeset/` to the diagram, as it is a workspace-level configuration directory used for release management
+* Added a note clarifying that Storybook is maintained as part of the `packages/luna-charts` package rather than as a separate app
+
+**Impact**
+
+The overall decision (pnpm-based monorepo with logical workspace separation) is unaffected. Only the illustrative directory layout was corrected to match the implemented structure. No other ADRs are impacted by this change.
@@ -0,0 +1,324 @@
+---
+title: "ADR-0002000: Technology Stack"
+description: "Selection of the technology stack for LUNA Charts based on the TOGAF architectural principles."
+---
+
+* **Status:** Accepted
+* **Date:** 2026-07-12
+* **Last Updated:** 2006-07-17
+* **Decision Makers:** LUNA Charts Maintainers
+
+---
+
+## Context
+
+LUNA Charts is an open-source charting library designed to provide accessible, framework-agnostic, and strongly typed chart components.
+
+The selected technology stack must support the architectural principles defined during the TOGAF Architecture Development Method (ADM), including:
+
+* Accessibility by Design
+* Framework Agnosticism
+* Strong Type Safety
+* Component-Based Architecture
+* High Developer Experience
+* Open Source Collaboration
+* Long-Term Maintainability
+
+Rather than selecting technologies based on popularity, each technology is evaluated according to its ability to support these architectural goals.
+
+---
+
+## Decision Drivers
+
+The following factors influenced the decision:
+
+* Accessibility
+* Framework Agnosticism
+* Type Safety
+* Developer Experience
+* Maintainability
+* Testability
+* Documentation
+* Open Source Collaboration
+* Long-Term Evolution
+
+---
+
+## Considered Alternatives
+
+| Technology Area         | Considered Alternatives                         | Selected           |
+| ------------------------ | ----------------------------------------------- | ------------------ |
+| Component Framework     | React, Vue, Angular, Lit, StencilJS             | **StencilJS**      |
+| Component Documentation | Storybook, Styleguidist                         | **Storybook**      |
+| Project Documentation   | Docusaurus, VitePress, Starlight                | **Starlight**      |
+| Package Manager         | npm, Yarn, pnpm                                 | **pnpm**           |
+| Unit Testing            | Vitest, Jest                                    | **Vitest**         |
+| Browser Testing         | Cypress, Playwright                             | **Playwright**     |
+| Accessibility Testing   | Manual Testing Only, axe-core                   | **axe-core**       |
+| Code Formatting         | Manual Formatting, Prettier                     | **Prettier**       |
+| Static Analysis         | TSLint, ESLint                                  | **ESLint**         |
+| Versioning              | Manual Versioning, Semantic Release, Changesets | **Changesets**     |
+| Continuous Integration  | GitLab CI, Azure Pipelines, GitHub Actions      | **GitHub Actions** |
+
+The selected technologies best support the project's architectural goals while remaining broadly adopted and well documented.
+
+---
+
+## Decision
+
+The following technology stack is adopted for the implementation of LUNA Charts.
+
+| Technology         | Purpose                                             |
+| ------------------- | ---------------------------------------------------- |
+| **StencilJS**      | Web Component development                           |
+| **Storybook**      | Interactive component documentation and development |
+| **Starlight**      | Project and architecture documentation              |
+| **TypeScript**     | Strong typing and developer tooling                 |
+| **pnpm**           | Package management and workspace support            |
+| **Vitest**         | Unit testing and browser/component testing           |
+| **Playwright**     | Browser provider for Vitest browser mode             |
+| **axe-core**       | Accessibility validation                            |
+| **ESLint**         | Static code analysis                                |
+| **Prettier**       | Consistent code formatting                          |
+| **Changesets**     | Versioning and release management                   |
+| **GitHub Actions** | Continuous Integration                              |
+
+The technology stack is considered part of the project's architecture and may only be changed through a new Architecture Decision Record.
+
+---
+
+## Rationale
+
+Each technology has been selected because it directly supports one or more architectural principles.
+
+### StencilJS
+
+StencilJS enables the development of standards-based Web Components.
+
+This aligns with the project's goal of remaining framework agnostic while allowing framework-specific wrappers to be generated automatically during the build process.
+
+---
+
+### Storybook
+
+Storybook provides an isolated environment for component development.
+
+It supports rapid development, interactive examples, accessibility validation, and visual review of chart components.
+
+---
+
+### Starlight
+
+Starlight serves as the central documentation platform.
+
+It separates architectural documentation from component documentation and supports long-term maintainability of the project's knowledge base.
+
+---
+
+### TypeScript
+
+TypeScript enables strong compile-time validation.
+
+It improves the developer experience by detecting integration errors early and providing comprehensive IDE support.
+
+---
+
+### pnpm
+
+pnpm Workspaces enable a modular repository structure while maintaining a single source of truth for dependencies and tooling.
+
+---
+
+### Vitest
+
+Vitest provides fast unit testing for business logic, utility functions, configuration handling, validation, and other non-browser-specific functionality.
+
+Vitest also serves as the single test runner for browser/component tests, using Playwright as its browser provider (`@vitest/browser-playwright`). This avoids maintaining two separate test runners and keeps unit and component testing under one consistent configuration and reporting workflow.
+
+---
+
+### Playwright
+
+Playwright validates component behavior inside real browsers, running as the browser provider within Vitest's browser mode rather than as a standalone test runner.
+
+It is used to verify keyboard interaction, focus management, SVG rendering, and other browser-dependent accessibility features.
+
+---
+
+### axe-core
+
+axe-core automatically validates accessibility requirements and complements manual accessibility reviews.
+
+---
+
+### ESLint and Prettier
+
+Both tools ensure consistent coding standards across the project and reduce friction during code reviews.
+
+---
+
+### Changesets
+
+Changesets manages package versioning and release notes while keeping release decisions under maintainer control.
+
+---
+
+### GitHub Actions
+
+GitHub Actions automates testing, validation, and release workflows to ensure consistent software quality.
+
+---
+
+## Consequences
+
+### Positive
+
+* Technology stack directly supports architectural principles.
+* Strong accessibility support throughout development.
+* Framework-independent component model.
+* Excellent developer experience.
+* Consistent documentation workflow.
+* High maintainability.
+* Modern testing strategy.
+* Simplified contributor onboarding.
+* Automated quality assurance.
+* Scalable project foundation.
+
+### Negative
+
+* Initial project setup is more complex.
+* Contributors must become familiar with multiple development tools.
+* Toolchain maintenance requires periodic updates.
+* CI configuration is more comprehensive than for smaller projects.
+
+---
+
+## Related TOGAF Phases
+
+* Architecture Vision (Phase A)
+* Information Systems Architecture (Phase C)
+* Technology Architecture (Phase D)
+* Opportunities & Solutions (Phase E)
+* Migration Planning (Phase F)
+* Implementation Governance (Phase G)
+
+---
+
+## References
+
+* LUNA Charts Architecture Wiki
+* ADR-0001: Repository Structure
+* ADR-0003: Web Components as Public API
+* StencilJS Documentation
+* Storybook Documentation
+* Starlight Documentation
+* Playwright Documentation
+* Vitest Documentation
+* pnpm Documentation
+
+---
+
+## Change Log
+
+### 2026-07-17 – Unit Testing: Jest replaced with Vitest
+
+**Reason**
+
+During implementation, Jest was replaced with Vitest as the unit testing tool. Stencil's official Vitest integration (`@stencil/vitest`) allows unit tests and browser/component tests to run through a single test runner and configuration file, instead of maintaining Jest for unit tests and a separate Playwright test runner for browser tests. This reduces toolchain complexity and keeps testing configuration consistent across both test types.
+
+**Changes**
+
+* "Considered Alternatives" table: selected Unit Testing technology changed from **Jest** to **Vitest**
+* "Decision" table: **Jest** entry replaced with **Vitest**; **Playwright**'s purpose updated to reflect its role as the browser provider used by Vitest, not a standalone browser test runner
+* "Rationale" section: `Jest` subsection replaced with `Vitest`; `Playwright` subsection clarified to describe it as running inside Vitest's browser mode
+* "References": `Jest Documentation` replaced with `Vitest Documentation`
+
+**Impact**
+
+Playwright remains part of the technology stack, but its architectural role changes from an independent browser test runner to the browser engine used by Vitest. No other decisions in this ADR are affected.
+
+### 2026-08-03 – Continuous Integration: GitHub Actions replaced with Gitea Actions
+
+**Reason**
+
+During implementation, the project moved to a self-hosted Gitea instance
+with Gitea Actions (`act_runner`) instead of GitHub Actions. The ADR's
+"Considered Alternatives" and "Decision" tables still listed GitHub
+Actions, which no longer matched the actual CI/CD tooling in use.
+
+**Changes**
+
+- "Considered Alternatives" table: `Continuous Integration` row updated —
+  considered alternatives changed to *GitHub Actions, GitLab CI, Azure
+  Pipelines, Gitea Actions*; selected technology changed to **Gitea
+  Actions**
+- "Decision" table: **GitHub Actions** entry replaced with **Gitea
+  Actions**
+- "Rationale" section: `GitHub Actions` subsection replaced with `Gitea
+  Actions`, noting that workflows run on a self-hosted `act_runner`
+  (Docker-in-Docker mode) against the project's own Gitea instance
+
+**Impact**
+
+Only the Continuous Integration technology choice is affected. Workflow
+syntax remains GitHub-Actions-compatible (Gitea Actions is designed to be
+largely compatible with the GitHub Actions workflow format), so no other
+architectural decisions in this ADR are impacted.
+
+### 2026-08-04 – Component test CI execution: prebuilt image instead of Docker-in-Docker
+
+**Reason**
+
+Component tests run inside a container built from `Dockerfile.test`
+(based on the official Playwright image). Running this build step inside
+every CI job would require Docker-in-Docker (DinD) access on the
+self-hosted Gitea Actions runner — a privileged sidecar container, custom
+pod networking, and runner-level configuration — solely to build a
+single-service image with no inter-service orchestration need.
+
+**Considered Alternatives**
+
+| Alternative | Description |
+| ----------- | ----------- |
+| Build `Dockerfile.test` fresh on every CI run (DinD) | Mirrors the local `docker compose up --build` flow exactly inside a DinD-enabled CI job. |
+| Replicate `Dockerfile.test`'s steps directly as CI workflow steps, using the public Playwright image | Avoids Docker entirely in CI, but duplicates the test environment definition in two places (`Dockerfile.test` and the workflow YAML), risking drift between local and CI environments. |
+| **Build and push `Dockerfile.test` out-of-band, pull the prebuilt image in CI (selected)** | `Dockerfile.test` remains the only definition of the test environment; the resulting image is built and pushed to the registry separately (tagged by Playwright version), and CI jobs simply pull it and run tests — no Docker access needed at test time. |
+
+Building fresh on every run was rejected due to the disproportionate DinD
+infrastructure complexity for a single-service build. Replicating the
+steps in the workflow file was rejected because it reintroduces a second,
+manually-synchronized source of truth for the test environment.
+
+**Decision**
+
+`Dockerfile.test` is built and pushed to the project's container registry
+out-of-band (not as part of the CI pipeline), tagged by Playwright
+version (e.g. `luna-charts-test:v1.62.1`). The `component-tests` CI job
+pulls this prebuilt image directly, checks out the current commit, and
+runs the test command — no Docker access is required inside the CI job
+container.
+
+**Consequences**
+
+*Positive*
+
+- `Dockerfile.test` remains the single source of truth for the test
+  environment definition
+- No Docker-in-Docker, privileged containers, or custom pod networking
+  required in the CI job itself
+- Faster, simpler `component-tests` job
+
+*Negative*
+
+- The test image must be rebuilt and pushed manually (or via a separate,
+  intentionally-triggered process) whenever `Dockerfile.test` changes;
+  forgetting this step means CI runs against a stale image
+- This is considered an acceptable trade-off given how infrequently
+  `Dockerfile.test` changes, versus the ongoing operational cost of
+  maintaining DinD access in the runner
+
+**Impact**
+
+Local component testing (`pnpm test:component` via Docker Compose) is
+unaffected — it continues to build `Dockerfile.test` fresh via
+`docker-compose.test.yaml`. Only the CI-side image sourcing changes.
@@ -1,4 +1,7 @@
-# ADR-0003: Web Components as Public API
+---
+title: "ADR-0003000: Web Components as Public API"
+description: "Decision to make LUNA Charts' public API available exclusively via Web Components."
+---

 * **Status:** Accepted
 * **Date:** 2026-07-12
@@ -34,7 +37,7 @@ The following factors influenced this decision:
 ## Considered Alternatives

 | Alternative                            | Description                                                       |
-| -------------------------------------- | ----------------------------------------------------------------- |
+| --------------------------------------- | ------------------------------------------------------------------- |
 | React Components                       | Components implemented exclusively for React.                     |
 | Vue Components                         | Components implemented exclusively for Vue.                       |
 | Angular Components                     | Components implemented exclusively for Angular.                   |
@@ -105,6 +108,6 @@ Framework wrappers remain lightweight integration layers and do not introduce ar
 ## References

 * LUNA Charts Architecture Wiki
-* ADR-0002: Technology Stack
+* ADR-0002000: Technology Stack
 * StencilJS Documentation
 * Web Components Specification
@@ -1,4 +1,7 @@
-# ADR-0004: SVG as Rendering Technology
+---
+title: "ADR-000400: SVG as Rendering Technology"
+description: "Decision to use SVG as the rendering technology for all chart visualizations in LUNA Charts."
+---

 * **Status:** Accepted
 * **Date:** 2026-07-12
@@ -38,10 +41,10 @@ The following factors influenced this decision:
 ## Considered Alternatives

 | Alternative      | Description                                               |
-| ---------------- | --------------------------------------------------------- |
+| ----------------- | ------------------------------------------------------------ |
 | HTML Elements    | Represent charts using standard HTML elements.            |
 | Canvas           | Render graphics using the HTML Canvas API.                |
-| Hybrid Rendering | Combine Canvas and SVG depending on the chart type.       |
+| Hybrid Rendering | Combine Canvas and SVG depending on the chart type.        |
 | **SVG**          | Render all chart graphics using Scalable Vector Graphics. |

 HTML was rejected because it is not designed to represent complex graphical visualizations.
@@ -123,7 +126,7 @@ These trade-offs are considered acceptable because accessibility and maintainabi
 ## References

 * LUNA Charts Architecture Wiki
-* ADR-0002: Technology Stack
-* ADR-0003: Web Components as Public API
+* ADR-000200: Technology Stack
+* ADR-000300: Web Components as Public API
 * Scalable Vector Graphics (SVG) Specification
 * Web Content Accessibility Guidelines (WCAG)
@@ -1,4 +1,7 @@
-# ADR-000500: Accessibility as a Cross-Cutting Concern
+---
+title: "ADR-000500: Accessibility as a Cross-Cutting Concern"
+description: "Decision to treat accessibility as a cross-cutting concern across all architectural layers of LUNA Charts."
+---

 * **Status:** Accepted
 * **Date:** 2026-07-12
@@ -40,7 +43,7 @@ The following factors influenced this decision:
 ## Considered Alternatives

 | Alternative                    | Description                                                                                                |
-| ------------------------------ | ---------------------------------------------------------------------------------------------------------- |
+| -------------------------------- | -------------------------------------------------------------------------------------------------------------- |
 | Dedicated Accessibility Engine | A centralized subsystem responsible for accessibility validation and enforcement.                          |
 | Accessibility Utilities        | A collection of reusable accessibility helper functions.                                                   |
 | **Cross-Cutting Concern**      | Accessibility is integrated into every architectural layer where accessibility-related decisions are made. |
@@ -0,0 +1,29 @@
+---
+title: "What are Architecture Decision Records?"
+description: "Overview of the Architecture Decision Records (ADRs) for LUNA Charts."
+---
+
+## What are ADRs?
+
+An **Architecture Decision Record (ADR)** documents an important architectural decision along with its context, the alternatives considered, and the resulting consequences.
+
+Instead of keeping knowledge only in the heads of individual maintainers, every decision is recorded in a traceable way: **why** it was made, **which options** were rejected, and **which trade-offs** were consciously accepted.
+
+## Why do we use ADRs?
+
+* **Traceability** – decisions remain understandable even years later.
+* **Onboarding** – new contributors quickly understand why the project is structured the way it is.
+* **Consistency** – future decisions can reference existing ADRs instead of repeating past discussions.
+* **Governance** – architectural changes happen deliberately, through a new ADR, rather than silently in the code.
+
+## ADRs at LUNA Charts
+
+LUNA Charts is an accessible, framework-agnostic charting library. Architectural decisions follow the phases of the **TOGAF Architecture Development Method (ADM)** and are continuously documented as ADRs – from repository structure to the technology stack to foundational principles such as accessibility.
+
+The following ADRs have been documented so far:
+
+* **ADR-000100** – Repository Structure
+* **ADR-000200** – Technology Stack
+* **ADR-000300** – Web Components as Public API
+* **ADR-000400** – SVG as Rendering Technology
+* **ADR-000500** – Accessibility as a Cross-Cutting Concern
@@ -1,4 +1,7 @@
-# ADR-XXXX: Title
+---
+title: Template for new ADRs
+description: "One-sentence summary of the decision."
+---

 * **Status:** Proposed
 * **Date:** YYYY-MM-DD
@@ -0,0 +1,6 @@
+---
+title: Architecture Dogumentation
+description: Read the Architecture
+---
+
+Welcome to the Architecture dogumentation!
@@ -0,0 +1,41 @@
+---
+title: Why LUNA Charts?
+description: Learn why LUNA Charts exists and what problems it aims to solve.
+sidebar:
+  order: 0
+---
+
+LUNA Charts is an open-source charting library built with a strong focus on **accessibility**, **developer experience**, and **long-term maintainability**.
+
+The project was created because many existing charting libraries provide excellent visualizations, but often treat accessibility, architecture, and maintainability as secondary concerns.
+
+LUNA Charts takes a different approach.
+
+Instead of starting with code, the project started with an **architecture-first process**. The entire foundation—including business goals, technical architecture, governance, and architectural decisions—was designed before implementation began.
+
+## Project Goals
+
+LUNA Charts aims to provide a charting library that is:
+
+- Accessible by default
+- Framework-independent through Web Components
+- Easy to integrate into modern frontend frameworks
+- Well documented for users and contributors
+- Designed for long-term maintainability
+- Governed through transparent architectural decisions
+
+## Current Project Status
+
+The project is currently in the **Groundwork** phase.
+
+At this stage, the architecture, repository structure, development workflow, and governance model are being established before implementing the first chart components.
+
+Although no production-ready charts are available yet, the project documentation already reflects the long-term vision and architectural direction.
+
+## Learn More
+
+If you're interested in the project's design decisions, continue with the following sections:
+
+- **Project Structure**
+- **Architecture**
+- **Architecture Decision Records (ADRs)**
@@ -0,0 +1,88 @@
+---
+title: Project Structure
+description: Overview of the LUNA Charts repository and its organization.
+sidebar:
+  order: 1
+---
+
+LUNA Charts follows a modular repository structure that separates the chart library from its documentation while keeping all project artifacts within a single repository.
+
+```text
+luna-charts/
+│
+├── packages/
+│   └── luna-charts/
+│
+├── docs/
+│
+├── examples/
+│
+├── .github/
+│
+├── package.json
+└── pnpm-workspace.yaml
+```
+
+## packages/
+
+The `packages` directory contains the actual LUNA Charts library.
+
+This package is responsible for:
+
+- Chart components
+- Rendering
+- Public API
+- Build process
+- Testing
+
+As the project evolves, all chart implementations will live here.
+
+---
+
+## docs/
+
+The `docs` directory contains the complete project documentation.
+
+It serves as the **Single Point of Truth (SPOT)** for:
+
+- Architecture documentation
+- Architecture Decision Records (ADRs)
+- Developer guides
+- Project governance
+- User documentation
+
+The documentation is rendered using **Starlight**, but the Markdown content remains the authoritative source.
+
+---
+
+## examples/
+
+Example applications demonstrating how to integrate LUNA Charts with supported frontend frameworks will be added here in future iterations.
+
+Examples may include:
+
+- Vanilla JavaScript
+- React
+- Angular
+- Vue
+
+---
+
+## .github/
+
+Contains project automation such as:
+
+- GitHub Actions
+- Issue templates
+- Pull request templates
+- Community workflows
+
+---
+
+## Monorepo
+
+LUNA Charts is maintained as a **pnpm workspace**.
+
+This structure allows multiple packages and supporting projects to evolve together while sharing a consistent toolchain and development workflow.
+
+As the project grows, additional packages or tooling may be introduced without changing the overall repository organization.
@@ -0,0 +1,92 @@
+---
+title: Roadmap
+description: Current project status and planned evolution of LUNA Charts.
+sidebar:
+  order: 2
+---
+
+LUNA Charts follows an **architecture-first** development approach.
+
+Instead of implementing features immediately, the project establishes a solid architectural and organizational foundation before writing production code. This ensures long-term maintainability, consistent quality, and transparent decision-making.
+
+---
+
+## Current Status
+
+**Current Phase:** Groundwork
+
+The project is currently preparing the technical and organizational foundation for future development.
+
+Completed work includes:
+
+- Repository structure
+- Development workflow
+- Architecture documentation (TOGAF ADM)
+- Architecture Decision Records (ADRs)
+- Project governance
+- Documentation infrastructure
+
+At this stage, no production-ready chart components are available.
+
+---
+
+## Upcoming Milestones
+
+### Foundation
+
+- Create the initial StencilJS library
+- Establish Storybook for component development
+- Configure testing infrastructure
+- Configure CI/CD pipeline
+
+---
+
+### First Proof of Concept
+
+Deliver the first functional chart implementation to validate the technical architecture.
+
+Goals include:
+
+- SVG rendering
+- Accessibility validation
+- Framework integration
+- Community feedback
+
+---
+
+### Minimum Viable Product (MVP)
+
+Provide the first publicly usable version of LUNA Charts.
+
+The MVP focuses on delivering value rather than completeness.
+
+Expected outcomes include:
+
+- Initial chart collection
+- Stable public API
+- Documentation
+- Example applications
+- Accessibility support
+
+---
+
+### Community Growth
+
+After the MVP, the project will gradually expand.
+
+Future work may include:
+
+- Additional chart types
+- Advanced customization
+- Performance improvements
+- Extended framework support
+- Community contributions
+- Governance evolution
+
+---
+
+## Long-Term Vision
+
+LUNA Charts aims to become an accessible, framework-independent charting library that combines modern Web Components with a transparent architecture and a sustainable open-source development model.
+
+Every milestone builds upon the architectural foundation established during the Groundwork phase.
@@ -0,0 +1,33 @@
+---
+title: Welcome to LUNA dogumentation &#128062;
+description: LUNA Charts is a reusable, developer-friendly charting library designed to make accessible, WCAG-oriented data visualization the default rather than an afterthought.
+template: splash # Remove or comment out this line to display the site sidebar on this page.
+hero:
+  tagline: Architecture, ADRs and classes. Everything you should now!
+  image:
+    file: ../../assets/luna_charts_logo_doc.png
+  actions:
+    - text: Start here
+      link: /getting-started/
+      icon: right-arrow
+    - text: Our Git-Repo
+      link: https://git.byting-pandas.ninja/Ninosaurier/LUNA-Charts
+      icon: external
+      variant: minimal
+---
+
+import { Card, CardGrid } from '@astrojs/starlight/components';
+
+## The Topics
+
+<CardGrid stagger>
+	<Card title="Getting started" icon="star">
+		Start reading [getting-started](./getting-started/) and learn how LUNA-Charts is organized.
+	</Card>
+	<Card title="LUNA is using the Architecture Development Method (ADM)" icon="document">
+		Read how LUNA is using the ADM [document](./architecture/adm/).
+	</Card>
+	<Card title="Architecture Decision Records (ADR)" icon="setting">
+		Explore our [ADRs](./architecture/adr/) to understand the reasoning behind our technical decisions.
+	</Card>
+</CardGrid>
@@ -0,0 +1,5 @@
+{
+  "extends": "astro/tsconfigs/strict",
+  "include": [".astro/types.d.ts", "**/*"],
+  "exclude": ["dist"]
+}
@@ -1,8 +1,34 @@
-import js from '@eslint/js';
+// For more info, see https://github.com/storybookjs/eslint-plugin-storybook#configuration-flat-config-format
+import storybook from "eslint-plugin-storybook";
+import js from "@eslint/js";
+import tseslint from "typescript-eslint";

 export default [
-  js.configs.recommended,
  {
-    ignores: ['**/dist/**', '**/www/**', '**/node_modules/**', '**/.stencil/**'],
+    ignores: [
+      "**/dist/**",
+      "**/www/**",
+      "**/node_modules/**",
+      "**/.stencil/**",
+      "**/loader/**",
+    ],
+  },
+
+  js.configs.recommended,
+
+  ...tseslint.configs.recommended,
+
+  ...storybook.configs["flat/recommended"],
+
+  {
+    files: ["**/*.tsx"],
+    rules: {
+      "@typescript-eslint/no-unused-vars": [
+        "error",
+        {
+          varsIgnorePattern: "^h$",
+        },
+      ],
+    },
  },
 ];
@@ -4,12 +4,16 @@
  "description": "",
  "main": "index.js",
  "scripts": {
-    "lint": "eslint .",
+    "docs": "pnpm --filter docs run dev",
+    "lint": "pnpm --filter luna-charts run lint",
    "format": "prettier --write .",
-    "test": "echo \"Error: no test specified\" && exit 1",
+    "format:check": "pnpm --filter luna-charts run format:check",
    "changeset": "changeset",
    "version": "changeset version",
-    "release": "changeset publish"
+    "release": "changeset publish",
+    "test:unit": "pnpm --filter luna-charts test:unit",
+    "test:component": "docker compose -f docker-compose.test.yaml up --build --abort-on-container-exit --exit-code-from test",
+    "test": "pnpm test:unit && pnpm test:component"
  },
  "keywords": [],
  "author": "",
@@ -28,7 +32,11 @@
  "type": "module",
  "devDependencies": {
    "@changesets/cli": "^2.31.0",
+    "@eslint/js": "^10.0.1",
    "eslint": "^10.6.0",
-    "prettier": "^3.9.4"
+    "eslint-config-prettier": "^10.1.8",
+    "eslint-plugin-storybook": "10.5.0",
+    "prettier": "^3.9.4",
+    "typescript-eslint": "^8.65.0"
  }
 }
@@ -24,3 +24,5 @@ $RECYCLE.BIN/
 Thumbs.db
 UserInterfaceState.xcuserstate
 .env
+
+test-results
@@ -0,0 +1,9 @@
+const config = {
+  stories: ['../src/**/*.stories.@(js|jsx|ts|tsx)'],
+  addons: ['@storybook/addon-links', '@storybook/addon-docs'],
+  framework: {
+    name: '@stencil/storybook-plugin',
+  },
+};
+
+export default config;
@@ -0,0 +1,15 @@
+// .storybook/preview.tsx
+import { defineCustomElements } from '../loader/index.js';
+import { setCustomElementsManifest } from '@stencil/storybook-plugin';
+import customElements from '../custom-elements.json';
+
+/**
+ * Registers all custom elements in the Storybook preview.
+ */
+defineCustomElements();
+
+/**
+ * Loads and registers component metadata for Storybook.
+ * This enables automatic generation of props, methods, events, slots, shadow parts, and CSS variables tables.
+ */
+setCustomElementsManifest(customElements);
@@ -0,0 +1,479 @@
+/**
+ * This is an autogenerated file created by the Stencil compiler.
+ * DO NOT MODIFY IT MANUALLY
+ */
+interface ComponentCompilerPropertyComplexType {
+  /**
+   * The string of the original type annotation in the Stencil source code
+   */
+  original: string;
+  /**
+   * A 'resolved' type, where e.g. imported types have been resolved and inlined
+   *
+   * For instance, an annotation like `(foo: Foo) => string;` will be
+   * converted to `(foo: { foo: string }) => string;`.
+   */
+  resolved: string;
+  /**
+   * A record of the types which were referenced in the assorted type
+   * annotation in the original source file.
+   */
+  references: ComponentCompilerTypeReferences;
+}
+type ComponentCompilerTypeReferences = Record<string, ComponentCompilerTypeReference>;
+interface ComponentCompilerTypeReference {
+  /**
+   * A type may be defined:
+   * - locally (in the same file as the component that uses it)
+   * - globally
+   * - by importing it into a file (and is defined elsewhere)
+   */
+  location: 'local' | 'global' | 'import';
+  /**
+   * The path to the type reference, if applicable (global types should not need a path associated with them)
+   */
+  path?: string;
+  /**
+   * An ID for this type which is unique within a Stencil project.
+   */
+  id: string;
+  /**
+   * Whether this type was imported as a default import (e.g., `import MyEnum from './my-enum'`)
+   * vs a named import (e.g., `import { MyType } from './my-type'`)
+   */
+  isDefault?: boolean;
+  /**
+   * The name used in the import statement (before any user-defined alias).
+   * For `import { XAxisOption as moo }`, this would be "XAxisOption".
+   * This is the name exported by the source module.
+   */
+  referenceLocation?: string;
+}
+interface ComponentCompilerReferencedType {
+  /**
+   * The path to the module where the type is declared.
+   */
+  path: string;
+  /**
+   * The string of the original type annotation in the Stencil source code
+   */
+  declaration: string;
+  /**
+   * An extracted docstring
+   */
+  docstring: string;
+}
+interface ComponentCompilerEventComplexType {
+  original: string;
+  resolved: string;
+  references: ComponentCompilerTypeReferences;
+}
+interface ComponentCompilerMethodComplexType {
+  signature: string;
+  parameters: JsonDocMethodParameter[];
+  references: ComponentCompilerTypeReferences;
+  return: string;
+}
+/**
+ * The Type Library holds information about the types which are used in a
+ * Stencil project. During compilation, Stencil gathers information about the
+ * types which form part of a component's public API, such as properties
+ * decorated with `@Prop`, `@Event`, `@Watch`, etc. This type information is
+ * then added to the Type Library, where it can be accessed later on for
+ * generating documentation.
+ *
+ * This information is included in the file written by the `docs-json` output
+ * target (see {@link JsonDocs.typeLibrary}).
+ */
+export type JsonDocsTypeLibrary = Record<string, ComponentCompilerReferencedType>;
+/**
+ * A container for JSDoc metadata for a project
+ */
+export interface JsonDocs {
+  /**
+   * The metadata for the JSDocs for each component in a Stencil project
+   */
+  components: JsonDocsComponent[];
+  /**
+   * The timestamp at which the metadata was generated, in the format YYYY-MM-DDThh:mm:ss
+   */
+  timestamp: string;
+  compiler: {
+    /**
+     * The name of the compiler that generated the metadata
+     */
+    name: string;
+    /**
+     * The version of the Stencil compiler that generated the metadata
+     */
+    version: string;
+    /**
+     * The version of TypeScript that was used to generate the metadata
+     */
+    typescriptVersion: string;
+  };
+  typeLibrary: JsonDocsTypeLibrary;
+}
+/**
+ * Container for JSDoc metadata for a single Stencil component
+ */
+export interface JsonDocsComponent {
+  /**
+   * The directory containing the Stencil component, minus the file name.
+   *
+   * @example /workspaces/stencil-project/src/components/my-component
+   */
+  dirPath?: string;
+  /**
+   * The name of the file containing the Stencil component, with no path
+   *
+   * @example my-component.tsx
+   */
+  fileName?: string;
+  /**
+   * The full path of the file containing the Stencil component
+   *
+   * @example /workspaces/stencil-project/src/components/my-component/my-component.tsx
+   */
+  filePath?: string;
+  /**
+   * The path to the component's `readme.md` file, including the filename
+   *
+   * @example /workspaces/stencil-project/src/components/my-component/readme.md
+   */
+  readmePath?: string;
+  /**
+   * The path to the component's `usage` directory
+   *
+   * @example /workspaces/stencil-project/src/components/my-component/usage/
+   */
+  usagesDir?: string;
+  /**
+   * The encapsulation strategy for a component
+   */
+  encapsulation: 'shadow' | 'scoped' | 'none';
+  /**
+   * The tag name for the component, for use in HTML
+   */
+  tag: string;
+  /**
+   * The contents of a component's `readme.md` that are user generated.
+   *
+   * Auto-generated contents are not stored in this reference.
+   */
+  readme: string;
+  /**
+   * The description of a Stencil component, found in the JSDoc that sits above the component's declaration
+   */
+  docs: string;
+  /**
+   * JSDoc tags found in the JSDoc comment written atop a component's declaration
+   */
+  docsTags: JsonDocsTag[];
+  /**
+   * The text from the class-level JSDoc for a Stencil component, if present.
+   */
+  overview?: string;
+  /**
+   * A mapping of usage example file names to their contents for the component.
+   */
+  usage: JsonDocsUsage;
+  /**
+   * Array of metadata for a component's `@Prop`s
+   */
+  props: JsonDocsProp[];
+  /**
+   * Array of metadata for a component's `@Method`s
+   */
+  methods: JsonDocsMethod[];
+  /**
+   * Array of metadata for a component's `@Event`s
+   */
+  events: JsonDocsEvent[];
+  /**
+   * Array of metadata for a component's `@Listen` handlers
+   */
+  listeners: JsonDocsListener[];
+  /**
+   * Array of metadata for a component's CSS styling information
+   */
+  styles: JsonDocsStyle[];
+  /**
+   * Array of component Slot information, generated from `@slot` tags
+   */
+  slots: JsonDocsSlot[];
+  /**
+   * Array of component Parts information, generate from `@part` tags
+   */
+  parts: JsonDocsPart[];
+  /**
+   * Array of custom states defined via @AttachInternals({ states: {...} })
+   */
+  customStates: JsonDocsCustomState[];
+  /**
+   * Array of metadata describing where the current component is used
+   */
+  dependents: string[];
+  /**
+   * Array of metadata listing the components which are used in current component
+   */
+  dependencies: string[];
+  /**
+   * Describes a tree of components coupling
+   */
+  dependencyGraph: JsonDocsDependencyGraph;
+  /**
+   * A deprecation reason/description found following a `@deprecated` tag
+   */
+  deprecation?: string;
+}
+export interface JsonDocsDependencyGraph {
+  [tagName: string]: string[];
+}
+/**
+ * A descriptor for a single JSDoc tag found in a block comment
+ */
+export interface JsonDocsTag {
+  /**
+   * The tag name (immediately following the '@')
+   */
+  name: string;
+  /**
+   * The description that immediately follows the tag name
+   */
+  text?: string;
+}
+export interface JsonDocsValue {
+  value?: string;
+  type: string;
+}
+/**
+ * A mapping of file names to their contents.
+ *
+ * This type is meant to be used when reading one or more usage markdown files associated with a component. For the
+ * given directory structure:
+ * ```
+ * src/components/my-component
+ * ├── my-component.tsx
+ * └── usage
+ *     ├── bar.md
+ *     └── foo.md
+ * ```
+ * an instance of this type would include the name of the markdown file, mapped to its contents:
+ * ```ts
+ * {
+ *   'bar': STRING_CONTENTS_OF_BAR.MD
+ *   'foo': STRING_CONTENTS_OF_FOO.MD
+ * }
+ * ```
+ */
+export interface JsonDocsUsage {
+  [key: string]: string;
+}
+/**
+ * An intermediate representation of a `@Prop` decorated member's JSDoc
+ */
+export interface JsonDocsProp {
+  /**
+   * the name of the prop
+   */
+  name: string;
+  complexType?: ComponentCompilerPropertyComplexType;
+  /**
+   * the type of the prop, in terms of the TypeScript type system (as opposed to JavaScript's or HTML's)
+   */
+  type: string;
+  /**
+   * `true` if the prop was configured as "mutable" where it was declared, `false` otherwise
+   */
+  mutable: boolean;
+  /**
+   * The name of the attribute that is exposed to configure a compiled web component
+   */
+  attr?: string;
+  /**
+   * `true` if the prop was configured to "reflect" back to HTML where it (the prop) was declared, `false` otherwise
+   */
+  reflectToAttr: boolean;
+  /**
+   * the JSDoc description text associated with the prop
+   */
+  docs: string;
+  /**
+   * JSDoc tags associated with the prop
+   */
+  docsTags: JsonDocsTag[];
+  /**
+   * The default value of the prop
+   */
+  default?: string;
+  /**
+   * Deprecation text associated with the prop. This is the text that immediately follows a `@deprecated` tag
+   */
+  deprecation?: string;
+  values: JsonDocsValue[];
+  /**
+   * `true` if a component is declared with a '?', `false` otherwise
+   *
+   * @example
+   * ```tsx
+   * @Prop() componentProps?: any;
+   * ```
+   */
+  optional: boolean;
+  /**
+   * `true` if a component is declared with a '!', `false` otherwise
+   *
+   * @example
+   * ```tsx
+   * @Prop() componentProps!: any;
+   * ```
+   */
+  required: boolean;
+  /**
+   * `true` if the prop has a `get()`. `false` otherwise
+   */
+  getter: boolean;
+  /**
+   * `true` if the prop has a `set()`. `false` otherwise
+   */
+  setter: boolean;
+}
+export interface JsonDocsMethod {
+  name: string;
+  docs: string;
+  docsTags: JsonDocsTag[];
+  deprecation?: string;
+  signature: string;
+  returns: JsonDocsMethodReturn;
+  parameters: JsonDocMethodParameter[];
+  complexType: ComponentCompilerMethodComplexType;
+}
+export interface JsonDocsMethodReturn {
+  type: string;
+  docs: string;
+}
+export interface JsonDocMethodParameter {
+  name: string;
+  type: string;
+  docs: string;
+}
+export interface JsonDocsEvent {
+  event: string;
+  bubbles: boolean;
+  cancelable: boolean;
+  composed: boolean;
+  complexType: ComponentCompilerEventComplexType;
+  docs: string;
+  docsTags: JsonDocsTag[];
+  deprecation?: string;
+  detail: string;
+}
+/**
+ * Type describing a CSS Style, as described by a JSDoc-style comment
+ */
+export interface JsonDocsStyle {
+  /**
+   * The name of the style
+   */
+  name: string;
+  /**
+   * The type/description associated with the style
+   */
+  docs: string;
+  /**
+   * The annotation used in the JSDoc of the style (e.g. `@prop`)
+   */
+  annotation: string;
+  /**
+   * The mode associated with the style
+   */
+  mode: string | undefined;
+}
+export interface JsonDocsListener {
+  event: string;
+  target?: string;
+  capture: boolean;
+  passive: boolean;
+}
+/**
+ * A descriptor for a slot
+ *
+ * Objects of this type are translated from the JSDoc tag, `@slot`
+ */
+export interface JsonDocsSlot {
+  /**
+   * The name of the slot. Defaults to an empty string for an unnamed slot.
+   */
+  name: string;
+  /**
+   * A textual description of the slot.
+   */
+  docs: string;
+}
+/**
+ * A descriptor of a CSS Shadow Part
+ *
+ * Objects of this type are translated from the JSDoc tag, `@part`, or the 'part'
+ * attribute on a component in TSX
+ */
+export interface JsonDocsPart {
+  /**
+   * The name of the Shadow part
+   */
+  name: string;
+  /**
+   * A textual description of the Shadow part.
+   */
+  docs: string;
+}
+/**
+ * A descriptor for a Custom State defined via @AttachInternals({ states: {...} })
+ *
+ * Custom states are exposed via the ElementInternals.states CustomStateSet
+ * and can be targeted with the CSS `:state()` pseudo-class.
+ *
+ * @see https://developer.mozilla.org/en-US/docs/Web/API/CustomStateSet
+ */
+export interface JsonDocsCustomState {
+  /**
+   * The name of the custom state (without dashes)
+   */
+  name: string;
+  /**
+   * The initial/default value of the state
+   */
+  initialValue: boolean;
+  /**
+   * A textual description of the custom state
+   */
+  docs: string;
+}
+/**
+ * Represents a parsed block comment in a CSS, Sass, etc. file for a custom property.
+ */
+export interface StyleDoc {
+  /**
+   * The name of the CSS property
+   */
+  name: string;
+  /**
+   * The user-defined description of the CSS property
+   */
+  docs: string;
+  /**
+   * The JSDoc-style annotation (e.g. `@prop`) that was used in the block comment to detect the comment.
+   * Used to inform Stencil where the start of a new property's description starts (and where the previous description
+   * ends).
+   */
+  annotation: 'prop';
+  /**
+   * The Stencil style-mode that is associated with this property.
+   */
+  mode: string | undefined;
+}
+
+export {};
+
+declare const _default: JsonDocs;
+export default _default;
@@ -0,0 +1,110 @@
+{
+  "timestamp": "2026-08-01T23:02:04",
+  "compiler": {
+    "name": "@stencil/core",
+    "version": "4.43.5",
+    "typescriptVersion": "5.8.3"
+  },
+  "components": [
+    {
+      "filePath": "src/components/my-component/my-component.tsx",
+      "encapsulation": "shadow",
+      "tag": "my-component",
+      "readme": "# my-component\n\n\n",
+      "docs": "",
+      "docsTags": [],
+      "usage": {},
+      "props": [
+        {
+          "name": "first",
+          "type": "string | undefined",
+          "complexType": {
+            "original": "string",
+            "resolved": "string | undefined",
+            "references": {}
+          },
+          "mutable": false,
+          "attr": "first",
+          "reflectToAttr": false,
+          "docs": "The first name",
+          "docsTags": [],
+          "values": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "undefined"
+            }
+          ],
+          "optional": true,
+          "required": false,
+          "getter": false,
+          "setter": false
+        },
+        {
+          "name": "last",
+          "type": "string | undefined",
+          "complexType": {
+            "original": "string",
+            "resolved": "string | undefined",
+            "references": {}
+          },
+          "mutable": false,
+          "attr": "last",
+          "reflectToAttr": false,
+          "docs": "The last name",
+          "docsTags": [],
+          "values": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "undefined"
+            }
+          ],
+          "optional": true,
+          "required": false,
+          "getter": false,
+          "setter": false
+        },
+        {
+          "name": "middle",
+          "type": "string | undefined",
+          "complexType": {
+            "original": "string",
+            "resolved": "string | undefined",
+            "references": {}
+          },
+          "mutable": false,
+          "attr": "middle",
+          "reflectToAttr": false,
+          "docs": "The middle name",
+          "docsTags": [],
+          "values": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "undefined"
+            }
+          ],
+          "optional": true,
+          "required": false,
+          "getter": false,
+          "setter": false
+        }
+      ],
+      "methods": [],
+      "events": [],
+      "listeners": [],
+      "styles": [],
+      "slots": [],
+      "parts": [],
+      "states": [],
+      "dependents": [],
+      "dependencies": [],
+      "dependencyGraph": {}
+    }
+  ],
+  "typeLibrary": {}
+}
@@ -18,9 +18,9 @@
      "types": "./dist/components/my-component.d.ts"
    },
    "./loader": {
+      "types": "./loader/index.d.ts",
      "import": "./loader/index.js",
-      "require": "./loader/index.cjs",
-      "types": "./loader/index.d.ts"
+      "require": "./loader/index.cjs"
    }
  },
  "repository": {
@@ -32,18 +32,32 @@
    "loader/"
  ],
  "scripts": {
+    "lint": "eslint .",
+    "format:check": "prettier --check .",
+    "format": "prettier --write .",
    "build": "stencil build",
    "start": "stencil build --dev --watch --serve",
    "test": "stencil-test --prod",
+    "test:unit": "stencil-test --prod --project=unit",
+    "test:browser": "stencil-test --prod --project=browser",
    "test:watch": "stencil-test --prod --watch",
-    "generate": "stencil generate"
+    "generate": "stencil generate",
+    "storybook": "storybook dev -p 6006 --no-open"
  },
  "devDependencies": {
-    "@stencil/core": "^4.27.1 || ^5.0.0-0",
+    "@oxc-parser/binding-linux-x64-gnu": "^0.141.0",
+    "@rolldown/binding-linux-x64-gnu": "^1.2.0",
+    "@stencil/core": "^4.43.5",
+    "@stencil/storybook-plugin": "^0.7.0",
    "@stencil/vitest": "^1.8.3",
+    "@storybook/addon-docs": "^10.5.0",
+    "@storybook/addon-links": "^10.5.0",
    "@types/node": "^22.13.5",
    "@vitest/browser-playwright": "^4.0.0",
-    "playwright": "^1.52.0",
+    "axe-core": "^4.12.1",
+    "eslint-plugin-storybook": "10.5.0",
+    "playwright": "^1.62.1",
+    "storybook": "^10.5.0",
    "vitest": "^4.0.0"
  },
  "license": "MIT"
@@ -95,11 +95,7 @@ function App() {
  return (
    <>
      <div>
-        <my-component
-          first="Stencil"
-          middle="'Don't call me a framework'"
-          last="JS"
-        ></my-component>
+        <my-component first="Stencil" middle="'Don't call me a framework'" last="JS"></my-component>
      </div>
    </>
  );
@@ -1,68 +1,68 @@
-/* eslint-disable */
 /* tslint:disable */
 /**
 * This is an autogenerated file created by the Stencil compiler.
 * It contains typing information for all components that exist in this project.
 */
-import { HTMLStencilElement, JSXBase } from "@stencil/core/internal";
+import { HTMLStencilElement, JSXBase } from '@stencil/core/internal';
 export namespace Components {
-    interface MyComponent {
-        /**
-          * The first name
-         */
-        "first"?: string;
-        /**
-          * The last name
-         */
-        "last"?: string;
-        /**
-          * The middle name
-         */
-        "middle"?: string;
-    }
+  interface MyComponent {
+    /**
+     * The first name
+     */
+    first?: string;
+    /**
+     * The last name
+     */
+    last?: string;
+    /**
+     * The middle name
+     */
+    middle?: string;
+  }
 }
 declare global {
-    interface HTMLMyComponentElement extends Components.MyComponent, HTMLStencilElement {
-    }
-    var HTMLMyComponentElement: {
-        prototype: HTMLMyComponentElement;
-        new (): HTMLMyComponentElement;
-    };
-    interface HTMLElementTagNameMap {
-        "my-component": HTMLMyComponentElement;
-    }
+  interface HTMLMyComponentElement extends Components.MyComponent, HTMLStencilElement {}
+  var HTMLMyComponentElement: {
+    prototype: HTMLMyComponentElement;
+    new (): HTMLMyComponentElement;
+  };
+  interface HTMLElementTagNameMap {
+    'my-component': HTMLMyComponentElement;
+  }
 }
 declare namespace LocalJSX {
-    interface MyComponent {
-        /**
-          * The first name
-         */
-        "first"?: string;
-        /**
-          * The last name
-         */
-        "last"?: string;
-        /**
-          * The middle name
-         */
-        "middle"?: string;
-    }
+  interface MyComponent {
+    /**
+     * The first name
+     */
+    first?: string;
+    /**
+     * The last name
+     */
+    last?: string;
+    /**
+     * The middle name
+     */
+    middle?: string;
+  }

-    interface MyComponentAttributes {
-        "first": string;
-        "middle": string;
-        "last": string;
-    }
+  interface MyComponentAttributes {
+    first: string;
+    middle: string;
+    last: string;
+  }

-    interface IntrinsicElements {
-        "my-component": Omit<MyComponent, keyof MyComponentAttributes> & { [K in keyof MyComponent & keyof MyComponentAttributes]?: MyComponent[K] } & { [K in keyof MyComponent & keyof MyComponentAttributes as `attr:${K}`]?: MyComponentAttributes[K] } & { [K in keyof MyComponent & keyof MyComponentAttributes as `prop:${K}`]?: MyComponent[K] };
-    }
+  interface IntrinsicElements {
+    'my-component': Omit<MyComponent, keyof MyComponentAttributes> & { [K in keyof MyComponent & keyof MyComponentAttributes]?: MyComponent[K] } & {
+      [K in keyof MyComponent & keyof MyComponentAttributes as `attr:${K}`]?: MyComponentAttributes[K];
+    } & { [K in keyof MyComponent & keyof MyComponentAttributes as `prop:${K}`]?: MyComponent[K] };
+  }
 }
 export { LocalJSX as JSX };
-declare module "@stencil/core" {
-    export namespace JSX {
-        interface IntrinsicElements {
-            "my-component": LocalJSX.IntrinsicElements["my-component"] & JSXBase.HTMLAttributes<HTMLMyComponentElement>;
-        }
+declare module '@stencil/core' {
+  export namespace JSX {
+    interface IntrinsicElements {
+      'my-component': LocalJSX.IntrinsicElements['my-component'] & JSXBase.HTMLAttributes<HTMLMyComponentElement>;
    }
+  }
 }
@@ -1,4 +1,5 @@
 import { render, h, describe, it, expect } from '@stencil/vitest';
+import { runA11yChecks } from '../../testing/a11y';

 describe('my-component', () => {
  it('renders', async () => {
@@ -14,10 +15,15 @@ describe('my-component', () => {
    `);
  });

+  it('has no accessibility violations', async () => {
+    const { root } = await render(<my-component></my-component>);
+
+    const results = await runA11yChecks(root);
+    expect(results).toHaveNoA11yViolations();
+  });
+
  it('renders with values', async () => {
-    const { root } = await render(
-      <my-component first="Stencil" middle="'Don't call me a framework'" last="JS"></my-component>,
-    );
+    const { root } = await render(<my-component first="Stencil" middle="'Don't call me a framework'" last="JS"></my-component>);
    await expect(root).toEqualHtml(`
      <my-component class="hydrated">
        <mock:shadow-root>
@@ -0,0 +1,41 @@
+import type { Meta, StoryObj } from '@stencil/storybook-plugin';
+import { h } from '@stencil/core';
+import { MyComponent } from './my-component';
+
+const meta: Meta<MyComponent> = {
+  title: 'MyComponent',
+  component: MyComponent,
+  parameters: {
+    layout: 'centered',
+  },
+  argTypes: {
+    first: { control: 'text' },
+    last: { control: 'text' },
+    middle: { control: 'text' },
+  },
+  args: { first: 'John', last: 'Doe', middle: 'Michael' },
+};
+
+export default meta;
+
+type Story = StoryObj<MyComponent>;
+
+export const Primary: Story = {
+  args: {
+    first: 'John',
+    last: 'Doe',
+    middle: 'Michael',
+  },
+  render: props => <my-component {...props} />,
+};
+
+/**
+ * Storybook story without custom render function
+ */
+export const Secondary: Story = {
+  args: {
+    first: 'Jane',
+    last: 'Smith',
+    middle: 'Marie',
+  },
+};
@@ -1,19 +1,15 @@
 # my-component

-
-
 <!-- Auto Generated Below -->

-
 ## Properties

-| Property | Attribute | Description     | Type     | Default     |
-| -------- | --------- | --------------- | -------- | ----------- |
-| `first`  | `first`   | The first name  | `string` | `undefined` |
-| `last`   | `last`    | The last name   | `string` | `undefined` |
-| `middle` | `middle`  | The middle name | `string` | `undefined` |
+| Property | Attribute | Description     | Type                  | Default     |
+| -------- | --------- | --------------- | --------------------- | ----------- |
+| `first`  | `first`   | The first name  | `string \| undefined` | `undefined` |
+| `last`   | `last`    | The last name   | `string \| undefined` | `undefined` |
+| `middle` | `middle`  | The middle name | `string \| undefined` | `undefined` |

+---

----------------------------------------------
-
-*Built with [StencilJS](https://stenciljs.com/)*
+_Built with [StencilJS](https://stenciljs.com/)_
@@ -1,4 +1,4 @@
-<!DOCTYPE html>
+<!doctype html>
 <html dir="ltr" lang="en">
  <head>
    <meta charset="utf-8" />
@@ -0,0 +1,21 @@
+import axe from 'axe-core';
+import type { A11yChecker, A11yCheckResult } from './types';
+
+export const axeCoreChecker: A11yChecker = {
+  name: 'axe-core',
+
+  async run(rootElement: Element): Promise<A11yCheckResult> {
+    const results = await axe.run(rootElement);
+
+    return {
+      checkerName: 'axe-core',
+      violations: results.violations.map(violations => ({
+        id: violations.id,
+        impact: violations.impact ?? null,
+        description: violations.help,
+        helpUrl: violations.helpUrl,
+        nodes: violations.nodes.map(node => node.target.join(' ')),
+      })),
+    };
+  },
+};
@@ -0,0 +1,17 @@
+export interface A11yViolation {
+  id: string;
+  impact: 'minor' | 'moderate' | 'serious' | 'critical' | null;
+  description: string;
+  helpUrl?: string;
+  nodes: string[];
+}
+
+export interface A11yCheckResult {
+  checkerName: string;
+  violations: A11yViolation[];
+}
+
+export interface A11yChecker {
+  name: string;
+  run(root: Element): Promise<A11yCheckResult>;
+}
@@ -0,0 +1,10 @@
+import type { A11yChecker, A11yCheckResult } from './checkers/types';
+import { axeCoreChecker } from './checkers/axe-core.checker';
+
+const a11yCheckerRegistry: A11yChecker[] = [axeCoreChecker];
+
+export async function runA11yChecks(rootElement: Element): Promise<A11yCheckResult[]> {
+  return Promise.all(a11yCheckerRegistry.map(a11yChecker => a11yChecker.run(rootElement)));
+}
+
+export type { A11yChecker, A11yCheckResult, A11yViolation } from './checkers/types';
@@ -0,0 +1,34 @@
+import { expect } from 'vitest';
+import type { A11yCheckResult } from './checkers/types';
+
+expect.extend({
+  toHaveNoA11yViolations(results: A11yCheckResult[]) {
+    const failing = results.filter(results => results.violations.length > 0);
+
+    if (failing.length === 0) {
+      return {
+        pass: true,
+        message: () => 'expected accessibility violations, but none were found',
+      };
+    }
+
+    const message = failing
+      .map(
+        results =>
+          `[${results.checkerName}] ${results.violations.length} violation(s):\n` +
+          results.violations.map(validation => `  - ${validation.id} (${validation.impact}): ${validation.description}\n    affected: ${validation.nodes.join(', ')}`).join('\n'),
+      )
+      .join('\n\n');
+
+    return {
+      pass: false,
+      message: () => `Accessibility violations found:\n\n${message}`,
+    };
+  },
+});
+
+declare module 'vitest' {
+  interface Assertion {
+    toHaveNoA11yViolations(): void;
+  }
+}
@@ -19,5 +19,9 @@ export const config: Config = {
      type: 'www',
      serviceWorker: null, // disable service workers
    },
+    {
+      type: 'docs-json',
+      file: './custom-elements.json',
+    },
  ],
 };
@@ -1,13 +1,11 @@
 {
+  "extends": "../../tsconfig.base.json",
  "compilerOptions": {
    "allowSyntheticDefaultImports": true,
    "allowUnreachableCode": false,
    "declaration": false,
    "experimentalDecorators": true,
-    "lib": [
-      "dom",
-      "es2022"
-    ],
+    "lib": ["dom", "es2022"],
    "moduleResolution": "bundler",
    "module": "esnext",
    "target": "es2022",
@@ -17,14 +15,8 @@
    "jsx": "react",
    "jsxFactory": "h",
    "jsxFragmentFactory": "h.Fragment",
-    "types": [
-      "@stencil/vitest/globals"
-    ]
+    "types": ["@stencil/vitest/globals"]
  },
-  "include": [
-    "src"
-  ],
-  "exclude": [
-    "node_modules"
-  ]
+  "include": ["src"],
+  "exclude": ["node_modules"]
 }
@@ -1,3 +1,4 @@
-import { defineCustomElements } from "./loader";
+import { defineCustomElements } from './loader';
+import './src/testing/a11y/matchers';

 defineCustomElements();
@@ -1,3 +1,21 @@
 packages:
  - "packages/*"
-  - "apps/*"
+  - "docs/"
+
+allowBuilds:
+  esbuild: true
+  sharp: true
+
+onlyBuiltDependencies:
+  - playwright
+
+supportedArchitectures:
+  os:
+    - current
+    - linux
+  cpu:
+    - current
+    - x64
+  libc:
+    - current
+    - glibc
Author	SHA1	Message	Date
Ninosaurier	72c49e6b0f	chore(changeset): prepare v0.1.0 release CI / lint-and-format (push) Successful in 37s Details CI / changeset-check (push) Successful in 25s Details CI / unit-tests (push) Successful in 39s Details CI / component-tests (push) Successful in 30s Details CI / lint-and-format (pull_request) Successful in 32s Details CI / changeset-check (pull_request) Successful in 28s Details CI / unit-tests (pull_request) Successful in 36s Details CI / component-tests (pull_request) Successful in 30s Details	2026-08-05 17:28:41 +02:00
Ninosaurier	9091bdcfae	docs(update): update README to reflect .gitea/ CI setup and test image sourcing CI / lint-and-format (push) Successful in 33s Details CI / changeset-check (push) Successful in 26s Details CI / unit-tests (push) Successful in 36s Details CI / component-tests (push) Successful in 29s Details Adds the .gitea/ directory to the project structure overview and corrects the claim that local and CI test environments are identical. Both are built from the same Dockerfile.test, but locally the image is built on demand while CI pulls a prebuilt version — see ADR-0002 and the Technology Architecture doc for details.	2026-08-05 17:20:41 +02:00
Ninosaurier	2ddf8961c2	docs(update): update README to reflect .gitea/ CI setup and test image sourcing CI / lint-and-format (push) Successful in 34s Details CI / changeset-check (push) Successful in 30s Details CI / unit-tests (push) Successful in 37s Details CI / component-tests (push) Successful in 30s Details Adds the .gitea/ directory to the project structure overview and corrects the claim that local and CI test environments are identical. Both are built from the same Dockerfile.test, but locally the image is built on demand while CI pulls a prebuilt version — see ADR-0002 and the Technology Architecture doc for details.	2026-08-05 17:00:52 +02:00
Ninosaurier	7559a2725a	Merge pull request 'ci(component-tests): add containerized component test workflow' (#14 ) from fix/ci-runner-test-component into dev CI / lint-and-format (push) Successful in 39s Details CI / changeset-check (push) Successful in 29s Details CI / unit-tests (push) Successful in 42s Details CI / component-tests (push) Successful in 32s Details Merge branch 'fix/ci-runner-test-component' into 'dev' ci(component-tests): add containerized component test workflow Reviewed-on: #14	2026-08-04 12:34:04 +00:00
Ninosaurier	caf0f3de2d	ci(component-tests): add containerized component test workflow CI / lint-and-format (push) Successful in 35s Details CI / changeset-check (push) Successful in 28s Details CI / unit-tests (push) Successful in 39s Details CI / component-tests (push) Successful in 29s Details CI / lint-and-format (pull_request) Successful in 36s Details CI / changeset-check (pull_request) Successful in 33s Details CI / unit-tests (pull_request) Successful in 37s Details CI / component-tests (pull_request) Successful in 29s Details Introduce dedicated CI container images and improve the component test execution in Gitea Actions. The workflow now uses reproducible runner environments, private registry authentication and executes Playwright component tests inside a prepared container.	2026-08-03 22:18:14 +02:00
Ninosaurier	856fea304a	chore: scope workspace commands with pnpm filter CI / lint-and-format (push) Successful in 36s Details CI / changeset-check (push) Successful in 32s Details CI / unit-tests (push) Successful in 38s Details CI / component-tests (push) Failing after 28s Details	2026-08-02 15:39:19 +02:00
Ninosaurier	3b9a78bf9d	style: format luna charts source	2026-08-02 15:38:45 +02:00
Ninosaurier	75d4632052	chore: update prettier configuration	2026-08-02 15:38:24 +02:00
Ninosaurier	9089a4ef60	fix(eslint): fix: allow stencil jsx helper in eslint CI / changeset-check (push) Canceled after 0s Details CI / unit-tests (push) Canceled after 0s Details CI / component-tests (push) Canceled after 0s Details CI / lint-and-format (push) Canceled after 4m4s Details	2026-08-02 15:26:15 +02:00
Ninosaurier	88154775de	eslint(error): removed double line	2026-08-02 15:25:53 +02:00
Ninosaurier	5211b5f76a	fix(ci): adjust root lint script to execute eslint directly within project directory	2026-08-02 15:25:31 +02:00
Ninosaurier	b0ae34dbaa	chore(lint): improve monorepo workspace scripts	2026-08-02 15:03:49 +02:00
Ninosaurier	a92d83a5f4	fix(ci): CI / lint-and-format (push) Failing after 34s Details CI / changeset-check (push) Successful in 31s Details CI / unit-tests (push) Successful in 42s Details CI / component-tests (push) Failing after 25s Details trigger workflow on all branch pushes and fix component tests setup	2026-08-02 14:35:50 +02:00
Ninosaurier	35747ec681	ci: trigger workflow on all branch pushes and fix component tests setup - Changed push branch filter to wildcard '*' to test feature branches before merging - Kept the missing pnpm/node setup fix for the component-tests job	2026-08-02 14:33:03 +02:00
Ninosaurier	6d1aeb6ee2	ci: trigger workflow on all branch pushes and fix component tests setup - Changed push branch filter to wildcard '*' to test feature branches before merging - Kept the missing pnpm/node setup fix for the component-tests job	2026-08-02 14:32:24 +02:00
Ninosaurier	768a43d9b6	fix(ci): add missing node and pnpm setup to component tests Every job runs in an isolated container. The component-tests job was missing the Node.js and pnpm installation steps, causing command not found errors (exit code 127) during local execution.	2026-08-02 14:30:05 +02:00
Ninosaurier	75c8300d84	fix(runner): Fixed wrong label. the right label for using the runner is ubuntu-docker-dind CI / lint-and-format (push) Failing after 1m31s Details CI / changeset-check (push) Successful in 29s Details CI / unit-tests (push) Successful in 39s Details CI / component-tests (push) Failing after 5s Details	2026-08-02 14:14:12 +02:00
Ninosaurier	97f99a23ae	fix-lint(lint-violation): Updated readme.md It had a lint-violation CI / lint-and-format (push) Canceled after 0s Details CI / changeset-check (push) Canceled after 0s Details CI / unit-tests (push) Canceled after 0s Details CI / component-tests (push) Canceled after 0s Details	2026-08-02 14:11:38 +02:00
Ninosaurier	dd2874d8b0	feat(ci): add quality gate workflow for dev/main CI / lint-and-format (push) Canceled after 0s Details CI / changeset-check (push) Canceled after 0s Details CI / unit-tests (push) Canceled after 0s Details CI / component-tests (push) Canceled after 0s Details Adds automated checks that were previously only run manually and locally, closing the last remaining gap before dev can be merged into main with confidence. Runs on every push and pull request targeting dev or main: - lint (eslint) - format check (prettier --check) - changeset presence check (non-blocking for now, see comment in workflow file) - unit tests (vitest) - component/browser tests (vitest + playwright, via the existing Docker test setup) Fixes: #10	2026-08-02 02:00:57 +02:00
Ninosaurier	6e13c29141	chore(tooling): add prettier format check script	2026-08-02 01:44:40 +02:00
Ninosaurier	85b1ca240e	fix(deps): pin playwright exactly and respect lockfile in docker build The Playwright version was pinned with a caret range and the test Dockerfile deleted pnpm-lock.yaml before installing, so every image build silently re-resolved to the latest matching Playwright version. This caused the npm package and the Docker base image to drift apart. - packages/luna-charts/package.json: pin playwright to 1.62.1 exactly - Dockerfile.test: stop deleting pnpm-lock.yaml before install, and use --frozen-lockfile so a mismatch between package.json and the lockfile fails the build loudly instead of resolving silently	2026-08-02 01:31:47 +02:00
Ninosaurier	82cfca4215	chore(luna-charts): update generated custom elements metadata	2026-08-02 01:12:57 +02:00
Ninosaurier	c1a1e71240	docs(readme): update readme content	2026-08-02 01:00:25 +02:00
Ninosaurier	2b742e95f1	fix(lint): resolve all outstanding eslint errors	2026-08-02 00:52:27 +02:00
Ninosaurier	a09d83fb53	fix(deps): pin playwright to 1.62.1 and sync docker test image Playwright was previously pinned with a caret range (^1.61.1), which allowed pnpm to silently resolve a newer minor version after the lockfile was regenerated. This caused a version mismatch with the Docker test image, which still referenced 1.61.1. - packages/luna-charts/package.json: pin playwright to 1.62.1 exactly - Dockerfile.test: bump base image to v1.62.1-noble to match	2026-08-02 00:45:30 +02:00
Ninosaurier	575f9202a8	docs(readme): add documentation and storybook start instructions The README was missing instructions for running the documentation site and Storybook locally, so contributors had to guess or dig through package.json scripts to find them. Documents the existing `pnpm run docs` command and the current Storybook workflow, including the known limitation that it must be run from within `packages/luna-charts` until a root-level filter script is set up.	2026-08-02 00:01:04 +02:00
Ninosaurier	bb6009d26c	build(workspace): add root command for documentation development Expose the Astro documentation development server through the root workspace to simplify the local development workflow. Developers can now start the documentation site without changing into the docs directory. Fixes: #12	2026-08-01 23:41:47 +02:00
Ninosaurier	568bc3a98b	textdocs(readme): add repository mirror and issue tracking notice To prevent fragmentation of feedback, we want all bug reports and contributions to be centralized on our main self-hosted platform. GitHub lacks active monitoring for issues, so users need clear direction on where to officially open them.	2026-08-01 23:12:45 +02:00
Ninosaurier	3dc61e5087	build: fix missing native linux bindings for oxc and rolldown Explicitly added @oxc-parser/binding-linux-x64-gnu and @rolldown/binding-linux-x64-gnu as devDependencies. This bypasses issues where pnpm occasionally skips optional native platform bindings during installation, which previously caused CriticalPresetLoadError when loading StencilJS plugins.	2026-07-22 23:50:31 +02:00
Ninosaurier	2991ddf567	Update(docs): add project README and CONTRIBUTING guide Adds a proper project README (description, tech stack, structure, setup, scripts) and a CONTRIBUTING guide (governance summary, workflow, PR expectations), both previously missing or placeholder-only.	2026-07-18 09:38:43 +02:00
Ninosaurier	669baef7d4	Update(docs): document containerized browser test execution Adds the containerized Playwright-based test execution environment (Dockerfile.test, docker-compose.test.yaml) to the Technology Architecture, which was implemented but never documented. - Added Section 6.6 "Test Execution Environment" describing the Docker-based Playwright setup used for local development and CI - Added the containerized test environment to the "Key Architectural Decisions" list - Added a Change Log entry explaining what changed and why	2026-07-17 18:49:35 +02:00
Ninosaurier	c5011073cf	Fix(config): remove stale apps/ references from workspace configs Cleans up leftover configuration from the apps/ → docs/ restructuring (see ADR-0001 update). Neither file had any effect anymore since the apps/ directory no longer exists, but both left stale references that could confuse future contributors. - pnpm-workspace.yaml: removed the unused "apps/*" package glob - .changeset/config.json: removed the "ignore": ["apps/docs"] entry, since docs/ is not tracked as a pnpm workspace package and the entry had no effect	2026-07-17 18:41:10 +02:00
Ninosaurier	2b5ce8a233	Update(docs): align ADR-0001 and ADR-0002 with implemented architecture Corrects two Architecture Decision Records that had drifted from the actual implementation during this sprint. - ADR-0002 (Technology Stack): unit testing now uses Vitest instead of Jest; Playwright's role is clarified as the browser provider used by Vitest's browser mode rather than a standalone test runner. - ADR-0001 (Repository Structure): repository diagram updated to remove the unused apps/ directory, correct the docs/ path to match the actual Starlight content location, and add the previously missing adm/ folder. Both ADRs now include a Change Log section documenting what changed and why, per the Architecture Change Management process (ADM Phase H).	2026-07-17 18:36:11 +02:00
Ninosaurier	9b0758a0eb	Update(docs) Updated ADR 200 Jest is replaced by Vitest. New version of StencilJS use Vitest for unit tests	2026-07-17 18:27:17 +02:00
Ninosaurier	477f2bcc47	feat(a11y-example) Added my-component my-component will remove in the future or moved in example. It is just a preview to see, if the tests run	2026-07-16 15:34:35 +02:00
Ninosaurier	64a6ff6a20	feat(a11y): add extensible accessibility test infrastructure with axe-core" -m "- Add A11yChecker interface (types.ts) as the shared contract for accessibility checkers	2026-07-16 15:33:28 +02:00
Ninosaurier	5564eaf31a	build: add axe-core dependency	2026-07-16 15:23:14 +02:00
Ninosaurier	a10b79b504	test(pnpm and playwright): Playwright run successful in docker container" -m "- Pin Dockerfile.test to mcr.microsoft.com/playwright:v1.52.0-noble to match the playwright npm package version (was mismatched at v1.61.1) - Add supportedArchitectures (linux-x64-gnu) to pnpm-workspace.yaml so native bindings (rolldown, esbuild) are included in the lockfile for the container's platform - Add onlyBuiltDependencies: [playwright] to pnpm-workspace.yaml so build scripts run non-interactively in CI/Docker - Remove stale/redundant pnpm field from package.json (moved to pnpm-workspace.yaml per pnpm v10+ config location) - Split stencil-test into test:unit (native, fast) and test:browser (Docker, cross-browser) scripts - Set ENV CI=true in Dockerfile.test to avoid interactive TTY prompts during pnpm install - Remove anonymous node_modules volumes from docker-compose.test.yaml to prevent stale volume state from surviving image rebuilds - Add root-level test:unit / test:component / test scripts to orchestrate native unit tests and Dockerized cross-browser tests	2026-07-15 16:42:43 +02:00
Ninosaurier	d8d4c7cb69	test(pnpm and playwright): Updated dependencies	2026-07-15 13:57:44 +02:00
Ninosaurier	9821ffe642	test(docker): Added docker container Playwright tests execute in containers, allowing developers to test independently of the operating system.	2026-07-15 13:55:27 +02:00
Ninosaurier	1874c0ea9e	Added .pnpm-store in .gitignore	2026-07-15 13:51:26 +02:00
Ninosaurier	2c2fbd160e	ignore(test): Added new folder After pnpm test, test-results will be created. Does need to push. Added the folder in .gitignore	2026-07-15 12:18:38 +02:00
Ninosaurier	94c12dc90a	fix(docs): Updated Startpage of the documentation	2026-07-15 01:05:21 +02:00
Ninosaurier	8e2131ef12	fix(docs): Added new chapter in the doc Added new chapter "getting-started", so new developers has a start point	2026-07-15 00:48:16 +02:00
Ninosaurier	3d79b545d4	fix(docs): Updated astro.config.mjs AstroJS will show automatically all mdx-files in the folder "getting-started"	2026-07-15 00:47:10 +02:00
Ninosaurier	7fa7211d8e	fix(docs): Migrate the first five ADRs	2026-07-15 00:23:53 +02:00
Ninosaurier	912a53d7df	fix(docs) Migration of the adm-document Added the whole adm-document oft LUNA-Charts in AstroJS	2026-07-15 00:21:16 +02:00
Ninosaurier	c6f83a9a90	fix(docs): Added an adr template Developers can use template for creating new adrs	2026-07-14 19:55:28 +02:00
Ninosaurier	869ea55378	fix(docs): Updated file, to automatically search for MDX files. The MDX files are automatically placed in the ADM and ADR subfolders in the documentation	2026-07-14 19:48:44 +02:00
Ninosaurier	080987ca52	docs(adr): add Starlight frontmatter to ADR template Add required `title`/`description` frontmatter and remove the redundant H1 heading so new ADRs created from this template conform to Starlight's content collection schema by default.	2026-07-14 16:48:26 +02:00
Ninosaurier	3d4c01250d	docs(adr): add ADR overview index page Add an introductory index page explaining what ADRs are, why LUNA Charts uses them, and listing the currently documented decisions.	2026-07-14 16:41:24 +02:00
Ninosaurier	f1339b1d5e	fix(docs): add Starlight frontmatter to ADR-0005 Add required `title`/`description` frontmatter and remove the redundant H1 heading so the file conforms to Starlight's content collection schema.	2026-07-14 16:34:49 +02:00
Ninosaurier	cc446bc683	fix(docs): add Starlight frontmatter to ADR-0004 Add required `title`/`description` frontmatter and remove the redundant H1 heading so the file conforms to Starlight's content collection schema.	2026-07-14 16:32:06 +02:00
Ninosaurier	9ad74eaa79	fix(docs): add Starlight frontmatter to ADR-0003 Add required `title`/`description` frontmatter and remove the redundant H1 heading so the file conforms to Starlight's content collection schema.	2026-07-14 16:30:07 +02:00
Ninosaurier	67e4204365	fix(docs): add Starlight frontmatter to ADR-0002 Add required `title`/`description` frontmatter and remove the redundant H1 heading so the file conforms to Starlight's content collection schema.	2026-07-14 16:26:13 +02:00
Ninosaurier	d8477ee2ac	Convert Markdown file to MDX	2026-07-14 16:25:53 +02:00
Ninosaurier	c46f4c6de7	fix(docs): add Starlight frontmatter to ADR-0001	2026-07-14 16:23:26 +02:00
Ninosaurier	2258e0b159	Added landing page, so other developers know where to start	2026-07-14 16:17:24 +02:00
Ninosaurier	630c1ca1b6	Added start page for topic architecture	2026-07-14 16:14:10 +02:00
Ninosaurier	58c12c4ffb	Added a start page for the ADRs	2026-07-14 16:13:45 +02:00
Ninosaurier	0f30917ce9	Become unnecessary	2026-07-14 16:08:09 +02:00
Ninosaurier	042d9f9252	Moved files in the docs/src/content of Astro JS	2026-07-14 16:07:51 +02:00
Ninosaurier	21cc6560d0	Removed unused files	2026-07-14 16:06:16 +02:00
Ninosaurier	33778acc09	Removed because it is unnecessary	2026-07-14 16:05:56 +02:00
Ninosaurier	e6e7218750	Updated content	2026-07-14 16:05:38 +02:00
Ninosaurier	75c2c12eca	Removed old favicon	2026-07-14 16:05:20 +02:00
Ninosaurier	24d99c887a	Added LUNA-Charts logo	2026-07-14 16:04:31 +02:00
Ninosaurier	0071faa18a	Changed favicon	2026-07-14 16:04:18 +02:00
Ninosaurier	6221e4c2de	Removed unused image	2026-07-14 15:23:23 +02:00
Ninosaurier	db35cc2b97	Created Starlight project	2026-07-14 14:04:21 +02:00
Ninosaurier	c112b44a0e	Moved actually docs in folder docs back. needed to move them away, for creating starlight project	2026-07-14 14:04:03 +02:00
Ninosaurier	e23bd8e721	Removed folder apps, because of new decision. Starlight doc tool will stored in docs folder	2026-07-14 13:58:55 +02:00
Ninosaurier	15b92fa27e	Added storybook with example in thw preview.tsx	2026-07-12 15:44:12 +02:00
Ninosaurier	54255b453a	tsconfig.json extends from tsconfig.base.json	2026-07-12 15:43:41 +02:00
Ninosaurier	193ce2b241	renamed tsconfig.base.yaml to tsconfig.base.json	2026-07-12 15:42:20 +02:00