chore(doc): Fixed typos

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