If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/Live-Charts/LiveCharts2 shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Single-maintainer risk — review before adopting

• Last commit today
• 2 active contributors
• MIT licensed
• CI configured
• ⚠ Small team — 2 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 98% of recent commits
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live Live-Charts/LiveCharts2 repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/Live-Charts/LiveCharts2.

What it runs against: a local clone of Live-Charts/LiveCharts2 — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in Live-Charts/LiveCharts2 | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 30 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of Live-Charts/LiveCharts2. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/Live-Charts/LiveCharts2.git
#   cd LiveCharts2
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of Live-Charts/LiveCharts2 and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "Live-Charts/LiveCharts2(\\.git)?\\b" \\
  && ok "origin remote is Live-Charts/LiveCharts2" \\
  || miss "origin remote is not Live-Charts/LiveCharts2 (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "LiveCharts.slnx" \\
  && ok "LiveCharts.slnx" \\
  || miss "missing critical file: LiveCharts.slnx"
test -f "Directory.Build.props" \\
  && ok "Directory.Build.props" \\
  || miss "missing critical file: Directory.Build.props"
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f ".github/workflows/livecharts.yml" \\
  && ok ".github/workflows/livecharts.yml" \\
  || miss "missing critical file: .github/workflows/livecharts.yml"
test -f "CONTRIBUTING.md" \\
  && ok "CONTRIBUTING.md" \\
  || miss "missing critical file: CONTRIBUTING.md"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 30 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~0d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/Live-Charts/LiveCharts2"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

LiveCharts2 is a cross-platform .NET charting library that renders beautiful, interactive charts, maps, and gauges across 10+ UI frameworks (WPF, WinUI, Avalonia, MAUI, Blazor WASM, UNO Platform, WinForms, Xamarin.Forms, Eto Forms, UWP) using a unified API. It solves the fundamental design limitation of v0 (which was WPF-specific) by decoupling core chart rendering logic from platform-specific UI implementations. Monorepo using .slnx (layered solutions): core abstraction in src/live-charts.core (rendering engine, data models), platform-specific bindings in src/live-charts.{wpf,winui,avalonia,maui,etc.}, test suites in LiveCharts.Tests.slnx, and shared build props in /build directory. Shared code linked via Directory.Build.props and XamlSharedLinks.Build.props (see build/SharedLinks.Build.props, build/XamlSharedLinks.Build.props).

.NET developers building data visualization dashboards across heterogeneous platforms—from desktop apps (WPF/WinUI) to mobile (MAUI/Xamarin) to web (Blazor WASM)—who need production-grade charting without reimplementing visualization logic per platform. Also useful for server-side chart generation in console or ASP.NET apps.

Production-ready with active maintenance: the project has proper CI/CD (.github/workflows/livecharts.yml), line coverage badges, NuGet distribution (documented 'downloads' badge), and supports 10 UI platforms. The shift from v0 (WPF-only) to v2 (multi-platform) indicates a mature architectural redesign, though the v2.0 README notes it was 'beta' at time of writing.

Standard open source risks apply.

Active feature work and platform support: CI pipelines include benchmarks.yml, claude.yml (for AI-assisted development), PR automation, and multi-platform test runners. The .claude/skills/repro-and-fix/SKILL.md suggests ongoing structured debugging/fixing workflows. GitHub actions for dotnet workload setup (setup-dotnet-and-workloads/action.yml) indicates recent platform SDK updates.

git clone https://github.com/Live-Charts/LiveCharts2.git && cd LiveCharts2 && dotnet restore LiveCharts.slnx && dotnet build LiveCharts.slnx. For a specific platform, use dotnet build LiveCharts.WPF.slnx (or .Avalonia, .Maui, etc.). Tests: dotnet build LiveCharts.Tests.slnx && dotnet test.

Daily commands: Select target platform and run: dotnet run -p src/live-charts.{wpf,avalonia,maui,blazor,etc}. For web demo: see docs for Blazor WASM setup (hosted at blazor-livecharts.controli.app). Local samples likely in examples/ or src/samples directories (not visible in file list, but standard structure).

• LiveCharts.slnx — Root solution file that orchestrates all platform-specific implementations and core libraries; essential for understanding the multi-platform architecture.
• Directory.Build.props — Shared build configuration for the entire monorepo; defines versioning, dependencies, and compilation settings across all projects.
• README.md — Primary documentation entry point describing LiveCharts2's positioning as a cross-platform charting library and its evolution from v0.
• .github/workflows/livecharts.yml — Main CI/CD pipeline defining test execution, build steps, and deployment logic for all platform targets.
• CONTRIBUTING.md — Contributor guidelines establishing development workflow, code standards, and submission requirements for the multi-platform codebase.
• .github/copilot-instructions.md — AI-assisted development instructions providing context on repo structure, conventions, and common patterns for this specific codebase.
• build/SharedLinks.Build.props — Core build property linking shared source files across platform implementations, enabling code reuse without duplication.

Add Support for a New Chart Type

1. Create the core chart model in the shared library implementing the base chart interface with data binding and layout logic (build/SharedLinks.Build.props (reference the core package))
2. Implement renderer adapters for each platform (WPF, WinUI, Avalonia, etc.) that translate the model to platform-specific drawing calls (LiveCharts.WPF.slnx (repeat for other frameworks))
3. Add series configuration and builder API to enable fluent chart definition (build/SharedLinks.Build.props)
4. Create unit tests validating layout, data binding, and animation behavior across platforms (LiveCharts.Tests.slnx)
5. Add visual documentation and example assets demonstrating the new chart type (docs/_assets)

Add a New Platform Target (e.g., new UI framework)

1. Create a new .slnx solution file for the platform following the naming pattern LiveCharts.{Framework}.slnx (LiveCharts.WPF.slnx (use as template))
2. Create platform-specific binding and renderer implementations that consume shared chart core via SharedLinks.Build.props (build/SharedLinks.Build.props)
3. Add platform-specific build properties and native links if needed (e.g., WinUISharedLinks.Build.props for WinUI) (build/WinUISharedLinks.Build.props (use as reference template))
4. Integrate the new platform into the main CI/CD pipeline and test matrix (.github/workflows/livecharts.yml)
5. Update Directory.Build.props to include the new platform's NuGet metadata and version (Directory.Build.props)

Implement a New Animation or Easing Function

1. Define the animation/easing model in the shared core library following existing patterns (build/SharedLinks.Build.props (reference core))
2. Create easing curve or animation timing class implementing the base animation interface (build/SharedLinks.Build.props)
3. Write unit tests validating timing values and interpolation across animation frames (LiveCharts.Tests.slnx)
4. Add visual demonstration GIF or example chart to the documentation showing the animation in action (docs/_assets)

• .NET (multi-targeted: .NET 6/7/8, .NET Framework 4.7.2, netstandard2.1) — Enables single codebase to run on desktop (WPF, WinForms, WinUI), mobile (MAUI), web (Blazor), and cross-platform (Avalonia, Uno) with platform-specific optimizations.
• Shared Source Pattern (SharedLinks.Build.props) — Allows core charting logic to be reused without dll dependencies, eliminating circular refs and enabling tight framework integration for each platform.
• GitHub Actions CI/CD — Provides native integration for multi-platform testing, enables matrix builds across Windows/Linux/macOS, and simplifies NuGet publish automation.
• SVG/Direct Drawing APIs (per-platform) — Abstracts rendering to platform-native systems (DirectX for WinUI, GDI+ for WinForms, SkiaSharp for Avalonia/MAUI, Canvas for Blazor) for optimal performance and visual fidelity.

• Shared source via build links vs. separate NuGet core library

  • Why: Avoids version mismatch issues, reduces assembly bloat, and allows per-platform optimizations without forking code; trade-off is more complex build configuration.
  • Consequence: Build process is more intricate (SharedLinks.Build.props, platform-specific .Build.props files); easier to accidentally break multiple platforms simultaneously.

• One API across all platforms rather than framework-native idioms

  • Why: Reduces learning curve and enables code reuse when switching frameworks; maximizes target audience.
  • Consequence: Some platform-specific capabilities are hidden or require custom extensions; not always the most idiomatic per framework.

• SLNX (VS solution explorer XML) format instead of .sln

  • Why: Modern solution format with improved source control diff readability and better IDE performance.
  • Consequence: Requires VS 2022.1+ or newer tooling; older tooling won't recognize the projects.

• Real-time data streaming / live WebSocket updates (charts are reactive to data changes, not pub/sub)
• 3D chart rendering (2D only; 3D would require significant renderer rewrites per platform)
• Built-in database persistence (charts consume in-memory collections; data storage is caller's responsibility)
• Platform-native accessibility features beyond OS defaults (some WCAG compliance, but not primary goal)

1. SkiaSharp is hardcoded as drawing abstraction; replacing it requires changes to all platform layers. 2) .slnx (new solution format) may require Visual Studio 2022+; older tooling won't parse it. 3) Each platform solution (LiveCharts.WPF.slnx, LiveCharts.Avalonia.slnx, etc.) has independent NuGet package references—version drift can cause subtle bugs across platforms. 4) Shared code linked via .Build.props files means renaming/moving source files breaks all platform projects silently; no central index. 5) The public demo (blazor-livecharts.controli.app) is desktop-only; mobile browser rendering untested in CI.

• Platform Adapter Pattern — LiveCharts2 decouples core chart logic from UI frameworks via adapters (one per platform: WPF, Avalonia, MAUI, etc.); understanding this pattern is essential to contributing platform-specific features or adding a new platform.
• Immediate-Mode Graphics (via SkiaSharp) — LiveCharts2 uses SkiaSharp's immediate-mode drawing (draw-each-frame) rather than retained-mode scene graphs; this impacts performance tuning, animation frame rates, and why the demo targets desktop-only.
• Monorepo with Shared Source Linking — Code is shared across platform projects via .Build.props files (SharedLinks.Build.props, XamlSharedLinks.Build.props) rather than NuGet packages; this requires understanding how MSBuild link semantics work to avoid circular dependencies or stale copies.
• Data-Driven Reactivity for Real-Time Charts — LiveCharts2 is optimized for streaming data (real-time updates) across platforms; understanding observable collections, change notification patterns, and frame-rate throttling is critical for high-frequency chart updates.
• Cross-Platform XAML Unification — WPF, WinUI, and Avalonia share XAML syntax but differ in namespace/API details; LiveCharts2 unifies them via conditional compilation and linked source files, avoiding duplication while preserving platform idioms.
• Geometric Transformations and Scaling — Charts must scale axes, labels, and glyphs across varied screen sizes and DPI; LiveCharts2 implements custom transformation logic in the core layer; understanding matrix math and coordinate spaces is essential for debugging rendering bugs.
• Build-Time Dependency Injection via MSBuild — Directory.Build.props and platform-specific .csproj files use MSBuild to inject platform-specific implementations; this differs from runtime DI and requires understanding MSBuild's property evaluation order.

• OxyPlot/oxyplot — Direct alternative multi-platform charting library for .NET; similar goal (cross-platform charts) but uses different rendering backend and predates LiveCharts2's architecture redesign.
• SciChart/SciChart.Wpf.Examples — Premium commercial charting for WPF/WinUI; LiveCharts2 is the open-source competitor for .NET developers seeking cost-free multi-platform charting.
• SkiaSharp/SkiaSharp — Core dependency for LiveCharts2's rendering abstraction; understanding SkiaSharp's API and limitations is essential for modifying chart rendering logic.
• microsoft/maui — MAUI is one of 10 supported platforms; LiveCharts2 includes live-charts.maui bindings and shares MAUI's dependency ecosystem.
• Live-Charts/Live-Charts — Predecessor (v0) of LiveCharts2; architectural predecessor that motivated the multi-platform redesign; useful for migration guides.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive unit tests for core charting math in src/drawing and src/measure modules

LiveCharts2 is a data visualization library where rendering accuracy is critical. The file structure shows multiple framework implementations (WPF, WinUI, Blazor, Avalonia, MAUI, Uno, WinForms) but the partial file list doesn't show dedicated unit tests for core mathematical operations (coordinate transforms, axis scaling, data normalization). This is high-value because: (1) bugs in core math affect all 7+ UI frameworks simultaneously, (2) visual correctness is harder to test than logic correctness, (3) new contributors can add value immediately without deep framework knowledge.

• [ ] Review src/drawing and src/measure directories to identify core math functions lacking test coverage
• [ ] Create LiveCharts.Tests/Drawing/MathTests.cs for coordinate transformation functions
• [ ] Create LiveCharts.Tests/Measure/AxisScalingTests.cs for axis normalization and scaling logic
• [ ] Add test cases for edge cases: zero ranges, negative values, extreme aspect ratios, NaN/Infinity handling
• [ ] Ensure tests run in LiveCharts.Tests.slnx solution

Add missing GitHub Actions workflow for cross-framework integration tests

The repo has LiveCharts.slnx (core) and 7 framework-specific solutions (.slnx files), but looking at .github/workflows/, there's likely no unified cross-framework test runner. Currently visible workflows are: auto-rerun.yml, benchmarks.yml, claude.yml, livecharts.yml, pr-comment.yml, publish.yml. High-value because: (1) ensures changes to core don't break any of the 7 frameworks, (2) prevents siloed testing where a PR passes core tests but breaks WinUI, (3) integrates naturally with existing workflow infrastructure.

• [ ] Audit .github/workflows/livecharts.yml to see which framework solutions are currently tested
• [ ] Create .github/workflows/test-all-frameworks.yml that runs: dotnet test LiveCharts.WPF.slnx, LiveCharts.WinUI.slnx, LiveCharts.Blazor.slnx, etc.
• [ ] Add matrix strategy to parallelize testing across frameworks
• [ ] Update .github/ISSUE_TEMPLATE/bug_report.md to ask which framework(s) are affected
• [ ] Document expected test coverage in CONTRIBUTING.md

Create API documentation for Painting and Styling system with code examples

The file structure shows docs/_assets/ with visual examples (axes-paints.png, bars-*.gif) but no corresponding API documentation in docs/ for how to use the painting/styling system. This is high-value for new contributors because: (1) visual customization is a major LiveCharts feature (colors, animations, brushes), (2) docs/_assets/ suggests documentation was planned but not completed, (3) adding docs helps contributors understand the architecture before modifying it, (4) reduces duplicate 'how to style' GitHub issues.

• [ ] Review src/ for Brush, Paint, Animation, and Style classes/interfaces
• [ ] Create docs/api/painting-and-styling.md with sections: Brushes, Paints, Animations, Custom Styles
• [ ] Add 3-5 runnable code examples for each major feature (reference docs/_assets/axes-paints.png, bars-bounce.gif, etc.)
• [ ] Link to framework-specific examples: docs/frameworks/wpf-styling.md, docs/frameworks/blazor-styling.md, etc.
• [ ] Add before/after visual examples showing style application

• Add unit tests for edge cases in chart data validation (e.g., null series, empty data arrays, negative axes). The test repo exists but likely lacks exhaustive coverage given 10 platform targets and complex rendering pipeline.
• Extend platform adapter documentation: create platform-specific 'how to implement a new chart type' guides for Avalonia and MAUI in docs/, mirroring existing WPF/WinUI examples. This reduces friction for contributors adding new chart variants.
• Profile and document SkiaSharp rendering performance on mobile platforms (MAUI/UNO); add benchmarks to .github/workflows/benchmarks.yml for 60fps compliance. Mobile perf is currently unmeasured based on visible CI config.

The LiveCharts2 repository shows a generally good security posture with proper use of GitHub Actions and documented contribution guidelines. However, the presence of a Strong Name Key file (LiveCharts.snk) in version control is a notable concern, as it may contain private cryptographic material. Additionally, the absence of a SECURITY.md policy document and the need for auditing workflow files and build configurations to ensure no hardcoded secrets are present represent moderate improvements areas. The codebase appears to be a charting library focused on UI rendering rather than data processing, which reduces injection attack vectors. No obvious SQL injection or XSS vulnerabilities are apparent from the file structure alone.

• Medium · Potential Exposed Signing Key — LiveCharts.snk. The file 'LiveCharts.snk' is present in the repository root. SNK (Strong Name Key) files contain cryptographic keys used for assembly signing. If this is a private key, it should never be committed to version control as it could be used to forge assemblies. Fix: Remove the SNK file from the repository and add it to .gitignore. Store the signing key securely in a CI/CD secrets manager or key vault. Update the build process to retrieve it from secure storage during the build pipeline.
• Low · GitHub Actions Token Exposure Risk — .github/workflows/. Multiple GitHub workflow files (.github/workflows/*.yml) are present. While the files themselves appear to be configuration, workflows often contain secrets passed through environment variables or action contexts. Ensure no hardcoded secrets are present in workflow definitions. Fix: Audit all workflow files to ensure secrets are only referenced via GitHub Secrets (e.g., ${{ secrets.TOKEN }}). Never hardcode API keys, tokens, or credentials directly in workflow YAML files.
• Low · Missing SECURITY.md Policy — Repository root. No SECURITY.md file is visible in the repository structure. This file typically contains information about reporting security vulnerabilities responsibly, which is important for coordinating security disclosures. Fix: Create a SECURITY.md file following GitHub's recommended format. Include clear instructions for reporting security issues privately and a response timeline commitment.
• Low · Potential Sensitive Information in Build Properties — Directory.Build.props, build/ directory. Build configuration files (Directory.Build.props, build/*.Build.props) may contain sensitive information or allow unsafe operations if not properly reviewed. Fix: Review all build property files to ensure they don't contain hardcoded credentials, API keys, or unsafe build configurations. Use secure build parameters instead.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.