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/btjawa/BiliTools 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 4w ago
• 2 active contributors
• GPL-3.0 licensed
• CI configured
• ⚠ Small team — 2 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 96% 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 btjawa/BiliTools repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/btjawa/BiliTools.

What it runs against: a local clone of btjawa/BiliTools — 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 btjawa/BiliTools | 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 master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 55 days ago | Catches sudden abandonment since generation |

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

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

# 4. Critical files exist
test -f "src-tauri/src/main.rs" \\
  && ok "src-tauri/src/main.rs" \\
  || miss "missing critical file: src-tauri/src/main.rs"
test -f "src-tauri/src/commands.rs" \\
  && ok "src-tauri/src/commands.rs" \\
  || miss "missing critical file: src-tauri/src/commands.rs"
test -f "src-tauri/src/services.rs" \\
  && ok "src-tauri/src/services.rs" \\
  || miss "missing critical file: src-tauri/src/services.rs"
test -f "src-tauri/Cargo.toml" \\
  && ok "src-tauri/Cargo.toml" \\
  || miss "missing critical file: src-tauri/Cargo.toml"
test -f "package.json" \\
  && ok "package.json" \\
  || miss "missing critical file: package.json"

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

BiliTools is a Tauri-based desktop application that parses and downloads resources from Bilibili (Chinese video platform), including videos, anime, music, subtitles, and danmaku (comments). It handles multiple video formats (DASH, MP4, FLV), codec support (AVC, HEVC, AV1), and premium content (4K, 8K, HDR, Dolby Vision) by leveraging user account credentials and subscriptions. Monorepo structure: Rust backend (155K lines, likely in src-tauri/) handles API calls, video processing, and authentication; TypeScript/Vue frontend (128K + 91K lines) in src/ provides UI; docs/ is a separate VitePress site. Core parsing logic appears centralized with feature-specific modules (av-bv.md guide suggests ID parsing utilities; download.md implies download orchestration).

Chinese content consumers who hold Bilibili premium memberships or own digital content, and developers interested in Bilibili API reverse-engineering and media processing. Contributors range from Rust backend developers to Vue/TypeScript frontend engineers.

Actively developed and production-ready. The project shows strong community engagement (Trendshift ranking), established CI/CD via GitHub Actions (release.yml, pr-checks.yml), comprehensive documentation site (docs/ with VitePress), and v2 is under discussion (discussions/214). Last visible activity suggests ongoing maintenance with structured versioning.

Moderate risk: depends on Bilibili's undocumented API which could break with platform changes; single primary maintainer (btjawa) visible in repo structure; requires user credentials (login functionality in docs/guide/login.md) introducing security considerations. However, active CI/CD and issue templates suggest responsive maintenance. v2 rewrite signals awareness of technical debt.

v2 rewrite is planned with community input (discussions/214). Current stable branch is v1.4.0+. Active issue templates and PR checks suggest ongoing bug fixes and feature requests. Documentation has grown to include guides for login, parsing, downloading, and resource types, indicating feature maturation and user education focus.

Clone: git clone https://github.com/btjawa/BiliTools.git && cd BiliTools. For docs only: cd docs && npm install && npm run dev. For full app: requires Rust (for Tauri backend) and Node.js; run npm install in root, then npm run tauri dev (exact command inferred from Tauri convention—check package.json for exact script).

Daily commands: Dev frontend: cd docs && npm run dev (starts VitePress on port 5173 typical). Full app dev: npm run tauri dev (standard Tauri command—inferred from repo structure). Build: npm run tauri build or check GitHub Actions workflows (release.yml) for exact CI build steps.

• src-tauri/src/main.rs — Desktop application entry point for Tauri; initializes the GUI framework and command handlers
• src-tauri/src/commands.rs — Defines all Rust IPC commands exposed to the frontend; core API surface between UI and backend
• src-tauri/src/services.rs — Implements bilibili download, parsing, and streaming logic; handles video/episode resource acquisition
• src-tauri/Cargo.toml — Rust dependencies configuration; declares external crates for HTTP, video processing, and platform integration
• package.json — Node.js workspace root; defines frontend build system, scripts, and coordination across subprojects
• .github/workflows/release.yml — CI/CD pipeline for multi-platform binary releases; automates builds for Windows, macOS, Linux

• Tauri App Shell (main.rs) — Initializes desktop window, registers IPC commands, manages app

Add a new IPC command (frontend → backend)

1. Define the Rust command handler function in services.rs with #[tauri::command] attribute (src-tauri/src/services.rs)
2. Export the command from commands.rs and register it in main.rs via .invoke_handler() (src-tauri/src/commands.rs)
3. Call the command from frontend code using tauri.invoke('command_name') (index.html)

Add support for a new bilibili resource type (video, anime, etc.)

1. Implement parsing logic in services.rs that handles the new resource endpoint (src-tauri/src/services.rs)
2. Add error handling for the new resource type in errors.rs (src-tauri/src/errors.rs)
3. Expose a command in commands.rs to allow the UI to request this resource (src-tauri/src/commands.rs)
4. Document usage in docs/guide/resource.md (docs/guide/resource.md)

Add a new platform binary (Windows/macOS/Linux)

1. Place compiled binary in the appropriate folder under src-tauri/binaries/{platform}/ (src-tauri/binaries/windows/)
2. Update build.rs to include the binary in the distribution package (src-tauri/build.rs)
3. Reference the binary path in services.rs when invoking external tools (src-tauri/src/services.rs)

Add a new documentation page

1. Create a new .md file in docs/guide/ with the topic name (docs/guide/about.md)
2. Register the page in docs/.vitepress/config.ts sidebar configuration (docs/.vitepress/config.ts)
3. Link to the new page from docs/index.md or relevant guide pages (docs/index.md)

• Tauri — Cross-platform desktop app framework using system webview; lightweight alternative to Electron with Rust backend for performance
• Rust — Type-safe, performant systems language; handles heavy I/O operations (downloading, transcoding) with minimal overhead
• aria2c — Fast, parallel download tool; native binary integration for resumable multi-segment downloads with retry logic
• FFmpeg — Industry-standard media toolkit; handles transcoding, remuxing, and quality conversion of downloaded videos
• VitePress — Static documentation site generator; zero-runtime docs for guides, API reference, and user instructions

• Bundled external binaries (FFmpeg, aria2c, DanmakuFactory) rather than native implementations

  • Why: Reduce Rust code complexity and maintenance burden; leverage battle-tested C/C++ tools
  • Consequence: Larger app distribution size (~50-200MB per platform); dependency on pre-compiled binaries for each OS/arch

• Multi-architecture binary packing (x86_64 + aarch64 for Linux/macOS) instead of universal builds

  • Why: Simplify build process; avoid complexity of cross-compilation toolchains
  • Consequence: Users must download platform-specific binaries; larger final distribution

• VitePress for documentation instead of built-in in-app help

  • Why: Decouple documentation from app releases; easier versioning and community contributions via GitHub
  • Consequence: Users must visit external website for help; no offline documentation in app by default

• Real-time streaming playback (only downloads)
• Cloud synchronization or account backup
• DRM-protected content support beyond bilibili's native DRM
• Mobile platform support (Windows, macOS, Linux desktop only)
• Live broadcast recording (focus on VOD content)

Bilibili API dependency: Undocumented and unstable—changes to Bilibili's endpoint responses can break parsing without warning. Authentication complexity: Must handle wind control verification (risk.md guide exists), fingerprint verification, and multiple login methods—test accounts needed for full testing. Media format landscape: Support for 8K, HDR, Dolby Vision requires knowledge of codec quirks; transcoding audio-to-MP3 has edge cases. No visible test directory: Suggests limited automated test coverage—manual testing may be primary validation. Clipboard monitoring: Requires platform-specific permissions (mentioned in README table) that may fail on some OS configurations.

• Danmaku (弹幕) Parsing & Rendering — Core differentiator of BiliTools; ASS/XML conversion and danmaku pool decompression are non-trivial (see docs/guide/stream.md)—requires understanding bitmap/RLE compression and subtitle format generation
• DASH Streaming Format Negotiation — BiliTools must select optimal video/audio codec pairs from Bilibili's DASH manifests (4K, 8K, HDR options)—requires knowledge of MP4 container, codec capability signaling, and bandwidth constraints
• Session-Based Authentication with Wind Control (风控) — Bilibili's anti-bot verification layer requires fingerprint extraction and challenge-response handling; failure here blocks all API calls—core to login.md complexity
• Tauri IPC Bridge (Rust ↔ TypeScript) — Backend logic runs in Rust; UI in TypeScript/Vue—messages cross an IPC boundary with serialization overhead. Understanding Tauri's invoke/listen patterns is essential for full-stack changes
• Codec Support Matrix (AVC, HEVC, AV1, Dolby Vision) — BiliTools must detect and handle multiple modern codecs with different container requirements; mishandling breaks 8K or HDR downloads—requires knowledge of video codec ecosystems
• NFO Scraping (Kodi Metadata Format) — BiliTools extracts episode/collection metadata into .nfo XML files for media library integration; requires understanding Kodi's schema and scraper patterns (docs/guide exists but implementation complex)
• Audio Transcoding & Metadata Embedding (ID3v2, Vorbis) — Audio downloads may require MP3 conversion; metadata (artist, album, bitrate) must be embedded losslessly—requires libmp3lame or similar integration and tag format knowledge

• SocialSisterYi/bilibili-API-collect — Comprehensive Bilibili API documentation reverse-engineered by community—BiliTools likely depends on or cross-references this for endpoint details
• yt-dlp/yt-dlp — Similar media downloader architecture for multiple platforms with format negotiation; design patterns applicable to Bilibili's codec/quality handling
• tauri-apps/tauri — Core framework dependency—BiliTools is a Tauri showcase app; staying updated with Tauri releases critical for security and features
• vuejs/vue — Frontend framework dependency—codebase uses Vue 3, understanding Vue patterns directly impacts component maintainability
• rust-lang/rust — Backend language dependency—Rust updates and ecosystem (reqwest, tokio, serde) changes affect backend stability and performance

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 E2E tests for download and parsing functionality

The repo has comprehensive download/parsing guides (docs/guide/download.md, docs/guide/parsing.md) but no visible test files in the structure. Given this is a cross-platform tool for downloading bilibili resources, E2E tests would validate core functionality across platforms and prevent regressions in critical features.

• [ ] Create tests/e2e directory structure
• [ ] Add tests for video download flows (reference src-tauri/Cargo.toml for Rust test setup)
• [ ] Add tests for parsing different resource types (video, anime, etc.)
• [ ] Integrate test runner into pr-checks.yml GitHub Action workflow
• [ ] Document test running instructions in CONTRIBUTING.md

Add missing GitHub Action for VitePress docs deployment validation

The repo has deploy-docs.yml workflow but no pre-deployment validation. The docs use VitePress v2.0.0-alpha.12 (unstable version) and docs/package.json has a 'build' script, but there's no CI step validating the docs build succeeds before deployment, risking broken documentation releases.

• [ ] Create new workflow file .github/workflows/docs-build-check.yml
• [ ] Add steps to install dependencies from docs/package.json and run 'npm run build'
• [ ] Trigger on pull requests modifying docs/ or .github/workflows/docs-build-check.yml
• [ ] Add status check as required on main branch
• [ ] Update CONTRIBUTING.md with local docs build verification instructions

Create platform-specific binary verification and testing workflow

The repo has pre-built binaries in src-tauri/binaries/ for multiple platforms (linux aarch64, x86_64) but no visible workflow to validate binary integrity or test them. With release.yml handling builds, a binary verification step would prevent corrupted releases and ensure all platform variants work.

• [ ] Create .github/workflows/binary-verify.yml workflow
• [ ] Add checksum validation for binaries in src-tauri/binaries/
• [ ] Add basic smoke tests for each binary variant (ffmpeg, aria2c, DanmakuFactory)
• [ ] Generate and commit checksum manifest (e.g., CHECKSUMS.sha256)
• [ ] Reference this workflow in release.yml as a pre-release check

• Add unit tests for av-bv.md conversion logic (file exists as user guide but likely has untested parsing code in Rust backend)
• Expand docs/guide/settings.md with concrete examples of each configuration option—currently sparse, would help new users and reveal missing UI features
• Create a migration guide or script for users upgrading from v1 to v2—v2 rewrite is under discussion and will need onboarding docs

The BiliTools codebase shows moderate security posture. Primary concerns include the use of alpha-stage VitePress dependency, precompiled binaries without verification mechanisms, and limited visibility into the Rust backend security. The project lacks formal security documentation and vulnerability reporting guidelines. The inclusion of external binaries (ffmpeg, aria2c, DanmakuFactory) without checksums or signature verification presents the highest supply chain risk. Recommendations focus on updating to stable dependencies, implementing binary verification, and improving security documentation.

• Medium · Outdated VitePress Version — docs/package.json. The docs package.json specifies VitePress version ^2.0.0-alpha.12, which is an alpha release. Alpha versions are unstable and may contain unpatched security vulnerabilities. Production documentation should use stable releases. Fix: Update to a stable VitePress version (e.g., ^2.0.0 or higher stable release) once available. Monitor VitePress releases for security patches.
• Medium · Missing Dependency Lock File Verification — pnpm-lock.yaml, src-tauri/binaries/. The pnpm-lock.yaml file is present but the security analysis cannot verify if dependencies have known vulnerabilities without access to the full lock file content and current CVE databases. The presence of external binaries (ffmpeg, aria2c, DanmakuFactory) adds supply chain risk. Fix: Regularly run 'pnpm audit' to check for vulnerabilities. Verify integrity and signatures of precompiled binaries. Consider building binaries from source or using verified sources only.
• Medium · Precompiled Binaries Without Verification — src-tauri/binaries/. The codebase includes precompiled binaries (ffmpeg, aria2c, DanmakuFactory) for multiple platforms without visible integrity checks or signature verification. This presents a supply chain attack vector. Fix: Implement checksum verification (SHA256) for all precompiled binaries. Sign binaries with GPG keys. Document the source and build process for each binary. Consider using package managers or building from source.
• Low · Missing Security Configuration Files — Repository root. No evidence of security-related configuration files such as .env.example, SECURITY.md, or security policy documentation for reporting vulnerabilities. Fix: Create a SECURITY.md file with vulnerability reporting instructions. Add .env.example to document required environment variables. Implement security.txt for coordinated vulnerability disclosure.
• Low · Potential Tauri-Based Attack Surface — src-tauri/. The application uses Tauri for cross-platform desktop functionality. Tauri security depends on proper IPC validation and Rust backend security. Without access to the Rust backend code (src-tauri/src/), potential vulnerabilities cannot be fully assessed. Fix: Conduct security review of Rust backend code, especially IPC command handlers. Validate all frontend-to-backend communication. Use Tauri's allowlist feature to restrict command access. Keep Tauri framework updated.

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.