Update(docs): document containerized browser test execution

Adds the containerized Playwright-based test execution environment
(Dockerfile.test, docker-compose.test.yaml) to the Technology
Architecture, which was implemented but never documented.

- Added Section 6.6 "Test Execution Environment" describing the
  Docker-based Playwright setup used for local development and CI
- Added the containerized test environment to the "Key Architectural
  Decisions" list
- Added a Change Log entry explaining what changed and why

.changeset/config.json

@@ -7,5 +7,5 @@
   "access": "restricted",
   "baseBranch": "dev",
   "updateInternalDependencies": "patch",
-  "ignore": ["apps/docs"]
+  "ignore": []
 }

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

@@ -148,6 +148,22 @@ LUNA Charts follows a multi-layer quality assurance model.
   Automated testing (unit, accessibility, linting, visual regression) is a **blocking condition for every release**. Usability testing is a **blocking condition for minor and major releases**, but is skipped for patch releases to avoid delaying critical fixes.
 </Aside>
 
+### 6.6 Test Execution Environment
+
+Component and browser tests (Vitest browser mode, see ADR-0002) run inside a **containerized Playwright environment** rather than directly on contributor or CI host machines.
+
+#### Characteristics
+
+- A dedicated `Dockerfile.test`, based on the official Playwright container image, provides a reproducible browser environment with pinned browser versions
+- `docker-compose.test.yaml` orchestrates the test execution, isolating dependencies from the host system
+- The same containerized environment is used locally by contributors and in Continuous Integration, avoiding "works on my machine" discrepancies caused by differing local Playwright/browser installations
+
+#### Rationale
+
+- Ensures deterministic, reproducible accessibility and browser test results independent of the host operating system
+- Removes the need for contributors to install and maintain matching Playwright browser binaries locally
+- Aligns automated testing (Section 6.1–6.4) with a single, version-controlled execution environment
+
 ## 7. Release & Distribution Model
 
 ### Open Source Release Pipeline
@@ -192,6 +208,7 @@ LUNA Charts targets modern web environments.
 - Single-package distribution model
 - No plugin or extension system
 - Multi-layer testing strategy with release gating
+- Containerized, reproducible test execution environment for browser and accessibility tests
 - Open-source distribution via GitHub and npm
 - Modern browser and mobile-first runtime strategy
 
@@ -224,3 +241,18 @@ This document reflects a refined Technology Architecture based on iterative arch
 - Distribution model defined as a single-package open-source release via npm and GitHub
 - Testing strategy defined as a multi-layer quality gate system (unit, accessibility, linting, visual regression)
 - Runtime scope restricted to modern browsers and mobile-first environments for performance and accessibility alignment
+
+### 2026-07-17 – Containerized test execution documented
+
+**Reason**
+
+Component and browser tests are executed inside a Docker-based Playwright environment (`Dockerfile.test`, `docker-compose.test.yaml`), which was introduced during implementation but had not yet been reflected in this document.
+
+**Changes**
+
+- Added Section 6.6 "Test Execution Environment" describing the containerized Playwright setup used for local development and CI
+- Added "Containerized, reproducible test execution environment" to Section 9 "Key Architectural Decisions"
+
+**Impact**
+
+This clarifies an already-implemented part of the testing strategy (Section 6) and does not change any other architectural decision in this document.

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

@@ -5,6 +5,7 @@ description: "Decision to use a pnpm-based monorepo structure for LUNA Charts."
 
 * **Status:** Accepted
 * **Date:** 2026-07-12
+* **Last Updated:** 2026-07-17
 * **Decision Makers:** LUNA Charts Maintainers
 
 ---
@@ -66,20 +67,23 @@ luna-charts/
 │
 ├── packages/
 │   └── luna-charts/
-│
-├── apps/
-│   ├── storybook/
-│   └── docs/
+│       └── .storybook/
 │
 ├── docs/
-│   ├── architecture/
-│   └── adr/
+│   └── src/content/docs/architecture/
+│       ├── adr/
+│       └── adm/
 │
 ├── examples/
 │
+├── .changeset/
+│
 └── .github/
 ```
 
+Storybook is not maintained as a separate app but lives directly inside the `packages/luna-charts` package, alongside the component source code it documents.
+The `docs/` workspace is not nested under an `apps/` directory; it is a top-level workspace built with Starlight, with architecture documentation (ADR and ADM) organized under `docs/src/content/docs/architecture/`.
+
 Internally, the library is organized into architectural modules such as:
 
 * Core
@@ -136,3 +140,25 @@ This structure supports the project's architecture-first approach and simplifies
 * LUNA Charts Architecture Wiki
 * ADR-0002: Technology Stack
 * pnpm Workspaces Documentation
+
+---
+
+## Change Log
+
+### 2026-07-17 – Repository structure diagram updated (removal of `apps/`)
+
+**Reason**
+
+The originally planned `apps/` workspace (containing `apps/storybook` and `apps/docs`) was never adopted in this form during implementation. Storybook was instead kept inside `packages/luna-charts` alongside the component source it documents, and the documentation workspace (`docs/`) was placed directly at the repository root rather than nested under `apps/`. The repository structure diagram in this ADR no longer matched the actual repository layout, while the Getting Started documentation (`project-structure.mdx`) already reflected the current structure.
+
+**Changes**
+
+* Removed the `apps/` directory (and its `storybook/` and `docs/` subentries) from the structure diagram
+* Corrected the `docs/` path to reflect the actual Starlight content location (`docs/src/content/docs/architecture/`)
+* Added the `adm/` folder to the diagram, alongside `adr/`, since Architecture Development Method documentation is stored there as well
+* Added `.changeset/` to the diagram, as it is a workspace-level configuration directory used for release management
+* Added a note clarifying that Storybook is maintained as part of the `packages/luna-charts` package rather than as a separate app
+
+**Impact**
+
+The overall decision (pnpm-based monorepo with logical workspace separation) is unaffected. Only the illustrative directory layout was corrected to match the implemented structure. No other ADRs are impacted by this change.

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

@@ -5,6 +5,7 @@ description: "Selection of the technology stack for LUNA Charts based on the TOG
 
 * **Status:** Accepted
 * **Date:** 2026-07-12
+* **Last Updated:** 2006-07-17
 * **Decision Makers:** LUNA Charts Maintainers
 
 ---
@@ -51,7 +52,7 @@ The following factors influenced the decision:
 | Component Documentation | Storybook, Styleguidist                         | **Storybook**      |
 | Project Documentation   | Docusaurus, VitePress, Starlight                | **Starlight**      |
 | Package Manager         | npm, Yarn, pnpm                                 | **pnpm**           |
-| Unit Testing            | Vitest, Jest                                    | **Jest**           |
+| Unit Testing            | Vitest, Jest                                    | **Vitest**         |
 | Browser Testing         | Cypress, Playwright                             | **Playwright**     |
 | Accessibility Testing   | Manual Testing Only, axe-core                   | **axe-core**       |
 | Code Formatting         | Manual Formatting, Prettier                     | **Prettier**       |
@@ -74,8 +75,8 @@ The following technology stack is adopted for the implementation of LUNA Charts.
 | **Starlight**      | Project and architecture documentation              |
 | **TypeScript**     | Strong typing and developer tooling                 |
 | **pnpm**           | Package management and workspace support            |
-| **Jest**           | Unit testing                                        |
-| **Playwright**     | Browser and interaction testing                     |
+| **Vitest**         | Unit testing and browser/component testing           |
+| **Playwright**     | Browser provider for Vitest browser mode             |
 | **axe-core**       | Accessibility validation                            |
 | **ESLint**         | Static code analysis                                |
 | **Prettier**       | Consistent code formatting                          |
@@ -128,15 +129,17 @@ pnpm Workspaces enable a modular repository structure while maintaining a single
 
 ---
 
-### Jest
+### Vitest
 
-Jest provides fast unit testing for business logic, utility functions, configuration handling, validation, and other non-browser-specific functionality.
+Vitest provides fast unit testing for business logic, utility functions, configuration handling, validation, and other non-browser-specific functionality.
+
+Vitest also serves as the single test runner for browser/component tests, using Playwright as its browser provider (`@vitest/browser-playwright`). This avoids maintaining two separate test runners and keeps unit and component testing under one consistent configuration and reporting workflow.
 
 ---
 
 ### Playwright
 
-Playwright validates component behavior inside real browsers.
+Playwright validates component behavior inside real browsers, running as the browser provider within Vitest's browser mode rather than as a standalone test runner.
 
 It is used to verify keyboard interaction, focus management, SVG rendering, and other browser-dependent accessibility features.
 
@@ -210,5 +213,26 @@ GitHub Actions automates testing, validation, and release workflows to ensure co
 * Storybook Documentation
 * Starlight Documentation
 * Playwright Documentation
-* Jest Documentation
+* Vitest Documentation
 * pnpm Documentation
+
+---
+
+## Change Log
+
+### 2026-07-17 – Unit Testing: Jest replaced with Vitest
+
+**Reason**
+
+During implementation, Jest was replaced with Vitest as the unit testing tool. Stencil's official Vitest integration (`@stencil/vitest`) allows unit tests and browser/component tests to run through a single test runner and configuration file, instead of maintaining Jest for unit tests and a separate Playwright test runner for browser tests. This reduces toolchain complexity and keeps testing configuration consistent across both test types.
+
+**Changes**
+
+* "Considered Alternatives" table: selected Unit Testing technology changed from **Jest** to **Vitest**
+* "Decision" table: **Jest** entry replaced with **Vitest**; **Playwright**'s purpose updated to reflect its role as the browser provider used by Vitest, not a standalone browser test runner
+* "Rationale" section: `Jest` subsection replaced with `Vitest`; `Playwright` subsection clarified to describe it as running inside Vitest's browser mode
+* "References": `Jest Documentation` replaced with `Vitest Documentation`
+
+**Impact**
+
+Playwright remains part of the technology stack, but its architectural role changes from an independent browser test runner to the browser engine used by Vitest. No other decisions in this ADR are affected.

pnpm-workspace.yaml

@@ -1,6 +1,5 @@
 packages:
   - "packages/*"
-  - "apps/*"
 
 allowBuilds:
   esbuild: false