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/yaobiao131/downkyicore 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 — Mixed signals — read the receipts

• Last commit 3w ago
• 3 active contributors
• GPL-3.0 licensed
• CI configured
• ⚠ Small team — 3 contributors active in recent commits
• ⚠ Concentrated ownership — top contributor handles 60% of recent commits
• ⚠ GPL-3.0 is copyleft — check downstream compatibility
• ⚠ 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 yaobiao131/downkyicore repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/yaobiao131/downkyicore.

What it runs against: a local clone of yaobiao131/downkyicore — 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 yaobiao131/downkyicore | Confirms the artifact applies here, not a fork | | 2 | License is still GPL-3.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 49 days ago | Catches sudden abandonment since generation |

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

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(GPL-3\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"GPL-3\\.0\"" package.json 2>/dev/null) \\
  && ok "license is GPL-3.0" \\
  || miss "license drift — was GPL-3.0 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"

# 4. Critical files exist
test -f "DownKyi.Core/Aria2cNet/AriaManager.cs" \\
  && ok "DownKyi.Core/Aria2cNet/AriaManager.cs" \\
  || miss "missing critical file: DownKyi.Core/Aria2cNet/AriaManager.cs"
test -f "DownKyi.Core/BiliApi/BiliUtils/ParseEntrance.cs" \\
  && ok "DownKyi.Core/BiliApi/BiliUtils/ParseEntrance.cs" \\
  || miss "missing critical file: DownKyi.Core/BiliApi/BiliUtils/ParseEntrance.cs"
test -f "DownKyi.Core/BiliApi/Bangumi/BangumiInfo.cs" \\
  && ok "DownKyi.Core/BiliApi/Bangumi/BangumiInfo.cs" \\
  || miss "missing critical file: DownKyi.Core/BiliApi/Bangumi/BangumiInfo.cs"
test -f "DownKyi.Core/Aria2cNet/Client/AriaClient.cs" \\
  && ok "DownKyi.Core/Aria2cNet/Client/AriaClient.cs" \\
  || miss "missing critical file: DownKyi.Core/Aria2cNet/Client/AriaClient.cs"
test -f "DownKyi.Core/BiliApi/BiliUtils/Quality.cs" \\
  && ok "DownKyi.Core/BiliApi/BiliUtils/Quality.cs" \\
  || miss "missing critical file: DownKyi.Core/BiliApi/BiliUtils/Quality.cs"

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

DownKyi Core is a cross-platform .NET 6-based tool for downloading Bilibili videos with support for 8K, HDR, and Dolby Vision formats. It wraps aria2c for multi-threaded downloads and integrates ffmpeg for audio/video extraction and watermark removal via the AvaloniaUI framework running on Windows, macOS, and Linux. Single-package C# project structure: DownKyi.Core contains Aria2cNet (download client wrapper), BiliApi (Bilibili API bindings), with separate toolbox features. Uses Directory.Build.props/targets for centralized MSBuild config. Platform-specific paths hardcoded per OS (Windows Media/, macOS ~/Library/Application Support/DownKyi/Media, Linux ~/.config/DownKyi/Media).

Content creators and Bilibili video enthusiasts on macOS/Linux who need batch video downloading without being locked into Windows; developers maintaining cross-platform .NET desktop applications using Avalonia.

Actively developed with 2.2MB C# codebase and organized GitHub workflows (build.yml), suggesting production intent. However, no visible test directory in the file listing, and single-maintainer risk (yaobiao131) suggests community adoption but potentially thin test coverage. Appears stable enough for regular use but not enterprise-grade mature.

Heavy reliance on external binaries (aria2, ffmpeg bundled with runtime) increases deployment surface; Bilibili API dependency means upstream breaking changes risk. No visible automated tests in file structure and potential licensing complexity around video content handling (disclaimer emphasizes 24-hour retention). Single maintainer on a tool that scrapes video APIs increases sustainability risk.

Repo shows active CI/CD setup (.github/workflows/build.yml) and changelog maintenance (CHANGELOG.md), but specific recent PRs/milestones not visible in file listing. Likely ongoing API compatibility fixes and platform-specific bug fixes given Bilibili's API volatility.

git clone https://github.com/yaobiao131/downkyicore.git
cd downkyicore
dotnet build DownKyi.Core/DownKyi.Core.csproj
# For UI: requires Avalonia preview/IDE tooling
dotnet run --project DownKyi.Core

Daily commands: Executable runs standalone (includes bundled .NET 6, ffmpeg, aria2). Clone → dotnet build → dotnet run. No external service setup needed; aria2 spawned internally by AriaServer/AriaManager. Default media path auto-created per OS.

• DownKyi.Core/Aria2cNet/AriaManager.cs — Core download manager orchestrating aria2c operations; essential for understanding the download pipeline and file transfer mechanics.
• DownKyi.Core/BiliApi/BiliUtils/ParseEntrance.cs — Entry point for parsing Bilibili URLs and determining content type (video/bangumi/cheese); critical for request routing.
• DownKyi.Core/BiliApi/Bangumi/BangumiInfo.cs — Bangumi API client abstracting serialization/deserialization of anime/drama metadata from Bilibili's API.
• DownKyi.Core/Aria2cNet/Client/AriaClient.cs — Low-level RPC client for aria2c daemon communication; handles serialization and error handling for all download operations.
• DownKyi.Core/BiliApi/BiliUtils/Quality.cs — Quality enumeration and selection logic for video formats (8K/HDR/Dolby); central to feature differentiation.
• Directory.Build.props — Centralized build configuration and dependency versions for all projects; required reading for build system understanding.

Add support for a new Bilibili content type (e.g., live streams)

1. Create a new content-type info class in DownKyi.Core/BiliApi/YourType/ following the pattern of BangumiInfo.cs (DownKyi.Core/BiliApi/Bangumi/BangumiInfo.cs)
2. Add the new content type enum value to VideoParseType enumeration (DownKyi.Core/BiliApi/BiliUtils/VideoParseType.cs)
3. Register URL parsing logic in ParseEntrance.cs to detect and route to your new content type (DownKyi.Core/BiliApi/BiliUtils/ParseEntrance.cs)
4. Implement quality selection logic if needed by extending Quality.cs with type-specific variants (DownKyi.Core/BiliApi/BiliUtils/Quality.cs)

Add a new download quality option (e.g., AV1 codec support)

1. Add new quality enum value to Quality.cs representing the AV1 quality tier (DownKyi.Core/BiliApi/BiliUtils/Quality.cs)
2. Update AriaManager.cs download method to handle AV1-specific options passed to aria2c (DownKyi.Core/Aria2cNet/AriaManager.cs)
3. Configure aria2c options in AriaConfig.cs to specify bandwidth/connection limits for AV1 if needed (DownKyi.Core/Aria2cNet/Server/AriaConfig.cs)

Integrate a new metadata source or API endpoint

1. Create new models in DownKyi.Core/BiliApi/YourSource/Models/ matching the JSON response structure (DownKyi.Core/BiliApi/Bangumi/Models/BangumiSeasonInfo.cs)
2. Create an info class (e.g., YourSourceInfo.cs) with HTTP client methods for each endpoint, following BangumiInfo pattern (DownKyi.Core/BiliApi/Bangumi/BangumiInfo.cs)
3. Update ParseEntrance.cs to recognize URLs pointing to your new source and instantiate the appropriate info client (DownKyi.Core/BiliApi/BiliUtils/ParseEntrance.cs)

Add a new batch download feature or toolbox function

1. Create a processing utility class in DownKyi.Core/Aria2cNet/ or BiliApi/ depending on whether it's download or API-related (DownKyi.Core/Aria2cNet/AriaManager.cs)
2. Implement batch operation logic leveraging AriaManager.cs for parallel downloads or BangumiInfo.cs for metadata fetching (DownKyi.Core/BiliApi/Bangumi/BangumiInfo.cs)
3. Expose the feature through a public method in AriaManager or a new info class following existing naming conventions (DownKyi.Core/Aria2cNet/AriaManager.cs)

• C# / .NET — Cross-platform via AvaloniaUI; allows Windows/Linux/macOS UI deployment while reusing core download logic
• aria2c daemon + JSON-RPC 2.0 — Decoupled download engine supporting multi-connection, torrent, magnet, resumable transfers; OS-level process isolation
• Protobuf for danmaku — Bilibili's native danmaku protocol; efficient binary serialization for high-volume comment streams
• AvaloniaUI — Cross-platform XAML-based UI framework; enables single codebase for Windows/Linux/macOS frontends

• Separate aria2c daemon process vs. embedded download library

  • Why: Cleaner separation of concerns; aria2c is battle-tested for concurrent downloads
  • Consequence: Requires aria2c binary shipped with installer; adds complexity to process management and IPC

• Synchronous API client pattern with JSON-RPC polling vs. async streams

  • Why: Simpler request/response model; easier debugging and error handling
  • Consequence: Potential UI blocking on slow API responses; polling adds latency vs. streaming

• Multiple content-type-specific info classes (BangumiInfo, CheeseInfo, etc.) vs. generic content resolver

  • Why: Type-safe, clear separation for anime vs. courses vs. videos with different metadata structures
  • Consequence: Code duplication across similar API clients; more files to maintain for each new content type

• Real-time live stream recording (live streaming requires continuous capture, not bulk download)
• Web-based UI (desktop-only via AvaloniaUI)
• Bilibili account creation or advanced authentication (QR login only, read-only access)
• Video re-encoding or format conversion (only extracts/demuxes existing streams)

Bilibili API endpoints change frequently—version pinning may break silently without API compatibility layer. aria2 daemon must bind to localhost RPC port (default 6800); port conflicts will cause silent spawn failures. Platform-specific bundle layout (bundled ffmpeg/aria2 locations) hardcoded; custom installations require recompiling paths. No environment variable override for media download path visible—hardcoded per OS. Aria2 session persistence (.aria2 file format) may corrupt if process killed abruptly.

• JSON-RPC 2.0 — AriaClient communicates with aria2 daemon exclusively via JSON-RPC over TCP—understanding request/response structure is essential for debugging download failures
• Aria2 RPC Protocol — AriaManager spawns aria2 as external process and controls it via RPC (AddUri, TellStatus, Pause commands)—key to understanding how downloads are queued and monitored
• Cross-platform .NET Runtime Identifiers (RID) — Directory.Build.props likely uses RID (win-x64, osx-x64, linux-x64) to bundle platform-specific ffmpeg/aria2 binaries—critical for understanding deployment model
• XAML and Data Binding — AvaloniaUI uses XAML for UI declarative definition with reactive data binding—required for contributing UI features or understanding view models
• REST API Pagination and Rate Limiting — BiliApi models likely implement pagination for episode/video lists and must handle Bilibili's rate limits—patterns visible in Bangumi model structure
• Process Lifecycle Management in .NET — AriaManager must spawn aria2.exe/aria2 binary as child process, manage its stdin/stdout, and handle graceful shutdown—core to preventing orphaned processes
• Metadata-driven Build Configuration — Directory.Packages.props centralizes NuGet versions avoiding duplication across projects—standard for monorepo and multi-target .NET solutions

• leiurayer/downkyi — Original Windows-only Bilibili downloader; this repo is the cross-platform AvaloniaUI port of it
• AvaloniaUI/Avalonia — Core UI framework dependency enabling cross-platform XAML rendering on Windows/macOS/Linux
• aria2/aria2 — Underlying download engine wrapped by Aria2cNet; this repo manages subprocess spawning and RPC communication
• BililiveRecorder/BililiveRecorder — Parallel Bilibili content capture tool; shares similar BiliAPI integration patterns and platform-specific bundling strategies

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 unit tests for BiliApi parsing utilities (BvId.cs, ParseEntrance.cs, Quality.cs)

The BiliApi utility classes handle critical functionality like converting between BV/AV IDs, parsing video URLs, and quality determination. Currently, there are no visible test files for these utilities. Adding comprehensive unit tests would improve reliability for URL parsing and ID conversion logic, which are error-prone operations.

• [ ] Create DownKyi.Core.Tests/BiliApi/BiliUtils/ test project
• [ ] Add BvIdTests.cs with tests for BV↔AV conversion edge cases
• [ ] Add ParseEntranceTests.cs for various Bilibili URL formats (video, bangumi, cheese, etc.)
• [ ] Add QualityTests.cs for quality parsing and comparison logic
• [ ] Reference DownKyi.Core/BiliApi/BiliUtils/BvId.cs, ParseEntrance.cs, Quality.cs, VideoParseType.cs

Add integration tests for Aria2cNet client/server communication (AriaClient.cs, AriaServer.cs)

The Aria2cNet module is critical for download management with RPC communication between client and server. There are no visible integration tests verifying that AriaClient.cs correctly communicates with AriaServer.cs, command serialization, or response parsing. This is high-risk code for missing tests.

• [ ] Create DownKyi.Core.Tests/Aria2cNet/ test project with integration test fixtures
• [ ] Add AriaServerClientIntegrationTests.cs testing server startup and basic RPC calls
• [ ] Add AriaCommandSerializationTests.cs verifying all Entity command classes (AriaAddUri, AriaPause, AriaChangeOption, etc.) serialize correctly
• [ ] Add AriaResponseParsingTests.cs for parsing responses from all Entity classes (AriaGetFiles, AriaTellStatus, etc.)
• [ ] Reference DownKyi.Core/Aria2cNet/Client/AriaClient.cs and DownKyi.Core/Aria2cNet/Server/AriaServer.cs

Add GitHub Actions workflow for cross-platform builds (Windows, Linux, macOS)

The repo already has .github/workflows/build.yml but given the project is marketed as 'cross-platform' (跨平台版) and targets multiple platforms (8K, HDR support suggests desktop app), there's likely no automated verification that builds succeed on non-Windows platforms. This prevents catching platform-specific compilation and runtime errors early.

• [ ] Review existing .github/workflows/build.yml and identify platform-specific build steps
• [ ] Create or extend build.yml with matrix strategy for [windows-latest, ubuntu-latest, macos-latest]
• [ ] Add platform-specific dotnet build commands for WPF/Avalonia UI targeting (reference Directory.Build.props for SDK targets)
• [ ] Add artifact upload step to capture platform-specific binaries
• [ ] Test workflow with a draft PR to verify all platforms build successfully

• Add unit tests for BiliApi Bangumi models (BangumiEpisode.cs, BangumiArea.cs parsing)—currently no test directory visible and these are critical API contracts
• Document aria2 RPC error handling edge cases in AriaClient.cs—no error recovery path visible for network timeouts or malformed responses
• Implement platform-agnostic download path resolver in AriaManager.cs to accept environment variable override instead of hardcoded OS-specific paths

• High · Potential Unvalidated External Input in Danmaku Processing — DownKyi.Core/BiliApi/Danmaku/DanmakuProtobuf.cs, DownKyi.Core/BiliApi/BiliUtils/DanmakuSender.cs. The codebase includes danmaku (comment) processing functionality via DanmakuProtobuf.cs and DanmakuSender.cs. Danmaku involves parsing and handling user-generated content from Bilibili. Without proper validation and sanitization, this could lead to injection attacks or parsing vulnerabilities. Fix: Implement strict input validation and sanitization for all danmaku content before processing or displaying. Use allowlists for acceptable characters and formats. Validate protobuf message structures before deserialization.
• High · Aria2c RPC Protocol Without Authentication Verification — DownKyi.Core/Aria2cNet/Client/AriaClient.cs, DownKyi.Core/Aria2cNet/Server/AriaServer.cs. The codebase integrates with Aria2c (a download manager) via RPC. The AriaClient.cs and related files in DownKyi.Core/Aria2cNet/Client/ may communicate with Aria2c daemon without proper authentication or encryption, especially if configured with default settings. This could allow unauthorized command execution. Fix: Enforce RPC authentication tokens for all Aria2c communications. Use encrypted connections (RPC over HTTPS/TLS) when available. Validate that only trusted local processes can communicate with the Aria2c daemon. Document secure configuration requirements.
• High · API Communication Without Visible HTTPS Enforcement — DownKyi.Core/BiliApi/. The codebase makes numerous API calls to Bilibili services (BangumiInfo, BiliApi classes). Without visible enforcement of HTTPS for all API communications in the analyzed files, there is risk of man-in-the-middle attacks on sensitive data like user tokens, video URLs, and metadata. Fix: Enforce HTTPS for all API communications with certificate pinning where possible. Implement strict certificate validation. Never allow fallback to HTTP. Add security headers validation for all API responses.
• Medium · Potential Path Traversal in File Operations — DownKyi.Core/ (File operations not fully visible in provided structure). The application handles file downloads and manipulation (as indicated by video/audio extraction toolbox features mentioned in the README). The file structure suggests file I/O operations but the actual implementation isn't visible. Without proper path validation, there could be path traversal vulnerabilities. Fix: Implement robust path validation and normalization. Use allowlists for permitted directories. Never concatenate user input directly into file paths. Use APIs that restrict file access to intended directories.
• Medium · Hardcoded API Endpoints or Configuration — DownKyi.Core/BiliApi/ (Constant.cs likely contains hardcoded values). The BiliApi folder structure suggests hardcoded API endpoints to Bilibili services. If endpoints, keys, or other configuration values are hardcoded, they create security risks including difficulty in rotating secrets and exposure in source code. Fix: Move all API endpoints, keys, and secrets to external configuration files or environment variables. Never commit secrets to version control. Use a secrets management system for production deployments.
• Medium · Protobuf Deserialization Risks — DownKyi.Core/BiliApi/Danmaku/DanmakuProtobuf.cs. The use of DanmakuProtobuf.cs indicates protobuf deserialization of untrusted data from Bilibili services. Deserialization of untrusted data can lead to denial of service, code execution, or information disclosure if not properly handled. Fix: Validate protobuf message schema strictly. Implement size limits on deserialized objects. Use timeout mechanisms during deserialization. Keep protobuf libraries updated to latest versions.
• Medium · Missing Dependency Information — Directory.Packages.props, .csproj files. The provided dependency file content is empty. Without visibility into package dependencies, it's impossible to assess for known vulnerabilities in third-party libraries (transitive dependencies, outdated packages). Fix: Implement automated dependency scanning with tools like OWASP Dependency-Check or Snyk. Maintain a Software

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.