Merge pull request 'chore(release): prepare v0.1.0 release for main' (#16) from dev into main

Reviewed-on: #16

.changeset/README.md

@@ -0,0 +1,8 @@
+# Changesets
+
+Hello and welcome! This folder has been automatically generated by `@changesets/cli`, a build tool that works
+with multi-package repos, or single-package repos to help you version and publish your code. You can
+find the full documentation for it [in our repository](https://github.com/changesets/changesets).
+
+We have a quick list of common questions to get you started engaging with this project in
+[our documentation](https://github.com/changesets/changesets/blob/main/docs/common-questions.md).

.changeset/config.json

@@ -0,0 +1,11 @@
+{
+  "$schema": "https://unpkg.com/@changesets/config@3.1.4/schema.json",
+  "changelog": "@changesets/cli/changelog",
+  "commit": false,
+  "fixed": [],
+  "linked": [],
+  "access": "restricted",
+  "baseBranch": "dev",
+  "updateInternalDependencies": "patch",
+  "ignore": []
+}

.changeset/ten-rules-bet.md

@@ -0,0 +1,5 @@
+---
+'luna-charts': minor
+---
+
+Establish the initial project foundation with architecture, documentation, governance, and development tooling.

.dockerignore

@@ -0,0 +1,2 @@
+node_modules
+packages/**/node_modules

.gitea/runners/Dockerfile

@@ -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

.gitea/workflows/quality-gate.yml

@@ -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

.github/CODE_OF_CONDUCT.md

@@ -0,0 +1,47 @@
+# Code of Conduct
+
+## Our Pledge
+
+We as contributors and maintainers pledge to make participation in our community a harassment-free experience for everyone.
+
+As this software focuses primarily on **accessibility**, we place great emphasis on ensuring that every person—regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, caste, color, religion, or sexual identity and orientation—can participate equally and without exclusion.
+
+## Our Standards
+
+Examples of behavior that contributes to a positive environment for our community include:
+
+* Demonstrating empathy and kindness toward other people
+* Being respectful of differing opinions, viewpoints, and experiences
+* Giving and gracefully accepting constructive feedback
+* Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience
+* Focusing on what is best not just for us as individuals, but for the larger community
+
+Examples of unacceptable behavior include:
+
+* The use of sexualized language or imagery, and unwelcome sexual attention or advances
+* Trolling, insulting or derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or email address, without their explicit permission
+* Other conduct which could reasonably be considered inappropriate in a professional setting
+
+## Enforcement Responsibilities
+
+Project maintainers are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful.
+
+Maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct.
+
+## Scope
+
+This Code of Conduct applies within all project spaces (e.g., GitHub/GitLab repository), and it also applies in all official community communication channels, including our Discord server. It also applies when an individual is officially representing the community in public spaces.
+
+## Reporting and Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported directly to the project maintainers. Please use the following official communication channel to report an incident:
+
+* **Discord:** [Report an incident / Open a ticket here](https://discord.gg)
+
+All complaints will be reviewed and investigated promptly and fairly. Project maintainers are obligated to respect the privacy and security of the reporter of any incident.
+
+## Attribution
+
+This Code of Conduct is adapted from the Contributor Covenant, version 2.1, available at <https://contributor-covenant.org>.

.gitignore

@@ -0,0 +1,2 @@
+node_modules
+.pnpm-store

.prettierignore

@@ -0,0 +1,4 @@
+dist 
+www 
+node_modules 
+.stencil

.prettierrc.json

@@ -0,0 +1,7 @@
+{
+  "singleQuote": true,
+  "semi": true,
+  "trailingComma": "es5",
+  "printWidth": 100,
+    "bracketSameLine": true
+}

CONTRIBUTING.md

@@ -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.

Dockerfile.test

@@ -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"]

LICENSE

@@ -1,4 +1,5 @@
-GNU LESSER GENERAL PUBLIC LICENSE
+# GNU LESSER GENERAL PUBLIC LICENSE
+
 Version 3, 29 June 2007
 
 Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/>

README.md

@@ -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).

docker-compose.test.yaml

@@ -0,0 +1,6 @@
+services:
+  test:
+    build:
+      context: .
+      dockerfile: Dockerfile.test
+    working_dir: /app/packages/luna-charts

docs/.gitignore

@@ -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

docs/.vscode/extensions.json

@@ -0,0 +1,4 @@
+{
+  "recommendations": ["astro-build.astro-vscode"],
+  "unwantedRecommendations": []
+}

docs/.vscode/launch.json

@@ -0,0 +1,11 @@
+{
+  "version": "0.2.0",
+  "configurations": [
+    {
+      "command": "./node_modules/.bin/astro dev",
+      "name": "Development server",
+      "request": "launch",
+      "type": "node-terminal"
+    }
+  ]
+}

docs/AGENTS.md

@@ -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/)

docs/CLAUDE.md

@@ -0,0 +1 @@
+AGENTS.md

docs/README.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).

docs/astro.config.mjs

@@ -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" } }],
+            },
+          ],
+        },
+      ],
+    }),
+  ],
+});

docs/package.json

@@ -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"
+  }
+}

docs/pnpm-workspace.yaml

@@ -0,0 +1,3 @@
+allowBuilds:
+  esbuild: true
+  sharp: true

docs/src/content.config.ts

@@ -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() }),
+};

docs/src/content/docs/architecture/adm/architecture-change-management.mdx

@@ -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.

docs/src/content/docs/architecture/adm/architecture-vision.mdx

@@ -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

docs/src/content/docs/architecture/adm/business-architecture.mdx

@@ -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)*

docs/src/content/docs/architecture/adm/implementation-governance.mdx

@@ -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)

docs/src/content/docs/architecture/adm/index.mdx

@@ -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.
+
+---

docs/src/content/docs/architecture/adm/information-systems-architecture.mdx

@@ -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)

docs/src/content/docs/architecture/adm/introduction.mdx

@@ -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>

docs/src/content/docs/architecture/adm/migration-planning.mdx

@@ -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)

docs/src/content/docs/architecture/adm/opportunities-and-solutions.mdx

@@ -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.

docs/src/content/docs/architecture/adm/technology-architecture.mdx

@@ -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.

docs/src/content/docs/architecture/adr/000100-repository-structure.mdx

@@ -0,0 +1,164 @@
+---
+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
+
+---
+
+## 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.
+
+---
+
+## Decision Drivers
+
+The following factors influenced this decision:
+
+* Maintainability
+* Developer Experience
+* Open Source Collaboration
+* Modular Architecture
+* Shared Tooling
+* Consistent Build Process
+* Long-Term Evolution
+
+---
+
+## Considered Alternatives
+
+| Alternative                          | Description                                                                        |
+| ------------------------------------ | ---------------------------------------------------------------------------------- |
+| Multiple repositories                | Separate repositories for documentation, examples, and library packages.           |
+| Single repository without workspaces | One repository containing all files without workspace separation.                  |
+| **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.
+
+---
+
+## Decision
+
+LUNA Charts is implemented as a **pnpm-based monorepo**.
+
+The repository contains all project artifacts, including:
+
+* Source code
+* Documentation
+* Storybook
+* Examples
+* Architecture documentation
+* Architecture Decision Records (ADRs)
+* CI/CD configuration
+
+The repository is organized into logical workspaces.
+
+```text
+luna-charts/
+│
+├── packages/
+│   └── luna-charts/
+│       └── .storybook/
+│
+├── docs/
+│   └── 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
+* Charts
+* Themes
+* Utilities
+
+These modules are implementation details and are **not** exposed as individual npm packages.
+
+---
+
+## 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.
+
+---
+
+## Consequences
+
+### Positive
+
+* Single source of truth
+* Simplified onboarding for contributors
+* Shared tooling and configuration
+* Consistent CI/CD pipeline
+* Easier dependency management
+* Centralized documentation
+* Scalable project organization
+
+### Negative
+
+* Larger repository size
+* Contributors clone the complete repository
+* Workspace configuration introduces a small amount of additional complexity
+
+---
+
+## Related TOGAF Phases
+
+* Architecture Vision (Phase A)
+* Technology Architecture (Phase D)
+* Opportunities & Solutions (Phase E)
+* Migration Planning (Phase F)
+* Implementation Governance (Phase G)
+* Architecture Change Management (Phase H)
+
+---
+
+## References
+
+* 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.

docs/src/content/docs/architecture/adr/000200-technology-stack.mdx

@@ -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.

docs/src/content/docs/architecture/adr/000300-web-components-as-public-api.mdx

@@ -0,0 +1,113 @@
+---
+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
+* **Decision Makers:** LUNA Charts Maintainers
+
+---
+
+## Context
+
+LUNA Charts is intended to be an open-source charting library that can be integrated into applications regardless of the frontend framework used.
+
+A primary architectural objective defined during the Architecture Vision and Technology Architecture phases is **framework agnosticism**. Consumers should be able to use LUNA Charts in React, Angular, Vue, Svelte, or plain HTML applications without requiring framework-specific implementations of the chart components.
+
+The public API therefore had to be based on a stable and widely adopted web standard rather than a framework-specific component model.
+
+---
+
+## Decision Drivers
+
+The following factors influenced this decision:
+
+* Framework Agnosticism
+* Standards Compliance
+* Long-Term Maintainability
+* Accessibility
+* Developer Experience
+* Component Reusability
+* Open Web Platform
+* Future Compatibility
+
+---
+
+## 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.                   |
+| Separate implementations per framework | Independent implementations for each supported framework.         |
+| **Web Components**                     | Standards-based custom elements implemented using Web Components. |
+
+Framework-specific implementations were rejected because they increase maintenance effort, duplicate functionality, and couple the architecture to individual frontend ecosystems.
+
+Maintaining multiple implementations would also increase the likelihood of inconsistent behavior across frameworks.
+
+---
+
+## Decision
+
+LUNA Charts exposes its public API exclusively through **Web Components**.
+
+The project uses **StencilJS** to implement these components according to the Web Components standard.
+
+Framework integrations (e.g., React, Angular, Vue) are generated automatically during the build process and are considered **integration adapters**, not independent implementations.
+
+The architecture therefore consists of a single component model with multiple consumption options.
+
+---
+
+## Rationale
+
+Web Components are an open web standard supported by all modern browsers.
+
+By building directly upon this standard, LUNA Charts remains independent of any frontend framework while still supporting popular ecosystems through automatically generated wrappers.
+
+This approach minimizes duplicated implementation effort and guarantees consistent functionality across all supported platforms.
+
+Using a single implementation also simplifies testing, documentation, maintenance, and accessibility validation.
+
+Framework wrappers remain lightweight integration layers and do not introduce architectural differences.
+
+---
+
+## Consequences
+
+### Positive
+
+* Framework-independent public API.
+* Single implementation for all supported platforms.
+* Reduced maintenance effort.
+* Consistent behavior across frameworks.
+* Simplified testing and documentation.
+* Better long-term stability.
+* Supports future frontend frameworks without redesigning the library.
+
+### Negative
+
+* Developers unfamiliar with Web Components may require additional documentation.
+* Framework wrappers depend on the capabilities provided by StencilJS.
+* Some framework-specific features cannot be exposed without breaking framework independence.
+
+---
+
+## Related TOGAF Phases
+
+* Architecture Vision (Phase A)
+* Information Systems Architecture (Phase C)
+* Technology Architecture (Phase D)
+* Opportunities & Solutions (Phase E)
+
+---
+
+## References
+
+* LUNA Charts Architecture Wiki
+* ADR-0002000: Technology Stack
+* StencilJS Documentation
+* Web Components Specification

docs/src/content/docs/architecture/adr/000400-svg-as-rendering-technology.mdx

@@ -0,0 +1,132 @@
+---
+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
+* **Decision Makers:** LUNA Charts Maintainers
+
+---
+
+## Context
+
+One of the primary goals of LUNA Charts is to provide accessible chart components that support modern accessibility standards and assist developers in creating WCAG-compliant data visualizations.
+
+Charts are graphical user interfaces that contain meaningful information. Depending on the chart type, individual graphical elements such as bars, points, labels, legends, and axes may need to be discoverable by assistive technologies, focusable using the keyboard, or interactable by users.
+
+The rendering technology therefore has a direct impact on accessibility, developer experience, testing capabilities, maintainability, and future extensibility.
+
+A rendering technology had to be selected that supports these architectural goals while remaining compatible with modern browsers and Web Components.
+
+---
+
+## Decision Drivers
+
+The following factors influenced this decision:
+
+* Accessibility
+* WCAG Compliance
+* Semantic Structure
+* Keyboard Navigation
+* Focus Management
+* Screen Reader Support
+* Developer Experience
+* Maintainability
+* Browser Compatibility
+* Long-Term Evolution
+
+---
+
+## 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.        |
+| **SVG**          | Render all chart graphics using Scalable Vector Graphics. |
+
+HTML was rejected because it is not designed to represent complex graphical visualizations.
+
+Canvas was rejected because graphical objects are rendered as pixels rather than DOM elements. This makes individual chart elements difficult to expose to assistive technologies and increases implementation complexity for keyboard interaction and accessibility.
+
+Hybrid rendering was rejected because it would introduce two rendering models, increasing architectural complexity, testing effort, and maintenance costs.
+
+---
+
+## Decision
+
+All chart visualizations within LUNA Charts are rendered using **Scalable Vector Graphics (SVG)**.
+
+Each visual element (e.g., bars, lines, points, labels, legends, and axes) is represented as an individual SVG element within the DOM.
+
+Accessibility information, keyboard navigation, focus management, and interaction are implemented directly on these SVG elements.
+
+Canvas is not used as a rendering technology for chart components.
+
+---
+
+## Rationale
+
+SVG integrates directly into the browser's Document Object Model (DOM), allowing every graphical element to be individually identified, styled, focused, and enriched with accessibility information.
+
+This capability aligns with the project's goal of supporting accessible chart implementations by design.
+
+Using SVG enables the library to:
+
+* associate semantic information with graphical elements,
+* support keyboard navigation,
+* expose meaningful structures to assistive technologies,
+* apply standard web accessibility techniques,
+* simplify automated accessibility testing,
+* integrate naturally with Web Components.
+
+SVG also provides excellent scalability across different display resolutions without requiring additional rendering logic.
+
+Although Canvas may provide better rendering performance for extremely large datasets, accessibility and maintainability are considered higher architectural priorities for LUNA Charts.
+
+---
+
+## Consequences
+
+### Positive
+
+* Native DOM representation of graphical elements.
+* Improved accessibility support.
+* Better compatibility with assistive technologies.
+* Simplified keyboard navigation.
+* Simplified focus management.
+* Easier automated accessibility testing.
+* Resolution-independent rendering.
+* Consistent styling using CSS.
+* Better integration with Web Components.
+* Simplified debugging using browser developer tools.
+
+### Negative
+
+* Rendering performance may decrease for extremely large datasets.
+* SVG documents become larger as chart complexity increases.
+* Very large visualizations may require optimization techniques such as virtualization or data aggregation.
+
+These trade-offs are considered acceptable because accessibility and maintainability have higher architectural priority than maximum rendering performance.
+
+---
+
+## Related TOGAF Phases
+
+* Architecture Vision (Phase A)
+* Business Architecture (Phase B)
+* Information Systems Architecture (Phase C)
+* Technology Architecture (Phase D)
+* Opportunities & Solutions (Phase E)
+
+---
+
+## References
+
+* LUNA Charts Architecture Wiki
+* ADR-000200: Technology Stack
+* ADR-000300: Web Components as Public API
+* Scalable Vector Graphics (SVG) Specification
+* Web Content Accessibility Guidelines (WCAG)

docs/src/content/docs/architecture/adr/000500-accessibility-as-a-cross-cutting-concern.mdx

@@ -0,0 +1,142 @@
+---
+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
+* **Decision Makers:** LUNA Charts Maintainers
+
+---
+
+## Context
+
+Accessibility is the primary quality attribute of LUNA Charts.
+
+The project's objective is not only to render charts but also to support developers in creating accessible data visualizations that align with the Web Content Accessibility Guidelines (WCAG).
+
+During the architectural design process, accessibility was initially considered as a separate subsystem responsible for validating and enforcing accessibility requirements.
+
+Further analysis revealed that accessibility affects nearly every architectural layer of the system.
+
+Rendering, component APIs, configuration, validation, interaction, keyboard navigation, documentation, and testing all contribute to the accessibility of the final chart.
+
+As a result, accessibility cannot be implemented as an isolated engine without introducing architectural inconsistencies.
+
+---
+
+## Decision Drivers
+
+The following factors influenced this decision:
+
+* Accessibility by Design
+* WCAG Compliance
+* Separation of Concerns
+* Maintainability
+* Consistency
+* Developer Experience
+* Long-Term Evolution
+* Testability
+
+---
+
+## 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. |
+
+A dedicated accessibility engine was rejected because accessibility cannot be guaranteed after a chart has already been designed or rendered.
+
+Accessibility decisions must be made continuously throughout the rendering process and component lifecycle.
+
+Accessibility utilities remain part of the implementation but do not represent the architectural model.
+
+---
+
+## Decision
+
+Accessibility is treated as a **cross-cutting concern** throughout the entire architecture of LUNA Charts.
+
+Accessibility responsibilities are distributed across multiple architectural modules rather than centralized in a single subsystem.
+
+Examples include:
+
+* Public component APIs
+* TypeScript type definitions
+* Validation
+* Rendering
+* SVG generation
+* Keyboard interaction
+* Focus management
+* Documentation
+* Automated testing
+
+Each architectural component is responsible for implementing the accessibility requirements relevant to its own responsibility.
+
+---
+
+## Rationale
+
+Accessibility is not a feature that can be added after rendering has completed.
+
+Instead, accessibility emerges from many architectural decisions working together.
+
+Examples include:
+
+* selecting SVG instead of Canvas,
+* designing semantic component APIs,
+* exposing accessible keyboard interaction,
+* generating meaningful DOM structures,
+* providing strongly typed configuration,
+* validating accessibility-related configuration,
+* documenting accessibility behavior,
+* verifying accessibility through automated testing.
+
+Treating accessibility as a cross-cutting concern ensures that accessibility remains an architectural responsibility rather than an isolated implementation detail.
+
+This approach also aligns with established software architecture principles, where quality attributes such as security, logging, and observability are commonly treated as cross-cutting concerns.
+
+---
+
+## Consequences
+
+### Positive
+
+* Accessibility is considered throughout the entire development process.
+* Architectural responsibilities remain clearly separated.
+* Accessibility becomes part of every feature rather than an optional extension.
+* Better support for WCAG-compliant chart implementations.
+* Simplified long-term maintenance.
+* Consistent accessibility behavior across all chart types.
+* Accessibility can be validated at multiple architectural levels.
+
+### Negative
+
+* Accessibility responsibilities are distributed across multiple modules.
+* Contributors must understand accessibility requirements beyond their immediate implementation.
+* Architectural reviews must continuously consider accessibility implications.
+
+These trade-offs are acceptable because accessibility represents the primary quality objective of LUNA Charts.
+
+---
+
+## Related TOGAF Phases
+
+* Architecture Vision (Phase A)
+* Business Architecture (Phase B)
+* Information Systems Architecture (Phase C)
+* Technology Architecture (Phase D)
+* Implementation Governance (Phase G)
+
+---
+
+## References
+
+* LUNA Charts Architecture Wiki
+* ADR-000300: Web Components as Public API
+* ADR-000400: SVG as Rendering Technology
+* Web Content Accessibility Guidelines (WCAG)
+* WAI-ARIA Authoring Practices Guide

docs/src/content/docs/architecture/adr/index.mdx

@@ -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

docs/src/content/docs/architecture/adr/template.mdx

@@ -0,0 +1,120 @@
+---
+title: Template for new ADRs
+description: "One-sentence summary of the decision."
+---
+
+* **Status:** Proposed
+* **Date:** YYYY-MM-DD
+* **Decision Makers:** LUNA Charts Maintainers
+
+---
+
+## Context
+
+Describe the background that led to this decision.
+
+Questions that should be answered:
+
+* What problem needs to be solved?
+* Which architectural constraints exist?
+* Which project goals influence the decision?
+* Which stakeholders are affected?
+
+---
+
+## Decision Drivers
+
+List the primary factors that influenced the decision.
+
+Typical examples:
+
+* Accessibility
+* Performance
+* Developer Experience
+* Maintainability
+* Framework Agnosticism
+* Type Safety
+* Simplicity
+* Scalability
+
+---
+
+## Considered Alternatives
+
+Document all relevant alternatives.
+
+| Alternative | Description |
+| ----------- | ----------- |
+| Option A    | Description |
+| Option B    | Description |
+| Option C    | Description |
+
+Briefly explain why the alternatives were not selected.
+
+---
+
+## Decision
+
+Describe the selected solution.
+
+This section should clearly answer:
+
+> What has been decided?
+
+---
+
+## Rationale
+
+Explain why the selected solution best satisfies the decision drivers.
+
+This section should justify the decision from an architectural perspective.
+
+---
+
+## Consequences
+
+### Positive
+
+Describe the expected benefits.
+
+Examples:
+
+* Improved maintainability
+* Better accessibility
+* Easier onboarding
+* Reduced complexity
+
+### Negative
+
+Describe possible drawbacks.
+
+Examples:
+
+* Increased implementation effort
+* Additional maintenance
+* Performance trade-offs
+
+---
+
+## Related TOGAF Phases
+
+List all architecture phases that influenced this decision.
+
+Examples:
+
+* Architecture Vision (Phase A)
+* Technology Architecture (Phase D)
+* Implementation Governance (Phase G)
+
+---
+
+## References
+
+Provide references to related documentation.
+
+Examples:
+
+* Architecture Wiki
+* Other ADRs
+* External standards
+* Specifications

docs/src/content/docs/architecture/index.mdx

@@ -0,0 +1,6 @@
+---
+title: Architecture Dogumentation
+description: Read the Architecture
+---
+
+Welcome to the Architecture dogumentation!

docs/src/content/docs/getting-started/index.mdx

@@ -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)**

docs/src/content/docs/getting-started/project-structure.mdx

@@ -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.

docs/src/content/docs/getting-started/roadmap.mdx

@@ -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.

docs/src/content/docs/index.mdx

@@ -0,0 +1,33 @@
+---
+title: Welcome to LUNA dogumentation 🐾
+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>

docs/tsconfig.json

@@ -0,0 +1,5 @@
+{
+  "extends": "astro/tsconfigs/strict",
+  "include": [".astro/types.d.ts", "**/*"],
+  "exclude": ["dist"]
+}

eslint.config.js

@@ -0,0 +1,34 @@
+// 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 [
+  {
+    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$",
+        },
+      ],
+    },
+  },
+];

package.json

@@ -0,0 +1,42 @@
+{
+  "name": "LUNA-Charts",
+  "version": "1.0.0",
+  "description": "",
+  "main": "index.js",
+  "scripts": {
+    "docs": "pnpm --filter docs run dev",
+    "lint": "pnpm --filter luna-charts run lint",
+    "format": "prettier --write .",
+    "format:check": "pnpm --filter luna-charts run format:check",
+    "changeset": "changeset",
+    "version": "changeset version",
+    "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": "",
+  "license": "ISC",
+  "devEngines": {
+    "runtime": {
+      "name": "node",
+      "version": ">=22.0.0"
+    },
+    "packageManager": {
+      "name": "pnpm",
+      "version": "11.11.0",
+      "onFail": "download"
+    }
+  },
+  "type": "module",
+  "devDependencies": {
+    "@changesets/cli": "^2.31.0",
+    "@eslint/js": "^10.0.1",
+    "eslint": "^10.6.0",
+    "eslint-config-prettier": "^10.1.8",
+    "eslint-plugin-storybook": "10.5.0",
+    "prettier": "^3.9.4",
+    "typescript-eslint": "^8.65.0"
+  }
+}

packages/luna-charts/.editorconfig

@@ -0,0 +1,15 @@
+# http://editorconfig.org
+
+root = true
+
+[*]
+charset = utf-8
+indent_style = space
+indent_size = 2
+end_of_line = lf
+insert_final_newline = true
+trim_trailing_whitespace = true
+
+[*.md]
+insert_final_newline = false
+trim_trailing_whitespace = false

packages/luna-charts/.gitignore

@@ -0,0 +1,28 @@
+dist/
+www/
+loader/
+
+*~
+*.sw[mnpcod]
+*.log
+*.lock
+*.tmp
+*.tmp.*
+log.txt
+*.sublime-project
+*.sublime-workspace
+
+.stencil/
+.idea/
+.vscode/
+.sass-cache/
+.versions/
+node_modules/
+$RECYCLE.BIN/
+
+.DS_Store
+Thumbs.db
+UserInterfaceState.xcuserstate
+.env
+
+test-results

packages/luna-charts/.prettierrc.json

@@ -0,0 +1,13 @@
+{
+  "arrowParens": "avoid",
+  "bracketSpacing": true,
+  "jsxBracketSameLine": false,
+  "jsxSingleQuote": false,
+  "quoteProps": "consistent",
+  "printWidth": 180,
+  "semi": true,
+  "singleQuote": true,
+  "tabWidth": 2,
+  "trailingComma": "all",
+  "useTabs": false
+}

packages/luna-charts/.storybook/main.ts

@@ -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;

packages/luna-charts/.storybook/preview.tsx

@@ -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);

packages/luna-charts/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2024
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

packages/luna-charts/custom-elements.d.ts

@@ -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;

packages/luna-charts/custom-elements.json

@@ -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": {}
+}

packages/luna-charts/package.json

@@ -0,0 +1,64 @@
+{
+  "name": "luna-charts",
+  "version": "0.0.1",
+  "description": "Stencil Component Starter",
+  "main": "dist/index.cjs.js",
+  "module": "dist/index.js",
+  "types": "dist/types/index.d.ts",
+  "collection": "dist/collection/collection-manifest.json",
+  "collection:main": "dist/collection/index.js",
+  "unpkg": "dist/luna-charts/luna-charts.esm.js",
+  "exports": {
+    ".": {
+      "import": "./dist/luna-charts/luna-charts.esm.js",
+      "require": "./dist/luna-charts/luna-charts.cjs.js"
+    },
+    "./my-component": {
+      "import": "./dist/components/my-component.js",
+      "types": "./dist/components/my-component.d.ts"
+    },
+    "./loader": {
+      "types": "./loader/index.d.ts",
+      "import": "./loader/index.js",
+      "require": "./loader/index.cjs"
+    }
+  },
+  "repository": {
+    "type": "git",
+    "url": "https://github.com/stenciljs/component-starter.git"
+  },
+  "files": [
+    "dist/",
+    "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",
+    "storybook": "storybook dev -p 6006 --no-open"
+  },
+  "devDependencies": {
+    "@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",
+    "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"
+}

packages/luna-charts/readme.md

@@ -0,0 +1,107 @@
+[![Built With Stencil](https://img.shields.io/badge/-Built%20With%20Stencil-16161d.svg?logo=data%3Aimage%2Fsvg%2Bxml%3Bbase64%2CPD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiPz4KPCEtLSBHZW5lcmF0b3I6IEFkb2JlIElsbHVzdHJhdG9yIDE5LjIuMSwgU1ZHIEV4cG9ydCBQbHVnLUluIC4gU1ZHIFZlcnNpb246IDYuMDAgQnVpbGQgMCkgIC0tPgo8c3ZnIHZlcnNpb249IjEuMSIgaWQ9IkxheWVyXzEiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyIgeG1sbnM6eGxpbms9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGxpbmsiIHg9IjBweCIgeT0iMHB4IgoJIHZpZXdCb3g9IjAgMCA1MTIgNTEyIiBzdHlsZT0iZW5hYmxlLWJhY2tncm91bmQ6bmV3IDAgMCA1MTIgNTEyOyIgeG1sOnNwYWNlPSJwcmVzZXJ2ZSI%2BCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI%2BCgkuc3Qwe2ZpbGw6I0ZGRkZGRjt9Cjwvc3R5bGU%2BCjxwYXRoIGNsYXNzPSJzdDAiIGQ9Ik00MjQuNywzNzMuOWMwLDM3LjYtNTUuMSw2OC42LTkyLjcsNjguNkgxODAuNGMtMzcuOSwwLTkyLjctMzAuNy05Mi43LTY4LjZ2LTMuNmgzMzYuOVYzNzMuOXoiLz4KPHBhdGggY2xhc3M9InN0MCIgZD0iTTQyNC43LDI5Mi4xSDE4MC40Yy0zNy42LDAtOTIuNy0zMS05Mi43LTY4LjZ2LTMuNkgzMzJjMzcuNiwwLDkyLjcsMzEsOTIuNyw2OC42VjI5Mi4xeiIvPgo8cGF0aCBjbGFzcz0ic3QwIiBkPSJNNDI0LjcsMTQxLjdIODcuN3YtMy42YzAtMzcuNiw1NC44LTY4LjYsOTIuNy02OC42SDMzMmMzNy45LDAsOTIuNywzMC43LDkyLjcsNjguNlYxNDEuN3oiLz4KPC9zdmc%2BCg%3D%3D&colorA=16161d&style=flat-square)](https://stenciljs.com)
+
+# Stencil Component Starter
+
+> This is a starter project for building a standalone Web Components using Stencil.
+
+Stencil is a compiler for building fast web apps using Web Components.
+
+Stencil combines the best concepts of the most popular frontend frameworks into a compile-time rather than runtime tool. Stencil takes TypeScript, JSX, a tiny virtual DOM layer, efficient one-way data binding, an asynchronous rendering pipeline (similar to React Fiber), and lazy-loading out of the box, and generates 100% standards-based Web Components that run in any browser supporting the Custom Elements specification.
+
+Stencil components are just Web Components, so they work in any major framework or with no framework at all.
+
+## Getting Started
+
+To start building a new web component using Stencil, clone this repo to a new directory:
+
+```bash
+git clone https://github.com/stenciljs/component-starter.git my-component
+cd my-component
+git remote rm origin
+```
+
+and run:
+
+```bash
+npm install
+npm start
+```
+
+To build the component for production, run:
+
+```bash
+npm run build
+```
+
+To run the unit tests for the components, run:
+
+```bash
+npm test
+```
+
+Need help? Check out our docs [here](https://stenciljs.com/docs/my-first-component).
+
+## Naming Components
+
+When creating new component tags, we recommend _not_ using `stencil` in the component name (ex: `<stencil-datepicker>`). This is because the generated component has little to nothing to do with Stencil; it's just a web component!
+
+Instead, use a prefix that fits your company or any name for a group of related components. For example, all of the [Ionic-generated](https://ionicframework.com/) web components use the prefix `ion`.
+
+## Using this component
+
+There are two strategies we recommend for using web components built with Stencil.
+
+The first step for all two of these strategies is to [publish to NPM](https://docs.npmjs.com/getting-started/publishing-npm-packages).
+
+You can read more about these different approaches in the [Stencil docs](https://stenciljs.com/docs/publishing).
+
+### Lazy Loading
+
+If your Stencil project is built with the [`dist`](https://stenciljs.com/docs/distribution) output target, you can import a small bootstrap script that registers all components and allows you to load individual component scripts lazily.
+
+For example, given your Stencil project namespace is called `my-design-system`, to use `my-component` on any website, inject this into your HTML:
+
+```html
+<script type="module" src="https://unpkg.com/my-design-system"></script>
+<!--
+To avoid unpkg.com redirects to the actual file, you can also directly import:
+https://unpkg.com/foobar-design-system@0.0.1/dist/foobar-design-system/foobar-design-system.esm.js
+-->
+<my-component first="Stencil" middle="'Don't call me a framework'" last="JS"></my-component>
+```
+
+This will only load the necessary scripts needed to render `<my-component />`. Once more components of this package are used, they will automatically be loaded lazily.
+
+You can also import the script as part of your `node_modules` in your applications entry file:
+
+```tsx
+import 'foobar-design-system/dist/foobar-design-system/foobar-design-system.esm.js';
+```
+
+Check out this [Live Demo](https://stackblitz.com/edit/vitejs-vite-y6v26a?file=src%2Fmain.tsx).
+
+### Standalone
+
+If you are using a Stencil component library with `dist-custom-elements`, we recommend importing Stencil components individually in those files where they are needed.
+
+To export Stencil components as standalone components make sure you have the [`dist-custom-elements`](https://stenciljs.com/docs/custom-elements) output target defined in your `stencil.config.ts`.
+
+For example, given you'd like to use `<my-component />` as part of a React component, you can import the component directly via:
+
+```tsx
+import 'foobar-design-system/my-component';
+
+function App() {
+  return (
+    <>
+      <div>
+        <my-component first="Stencil" middle="'Don't call me a framework'" last="JS"></my-component>
+      </div>
+    </>
+  );
+}
+
+export default App;
+```
+
+Check out this [Live Demo](https://stackblitz.com/edit/vitejs-vite-b6zuds?file=src%2FApp.tsx).

packages/luna-charts/src/components.d.ts

@@ -0,0 +1,68 @@
+/* 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';
+export namespace Components {
+  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;
+  }
+}
+declare namespace LocalJSX {
+  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 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>;
+    }
+  }
+}

packages/luna-charts/src/components/my-component/my-component.cmp.test.tsx

@@ -0,0 +1,37 @@
+import { render, h, describe, it, expect } from '@stencil/vitest';
+import { runA11yChecks } from '../../testing/a11y';
+
+describe('my-component', () => {
+  it('renders', async () => {
+    const { root } = await render(<my-component></my-component>);
+    await expect(root).toEqualHtml(`
+      <my-component class="hydrated">
+        <mock:shadow-root>
+          <div>
+            Hello, World! I'm
+          </div>
+        </mock:shadow-root>
+      </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>);
+    await expect(root).toEqualHtml(`
+      <my-component class="hydrated">
+        <mock:shadow-root>
+          <div>
+            Hello, World! I'm Stencil 'Don't call me a framework' JS
+          </div>
+        </mock:shadow-root>
+      </my-component>
+    `);
+  });
+});

packages/luna-charts/src/components/my-component/my-component.css

@@ -0,0 +1,3 @@
+:host {
+  display: block;
+}

packages/luna-charts/src/components/my-component/my-component.stories.tsx

@@ -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',
+  },
+};

packages/luna-charts/src/components/my-component/my-component.tsx

@@ -0,0 +1,32 @@
+import { Component, Prop, h } from '@stencil/core';
+import { format } from '../../utils/utils';
+
+@Component({
+  tag: 'my-component',
+  styleUrl: 'my-component.css',
+  shadow: true,
+})
+export class MyComponent {
+  /**
+   * The first name
+   */
+  @Prop() first?: string;
+
+  /**
+   * The middle name
+   */
+  @Prop() middle?: string;
+
+  /**
+   * The last name
+   */
+  @Prop() last?: string;
+
+  private getText(): string {
+    return format(this.first, this.middle, this.last);
+  }
+
+  render() {
+    return <div>Hello, World! I'm {this.getText()}</div>;
+  }
+}

packages/luna-charts/src/components/my-component/readme.md

@@ -0,0 +1,15 @@
+# my-component
+
+<!-- Auto Generated Below -->
+
+## Properties
+
+| 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/)_

packages/luna-charts/src/index.html

@@ -0,0 +1,14 @@
+<!doctype html>
+<html dir="ltr" lang="en">
+  <head>
+    <meta charset="utf-8" />
+    <meta name="viewport" content="width=device-width, initial-scale=1.0, minimum-scale=1.0, maximum-scale=5.0" />
+    <title>Stencil Component Starter</title>
+
+    <script type="module" src="/build/luna-charts.esm.js"></script>
+    <script nomodule src="/build/luna-charts.js"></script>
+  </head>
+  <body>
+    <my-component first="Stencil" middle="'Don't call me a framework'" last="JS"></my-component>
+  </body>
+</html>

packages/luna-charts/src/index.ts

@@ -0,0 +1,12 @@
+/**
+ * @fileoverview entry point for your component library
+ *
+ * This is the entry point for your component library. Use this file to export utilities,
+ * constants or data structure that accompany your components.
+ *
+ * DO NOT use this file to export your components. Instead, use the recommended approaches
+ * to consume components of this package as outlined in the `README.md`.
+ */
+
+export { format } from './utils/utils';
+export type * from './components.d.ts';

packages/luna-charts/src/testing/a11y/checkers/axe-core.checker.ts

@@ -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(' ')),
+      })),
+    };
+  },
+};

packages/luna-charts/src/testing/a11y/checkers/types.ts

@@ -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>;
+}

packages/luna-charts/src/testing/a11y/index.ts

@@ -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';

packages/luna-charts/src/testing/a11y/matchers.ts

@@ -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;
+  }
+}

packages/luna-charts/src/utils/utils.ts

@@ -0,0 +1,3 @@
+export function format(first?: string, middle?: string, last?: string): string {
+  return (first || '') + (middle ? ` ${middle}` : '') + (last ? ` ${last}` : '');
+}

packages/luna-charts/src/utils/utils.unit.test.ts

@@ -0,0 +1,20 @@
+import { describe, it, expect } from 'vitest';
+import { format } from './utils';
+
+describe('format', () => {
+  it('returns empty string for no names defined', () => {
+    expect(format(undefined, undefined, undefined)).toEqual('');
+  });
+
+  it('formats just first names', () => {
+    expect(format('Joseph', undefined, undefined)).toEqual('Joseph');
+  });
+
+  it('formats first and last names', () => {
+    expect(format('Joseph', undefined, 'Publique')).toEqual('Joseph Publique');
+  });
+
+  it('formats first, middle and last names', () => {
+    expect(format('Joseph', 'Quincy', 'Publique')).toEqual('Joseph Quincy Publique');
+  });
+});

packages/luna-charts/stencil.config.ts

@@ -0,0 +1,27 @@
+import { Config } from '@stencil/core';
+
+export const config: Config = {
+  namespace: 'luna-charts',
+  outputTargets: [
+    {
+      type: 'dist',
+      esmLoaderPath: '../loader',
+    },
+    {
+      type: 'dist-custom-elements',
+      customElementsExportBehavior: 'auto-define-custom-elements',
+      externalRuntime: false,
+    },
+    {
+      type: 'docs-readme',
+    },
+    {
+      type: 'www',
+      serviceWorker: null, // disable service workers
+    },
+    {
+      type: 'docs-json',
+      file: './custom-elements.json',
+    },
+  ],
+};

packages/luna-charts/tsconfig.json

@@ -0,0 +1,22 @@
+{
+  "extends": "../../tsconfig.base.json",
+  "compilerOptions": {
+    "allowSyntheticDefaultImports": true,
+    "allowUnreachableCode": false,
+    "declaration": false,
+    "experimentalDecorators": true,
+    "lib": ["dom", "es2022"],
+    "moduleResolution": "bundler",
+    "module": "esnext",
+    "target": "es2022",
+    "noUnusedLocals": true,
+    "noUnusedParameters": true,
+    "rootDir": "./",
+    "jsx": "react",
+    "jsxFactory": "h",
+    "jsxFragmentFactory": "h.Fragment",
+    "types": ["@stencil/vitest/globals"]
+  },
+  "include": ["src"],
+  "exclude": ["node_modules"]
+}

packages/luna-charts/vitest-setup.ts

@@ -0,0 +1,4 @@
+import { defineCustomElements } from './loader';
+import './src/testing/a11y/matchers';
+
+defineCustomElements();

packages/luna-charts/vitest.config.ts

@@ -0,0 +1,32 @@
+import { defineVitestConfig } from '@stencil/vitest/config';
+import { playwright } from '@vitest/browser-playwright';
+
+export default defineVitestConfig({
+  stencilConfig: './stencil.config.ts',
+  test: {
+    projects: [
+      // Unit tests - stencil environment for component logic
+      {
+        test: {
+          name: 'unit',
+          include: ['src/**/*.unit.test.{ts,tsx}'],
+          environment: 'stencil',
+        },
+      },
+      // Component browser tests - real browser via Playwright
+      {
+        test: {
+          name: 'browser',
+          include: ['src/**/*.cmp.test.{ts,tsx}'],
+          setupFiles: ['./vitest-setup.ts'],
+          browser: {
+            enabled: true,
+            provider: playwright(),
+            headless: true,
+            instances: [{ browser: 'chromium' }],
+          },
+        },
+      },
+    ],
+  },
+});

pnpm-workspace.yaml

@@ -0,0 +1,21 @@
+packages:
+  - "packages/*"
+  - "docs/"
+
+allowBuilds:
+  esbuild: true
+  sharp: true
+
+onlyBuiltDependencies:
+  - playwright
+
+supportedArchitectures:
+  os:
+    - current
+    - linux
+  cpu:
+    - current
+    - x64
+  libc:
+    - current
+    - glibc

tsconfig.base.json

@@ -0,0 +1,17 @@
+{
+  "compilerOptions": {
+    "target": "ES2022",
+    "module": "ESNext",
+    "moduleResolution": "Bundler",
+    "strict": true,
+    "noImplicitOverride": true,
+    "noUncheckedIndexedAccess": true,
+    "exactOptionalPropertyTypes": true,
+    "declaration": true,
+    "sourceMap": true,
+    "isolatedModules": true,
+    "skipLibCheck": true,
+    "esModuleInterop": true,
+    "forceConsistentCasingInFileNames": true
+  }
+}