2026-08-05 15:57:47 +00:00
11 changed files with 1712 additions and 0 deletions
@@ -0,0 +1,169 @@
 ---
 title: 8. Architecture Change Management
 description: Process for evaluating and managing future architectural change in LUNA Charts, ensuring the system evolves without losing consistency.
 sidebar:
  order: 9
 ---
 ## 1. Overview
 Architecture Change Management defines how LUNA Charts adapts to new requirements, technologies, standards, and stakeholder needs throughout its lifecycle.
 Rather than treating the architecture as a static artifact, this phase establishes a controlled evolution process that preserves architectural consistency while enabling continuous improvement.
 All architectural changes follow documented governance processes and remain aligned with the project's long-term vision and architectural principles.
 ## 2. Objectives
 Architecture Change Management pursues the following objectives:
 - Ensure the long-term sustainability of the architecture
 - Adapt to technological and regulatory changes
 - Preserve architectural consistency across releases
 - Support controlled innovation without compromising existing principles
 - Maintain traceable architectural evolution
 ## 3. Architecture Change Triggers
 Architectural changes may be initiated by various internal and external factors.
 Typical triggers include:
 ### External Triggers
 - Updates to WCAG recommendations
 - Changes in accessibility regulations
 - Browser platform evolution
 - SVG specification changes
 - TypeScript language evolution
 - New web platform capabilities
 ### Internal Triggers
 - Architectural improvements
 - Lessons learned during implementation
 - Long-term maintainability concerns
 - Performance improvements
 - Community feedback
 - New functional requirements
 The existence of a trigger does not automatically require an architectural change. Every trigger must first be evaluated.
 ## 4. Change Evaluation
 Every proposed architectural change is evaluated before implementation begins.
 Evaluation includes questions such as:
 - Does the proposal align with the Architecture Vision?
 - Does it respect the established architecture principles?
 - Does it improve long-term maintainability?
 - Does it preserve accessibility objectives?
 - Does it maintain a positive developer experience?
 - Does the expected value justify the architectural impact?
 Architectural principles always take precedence over feature demand.
 New functionality should strengthen the existing architecture rather than weaken its consistency.
 ## 5. Architecture Evolution Process
 Architectural evolution follows a structured review process.
 ```text
 Change Trigger
        ↓
 Architecture Evaluation
        ↓
 Architecture Discussion
        ↓
 Maintainer Decision
        ↓
 Architecture Documentation Update
        ↓
 Implementation
        ↓
 Project Documentation Update
        ↓
 Release
 ```
 Implementation follows documented architectural decisions rather than defining them.
 ## 6. Documentation Management
 Architecture documentation is the primary source of truth for architectural decisions.
 Whenever an architectural change is approved, the following artifacts should be reviewed and updated where applicable:
 - Architecture documentation (ADM phases)
 - Developer documentation
 - Usage examples
 - Test suites
 - Public Change Log
 Documentation updates should precede or accompany implementation to ensure architectural transparency.
 ## 7. Continuous Improvement
 LUNA Charts is designed to evolve continuously through incremental architectural improvements.
 Continuous improvement includes:
 - Refining existing architectural decisions
 - Improving accessibility support
 - Simplifying developer experience
 - Enhancing maintainability
 - Responding to technological evolution
 Continuous evolution should preserve the project's architectural identity.
 ## 8. Major Architectural Evolution
 Some changes may fundamentally affect the architecture.
 Examples include:
 - Replacing core rendering technologies
 - Redefining the public API model
 - Introducing a new architectural paradigm
 - Fundamental changes to supported platforms
 Such changes should be treated as major architectural revisions and may require a new major software version.
 Major architectural evolution should be carefully evaluated before implementation begins.
 ## 9. Relationship to Previous Phases
 Architecture Change Management builds upon all previous ADM phases.
 - Architecture Vision defines the long-term direction.
 - Business Architecture defines the expected business value.
 - Information Systems Architecture defines the application structure.
 - Technology Architecture defines the technical implementation.
 - Opportunities & Solutions defines the implementation roadmap.
 - Migration Planning defines delivery planning.
 - Implementation Governance ensures architectural compliance during implementation.
 Architecture Change Management ensures that future architectural evolution remains aligned with these foundations.
 ## 10. Key Outcome of this Phase
 Architecture Change Management establishes:
 - A structured process for architectural evolution
 - Clear architecture change triggers
 - Evaluation criteria for architectural decisions
 - Documentation-first architecture evolution
 - Continuous architectural improvement
 - Controlled management of major architectural revisions
 The result is an architecture that remains stable, maintainable, and adaptable throughout the lifecycle of LUNA Charts.
 ## 11. Change Log
 No structural changes were introduced in this document during this iteration.
 This phase concludes the Architecture Development Method (ADM) lifecycle by defining how architectural evolution is managed after implementation.
 The Architecture Change Management process complements the governance model established in Implementation Governance (Phase G) and provides the long-term evolution strategy for LUNA Charts.
@@ -0,0 +1,135 @@
 ---
 title: 1. Architecture Vision
 description: Problem statement, objectives, target audience, guiding principles, and success criteria for LUNA Charts.
 sidebar:
  order: 2
 ---
 import { Aside } from '@astrojs/starlight/components';
 ## 1. Problem Statement
 Modern web applications are increasingly required to meet accessibility standards such as the European Accessibility Act (EAA) and WCAG 2.2 guidelines.
 However, implementing accessible data visualizations remains a complex and underrepresented area in frontend development. Many developers lack specialized knowledge in accessibility design patterns, especially for chart components such as bar, line, or pie charts. As a result, accessibility is often added late, inconsistently, or not at all.
 ## 2. Objective
 LUNA Charts aims to provide a reusable, developer-friendly charting library that enables the creation of accessible, WCAG-oriented data visualizations for web applications.
 The primary objective is to reduce the complexity of implementing accessibility in charts while maintaining flexibility for customization and integration into modern frontend stacks.
 ## 3. Target Audience
 The primary stakeholders of LUNA Charts are:
 - Frontend developers integrating chart components into web applications
 - Full-stack developers building data-driven products
 - Teams responsible for accessibility compliance in digital products
 Secondary stakeholders include:
 - UX/UI designers concerned with accessible data representation
 - Accessibility specialists reviewing compliance with WCAG standards
 - End users, including users with visual, cognitive, or motor impairments
 ## 4. Benefits
 LUNA Charts provides the following benefits:
 - Simplifies the implementation of accessible data visualizations
 - Reduces the need for deep accessibility expertise in development teams
 - Promotes consistent WCAG-aligned chart behavior across applications
 - Improves development speed by providing reusable, standardized components
 - Enhances end-user accessibility for data-driven interfaces
 - Supports regulatory compliance with accessibility requirements
 ## 5. Scope
 LUNA Charts is a frontend-focused charting library providing reusable components for accessible data visualization.
 It is further defined as a **closed system with a strictly controlled input boundary and deterministic internal processing pipeline** (see [Section 8.4](#84-system-boundary-and-extensibility-constraint)).
 ## 6. Architecture Principles
 The following principles guide all architectural decisions in LUNA Charts. They apply across all ADM phases and serve as the basis for evaluating design options, resolving conflicts, and maintaining long-term consistency.
 | ID | Principle | Statement | Rationale |
 |----|-----------|-----------|-----------|
 | P01 | Accessibility by Design | Accessibility is a core requirement of every component, not a feature added after the fact. | Aligns with the EAA and WCAG mandate; prevents costly rework in later development stages. |
 | P02 | Framework Agnosticism | LUNA Charts must not introduce tight coupling to any specific frontend framework. | Maximizes adoption potential across React, Vue, Angular, and Web Components ecosystems. |
 | P03 | Developer Experience First | Every API decision is evaluated primarily by the effort it imposes on the integrating developer. | Adoption depends directly on integration speed and ease of use. |
 | P04 | Open Source by Default | LUNA Charts is developed and maintained as an open-source project. | Builds community trust, enables external contributions, and ensures regulatory transparency. |
 | P05 | Standards over Convention | Where open standards exist (WCAG, ARIA, WAI-ARIA), LUNA Charts follows them over proprietary patterns. | Ensures long-term maintainability and compatibility with assistive technologies. |
 | P06 | Lightweight by Design | The library actively minimizes external dependencies and bundle size. | Prevents performance regressions in integrating products. |
 | P07 | Separation of Concerns | Visual rendering, data processing, configuration resolution, and cross-cutting concerns are clearly separated. | Improves testability, predictability, and architectural clarity. |
 ## 7. Success Criteria
 The success of LUNA Charts is primarily measured by:
 - Adoption rate among frontend and full-stack developers
 - Integration into production-grade applications
 - Reduction of accessibility-related implementation effort in charting
 - Positive developer experience and ease of integration
 ## 8. Change Log
 <Aside type="note">
  During subsequent TOGAF ADM phases (Business and Application Architecture), the following refinements were made.
 </Aside>
 ### 8.1 Accessibility Model Refinement
 - Accessibility was reclassified from a conceptual "Accessibility Engine" to a **system-wide cross-cutting concern**
 - Accessibility is enforced across multiple layers:
  - Default value handling (design-time)
  - Validation and checks (build-time)
  - Runtime warnings and safeguards
 *(See original Section 1 + Section 6 — refinement of internal architecture interpretation)*
 ### 8.2 Architectural Structure Shift (Component → Pipeline Model)
 - The system architecture was refined from a component-oriented view to a **deterministic processing pipeline model**
 ![Architectural Structure Shift](https://wiki.byting-pandas.ninja/luna-charts/architecture-vision/luna_charts_architectural_structure_shift.svg)
 - Internal processing is now defined as sequential stages:
  - Input / Interaction
  - Validation / Resilience
  - Configuration Resolution
  - Accessibility Enforcement
  - Rendering
 *(Impacts Section 5 Scope and Section 6 Principles P07)*
 ### 8.3 Developer Interaction Model Clarification
 - The developer interaction model was clarified as a **component-based declarative API**
 - Developers interact via strongly typed chart-specific components such as:
  - `<BarChart />`
  - `<LineChart />`
  - `<PieChart />`
 - Each chart type defines its own strict data model
 *(Refines Section 2 Objective and Section 3 Target Audience assumptions)*
 ### 8.4 System Boundary and Extensibility Constraint
 - The architecture was explicitly defined as a **closed system**
 - No plugin system or extension points are provided
 - Internal pipeline stages cannot be modified or extended by external developers
 - Developer interaction is strictly limited to input and configuration at the system boundary
 *(Refines Section 5 Scope and Section 6 Principles P07)*
 ---
 ## 🔎 Summary of Changes in This Document
 The following sections were updated compared to the original version:
 - Section 5 (Scope) → clarified system boundary model
 - Section 6 (Principles) → refined separation of concerns wording
 - Section 8 (Evolution Note) → fully introduced and structured architectural evolution
@@ -0,0 +1,197 @@
 ---
 title: 2. Business Architecture
 description: Stakeholders, business processes, decision-making model, capability map, and business value driving adoption of LUNA Charts.
 sidebar:
  order: 3
 ---
 import { Aside } from '@astrojs/starlight/components';
 ## 1. Overview
 This Business Architecture describes how LUNA Charts is used in a real-world context. It focuses on stakeholders, decision processes, business workflows, and value creation rather than technical implementation details.
 LUNA Charts is a developer-focused charting library designed to support the creation of accessible, WCAG-compliant data visualizations in web applications.
 ## 2. Business Context
 Modern software products are required to meet accessibility regulations such as the European Accessibility Act (EAA) and WCAG 2.2 guidelines.
 Accessible data visualization is a particularly complex area, especially for chart components (e.g., bar, line, pie charts), where accessibility is often inconsistent or added late in development.
 LUNA Charts addresses this gap by providing a reusable solution that reduces accessibility complexity for development teams.
 ## 3. Business Actors (Stakeholders)
 ### 3.1 Primary Actors
 - Development Team responsible for evaluating, integrating, and maintaining LUNA Charts within the application
 - Product Owner responsible for final decision-making based on business value, cost, and priorities
 ### 3.2 Supporting Actors
 - Software Architect provides technical evaluation and ensures long-term architectural consistency
 - Accessibility / Compliance Stakeholders ensure adherence to WCAG and regulatory requirements
 ### 3.3 End Users
 - Users consuming data visualizations
 - Includes users with disabilities relying on assistive technologies
 ## 4. Business Trigger (Why the process starts)
 The process begins when a product requirement emerges that requires accessible data visualizations.
 Typical triggers include:
 - Need for WCAG-compliant charts in a product
 - Accessibility audit findings requiring improvements
 - Product Owner requesting new data visualization features
 ## 5. Business Process (LUNA Charts Adoption Lifecycle)
 The adoption of LUNA Charts typically follows this sequence:
 - A business need for accessible charts is identified
 - The team researches possible solutions
 - Alternative charting libraries are evaluated
 - LUNA Charts is selected as a candidate solution
 - The team validates usability through documentation and examples
 - A proof of concept is created
 - The Product Owner makes the final decision
 - LUNA Charts is integrated into the product
 - Developers implement charts in production features
 - End users interact with accessible visualizations
 ## 6. Decision-Making Model
 The decision to adopt LUNA Charts is typically shared across roles:
 - Development Team → provides technical feasibility assessment
 - Software Architect → evaluates architectural fit and long-term sustainability
 - Product Owner → makes the final investment and product decision
 ### Decision Criteria Include:
 - Documentation quality
 - Community / support availability
 - Licensing model (e.g., Open Source)
 - Technological compatibility (web ecosystem fit)
 - Ease of integration and developer experience
 ## 7. Business Capability Map
 The following capability map defines what LUNA Charts must be able to do as a product — organized into three levels:
 - Core Capabilities
 - Enabling Capabilities
 - Governance & Sustainability Capabilities
 ### 7.1 Core Capabilities
 | Capability | Description |
 |------------|-------------|
 | Chart Rendering | Creation of standard data visualizations: bar, line, pie, scatter charts via SVG or Canvas output |
 | Interaction Handling | Enables keyboard navigation, focus management, and non-pointer interaction models across all chart types |
 <Aside type="caution" title="⚠️ Important Architectural Change">
  The **Accessibility Engine was removed as a standalone capability**. Accessibility is now defined as a **cross-cutting system-wide concern**, not a separate capability or module. See [Evolution Note Section 12.1](#121-accessibility-model-refinement).
 </Aside>
 ### 7.2 Enabling Capabilities
 | Capability | Description |
 |------------|-------------|
 | Configuration & Theming | Allows customization of chart appearance including colors, contrast, labels, and layout |
 | Framework Integration | Enables embedding into modern web application frameworks: React, Vue, Angular, and Web Components |
 | Data Processing | Handles normalization, scaling, and transformation of input datasets into renderable structures |
 | Documentation & DX | Maintains API documentation, examples, and developer experience consistency |
 ### 7.3 Governance & Sustainability
 | Capability | Description |
 |------------|-------------|
 | Release Management | Governs versioning (Semantic Versioning), changelog discipline, and predictable releases |
 | Compliance Monitoring | Tracks WCAG audit status across releases and prevents regressions |
 ## 8. Business Value
 ### 8.1 Value for Development Teams
 - Faster implementation of charts
 - No need for deep accessibility expertise
 - Reduced implementation complexity
 - Standardized reusable solution
 ### 8.2 Value for Product Owners
 - Reduced development and maintenance costs
 - Lower risk of accessibility compliance issues
 - Avoidance of repeated evaluation efforts
 - Predictable integration effort
 ### 8.3 Value for End Users
 - Improved accessibility of information
 - Support for assistive technologies
 - More consistent data visualization experience
 ## 9. Business Risks / Reasons for Rejection
 LUNA Charts may be rejected if:
 - Lack of commercial support raises operational risk concerns
 - Limited chart types do not meet product requirements
 - Insufficient flexibility for custom visualization needs
 - Concerns about long-term maintenance in open-source context
 ## 10. Business Constraints
 - Must operate in modern web environments
 - Must integrate with existing frontend architectures
 - Must support accessibility requirements (WCAG compliance)
 - Must remain lightweight and developer-friendly
 - Must not introduce excessive framework lock-in
 - **Must operate as a closed system with defined input boundary and no extension mechanisms** *(See [Evolution Note 12.2](#122-system-boundary--extensibility-constraint))*
 ## 11. Key Outcome of this Phase
 The Business Architecture defines:
 - How LUNA Charts is evaluated and adopted
 - Which stakeholders influence the decision
 - What value is expected from the solution
 - Which risks can lead to rejection
 - How the solution fits into real-world workflows
 - Which capabilities the product must maintain to remain viable
 ## 12. Change Log
 ### 12.1 Accessibility Model Refinement
 - The previously defined "Accessibility Engine" was removed as a standalone capability
 - Accessibility is now defined as a **system-wide cross-cutting concern**
 - It is enforced through:
  - Default configurations
  - Validation processes
  - Runtime feedback mechanisms
 *(Impacts Section 7.1 Core Capabilities)*
 ### 12.2 System Boundary & Extensibility Constraint
 - LUNA Charts is explicitly defined as a **closed system**
 - No plugin or extension mechanism is provided
 - Developers cannot modify internal processing pipeline behavior
 - Interaction is limited to declarative input and configuration only
 *(Impacts Section 10 Business Constraints and Section 6 Decision Criteria indirectly)*
 ### 12.3 Architectural Model Alignment (Business ↔ Application)
 - The Business Architecture now explicitly aligns with the Application Architecture:
  - Declarative component-based API model
  - Strict separation of responsibilities
  - Accessibility as cross-cutting concern
 *(Ensures consistency with Phase C decisions)*
@@ -0,0 +1,199 @@
 ---
 title: 7. Implementation Governance
 description: Roles, review processes, and quality gates that keep LUNA Charts implementation aligned with the documented architecture.
 sidebar:
  order: 8
 ---
 ## 1. Overview
 This phase defines how the implementation of LUNA Charts is governed to ensure long-term architectural consistency, product quality, and maintainability.
 Rather than introducing new architectural decisions, Implementation Governance ensures that all implementation activities remain aligned with the architecture defined in previous phases. It establishes responsibilities, review processes, quality gates, and decision-making procedures for both contributors and maintainers.
 As an open-source project, LUNA Charts balances community contributions with centralized architectural governance to protect the project's long-term vision.
 ## 2. Governance Principles
 Implementation Governance is guided by the following principles:
 - Architecture remains the authoritative source for implementation decisions.
 - Community contributions are encouraged but do not define the architecture.
 - Architectural decisions are reviewed collectively by the Maintainer Team.
 - Quality requirements apply consistently across the entire project.
 - Architectural evolution is documented and traceable through the architecture repository.
 ## 3. Governance Roles
 ### Community
 The community contributes ideas and implementation proposals.
 Responsibilities include:
 - Reporting bugs
 - Suggesting improvements
 - Participating in architectural discussions
 - Creating Pull Requests
 The community may influence discussions but does not make architectural decisions.
 ### Contributors
 Contributors actively improve the project.
 Responsibilities include:
 - Implementing new features
 - Fixing defects
 - Improving documentation
 - Maintaining existing functionality
 All contributions are subject to review before integration.
 ### Maintainers
 The Maintainer Team is responsible for the long-term integrity of the project.
 Responsibilities include:
 - Reviewing Pull Requests
 - Protecting architectural consistency
 - Approving architectural changes
 - Ensuring accessibility standards
 - Maintaining API stability
 - Approving public releases
 Architectural governance is owned collectively by the Maintainer Team rather than by an individual contributor.
 ## 4. Governance Layers
 Implementation Governance operates across three complementary layers.
 ### 4.1 Automated Governance
 Objective quality checks performed automatically during development.
 Examples include:
 - TypeScript validation
 - Linting
 - Unit testing
 - Accessibility testing
 - Build verification
 - Continuous Integration (CI)
 These checks ensure that objective quality requirements are consistently enforced.
 ### 4.2 Architectural Governance
 Architectural Governance ensures that implementations remain aligned with the defined architecture.
 Maintainers review topics such as:
 - Public API consistency
 - Architectural boundaries
 - Rendering strategy
 - Cross-cutting concerns
 - Long-term maintainability
 Architectural compliance cannot be verified solely through automation and therefore requires human review.
 ### 4.3 Project Governance
 Project Governance focuses on overall software quality beyond technical correctness.
 Evaluation criteria include:
 - Code readability
 - Maintainability
 - Documentation quality
 - Consistency with project conventions
 - Long-term sustainability
 A contribution may therefore be rejected even if all automated quality checks have passed.
 ## 5. Architectural Compliance
 Every contribution is evaluated against the documented architecture.
 A Pull Request may be rejected if it:
 - Violates documented architectural decisions
 - Introduces unnecessary API changes
 - Circumvents accessibility mechanisms
 - Ignores cross-cutting concerns
 - Reduces maintainability or consistency
 - Conflicts with established architectural principles
 Maintainers are responsible for ensuring compliance before accepting contributions.
 ## 6. Architectural Change Process
 Architectural evolution follows a structured review process.
 ```text
 Proposal
    ↓
 Architecture Discussion
    ↓
 Maintainer Review
    ↓
 Decision
    ↓
 Architecture Documentation Update
    ↓
 Evolution Note
    ↓
 Implementation
 ```
 Architectural decisions become official only after the architecture documentation has been updated.
 Implementation follows the documented architecture rather than defining it.
 ## 7. Release Governance
 Public releases require successful completion of all mandatory quality gates defined by the Technology Architecture.
 These quality gates include, where applicable:
 - Automated testing
 - Accessibility validation
 - Build verification
 - Packaging validation
 - Release-specific usability testing
 Implementation Governance ensures that releases cannot be approved until all required validation activities have been successfully completed.
 ## 8. Continuous Architecture Evolution
 The architecture is expected to evolve throughout the lifetime of the project.
 Potential triggers include:
 - New WCAG recommendations
 - Browser platform changes
 - TypeScript language evolution
 - SVG specification updates
 - Community feedback
 - Long-term maintainability concerns
 All architectural changes follow the same governance process regardless of their origin.
 ## 9. Key Outcome of this Phase
 Implementation Governance defines:
 - Governance responsibilities
 - Review and approval processes
 - Automated and manual quality controls
 - Architectural compliance rules
 - Release approval governance
 - Continuous architecture evolution
 The result is a governance model that protects the long-term architectural integrity of LUNA Charts while enabling collaborative open-source development.
 ## 10. Change Log
 No structural changes were introduced in this document during this iteration.
 This governance model is fully aligned with:
 - Architecture Vision (Phase A)
 - Business Architecture (Phase B)
 - Information Systems Architecture (Phase C)
 - Technology Architecture (Phase D)
 - Opportunities & Solutions (Phase E)
 - Migration Planning (Phase F)
@@ -0,0 +1,74 @@
 ---
 title: What is the Architecture Development Method (ADM)
 description: Overview of the TOGAF Architecture Development Method (ADM) used in LUNA-Charts.
 sidebar:
  order: 1
 ---
 import { Aside, Steps, Card, CardGrid } from '@astrojs/starlight/components';
 The **Architecture Development Method (ADM)** is the core process at the heart of [TOGAF](https://www.opengroup.org/togaf) (The Open Group Architecture Framework), one of the most widely used enterprise architecture frameworks. It provides a step-by-step, iterative approach for developing, implementing, and governing enterprise architecture.
 ## Purpose
 ADM gives organizations a repeatable, structured way to design architecture that aligns business goals with IT systems, rather than approaching architecture work ad hoc.
 <Aside type="note">
  ADM is typically visualized as a wheel/cycle, since architecture work is iterative rather than strictly linear.
 </Aside>
 ## The Phases
 <Steps>
 1. **Preliminary Phase**
   Define the architecture framework, principles, and scope for the organization.
 2. **Phase A: Architecture Vision**
   Establish the scope, stakeholders, constraints, and high-level vision of the project.
 3. **Phase B: Business Architecture**
   Model current and target business processes, organization, and capabilities.
 4. **Phase C: Information Systems Architectures**
   Split into Data Architecture and Application Architecture.
 5. **Phase D: Technology Architecture**
   Define hardware, software, and network infrastructure needed to support the architecture.
 6. **Phase E: Opportunities & Solutions**
   Identify major implementation projects and delivery vehicles.
 7. **Phase F: Migration Planning**
   Prioritize projects and develop a detailed roadmap.
 8. **Phase G: Implementation Governance**
   Ensure implementation projects conform to the architecture.
 9. **Phase H: Architecture Change Management**
   Monitor and manage changes to the architecture over time.
 </Steps>
 <Aside type="tip">
  **Requirements Management** runs through the center of the ADM cycle, since requirements can emerge and need to be addressed at any phase.
 </Aside>
 ## Phase C in Detail
 <CardGrid>
  <Card title="Data Architecture">
    Structure of an organization's logical and physical data assets.
  </Card>
  <Card title="Application Architecture">
    Blueprint for individual application systems, their interactions, and their relationships to core business processes.
  </Card>
 </CardGrid>
 ## Key Characteristics
 - **Iterative** — Organizations often cycle through the phases multiple times, refining architecture at increasing levels of detail.
 - **Adaptable** — Phases can be tailored, skipped, or reordered depending on the organization's needs and maturity.
 - **Governance-focused** — Strong emphasis on ensuring architecture decisions are actually implemented and maintained correctly.
 ---
@@ -0,0 +1,206 @@
 ---
 title: 3. Information Systems Architecture
 description: Internal application design of LUNA Charts and how the system is structured to process and render data.
 sidebar:
  order: 4
 ---
 import { Aside } from '@astrojs/starlight/components';
 ## 1. Overview
 This Application Architecture defines how LUNA Charts is structured at the application level. It describes the internal processing model, developer interaction boundaries, system layers, and architectural style used to ensure accessible, consistent, and predictable chart rendering.
 LUNA Charts is designed as a declarative, component-based charting library with a controlled internal processing pipeline and strict input boundaries.
 ## 2. Architectural Style
 LUNA Charts follows a:
 - Declarative API model
 - Component-based developer interface
 - Black-box processing pipeline
 - Opinionated and non-extensible architecture
 ### Key Characteristics
 - Single entry point for developers via chart components
 - Strict separation between input and internal processing
 - Deterministic rendering behavior
 - No plugin or extension system
 - Accessibility and validation are enforced internally
 ## 3. Developer Interaction Model
 Developers interact with LUNA Charts exclusively through a declarative component API.
 ### Public API
 - `<BarChart />`
 - `<LineChart />`
 - `<PieChart />`
 - (and other chart-specific components)
 Each component has its own strongly typed data model.
 ### Responsibilities of the Developer
 Developers are responsible for:
 - Providing correctly structured data per chart type
 - Using typed configuration models provided by the library
 - Preparing and transforming data before passing it into the component
 ### Restrictions
 Developers cannot:
 - Modify internal rendering logic
 - Override accessibility processing
 - Inject plugins or extensions
 - Interfere with internal pipeline stages
 ## 4. System Boundary Model
 LUNA Charts exposes a strict system boundary:
 ### Allowed Inputs
 - Typed chart components
 - Structured data per chart type
 - Configuration properties (themes, labels, styling overrides)
 ### Internal System Ownership
 After input is provided, the system fully controls:
 - Data validation
 - Configuration resolution
 - Accessibility enforcement (system-wide cross-cutting concern)
 - Rendering process
 - Fallback behavior
 ## 5. Internal Processing Pipeline
 LUNA Charts processes all input through a deterministic pipeline:
 ![Internal Processing Pipeline](https://wiki.byting-pandas.ninja/luna-charts/information-systems-architecture-diagrams/luna_charts_internal_processing_pipeline.svg)
 ### 5.1 Interaction Layer (Entry Point)
 Receives component input, accepts data and configuration, and normalizes incoming parameters.
 ### 5.2 Resilience & Validation Layer
 Validates input data integrity, detects missing or invalid values, triggers fallback behavior if necessary, and emits warnings for developer feedback.
 ### 5.3 Configuration Resolution Layer
 Merges user configuration with default values, resolves themes, labels, and styling parameters, and applies library-provided defaults when needed.
 ### 5.4 Accessibility Enforcement Layer
 Applies accessibility rules and guidance mechanisms intended to support WCAG-compliant chart implementations, generates ARIA attributes, validates known accessibility constraints, and provides runtime warnings and developer feedback.
 <Aside type="tip">
  Accessibility enforcement is a cross-cutting concern applied across all layers — see [Section 4](#4-system-boundary-model).
 </Aside>
 ### 5.5 Rendering Layer
 Transforms processed data into visual representations, generates SVG or Canvas output, and produces the final chart visualization.
 ## 6. Chart Type Model
 LUNA Charts uses explicit chart-type components:
 - `<BarChart />`
 - `<LineChart />`
 - `<PieChart />`
 ### Characteristics
 - Each chart type has a dedicated internal rendering strategy
 - Chart type selection is static and defined at component level
 - No runtime switching of chart types
 - Each chart type defines its own data structure
 ## 7. Cross-Cutting Concerns
 ### Accessibility (System-wide Concern)
 Accessibility is implemented through a combination of type-safe APIs, validation mechanisms, default configurations, runtime warnings, and internal quality assurance processes.
 It includes:
 - WCAG compliance rules
 - ARIA generation
 - Accessibility validation
 - Runtime and build-time checks
 ### Resilience & Fallback Behavior
 The system ensures stability through:
 - Default values for missing configurations
 - Fallback labels for missing data
 - Safe rendering under incomplete input
 - Warning generation for developer feedback
 ## 8. Configuration Model
 LUNA Charts provides a strongly typed configuration system.
 Developers can configure:
 - Themes (colors, contrast, styling)
 - Labels and text overrides
 - Chart-specific display options
 - Accessibility hints (optional)
 Configuration is merged with system defaults during the processing pipeline.
 ## 9. Technology-Agnostic Design
 This Application Architecture does not assume a specific frontend framework but is compatible with modern web ecosystems such as:
 - React
 - Vue
 - Angular
 - Web Components
 The API is component-based but conceptually framework-agnostic.
 ## 10. Key Architectural Decisions
 - Component-based declarative API is used instead of pure DSL or JSON input
 - System uses a single controlled entry point for all interactions
 - Internal pipeline is fully deterministic and not externally modifiable
 - Accessibility is enforced as a core system responsibility
 - No plugin or extension mechanisms are provided
 - Chart types are explicitly defined and not dynamically extensible
 ## 11. Trade-offs
 ### Advantages
 - Strong accessibility guarantees
 - High consistency across all charts
 - Excellent developer experience
 - Predictable behavior
 - Reduced implementation complexity
 ### Limitations
 - Limited extensibility for custom chart types
 - Reduced low-level control over rendering
 - Strict API constraints for developers
 - No plugin ecosystem support
 ## 12. Evolution Note
 No structural changes were introduced in this document during this iteration. This architecture remains fully aligned with:
 - Architecture Vision (Phase A)
 - Business Architecture (Phase B)
 - Information System Architecture (Phase C)
@@ -0,0 +1,29 @@
 ---
 title: Introduction to LUNA Charts using the ADM
 description: A short introduction to LUNA Charts and how its architecture documentation follows the TOGAF Architecture Development Method (ADM).
 sidebar:
  order: 1
 ---
 import { Aside } from '@astrojs/starlight/components';
 LUNA Charts is a reusable, developer-friendly charting library that makes accessible, WCAG-oriented data visualization the default rather than an afterthought. Since chart accessibility is often added late or skipped entirely, LUNA Charts bakes it into every component from the start.
 ## Documented with the ADM
 To keep the architecture consistent and traceable as the project grows, this documentation follows the **TOGAF Architecture Development Method (ADM)** — an iterative, phase-based process for developing and governing enterprise architecture.
 Each phase of the ADM maps to one section of this wiki:
 - **Architecture Vision** — problem statement and objectives
 - **Business Architecture** — stakeholders and value drivers
 - **Information Systems Architecture** — internal application design
 - **Technology Architecture** — underlying technology choices
 - **Opportunities & Solutions** — implementation roadmap
 - **Migration Planning** — staged rollout plan
 - **Implementation Governance** — quality gates and review process
 - **Architecture Change Management** — how the architecture evolves
 <Aside type="tip">
  Reading the phases in order helps, since later phases build on decisions made earlier in the cycle.
 </Aside>
@@ -0,0 +1,221 @@
 ---
 title: 6. Migration Planning
 description: Staged delivery plan for rolling out the LUNA Charts architecture over time.
 sidebar:
  order: 7
 ---
 ## 1. Overview
 This phase defines how LUNA Charts transitions from architectural design into a deliverable product.
 Unlike traditional migration planning, LUNA Charts is a greenfield project with no existing solution to replace. Therefore, this phase focuses on planning the incremental delivery of the solution through implementation milestones and public releases.
 The objective is to maximize business value while minimizing implementation risk by validating architectural decisions before expanding the solution.
 ## 2. Delivery Strategy
 LUNA Charts follows an incremental delivery strategy.
 Implementation begins with establishing the architectural groundwork, followed by a reference implementation used to validate the overall architecture.
 Once a usable Minimum Viable Product (MVP) has been completed and reviewed internally, the project transitions into parallel development and continuous feature expansion.
 This approach enables early stakeholder feedback while ensuring that public releases maintain a professional quality standard.
 ## 3. Migration Stages
 ### Stage 1 – Architectural Groundwork
 **Objective**
 Establish the technical foundations required for all future chart implementations.
 **Deliverables**
 - Type System
 - Public API Contracts
 - Rendering Foundation
 - Configuration Model
 - Validation Framework
 **Outcome**
 A stable architectural foundation capable of supporting reusable chart implementations.
 ### Stage 2 – Reference Implementation
 **Objective**
 Validate the architecture through a production-ready BarChart implementation.
 **Deliverables**
 - BarChart component
 - Rendering pipeline
 - Accessibility support
 - Configuration integration
 - Validation integration
 **Outcome**
 Confirmation that the architectural decisions are viable for real-world usage.
 ### Stage 3 – Minimum Viable Product (MVP)
 **Objective**
 Create the first usable product increment.
 **Deliverables**
 - BarChart Reference Implementation
 - Documentation & Developer Experience
 **Outcome**
 The first version that can be evaluated by stakeholders and integrated into demonstration applications.
 The MVP serves as the primary milestone for Product Owner review and architectural validation.
 ### Stage 4 – Public Release Preparation
 **Objective**
 Prepare the library for public distribution.
 **Deliverables**
 - Unit Tests
 - Accessibility Tests
 - Linting
 - Visual Regression Testing
 - GitHub Release Pipeline
 - npm Publishing
 **Outcome**
 A production-ready release process capable of delivering reliable public versions.
 ### Stage 5 – Product Evolution
 **Objective**
 Expand the library after the initial public release.
 **Examples**
 - LineChart
 - PieChart
 - ScatterChart
 Future enhancements remain based on the architectural foundations established during earlier stages.
 ## 4. Delivery Roadmap
 The planned delivery sequence is illustrated below.
 ### Internal Delivery
 ```text
 WP1 Groundwork
        ↓
 WP2 BarChart Reference Implementation
        ↓
 WP3 Documentation & Developer Experience
        ↓
 Internal Product Review (MVP)
 ```
 The MVP enables architectural validation and stakeholder feedback before the first public release.
 ### Public Delivery
 ```text
 Internal MVP
      ↓
 WP4 Quality & Release Infrastructure
      ↓
 Public Release 1.0.0
      ↓
 WP5 Additional Chart Types
      ↓
 Future Releases
 ```
 The first public release prioritizes stability, documentation, accessibility, and developer experience over feature completeness.
 ## 5. Stakeholder Validation Strategy
 Different stakeholders participate at different stages of the delivery process.
 ### Internal Stakeholders
 - Development Team
 - Software Architect
 - Product Owner
 **Responsibilities**
 - Validate architectural decisions
 - Review developer experience
 - Confirm business value
 - Evaluate implementation quality
 ### External Stakeholders
 - Open-source community
 - Frontend developers
 - Accessibility specialists
 **Responsibilities**
 - Adopt the library
 - Provide community feedback
 - Report issues
 - Contribute improvements
 Public stakeholder involvement begins after the first production-ready release.
 ## 6. Release Strategy
 LUNA Charts distinguishes between internal milestones and public releases.
 ### Internal Milestones
 **Purpose**
 - Validate architecture
 - Validate usability
 - Gather Product Owner feedback
 Internal milestones are not intended for public consumption.
 ### Public Releases
 **Purpose**
 - Stable APIs
 - Complete documentation
 - Reliable release process
 - Community adoption
 Public releases follow Semantic Versioning and are published through npm and GitHub.
 ## 7. Migration Risks
 Potential risks include:
 - Architectural refinements discovered during the reference implementation
 - Additional accessibility requirements emerging during implementation
 - Delays caused by documentation or quality assurance activities
 - API adjustments before the first stable release
 These risks are mitigated by validating the architecture before expanding the feature set.
 ## 8. Key Outcome of this Phase
 Migration Planning defines:
 - The incremental delivery strategy
 - Internal implementation milestones
 - The Minimum Viable Product (MVP)
 - The transition from internal validation to public releases
 - Stakeholder involvement throughout delivery
 - The long-term release strategy for LUNA Charts
 The result is a structured roadmap that transforms the architectural vision into a deliverable, production-ready open-source project.
 ## 9. Change Log
 No structural changes were introduced in this document during this iteration.
 This migration strategy is fully aligned with:
 - Architecture Vision (Phase A)
 - Business Architecture (Phase B)
 - Information Systems Architecture (Phase C)
 - Technology Architecture (Phase D)
 - Opportunities & Solutions (Phase E)
@@ -0,0 +1,227 @@
 ---
 title: 5. Opportunities & Solutions
 description: Work packages that translate the LUNA Charts architecture into an implementation roadmap.
 sidebar:
  order: 6
 ---
 import { Aside } from '@astrojs/starlight/components';
 ## 1. Overview
 This phase translates the target architecture into implementable solution increments. It identifies the major work packages required to realize LUNA Charts and defines their dependencies, priorities, and expected outcomes.
 As LUNA Charts is a greenfield project, the focus is not on migration from an existing solution but on establishing a structured implementation path from architecture to a production-ready charting library.
 The goal of this phase is to identify what must be built, in which order it should be built, and which implementation areas can later evolve independently.
 ## 2. Solution Strategy
 LUNA Charts is implemented incrementally.
 The implementation begins with a foundational groundwork package that establishes the architectural contracts and reusable building blocks required by all future chart types.
 A BarChart is then implemented as the first production-ready chart and serves as a reference implementation for validating architectural decisions.
 Once the architecture has been validated through the BarChart implementation, **Documentation & Developer Experience is completed to form the first usable Minimum Viable Product (MVP)**.¹
 After this milestone has been reached, the remaining work packages can proceed in parallel.¹
 ## 3. Work Packages
 ### WP1 – Groundwork
 **Objective**
 Establish all reusable architectural foundations required for chart implementation.
 **Scope**
 - Type System
 - Public API Contracts
 - Rendering Foundation
 - Configuration Model
 - Validation Framework
 **Expected Outcome**
 The groundwork package is considered complete when:
 - Public APIs are defined
 - Chart-related data types are available
 - Rendering utilities exist
 - Configuration handling is established
 - Validation and warning mechanisms are implemented
 - A chart implementation can be built on top of the provided foundations
 **Architectural Role**
 This work package provides the reusable building blocks used by all future chart types.
 ### WP2 – BarChart Reference Implementation
 **Objective**
 Implement the first production-ready chart type and validate the architecture.
 **Scope**
 - BarChart component
 - Rendering integration
 - Accessibility validation
 - Configuration integration
 - Validation integration
 **Expected Outcome**
 The BarChart serves as a reference implementation demonstrating that:
 - The public API is usable
 - The rendering architecture is viable
 - Accessibility concepts are effective
 - Reusable foundations support real-world chart implementations
 **Architectural Role**
 This work package acts as the architectural proof-of-concept for the entire solution.
 ### WP3 – Documentation & Developer Experience
 **Objective**
 Enable developers to successfully adopt and use LUNA Charts.
 **Scope**
 - Getting Started Guides
 - Tutorials
 - API Documentation
 - Accessibility Guidance
 - Usage Examples
 **Expected Outcome**
 Developers can understand, integrate, and use LUNA Charts without requiring internal architectural knowledge.
 ### WP4 – Quality & Release Infrastructure
 **Objective**
 Ensure product quality and reliable software delivery.
 **Scope**
 - Unit Testing
 - Accessibility Testing
 - Linting
 - Visual Regression Testing
 - GitHub Release Pipeline
 - npm Publishing
 **Expected Outcome**
 All releases follow a repeatable and quality-controlled process.
 ### WP5 – Additional Chart Types
 **Objective**
 Extend the library with additional chart implementations.
 **Scope**
 Examples include:
 - LineChart
 - PieChart
 - ScatterChart
 Additional chart types may be introduced based on project priorities and community demand.
 **Expected Outcome**
 The chart ecosystem expands while reusing the foundations established in earlier work packages.
 ## 4. Work Package Dependencies
 The implementation follows a staged approach.
 ### Phase 1
 ```
 WP1 Groundwork
        ↓
 WP2 BarChart Reference Implementation
        ↓
 WP3 Documentation & Developer Experience¹
        ↓
 Internal Product Review (MVP)¹
 ```
 The first implementation phase focuses on validating the architecture and delivering the first usable product increment.
 Although Documentation & Developer Experience is modeled as an independent work package, it is functionally coupled to the BarChart Reference Implementation. Together they form the project's first Minimum Viable Product (MVP), enabling meaningful stakeholder evaluation.
 ### Phase 2
 After successful completion of the BarChart reference implementation, additional work packages can proceed independently.
 ```
                MVP¹
                 │
        ┌────────┴────────┐
        ▼                 ▼
 WP4 Quality &      WP5 Additional
 Release             Chart Types
 Infrastructure
 ```
 Although Documentation & Developer Experience is modeled as an independent work package, it is functionally coupled to the BarChart Reference Implementation.¹ Together they form the project's first Minimum Viable Product (MVP), enabling meaningful stakeholder evaluation.
 ## 5. Accessibility Strategy
 Accessibility is not implemented as a dedicated work package.
 Instead, accessibility requirements are integrated into all work packages and act as a cross-cutting quality requirement throughout the solution.
 Examples include:
 - Accessibility-related type definitions
 - Validation rules and developer warnings
 - Accessible default values and fallbacks
 - Accessible SVG output generation
 - Accessibility-focused documentation
 - Automated accessibility testing
 This approach aligns with the architectural principle of Accessibility by Design established in the Architecture Vision.
 ## 6. Solution Risks
 Potential risks include:
 - Architectural assumptions may prove invalid during the BarChart reference implementation
 - Accessibility requirements may reveal additional constraints during implementation
 - Future chart types may require capabilities not anticipated during groundwork design
 - Open-source maintenance capacity may influence implementation speed
 These risks are mitigated through the staged implementation approach and early architectural validation.
 ## 7. Key Outcome of this Phase
 - The implementation strategy for LUNA Charts
 - The major work packages required for delivery
 - Dependencies between implementation activities
 - The role of the BarChart as a reference implementation
 - The definition of the first usable MVP consisting of the BarChart implementation and developer documentation¹
 - The integration of accessibility as a cross-cutting concern
 - A phased roadmap for incremental solution realization
 ## 8. Change Log
 <Aside type="note">
  ¹ Updated during Phase F (Migration Planning). See Evolution Note below for details.
 </Aside>
 ### Work Package Dependencies and MVP Definition
 **Reason**
 During Migration Planning (Phase F), it became clear that the BarChart Reference Implementation alone does not provide sufficient business value for stakeholder evaluation. A usable product increment also requires developer documentation and onboarding material.
 This insight refined the implementation sequence without changing the overall work package structure.
 **Changes**
 - Clarified that **WP3 – Documentation & Developer Experience** is functionally coupled to **WP2 – BarChart Reference Implementation**.
 - Defined the project's first **Minimum Viable Product (MVP)** as the combination of:
  - WP2 – BarChart Reference Implementation
  - WP3 – Documentation & Developer Experience
 - Updated the work package dependency model so that parallel development begins only after the MVP has been completed and reviewed.
 - Refined the solution strategy to distinguish between:
  - Architectural validation (Groundwork + BarChart)
  - MVP completion (Documentation & Developer Experience)
  - Subsequent parallel solution evolution
 **Impact**
 The overall work package structure remains unchanged.
 Only the implementation sequence has been refined to better align the technical implementation with the project's business objectives. This ensures that the first stakeholder evaluation is based on a usable product increment rather than a purely technical implementation.
@@ -0,0 +1,226 @@
 ---
 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>
 ## 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
 - 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
@@ -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