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/BililiveRecorder/BililiveRecorder 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 1d ago
• 15 active contributors
• GPL-3.0 licensed
• CI configured
• Tests present
• ⚠ Single-maintainer risk — top contributor 80% 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 BililiveRecorder/BililiveRecorder repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/BililiveRecorder/BililiveRecorder.

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

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

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

# 4. Critical files exist
test -f "BililiveRecorder.Core/Recorder.cs" \\
  && ok "BililiveRecorder.Core/Recorder.cs" \\
  || miss "missing critical file: BililiveRecorder.Core/Recorder.cs"
test -f "BililiveRecorder.Core/IRoom.cs" \\
  && ok "BililiveRecorder.Core/IRoom.cs" \\
  || miss "missing critical file: BililiveRecorder.Core/IRoom.cs"
test -f "BililiveRecorder.Core/Api/IApiClient.cs" \\
  && ok "BililiveRecorder.Core/Api/IApiClient.cs" \\
  || miss "missing critical file: BililiveRecorder.Core/Api/IApiClient.cs"
test -f "BililiveRecorder.Core/Config/V3/ConfigV3.cs" \\
  && ok "BililiveRecorder.Core/Config/V3/ConfigV3.cs" \\
  || miss "missing critical file: BililiveRecorder.Core/Config/V3/ConfigV3.cs"
test -f "BililiveRecorder.Core/Recording/IRecordTask.cs" \\
  && ok "BililiveRecorder.Core/Recording/IRecordTask.cs" \\
  || miss "missing critical file: BililiveRecorder.Core/Recording/IRecordTask.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 31 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1d)"
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/BililiveRecorder/BililiveRecorder"
  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).

BililiveRecorder is a pure C# application that automatically records live streams from Bilibili (a Chinese video platform) and repairs corrupted FLV stream files without external dependencies like FFmpeg. It monitors multiple channels simultaneously, detects when streams go live, and records them while also offering a toolbox mode to fix broken recordings from other software. Modular C# architecture split into BililiveRecorder.Core (API clients, danmaku transport layer with TCP/WebSocket/secure variants in Api/Danmaku/, HTTP client with BUVID/WBI auth) and BililiveRecorder.Cli (command-line interface with configuration generation). The Core exposes interfaces (IApiClient, IDanmakuClient) that implementations wrap with PolicyWrappedApiClient for resilience.

Chinese Bilibili streamers and content archivists who need reliable automated recording of live broadcasts, plus developers maintaining recording infrastructure that requires programmatic stream capture without system-level FFmpeg dependencies.

Production-ready and actively maintained. The project has CI/CD pipelines (build.yml, release.yml, codeql.yml), Docker support (Dockerfile + hub.docker.com distribution), and a version management system with releases on GitHub. However, maturity assessment limited by visible metadata—check GitHub stars and last commit timestamp for activity confirmation.

Moderate risk: the codebase is tightly coupled to Bilibili's proprietary API surface (DanmakuClient, HttpApiClient, Wbi signing in Http/Wbi.cs) which can break unexpectedly when the platform changes endpoints or authentication. Single large C# codebase without visible monorepo structure means refactoring affects many subsystems; no visible test count in file list is a concern for streaming logic reliability.

Unable to determine from file list alone—check GitHub Actions workflow runs and commit log. Visible infrastructure: copyright year auto-update workflow, CodeQL security scanning enabled, desktop release packaging pipeline (package-desktop-release.yml suggests ongoing GUI maintenance).

git clone https://github.com/BililiveRecorder/BililiveRecorder.git
cd BililiveRecorder
dotnet restore
dotnet build

For CLI usage: dotnet run --project BililiveRecorder.Cli. TypeScript tooling (if needed for web UI) requires npm install at the TypeScript workspace root, then npm run build.

Daily commands:

# Core library builds to dll
dotnet build BililiveRecorder.Core/BililiveRecorder.Core.csproj

# Run CLI
dotnet run --project BililiveRecorder.Cli -- --help

# Docker
docker pull bililive/recorder
docker run bililive/recorder

Check BililiveRecorder.Cli/Program.cs for CLI entry point and ConfigureCommand.cs for configuration flow.

• BililiveRecorder.Core/Recorder.cs — Core orchestration class that manages room recording sessions and lifecycle—every contributor must understand the main entry point for recording functionality
• BililiveRecorder.Core/IRoom.cs — Primary interface for room abstraction; defines the contract for recording rooms and is fundamental to the plugin/extension model
• BililiveRecorder.Core/Api/IApiClient.cs — Abstraction for Bilibili API interactions; all network communication with the streaming platform depends on this interface
• BililiveRecorder.Core/Config/V3/ConfigV3.cs — Latest configuration schema version; critical for understanding how recorder settings are persisted and validated
• BililiveRecorder.Core/Recording/IRecordTask.cs — Interface for recording task execution; defines how FLV streaming and file writing are coordinated
• BililiveRecorder.Core/Api/Danmaku/IDanmakuClient.cs — Danmaku (bullet chat) client abstraction; essential for understanding real-time comment capture alongside video recording
• BililiveRecorder.Core/DependencyInjectionExtensions.cs — DI container setup for the entire core library; required for understanding how components are wired and instantiated

Add a New Configuration Parameter

1. Define the parameter in BililiveRecorder.Core/Config/V3/ConfigV3.cs by adding a public property with backing field and OnPropertyChanged notification (BililiveRecorder.Core/Config/V3/ConfigV3.cs)
2. Update the JSON schema at BililiveRecorder.Core/Config/V3/config.schema.json to include the new property with type, description, and constraints (BililiveRecorder.Core/Config/V3/config.schema.json)
3. Add migration logic in BililiveRecorder.Core/Config/ConfigMapper.cs to handle older config versions that lack this parameter (BililiveRecorder.Core/Config/ConfigMapper.cs)
4. If needed, add a CLI prompt in BililiveRecorder.Cli/Configure/ConfigInstruction.cs to allow users to set this parameter interactively (BililiveRecorder.Cli/Configure/ConfigInstruction.cs)

Add a New Danmaku Transport Mode

1. Create a new transport class implementing IDanmakuTransport in BililiveRecorder.Core/Api/Danmaku/ (e.g., DanmakuTransportNewMode.cs) (BililiveRecorder.Core/Api/Danmaku/IDanmakuTransport.cs)
2. Add the new transport mode enum value to BililiveRecorder.Core/Config/DanmakuTransportMode.cs (BililiveRecorder.Core/Config/DanmakuTransportMode.cs)
3. Update DanmakuClient.cs to instantiate your new transport in the switch/factory logic when that mode is selected (BililiveRecorder.Core/Api/Danmaku/DanmakuClient.cs)
4. Implement IDanmakuTransport methods: Connect, Disconnect, and fire DanmakuReceived events for received packets (BililiveRecorder.Core/Api/Danmaku/IDanmakuTransport.cs)

Add a New API Endpoint Call

1. Define a new method in BililiveRecorder.Core/Api/IApiClient.cs interface for the API call (e.g., Task<T> GetNewData(...)) (BililiveRecorder.Core/Api/IApiClient.cs)
2. Implement the method in BililiveRecorder.Core/Api/Http/HttpApiClient.cs, including URL construction, request headers, and response parsing (BililiveRecorder.Core/Api/Http/HttpApiClient.cs)
3. If the endpoint requires Bilibili's WBI signature, use the Wbi.cs class to sign the request (BililiveRecorder.Core/Api/Http/Wbi.cs)
4. Optionally add a convenience extension method in BililiveRecorder.Core/Api/IApiClientExtensions.cs if the call has complex pre/post-processing (BililiveRecorder.Core/Api/IApiClientExtensions.cs)

Add a New Event Type & Handler

1. Create a new event args class in BililiveRecorder.Core/Event/ inheriting from RecordEventArgsBase (e.g., MyCustomEventArgs.cs) (BililiveRecorder.Core/Event/RecordEventArgsBase.cs)
2. Add an event property to IRoom.cs or Recorder.cs using EventHandler<MyCustomEventArgs> (BililiveRecorder.Core/IRoom.cs)
3. Fire the event from the appropriate location (e.g., in Recorder.cs or the recording task) using RaiseEvent() or OnMyCustomEvent() pattern (BililiveRecorder.Core/Recorder.cs)
4. Subscribe to the event in the CLI or UI layer (BililiveRecorder.Cli/Program.cs or equivalent) and handle the notification (BililiveRecorder.Cli/Program.cs)

Bilibili API authentication: WBI signature scheme (Http/Wbi.cs) is reverse-engineered and fragile—Bilibili updates this quarterly, breaking all API calls. Danmaku transport multiplexing: three transports (TCP, WS, WSS) have protocol quirks; testing locally requires live stream. FLV repair logic: assumes unprocessed Bilibili FLV stream format—muxed or re-encoded files cannot be fixed. No visible dotnet tool setup docs: .config/dotnet-tools.json exists but usage is undocumented—check for local tool dependencies. Chinese-language codebase: comments and issue templates are in Chinese; configuration instruction generation (ConfigInstructions.gen.cs) suggests autogenerated code, don't edit directly.

• WBI Signature (Bilibili proprietary auth) — The Http/Wbi.cs module implements reverse-engineered cryptographic signing required by Bilibili's API; understanding this is critical for debugging API failures and maintaining compatibility with platform updates
• Danmaku (弹幕) Protocol — Chinese streaming platforms use a WebSocket-based protocol for real-time comments and donations; BililiveRecorder implements this in DanmakuTransport subclasses to log metadata and detect stream state changes
• FLV stream repair (FLVFIX) — Bilibili's stream servers occasionally produce malformed FLV files with broken keyframes or duration metadata; BililiveRecorder's toolbox mode surgically fixes these without re-encoding, preserving original quality
• Pluggable transport abstraction (IDanmakuTransport) — The Danmaku layer defines three implementations (TCP, WS, WSS) behind a common interface; understanding this pattern is essential for adding Bilibili protocol variants or debugging transport-specific issues
• Policy-wrapped resilience (Polly pattern) — PolicyWrappedApiClient wraps the Bilibili HTTP client with retry/backoff logic to handle transient API failures; critical for reliable 24/7 recording of unpredictable stream uptime
• BUVID cookie tracking — Bilibili requires a unique device identifier (BUVID) in HTTP headers; Http/Buvid.cs manages generation and persistence, without which API requests are rate-limited or blocked

• dd-center/bilibili-live-api — Community-maintained Bilibili live API documentation and examples; reference for WBI signature updates and undocumented endpoints
• flv.js/flv.js — JavaScript FLV parser used in web-based stream playback tools; complementary to BililiveRecorder's FLV repair and remux features
• yt-dlp/yt-dlp — Analogous live stream recorder for YouTube/Twitch; similar architecture pattern of API wrapping + stream capture, useful for architecture inspiration
• BililiveRecorder/BililiveRecorder-WebUI — Official web UI companion project for remote monitoring and control of recording instances
• ffmpeg/ffmpeg — While BililiveRecorder has no hard FFmpeg dependency, the bundled minimal FFmpeg in desktop edition is used for remuxing; relevant for output format support

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 BililiveRecorder.Core/Api/Http/Wbi.cs WBI signature algorithm

The Wbi.cs file implements Bilibili's WBI (Web API signature) algorithm which is critical for API requests. Currently, there appear to be no dedicated unit tests for this crypto-sensitive component. This is high-value because: (1) WBI signatures are security-critical for API authentication, (2) any regression could break all HTTP API calls, (3) test vectors from real Bilibili responses would ensure compatibility across versions.

• [ ] Create BililiveRecorder.Core.Tests/Api/Http/WbiTests.cs with unit tests
• [ ] Test the signature generation against known Bilibili WBI challenge/signature pairs
• [ ] Test edge cases: empty parameters, special characters, parameter ordering
• [ ] Add integration test in existing test suite to verify WBI signatures work with HttpApiClient.cs

Add GitHub Actions workflow for .NET code quality (StyleCop/FxCop analysis)

The repo has build.yml and codeql.yml workflows, but no .NET-specific static analysis workflow. Given the presence of BannedSymbols.txt and multiple .csproj files, there's infrastructure for code style enforcement that isn't being validated in CI. This PR would: (1) catch style violations early before code review, (2) enforce consistency across BililiveRecorder.Core, BililiveRecorder.Cli, and other projects, (3) prevent technical debt from accumulating.

• [ ] Create .github/workflows/dotnet-analysis.yml workflow file
• [ ] Configure StyleCop/FxCop analyzers via .editorconfig and/or BannedSymbols.txt validation
• [ ] Run 'dotnet analyzers' or equivalent on all *.csproj files in the matrix
• [ ] Make workflow run on pull_request events to block non-compliant PRs

Document and add tests for BililiveRecorder.Core/Config/V1 to V2 migration (ConfigMapper.cs)

The ConfigMapper.cs in BililiveRecorder.Core/Config handles migration from ConfigV1 to V2, which is critical infrastructure for user upgrades. However, there's no visible test coverage or documentation of migration scenarios. This is valuable because: (1) config migrations are brittle and easy to regress, (2) users relying on legacy V1 configs need confidence in the upgrade path, (3) tests would prevent silent data loss during version transitions.

• [ ] Create BililiveRecorder.Core.Tests/Config/ConfigMapperTests.cs with comprehensive migration test cases
• [ ] Test migration of sample V1 configs (from BililiveRecorder.Core/Config/V1/) to V2 format
• [ ] Verify all V1 room and global settings are preserved and correctly mapped to V2 equivalents
• [ ] Add documentation in BililiveRecorder.Core/Config/README.md explaining the V1→V2 migration strategy

• Add integration tests for BililiveRecorder.Core/Api/Http/HttpApiClient.cs covering room info and stream URL retrieval with mock responses—currently no test files visible for the primary API surface
• Document the WBI signature algorithm in BililiveRecorder.Core/Api/Http/Wbi.cs with inline comments and link to the reverse-engineering source (likely a Chinese wiki or community doc)—future maintainers need to understand when Bilibili breaks this
• Create a TypeScript/HTML test page in the workspace root for the danmaku transport layer (simulating TCP/WS/WSS connections)—the UI exists but e2e testing infrastructure is not visible

• Medium · Outdated TypeScript Dependencies — package.json. The package.json contains TypeScript dev dependencies pinned to versions from 2021 (TypeScript 4.3.5, ts-node 10.2.0, @types/node 16.11.39). These versions are significantly outdated and may contain known vulnerabilities. While this is a build-time dependency, it could introduce security risks during the build process. Fix: Update all TypeScript dependencies to their latest stable versions. Run 'npm audit' to identify and fix vulnerabilities. Consider using dependency management tools like Dependabot for automated updates.
• Medium · Exposed Port in Docker Configuration — Dockerfile. The Dockerfile exposes port 2356/tcp (EXPOSE 2356/tcp) with the default bind address set to 'http://*:2356', making the service accessible on all network interfaces by default. This could expose the application to unauthorized access if deployed in an untrusted network. Fix: Bind to localhost (127.0.0.1) by default, or require explicit configuration for network exposure. Document security implications in README. Consider using firewall rules or network policies to restrict access in production.
• Medium · Alpine Linux Base Image Without Security Scanning — Dockerfile. While Alpine is a lightweight base image, the Dockerfile uses 'mcr.microsoft.com/dotnet/sdk:8.0-alpine' and 'mcr.microsoft.com/dotnet/aspnet:8.0-alpine' without specifying exact tags. This could lead to unexpected base image changes when rebuilding. Additionally, there is no explicit security scanning or vulnerability checks in the CI/CD pipeline visible. Fix: Pin Docker base images to specific SHA256 digests instead of tag names. Add image scanning to CI/CD pipeline using tools like Trivy or Snyk. Consider using 'FROM mcr.microsoft.com/dotnet/aspnet:8.0-alpine@sha256:...' for reproducible builds.
• Low · Potential Danmaku Client Security Risk — BililiveRecorder.Core/Api/Danmaku/DanmakuTransport*.cs. The codebase includes danmaku (bullet comment) handling via WebSocket, TCP, and WebSocket Secure transports (DanmakuTransport*.cs files). WebSocket connections could be vulnerable to man-in-the-middle attacks if not properly validated. The presence of multiple transport modes suggests some may not enforce TLS/SSL. Fix: Ensure all WebSocket connections use WSS (secure WebSocket) by default. Implement certificate validation for TLS connections. Add security headers for WebSocket handshakes. Review and test each transport mode for security compliance.
• Low · HTTP API Client Without Visible Security Headers — BililiveRecorder.Core/Api/Http/HttpApiClient.cs. The HttpApiClient (BililiveRecorder.Core/Api/Http/HttpApiClient.cs) is responsible for API communication. Without reviewing the implementation, there's a risk of missing security headers, improper certificate validation, or vulnerable HTTP handling. Fix: Implement and enforce security headers (Content-Security-Policy, X-Content-Type-Options, etc.). Use HttpClientHandler with proper certificate validation. Implement request/response logging without exposing sensitive data. Consider using HTTP/2 or HTTP/3.
• Low · No Visible Input Validation Framework — BililiveRecorder.Core/Config/ConfigParser.cs, BililiveRecorder.Core/Api/. The codebase handles configuration parsing (ConfigParser.cs) and HTTP API responses without a clearly visible input validation or sanitization framework. This could lead to injection attacks if user input or API responses are not properly validated. Fix: Implement comprehensive input validation for all user-controlled inputs. Use allowlist validation where possible. Sanitize all external API responses before processing. Consider using a validation library like FluentValidation.
• Low · Missing Security Policy Documentation — Repository Root. The repository does not appear to have a SECURITY.md file or security policy documentation. This makes it difficult for security researchers to report vulnerabilities responsibly. Fix: Create a SECURITY.md file with instructions for reporting security vulnerabilities. Include responsible disclosure timeline and contact information. Add security section to README.md.
• Low · Hardcoded Default Environment — undefined. undefined Fix: undefined

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.