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/XuanchenLin/NanUI 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.

GO — Healthy across all four use cases

• Last commit 6mo ago
• 5 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Slowing — last commit 6mo ago
• ⚠ Single-maintainer risk — top contributor 96% of recent commits

_{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 XuanchenLin/NanUI repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/XuanchenLin/NanUI.

What it runs against: a local clone of XuanchenLin/NanUI — 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 XuanchenLin/NanUI | 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 ≤ 200 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of XuanchenLin/NanUI. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/XuanchenLin/NanUI.git
#   cd NanUI
#
# 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 XuanchenLin/NanUI and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "XuanchenLin/NanUI(\\.git)?\\b" \\
  && ok "origin remote is XuanchenLin/NanUI" \\
  || miss "origin remote is not XuanchenLin/NanUI (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 "NanUI.sln" \\
  && ok "NanUI.sln" \\
  || miss "missing critical file: NanUI.sln"
test -f "Directory.Build.props" \\
  && ok "Directory.Build.props" \\
  || miss "missing critical file: Directory.Build.props"
test -f ".github/workflows/main.yml" \\
  && ok ".github/workflows/main.yml" \\
  || miss "missing critical file: .github/workflows/main.yml"
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "NuGet.config" \\
  && ok "NuGet.config" \\
  || miss "missing critical file: NuGet.config"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 200 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~170d)"
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/XuanchenLin/NanUI"
  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).

NanUI is a .NET framework for building Windows desktop applications with HTML5, CSS3, and JavaScript UI rendered via the Chromium Embedded Framework (CEF) through Xilium.CefGlue bindings. It lets C# developers write business logic while using web technologies for the UI, directly addressing the gap between WinForms/WPF and modern web-based interfaces on Windows. Monolithic .NET solution (NanUI.sln) with primary C# codebase (~3.2MB), minimal JavaScript (11KB) and HTML (780B) in repo; heavy lifting is CEF interop. Directory structure separates docs/zh-CN (Chinese docs), artworks (branding), and the core NanUI source (not explicitly shown but inferred to be in root src/ or project folders). Build config via Directory.Build.props and NuGet.config.

.NET developers (C#) building Windows desktop applications who want modern, web-based UIs without learning WPF/UWP, and who prefer HTML/CSS/JavaScript for rapid UI iteration over traditional WinForms controls.

Actively developed with CI/CD via GitHub Actions (workflows/main.yml) and published to NuGet. Supports .NET 6+ and .NET Framework 4.6.2+. Mature enough for production (Windows 7 SP1+ support), though the codebase shows it's maintained by a single primary author (XuanchenLin); recent activity visible but with a noted alternative (WinFormedge) suggesting the author is evolving the approach.

Single-maintainer project with no visible test directory in the file list (only C# source and docs), raising coverage concerns. Hard dependency on CEF distribution and Xilium.CefGlue versioning creates external risk. No open PR/issue data visible, but the project explicitly recommends WebView2-based WinFormedge for new projects, hinting at CEF integration complexity and deployment size overhead (~125MB+).

Active maintenance with GitHub Actions workflows for CI/CD (workflows/main.yml). Recent updates suggest refinement of the CEF integration and .NET version support (6.0, 7.0, 8.0 mentioned). The CHANGELOG and docs indicate ongoing feature work around window styles (KIOSK modes, backdrop types, drop shadows, transparency) and JavaScript-to-.NET interop.

git clone https://github.com/XuanchenLin/NanUI.git
cd NanUI
cd NanUI.sln  # Open in Visual Studio 2019+ or use dotnet cli
dotnet build NanUI.sln

Restore NuGet packages via NuGet.config or Visual Studio package restore. No yarn/npm step needed (minimal web assets in repo).

Daily commands: Open NanUI.sln in Visual Studio 2019+ and build. No dev server; this is a compiled desktop app framework. Run examples by building example projects (not visible in file list but standard for framework repos). Deployment requires CEF redistribution (~100MB+) alongside .NET runtime.

• NanUI.sln — Solution file defining all projects and their dependencies; essential for understanding the complete build structure and project organization.
• Directory.Build.props — Central MSBuild configuration for all projects; controls versioning, dependencies, and compilation settings across the entire codebase.
• .github/workflows/main.yml — CI/CD pipeline definition; shows how the project is built, tested, and published automatically on every commit.
• README.md — Primary documentation explaining NanUI's purpose, capabilities, and architecture as a CEF-based HTML/CSS/JavaScript bridge for WinForms.
• NuGet.config — NuGet feed configuration; critical for resolving managed dependencies and CEF runtime packages during build.
• .github/FUNDING.yml — Sponsorship and funding configuration; indicates project maintenance model and community support channels.

• WinForm Host — undefined

Create a New WinForms Application with NanUI

1. Review the project structure and dependencies in the solution file (NanUI.sln)
2. Follow the getting started guide for application creation (docs/GettingStarted/Complie-WinFormium.md)
3. Configure startup properties and CEF runtime in your application (docs/Configuration/Startup.md)
4. Design your UI using HTML/CSS and bind it with JavaScript (docs/Forms/Form-JavaScript-Guide.md)

Configure Form Styling and Appearance

1. Review available form styles (system, borderless, transparent, KIOSK, etc.) (docs/Forms/Overview.md)
2. Select backdrop effects (acrylic, mica, surface, etc.) from the style documentation (docs/Forms/Transparency-Style-Forms.md)
3. Configure drop shadow effects using the documented presets (docs/Forms/System-Style-Forms.md)
4. Apply control-specific styling via CSS and control style configuration (docs/Forms/Control-Style.md)

Set Up Resource Embedding and Mapping

1. Understand resource types (embedded, local, data, proxy-mapped) and their use cases (docs.zh-CN/资源/概述.md)
2. Configure embedded file resources with proper build action in project properties (docs.zh-CN/资源/嵌入式文件资源.md)
3. Set up proxy mapping for dynamic resource loading and serving (docs.zh-CN/资源/代理映射资源.md)
4. Verify resource accessibility in your application manifest (docs/Configuration/App-Manifest.md)

Enable JavaScript-to-.NET Interoperability

1. Review JavaScript binding fundamentals and interop concepts (docs/Forms/Form-JavaScript-Guide.md)
2. Register .NET objects for access from JavaScript code (docs.zh-CN/JavaScript/在JavaScript中注册.NET映射对象.md)
3. Expose form-level JavaScript bindings for window control and events (docs.zh-CN/JavaScript/注册JavaScript窗体绑定对象.md)
4. Implement browser features (console, DevTools, etc.) as needed (docs/Forms/Browser-Features.md)

• Chromium Embedded Framework (CEF) via Xilium.CefGlue — Provides full Chromium browser engine within WinForms; enables modern HTML5/CSS3/JavaScript UI without building custom rendering pipeline
• .NET (C#) with WinForms — Leverages Windows native interop capabilities and mature .NET ecosystem; allows seamless JS-to-.NET marshaling and desktop integration
• HTML5, CSS3, JavaScript — Web-standard UI development; developers can use modern frontend frameworks and design patterns in desktop applications
• GitHub Actions (CI/CD) — Automated build validation and NuGet package publishing; ensures quality gates and continuous delivery

• Embedded Chromium runtime instead of native Windows UI

  • Why: Provides visual consistency, modern web stack familiarity, and rapid iteration for UI developers
  • Consequence: Larger application footprint and higher memory usage compared to pure WinForms; dependency on CEF distribution and updates

• Full JavaScript-to-.NET interop bridge via marshaling

  • Why: Eliminates friction between web frontend and .NET backend; enables seamless data binding and async operations
  • Consequence: Adds serialization/deserialization overhead; potential for security vulnerabilities if untrusted input is passed across bridge

• Multi-project solution (core + samples + docs)

  • Why: Modular structure allows independent versioning, testing, and documentation
  • Consequence: Increased build complexity; requires coordination across projects when making breaking changes

• Dual-language documentation (English + Chinese)

  • Why: Serves both global and Chinese-speaking developer communities
  • Consequence: Documentation maintenance burden doubles; risk of divergence between versions

• Cross-platform UI framework (Windows-only via WinForms & CEF on Windows)
• Mobile application development
• Real-time collaborative editing or WebSocket streaming (not mentioned in docs)
• Native performance parity with pure C++/Win32 applications
• Support for older browsers or IE fallback rendering

CEF redistribution: Applications require libcef DLLs (~100MB+) packaged separately; this is not automatic and must be configured in your app's deployment. Windows-only: Will not build/run on Linux or macOS despite being .NET (hard OS dependency in CEF). Version constraints: Windows 7 SP1 support ends at specific .NET versions (6.0+); Windows 10+ allows 7.0/8.0; ensure target framework matches your OS requirement. Build dependencies: Xilium.CefGlue version must align with your CEF binary version; mismatch causes interop failures. No embedded dev tools: Unlike standalone Electron, you must manually set up Chrome DevTools if needed for debugging.

• Chromium Embedded Framework (CEF) — NanUI's entire rendering engine is CEF; understanding its architecture (process model, message routing, memory model) is essential for debugging UI issues and deployment.
• P/Invoke and COM Interop — NanUI uses Windows API calls via P/Invoke (e.g., for window styling, transparency, backdrop effects) and CEF's COM-like interfaces; essential for understanding how C# calls native code.
• Message Loop and Event Routing — CEF and WinForms both use message loops; NanUI must synchronize them to prevent deadlocks and ensure events flow correctly between JavaScript, C#, and Windows.
• DirectComposition and DWM (Desktop Window Manager) — Modern window effects (Mica, Acrylic backdrops, drop shadows) in NanUI leverage DirectComposition; understanding DWM is needed to debug transparency and composition issues.
• JavaScript-to-.NET Marshalling — NanUI's core feature; JavaScript objects must be serialized and passed to C# methods (and vice versa); understanding serialization format and type mapping prevents binding bugs.
• Application Packaging and CEF Redistribution — Unlike managed-only .NET apps, NanUI apps require CEF binaries (~100MB) to be packaged separately; deployment strategy directly affects installer size and user experience.
• Frameless Windows and Hit Testing — NanUI supports frameless windows (无标题栏窗体); requires custom hit testing to detect draggable areas and window edges — a common source of UX bugs.

• XuanchenLin/WinFormedge — Official lightweight alternative using WebView2 instead of CEF; ~36MB vs 125MB+, but Windows 10+ only — same author's modern recommendation.
• cefsharp/CefSharp — Alternative CEF .NET wrapper with more active development and community; higher-level than Xilium.CefGlue but heavier than NanUI.
• ElectronNET/Electron.NET — Similar concept (desktop apps with web tech) but wraps Electron instead of CEF; cross-platform but larger footprint.
• xilium/xilium.cefglue — Upstream dependency; the .NET CEF wrapper that NanUI builds upon — critical for understanding interop and CEF versioning.
• chromiumembedded/cef — Root dependency (Chromium Embedded Framework); understanding CEF versioning and APIs helps debug low-level issues.

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 English documentation for JavaScript integration features

The repo has comprehensive Chinese docs (docs.zh-CN/JavaScript/) covering .NET object mapping and form binding, but no equivalent English documentation. This is critical for non-Chinese developers trying to use NanUI's JavaScript-to-.NET interop features. The README.md is incomplete (cuts off mid-sentence), making onboarding difficult for English speakers.

• [ ] Create docs/JavaScript/ directory structure mirroring docs.zh-CN/JavaScript/
• [ ] Translate and expand: 在JavaScript中注册.NET映射对象.md, 注册JavaScript窗体绑定对象.md, and 概述.md into English docs/JavaScript/ files
• [ ] Add code examples showing .NET object registration and JavaScript binding in English docs
• [ ] Update README.md with links to JavaScript integration documentation and complete the truncated section

Add GitHub Actions workflow for NuGet package validation and automated versioning

The repo has main.yml CI workflow but doesn't validate NuGet package metadata or automate package versioning. Since NanUI is published to NuGet (shown in badges: netdimension.nanui), adding automated validation would catch packaging issues early and enable semantic versioning from git tags.

• [ ] Examine Directory.Build.props and NuGet.config to identify version management strategy
• [ ] Create .github/workflows/nuget-validation.yml to run 'dotnet pack' and validate package contents on PR
• [ ] Add version extraction from git tags (v*.. format) and inject into build properties
• [ ] Add workflow step to push to NuGet.org on release tag creation, with credential management via GitHub secrets

Create comprehensive Windows platform compatibility test suite

NanUI is a Windows desktop framework handling window styles (KIOSK, titleless, borderless, transparent), backdrop effects (Mica, Acrylic), and subprocess management. The docs reference these features extensively but there are no visible unit or integration tests. A test suite would ensure cross-version Windows compatibility (Win10/Win11 API differences in backdrop types).

• [ ] Create src/NanUI.Tests/ directory with xUnit project for core window styling
• [ ] Add tests for window backdrop type initialization (docs.zh-CN/窗体/backdrop-type-*.md features) covering Win10/Win11 behavior differences
• [ ] Add integration tests for subprocess browser mode (docs.zh-CN/配置应用/使用子进程.md) validating process lifecycle
• [ ] Add tests for transparent window style edge cases (docs.zh-CN/窗体/transparency-style-exclude-border-area.png scenario)

• issue: Add unit test coverage for C# interop layer under test/ directory (e.g., JavaScript-to-.NET method marshalling); currently no tests visible in repo structure.
• issue: Expand English documentation in docs/ (currently minimal compared to docs.zh-CN/); translate and supplement 窗体 (window styling) guides and JavaScript binding examples.
• issue: Create example app demonstrating KIOSK window style with backdrop types (Mica, Acrylic); docs exist but no runnable example in examples/ folder visible.

NanUI presents moderate-to-high security risks primarily due to its architecture as a browser-to-.NET inter

• High · Chromium Embedded Framework (CEF) Supply Chain Risk — Project dependencies (Xilium.CefGlue wrapper). NanUI is built on top of Xilium.CefGlue, which wraps Chromium Embedded Framework. CEF is a complex, large codebase that requires regular security updates. The project structure doesn't show explicit version pinning or update mechanisms documented, which could lead to using outdated CEF versions with known vulnerabilities. Fix: Implement a documented process for regularly updating CEF and CefGlue dependencies. Use version pinning with explicit security update tracking. Consider adding dependency scanning CI/CD checks to alert on CVEs.
• High · HTML/JavaScript Execution in Embedded Browser — Core framework architecture - browser rendering engine. NanUI allows developers to build Windows desktop applications with HTML, CSS, and JavaScript executed in an embedded Chromium browser. This creates significant XSS and injection attack surface if user input is not properly sanitized before rendering in the browser context. Fix: Provide secure coding documentation and examples. Enforce Content Security Policy (CSP) by default. Implement input validation and output encoding libraries in the framework. Add security warnings in documentation about XSS prevention.
• High · JavaScript-to-.NET Bridge Security — docs.zh-CN/JavaScript/在JavaScript中注册.NET映射对象.md and related interop mechanisms. The documentation references 'registering .NET mapped objects' and 'JavaScript window binding objects' (docs.zh-CN/JavaScript/). This creates a JavaScript-to-.NET interop bridge that, if not properly secured, could allow JavaScript code to invoke arbitrary .NET methods with elevated privileges. Fix: Implement strict whitelist-based method exposure. Use explicit decoration/attributes to mark only safe methods for JavaScript access. Add authentication/authorization checks on all interop calls. Document security best practices for bridge methods.
• Medium · Missing Dependency Lock File Information — NuGet.config, Directory.Build.props. The NuGet.config file is present but no detailed lock file (packages.lock.json) information is visible in the repository structure. Without explicit version pinning, transitive dependencies could pull in vulnerable versions. Fix: Enable and commit packages.lock.json to ensure reproducible builds and explicit tracking of all dependency versions. Use NuGet restore with --locked-mode in CI/CD pipelines.
• Medium · Embedded Resource Security — docs.zh-CN/资源/嵌入式文件资源.md. Documentation references 'embedded resource build action' for including resources in the application. Sensitive files (credentials, API keys, certificates) could be accidentally embedded and exposed in compiled assemblies. Fix: Add security guidelines to documentation warning against embedding secrets. Implement resource scanning in build process to detect potential secrets. Use secure configuration management for sensitive data.
• Medium · CEF Subprocess Configuration — docs.zh-CN/配置应用/使用子进程.md and docs/Configuration/Subprocess.md. Documentation references subprocess configuration options. Improperly configured CEF subprocesses could allow privilege escalation or sandbox escape attacks. Fix: Document security best practices for subprocess configuration. Enforce strict sandbox policies. Implement process isolation and capability restrictions. Validate all subprocess arguments.
• Low · Limited Visible Security Controls — Repository root and documentation structure. From the file structure, no explicit security-related documentation files are visible (e.g., SECURITY.md, security guidelines). Security considerations may not be adequately addressed in user-facing documentation. Fix: Create a SECURITY.md file documenting security considerations, responsible disclosure process, and security best practices. Add security section to main README.md files.
• Low · No Visible SBOM or Security Audit Trail — Repository root. No evidence of Software Bill of Materials (SBOM), security audit reports, or vulnerability disclosure history in the visible repository structure. Fix: Generate and maintain SBOM using tools like CycloneDX or SPDX. Publish security audit reports if conducted. Maintain a public vulnerability disclosure process.

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.