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/nICEnnnnnnnLee/BilibiliDown 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 2w ago
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Solo or near-solo (1 contributor active in 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 nICEnnnnnnnLee/BilibiliDown repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/nICEnnnnnnnLee/BilibiliDown.

What it runs against: a local clone of nICEnnnnnnnLee/BilibiliDown — 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 nICEnnnnnnnLee/BilibiliDown | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.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 ≤ 44 days ago | Catches sudden abandonment since generation |

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

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.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/nicelee/bilibili/INeedAV.java" \\
  && ok "src/nicelee/bilibili/INeedAV.java" \\
  || miss "missing critical file: src/nicelee/bilibili/INeedAV.java"
test -f "src/nicelee/bilibili/API.java" \\
  && ok "src/nicelee/bilibili/API.java" \\
  || miss "missing critical file: src/nicelee/bilibili/API.java"
test -f "src/nicelee/bilibili/INeedLogin.java" \\
  && ok "src/nicelee/bilibili/INeedLogin.java" \\
  || miss "missing critical file: src/nicelee/bilibili/INeedLogin.java"
test -f "src/nicelee/bilibili/downloaders/Downloader.java" \\
  && ok "src/nicelee/bilibili/downloaders/Downloader.java" \\
  || miss "missing critical file: src/nicelee/bilibili/downloaders/Downloader.java"
test -f ".github/workflows/release.yml" \\
  && ok ".github/workflows/release.yml" \\
  || miss "missing critical file: .github/workflows/release.yml"

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

BilibiliDown is a cross-platform Java GUI application that downloads videos from Bilibili (B站), supporting batch downloads of watchlist items, favorites, and creator video collections. It handles video format conversion (FLV→MP4), cookie management, login via QR code, and integrates ffmpeg for transcoding m4s/FLV segments. Monolithic Java application with release/ folder containing launcher scripts and the main JAR (INeedBiliAV.jar). Configuration persists in config/ folder (app.config, cookies.config). Build artifacts flow through .github/scripts/ (packaging, version reading, multi-platform signing). Desktop entry at release/BilibiliDown.desktop suggests Swing/AWT GUI.

Chinese video enthusiasts and content archivists who want to bulk-download Bilibili videos without using a browser or web scraping. Contributors are primarily Java desktop application developers working on video processing pipelines.

Actively maintained with CI/CD pipelines (GitHub Actions for releases and installers), though single maintainer (nICEnnnnnnnLee). Latest commit is recent, release process is automated (.github/workflows/release.yml), and Windows MSI installer exists (.github/scripts/installer-win/). Production-ready with multi-platform support (Win/Linux/Mac, tested on Win10 x64 with Java 1.8.0_101).

Standard open source risks apply.

Active release cycle with automated MSI Windows installer generation, pre-release artifact uploads to multiple CDNs (cloudinary, imagekit, railway, supabase), and stale issue auto-closing workflows. Recent focus on build infrastructure (.github/workflows/) and cross-repo mirroring (Bitbucket, Gitee, GitHub).

git clone https://github.com/nICEnnnnnnnLee/BilibiliDown.git
cd BilibiliDown
# Requires Java 1.8+ and ffmpeg installed
# Build: mvn clean package (or ./package.sh on Unix / package.bat on Windows)
java -jar release/INeedBiliAV.jar

Daily commands: Execute release/INeedBiliAV.jar directly (Double-Click-to-Run-for-Win.bat on Windows, Double-Click-to-Run-for-Mac.command on macOS, or shell equivalent on Linux). Requires Java runtime and ffmpeg in PATH for transcoding. GUI launches with embedded video download forms.

• src/nicelee/bilibili/INeedAV.java — Main application entry point and core GUI initialization; all contributors must understand the app lifecycle and threading model here
• src/nicelee/bilibili/API.java — Bilibili API client wrapper handling authentication, video metadata, and download request orchestration; essential for understanding data flow
• src/nicelee/bilibili/INeedLogin.java — Login and credential management system; critical for security and cookie persistence understanding
• src/nicelee/bilibili/downloaders/Downloader.java — Abstract downloader interface and core download logic; foundation for all video/audio retrieval implementations
• .github/workflows/release.yml — CI/CD pipeline for cross-platform builds (Win/Linux/Mac JAR and MSI generation); required for release and deployment process
• config/app.config — Application configuration and user preferences storage; defines default behavior and customization points
• src/nicelee/bilibili/annotations/Controller.java — Custom annotation-driven controller framework; defines how UI components and API handlers are bound together

Add Support for a New Video Source (not just Bilibili)

1. Create a new downloader class extending Downloader.java (src/nicelee/bilibili/downloaders/Downloader.java)
2. Implement the download() and related methods for your source (src/nicelee/bilibili/downloaders/[YourDownloader].java)
3. Create API client wrapper (parallel to API.java) for your source's endpoints (src/nicelee/bilibili/[YourSource]API.java)
4. Register your downloader in PackageScanLoader via classpath annotations (src/nicelee/bilibili/annotations/Bilibili.java)
5. Add UI controller methods in INeedAV.java to expose your downloader (src/nicelee/bilibili/INeedAV.java)

Add a New Configuration Option

1. Add key-value pair to app.config with default value (config/app.config)
2. Create or update a @Config annotated class to hold the setting (src/nicelee/bilibili/[ComponentName]Config.java)
3. Inject via @Value annotation in the consuming class (API, Downloader, or Controller) (src/nicelee/bilibili/[Consumer].java)
4. Add UI controls in INeedAV.java if user-facing setting required (src/nicelee/bilibili/INeedAV.java)

Add a New Login Method

1. Implement login flow in INeedLogin.java (e.g., phone/password alternative to QR) (src/nicelee/bilibili/INeedLogin.java)
2. Persist credentials to cookies.config in config folder (config/cookies.config)
3. Update API.java to use new credential format if needed (src/nicelee/bilibili/API.java)
4. Add UI button or menu in INeedAV.java to trigger new login method (src/nicelee/bilibili/INeedAV.java)

• Java 8 + Swing GUI — Cross-platform desktop application without external runtime dependency beyond JRE; Swing provides native look-and-feel on Win/Linux/Mac
• Custom annotation framework (@Controller, @Config, @Value) — Lightweight dependency injection avoiding heavy frameworks like Spring; reduces JAR size and startup time for GUI app
• FFmpeg (bundled for Windows, system-provided on Unix) — Industry-standard for video muxing/transcoding; avoids reimplementing codec logic; handles subtitle embedding and format conversion
• HTTP chunked downloads with resume — Resilience against network interruptions; enables pause/resume functionality on poor connections
• Cookies.config plaintext credential storage — Convenience for repeated login sessions; developers can delete file for security; acceptable for desktop app (not web service)

• Swing GUI instead of JavaFX or web-based UI

  • Why: Swing is more mature, lighter-weight, and guaranteed available in all JRE distributions (even older ones)
  • Consequence: Visual appearance more dated; fewer animation/styling capabilities compared to JavaFX; but lower barrier to entry for Java-only environments

• Plaintext cookie storage in config folder

  • Why: Simplicity for desktop application; users have physical access to machine anyway
  • Consequence: Credentials exposed if filesystem is compromised; acceptable trade-off for single-user desktop tool

• Single JAR with embedded launcher for memory loading

  • Why: Reduce distribution footprint and enable faster startup via MemoryURLHandler
  • Consequence: Complex class loading; harder to debug; increases launcher code complexity

• Annotation-driven component discovery via PackageScanLoader

  • Why: Avoid boilerplate component registration; enable plugin-like architecture without framework overhead
  • Consequence: Classpath scanning at runtime adds startup latency; requires naming conventions for discovery

• Real-time streaming or HLS re-encoding (downloads only)
• Web UI or headless/CLI mode (GUI-first design)
• Commercial video protection circumvention (Bilibili public content only)
• Android/iOS app (desktop-only application)
• Integration with cloud storage or email delivery

ffmpeg must be installed and on system PATH — the application shells out to ffmpeg for FLV→MP4 transcoding and m4s conversion; no bundled binary exists, causing silent failures if missing. Cookies stored plaintext in config/cookies.config (acknowledged in README as a security tradeoff). Bilibili API authentication uses wasm-based cookie refresh logic (reverse-engineered from geetest-validator and SocialSisterYi) which may break with upstream changes. QR code login flow depends on ZXing library and real-time polling. Eclipse .classpath binds specific JAR versions (core-3.3.3.jar, javax.mail-1.6.2.jar) — upgrading requires manual config. Windows MSI installer script (.github/scripts/installer-win/) is tightly coupled to WiX toolset and requires Windows build environment.

• FLV to MP4 transcoding pipeline — Bilibili serves videos as FLV segments or m4s fragments; understanding ffmpeg's role in merging and converting these formats is essential for modifying the download/encoding logic
• Cookie persistence and refresh (WASM-based) — BilibiliDown reverse-engineered Bilibili's wasm cookie refresh mechanism for session management; understanding the refresh token flow prevents authentication breakage
• Geetest CAPTCHA challenge-response — Bilibili's login protection uses Geetest verification; the codebase imports this solver, so understanding the handshake flow is needed for login feature maintenance
• AV (legacy) vs BV (modern) video ID encoding — Bilibili transitioned from AV IDs to BV IDs; BilibiliDown must parse and convert between both formats for user input and API requests
• Swing GUI event-driven architecture — BilibiliDown is a desktop Swing application; understanding event loops, layout managers, and component threading is essential for UI modifications
• Process spawning for external ffmpeg — The downloader shells out to ffmpeg as a subprocess for transcoding; handling process lifecycle, stdout/stderr capture, and timeout management is critical for reliability
• HTTP-based Bilibili streaming protocol — Video download requires fetching fragmented FLV or m4s chunks from Bilibili's CDN with proper headers and cookie management; understanding the request/response flow prevents throttling and auth failures

• SocialSisterYi/bilibili-API-collect — Canonical reference for Bilibili API documentation and reverse-engineering notes; directly cited in BilibiliDown's cookie refresh wasm implementation
• Colerar/abv — Standalone AV↔BV ID conversion utility that BilibiliDown's video ID parsing references (MIT licensed)
• kuresaru/geetest-validator — Geetest CAPTCHA solver implementation that BilibiliDown's login flow depends on for challenge-response validation
• zxing/zxing — QR code generation library bundled in BilibiliDown for producing QR codes for login and sharing
• yt-dlp/yt-dlp — Spiritual cousin: universal video downloader framework that handles similar fragmented streaming, authentication, and format conversion challenges

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 cookie management and authentication flows

The README explicitly mentions that login credentials are stored plaintext in config/cookies.config, which is a security-sensitive operation. Currently, there are no visible test files in the repository structure. Adding unit tests for the authentication module would help catch bugs in cookie handling, session management, and logout flows before they affect users' security.

• [ ] Create src/test/java directory structure matching source layout
• [ ] Write tests for cookie serialization/deserialization in cookies.config
• [ ] Add tests for login/logout operations to verify credentials are properly cleared
• [ ] Add tests to verify cookie file permissions and access controls
• [ ] Integrate test execution into existing .github/workflows/release.yml pipeline

Create comprehensive GitHub Actions workflow for cross-platform testing

The repo supports Win/Linux/Mac platforms but the current CI workflow (.github/workflows/release.yml) likely only tests on one platform. The file structure shows platform-specific scripts (.github/scripts/installer-win, release scripts for Mac/Linux) but no matrix testing strategy. A dedicated test workflow would catch platform-specific bugs early.

• [ ] Create new .github/workflows/test.yml with matrix strategy for [ubuntu-latest, windows-latest, macos-latest]
• [ ] Add Java 1.8+ setup step (repo requires Java as per README)
• [ ] Execute existing test suite and package.sh/package.bat on each platform
• [ ] Verify JAR builds successfully and runs on all platforms before merge
• [ ] Report platform-specific failures to PR authors

Document the build and release process in a CONTRIBUTING.md file

The repo has complex multi-platform build scripts (.github/scripts/gen_zip_for_pre_release.sh, win64_msi.py, platform-specific launchers) and conditional packaging logic, but no contributor guide explaining how to build locally. New contributors cannot easily understand the build pipeline or validate changes before submission.

• [ ] Create CONTRIBUTING.md documenting local build steps for Win/Linux/Mac
• [ ] Document the purpose of each script in .github/scripts/ directory
• [ ] Add instructions for testing the JAR locally with Double-Click-to-Run-* scripts
• [ ] Explain the relationship between package.bat, package.sh and Windows MSI generation
• [ ] Link to existing help documentation from README (partially visible but incomplete URL)

• Add unit tests for AV↔BV conversion logic (referenced from Colerar/abv but no visible test files in repo) — would catch regressions when Bilibili's ID scheme changes
• Document the ffmpeg dependency requirements in README (minimum version, supported codecs for m4s→mp4 conversion) — currently only mentioned in comments, causing setup friction
• Extract hardcoded Bilibili API endpoints (geetest验证码 URLs, cookie refresh wasm endpoint) into a centralized config file to simplify future API migrations

This Bilibili downloader application has several notable security concerns. The most critical issue is plain text storage of authentication credentials (cookies), which poses an immediate risk to user accounts. The codebase relies

• High · Credentials Stored in Plain Text — config/cookies.config. According to the README, login credentials are stored in plain text in the config/cookies.config file. This poses a significant security risk as any user with file system access can read the authentication tokens and session cookies. Fix: Implement encrypted credential storage. Use Java's KeyStore or a dedicated secrets management library. At minimum, encrypt sensitive data at rest and implement proper key management.
• High · Outdated Java Email Library — libs/javax.mail-1.6.2.jar. The dependency javax.mail-1.6.2.jar is an outdated version of the Java Mail API. Older versions may contain known vulnerabilities in email handling and could be susceptible to various attacks including injection attacks. Fix: Upgrade to the latest version of Jakarta Mail (javax.mail has been moved to the Jakarta EE project). Review and apply security patches from the mail library vendor.
• High · Outdated Core Activation Library — libs/jaf-1.1.1-activation.jar. The jaf-1.1.1-activation.jar library is outdated. This ancient activation framework may contain unpatched security vulnerabilities. Fix: Upgrade to jakarta.activation (the modern replacement). This library is no longer actively maintained in its old form.
• Medium · Potentially Insecure External Binary Dependency — release/ffmpeg.exe. The codebase includes release/ffmpeg.exe, a compiled binary. Including pre-compiled binaries in source control without verification mechanisms creates supply chain risks and makes it difficult to verify integrity. Fix: Download ffmpeg at runtime from official sources with integrity verification (checksum validation). If bundling is necessary, implement cryptographic signature verification. Document the ffmpeg version and source.
• Medium · Missing Security Configuration in App Config — config/app.config. The config/app.config file is referenced but its contents are not visible. Default or insecure configurations could expose the application to various attacks. Fix: Review the configuration file for: default credentials, exposed ports, missing security headers, and insecure protocol settings. Implement configuration validation and use secure defaults.
• Medium · No Visible Input Validation for Video URLs — Source code (not fully visible). As a Bilibili video downloader that processes URLs, there is potential for URL injection or SSRF attacks if user input is not properly validated before making network requests. Fix: Implement strict URL validation and whitelist allowed domains. Sanitize all user inputs before using them in network requests. Use URL parsing libraries to prevent bypass techniques.
• Medium · Build Scripts with Potential Security Issues — .github/scripts/. Multiple bash and batch scripts in .github/scripts/ are used for building and packaging. These scripts may execute arbitrary commands and could be vulnerable to injection if they process untrusted input. Fix: Review all build and deployment scripts for command injection vulnerabilities. Quote all variables properly. Use parameterized commands instead of shell evaluation where possible. Implement script signing.
• Low · No SBOM or Dependency Lock File Visible — Repository root. There is no visible Software Bill of Materials (SBOM) or dependency lock file (like pom.xml, build.gradle, or package-lock.json). This makes it difficult to track and audit dependencies for vulnerabilities. Fix: Implement a proper dependency management system (Maven, Gradle, etc.). Generate and maintain an SBOM. Use tools like OWASP Dependency-Check to scan for known vulnerabilities regularly.
• Low · Bundled Java Mail Jars Not Using Package Manager — libs/. Dependencies are manually placed in libs/ folder rather than managed through a package manager. This prevents automatic security updates and vulnerability tracking. Fix: Migrate to Maven or Gradle for dependency management. This enables automated vulnerability scanning and easier updates.

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.