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/Richasy/Bili.Uwp 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 — Stale — last commit 3y ago

• 9 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 3y ago
• ⚠ Single-maintainer risk — top contributor 90% 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 Richasy/Bili.Uwp repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/Richasy/Bili.Uwp.

What it runs against: a local clone of Richasy/Bili.Uwp — 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 Richasy/Bili.Uwp | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | Last commit ≤ 952 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "Richasy/Bili.Uwp(\\.git)?\\b" \\
  && ok "origin remote is Richasy/Bili.Uwp" \\
  || miss "origin remote is not Richasy/Bili.Uwp (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 main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

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

Bili.Uwp is a native Windows UWP application for Bilibili (a Chinese video platform) built with C# targeting Windows 10/11. It provides a third-party desktop client optimized for the new Windows 11 Fluent design system, offering video browsing, playback, comments, favorites, and live streaming features without relying on the web interface. Adapter-based monolith: src/Adapter/ contains interface definitions (Adapter.Interfaces/) and implementations (Adapter.Implementation/) for domain modules—VideoAdapter, PlayerAdapter, CommentAdapter, LiveAdapter, etc. Each adapter handles API-to-domain-model conversion. Unit tests sit alongside in Adapter.UnitTests/. Root solution files (Bili.Uwp.sln, Bili.Workspace.sln) and shared build props (Directory.Build.props, Uwp.props) suggest multi-project C# organization.

Windows developers maintaining UWP applications, Bilibili users on Windows 10/11 who want a native app experience instead of web access, and contributors interested in C# desktop application architecture with modern UI patterns.

The project has 2.7M lines of C# code and visible GitHub Actions CI/CD pipelines (release-builder.yml, release-drafter.yml), indicating active deployment infrastructure. However, the README prominently notes the successor project 'Bili.Copilot' is now preferred and will gradually replace this—suggesting this is in maintenance mode rather than active feature development. Production-ready but transitioning to successor.

Single-maintainer project (Richasy) with no recent commit visibility in the provided data—maturity status unclear. The project was removed from Microsoft Store due to name/feature conflicts with the official app, limiting distribution. Heavy coupling to Bilibili's undocumented API (inferred from adapter pattern) creates fragility if the platform changes endpoints. Dependency on UWP framework locks users to Windows ecosystem.

According to the README, active development has shifted to the Bili.Copilot successor project. This repository is in maintenance mode with no breaking changes expected. The CI pipeline (release-builder.yml) suggests automated builds for new commits, but the transition messaging indicates feature work is frozen here.

Clone: git clone https://github.com/Richasy/Bili.Uwp.git. Open Bili.Uwp.sln in Visual Studio 2019+ with UWP workload installed. Restore NuGet packages via nuget restore or Visual Studio's package manager. Build via Visual Studio or msbuild Bili.Uwp.sln. Deploy to local machine or emulator via Visual Studio's Debug/Deploy buttons.

Daily commands: Open Bili.Uwp.sln in Visual Studio → Select UWP project as startup → Press F5 or Debug → Start Debugging. For sideloaded deployment: unzip release package, run install.ps1 in PowerShell (admin mode) on Windows 10/11 with Developer Mode enabled.

• src/Adapter/Adapter.Interfaces/: Defines contracts for all domain adapters (IVideoAdapter, IPlayerAdapter, etc.)—understanding these contracts is essential before modifying implementations
• src/Adapter/Adapter.Implementation/VideoAdapter.cs: Core video fetching/listing logic—largest surface area for API changes and most likely source of Bilibili API integration issues
• Bili.Uwp.sln: Root solution file; required entry point for building and debugging the entire application in Visual Studio
• Directory.Build.props: Shared MSBuild properties across all projects—contains version numbers, common dependencies, and build flags for the entire workspace
• .github/workflows/release-builder.yml: Automated CI/CD pipeline; defines how releases are built and packaged for distribution
• src/Adapter/Adapter.UnitTests/ImageAdapterTests.cs: Example unit test pattern for adapters—reference this when adding tests for new features or bug fixes

For API handling changes: edit src/Adapter/Adapter.Implementation/{FeatureAdapter}.cs (e.g., VideoAdapter.cs for video logic). For UI changes: look in src/ for View/ViewModel pairs (inferred UWP MVVM). For cross-adapter shared logic: modify src/Adapter/Adapter.Interfaces/I{Feature}Adapter.cs first, then implementations. Add unit tests to src/Adapter/Adapter.UnitTests/ (see ImageAdapterTests.cs pattern).

UWP requires Developer Mode enabled on Windows 10/11 and specific PowerShell version (Windows PowerShell, not Core) for install.ps1—this is not obvious from the code. The Bilibili API is undocumented and reverse-engineered, so breaking changes on their side will silently break adapters without compiler warnings. Project removed from Microsoft Store means no automatic updates—users must manually re-sideload new releases. Build requires Visual Studio with UWP workload; minimal/Community editions may not include it by default.

• Adapter Pattern — This repo's entire architecture is built on adapters (VideoAdapter, PlayerAdapter, etc.) that convert Bilibili's API responses into domain models—understanding this pattern is essential to navigating src/Adapter/ and making API integration changes
• UWP (Universal Windows Platform) — The entire application framework; UWP provides sandboxing, app lifecycle management, and the XAML UI model that shape how this project is structured and deployed
• MVVM (Model-View-ViewModel) — Inferred architectural pattern in UWP apps; understanding MVVM binding, commands, and state management is necessary to modify the UI layer and connect adapters to views
• Sideloading (UWP) — Since the app was removed from Microsoft Store, sideloading is the only deployment method; understanding PowerShell install scripts and app package signing is required to build and distribute releases
• Reverse-Engineered API Integration — Bilibili's API is undocumented; all adapters rely on patterns discovered through network analysis, making this project fragile to API changes and requiring deep knowledge of how each endpoint is used
• GitHub Actions CI/CD — The release-builder.yml and release-drafter.yml pipelines automate builds and package distribution—modifying these is necessary to change deployment behavior or add pre-release validation
• C# Async/Await & Task-Based Asynchrony — UWP and .NET rely heavily on async patterns for network calls in adapters; understanding Task<T>, ConfigureAwait(), and cancellation tokens is essential for modifying API layers without deadlocks

• Richasy/Bili.Copilot — Official successor project—this repo explicitly states Bili.Copilot is gradually replacing Bili.Uwp; new features are being added there instead
• windows-uwp/Samples — Microsoft's official UWP samples and documentation—reference architecture patterns and MVVM best practices for Windows platform development
• SciresM/Hactool — Example of reverse-engineering undocumented APIs and building tooling around them—similar domain challenge to discovering Bilibili API contracts
• AvaloniaUI/Avalonia — Modern cross-platform C# UI framework alternative to UWP; relevant for contributors considering how to extend or migrate this architecture to other platforms
• dotnet/docs — Official .NET and C# documentation—essential reference for UWP patterns, async/await conventions, and XAML binding used throughout this project

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 Adapter.Implementation classes

The repo has minimal test coverage - only ImageAdapterTests.cs exists in src/Adapter/Adapter.UnitTests/, but 11 adapter implementations (ArticleAdapter, CommentAdapter, CommunityAdapter, DynamicAdapter, FavoriteAdapter, LiveAdapter, PgcAdapter, PlayerAdapter, SearchAdapter, UserAdapter, VideoAdapter) lack corresponding tests. This is critical for a public API layer that likely transforms Bilibili API responses.

• [ ] Create CommentAdapterTests.cs following the pattern of ImageAdapterTests.cs in src/Adapter/Adapter.UnitTests/
• [ ] Create VideoAdapterTests.cs with tests for video data transformation
• [ ] Create UserAdapterTests.cs and LiveAdapterTests.cs to cover high-traffic features
• [ ] Verify test project references are correctly set in Adapter.UnitTests.csproj
• [ ] Run dotnet test to ensure all new tests pass against Adapter.Implementation interfaces

Add CI workflow to run unit tests on pull requests

The repo has release-builder.yml and release-drafter.yml workflows but no automated test execution on PRs. Given the presence of test projects (Adapter.UnitTests, and references to UnitTests.targets), a test verification workflow would catch regressions early and enforce code quality standards for contributors.

• [ ] Create .github/workflows/test.yml that triggers on pull_request and push events
• [ ] Configure the workflow to run 'dotnet test' against Adapter.UnitTests.csproj
• [ ] Set the workflow to also execute tests from any test projects referenced in UnitTests.targets
• [ ] Add a required status check in GitHub branch protection to require test workflow to pass
• [ ] Test the workflow locally using act or by creating a draft PR

Create CONTRIBUTING.md with architecture guide for adapter pattern

The repo uses a clean adapter pattern (Adapter.Interfaces contracts + Adapter.Implementation implementations) but this architecture is undocumented. New contributors adding features don't have guidance on how to extend the adapter layer. README is currently minimal and lacks development setup instructions.

• [ ] Create CONTRIBUTING.md at repo root with development prerequisites (VS version, .NET SDK version from Directory.Build.props)
• [ ] Document the adapter pattern: explain why IVideoAdapter, ILiveAdapter interfaces exist separately from implementations
• [ ] Add a section showing how to add a new adapter (reference the existing adapter files like VideoAdapter.cs and IVideoAdapter.cs)
• [ ] Include the mono-repo structure explanation (why Bili.Uwp.sln vs Bili.Workspace.sln exist)
• [ ] Link to relevant issue templates and note the release-drafter workflow for changelog generation

• Add unit test coverage for CommentAdapter.cs and DynamicAdapter.cs (src/Adapter/Adapter.UnitTests/)—they lack test files like ImageAdapterTests.cs does, making them regression-prone
• Document the Bilibili API contract used by each adapter—create markdown files in docs/ mapping IVideoAdapter methods to actual API endpoints, since the API is reverse-engineered and undocumented
• Implement missing adapter tests for CommunityAdapter, FavoriteAdapter, and SearchAdapter by following the ImageAdapterTests.cs pattern and adding test fixtures

The Bili.Uwp UWP application presents a moderate security posture based on static structural analysis. The most concerning finding is the inclusion of a .pfx certificate file in the repository, which is a critical security practice violation. The lack of visible dependency information prevents comprehensive vulnerability assessment. The application's architecture (multiple adapters for third-party API integration) introduces potential attack surface that requires careful implementation. Recommended actions include: immediate removal of certificate files, implementation of automated dependency scanning, comprehensive code review of adapter implementations, and establishment of secure development practices for credential/certificate management.

• Medium · Hardcoded Certificate Key File — src/App/App_TemporaryKey.pfx. The presence of 'App_TemporaryKey.pfx' in the repository suggests a certificate key file may be tracked in version control. This file contains sensitive cryptographic material that should never be committed to a repository, even if it's temporary or for development. Fix: Remove the .pfx file from the repository immediately, add *.pfx to .gitignore, and rotate any exposed certificates. Use secure certificate management practices for code signing.
• Medium · Missing Dependency Verification — nuget.config and project dependencies. The dependency file content is empty/missing. Without visibility into NuGet package dependencies used by this UWP application, it's impossible to verify for known vulnerabilities, outdated packages, or malicious dependencies. Fix: Regularly audit NuGet dependencies using tools like 'dotnet list package --vulnerable', implement dependency scanning in CI/CD pipelines, and maintain up-to-date packages with security patches.
• Low · Generic API Adapter Pattern Risk — src/Adapter/Adapter.Implementation/. The project structure includes multiple adapter classes (ArticleAdapter, CommentAdapter, UserAdapter, etc.) that interact with the Bilibili API. Without reviewing the actual implementation, there's potential risk of improper input validation, insufficient output encoding, or insecure API communication. Fix: Implement strict input validation and output encoding in all adapter classes. Use parameterized requests for API calls. Validate and sanitize all user-provided data. Implement proper error handling that doesn't expose sensitive information.
• Low · Limited Code Review Visibility — All source files. Static analysis is limited to file structure and naming only. Critical security issues in implementation details (authentication, encryption, API communication) cannot be detected without reviewing actual source code. Fix: Perform manual code review focusing on: authentication mechanisms, cryptographic operations, API communication security, user data handling, and input validation. Conduct regular security audits and penetration testing.

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.