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.
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.*¹
Establish all reusable architectural foundations required for chart implementation.
Type System
Public API Contracts
Rendering Foundation
Configuration Model
Validation Framework
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
This work package provides the reusable building blocks used by all future chart types.
Implement the first production-ready chart type and validate the architecture.
BarChart component
Rendering integration
Accessibility validation
Configuration integration
Validation integration
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
This work package acts as the architectural proof-of-concept for the entire solution.
Enable developers to successfully adopt and use LUNA Charts.
Getting Started Guides
Tutorials
API Documentation
Accessibility Guidance
Usage Examples
Developers can understand, integrate, and use LUNA Charts without requiring internal architectural knowledge.
Ensure product quality and reliable software delivery.
Unit Testing
Accessibility Testing
Linting
Visual Regression Testing
GitHub Release Pipeline
npm Publishing
All releases follow a repeatable and quality-controlled process.
Extend the library with additional chart implementations.
Examples include:
LineChart
PieChart
ScatterChart
Additional chart types may be introduced based on project priorities and community demand.
The chart ecosystem expands while reusing the foundations established in earlier work packages.
The implementation follows a staged approach.
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.
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.
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.
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.
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
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.