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/RayWangQvQ/BiliBiliToolPro 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 2d ago
• 2 active contributors
• GPL-3.0 licensed
• CI configured
• Tests present
• ⚠ Small team — 2 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 99% of recent commits
• ⚠ GPL-3.0 is copyleft — check downstream compatibility

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

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

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "RayWangQvQ/BiliBiliToolPro(\\.git)?\\b" \\
  && ok "origin remote is RayWangQvQ/BiliBiliToolPro" \\
  || miss "origin remote is not RayWangQvQ/BiliBiliToolPro (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 "Ray.BiliBiliTool.sln" \\
  && ok "Ray.BiliBiliTool.sln" \\
  || miss "missing critical file: Ray.BiliBiliTool.sln"
test -f "Dockerfile" \\
  && ok "Dockerfile" \\
  || miss "missing critical file: Dockerfile"
test -f ".github/workflows/publish-image.yml" \\
  && ok ".github/workflows/publish-image.yml" \\
  || miss "missing critical file: .github/workflows/publish-image.yml"
test -f "common.props" \\
  && ok "common.props" \\
  || miss "missing critical file: common.props"
test -f "Directory.Packages.props" \\
  && ok "Directory.Packages.props" \\
  || miss "missing critical file: Directory.Packages.props"

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

BiliBiliToolPro is a C# (.NET) automation framework that performs daily tasks on Bilibili (China's premier video platform), including auto-login via QR code, daily experience farming (watch/coin/share/like), live stream AFK farming, manga/live check-ins, monthly pass perks collection, and B-coin charging. It supports multi-account execution across Docker, Kubernetes, Qinglong (a Chinese task scheduler), and standalone deployment with push notifications to Telegram, WeChat, DingTalk, PushPlus, and custom webhooks. Monorepo structure: Ray.BiliBiliTool.sln (C# solution root) with core library handling Bilibili API calls and task orchestration; bruno/ directory contains API request definitions for development/testing (structured by endpoint: api.bilibili.com/x/{vip,space}/, app.bilibili.com/pgc/); deployment scripts in .github/workflows/ and Dockerfile for containerization; krew/ (Go module) for Kubernetes plugin installation. Configuration-driven (appsettings.json style) supporting multi-account and push notifications.

Bilibili users (especially premium members) seeking to automate daily account maintenance tasks without manual interaction; DevOps engineers deploying it at scale via K8s or Qinglong; Chinese automation enthusiasts needing multi-platform deployment (docker, k8s, SCF serverless, local binary).

Actively maintained and production-ready. High GitHub visibility (evident from badges in README), comprehensive deployment options (5+ methods documented), mature CI/CD pipelines (.github/workflows/ includes auto-deploy, publish-image, codeql-analysis, verify-pr), and structured monorepo with Directory.Packages.props centralized dependency management. Handles sensitive authentication (QR code login, cookie management) suggesting battle-tested credential handling.

Standard open source risks apply.

Active feature development indicated by CHANGELOG.md, recent workflow additions (auto-deploy-tencent-scf.yml, publish-image.yml), and issue template coverage (bug reports split by deployment method: standard vs Qinglong). The bruno/ API test suite shows iterative Bilibili endpoint discovery (vip_center v2, modules, three_days_sign activities). No specific PR/milestone data visible, but tag.yml workflow suggests semantic versioning discipline.

Clone and build:

git clone https://github.com/RayWangQvQ/BiliBiliToolPro.git
cd BiliBiliToolPro
dotnet restore Ray.BiliBiliTool.sln
dotnet build Ray.BiliBiliTool.sln

Or deploy via Docker (Dockerfile present):

docker build -t bilitool .
docker run -e "ACCOUNT=<account>" -e "PASSWORD=<password>" bilitool

For Kubernetes: use .github/workflows/ as reference or see Chart deployment method (1.1.5).

Daily commands: Dev build & test:

dotnet restore
dotnet build
dotnet test  # if test projects exist in .sln

Run locally:

dotnet run --project <main-project-path> -- --config appsettings.json

Docker:

docker build -t bilitool .
docker run --rm -v $(pwd)/config:/app/config bilitool

Qinglong integration: Add as scheduled task via Qinglong UI with provided docker image. K8s: Use krew plugin (./krew/go.mod) or reference .github/workflows/publish-image.yml for image registry.

• Ray.BiliBiliTool.sln — Root solution file that defines the entire .NET project structure and all dependencies for the BiliBili automation tool
• Dockerfile — Container definition required to understand how the tool is packaged and deployed across Docker, K8s, and serverless platforms
• .github/workflows/publish-image.yml — CI/CD pipeline that orchestrates multi-architecture builds and releases; critical for understanding deployment automation
• common.props — Centralized NuGet package and build configuration shared across all projects; defines dependency versions and compilation settings
• Directory.Packages.props — Central package management file using NuGet Central Package Management; controls all transitive dependency versions
• README.md — Project documentation covering features, deployment modes (Docker/Qinglong/K8s), and configuration patterns essential to understanding project intent
• .github/workflows/verify-pr.yml — Pull request validation workflow that enforces code quality gates and prevents regressions before merge

Add a New BiliBili API Task Endpoint

1. Create a Bruno API request file in the appropriate subdirectory under bruno/ (e.g., bruno/api.bilibili.com/x/vip/new_feature/) documenting the HTTP endpoint, headers, and payload (bruno/api.bilibili.com/x/vip/folder.bru)
2. Define environment variables needed for the endpoint in bruno/environments/default.bru or create a task-specific .env (bruno/environments/default.bru)
3. Add a new C# service class in the main project (following Ray.BiliBiliTool.* project structure) that wraps the HTTP client and implements the task logic (Ray.BiliBiliTool.sln)
4. Register the new service in common.props or the relevant project file with appropriate NuGet dependencies if needed (common.props)
5. Add workflow configuration in .github/workflows/ to test the new endpoint in CI/CD pipeline (.github/workflows/verify-pr.yml)

Deploy Tool to Kubernetes Cluster

1. Review existing Kubernetes manifests and kustomization files referenced in the krew module (go.mod shows k8s.io dependencies) (krew (module))
2. Ensure Dockerfile multi-arch build is passing by checking .github/workflows/publish-image.yml for image registry push step (.github/workflows/publish-image.yml)
3. Configure kubectl plugin via krew using sigs.k8s.io/kustomize libraries to patch and deploy manifests (krew (module))
4. Set cluster environment variables and secrets in your K8s namespace following patterns in bruno/environments/ (bruno/environments/default.bru)
5. Trigger deployment via auto-deploy workflow or manual kubectl apply using generated images from publish-image.yml (.github/workflows/auto-deploy-tencent-scf.yml)

Add a New Daily Scheduled Task

1. Create the API endpoint test in Bruno (e.g., bruno/app.bilibili.com/pgc/activity/new_task/receive.bru) to validate the BiliBili endpoint (bruno/app.bilibili.com/pgc/activity/deliver/task/complete.bru)
2. Implement the task service in the main .NET solution following existing patterns (C# service class with HTTP calls) (Ray.BiliBiliTool.sln)
3. Register the task in the scheduler orchestration code (likely in a main entry point or startup configuration file) (common.props)
4. Add task-specific configuration keys to README.md and any example .env files to document new settings (README.md)
5. Add test case in verify-pr.yml workflow and update CHANGELOG.md with the new feature (.github/workflows/verify-pr.yml)

Update Docker Image Build for New Architecture Support

1. Modify Dockerfile RUN and FROM directives to support the new architecture (e.g., add qemu setup for ARM64) (Dockerfile)
2. Update the buildAndPushImage_multiArch.ps1 PowerShell script to include the new target architecture in the docker buildx build command (docker/build/buildAndPushImage_multiArch.ps1)
3. Ensure publish-image.yml workflow matrix includes the new architecture in its strategy.matrix.platform setting (.github/workflows/publish-image.yml)
4. Test locally with docker buildx and verify the image runs correctly on the target architecture before pushing to registry (docker/README.md)

• .NET / C# (Ray.BiliBiliTool.sln) — Type-safe automation framework with extensive ecosystem; enables rapid development of BiliBili API integrations with dependency injection and async/await
• Docker & Multi-arch Buildx — Ensures tool runs consistently across environments (developer laptop, Docker Desktop, Kubernetes, serverless); multi-arch support (amd64, arm64

Bilibili API brittleness: API endpoints change frequently (evidenced by multiple vip_center versions in bruno/); no SDK available, so wrapper breaks silently on API changes. WBI signature: Bilibili uses a Web Business Intelligence (WBI) signature for sensitive endpoints (hints in bruno/ folder structure); reverse-engineering WBI is non-trivial and version-dependent. Authentication state: QR code login flow must maintain session cookies and handle expiry; cookie rotation logic must be correct or tasks silently fail. Qinglong environment variables: Qinglong deployments require specific env var naming (ACCOUNT, PASSWORD, COOKIES, etc.); mismatch causes silent skips, not errors. Multi-account isolation: Switching between accounts requires careful credential isolation; token leakage across accounts is a risk. Rate limiting: Bilibili likely has aggressive rate limits; concurrent multi-account execution may trigger captchas or IP bans. No visible test suite: Critical task logic (coin, share, live AFK) lacks visible unit/integration tests; regressions only caught by user reports. Timezone handling: Task scheduling (daily, monthly) must handle timezone correctly; implicit UTC or local time assumptions cause wrong execution times.

• WBI Signature (Web Business Intelligence) — Bilibili uses proprietary WBI signatures to protect sensitive endpoints; reverse-engineering and maintaining the signature algorithm is critical to keeping BiliBiliToolPro's API calls working as Bilibili updates it
• Cookie-based Session Management — BiliBiliToolPro must maintain Bilibili session cookies across task executions and detect expiry; improper cookie handling breaks all subsequent requests silently
• QR Code Authentication Flow — BiliBiliToolPro's auto-login uses QR codes instead of passwords; understanding the polling mechanism and state transitions is necessary to implement or debug the login flow
• Cron Expression / Task Scheduling — Daily, monthly, and time-range constrained task execution requires understanding cron syntax or a scheduling library; timezone handling is a common pitfall
• Multi-tenancy via Configuration — BiliBiliToolPro supports multiple Bilibili accounts; isolating credentials, tasks, and notifications per account requires careful configuration design and environment variable mapping
• Adapter Pattern for Notifications — Supporting Telegram, WeChat, DingTalk, PushPlus, and custom webhooks requires a notification adapter; each has different auth, payload, and error handling—the abstraction keeps code maintainable
• API Reverse-Engineering & Scraping — Bilibili has no public API; BiliBiliToolPro relies entirely on reverse-engineered endpoints (documented in bruno/); API changes break all tasks and require rapid mitigation

• JunzhouLiu/BILIBILI-HELPER-PRE — Direct competitor: Node.js-based Bilibili automation tool with similar feature set (daily login, coin, share); alternative implementation in a different ecosystem
• srcrs/BilibiliTask — Similar Bilibili automation in Go; demonstrates how to tackle Bilibili API reverse-engineering in a different language and deployment model
• eelbull/qinglong — Qinglong task scheduler (referenced deployment target); understanding Qinglong's plugin architecture and environment interface is essential for BiliBiliToolPro's Qinglong integration
• containrrr/watchtower — Docker container auto-updater; common companion for keeping BiliBiliToolPro image fresh in self-hosted deployments
• pushplus/pushplus-client — PushPlus notification service (supported by BiliBiliToolPro); understanding its API helps debug notification failures and extend notification routing

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 integration tests for Bruno API collection files

The repo has an extensive Bruno API collection (bruno/ directory) with 20+ endpoint definitions for BiliBili API interactions, but there's no automated verification that these requests are syntactically correct or that they match the actual application implementation. Adding integration tests would catch breaking API changes early and validate the Bruno collections work correctly.

• [ ] Create a new test directory: tests/bruno-integration/
• [ ] Add a Bruno collection validator that parses .bru files in bruno/ directory
• [ ] Implement schema validation for required fields (method, url, headers, body) in each .bru file
• [ ] Add a GitHub Actions workflow (tests-bruno.yml) that runs collection validation on PRs
• [ ] Document test execution in a new TESTING.md file

Create Go module tests for krew plugin functionality

The go.mod file in the krew/ directory shows K8s integration dependencies (k8s.io/cli-runtime, sigs.k8s.io/kustomize), indicating a kubectl plugin, but there are no visible unit tests. Adding tests would ensure the K8s deployment pathway works correctly and prevent regressions when updating K8s client libraries.

• [ ] Create tests/krew/ directory with test files matching krew module structure
• [ ] Add unit tests for the main cobra command handlers (test CLI flag parsing and K8s resource creation)
• [ ] Add mock tests for K8s client interactions using k8s.io/client-go/testing
• [ ] Create a GitHub Actions workflow (test-krew.yml) that runs 'go test ./krew/...' on PRs
• [ ] Update Directory.Packages.props to include testing dependencies if missing

Add pre-deployment validation workflow for multi-environment configs

The repo supports multiple deployment methods (Docker, 青龙, K8s) but there's no automated validation that configuration files are consistent across deployment methods. Adding a workflow to validate .env, Dockerfile, and K8s manifests would catch configuration mismatches early.

• [ ] Create a new GitHub Actions workflow: .github/workflows/validate-configs.yml
• [ ] Add validation script (scripts/validate-deployment-configs.sh) that checks: env file schema consistency, Dockerfile build args match .env.sample, K8s manifests reference correct image versions
• [ ] Create a DEPLOYMENT_GUIDE.md documenting configuration requirements for each deployment method (Docker, 青龙, K8s) with examples from bruno/ and existing configs
• [ ] Add pre-commit hook in .husky/ to run config validation locally before commit

• Add unit tests for Bilibili API client wrapper methods: bruno/ directory has request definitions but core C# client logic (likely in src/) has no visible test coverage; adding tests for dailyLogin, coinVideo, shareVideo methods would catch API contract changes early
• Document WBI signature algorithm and reverse-engineering steps: bruno/ reveals WBI-authenticated endpoints (api.bilibili.com/x/space/wbi-acc-info.bru) but no docs explain how the signature is computed; new contributors struggle to debug or add similar endpoints without this tribal knowledge
• Create Helm chart for K8s deployment: krew/ plugin exists and .github/workflows includes publish-image.yml, but no Helm chart in repo; users deploying to K8s manually write YAML; a chart template (Chart.yaml, templates/deployment.yaml, values.yaml) would standardize deployment and reduce configuration errors

Failed to generate security analysis.

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.