chore(doc): Fixed typos

- Fixed some typos
- Updated the roadmap and project structure

.changeset/ten-rules-bet.md

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

.gitea/templates/ISSUE_TEMPLATE.md

@@ -0,0 +1,37 @@
+<!-- markdownlint-disable MD041 -->
+## Goal
+
+<!-- One sentence: what should this issue achieve? -->
+
+## Description
+
+<!-- Context and background: why is this issue necessary?
+     What is the current state, and what is missing or needs to be done? -->
+
+## Steps to Reproduce
+
+<!-- Only relevant for bugs — remove this section for tasks/features.
+     1. Go to '...'
+     2. Click on '...'
+     3. See error -->
+
+## Expected Behaviour
+
+<!-- Only relevant for bugs — what should have happened? -->
+
+## Actual Behaviour
+
+<!-- Only relevant for bugs — what happened instead? -->
+
+## Tasks
+
+- [ ] ...
+- [ ] ...
+- [ ] ...
+- [ ] Update the related parts of the documentation
+
+## Acceptance Criteria
+
+- ...
+- ...
+- ...

.gitea/templates/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,34 @@
+<!-- markdownlint-disable MD041 -->
+## Description
+
+<!-- What does this PR change and why? -->
+
+## Related Issue
+
+<!-- Closes #... / Relates to #... -->
+
+## Type of Change
+
+- [ ] Bug fix
+- [ ] New feature
+- [ ] Refactoring (no functional changes)
+- [ ] Documentation
+- [ ] Tests
+
+## Changes
+
+- ...
+- ...
+- ...
+
+## How Has This Been Tested?
+
+<!-- Describe how you verified your changes (unit tests, manual testing, etc.) -->
+
+## Checklist
+
+- [ ] Code follows the project's style guidelines
+- [ ] Self-review of the code has been performed
+- [ ] Tests have been added/updated and pass locally
+- [ ] Documentation has been updated where necessary
+- [ ] No new warnings or errors introduced

.gitea/workflows/quality-gate.yml

@@ -87,4 +87,4 @@ jobs:
 
       - name: Run component tests (Playwright)
         working-directory: packages/luna-charts
-        run: pnpm test:browser
+        run: pnpm test:browser --passWithNoTests

Dockerfile.test

@@ -18,4 +18,4 @@ WORKDIR /app/packages/luna-charts
 
 RUN pnpm add -D @rolldown/binding-linux-x64-gnu
 
-CMD ["pnpm", "test:browser"]
+CMD ["pnpm", "test:browser", "--", "--passWithNoTests"]

README.md

@@ -2,7 +2,7 @@
 
 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.
+> **Project status:** Working on First Proof of Concept v0.3.0 phase. This milestone focuses on validating the core technical and accessibility assumptions of the library through a first working implementation. The goal is to prove that the chosen architecture (SVG rendering, Web Components, accessibility-first approach) actually works in practice before committing to a broader component set. See the [Roadmap](./docs/src/content/docs/getting-started/roadmap.mdx) for details.
 
 ## Preface & Repository Mirror Notice
 
@@ -17,7 +17,7 @@ Please be aware of our repository structure:
 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
+* **Framework-agnostic** — built as standard Web Components (Stencil), usable in React, Vue or Angular.
 * **SVG-based rendering** — inspectable, stylable, and screen-reader-friendly output instead of an opaque canvas
 
 ## Tech Stack
@@ -59,8 +59,9 @@ luna-charts/
 
 ### Prerequisites
 
-* Node.js `>= 22.0.0`
+* [Node Version manager](https://github.com/nvm-sh/nvm/blob/master/README.md) `0.40.7`
-* pnpm `11.11.0` (see `devEngines` in `package.json`; pnpm will be downloaded automatically via Corepack if missing)
+* Node.js `>= 24.0.0`. Use `nvm install 24` for it
+* pnpm `12.0.0`
 * Docker (required for running component/browser tests locally, see below)
 
 ### Installation
@@ -91,17 +92,7 @@ pnpm install
 | `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) |
-
+| `pnpm run storybook` | Start the storybook documentation |
-### 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).
 

docs/.gitignore

@@ -19,3 +19,6 @@ pnpm-debug.log*
 
 # macOS-specific files
 .DS_Store
+
+# IDE specific files
+.vscode

docs/CHANGELOG.md

@@ -0,0 +1,13 @@
+# docs
+
+## 0.2.0
+
+### Minor Changes
+
+- This release introduces the next iteration of LUNA Charts with improvements to the component architecture, development workflow, testing infrastructure, and documentation.
+
+  - Improved component development and project structure
+  - Enhanced component testing infrastructure
+  - Improved CI/CD test handling, including projects without test files
+  - Updated and extended project documentation
+  - Various improvements and fixes across the library

docs/package.json

@@ -1,7 +1,7 @@
 {
   "name": "docs",
   "type": "module",
-  "version": "0.0.1",
+  "version": "0.2.0",
   "scripts": {
     "dev": "astro dev",
     "start": "astro dev",
@@ -10,8 +10,8 @@
     "astro": "astro"
   },
   "dependencies": {
-    "@astrojs/starlight": "^0.41.3",
+    "@astrojs/starlight": "^0.41.9",
-    "astro": "^7.0.2",
+    "astro": "^7.2.9",
     "sharp": "^0.34.5"
   }
 }

docs/pnpm-workspace.yaml

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

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

@@ -194,4 +194,4 @@ The Business Architecture defines:
   - Strict separation of responsibilities
   - Accessibility as cross-cutting concern
 
-*(Ensures consistency with Phase C decisions)*
+*(Ensures consistency with Phase C _"Information Systems Architecture"_ decisions)*

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

@@ -9,9 +9,12 @@ 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.
+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.
+LUNA Charts is designed as a declarative, component-based charting library with a controlled internal processing pipeline 
+and strict input boundaries.
 
 ## 2. Architectural Style
 
@@ -62,7 +65,7 @@ Developers cannot:
 
 ## 4. System Boundary Model
 
-LUNA Charts exposes a strict system boundary:
+LUNA Charts exposes a strict system boundary.
 
 ### Allowed Inputs
 
@@ -92,15 +95,18 @@ Receives component input, accepts data and configuration, and normalizes incomin
 
 ### 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.
+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.
+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.
+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).
@@ -108,7 +114,8 @@ Applies accessibility rules and guidance mechanisms intended to support WCAG-com
 
 ### 5.5 Rendering Layer
 
-Transforms processed data into visual representations, generates SVG or Canvas output, and produces the final chart visualization.
+Transforms processed data into visual representations, generates SVG or Canvas output, and produces 
+the final chart visualization.
 
 ## 6. Chart Type Model
 
@@ -162,7 +169,8 @@ 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:
+This Application Architecture does not assume a specific frontend framework but is compatible with 
+modern web ecosystems such as:
 
 - React
 - Vue

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

@@ -7,7 +7,9 @@ sidebar:
 
 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.
+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 development start.
 
 ## Documented with the ADM
 

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

@@ -9,9 +9,12 @@ 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.
+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.
+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
 
@@ -145,7 +148,9 @@ LUNA Charts follows a multi-layer quality assurance model.
 - **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.
+  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
@@ -229,7 +234,7 @@ LUNA Charts targets modern web environments.
 - 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
+- Open-source distribution via Gitea and npm
 - Modern browser and mobile-first runtime strategy
 
 ## 10. Trade-offs
@@ -253,10 +258,12 @@ LUNA Charts targets modern web environments.
 
 ## 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:
+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)
+- 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)
@@ -266,16 +273,20 @@ This document reflects a refined Technology Architecture based on iterative arch
 
 **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.
+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 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.
+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
 

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

@@ -1,11 +1,11 @@
 ---
-title: "ADR-0001000: Repository Structure"
+title: "ADR-000100: 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
+* **Last Updated:** 2026-08-31
 * **Decision Makers:** LUNA Charts Maintainers
 
 ---

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

@@ -1,11 +1,11 @@
 ---
-title: "ADR-0002000: Technology Stack"
+title: "ADR-000200: 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
+* **Last Updated:** 2026-07-17
 * **Decision Makers:** LUNA Charts Maintainers
 
 ---
@@ -58,7 +58,7 @@ The following factors influenced the decision:
 | 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** |
+| Continuous Integration  | GitLab CI, Azure Pipelines, Gitea Actions       | **Gitea Actions**  |
 
 The selected technologies best support the project's architectural goals while remaining broadly adopted and well documented.
 

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

@@ -1,5 +1,5 @@
 ---
-title: "ADR-0003000: Web Components as Public API"
+title: "ADR-000300: Web Components as Public API"
 description: "Decision to make LUNA Charts' public API available exclusively via Web Components."
 ---
 

docs/src/content/docs/architecture/adr/000600-declarative-component-api.mdx

@@ -0,0 +1,111 @@
+---
+title: "ADR-000600: Declarative Component API"
+description: "LUNA Charts exposes chart functionality through a strongly typed, component-based declarative API."
+---
+
+* **Status:** Accepted
+* **Date:** 2026-08-31
+* **Decision Makers:** LUNA Charts Maintainers
+
+---
+
+## Context
+
+LUNA Charts must provide a developer-facing API that is easy to understand, strongly typed, framework-agnostic, and capable of enforcing accessibility and validation rules consistently.
+
+Several API models were considered, including a pure domain-specific language (DSL), JSON-based configuration, and a component-based API. The architecture also requires a controlled system boundary so that developers provide chart data and configuration without directly interfering with internal processing.
+
+The Information Systems Architecture defines chart-specific components such as `<BarChart />`, `<LineChart />`, and `<PieChart />`, each with its own strongly typed data model. A single controlled entry point is used for developer interaction, while validation, configuration resolution, accessibility enforcement, and rendering remain under the ownership of the library.
+
+---
+
+## Decision Drivers
+
+* Developer Experience
+* Type Safety
+* Framework Agnosticism
+* Accessibility
+* Maintainability
+* Predictable Behavior
+* Clear System Boundaries
+* Simplicity
+
+---
+
+## Considered Alternatives
+
+| Alternative | Description |
+| ----------- | ----------- |
+| Component-based declarative API | Developers configure charts through strongly typed chart components and their properties. |
+| JSON-based API | Developers provide chart definitions as JSON objects that are interpreted by the library. |
+| Pure DSL | A dedicated textual or configuration language is used to describe charts. |
+| Imperative API | Developers directly invoke rendering and processing operations. |
+
+The component-based declarative API was selected because it provides a natural developer experience, strong TypeScript integration, and a clear boundary between public inputs and internal processing. JSON and pure DSL approaches would require an additional abstraction layer and provide less natural integration with component-based frontend ecosystems. An imperative API would expose more implementation details and weaken the controlled processing model.
+
+---
+
+## Decision
+
+LUNA Charts uses a **component-based declarative API** as its primary developer interaction model.
+
+Developers interact with chart-specific components such as:
+
+* `<BarChart />`
+* `<LineChart />`
+* `<PieChart />`
+
+Each chart component exposes a strongly typed data and configuration model.
+
+The public API is the controlled entry point into the library. Developers provide structured data and configuration, while the internal processing pipeline remains under the control of LUNA Charts.
+
+---
+
+## Rationale
+
+A component-based declarative API aligns the developer experience with modern web component and framework ecosystems while allowing TypeScript to express valid data and configuration structures.
+
+The model also supports LUNA Charts' architectural goals:
+
+* Developers describe the desired chart rather than controlling rendering steps.
+* Type-safe contracts make invalid inputs more explicit.
+* Internal validation and accessibility enforcement remain centrally controlled.
+* The same conceptual API can be consumed through framework-specific integrations.
+* The API remains predictable and maintainable as additional chart types are introduced.
+
+---
+
+## Consequences
+
+### Positive
+
+* Clear and approachable developer API.
+* Strong TypeScript integration and type safety.
+* Declarative usage reduces exposure to internal implementation details.
+* Consistent integration model across supported frontend ecosystems.
+* Internal accessibility and validation rules remain centrally enforceable.
+* New chart types can follow the same API pattern.
+
+### Negative
+
+* Developers have less low-level control over internal processing.
+* Custom behavior outside the defined API requires changes by the LUNA Charts maintainers.
+* Strong API constraints can make unusual use cases harder to support.
+* Each chart type requires a dedicated typed model.
+
+---
+
+## Related TOGAF Phases
+
+* Architecture Vision (Phase A)
+* Business Architecture (Phase B)
+* Information Systems Architecture (Phase C)
+* Technology Architecture (Phase D)
+
+---
+
+## References
+
+* [Information Systems Architecture](../adm/information-systems-architecture/)
+* [Technology Architecture](../adm/technology-architecture/)
+* [ADR-000300 – Web Components as Public API](./000300-web-components-as-public-api/)

docs/src/content/docs/architecture/adr/000700-no-plugin-or-extension-system.mdx

@@ -0,0 +1,102 @@
+---
+title: "ADR-0007000: No Plugin or Extension System"
+description: "LUNA Charts does not provide a consumer-facing plugin or extension mechanism."
+---
+
+* **Status:** Accepted
+* **Date:** 2026-08-31
+* **Decision Makers:** LUNA Charts Maintainers
+
+---
+
+## Context
+
+LUNA Charts is designed as an opinionated charting library with a controlled internal processing pipeline. Accessibility, validation, configuration resolution, and rendering are library-owned responsibilities.
+
+An extension mechanism could allow consumers to modify internal behavior or add functionality without changing the core library. However, unrestricted extensibility could also introduce inconsistent behavior, weaken accessibility guarantees, and increase architectural and maintenance complexity.
+
+The Information Systems Architecture therefore defines LUNA Charts as a closed system with a strict input boundary and no external plugin or extension mechanism.
+
+---
+
+## Decision Drivers
+
+* Accessibility
+* Maintainability
+* Predictable Behavior
+* Simplicity
+* Quality Control
+* Security
+* Developer Experience
+
+---
+
+## Considered Alternatives
+
+| Alternative | Description |
+| ----------- | ----------- |
+| No plugin or extension system | Consumers use only the public API provided by LUNA Charts. |
+| Consumer plugin system | Consumers can register plugins that modify or extend library behavior. |
+| Extension hooks | Consumers can inject custom logic into selected processing stages. |
+| Fully extensible architecture | Internal layers and chart types can be extended directly by consumers. |
+
+The no-plugin approach was selected because the library's accessibility and rendering behavior must remain centrally controlled. Plugin systems and extension hooks would increase the number of execution paths that must be validated and supported.
+
+---
+
+## Decision
+
+LUNA Charts **does not provide a consumer-facing plugin or extension system**.
+
+Consumers interact with the library exclusively through its defined public API. Internal processing stages cannot be replaced, intercepted, or extended by consumers.
+
+New chart types, accessibility behavior, rendering capabilities, and other architectural functionality are implemented and maintained within the LUNA Charts project itself.
+
+---
+
+## Rationale
+
+LUNA Charts is intentionally opinionated. Its value depends not only on providing chart visualizations but also on providing predictable and accessible implementations.
+
+Allowing consumers to modify internal behavior would make it harder to guarantee consistent accessibility and quality. A closed architecture keeps the processing pipeline deterministic and allows maintainers to evolve the implementation under a single quality and accessibility model.
+
+This decision also avoids the additional API surface, compatibility requirements, documentation burden, and support obligations associated with a plugin ecosystem.
+
+---
+
+## Consequences
+
+### Positive
+
+* Centralized control over accessibility behavior.
+* Predictable and deterministic processing.
+* Smaller public API surface.
+* Lower maintenance and compatibility burden.
+* Easier quality assurance and testing.
+* No plugin ecosystem needs to be designed or maintained.
+* Reduced risk that consumer extensions bypass architectural safeguards.
+
+### Negative
+
+* Consumers cannot add custom processing stages.
+* Consumers cannot introduce custom chart types through plugins.
+* Unusual use cases may require changes to LUNA Charts itself.
+* The architecture places more responsibility on the maintainers to evolve the library.
+
+---
+
+## Related TOGAF Phases
+
+* Architecture Vision (Phase A)
+* Business Architecture (Phase B)
+* Information Systems Architecture (Phase C)
+* Technology Architecture (Phase D)
+
+---
+
+## References
+
+* [Business Architecture](../adm/business-architecture/)
+* [Information Systems Architecture](../adm/information-systems-architecture/)
+* [Technology Architecture](../adm/technology-architecture/)
+* [ADR-000500 – Accessibility as a Cross-Cutting Concern](./000500-accessibility-as-a-cross-cutting-concern/)

docs/src/content/docs/architecture/adr/000800-single-package-distribution-model.mdx

@@ -0,0 +1,101 @@
+---
+title: "ADR-000800: Single-Package Distribution Model"
+description: "LUNA Charts is distributed as one unified package rather than separate packages per chart type or internal module."
+---
+
+* **Status:** Accepted
+* **Date:** 2026-08-31
+* **Decision Makers:** LUNA Charts Maintainers
+
+---
+
+## Context
+
+LUNA Charts is developed as a monorepo and contains multiple internal modules and chart types. The repository structure must remain flexible for implementation while the public distribution model should remain simple for consumers.
+
+The architecture distinguishes between internal implementation boundaries and the public package boundary. Chart types such as BarChart, LineChart, and PieChart are not intended to become independent npm packages.
+
+LUNA Charts is intended to be consumed as one coherent, accessibility-focused library.
+
+---
+
+## Decision Drivers
+
+* Developer Experience
+* Simplicity
+* Accessibility
+* Maintainability
+* Consistent API Behavior
+* Framework Agnosticism
+* Release Management
+* Reduced Package Fragmentation
+
+---
+
+## Considered Alternatives
+
+| Alternative | Description |
+| ----------- | ----------- |
+| Single package | All public chart functionality is distributed through one LUNA Charts package. |
+| Package per chart type | Each chart type is published as an independent npm package. |
+| Package per internal module | Internal modules such as core and charts are independently published. |
+| Monorepo with multiple public packages | The repository remains a monorepo while several independently versioned packages are published. |
+
+The single-package model was selected because the library is intended to provide one coherent developer experience and one consistent accessibility model. Publishing chart types or internal modules separately would increase package, versioning, dependency, and compatibility complexity.
+
+---
+
+## Decision
+
+LUNA Charts is distributed as **one unified public npm package**.
+
+Chart types, core functionality, accessibility mechanisms, and other implementation modules remain internal parts of the distribution and are not published as separate public packages.
+
+Framework-specific integrations generated from the Stencil-based implementation are considered part of the overall LUNA Charts distribution model rather than independent chart packages.
+
+---
+
+## Rationale
+
+A single package gives consumers one installation target and one coherent version of the library.
+
+It also supports the project's accessibility-first architecture. Accessibility enforcement, validation, rendering, and chart functionality can evolve together without requiring consumers to coordinate compatible versions of several packages.
+
+The monorepo therefore provides internal organizational and architectural separation without exposing unnecessary package fragmentation to consumers.
+
+---
+
+## Consequences
+
+### Positive
+
+* Simple installation and onboarding.
+* One public version and release lifecycle.
+* Consistent accessibility and API behavior across chart types.
+* No dependency coordination between separate chart packages.
+* Easier documentation and support.
+* Internal modules can evolve without becoming public package contracts.
+
+### Negative
+
+* Consumers cannot install only an individual chart package.
+* The public package may contain functionality that a particular consumer does not use.
+* A change in one part of the library may require a release of the unified package.
+* Package-level boundaries cannot be used to independently version individual chart types.
+
+---
+
+## Related TOGAF Phases
+
+* Architecture Vision (Phase A)
+* Business Architecture (Phase B)
+* Information Systems Architecture (Phase C)
+* Technology Architecture (Phase D)
+
+---
+
+## References
+
+* [Repository Structure](./000100-repository-structure/)
+* [Technology Architecture](../adm/technology-architecture/)
+* [Information Systems Architecture](../adm/information-systems-architecture/)

docs/src/content/docs/architecture/adr/000900-multi-layer-testing-strategy.mdx

@@ -0,0 +1,116 @@
+---
+title: "ADR-000900: Multi-Layer Testing Strategy"
+description: "LUNA Charts uses multiple complementary quality assurance layers with automated release gates."
+---
+
+* **Status:** Accepted
+* **Date:** 2026-08-31
+* **Decision Makers:** LUNA Charts Maintainers
+
+---
+
+## Context
+
+LUNA Charts is an accessibility-focused charting library whose output must be correct, stable, and usable across supported environments.
+
+No single testing technique can adequately validate the library. Functional correctness, accessibility constraints, DOM and SVG structure, visual stability, code quality, and real-world usability require different forms of verification.
+
+The Technology Architecture therefore defines a multi-layer quality assurance model covering functional tests, accessibility tests, linting, visual regression testing, and usability testing. Automated checks are combined with release gating so that defined quality requirements are evaluated before releases.
+
+---
+
+## Decision Drivers
+
+* Accessibility
+* Reliability
+* Visual Stability
+* Maintainability
+* Developer Experience
+* Reproducibility
+* Release Quality
+* Automation
+
+---
+
+## Considered Alternatives
+
+| Alternative | Description |
+| ----------- | ----------- |
+| Multi-layer testing strategy | Multiple complementary test and quality layers are combined into release gates. |
+| Unit tests only | Functional behavior is validated primarily through unit tests. |
+| End-to-end tests only | Browser-based tests are used as the primary validation mechanism. |
+| Manual testing only | Quality is validated through manual verification before releases. |
+
+The multi-layer approach was selected because each alternative alone leaves important quality risks uncovered. Unit tests do not sufficiently validate browser behavior or accessibility, while browser tests alone are less efficient for isolated logic. Manual testing remains valuable for usability but cannot provide sufficient automated regression coverage.
+
+---
+
+## Decision
+
+LUNA Charts uses a **multi-layer testing and quality assurance strategy**.
+
+The strategy includes:
+
+1. **Functional testing** for core logic and processing behavior.
+2. **Accessibility testing** for machine-verifiable accessibility requirements and ARIA structure.
+3. **Code quality checks** including linting and formatting-related quality controls.
+4. **Visual regression testing** to detect unintended visual and structural changes.
+5. **Usability testing** for relevant minor and major releases and significant user-facing changes.
+6. **Release gates** that prevent releases when required automated quality checks fail.
+
+Browser-based tests use a reproducible test execution environment so that local and CI execution can use a controlled environment.
+
+---
+
+## Rationale
+
+LUNA Charts has accessibility and visual output as central quality attributes. These cannot be reliably validated through unit tests alone.
+
+A layered strategy assigns each quality concern to an appropriate verification mechanism:
+
+* Unit tests provide fast feedback for logic.
+* Accessibility tests validate machine-verifiable accessibility constraints.
+* Linting protects code and architectural consistency.
+* Visual regression tests protect rendered output and relevant DOM structure.
+* Usability testing evaluates aspects that cannot be reliably automated.
+* Release gates ensure required automated checks are completed before distribution.
+
+The approach balances fast developer feedback with stronger release confidence.
+
+---
+
+## Consequences
+
+### Positive
+
+* Higher confidence in functional correctness.
+* Accessibility becomes part of the quality process rather than a final manual check.
+* Visual regressions can be detected automatically.
+* Release quality is enforced consistently.
+* Different test types can remain focused on the problems they are best suited to detect.
+* Reproducible browser test execution reduces environment-related differences between developers and CI.
+
+### Negative
+
+* More tooling and infrastructure must be maintained.
+* Test execution can require more time and resources than unit tests alone.
+* Visual regression tests require maintenance when intentional visual changes occur.
+* Usability testing introduces manual effort.
+* Release gates can delay releases when infrastructure or tests fail.
+
+---
+
+## Related TOGAF Phases
+
+* Architecture Vision (Phase A)
+* Technology Architecture (Phase D)
+* Opportunities and Solutions (Phase E)
+* Implementation Governance (Phase G)
+
+---
+
+## References
+
+* [Technology Architecture](../adm/technology-architecture/)
+* [Testing and Quality Strategy](../adm/technology-architecture/#6-testing--quality-strategy)
+* [ADR-000500 – Accessibility as a Cross-Cutting Concern](./000500-accessibility-as-a-cross-cutting-concern/)

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

@@ -5,13 +5,22 @@ sidebar:
   order: 0
 ---
 
-LUNA Charts is an open-source charting library built with a strong focus on **accessibility**, **developer experience**, and **long-term maintainability**.
+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.
+The project was created because many existing charting libraries provide excellent visualizations but often 
+treat accessibility as a secondary concern. Furthermore, a lot of teams have a lack of accessibility awareness, 
+and accessibility features are often pushed to the end of the project.
 
 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.
+Instead of focusing on becoming a big library with numerous chart-creation functions, this project concentrates 
+on ease of use and chart modification, with accessibility playing a major role throughout the entire development process. 
+LUNA-Charts is open-source software. 
+This guarantees that everyone can use and modify it. We want to make the world more accessible for everyone.
+
+Furthermore, we focus on an **architecture-first process**. The entire foundation—including 
+business goals, technical architecture, governance, and architectural decisions—was designed before implementation began.
 
 ## Project Goals
 
@@ -26,11 +35,9 @@ LUNA Charts aims to provide a charting library that is:
 
 ## Current Project Status
 
-The project is currently in the **Groundwork** phase.
+The project is currently in the **First Proof of Concept (v0.3.0)** phase.
-
+We validate the core technical and accessibility assumptions of the library through a first working implementation. 
-At this stage, the architecture, repository structure, development workflow, and governance model are being established before implementing the first chart components.
+The goal is to prove that the chosen architecture actually works in practice before committing to a broader component set.
-
-Although no production-ready charts are available yet, the project documentation already reflects the long-term vision and architectural direction.
 
 ## Learn More
 

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

@@ -5,7 +5,8 @@ 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.
+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/
@@ -17,7 +18,7 @@ luna-charts/
 │
 ├── examples/
 │
-├── .github/
+├── .gitea/
 │
 ├── package.json
 └── pnpm-workspace.yaml
@@ -51,31 +52,38 @@ It serves as the **Single Point of Truth (SPOT)** for:
 - Project governance
 - User documentation
 
-The documentation is rendered using **Starlight**, but the Markdown content remains the authoritative source.
+The documentation is rendered using **Astro and 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.
+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
 
+Right now, we are working on version 0.3.0, implementing a first proof of concept. 
+The first Minimum Viable Product will be launched with version 1.0.0.
+
 ---
 
+## .gitea/
+
+- Gitea Actions
+- Issue templates
+- Pull request templates
+- Community workflows
+
 ## .github/
 
 Contains project automation such as:
 
-- GitHub Actions
+- Code of Conduct
-- Issue templates
-- Pull request templates
-- Community workflows
 
 ---
 
@@ -83,6 +91,7 @@ Contains project automation such as:
 
 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.
+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

@@ -7,86 +7,102 @@ sidebar:
 
 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.
+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
+## Completed Milestones ✅
 
-**Current Phase:** Groundwork
+<details>
-
+  <summary>**Completed:** Groundwork (v0.1.0)</summary>
-The project is currently preparing the technical and organizational foundation for future development.
+  The project is preparing the technical and organizational foundation for future development.
 
 Completed work includes:
 
-- Repository structure
+- **Repository structure:** Standardized layout for code, configurations, and assets.
-- Development workflow
+- **Development workflow:** Definition of branching strategies, commit rules, and review processes.
-- Architecture documentation (TOGAF ADM)
+- **Architecture documentation (TOGAF ADM):** Architecture framework set up according to the TOGAF standard.
-- Architecture Decision Records (ADRs)
+- **Architecture Decision Records (ADRs 1-5):** System established for transparent documentation of architectural decisions.
-- Project governance
+- **Project governance:** Defined roles, responsibilities, and decision-making processes.
-- Documentation infrastructure
+- **Documentation infrastructure:** "Docs-as-Code" setup integrated into the repository.
 
 At this stage, no production-ready chart components are available.
 
----
+</details>
-
-## Upcoming Milestones
-
-### Foundation
-
-- Create the initial StencilJS library
-- Establish Storybook for component development
-- Configure testing infrastructure
-- Configure CI/CD pipeline
 
 ---
 
-### First Proof of Concept
+<details>
+  <summary>
+    Completed Foundation v0.2.0
+  </summary>
+  This milestone focuses on setting up the technical core of the component library. The goal is to build an automated, 
+  testable, and documented environment for efficient StencilJS component development.
 
-Deliver the first functional chart implementation to validate the technical architecture.
+  This milestone focuses on setting up the technical core of the component library. The goal is to build an automated,
+  testable, and documented environment for efficient StencilJS component development.
 
+  - **Create the initial StencilJS library:** Initialize the codebase and core configurations for the web component engine.
+  - **Establish Storybook for component development:** Set up Storybook as the development environment and isolated playground for component creation.
+  - **Configure testing infrastructure:** Configure unit, integration, or visual regression testing frameworks.
+  - **Configure CI/CD pipeline:** Automate linting, testing, and initial build checks on every repository push or pull request.
+</details>
+
+---
+
+## Current Status ⏳
+
+### First Proof of Concept v0.3.0
+
+This milestone focuses on validating the core technical and accessibility assumptions of the library through a first
+working implementation. The goal is to prove that the chosen architecture (SVG rendering, Web Components, accessibility-first
+approach) actually works in practice before committing to a broader component set.
 Goals include:
 
-- SVG rendering
+- **SVG rendering:** Implement a first chart component using SVG-based rendering.
-- Accessibility validation
+- **Accessibility validation:** Verify WCAG compliance with automated (axe-core) and manual (screen reader) testing.
-- Framework integration
+- **Framework integration:** Confirm the component works correctly when consumed from at
-- Community feedback
+  least one external framework (e.g. React or Vue).
+- **Community feedback:** Share the proof of concept for early feedback before scaling to further components.
 
 ---
 
-### Minimum Viable Product (MVP)
+## Upcoming Milestones 🚀
 
-Provide the first publicly usable version of LUNA Charts.
+### Minimum Viable Product (MVP) v1.0.0
 
+This milestone marks the first public-ready release. The goal is a stable, documented,
+and accessible set of chart components that can be safely adopted by external users.
 The MVP focuses on delivering value rather than completeness.
 
 Expected outcomes include:
 
-- Initial chart collection
+- **Initial chart collection:** Ship a first stable set of chart types built on the validated architecture.
-- Stable public API
+- **Stable public API:** Freeze the public component API surface and document breaking-change policy.
-- Documentation
+- **Documentation:** Complete user-facing documentation (usage guides, API reference, accessibility notes).
-- Example applications
+- **Example applications:** Provide working examples for common framework integrations.
-- Accessibility support
+- **Accessibility support:** Ensure all shipped components meet the project's WCAG target across the full component set.
 
 ---
 
 ### Community Growth
 
-After the MVP, the project will gradually expand.
+With a stable MVP in place, this milestone shifts focus toward expanding the library's reach,
-
+capabilities, and contributor base.
 Future work may include:
 
-- Additional chart types
+- **Additional chart types:** Expand the component library beyond the initial MVP set.
-- Advanced customization
+- **Advanced customization:** Add theming, styling, and configuration options requested by users.
-- Performance improvements
+- **Performance improvements:** Optimize rendering and bundle size based on real-world usage.
-- Extended framework support
+- **Extended framework support:** Broaden compatibility with additional frameworks and build tools.
-- Community contributions
+- **Community contributions:** Establish a smooth path for external contributors (good-first-issue labeling, contributor docs).
-- Governance evolution
+- **Governance evolution:** Revisit and evolve project governance as the contributor base grows.
 
 ---
 
 ## 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.
+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.

package.json

@@ -1,6 +1,6 @@
 {
   "name": "LUNA-Charts",
-  "version": "1.0.0",
+  "version": "0.2.0",
   "description": "",
   "main": "index.js",
   "scripts": {
@@ -11,6 +11,7 @@
     "changeset": "changeset",
     "version": "changeset version",
     "release": "changeset publish",
+    "storybook": "pnpm --filter luna-charts run storybook",
     "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"
@@ -19,18 +20,19 @@
   "author": "",
   "license": "ISC",
   "devEngines": {
-    "runtime": {
-      "name": "node",
-      "version": ">=22.0.0"
-    },
     "packageManager": {
       "name": "pnpm",
-      "version": "11.11.0",
+      "version": "12.0.0",
       "onFail": "download"
+    },
+    "runtime": {
+      "name": "node",
+      "version": ">=24.0.0"
     }
   },
+  "packageManager": "pnpm@12.0.0",
   "type": "module",
-  "devDependencies": {
+    "devDependencies": {
     "@changesets/cli": "^2.31.0",
     "@eslint/js": "^10.0.1",
     "eslint": "^10.6.0",

packages/luna-charts/CHANGELOG.md

@@ -0,0 +1,15 @@
+# luna-charts
+
+## 0.2.0
+
+### Minor Changes
+
+- This release introduces the next iteration of LUNA Charts with improvements to the component architecture, development workflow, testing infrastructure, and documentation.
+
+  - Improved component development and project structure
+  - Enhanced component testing infrastructure
+  - Improved CI/CD test handling, including projects without test files
+  - Updated and extended project documentation
+  - Various improvements and fixes across the library
+
+- 72c49e6: Establish the initial project foundation with architecture, documentation, governance, and development tooling.

packages/luna-charts/package.json

@@ -1,6 +1,6 @@
 {
   "name": "luna-charts",
-  "version": "0.0.1",
+  "version": "0.2.0",
   "description": "Stencil Component Starter",
   "main": "dist/index.cjs.js",
   "module": "dist/index.js",

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

@@ -1,37 +0,0 @@
-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

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

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

@@ -1,41 +0,0 @@
-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

@@ -1,32 +0,0 @@
-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

@@ -1,15 +0,0 @@
-# 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/)_

pnpm-workspace.yaml

@@ -3,19 +3,20 @@ packages:
   - "docs/"
 
 allowBuilds:
-  esbuild: true
   sharp: true
+  esbuild: true
+  playwright: true
 
-onlyBuiltDependencies:
+fetchTimeout: 300000
-  - playwright
+fetchRetries: 10
 
 supportedArchitectures:
   os:
     - current
-    - linux
   cpu:
     - current
-    - x64
   libc:
     - current
-    - glibc
+
+minimumReleaseAgeExclude:
+  - astro@7.2.9